creating infrastructure for NL libraries
diff --git a/.project b/.project
new file mode 100644
index 0000000..d7189d7
--- /dev/null
+++ b/.project
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<projectDescription>
+ <name>nl_libraries</name>
+ <comment></comment>
+ <projects>
+ </projects>
+ <buildSpec>
+ </buildSpec>
+ <natures>
+ </natures>
+</projectDescription>
diff --git a/OpenUP/OpenUP_PT/HTML_to_be_imported/temp b/OpenUP/OpenUP_PT/HTML_to_be_imported/temp
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/OpenUP/OpenUP_PT/HTML_to_be_imported/temp
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/Custom Categories.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/Custom Categories.xmi
new file mode 100644
index 0000000..452d87a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/Custom Categories.xmi
@@ -0,0 +1,2 @@
+<?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="_rgwycf1WEdmek8CQTQgrOQ" name="Custom Categories,_WCguSe8KEdmKSqa_gSYthg" guid="_rgwycf1WEdmek8CQTQgrOQ"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/base_concepts_view_building_blocks.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/base_concepts_view_building_blocks.xmi
new file mode 100644
index 0000000..9d7f4f4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/base_concepts_view_building_blocks.xmi
@@ -0,0 +1,2 @@
+<?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="__cpIYBTLEdqrUt4zetC1gg" guid="__cpIYBTLEdqrUt4zetC1gg"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/base_concepts_view_inserts.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/base_concepts_view_inserts.xmi
new file mode 100644
index 0000000..cd7ead7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/base_concepts_view_inserts.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="__cpIYBTLEdqrUt4zetC1gg" name="base_concepts_view_building_blocks,_7-x6YBTLEdqrUt4zetC1gg" guid="__cpIYBTLEdqrUt4zetC1gg" changeDate="2005-09-01T16:58:54.943-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/categories.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/categories.xmi
new file mode 100644
index 0000000..c427fd2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/categories.xmi
@@ -0,0 +1,23 @@
+<?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="_yrIvUBTMEdqrUt4zetC1gg" name="categories,_yqwU0BTMEdqrUt4zetC1gg" guid="_yrIvUBTMEdqrUt4zetC1gg" changeDate="2005-10-26T23:27:36.315-0700">
+ <mainDescription><p>
+ Categories provide different ways to logically organize Content Elements. In addition to Standard Categories that have
+ been predefined for most Content Element types in UMA, <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/concepts/custom_category,_xuO10BUGEdqrUt4zetC1gg.html"
+ guid="_xuO10BUGEdqrUt4zetC1gg">Custom Categories</a> can be used to either of the following:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Categorize content based on the user's criteria.
+ </li>
+ <li>
+ Define tree-structures of nested categories allowing the user to systematically navigate and browse Method
+ Content as well as Processes based on these categories. When&nbsp;Custom Categories are used in this way they
+ are also referred to&nbsp;as <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/concepts/view,_uMKSsBUFEdqrUt4zetC1gg.html"
+ guid="_uMKSsBUFEdqrUt4zetC1gg">Views</a>.
+ </li>
+ </ul>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/cc_list.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/cc_list.xmi
new file mode 100644
index 0000000..20114de
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/cc_list.xmi
@@ -0,0 +1,2 @@
+<?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="_6B9_MO8KEdmKSqa_gSYthg" guid="_6B9_MO8KEdmKSqa_gSYthg"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/guidance 2.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/guidance 2.xmi
new file mode 100644
index 0000000..293561a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/guidance 2.xmi
@@ -0,0 +1,15 @@
+<?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="_xy2SAQIsEdqEutyfYo0quQ" guid="_xy2SAQIsEdqEutyfYo0quQ" changeDate="2005-10-28T22:47:06.839-0700">
+ <mainDescription><p>
+ UMA&nbsp;defines a number of pre-defined concrete Guidance Types.
+</p>
+<p>
+ Associations and multiplicities have been predefined on the level of detail as depicted to ensure that Guidance is only
+ related to appropriate Content Elements. For example, UMA defines that Templates can only be associated with Work
+ Products. Guidance association rules are specified with the following UML diagram:
+</p>
+<p align="center">
+ <img height="571" alt="UML diagram showing Guidance relationships"
+ src="./../guidances/concepts/resources/guidance_uml.gif" width="586" />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/guidance.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/guidance.xmi
new file mode 100644
index 0000000..4fe6ec7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/guidance.xmi
@@ -0,0 +1,2 @@
+<?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="_RdU9MAIhEdqEutyfYo0quQ" name="guidance,_RdIv8AIhEdqEutyfYo0quQ" guid="_RdU9MAIhEdqEutyfYo0quQ" changeDate="2005-07-31T17:15:02.367-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_and_process_fundamentals.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_and_process_fundamentals.xmi
new file mode 100644
index 0000000..ca3e085
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_and_process_fundamentals.xmi
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_uDU1oQSEEdq61bDkWg1SXw" name="method_architecture_fundamentals,_uDU1oASEEdq61bDkWg1SXw" guid="_uDU1oQSEEdq61bDkWg1SXw" changeDate="2005-09-07T00:41:01.369-0700">
+ <mainDescription><h3>
+ What is UMA?
+</h3>
+<p>
+ UMA is a state-of-the-art architecture for the conceiving, specifying, and storing of method and process metadata
+ (a.ka. content). Its defining feature and fundamental innovation is that it achieves clear separation between generic
+ core method content and it its application in the specification of business processes.
+</p>
+<h3>
+ Key Aspects of UMA
+</h3>
+<h4>
+ Fundamental Elements
+</h4>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif">< alt="Method versus Process Content"
+ src="./../guidances/concepts/resources/uma_m_vs_p.gif" width="480" border="0" /></font>
+</p>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif">Overview of how the key UMA concepts positioned based on whether they
+ represent methodcontent or process</font>
+</p>
+<!--EndFragment-->
+<h4>
+ Separation of Concerns
+</h4>
+<p>
+ <font face="Arial, Helvetica, sans-serif">Key <em>separations of concerns</em> in the design UMA<em>:</em></font>
+</p>
+<blockquote>
+ <p>
+ <font face="Arial, Helvetica, sans-serif">•The separation of core method content versus the application of method
+ content in processes<br />
+ •The definition of an optional extensibility mechanism in the method for large scale management of method and
+ process repositories<br />
+ •Packaging and configuration of method content, processes, and plugins in method libraries<br />
+ •A separation of recommended method and guidance description fields<br />
+ •A separation of semantic elements from their notation in process diagrams</font>
+ </p>
+</blockquote>
+<h4>
+ <font face="Arial, Helvetica, sans-serif">Method Content versus Process</font>
+</h4>
+<p>
+ <font face="Arial, Helvetica, sans-serif">The Unified Method Architecture (UMA) separates reusable core method content
+ from its application inprocesses.Methodcontent provides step-by-step explanations, describing how specific development
+ goals are achievedindependent oftheplacement of these steps within a development lifecycle. Processes take these method
+ elements and relatethemintosemi-ordered sequences that are customized to specific types of projects.<br />
+ For example, a software development project that develops an application from scratch performs development
+ taskssuchas“Develop Vision” or “Use Case Design” similar to a project that extends an existing software system.
+ However,thetwoprojects will perform the Tasks at different points in time with a different emphasis, i.e. they will
+ perform thestepsofthese tasks at different point of time and perhaps apply individual variations and additions.<br />
+ In contrast to other method engineering approaches, UMA’s unique solution allows each process to
+ referencecommonmethodguidance from a common method content pool, which then makes up the actual process guidance.
+ Becauseofthesereferences, changes in the methods will automatically be reflected in all processes using it.
+ However,UMAstillallows overwriting certain method related guidance within a process as well as
+ definingindividualprocess-specificrelationships for each process element (such as work breakdown and new relations to
+ work productsandroles).<br />
+ Figure 4 shows the difference between method content and process by representing them as twodifferentdimensions.Method
+ content describing how development work is being performed is categorized bydisciplines.Each discipline iscomprised of
+ tasks (not visible in Figure 4) that provide step-by-step descriptions ofhow specificdevelopment goals areachieved. For
+ a process, tasks have been selected from the method content and placedintoworkflows ready forinstantiation by
+ allocating resources to perform the work and having real work products as theinputsand outputs of thetasks. As a
+ result, the workload graphs shown in Figure 4 can be computed showing work effortforeach disciplineover time (from left
+ to right).<br />
+ <br />
+ </font>
+</p>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif"><img alt=&Structure of the UMA Meta-Model"
+ src="./../guidances/concepts/resources/uma_hump.gif" border="0" /></font>
+</p>
+<p class="picturetext" align="center">
+ <font face="Arial, Helvetica, sans-serif">Figure 4: Method Content definition versus<br />
+ the application of Method Content in a Process.</font>
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_architecture_fundamentals.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_architecture_fundamentals.xmi
new file mode 100644
index 0000000..cff070d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_architecture_fundamentals.xmi
@@ -0,0 +1,199 @@
+<?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" epf:version="1.0.0" xmi:id="_uDU1oQSEEdq61bDkWg1SXw" guid="_uDU1oQSEEdq61bDkWg1SXw" changeDate="2005-10-30T16:58:11.631-0800">
+ <mainDescription><h3>
+ What is UMA?
+</h3>
+<p>
+ The Unified Method Architecture (UMA) is a process engineering meta-model that defines schema and terminology for
+ representing methods consisting of method content and processes. Also see <a class="elementLinkWithType" href="./../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html" guid="_94_eoO8LEdmKSqa_gSYthg">Concept: Key Capabilities of the Unified Method Architecture (UMA)</a>&nbsp;for more
+ details.
+</p>
+<h3>
+ Fundamental principle within UMA
+</h3>
+<p>
+ UMA is based&nbsp;on the following fundamental&nbsp;separations of concern:
+</p>
+<ul>
+ <li>
+ The separation of core method content versus the application of method content in processes
+ </li>
+ <li>
+ The definition of an optional extensibility mechanism in the method for large scale management of method and
+ process repositories
+ </li>
+ <li>
+ Packaging and configuration of method content, processes, and plugins in method libraries
+ </li>
+ <li>
+ A separation of recommended method and guidance description fields
+ </li>
+ <li>
+ A separation of semantic elements from their notation in process diagrams
+ </li>
+</ul>
+<h3>
+ The Basic Elements of UMA
+</h3>
+<p>
+ The most fundamental principle of the Unified Method Architecture (UMA) is the separation of&nbsp;reusable core method
+ content from its application in processes and almost all of UMA's elements are categorized along this separations.
+</p>
+<p>
+ The Unified Method Architecture separates reusable core method content from its application in processes.&nbsp; Method
+ content describes what is to be produced, the necessary skills required and the step-by-step explanation describing how
+ specific development goals are achieved, independently of the placement of these items within a development
+ lifecycle.&nbsp; Processes take these method elements and relate them into semi-ordered sequences that are customized
+ to specific types of projects. For example, a software development project that develops an application from scratch
+ performs development tasks such as "Develop Vision" or "Use Case Design" similar to a project that extends an existing
+ software system.&nbsp; However, the two projects will perform the Tasks at different points in time with a different
+ emphasis, i.e. they will perform the steps of these tasks at different point of time and perhaps apply individual
+ variations and additions.
+</p>
+<p>
+ The figure below shows the difference between method content and process by representing them as two different
+ dimensions:
+</p>
+<ul>
+ <li>
+ Method content describing how development work is being performed is categorized by disciplines.&nbsp; Each
+ discipline is comprised of tasks (not visible in the figure) that provide step-by-step descriptions of how specific
+ development goals are achieved.&nbsp;
+ </li>
+ <li>
+ For a process, tasks have been referenced by the process from the method content and placed into breakdown
+ structures and workflows ready for instantiation by allocating resources to perform the work and having real work
+ products as the inputs and outputs of the tasks.<br />
+ </li>
+</ul>
+<p align="center">
+ <img alt="Diagram illustrating the separation of Method and Process content within the UMA Meta-Model" src="../guidances/concepts/resources/uma_hump.jpg" border="0" />
+</p>
+<p class="picturetext" align="center">
+ Method Content definition versus<br />
+ the application of Method Content in a Process.
+</p>
+<p>
+ UMA's key concepts reflect this separation of method content from process as shown in the figure below.&nbsp; It show
+ that a Method (also refered to as a Method Framework) comprises on method content described with concepts such Work
+ Products, Roles, Task and Categories as well as Processes described with Activities, Capability Patterns, or Delivery
+ Processes.
+</p>
+<p align="center">
+ <img alt="Diagram illustrating that the intersection between Method and Process content is guidance" src="../guidances/concepts/resources/uma_m_vs_p.gif" />
+</p>
+<p align="center">
+ Overview of how the key UMA concepts are positioned based on whether they represent method content or process
+</p>
+<p class="picturetext" align="left">
+ Key <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/method_concepts,_WfL28BTMEdqrUt4zetC1gg.html" guid="_WfL28BTMEdqrUt4zetC1gg">Method Content Elements</a> &nbsp;are:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html" guid="4.804531471620803E-306">Work Product</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/role,1.1609745730665898E-304.html" guid="1.1609745730665898E-304">Role</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html" guid="7.624729048911575E-305">Task</a>
+ </div>
+ </li>
+ </ul>
+</div>
+<p class="picturetext" align="left">
+ Key <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/process_concepts,_AtM0gBTQEdqrUt4zetC1gg.html" guid="_AtM0gBTQEdqrUt4zetC1gg">Process Elements</a> &nbsp;are:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html" guid="3.132140065969088E-305">Activity</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html" guid="1.7072348895114264E-305">Capability Pattern</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html" guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>
+ </div>
+ </li>
+ </ul>
+</div>
+<p class="picturetext" align="left">
+ <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/guidance,_xy2SAAIsEdqEutyfYo0quQ.html" guid="_xy2SAAIsEdqEutyfYo0quQ">Guidance</a> &nbsp;comes in many types:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/checklist,_2vVuUBT9EdqrUt4zetC1gg.html" guid="_2vVuUBT9EdqrUt4zetC1gg">Checklist</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/concept,_8wobABUAEdqrUt4zetC1gg.html" guid="_8wobABUAEdqrUt4zetC1gg">Concept</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/example,_dCG-UBUBEdqrUt4zetC1gg.html" guid="_dCG-UBUBEdqrUt4zetC1gg">Example</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/guideline,_IAwkEBUEEdqrUt4zetC1gg.html" guid="_IAwkEBUEEdqrUt4zetC1gg">Guideline</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/practice,_szl6EBUBEdqrUt4zetC1gg.html" guid="_szl6EBUBEdqrUt4zetC1gg">Practice</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/report,_x2sAgBUBEdqrUt4zetC1gg.html" guid="_x2sAgBUBEdqrUt4zetC1gg">Report</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/reusable_asset,_20bs4BUBEdqrUt4zetC1gg.html" guid="_20bs4BUBEdqrUt4zetC1gg">Reusable Asset</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/roadmap,_JCQbIBnXEdqYreeU3jqaDQ.html" guid="_JCQbIBnXEdqYreeU3jqaDQ">Roadmap</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/supporting_material,_80XPABUBEdqrUt4zetC1gg.html" guid="_80XPABUBEdqrUt4zetC1gg">Supporting Material</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/template,_G_UnIBUCEdqrUt4zetC1gg.html" guid="_G_UnIBUCEdqrUt4zetC1gg">Template</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/term_definition,_Z45fwBUDEdqrUt4zetC1gg.html" guid="_Z45fwBUDEdqrUt4zetC1gg">Term Definition</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/tool_mentor,1.0762105093945226E-304.html" guid="1.0762105093945226E-304">Tool Mentor</a>
+ </div>
+ </li>
+ </ul>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_concepts.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_concepts.xmi
new file mode 100644
index 0000000..45a30a7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_concepts.xmi
@@ -0,0 +1,33 @@
+<?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="_WfkRcBTMEdqrUt4zetC1gg" name="method_concepts,_WfL28BTMEdqrUt4zetC1gg" guid="_WfkRcBTMEdqrUt4zetC1gg" changeDate="2005-11-07T15:54:23.625-0800">
+ <mainDescription><p>
+ Method Content is fundamentally described by defining Tasks described with Steps that have Work Products as input and
+ output and which are&nbsp;performed by Roles.&nbsp; Roles also define important responsibility relationships to work
+ products.
+</p>
+<p>
+ The fundamental Method Content abstractions are:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">Work Product</a>, which includes <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/artifact,_fdRfkBUJEdqrUt4zetC1gg.html"
+ guid="_fdRfkBUJEdqrUt4zetC1gg">Artifact</a>, <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/deliverable,_lBgkMBUJEdqrUt4zetC1gg.html"
+ guid="_lBgkMBUJEdqrUt4zetC1gg">Deliverable</a>&nbsp;and <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/outcome,_pROF4BUJEdqrUt4zetC1gg.html"
+ guid="_pROF4BUJEdqrUt4zetC1gg">Outcome</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/role,1.1609745730665898E-304.html"
+ guid="1.1609745730665898E-304">Role</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">Task</a>
+ </li>
+</ul>
+<br align="center" />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_package.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_package.xmi
new file mode 100644
index 0000000..1e7633b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/method_package.xmi
@@ -0,0 +1,20 @@
+<?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="-G5kN9IUns9GPxohNmAeeyw" name="method_package,_R5Vk4BtpEdqSLrJ4Ij2LVA" guid="-G5kN9IUns9GPxohNmAeeyw" changeDate="2005-10-27T14:50:07.109-0700">
+ <mainDescription><p>
+ Method Packages physically organize Method Elements&nbsp;into package hierarchies. All Method Elements are located in
+ exactly one Method Package.
+</p>
+<p>
+ There are two type of Method Package:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/content_package,_49a10BUFEdqrUt4zetC1gg.html"
+ guid="_49a10BUFEdqrUt4zetC1gg">Content Package</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/process_package,_MT6U8BneEdqYreeU3jqaDQ.html"
+ guid="_MT6U8BneEdqYreeU3jqaDQ">Process Package</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/navigating_the_process.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/navigating_the_process.xmi
new file mode 100644
index 0000000..30e1322
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/navigating_the_process.xmi
@@ -0,0 +1,2 @@
+<?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="_3uTl0QSHEdq61bDkWg1SXw" guid="_3uTl0QSHEdq61bDkWg1SXw" changeDate="2005-09-07T04:00:10.170-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/organizational_concepts.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/organizational_concepts.xmi
new file mode 100644
index 0000000..d8137b1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/organizational_concepts.xmi
@@ -0,0 +1,35 @@
+<?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="_TqJmsBTQEdqrUt4zetC1gg" name="organizational_concepts,_Tp3S0BTQEdqrUt4zetC1gg" guid="_TqJmsBTQEdqrUt4zetC1gg" changeDate="2005-11-08T15:04:09.331-0800">
+ <mainDescription><p>
+ This section describes concepts that are only used to organize method content and processes in an authoring
+ environment.None of these UMA abstractions are subject to publication.&nbsp;They include:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/method_library,_m8lGkBUFEdqrUt4zetC1gg.html"
+ guid="_m8lGkBUFEdqrUt4zetC1gg">Method Library</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+ guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugin</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+ guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>
+ </li>
+ <li>
+ Method Package, which includes <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/content_package,_49a10BUFEdqrUt4zetC1gg.html"
+ guid="_49a10BUFEdqrUt4zetC1gg">Content Package</a>, and <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/process_package,_MT6U8BneEdqYreeU3jqaDQ.html"
+ guid="_MT6U8BneEdqYreeU3jqaDQ">Process Package</a>
+ </li>
+</ul>
+<p>
+ These abstractions as well as their relationships are presented with the the following UML 2.0 class diagram:
+</p>
+<p align="center">
+ &nbsp;<img alt="UML Diagram describing the modeling or organizational abstractions"
+ src="../../base_concepts/guidances/concepts/resources/packaging_uml.gif" />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/process_concepts.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/process_concepts.xmi
new file mode 100644
index 0000000..f30bf9c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/process_concepts.xmi
@@ -0,0 +1,46 @@
+<?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="_AtZBwBTQEdqrUt4zetC1gg" name="process_concepts,_AtM0gBTQEdqrUt4zetC1gg" guid="_AtZBwBTQEdqrUt4zetC1gg" changeDate="2005-10-27T00:17:01.670-0700">
+ <mainDescription><p>
+ A Development Process defines the structured work definitions that need to be performed to develop a system, e.g. by
+ performing a project that follows the process.&nbsp; Such structured work definitions delineate the work to be
+ performed along a timeline or lifecycle and organize it in so called breakdown structures and/or activity diagrams. A
+ process takes reusable core method elements such as Tasks and Work Products and relates them into semi-ordered
+ sequences that are then customized to specific types of projects.
+</p>
+<p>
+ Fundamental concepts used in UMA to define processes include:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html"
+ guid="3.132140065969088E-305">Activity</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/process_contribution,_NYASQBtqEdqSLrJ4Ij2LVA.html"
+ guid="_NYASQBtqEdqSLrJ4Ij2LVA">Process Contribution</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/descriptor,_5V9HEBUEEdqrUt4zetC1gg.html"
+ guid="_5V9HEBUEEdqrUt4zetC1gg">Descriptor</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/composite_role,_P9gp0BtHEdqSLrJ4Ij2LVA.html"
+ guid="_P9gp0BtHEdqSLrJ4Ij2LVA">Composite Role</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/team_profile,_dRKRMBtHEdqSLrJ4Ij2LVA.html"
+ guid="_dRKRMBtHEdqSLrJ4Ij2LVA">Team Profile</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/compass.gif b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/compass.gif
new file mode 100644
index 0000000..39f306a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/compass.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/compassL.gif b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/compassL.gif
new file mode 100644
index 0000000..4117414
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/compassL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/concept_dgm32.gif b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/concept_dgm32.gif
new file mode 100644
index 0000000..fa195bd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/concept_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/concept_obj.gif b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/concept_obj.gif
new file mode 100644
index 0000000..03af38b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/concept_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/wp_uml_structure.gif b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/wp_uml_structure.gif
new file mode 100644
index 0000000..c2aad65
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/resources/wp_uml_structure.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/customcategories/view_building_blocks.xmi b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/view_building_blocks.xmi
new file mode 100644
index 0000000..d8c3666
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/customcategories/view_building_blocks.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_6B9_MO8KEdmKSqa_gSYthg" name="obsolete,_5_90EO8KEdmKSqa_gSYthg" guid="_6B9_MO8KEdmKSqa_gSYthg" changeDate="2005-09-01T16:54:43.741-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/activity.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/activity.xmi
new file mode 100644
index 0000000..68d4b36
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/activity.xmi
@@ -0,0 +1,26 @@
+<?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="_zaqEMNnmEdmO6L4XMImrsA" name="activity,3.132140065969088E-305" guid="_zaqEMNnmEdmO6L4XMImrsA" changeDate="2005-10-27T01:00:09.167-0700">
+ <mainDescription><p>
+ Activities are the fundamental concept for defining processes.&nbsp; Activities define the breakdown as well as flow of
+ work.&nbsp; In other words, Activities can be nested into each other defining a breakdown structure of work or they can
+ define predecessor relationships to other Activities defining a flow presented in Activity diagrams.&nbsp; Activities
+ can also contain references to Task, Roles, and Work Products called <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/descriptor,_5V9HEBUEEdqrUt4zetC1gg.html"
+ guid="_5V9HEBUEEdqrUt4zetC1gg">Descriptor</a>.&nbsp; Activities as well as Descriptors relate to timelines by allowing
+ their instances to define start and/or end dates.&nbsp; Further, they specify information relevant to the instantiation
+ of work in project such as if an Activity shall be performed several times and if so if they can be performed in
+ parallel (hasMultipleOccurrences attribute) or one after other (isRepeatable attribute).&nbsp; Activities and Task
+ Descriptors can also be event driven or describing ongoing work that does not have a fixed start and end time.
+</p>
+<p>
+ UMA defines several&nbsp;special Activities that allow expressing processes with terms many users are familiar
+ with.&nbsp; For example, Phase or Iteration are just special Activities for which specific attribute values have been
+ set with predefined values. A process such as a <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>&nbsp;or <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>&nbsp;is also nothing else than just a special Activity that
+ contains additional documentation on why and how to use the process. Hence, because Activities could be nested into
+ each other, so can processes.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/artifact.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/artifact.xmi
new file mode 100644
index 0000000..987f095
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/artifact.xmi
@@ -0,0 +1,59 @@
+<?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="_fdds0BUJEdqrUt4zetC1gg" name="artifact,_fdRfkBUJEdqrUt4zetC1gg" guid="_fdds0BUJEdqrUt4zetC1gg" changeDate="2006-04-13T14:05:00.252-0700">
+ <mainDescription><p>
+ Artifacts are tangible well-defined Work Products consumed, produced, or modified by Tasks.&nbsp; Artifacts may be
+ composed of other Artifacts. For example, a model Artifact can be composed of model elements, which are also Artifacts.
+ They may serve as a basis for defining Reusable Assets.&nbsp; Roles use Artifacts to perform Tasks and produce
+ Artifacts in the course of performing Tasks.
+</p>
+<p>
+ Artifacts are the responsibility of a single Role, making responsibility easy to identify and understand, and promoting
+ the idea that every piece of information produced in the method requires the appropriate set of skills. Even though one
+ Role might "own" a specific type of Artifact, other Roles can still use the Artifacts, and perhaps even update them if
+ the Role has been given permission to do so.
+</p>
+<p>
+ <b>Artifacts&nbsp;are generally <i>not</i> documents</b>. Many methods have an excessive focus on documents, and in
+ particular on <i>paper documentation</i>. The most efficient and pragmatic approach to managing project Artifacts is to
+ maintain&nbsp;them <i>within</i> the appropriate tool used to create and manage them. When necessary, one may generate
+ documents (snapshots) from these tools, on a just-in-time basis.
+</p>
+<p>
+ Examples Artifacts:
+</p>
+<ul>
+ <li>
+ A use case specification stored in&nbsp;a word processor tool&nbsp;
+ </li>
+ <li>
+ A design model stored in&nbsp;a visual modeling tool.&nbsp;
+ </li>
+ <li>
+ A project plan stored in&nbsp;a project planning tool.&nbsp;
+ </li>
+ <li>
+ A defect stored in&nbsp;a change requests tools&nbsp;
+ </li>
+ <li>
+ A project requirements database in a requirements management tool.
+ </li>
+</ul>
+<p>
+ Note also that formats such as on <b>whiteboards</b> or <b>flip charts</b> can be used to capture pictorial information
+ such as UML diagrams, tabular information such as short lists of status information or even textual information such as
+ short vision statements. These formats work well for smaller, collocated teams where all team members have ready access
+ to these resources.
+</p>
+<p>
+ However, there are still Artifacts which either have to be or are best suited to being plain text documents, as in the
+ case of external input to the project, or in some cases where it is simply the best means of presenting descriptive
+ information. Where possible, teams should consider using collaborative <b>Work Group</b> tools, such as WikiWiki webs
+ or Groove to capture textual documentation electronically, thus simplifying ongoing content and version management.
+ This is especially of importance where historic records must be maintained for purposes such as fulfilling audit
+ requirements. For any nontrivial development effort, especially where large development teams are involved, Work
+ Products <strong>are</strong> <strong>most likely to be subject to version control and configuration
+ management.</strong> This is sometimes only achieved by versioning the container Work Product, when it is not possible
+ to do it for the elementary, contained Work Products. For example, in software development, you may control the
+ versions of a whole design model, or design package, and not the individual classes they contain.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/capability_pattern.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/capability_pattern.xmi
new file mode 100644
index 0000000..7a7ec12
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/capability_pattern.xmi
@@ -0,0 +1,52 @@
+<?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="_zag6RdnmEdmO6L4XMImrsA" name="capability_pattern,1.7072348895114264E-305" guid="_zag6RdnmEdmO6L4XMImrsA" changeDate="2006-04-13T14:10:52.188-0700">
+ <mainDescription><a id="XE_WORKFLOW__KEY_CONCEPTS" name="XE_workflow__key_concepts"></a>
+<p>
+ Capabilities Patterns express and communicate process knowledge for a key area of interest such as a Discipline
+ or&nbsp;a practice and can be directly used by process practitioners to guide their work.&nbsp; They are also used as
+ building blocks to assemble <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Processes</a>&nbsp;or larger Capability Patterns ensuring optimal reuse and
+ application of the key practices they express.
+</p>
+<p>
+ Examples for Capability Pattern could be 'use case-based requirements management', 'use case analysis', or 'unit
+ testing'. Typically but not necessarily, Capability Patterns have the scope of one Discipline providing a breakdown of
+ reusable complex Activities, relationships to the Roles which perform Tasks within these Activities, as well as to the
+ Work Products that are used and produced.&nbsp; Generally, a Capability Pattern does not relate to any specific phase
+ or iteration of a development lifecycle, and should not imply any.&nbsp; In other words, a pattern should be designed
+ in a way that it is applicable anywhere in a Delivery Process.&nbsp; This enables its Activities to be flexibly
+ assigned to whatever phases there are in the Delivery Process to which it is being applied.&nbsp; An exception to this
+ would be capability patterns that are intended to provide a template for quickly creating an iteration or portion of an
+ iteration for a particular phase in a Delivery Process.<br />
+ <br />
+ Key applications&nbsp;or areas of reuse for Capability Patterns are:
+</p>
+<ul>
+ <li>
+ To serve as building blocks for assembling Delivery Processes or larger Capability Patterns.&nbsp; Normally
+ developing a Delivery Process is not done from scratch but by systematically applying and binding patterns.
+ </li>
+ <li>
+ To support direct execution in a development project that does not work following a well-defined process, but works
+ based on loosely connected process fragments of practices in a flexible manner (for example, Agile Development).
+ </li>
+ <li>
+ To support process education by describing knowledge for a key area such as practices on how to perform the work
+ for a Discipline (for example, Requirements Management), for a specific development technique (aspect-oriented
+ development), or a specific technical area (for example, relational database design), which is used for education
+ and teaching.<br />
+ </li>
+</ul>
+<p>
+ The workflow of a Capability Pattern is usually represented using the UML Activity Diagram notation.&nbsp;
+</p>
+<p align="center">
+ <img alt="Sample activity diagram representing the workflow of a Capability Pattern" src="resources/wf_req.gif" />
+</p>
+<p>
+ <font size="1">Sample activity diagram representing the workflow of a Capability Pattern</font>.<br />
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/checklist.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/checklist.xmi
new file mode 100644
index 0000000..04de421
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/checklist.xmi
@@ -0,0 +1,12 @@
+<?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="_2wY3MBT9EdqrUt4zetC1gg" name="checklist,_2vVuUBT9EdqrUt4zetC1gg" guid="_2wY3MBT9EdqrUt4zetC1gg" changeDate="2005-10-21T19:21:29.297-0700">
+ <mainDescription><p>
+ In UMA, a Content Element has at most one Checklist. Checklists, are useful in a number of contexts: they help you
+ decide what to do, they help doing it, they help&nbsp;assess the quality of the work, and they help understand how a
+ particular Work Product relates to the rest of the process.<!--EndFragment-->
+</p>
+<p>
+ Work products typically have an associated Checklist which present information on how to develop, evaluate and
+ use&nbsp;them .
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/composite_role.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/composite_role.xmi
new file mode 100644
index 0000000..f3cba48
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/composite_role.xmi
@@ -0,0 +1,18 @@
+<?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="-FD4UbInbyzlaGxB9oPHdcg" name="composite_role,_P9gp0BtHEdqSLrJ4Ij2LVA" guid="-FD4UbInbyzlaGxB9oPHdcg" changeDate="2005-09-01T17:19:52.101-0700">
+ <mainDescription><p>
+ A Composite Role is a grouping of Roles that can be used in an Activity or Process to reduce the number of Roles. A
+ Composite Role is thus for the Tasks and Work Products defined for the Roles it refers to. A typical use of this
+ construct occurs within a Process designed for a small team in which multiple standard Roles from the Method Content
+ are assigned to a single resource. By using a Composite Role the Process suggests a typical clustering of Roles to
+ Resources.<br />
+</p>
+<p>
+ A simple example is a Composite Role named <em><strong>Developer</strong></em> that groups together the
+ <em><strong>Implementer</strong></em> and <em><strong>Tester</strong></em> Roles. Now, every time one of the Roles
+ Implementer or Tester would normally be used within the breakdown structure, Developer is used instead. Hence, if a
+ Task Descriptor is added to the Process, that has Implementer or Tester as the primary performer, this Role would be
+ automatically be substituted by&nbsp;the Composite Role instance Developer that links back to either Tester or
+ Implementer (or both if both were listed as the Task performers).
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/concept.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/concept.xmi
new file mode 100644
index 0000000..e9fbfdf
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/concept.xmi
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_8w0oQBUAEdqrUt4zetC1gg" name="concept,_8wobABUAEdqrUt4zetC1gg" guid="_8w0oQBUAEdqrUt4zetC1gg" changeDate="2005-10-30T17:17:56.590-0800">
+ <mainDescription><p>
+ In the context of Software Engineering, key Concepts such as risk, performance testing, and so on, are introduced at
+ different levels in the process, and attached to the most appropriate Content Element. Some concepts are best
+ associated to a Discipline because they describe multiple Work Products and Tasks within this Discipline.
+</p>
+<p>
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/configuration.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/configuration.xmi
new file mode 100644
index 0000000..80c3e14
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/configuration.xmi
@@ -0,0 +1,30 @@
+<?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="_d7QQABUFEdqrUt4zetC1gg" name="configuration,_d698IBUFEdqrUt4zetC1gg" guid="_d7QQABUFEdqrUt4zetC1gg" changeDate="2005-11-04T18:15:35.245-0800">
+ <mainDescription><p>
+ A Method Configuration is a collection of selected <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+ guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugins</a>, <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/customcategories/method_package,_R5Vk4BtpEdqSLrJ4Ij2LVA.html"
+ guid="_R5Vk4BtpEdqSLrJ4Ij2LVA">Method Packages</a> and Processes (see <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Concept: Capability Pattern</a>, <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Concept: Delivery Process</a>). A Configuration can be exported into its own stand-alone
+ library when it includes the full transitive closure of all elements it depends on. A Method Configuration defines a
+ logical subset of a <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/method_library,_m8lGkBUFEdqrUt4zetC1gg.html"
+ guid="_m8lGkBUFEdqrUt4zetC1gg">Method Library</a>.
+</p>
+<h3>
+ Applications
+</h3>
+<p>
+ A Configuration is often built around one or more Delivery Processes. A Delivery Process can be valid for different
+ Method Configurations, but each Configuration may include or exclude particular content for specific situations. For
+ example, a Delivery Process can be defined to include content for developing schemas for different types of database
+ management systems, such as content for RDBMS and OODBMS. When using such a Delivery Process, users may want to select
+ just the type of DBMS used within their project, and hence exclude all content pertaining to other types of DBMS. They
+ achieve this by selecting a Configuration which excludes the respective content or by creating a new one if none such
+ already exists.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/content_package.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/content_package.xmi
new file mode 100644
index 0000000..0c459a5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/content_package.xmi
@@ -0,0 +1,2 @@
+<?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="_49tJsBUFEdqrUt4zetC1gg" name="content_package,_49a10BUFEdqrUt4zetC1gg" guid="_49tJsBUFEdqrUt4zetC1gg" changeDate="2005-09-22T14:32:00.057-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/custom_category.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/custom_category.xmi
new file mode 100644
index 0000000..47c1f76
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/custom_category.xmi
@@ -0,0 +1,24 @@
+<?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="_xuhJsBUGEdqrUt4zetC1gg" name="custom_category,_xuO10BUGEdqrUt4zetC1gg" guid="_xuhJsBUGEdqrUt4zetC1gg" changeDate="2005-10-26T23:47:50.212-0700">
+ <mainDescription><p>
+ A Custom Category is a category introduced by a method author to structure any number of Method Content Elements of any
+ type based on user-defined criteria. Custom categories can be used to categorize content based on the user's criteria
+ as well as to define whole tree-structures of nested categories allowing the user to systematically navigate and browse
+ Method Content and Processes based on these categories. This application of Custom Categories is also called <a
+ class="elementLink" href="./../../../base_concepts/guidances/concepts/view,_uMKSsBUFEdqrUt4zetC1gg.html"
+ guid="_uMKSsBUFEdqrUt4zetC1gg">View</a>.
+</p>
+<h3>
+ Examples
+</h3>
+<p>
+ One could create a Custom Category to logically organize content relevant for the user development organization's
+ departments: A "Testing" category would group together all Roles, Work Products, Tasks, Capability Patterns and
+ Guidance relevant to testing.
+</p>
+<p>
+ Another example would be categories that express licensing levels of the content: These categories would separate
+ freely distributable Method Content from Method Content that represents intellectual property and requires a purchased
+ license for use.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/deliverable.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/deliverable.xmi
new file mode 100644
index 0000000..6b1a966
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/deliverable.xmi
@@ -0,0 +1,13 @@
+<?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="_lBy4EBUJEdqrUt4zetC1gg" name="deliverable,_lBgkMBUJEdqrUt4zetC1gg" guid="_lBy4EBUJEdqrUt4zetC1gg" changeDate="2005-10-26T18:16:48.795-0700">
+ <mainDescription><p>
+ A deliverable is a Work Product that provides a description and definition for packaging other Work Products, and may
+ be delivered to an internal or external party.&nbsp; Therefore, a Deliverable aggregates other Work Products.&nbsp;
+</p>
+<p>
+ A Deliverable is used to pre-define typical or recommended content in the form or work products that would be packaged
+ for delivery.&nbsp; The actual content and packaging of the Deliverable may need to be modified for individual projects
+ based on these recommendations.&nbsp; Deliverables are used to represent an output from a process that has value,
+ material or otherwise, to a client, customer or other stakeholder.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/delivery_process.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/delivery_process.xmi
new file mode 100644
index 0000000..de9437c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/delivery_process.xmi
@@ -0,0 +1,29 @@
+<?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="_EijzoO8MEdmKSqa_gSYthg" name="delivery_process,_EhgqwO8MEdmKSqa_gSYthg" guid="_EijzoO8MEdmKSqa_gSYthg" changeDate="2005-10-27T14:10:27.282-0700">
+ <mainDescription><p>
+ A Delivery Process is a special <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific
+ project type. <!--StartFragment-->It provides a complete lifecycle model that has been detailed by sequencing Method
+ Content in breakdown structures. It describes a complete project lifecycle end-to-end and is used as a reference for
+ running projects with similar characteristics.
+</p>
+<p>
+ A&nbsp;process engineer can define alternative Delivery Processes for software development projects that differ in the
+ scale of the engagement and staffing necessary, the type of the software application to be developed, the development
+ methods and technologies to be used, etc. Although, the Delivery Process aims to cover a whole project it keeps certain
+ decision that are too project specific open.&nbsp;&nbsp;For example, the breakdown structure defines which Breakdown
+ Elements have multiple occurrences or are repeatable via its specific attributes, but does not say how many occurrences
+ and how many repeats/iterations it will have.&nbsp; These decisions have to be done by a project manager when planning
+ a concrete project, project phase, or project iterations.<!--EndFragment-->
+</p>
+<h3>
+ <a id="Software Engineering Process" name="Software Engineering Process">Example</a>
+</h3>
+<p>
+ In software engineering, the goal is to build a software product or to enhance an existing one. The Delivery Process
+ for software could be an iterative process, where the product is built incrementally over time, or it could be a
+ traditional waterfall Delivery Process in which all requirements are specified up front, followed by design,
+ implementation, and test phases.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/descriptor.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/descriptor.xmi
new file mode 100644
index 0000000..380efab
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/descriptor.xmi
@@ -0,0 +1,47 @@
+<?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="_5WJUUBUEEdqrUt4zetC1gg" name="descriptor,_5V9HEBUEEdqrUt4zetC1gg" guid="_5WJUUBUEEdqrUt4zetC1gg" changeDate="2005-11-15T10:35:38.218-0800">
+ <mainDescription><p>
+ A Descriptor represent an occurrence of one concrete Content Element (such as Task, Role, Work Product) in an Activity.
+ Descriptors provides a proxy-like representation for these Content Elements within breakdown structures. In addition to
+ just referencing Content Elements it allows overriding the Content Elements' structural relationships by defining its
+ own sets of associations.
+</p>
+<p>
+ Descriptors are a key concept for realizing the separation of Processes from Method Content. A Descriptor can be
+ characterized as a reference object for one particular Content Element, which has its own relationships and properties.
+ When a Descriptor is created, it has the same relationships as the referenced Content Element. However, users can
+ modify these relationships for the particular process situation for which the Descriptor has been created. The
+ Descriptor concept allows defining new relationships and specific process related properties. Descriptors are not
+ Content Elements and do not contain their own full descriptions. They refer or trace back to the Content Elements they
+ are based on instead.
+</p>
+<h3>
+ Example&nbsp;
+</h3>
+<p align="center">
+ <img alt="Example of Method Content referenced by Descriptor" src="resources/descriptors_uml.gif" />
+</p>
+<p align="center">
+ Example of Method Content referenced by Descriptors
+</p>
+<p>
+ <br />
+ The above illustration depicts an example using the UML 2.0 profile representation for UMA&nbsp;in which Descriptors
+ have been created for a Task, its performing Roles, as well as its input/output Work Products. The situation implied by
+ this example is that the Task "Prioritize Use Cases" is to be performed differently in a project's Inception phase than
+ in its Elaboration phase. (that is, with different emphasis on different Steps, utilizing different inputs, etc.). In
+ particular, we can observe the following:
+</p>
+<ul>
+ <li>
+ The Task in Inception has an additional assisting Role (Customer.Project Manager) and does not provide a
+ relationship to the Risk List Work Product that had been defined as an optional input in the Method Content (that
+ is, Steps of the Task that work with the Risk List will be omitted in this phase).
+ </li>
+ <li>
+ Two different types of Use Case Model Work Products are distinguished here: a Use Case Model as it is normally
+ being used during Inception, which describes use cases only briefly, versus use cases that have been detailed as it
+ is the case during the Elaboration phase.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/discipline.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/discipline.xmi
new file mode 100644
index 0000000..cb390a8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/discipline.xmi
@@ -0,0 +1,64 @@
+<?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="_zag6Q9nmEdmO6L4XMImrsA" name="discipline,3.409251897849429E-305" guid="_zag6Q9nmEdmO6L4XMImrsA" changeDate="2005-10-28T23:12:26.440-0700">
+ <mainDescription><a id="XE_DISCIPLINE__KEY_CONCEPTS" name="XE_discipline__key_concepts"></a>
+<p>
+ A Discipline is a collection of Tasks that are related to a major "area of concern" within the overall project. The
+ grouping of Tasks into Disciplines is mainly an aid to understanding the project from a traditional waterfall
+ perspective. Although it is more common to perform Tasks concurrently across several Disciplines (for example, certain
+ requirements Tasks are performed in close coordination with analysis and design Tasks), separating these Tasks into
+ distinct Disciplines is simply an effective way to organize content, which makes comprehension easier.
+</p>
+<p>
+ Another reason that several Tasks are all categorized by the same Discipline is that they all represent a part in
+ achieving a higher goal or performing work that is all related to each other.&nbsp; Every Discipline defines standard
+ ways of doing the work it categorizes.&nbsp; Such standard ways are expressed by so-called reference workflows
+ described with <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>s defining how the Tasks categorized by the Discipline 'work
+ together' in the most generic way.&nbsp; These reference workflows are often used for educating and teaching
+ practitioners.
+</p>
+<p>
+ Like other workflows, a Discipline's reference workflow is a semi-ordered sequence of activities presented as either a
+ breakdown structure or an activity diagram performed to achieve a particular result. The "semi-ordered" nature of
+ Discipline workflows emphasizes that the Discipline workflows cannot present the real nuances of scheduling "real
+ work", for they cannot depict the optionality of activities or iterative nature of real projects. Yet they still have
+ value as a way for us to understand the process by breaking it into smaller areas of concern.
+</p>
+<h4>
+ Example: The role of Disciplines in Software Engineering
+</h4>
+<p>
+ In Software Development, each Discipline has associated with it one or more 'models', which are in turn composed of
+ associated Work Products. Some fundamental disciplines identified in Software are:
+</p>
+<ul>
+ <li>
+ Business Modeling
+ </li>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Analysis and Design
+ </li>
+ <li>
+ Implementation
+ </li>
+ <li>
+ Test
+ </li>
+ <li>
+ Deployment
+ </li>
+ <li>
+ Configuration and Change Management
+ </li>
+ <li>
+ Project Management
+ </li>
+ <li>
+ Environment
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/domain.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/domain.xmi
new file mode 100644
index 0000000..e7a057d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/domain.xmi
@@ -0,0 +1,11 @@
+<?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="_DiKm8BUGEdqrUt4zetC1gg" name="domain,_Dh4TEBUGEdqrUt4zetC1gg" guid="_DiKm8BUGEdqrUt4zetC1gg" changeDate="2005-09-22T14:32:59.052-0700">
+ <mainDescription><p>
+ A Domain is a refineable hierarchy designed to classify related Work Products. In other words, Domains are organized
+ into trees where individual Work Products appear as the leaves. Conceptually, each Domain is a grouping of related Work
+ Products that tend to be used for a similar purpose.
+</p>
+<p>
+ A&nbsp;single Work Product can be categorized in only one Domain.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/example.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/example.xmi
new file mode 100644
index 0000000..379f606
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/example.xmi
@@ -0,0 +1,12 @@
+<?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="_dCTLkBUBEdqrUt4zetC1gg" name="example,_dCG-UBUBEdqrUt4zetC1gg" guid="_dCTLkBUBEdqrUt4zetC1gg" changeDate="2005-09-07T03:57:41.587-0700">
+ <mainDescription><p>
+ An Example represents a typical, partially completed, sample instance of one or more Content Elements. Examples are
+ most commonly provided for Work Products. A Work Product Example is a good supplement to its prescriptive and
+ descriptive process Guidance.
+</p>
+<p>
+ Examples should be associated with specific Work Products to give their producer a view of how it should look like when
+ it is done.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/guideline.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/guideline.xmi
new file mode 100644
index 0000000..de190a9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/guideline.xmi
@@ -0,0 +1,31 @@
+<?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="_IBPFMBUEEdqrUt4zetC1gg" name="guideline,_IAwkEBUEEdqrUt4zetC1gg" guid="_IBPFMBUEEdqrUt4zetC1gg" changeDate="2005-10-30T17:23:28.397-0800">
+ <mainDescription><p>
+ A Guideline usually focuses on how to perform a particular Task or grouping of Tasks (for example, grouped together as
+ activities) or provides additional detail, rules, and recommendations on Work Products and their properties. Guidelines
+ can include details about a variety of topics including:
+</p>
+<ul>
+ <li>
+ Practices and different approaches for doing work,
+ </li>
+ <li>
+ How to handle particular kinds of Content Elements,
+ </li>
+ <li>
+ Information on different subtypes and variants of Content Elements and how they evolve throughout a lifecycle,
+ </li>
+ <li>
+ Discussions on skills the performing Roles should acquire,
+ </li>
+ <li>
+ Measurements of progress and maturity, etc.
+ </li>
+</ul>
+<p>
+ Work products typically have associated guidelines which present information on how to develop, evaluate and use the
+ Work Products . Guidelines contain much of the substance of a method and provide assistance in a number of contexts:
+ they help you decide what to do, they help doing it, they help assess the quality of the work, and they help understand
+ how a particular Work Product relates to the rest of the process.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/introduction_to_uma.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/introduction_to_uma.xmi
new file mode 100644
index 0000000..ee0edb8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/introduction_to_uma.xmi
@@ -0,0 +1,121 @@
+<?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>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/library.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/library.xmi
new file mode 100644
index 0000000..1b7f65c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/library.xmi
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_m83acBUFEdqrUt4zetC1gg" name="library,_m8lGkBUFEdqrUt4zetC1gg" guid="_m83acBUFEdqrUt4zetC1gg" changeDate="2005-09-07T03:52:29.278-0700">
+ <mainDescription><p align="center">
+ <font face="Arial, Helvetica, sans-serif"><img height="631" src="resources/packaging_picl.gif" width="905" /></font>
+</p>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif">Illustration of a Library with a Method Configuration highlighted in
+ Red</font>
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_library.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_library.xmi
new file mode 100644
index 0000000..04deb46
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_library.xmi
@@ -0,0 +1,10 @@
+<?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="_m83acBUFEdqrUt4zetC1gg" guid="_m83acBUFEdqrUt4zetC1gg" changeDate="2005-10-28T07:34:36.302-0700">
+ <mainDescription>Method Libraries represent physical storage of&nbsp;all Content and Process Elements as well as <a class="elementLink"
+href="./../../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>s. A Method Library defines a closed universe for all elements in
+it,&nbsp;since &nbsp;library elements cannot refer to other libraries.&nbsp; All user-defined extensions to method content
+and processes have to be done with <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugins</a>&nbsp;within the same physical library.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_package.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_package.xmi
new file mode 100644
index 0000000..1655135
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_package.xmi
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_iegZwBncEdqYreeU3jqaDQ" name="method_package,_idpeIBncEdqYreeU3jqaDQ" guid="_iegZwBncEdqYreeU3jqaDQ" changeDate="2005-09-07T01:34:01.431-0700">
+ <mainDescription><p>
+ <font face="Arial, Helvetica, sans-serif">A Method Package package defines how the method elements can be physically
+ organized in package hierarchies. It is an abstract class for packaging Method Elements. All Method Elements shall be
+ located in exactly one of Method Package’s concrete specializations (e.g. Content Package). Method Package defines
+ common properties for all of its specializations.</font>
+</p>
+<p>
+ <font face="Arial, Helvetica, sans-serif">Elements are organized in Method Packages to structure large scale of method
+ content and processes as well as to define a mechanism for reuse. Method Elements from one package can reuse element
+ from other packages by defining a reusedPackages link.</font>
+</p>
+<p>
+ <font face="Arial, Helvetica, sans-serif">For example, a work product defined in one package can be used as an input
+ for Tasks defined in other packages. By reusing it from one common place (i.e. the package in which it has been
+ defined) ensures that no redundant definitions of the same elements are required. Also maintenance of method content is
+ greatly improved as changes can be performed in only one place.</font>
+</p>
+<p>
+ <font face="Arial, Helvetica, sans-serif"><br />
+ Note, that other packages will introduce more specializations of Method Package, e.g. Process Package and Process
+ Component</font>.
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_plugin.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_plugin.xmi
new file mode 100644
index 0000000..6e52da4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/method_plugin.xmi
@@ -0,0 +1,18 @@
+<?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="_0LCr8BUFEdqrUt4zetC1gg" guid="_0LCr8BUFEdqrUt4zetC1gg" changeDate="2006-04-13T14:26:20.262-0700">
+ <mainDescription><p>
+ Method Plugin conceptually represents a unit for configuration, modularization, extension, packaging, and deployment of
+ method content and processes.&nbsp; A Process Engineer shall design&nbsp;Plugins and allocate content to these Plugins
+ with requirements for extensibility, modularity, reuse, and maintainability in mind.
+</p>
+<p>
+ Plug-ins can directly contribute new content, replace existing content, or to cross-reference to any Content Element or
+ Process within another Plug-in that it extends.&nbsp; Similar to UML 2.0's 'package merge' mechanism transformation
+ interpretations, interpreting these Method Plug-in mechanisms results into new extended Method Content and
+ Processes.&nbsp; For example, a might contain additional steps for Tasks, new Work Products extensions to existing
+ Roles to be responsible for the new Work Products, additional relationships of existing Content Elements to new
+ specific Guidance elements (such as Guidelines, White Papers, Checklists), additional Activities for a Delivery
+ Process, new Capability Patterns, etc.&nbsp; A Method Plug-in defines these extension using Variability Element
+ relationships and interpretation of these leads to new Method Content and Processes.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/outcome.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/outcome.xmi
new file mode 100644
index 0000000..81441e7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/outcome.xmi
@@ -0,0 +1,10 @@
+<?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="_pRmgYBUJEdqrUt4zetC1gg" name="outcome,_pROF4BUJEdqrUt4zetC1gg" guid="_pRmgYBUJEdqrUt4zetC1gg" changeDate="2005-10-26T18:17:53.880-0700">
+ <mainDescription><p>
+ An Outcome describes intangible Work Products that are a result or state, such as an installed server or optimized
+ network.&nbsp;As the occurrence of an Outcome is often informally documented (for example, through minutes or memos),
+ Outcomes may also be used to describe Work Products that are not formally defined.&nbsp;A key differentiator for
+ Outcomes against Artifacts is that Outcomes are not candidates for harvesting as reusable assets.&nbsp; Outcomes can
+ not have associated templates or examples and are not possible to reuse as assets on other projects.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/phase.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/phase.xmi
new file mode 100644
index 0000000..03e57de
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/phase.xmi
@@ -0,0 +1,36 @@
+<?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" epf:version="1.0.0" xmi:id="-bhzuf6RMHP3d-AHkoKDg7g" name="phase,__7xOEC7aEdqHMdmRzC0-2g" guid="-bhzuf6RMHP3d-AHkoKDg7g" changeDate="2007-02-27T09:17:14.810-0800" version="1.0.0">
+ <mainDescription><h3>
+ What is a Phase?
+</h3>
+<p>
+ While the entire purpose of a project is to produce a product, the specific goals of the team will vary substantially
+ throughout the project. In the beginning, there usually is considerable latitude in the requirements for the product.
+ It may not be clear whether the project is feasible or even if it is likely to be profitable. At that time, it is
+ critical to bring an answer to these questions, and of little to no value to start developing the product in
+ earnest.&nbsp;Towards the end of the project, the product itself is usually complete, and issues of quality, delivery,
+ and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work
+ products will have new content.
+</p>
+<p>
+ To coordinate the team’s efforts in a manner that takes these fundamental observations into account, the project
+ lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, its own iteration style
+ and customized <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">tasks</a> and <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">work products</a> to address the unique needs of the project at that point in time.
+</p>
+<p>
+ We recommend&nbsp;dividing the project lifecycle into&nbsp;four phases: Inception, Elaboration, Construction and
+ Transition.
+</p>
+<h3>
+ Iteration and Phases
+</h3>
+<p>
+ Each phase is divided into iterations. An iteration is a complete development loop resulting in a build (internal or
+ external) of an executable system, usually a subset of the final product under development, which grows incrementally
+ from iteration to iteration to become the final product.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/plugin.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/plugin.xmi
new file mode 100644
index 0000000..a0e21be
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/plugin.xmi
@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_0LCr8BUFEdqrUt4zetC1gg" name="method_plugin,_0KeEMBUFEdqrUt4zetC1gg" guid="_0LCr8BUFEdqrUt4zetC1gg" changeDate="2005-09-07T02:03:28.352-0700">
+ <mainDescription><p>
+ A Method Plugin is a Method Element that represents a physical container for Method Packages.&nbsp; It defines a
+ granularity level for the modularization and organization of method content and processes.&nbsp; A Method Plugin can
+ extend many other Method Plugins and it can be extended by many Method Plugins.&nbsp; It can also be used stand-alone,
+ i.e. with no Extension relationship to other plug-ins.
+</p>
+<p>
+ Method Plugin conceptually represents a unit for configuration, modularization, extension, packaging, and deployment of
+ method content and processes.&nbsp; A Process Engineer must design his Plugins and allocate his content to these
+ Plugins with requirements for extensibility, modularity, reuse, and maintainability in mind.&nbsp;<br />
+</p>
+<p>
+ Another use of Plugins is that they allow factoring out context or technology specific content into separate Method
+ Plugins.For example, his factoring allows one to alternatively choose one Method Plugin over another depending on the
+ technology used for the project (e.g. J2EE vs. .NET)
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/practice.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/practice.xmi
new file mode 100644
index 0000000..5377fbb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/practice.xmi
@@ -0,0 +1,19 @@
+<?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="_s0dcwBUBEdqrUt4zetC1gg" name="practice,_szl6EBUBEdqrUt4zetC1gg" guid="_s0dcwBUBEdqrUt4zetC1gg" changeDate="2005-10-30T17:24:23.678-0800">
+ <mainDescription><p>
+ Practices are orthogonal to methods and processes. They often summarize aspects that impact many different parts of a
+ method or specific processes.
+</p>
+In Software Engineering, examples for practices include:
+<ul>
+ <li>
+ Manage Risks,
+ </li>
+ <li>
+ Continuously verify quality,
+ </li>
+ <li>
+ Architecture-centric and component-based development, etc.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/process_contribution.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/process_contribution.xmi
new file mode 100644
index 0000000..31cf786
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/process_contribution.xmi
@@ -0,0 +1,19 @@
+<?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="-x11qt8TVnuIKeMC69UP1TQ" name="process_contribution,_NYASQBtqEdqSLrJ4Ij2LVA" guid="-x11qt8TVnuIKeMC69UP1TQ" changeDate="2005-11-15T11:34:50.224-0800">
+ <mainDescription><p>
+ A Process Contribution is a special Process that externally defines additions and changes to an existing Process
+ without directly modifying the existing Process. It achieves this by describing these additions and changes in a
+ separate Process structure. This structures' elements relate to the other Process's elements using "Contributes" and
+ "Replace" specializations. Process Contributions are normally packaged with Method Plug-ins that extend existing Method
+ Plug-in with new capabilities.
+</p>
+<p>
+ A Process Contribution is a kind of "process plug-in" that plugs additional breakdown structures into an existing
+ Process and therefore updates it afterwards with new or changed capabilities. For example, the J2EE Plug-in plugs into
+ the technology independent main Plug-in. It may update the generic Delivery Processes defined in that Plug-in with J2EE
+ specific Activities. A respective ".NET Plug-in" could define similar updates relevant for that technology platform. A
+ process practitioner could then apply the chosen Plug-in, thereby generating a technology specific Process, but keeping
+ maintenance of his/her Processes minimal, because technology specific parts are kept separate and will be applied on
+ demand only.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/process_package.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/process_package.xmi
new file mode 100644
index 0000000..8de9fcb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/process_package.xmi
@@ -0,0 +1,2 @@
+<?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="_MUGiMBneEdqYreeU3jqaDQ" name="process_package,_MT6U8BneEdqYreeU3jqaDQ" guid="_MUGiMBneEdqYreeU3jqaDQ" changeDate="2005-09-22T14:34:16.793-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/release.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/release.xmi
new file mode 100644
index 0000000..c5175ed
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/release.xmi
@@ -0,0 +1,26 @@
+<?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="-dsgUC_uXte9wj6nt8DLHtw" name="release,_L5BIkC7uEdqHMdmRzC0-2g" guid="-dsgUC_uXte9wj6nt8DLHtw" changeDate="2005-09-26T17:32:36.683-0700">
+ <mainDescription><p>
+ A release can be internal or external. An internal release is used only by the development organization, as part of a
+ milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to users. A
+ release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured
+ only from an engineering perspective. Releases act as a forcing function that drives the development team to get
+ closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome.
+</p>
+<p>
+ <a class="elementLinkWithType" href="./../../../base_concepts/guidances/concepts/iteration,3.379871268737602E-305.html"
+ guid="3.379871268737602E-305">Concept: Iteration</a>s and releases allow a better usage over time of the various
+ specialties in the team: designers, testers, writers, and so forth. Regular releases let you break down the integration
+ and test issues and spread them across the development cycle. These issues have often been the downfall of large
+ projects because all problems were discovered at once during the single massive integration step, which occurred very
+ late in the cycle, and where a single problem halts the whole team.
+</p>
+<p>
+ With each Release,&nbsp;many <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">Concept: Work Product</a>s&nbsp;are updated. It is said that this is a bit like "growing"
+ software. Instead of developing Work Products one after another, in a pipeline fashion, they are evolving across the
+ cycle, although at different rates.
+</p>
+<!--EndFragment--><!--EndFragment--><!--EndFragment--><!--EndFragment--></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/report.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/report.xmi
new file mode 100644
index 0000000..3986b7b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/report.xmi
@@ -0,0 +1,12 @@
+<?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="_x2-UYBUBEdqrUt4zetC1gg" name="report,_x2sAgBUBEdqrUt4zetC1gg" guid="_x2-UYBUBEdqrUt4zetC1gg" changeDate="2005-10-30T17:28:20.686-0800">
+ <mainDescription><p>
+ An example for a report would be a use case model survey, which is generated by extracting diagram information from a
+ graphical model and textual information from documents and combines these two types of information into a report.
+</p>
+<p>
+ Unlike regular Work Products, reports are not subject to version control. However they may be baselined to provide a
+ historic audit trail of the report over time. In some cases, the development tools enable the report to be reproduced
+ at any time by rerunning the report against the Work product's History.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl1.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl1.gif
new file mode 100644
index 0000000..ed7a877
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl2.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl2.gif
new file mode 100644
index 0000000..0204883
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl3.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl3.gif
new file mode 100644
index 0000000..adc6baa
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl4.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl4.gif
new file mode 100644
index 0000000..15ed91e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/co_lfcl4.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/descriptors_uml.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/descriptors_uml.gif
new file mode 100644
index 0000000..29dd96e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/descriptors_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/guidance_uml.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/guidance_uml.gif
new file mode 100644
index 0000000..21d2b32
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/guidance_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/im_prar6.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/im_prar6.gif
new file mode 100644
index 0000000..122011d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/im_prar6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/infoset.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/infoset.gif
new file mode 100644
index 0000000..ee1442f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/infoset.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/iterative.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/iterative.gif
new file mode 100644
index 0000000..91f174f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/iterative.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/method_uml.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/method_uml.gif
new file mode 100644
index 0000000..a254a57
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/method_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/overview.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/overview.gif
new file mode 100644
index 0000000..b898efd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/overview.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/packaging_picl.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/packaging_picl.gif
new file mode 100644
index 0000000..376133d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/packaging_picl.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/packaging_uml.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/packaging_uml.gif
new file mode 100644
index 0000000..fa91c2d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/packaging_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma-evo.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma-evo.gif
new file mode 100644
index 0000000..350cc98
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma-evo.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_hump.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_hump.gif
new file mode 100644
index 0000000..fa0ad27
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_hump.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_hump.jpg b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_hump.jpg
new file mode 100644
index 0000000..7f4596e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_hump.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_m_vs_p.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_m_vs_p.gif
new file mode 100644
index 0000000..28cf1c3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_m_vs_p.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_processElts_uml.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_processElts_uml.gif
new file mode 100644
index 0000000..abb4fae
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/uma_processElts_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/waterfall.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/waterfall.gif
new file mode 100644
index 0000000..495b64b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/waterfall.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/wf_req.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/wf_req.gif
new file mode 100644
index 0000000..d48bef3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/resources/wf_req.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/reusable_asset.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/reusable_asset.xmi
new file mode 100644
index 0000000..5bace2c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/reusable_asset.xmi
@@ -0,0 +1,8 @@
+<?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="_21rDABUBEdqrUt4zetC1gg" name="reusable_asset,_20bs4BUBEdqrUt4zetC1gg" guid="_21rDABUBEdqrUt4zetC1gg" changeDate="2005-10-07T18:47:08.091-0700">
+ <mainDescription><p>
+ &nbsp;A Reusable Asset typically includes source code, templates, patterns, but may also include architectural
+ frameworks, domain models, and so on.&nbsp; A Reusable Asset has usage rules which are the instructions describing how
+ the asset should be used.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/roadmap.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/roadmap.xmi
new file mode 100644
index 0000000..07e39f1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/roadmap.xmi
@@ -0,0 +1,14 @@
+<?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="_JCivABnXEdqYreeU3jqaDQ" name="roadmap,_JCQbIBnXEdqYreeU3jqaDQ" guid="_JCivABnXEdqYreeU3jqaDQ" changeDate="2005-10-07T18:47:16.384-0700">
+ <mainDescription><p>
+ An instance of a Roadmap represents important documentation for the Activity or Process it is related to. Often a
+ complex Activity such as a Process can be much easier understood by providing a walkthrough with a linear thread of a
+ typical instantiation of this Activity.
+</p>
+<p>
+ In addition to making the process practitioner understand how work in the process is being performed, a Roadmap
+ provides additional information about how Activities and Tasks relate to each other over time. Roadmaps are also used
+ to show how specific aspects are distributed over a whole process providing a kind of filter on the Process for this
+ information.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/role.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/role.xmi
new file mode 100644
index 0000000..82806f6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/role.xmi
@@ -0,0 +1,21 @@
+<?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="_zaqEMtnmEdmO6L4XMImrsA" name="role,1.1609745730665898E-304" guid="_zaqEMtnmEdmO6L4XMImrsA" changeDate="2006-04-13T14:30:25.906-0700">
+ <mainDescription><a id="Top" name="Top"></a><a id="XE_key_concepts__role" name="XE_key_concepts__role"></a><a id="XE_role__key_concepts"
+name="XE_role__key_concepts"></a>
+<p>
+ A Role is a Method Content element that defines a set of related skills, competencies, and responsibilities. Roles are
+ used by Tasks to specify who performs them as well as define a set of Work Products they are responsible for.
+</p>
+<p class="node" align="left">
+ Roles are typically realized by an individual, or a set of individuals, working together as a team. A project team
+ member typically fulfills many different roles. Note that <b>Roles are not individuals nor are they necessarily
+ equivalent to job titles;</b> instead, they describe how individuals should behave in the project and the
+ responsibilities of an individual. Individual members of the organization will wear different hats, or perform
+ different Roles. The mapping from individual to Role is performed by the project manager when planning and staffing the
+ project.
+</p>
+<p class="node" align="left">
+ While most roles are realized by people within the organization, people outside of the development organization play an
+ important role: for example, that of the stakeholder of the project or product being developed.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/role_set.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/role_set.xmi
new file mode 100644
index 0000000..5653cd4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/role_set.xmi
@@ -0,0 +1,24 @@
+<?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="_u4APkBUGEdqrUt4zetC1gg" name="role_set,_u3t7sBUGEdqrUt4zetC1gg" guid="_u4APkBUGEdqrUt4zetC1gg" changeDate="2005-10-28T23:15:33.184-0700">
+ <mainDescription><p>
+ Role Sets are used to group Roles together that have certain commonalities.
+</p>
+<p>
+ For example, in Software Engineering, the "Analysts" Role Set could group the
+</p>
+<ul>
+ <li>
+ Business Process Analyst
+ </li>
+ <li>
+ System Analyst
+ </li>
+ <li>
+ Requirements Specifier
+ </li>
+</ul>
+<p>
+ All of these Roles&nbsp;work with similar techniques and have overlapping skills, but are required to be
+ distinct&nbsp;by the&nbsp;software engineering method.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/supporting_material.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/supporting_material.xmi
new file mode 100644
index 0000000..7e0e02c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/supporting_material.xmi
@@ -0,0 +1,2 @@
+<?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="_80pi4BUBEdqrUt4zetC1gg" name="supporting_material,_80XPABUBEdqrUt4zetC1gg" guid="_80pi4BUBEdqrUt4zetC1gg" changeDate="2005-10-30T17:28:33.114-0800"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/task.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/task.xmi
new file mode 100644
index 0000000..40813dc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/task.xmi
@@ -0,0 +1,130 @@
+<?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="_zaqENNnmEdmO6L4XMImrsA" name="task,7.624729048911575E-305" guid="_zaqENNnmEdmO6L4XMImrsA" changeDate="2006-04-27T15:39:25.282-0700">
+ <mainDescription><a id="XE_ACTIVITY__KEY_CONCEPTS" name="XE_activity__key_concepts"></a>
+<h3>
+ Definition
+</h3>
+<p>
+ A Task describes a unit of work. Every Task is performed by specific Roles. The granularity of a Task is generally a
+ few hours to a few days. It usually affects one or only a small number of Work Products. Tasks are not necessarily used
+ as&nbsp;a basis for planning and tracking progress - they are often too fine-grained for that purpose; Activity
+ groupings of Tasks are often the better units for planning and tracking.
+</p>
+<p>
+ A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models,
+ classes, or&nbsp;plans. Within a Task, each performing Role achieves a well defined goal. A Task provides complete
+ step-by-step explanations of doing all the work required to achieve this goal. This description is complete,
+ independent of when in a process lifecycle the work would actually be done. Therefore, it does not describe when you do
+ what work at what point of time, but describes all the work that gets done throughout the development lifecycle that
+ contributes to the achievement of the Tasks' goal.
+</p>
+<p>
+ When a Task is being applied in a Process, a reference object defined as Task Descriptor provides information, which
+ includes what elements of the Task will actually be performed at that point in time. This assumes that a Task will
+ usually be performed in the Process over and over again, but each time with a slightly different emphasis on different
+ steps or aspects of the Task description&nbsp;as well as perhaps different or additional performing roles or different
+ input/output (also refer to <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html"
+ guid="_94_eoO8LEdmKSqa_gSYthg">Key Capabilities of the Unified Method Architecture (UMA)</a> for the difference between
+ Method Content and Process).
+</p>
+<h3>
+ Steps
+</h3>
+<p>
+ Tasks can be broken down into sections of Steps. A Step describes a meaningful and consistent part of the overall work
+ described for a Task. Steps fall into three main categories:
+</p>
+<ul>
+ <li>
+ <b>Thinking</b> Steps: where the individual performing the Role understands the nature of the Task, gathers and
+ examines the input Work Products, and formulates the result.
+ </li>
+ <li>
+ <b>Performing</b> Steps: where the individual performing the Role creates or updates some Work Products.
+ </li>
+ <li>
+ <b>Reviewing</b> Steps: where the individual performing the Role inspects the results against some criteria.
+ </li>
+</ul>
+<p>
+ Not all Steps are necessarily performed each time a Task is invoked, so they can be expressed in the form of alternate
+ flows (similar to Use Cases).
+</p>
+<h3>
+ Examples
+</h3>
+<h4>
+ A Typical Task
+</h4>
+<p>
+ A typical Task&nbsp;to "Develop Use-Case Model" would describe all the work that needs to be done to develop a complete
+ use-case model. This would consist of the following:
+</p>
+<ul>
+ <li>
+ The identification and naming of use cases and actors
+ </li>
+ <li>
+ The writing of a brief description
+ </li>
+ <li>
+ The modeling of use cases and their relationships in diagrams
+ </li>
+ <li>
+ The detailed description of a basic flow
+ </li>
+ <li>
+ The detailed description of alternative flows
+ </li>
+ <li>
+ Performing of walkthroughs, workshops and reviews, etc.
+ </li>
+</ul>
+<p>
+ All of these parts contribute to the development goal of developing the use case model, but the parts will be performed
+ at different points in time in a Process. Identification, naming, and brief descriptions would be performed
+ <strong>early</strong> in a typical development process versus the writing of detailed alternative flows which would be
+ performed much <strong>later</strong>. All these parts or Steps within the same Task define the "method" of developing
+ a use-case model. Applying such a method in a lifecycle is defining which Steps are done when going from one iteration
+ to the next.
+</p>
+<h4>
+ A Task and its Steps
+</h4>
+<p class="example">
+ A&nbsp;typical Task to "Find Use Cases and Actors"&nbsp;would be decomposed into the following Steps:
+</p>
+<blockquote>
+ <blockquote>
+ <ol>
+ <li>
+ Find actors
+ </li>
+ <li>
+ Find use cases
+ </li>
+ <li>
+ Describe how actors interact with use cases
+ </li>
+ <li>
+ Package use cases and actors
+ </li>
+ <li>
+ Present the use-case model in use-case diagrams
+ </li>
+ <li>
+ Develop a survey of the use-case model
+ </li>
+ <li>
+ Evaluate your results
+ </li>
+ </ol>
+ </blockquote>
+</blockquote>
+<p class="example">
+ The finding part [Steps 1 to 3] requires some thinking; the performing part [Steps 4 to 6] involves capturing the
+ result in the use-case model; the reviewing part [Step 7] is where the individual performing the Role evaluates the
+ result to assess completeness, robustness, intelligibility, or other qualities.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/team_profile.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/team_profile.xmi
new file mode 100644
index 0000000..1b32406
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/team_profile.xmi
@@ -0,0 +1,18 @@
+<?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="-J7jcN9p3FRyhuwV5Hq42Kw" name="team_profile,_dRKRMBtHEdqSLrJ4Ij2LVA" guid="-J7jcN9p3FRyhuwV5Hq42Kw" changeDate="2005-11-07T14:47:07.040-0800">
+ <mainDescription><p>
+ Work assignments and Work Product responsibilities can be different from Activity to Activity in a development project.
+ Different phases require different staffing profiles, that is, different skills and resources doing different types of
+ work. Therefore, a Process needs to define these profiles in a flexible manner. Whereas Core Method Content defines
+ standard responsibilities and assignments, a Process expressed in breakdown structures needs to be able to refine and
+ redefine these throughout its definition.
+</p>
+<p>
+ Role Descriptors, Composite Roles, as well as Team Profiles provide the data structure necessary to achieve this
+ flexibility and to provide&nbsp;Process users with the capability to define different teams and Role relationships for
+ every Activity (including Activities on any nesting level as well as Iterations or Phases). Hence, in addition to the
+ work breakdown and Work Product breakdown structures, Team Profiles are used to define a third type of breakdown
+ structure: The Team Breakdown Structure. It is created as an Activity specific hierarchy of Team Profiles comprising of
+ Role Descriptors and Composite Roles. These structures can be presented as Org-Charts.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/template.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/template.xmi
new file mode 100644
index 0000000..4605f7b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/template.xmi
@@ -0,0 +1,27 @@
+<?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="_G_m7ABUCEdqrUt4zetC1gg" name="template,_G_UnIBUCEdqrUt4zetC1gg" guid="_G_m7ABUCEdqrUt4zetC1gg" changeDate="2006-04-13T14:38:58.693-0700">
+ <mainDescription><p>
+ Templates are "models," or prototypes, of Work Products. Within a Work Product description, there usually are one or
+ more templates that can be used to create the corresponding Work Product. Templates are linked to the tool that is to
+ be used to create the Work Product. Prior to project start, organizations may want to customize the templates by adding
+ the company logo, some project identification, or information specific to the type of project.
+</p>
+<h3>
+ Example:
+</h3>
+<ul>
+ <li>
+ Word processor tools&nbsp;templates can be used for Work Products that are documents, and for some reports.
+ </li>
+ <li>
+ Automated report generation tools templates extract information from tools such as visual modeling tools,
+ requirements management tools or testing tools.
+ </li>
+ <li>
+ HTML tool templates for the various elements of the process.
+ </li>
+ <li>
+ Project planning tool&nbsp;template for the project plan.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/term_definition.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/term_definition.xmi
new file mode 100644
index 0000000..02e763f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/term_definition.xmi
@@ -0,0 +1,2 @@
+<?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="_Z7wmgBUDEdqrUt4zetC1gg" name="term_definition,_Z45fwBUDEdqrUt4zetC1gg" guid="_Z7wmgBUDEdqrUt4zetC1gg" changeDate="2005-09-07T02:52:32.005-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/tool.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/tool.xmi
new file mode 100644
index 0000000..1aebb22
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/tool.xmi
@@ -0,0 +1,13 @@
+<?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="_66cGsBUGEdqrUt4zetC1gg" name="tool,_66Jy0BUGEdqrUt4zetC1gg" guid="_66cGsBUGEdqrUt4zetC1gg" changeDate="2005-10-27T12:38:43.264-0700">
+ <mainDescription><p>
+ <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/tool_mentor,1.0762105093945226E-304.html"
+ guid="1.0762105093945226E-304">Tool Mentors</a>&nbsp;are a guidance type that define how work described with <a
+ class="elementLinkWithUserText" href="./../../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">Tasks</a>&nbsp;or <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html"
+ guid="3.132140065969088E-305">Activities</a>&nbsp;is to be performed using a specific tool.&nbsp; Every Tool Mentor
+ shall therefore be categorized by exactly one Tool category.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/tool_mentor.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/tool_mentor.xmi
new file mode 100644
index 0000000..66b0a40
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/tool_mentor.xmi
@@ -0,0 +1,13 @@
+<?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="_zaz1MtnmEdmO6L4XMImrsA" name="tool_mentor,1.0762105093945226E-304" guid="_zaz1MtnmEdmO6L4XMImrsA" changeDate="2006-04-13T14:41:01.910-0700">
+ <mainDescription><a id="Top" name="Top"></a><a id="XE_key_concepts__tool_mentor" name="XE_key_concepts__tool_mentor"></a><a
+id="XE_TOOL_MENTOR__KEY_CONCEPTS" name="XE_tool_mentor__key_concepts"></a>
+<p>
+ Tasks, Steps, and associated guidelines provide general guidance to the practitioner. To go one step further, Tool
+ Mentors are an additional means of providing guidance by showing how to achieve certain goals with a specific software
+ tool. Tool mentors link Tasks with tools such as visual modeling tools, requirements management tools, configuration
+ management tools, change requests/tracking tools and automated testing tools. Tool Mentors almost completely
+ encapsulate the dependencies of the content on the tool set, keeping the tasks free from tool details. An organization
+ can extend the concept of Tool Mentor to provide guidance for other tools.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/uma_diagrams.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/uma_diagrams.xmi
new file mode 100644
index 0000000..e78fbcf
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/uma_diagrams.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_H7U1ABUFEdqrUt4zetC1gg" name="uma_diagrams,_H7InwBUFEdqrUt4zetC1gg" guid="_H7U1ABUFEdqrUt4zetC1gg" changeDate="2005-08-24T18:11:23.031-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/view.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/view.xmi
new file mode 100644
index 0000000..44b4381
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/view.xmi
@@ -0,0 +1,16 @@
+<?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="_uMcmkBUFEdqrUt4zetC1gg" name="view,_uMKSsBUFEdqrUt4zetC1gg" guid="_uMcmkBUFEdqrUt4zetC1gg" changeDate="2005-10-26T23:55:52.721-0700">
+ <mainDescription><p>
+ Views are tabs that appear at the top of the tree browser within a published site. They identify pre-arranged
+ structured collections of content designed to facilitate its browsing by process users and practitioners.
+</p>
+<p>
+ A View is specified by defining a nested structure of <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/custom_category,_xuO10BUGEdqrUt4zetC1gg.html"
+ guid="_xuO10BUGEdqrUt4zetC1gg">Custom Categories</a> containing references to the&nbsp;Content Elements one desires to
+ publish within the view. Structurally, Views represent a selection of Custom Categories for one specific&nbsp;<a
+ class="elementLink" href="./../../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+ guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>. In other words, every configuration defines its views by
+ referring to a set of Custom Categories.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/white_paper.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/white_paper.xmi
new file mode 100644
index 0000000..61779cd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/white_paper.xmi
@@ -0,0 +1,7 @@
+<?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="_iePk8BUDEdqrUt4zetC1gg" name="white_paper,_id9REBUDEdqrUt4zetC1gg" guid="_iePk8BUDEdqrUt4zetC1gg" changeDate="2005-09-07T03:45:10.597-0700">
+ <mainDescription><p>
+ A whitepaper is a&nbsp;Guidance Type for externally&nbsp;published papers&nbsp;that can be read and understood in
+ isolation of other Content Elements and Guidance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/work_product.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/work_product.xmi
new file mode 100644
index 0000000..4bb5684
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/work_product.xmi
@@ -0,0 +1,47 @@
+<?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="_zaz1MNnmEdmO6L4XMImrsA" name="work_product,4.804531471620803E-306" guid="_zaz1MNnmEdmO6L4XMImrsA" changeDate="2006-04-13T15:39:29.597-0700">
+ <mainDescription><a id="XE_ARTIFACT__KEY_CONCEPTS" name="XE_artifact__key_concepts"></a>
+<h3>
+ Work Product
+</h3>
+<p>
+ A Work Product is a general abstraction that represents something resulting from the process.&nbsp; Work Products
+ include:
+</p>
+<ul>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/artifact,_fdRfkBUJEdqrUt4zetC1gg.html"
+ guid="_fdRfkBUJEdqrUt4zetC1gg">Artifact</a>
+ </li>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/deliverable,_lBgkMBUJEdqrUt4zetC1gg.html"
+ guid="_lBgkMBUJEdqrUt4zetC1gg">Deliverable</a>
+ </li>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/outcome,_pROF4BUJEdqrUt4zetC1gg.html"
+ guid="_pROF4BUJEdqrUt4zetC1gg">Outcome</a>
+ </li>
+</ul>
+<p>
+ Tasks have input and output Work Products. Roles use Work Products to perform Tasks, and produce other Work Products in
+ the course of performing Tasks. Work Products are the responsibility of a single Role, making responsibility easy to
+ identify and understand, and promoting the idea that every piece of information produced in the process requires the
+ appropriate set of skills. Even though one Role may "own" the Work Product, other Roles will use the Work Product,
+ perhaps even updating it if the Role has been given permission to do so.
+</p>
+<p align="center">
+ <map id="FPMap1" name="FPMap1">
+ </map><img height="569"
+ alt="Popular Work Products in Software Development, and the approximate dependency relationships between them."
+ src="resources/overview.gif" width="536" usemap="#FPMap1" border="0" />
+</p>
+<p class="picturetext" align="center">
+ Popular Work Products in Software Development, and the approximate dependency relationships between them.
+</p>
+<p>
+ Note that "<b>Work Product</b> " is the term used to describe what other processes denote using terms such as
+ <b>Artifact</b>, <b>work unit</b>, and so on. In UMA, <b>Deliverables</b> are only considered to be the subset of all
+ Work Products that will end up being delivered into the hands of the customers and users, usually as part of a formal
+ or contractually agreed hand-over.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/work_product_kind.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/work_product_kind.xmi
new file mode 100644
index 0000000..b3665aa
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/concepts/work_product_kind.xmi
@@ -0,0 +1,31 @@
+<?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="_VRz4gBUGEdqrUt4zetC1gg" name="work_product_kind,_VRhkoBUGEdqrUt4zetC1gg" guid="_VRz4gBUGEdqrUt4zetC1gg" changeDate="2005-10-14T01:31:27.275-0700">
+ <mainDescription><p>
+ Work Products may take various shapes or forms, such as:
+</p>
+<ul>
+ <li>
+ A <b>model</b>, such as the Use-Case Model or the Design Model, which contains other Artifacts.
+ </li>
+ <li>
+ A <b>model element</b>; that is, an element within a model, such as a Design Class, a Use-Case or a Design
+ Subsystem.
+ </li>
+ <li>
+ <strong>Project data</strong> that might be kept in databases or other types of tabular information repositories
+ such as spreadsheets.
+ </li>
+ <li>
+ Source code and executable programs&nbsp;that contribute to the product or <strong>Solution.</strong>
+ </li>
+ <li>
+ Various types of documents, for example a <strong>specification</strong> document<strong>,</strong> such as
+ Requirements Specification, or a <strong>plan</strong> document, such as the Software Requirements Plan.
+ </li>
+</ul>
+<p>
+ They can therefore be categorized accordingly. An example is "<strong>Specification</strong>", which categorizes
+ requirements specifications that define a system with a well-defined system boundary, such as use case or functional
+ requirements specification. Unlike in Domains, a single Work Product can be categorized in multiple Work Product Kinds.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/about_base_concepts.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/about_base_concepts.xmi
new file mode 100644
index 0000000..1f9a5c0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/about_base_concepts.xmi
@@ -0,0 +1,28 @@
+<?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" epf:version="1.0.0" xmi:id="-V2B7_NtU_O7-45ldkX0Rrw" name="new_supporting_material,_uvje4D_fEdqDFvujd6NHiA" guid="-V2B7_NtU_O7-45ldkX0Rrw" changeDate="2006-09-27T19:24:54.186-0400" version="1.0.0">
+ <mainDescription><h3>
+ <a id="version" name="version">Version Information</a>
+</h3>
+<p>
+ Version 0.9
+</p>
+<h3>
+ Content
+</h3>
+<p>
+ This plug-in is a formal introduction to the Unified Method Architecture (UMA).
+</p>
+<p>
+ It&nbsp;positions UMA in terms of its goals and its novel aspects and defines all fundamental abstractions central to
+ UMA.
+</p>
+<p>
+ It is not dependent upon any other plug-ins.
+</p>
+<h3>
+ Legal Statement
+</h3>
+<p class="node">
+ See <a href="resources/copyrite.htm">Intellectual Property Notices</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/copyright.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/copyright.xmi
new file mode 100644
index 0000000..b2ea81a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/copyright.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="_u_Zg4PsDEdmyhNQr5STrZQ" name="copyright,_uuunoPsDEdmyhNQr5STrZQ" guid="_u_Zg4PsDEdmyhNQr5STrZQ" changeDate="2007-01-25T16:10:08.377-0800">
+ <mainDescription><p>
+ This program and the accompanying materials are made available under the<br />
+ <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a> which
+ accompanies this distribution.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/keyword_index.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/keyword_index.xmi
new file mode 100644
index 0000000..13e8257
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/keyword_index.xmi
@@ -0,0 +1,13 @@
+<?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="_zZxTYNnmEdmO6L4XMImrsA" name="keyword_index,2.0088322577945588E-305" guid="_zZxTYNnmEdmO6L4XMImrsA" changeDate="2005-06-14T08:32:05.050-0700">
+ <mainDescription><p class="banner" align="left">
+ The keyword index provides the ability to look-up topics in the method website based on keywords or topics. At the time
+ the pages are created, keywords are identified which allows the keyword index to be built. The top frame of the keyword
+ index window allows topics beginning with a letter or number to be displayed. The lower frame displays a list of topics
+ and their related links. Clicking on a link causes the related page to be displayed in the main frame of the published
+ site browser window.
+</p>
+<p class="banner" align="left">
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif
new file mode 100644
index 0000000..d1f6a31
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/about.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/about.gif
new file mode 100644
index 0000000..1316610
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/about.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/bookc.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/bookc.gif
new file mode 100644
index 0000000..7f2ab85
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/bookc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/bookcL.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/bookcL.gif
new file mode 100644
index 0000000..6c5b064
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/bookcL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/copyrite.htm b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/copyrite.htm
new file mode 100644
index 0000000..51edd3a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/copyrite.htm
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>IBM(R) Rational(R) Intellectual Property Notices and Other Licensing Requirements</title>
+</head>
+
+<body>
+NOTICES AND INFORMATION <br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+About This Content
+</p>
+<p>
+May 2, 2006
+</p>
+<p>
+License
+</p>
+<p>
+The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
+</p>
+<p>
+If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributors license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
+ <br>
+</BODY>
+</HTML>
\ No newline at end of file
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/whats_new.gif b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/whats_new.gif
new file mode 100644
index 0000000..7039631
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/resources/whats_new.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/search_engine.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/search_engine.xmi
new file mode 100644
index 0000000..317a834
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/search_engine.xmi
@@ -0,0 +1,147 @@
+<?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="_zZxTYtnmEdmO6L4XMImrsA" name="search_engine,3.1789140222665413E-305" guid="_zZxTYtnmEdmO6L4XMImrsA" changeDate="2005-11-09T12:02:32.459-0800">
+ <mainDescription><p>
+ <a id="using" name="using"><strong>Note</strong>: The&nbsp;Search Engine, implemented as applets, requires JRE 1.4.2 or
+ higher (you can download a JRE from</a> <a href="http://java.sun.com/j2se"
+ target="_blank">http://java.sun.com/j2se</a><a id="using" name="using">).</a>
+</p>
+<h3>
+ Tips on Using the Search Engine
+</h3>
+<p>
+ The search engine allows you to search for pages in the&nbsp;published&nbsp;Web site in a number of ways. For example,
+ you can:
+</p>
+<ul>
+ <li>
+ Search for pages that contain <b>all</b> of the words that you have typed.
+ </li>
+ <li>
+ Search for pages that contain <b>any</b> of the words that you have typed.
+ </li>
+ <li>
+ Search for pages that contain the <b>exact phrase</b> that you have typed.
+ </li>
+ <li>
+ Search for pages that contain <b>none of the words</b> that you have typed.
+ </li>
+</ul>
+<p>
+ To enter a search query, type the words to be searched for in your choice of the <b>All the words</b>, <b>Any word</b>,
+ <b>Exact phrase</b>, and <b>Without the words</b> fields, and then press <tt>ENTER</tt> or click the <b>Search Now</b>
+ button. When the search is complete, each matching page will be listed in the <b>Results</b> field, showing the page
+ title and a short summary of the content. Click a title to open the page in your published siteWeb browser window.
+</p>
+<p>
+ For example, to search for pages that contain all of the words "Rational", "Unified", and "Process", and either or both
+ of the words "adopt" and "vision", type the words <tt>Rational Unified Process</tt> in the <b>All the words</b> field,
+ and <tt>adopt vision</tt> in the <b>Any word</b> field.
+</p>
+<p>
+ You can select how many results per page that you want by using the <b>Show</b> list. If the results are more than what
+ you selected to see per page, click the <b>next</b> and <b>previous</b> buttons to page through the results.
+</p>
+<p>
+ You can also indicate whether you want the query to be applied against the published web-site or developerWorks. To
+ choose between the published web-site and developerWorks, click the <b>In section</b> list, and then select the desired
+ section.
+</p>
+<h3>
+ <a id="finding" name="finding">Finding a Word on a Page</a>
+</h3>
+<p>
+ Once a page is displayed by the search engine, use the Web browser's search tool to find a specific word on that page.
+ Press <tt>CTRL+F</tt> to start the Web browser's search tool.
+</p>
+<h3>
+ <a id="entering" name="entering">Entering a Search Query</a>
+</h3>
+<p>
+ A search query consists of one or more specified words. Boolean operators cannot be used. Instead of Boolean operators,
+ use the <b>All the words</b>, <b>Any word</b>, <b>Exact phrase</b>, or <b>Without the word</b> fields that are
+ provided. The search process is not case-sensitive, which means that <font size="3"><tt>Hello, HELLO, and
+ hElLo</tt></font> are all considered the same. The wildcard symbol is not supported: <font size="3"><tt>*</tt></font>.
+</p>
+<p>
+ When more than one field is used, the query is evaluated with precedence from top to bottom. For example, the query:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="4" bordercolordark="#808080" cellpadding="4" width="350" bordercolorlight="#808080" border="0">
+ <tbody>
+ <tr>
+ <th align="left" width="40%">
+ All the words:
+ </th>
+ <td width="60%">
+ project management
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Any word</b>:
+ </th>
+ <td width="60%">
+ adopt vision
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Exact phrase</b>:
+ </th>
+ <td width="60%">
+ Rational Unified Process
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Without the words</b>:
+ </th>
+ <td width="60%">
+ implementation
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+ <br />
+</div>
+<p>
+ This can be expressed as the following: (project AND management) AND (adopt OR vision) AND (Rational Unified Process)
+ NOT (implementation). In other words, the matching pages must contain both of the words "project" and "management", the
+ word "adopt" or "vision", along with the phrase "Rational Unified Process". Matching pages must not contain the word
+ "implementation".
+</p>
+<h3>
+ <a id="special_considerations" name="special_considerations">Special Considerations</a>
+</h3>
+<ul>
+ <li>
+ The search engine automatically excludes common words such as "where", "when", and "the" from search queries,
+ because these words are excluded during the creation of the index files on which the search operates. Excluding
+ these words improves performance of the search without impacting the precision of the results.
+ </li>
+ <li>
+ In order for a query using the <b>Without the words</b> field to make sense, there must be text in at least one of
+ the other search fields. In other words, unless you first specify that you want the search to find pages that
+ <b>do</b> contain certain words or a specific phrase, the search engine cannot find pages that <b>do not</b>
+ contain certain words.
+ </li>
+ <li>
+ Wildcard searches using the wildcard character are not supported.
+ </li>
+ <li>
+ Boolean operators are not supported. See the section titled <a href="#entering">Entering a Search Query</a> for
+ instructions on how to perform searches that are equivalent to using Boolean operators.
+ </li>
+ <li>
+ You may obtain unsatisfactory search results for queries that attempt to search for single digit numbers in their
+ numeric format, especially the numbers 0 though 9. Instead of searching for the numeric value, either omit the
+ number from the search or use the full textual spelling of the number, for example "zero", "six", "nine", "ten" and
+ so forth.
+ </li>
+</ul>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.xmi
new file mode 100644
index 0000000..eefeca4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.xmi
@@ -0,0 +1,25 @@
+<?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="-eyFTMGu83WSs-yJedYCY3g" name="new_supporting_material,_qxY8MEALEdqTMtYjAib0og" guid="-eyFTMGu83WSs-yJedYCY3g" changeDate="2006-01-18T23:07:01.069-0800">
+ <mainDescription><p>
+ For a description of this plug-in's contents, refer to <a class="elementLink"
+ href="./../../../base_concepts/guidances/supportingmaterials/about_base_concepts,_uvje4D_fEdqDFvujd6NHiA.html"
+ guid="_uvje4D_fEdqDFvujd6NHiA">About Base Concepts</a>.
+</p>
+<p>
+ The new features and changes from version to version are described below.
+</p>
+<ul>
+ <li>
+ <a href="#2.0">From&nbsp;2.0 to 2.0.1</a>
+ </li>
+ <li>
+ <a href="#1.0">1.0</a>
+ </li>
+</ul>
+<h2>
+ <a id="1.0" name="1.0">1.0</a>
+</h2>
+<p>
+ This is the initial release of this plug-in.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/activity.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/activity.xmi
new file mode 100644
index 0000000..aaac032
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/activity.xmi
@@ -0,0 +1,18 @@
+<?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" epf:version="1.0.0" xmi:id="-67u6-WRUmTOB9IdLgQg6aw" name="activity,_yoVhMB_IEdq6CKKKq4D7YA" guid="-67u6-WRUmTOB9IdLgQg6aw" changeDate="2007-02-27T09:04:48.571-0800" version="1.0.0">
+ <mainDescription><p>
+ An activity is something that one or more roles do.
+</p>
+<p>
+ In the <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html"
+ guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;, an activity is a <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html"
+ guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>&nbsp;which supports the nesting and logical grouping of related
+ process elements such as <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/descriptor,_7rS6AB_JEdq6CKKKq4D7YA.html"
+ guid="_7rS6AB_JEdq6CKKKq4D7YA">descriptor</a>&nbsp;and sub-activities, thus forming <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html"
+ guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/activity_detail_diagram.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/activity_detail_diagram.xmi
new file mode 100644
index 0000000..7b42d08
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/activity_detail_diagram.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="_ycE8HdnmEdmO6L4XMImrsA" name="activity_detail_diagram,_ycE8HNnmEdmO6L4XMImrsA" guid="_ycE8HdnmEdmO6L4XMImrsA" changeDate="2006-09-28T16:40:16.078-0400">
+ <mainDescription>Diagram depicting all the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s within the scope of an <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/activity,_yoVhMB_IEdq6CKKKq4D7YA.html" guid="_yoVhMB_IEdq6CKKKq4D7YA">activity</a>. This diagram also depicts input/output relationships between <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s,&nbsp;activities, and <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s;&nbsp;as well as responsibility relationships between <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html" guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and tasks. Activity detail diagrams are used to provide a complete summary of an
+activity&nbsp;and thus&nbsp;improve their comprehensibility.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/artifact.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/artifact.xmi
new file mode 100644
index 0000000..fbde4f9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/artifact.xmi
@@ -0,0 +1,12 @@
+<?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="_x7cUNNnmEdmO6L4XMImrsA" name="artifact,_x7cUM9nmEdmO6L4XMImrsA" guid="_x7cUNNnmEdmO6L4XMImrsA" changeDate="2006-08-31T13:52:50.953-0700">
+ <mainDescription>A formal <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;that:
+<div style="MARGIN-LEFT: 2em">
+ 1) is produced, modified, or used by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>,<br />
+ 2) defines an area of responsibility<br />
+ 3) is subject to version control.
+</div>
+<p>
+ An artifact can have multiple forms including a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/model,_yNefY9nmEdmO6L4XMImrsA.html" guid="_yNefY9nmEdmO6L4XMImrsA">model</a></i>, a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/model_element,_yNnpVdnmEdmO6L4XMImrsA.html" guid="_yNnpVdnmEdmO6L4XMImrsA">model element</a></i>, or a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/document,_yG6kY9nmEdmO6L4XMImrsA.html" guid="_yG6kY9nmEdmO6L4XMImrsA">document</a></i>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/breakdown_element.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/breakdown_element.xmi
new file mode 100644
index 0000000..060a3d4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/breakdown_element.xmi
@@ -0,0 +1,8 @@
+<?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="-7pbyO29v0VnsosWHabeZDQ" name="breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA" guid="-7pbyO29v0VnsosWHabeZDQ" changeDate="2005-09-22T19:07:46.580-0700">
+ <mainDescription>Any element modeled in <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html"
+guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that is part of <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;structure.<!--EndFragment--></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/breakdown_structure.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/breakdown_structure.xmi
new file mode 100644
index 0000000..f16fbc6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/breakdown_structure.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-dpUlq7kJXlJBUjvh7lHW7Q" name="breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA" guid="-dpUlq7kJXlJBUjvh7lHW7Q" changeDate="2006-09-28T16:44:00.796-0400">
+ <mainDescription><p>
+ A <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;construct that specifies a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;as the hierarchical composition of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/capability_pattern.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/capability_pattern.xmi
new file mode 100644
index 0000000..d951bc1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/capability_pattern.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-AY7-wWpxUmZp4c-odX8e7g" name="capability_pattern,_2RUJACO4EdqaNq6Ptg8uyA" guid="-AY7-wWpxUmZp4c-odX8e7g" changeDate="2007-02-27T09:52:34.463-0800" version="1.0.0">
+ <mainDescription><p>
+ <!--StartFragment-->A&nbsp;special <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;that describes a reusable cluster of <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/activity,_yoVhMB_IEdq6CKKKq4D7YA.html"
+ guid="_yoVhMB_IEdq6CKKKq4D7YA">activity</a>. Capability patterns express and communicate process knowledge for a key
+ area of interest such as a <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/discipline,_yGUuidnmEdmO6L4XMImrsA.html"
+ guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a>&nbsp;and can be directly used by&nbsp;practitioners to guide their work.
+ <!--EndFragment-->
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/checklist.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/checklist.xmi
new file mode 100644
index 0000000..0a16c51
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/checklist.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-d9uOWrjeHbE_1Xu2RIs-0A" name="new_term_definition,_7vpJsMaCEduMlb2cQZNTYw" guid="-d9uOWrjeHbE_1Xu2RIs-0A" changeDate="2007-02-27T09:01:08.783-0800">
+ <mainDescription>Identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as
+walkthroughs or inspections.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/composite_role.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/composite_role.xmi
new file mode 100644
index 0000000..0ff4765
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/composite_role.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-KNw2PnSSEEogCvg4sj1ebg" name="new_term_definition,_PzL7EMaEEduMlb2cQZNTYw" guid="-KNw2PnSSEEogCvg4sj1ebg" changeDate="2007-02-27T09:02:53.638-0800">
+ <mainDescription>A special role descriptor that relates to more than one <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a>. It represents a grouping of roles with the main purpose of reducing the number of
+roles defined in method content for a process.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/concept.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/concept.xmi
new file mode 100644
index 0000000..6dd4eef
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/concept.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-5bvXXNVzF7mZf0R7Oez5_g" name="new_term_definition,_wMchYMaEEduMlb2cQZNTYw" guid="-5bvXXNVzF7mZf0R7Oez5_g" changeDate="2007-02-27T09:06:17.781-0800">
+ <mainDescription>Outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general
+topics than <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guideline,_uK8HMMaFEduMlb2cQZNTYw.html"
+guid="_uK8HMMaFEduMlb2cQZNTYw">guidelines</a> and span across several work products, tasks, or activities.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/content_element.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/content_element.xmi
new file mode 100644
index 0000000..8ede4d2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/content_element.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-We7G-7OM2QspR_i1ErwtLA" name="content_element,_N8x34B_LEdq6CKKKq4D7YA" guid="-We7G-7OM2QspR_i1ErwtLA" changeDate="2006-09-28T16:46:45.015-0400">
+ <mainDescription>Any element modeled in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that is part of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/method_content,_Ts2joB_MEdq6CKKKq4D7YA.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">Method Content</a>. Content elements providestep-by-step explanations,describing how very
+specific development goals are achieved independent of the placement of these steps within a development lifecycle. They
+are instantiated and adapted to the specific situation within <a class="ELEMENTLINK" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;structures.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/content_package.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/content_package.xmi
new file mode 100644
index 0000000..89eafb7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/content_package.xmi
@@ -0,0 +1,15 @@
+<?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" epf:version="1.0.0" xmi:id="-t4Xac9J5DWCA6r1b9L40Mw" name=",_SAWgwMaFEduMlb2cQZNTYw" guid="-t4Xac9J5DWCA6r1b9L40Mw" changeDate="2007-02-27T09:10:22.988-0800">
+ <mainDescription>A&nbsp;special method package that contains <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a> exclusively. Examples for content element are <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/artifact,_x7cUM9nmEdmO6L4XMImrsA.html"
+guid="_x7cUM9nmEdmO6L4XMImrsA">artifacts</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a>, and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/custom_category.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/custom_category.xmi
new file mode 100644
index 0000000..506b86c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/custom_category.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-G9dXZH2IkpWGi4NZK-2vEw" name="new_term_definition,_eqw94MaFEduMlb2cQZNTYw" guid="-G9dXZH2IkpWGi4NZK-2vEw" changeDate="2007-02-27T09:11:39.800-0800">
+ <mainDescription>Used to categorize content based on the user's criteria. One important use is for constructing <a
+class="elementLinkWithUserText" href="./../../../base_concepts/guidances/termdefinitions/view,_GH6WUMaJEduMlb2cQZNTYw.html"
+guid="_GH6WUMaJEduMlb2cQZNTYw">views</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/customer.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/customer.xmi
new file mode 100644
index 0000000..4b69f3e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/customer.xmi
@@ -0,0 +1,7 @@
+<?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="_yE05tNnmEdmO6L4XMImrsA" name="customer,_yE05s9nmEdmO6L4XMImrsA" guid="_yE05tNnmEdmO6L4XMImrsA">
+ <mainDescription>A person or organization, internal or external to the producing organization, who takes financial responsibility for the
+system. In a large system this may or may not be the user. The customer is the ultimate recipient of the developed product.
+See also: <i><a class="elementLink" href="rup/guidances/termdefinitions/stakeholder,_yWHeDNnmEdmO6L4XMImrsA.html"
+guid="_yWHeDNnmEdmO6L4XMImrsA">stakeholder</a>.</i></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/deliverable.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/deliverable.xmi
new file mode 100644
index 0000000..98cd159
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/deliverable.xmi
@@ -0,0 +1,10 @@
+<?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="_yFbWodnmEdmO6L4XMImrsA" name="deliverable,_yFbWoNnmEdmO6L4XMImrsA" guid="_yFbWodnmEdmO6L4XMImrsA">
+ <mainDescription>An output from a <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that has a value, material or otherwise, to a <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/customer,_yE05s9nmEdmO6L4XMImrsA.html"
+guid="_yE05s9nmEdmO6L4XMImrsA">customer</a></i> or other <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/stakeholder,_yWHeDNnmEdmO6L4XMImrsA.html"
+guid="_yWHeDNnmEdmO6L4XMImrsA">stakeholder</a></i> .</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/delivery_process.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/delivery_process.xmi
new file mode 100644
index 0000000..9172121
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/delivery_process.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-IsV3QdyMdwFlqznd4UAYhw" name="delivery_process,_ZufeMCO3EdqaNq6Ptg8uyA" guid="-IsV3QdyMdwFlqznd4UAYhw" changeDate="2006-09-28T16:49:17.984-0400">
+ <mainDescription>A delivery process is a special <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific project
+type. <!--StartFragment-->It provides a complete lifecycle model that has been detailed by sequencing <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/method_content,_Ts2joB_MEdq6CKKKq4D7YA.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/descriptor.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/descriptor.xmi
new file mode 100644
index 0000000..3d05553
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/descriptor.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-TI6lqoTE1op3-SnmGa2S9Q" name="descriptor,_7rS6AB_JEdq6CKKKq4D7YA" guid="-TI6lqoTE1op3-SnmGa2S9Q" changeDate="2006-09-28T16:52:03.671-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a description is an abstract generalization for special <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s&nbsp;that reference one concrete <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>. Descriptors are the key concept for realizing the separation of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;from Method Content. A descriptor can be characterized as a reference
+object for one particular content element. In addition, a descriptor&nbsp;has its own relationships and properties whose
+purpose is to modify the semantics of the content element it refers to.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/discipline.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/discipline.xmi
new file mode 100644
index 0000000..23ec67e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/discipline.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="_yGUuitnmEdmO6L4XMImrsA" name="discipline,_yGUuidnmEdmO6L4XMImrsA" guid="_yGUuitnmEdmO6L4XMImrsA" changeDate="2006-09-28T16:52:55.750-0400">
+ <mainDescription>A&nbsp;collection of related <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s&nbsp;that define&nbsp;a major 'area of concern'. In software engineering,
+Disciplines include:&nbsp;<em>Requirements, Analysis &amp; Design, Implementation,Test,</em> and <em>Project
+Management</em>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/document.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/document.xmi
new file mode 100644
index 0000000..9316713
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/document.xmi
@@ -0,0 +1,7 @@
+<?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="_yG6kZNnmEdmO6L4XMImrsA" name="document,_yG6kY9nmEdmO6L4XMImrsA" guid="_yG6kZNnmEdmO6L4XMImrsA">
+ <mainDescription>A document is a collection of information intended to be represented on paper, or in a medium using a paper metaphor. The
+paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The
+information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets,
+schedules, Gantt charts, web-pages,&nbsp;and overhead slide presentations.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/domain.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/domain.xmi
new file mode 100644
index 0000000..34706f9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/domain.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="_yHEVYtnmEdmO6L4XMImrsA" name="domain,_yHEVYdnmEdmO6L4XMImrsA" guid="_yHEVYtnmEdmO6L4XMImrsA" changeDate="2007-02-27T11:45:19.192-0800">
+ <mainDescription><p>
+ (1)An area of knowledge or activity characterized by a family of related values.
+</p>
+<p>
+ (2) A specific problem category that is characterized by a body of knowledge, activities, and behaviors.
+</p>
+<p>
+ (3)A refineable hierarchy that groups related <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s.&nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/example.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/example.xmi
new file mode 100644
index 0000000..05a1c4e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/example.xmi
@@ -0,0 +1,12 @@
+<?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" epf:version="1.0.0" xmi:id="-WGi50KpVG9oQbP82Xvk1UA" name="new_term_definition,_nE6fsMaFEduMlb2cQZNTYw" guid="-WGi50KpVG9oQbP82Xvk1UA" changeDate="2007-02-27T09:12:23.699-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that represents a typical, partially completed, sample instance of one or more
+<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a>. Examples are most commonly provided for <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/guidance.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/guidance.xmi
new file mode 100644
index 0000000..50f31fd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/guidance.xmi
@@ -0,0 +1,10 @@
+<?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" epf:version="1.0.0" xmi:id="-CTatxBir28UK-VwWwDij-g" name="guidance,_83ttAB_NEdq6CKKKq4D7YA" guid="-CTatxBir28UK-VwWwDij-g" changeDate="2006-09-28T17:13:32.046-0400">
+ <mainDescription><p>
+ Guidance describes proven advice for accomplishing a goal.&nbsp;
+</p>
+<p>
+ In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, guidance generalizes all forms of content whose primary purpose is to provide
+ explanations about other UMA&nbsp;elements. Guidance being itself a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>, it is possible to associate guidance to other guidance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/guideline.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/guideline.xmi
new file mode 100644
index 0000000..6e83686
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/guideline.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-EEF1Y386HZ1XRsyHmGLE3g" name="new_term_definition,_uK8HMMaFEduMlb2cQZNTYw" guid="-EEF1Y386HZ1XRsyHmGLE3g" changeDate="2007-02-27T09:13:09.406-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that provides additional detail on how to handle a particular <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>. Guidelines most commonly apply to <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/input.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/input.xmi
new file mode 100644
index 0000000..eed2e20
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/input.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="_yK8IydnmEdmO6L4XMImrsA" name="input,_yK8IyNnmEdmO6L4XMImrsA" guid="_yK8IydnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:14:16.437-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>,
+input is a type of&nbsp;<a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;used by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a> See: <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/static_work_product,_yWaY9tnmEdmO6L4XMImrsA.html" guid="_yWaY9tnmEdmO6L4XMImrsA">static work product</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_configuration.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_configuration.xmi
new file mode 100644
index 0000000..75eaf45
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_configuration.xmi
@@ -0,0 +1,12 @@
+<?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" epf:version="1.0.0" xmi:id="-kzN6-iqn9zDtfnJc7IWkIg" name="new_term_definition,__V7pAMaEEduMlb2cQZNTYw" guid="-kzN6-iqn9zDtfnJc7IWkIg" changeDate="2007-02-27T09:08:12.573-0800">
+ <mainDescription>A method configuration specifies the selection of a logical subset of a <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_library,_1xELEMaFEduMlb2cQZNTYw.html"
+guid="_1xELEMaFEduMlb2cQZNTYw">method library</a>, in terms of <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_plugin,_D4TLgMaGEduMlb2cQZNTYw.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a>,&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_package,_SAWgwMaFEduMlb2cQZNTYw.html"
+guid="_SAWgwMaFEduMlb2cQZNTYw">content packages</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process_package,_MN1doMaHEduMlb2cQZNTYw.html"
+guid="_MN1doMaHEduMlb2cQZNTYw">process packages</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_content.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_content.xmi
new file mode 100644
index 0000000..6f07548
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_content.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-akU0PqDaad4Ns5MQhVBJ7Q" name="method_content,_Ts2joB_MEdq6CKKKq4D7YA" guid="-akU0PqDaad4Ns5MQhVBJ7Q" changeDate="2006-09-28T16:50:35.656-0400">
+ <mainDescription><p>
+ <!--StartFragment-->Describes generic <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> methodological concepts and <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;which provide step-by-step explanations, describing how specific goals
+ are achieved independently of the placement of these steps within a process lifecycle. <!--EndFragment-->UMA separates
+ method content from its application in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_library.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_library.xmi
new file mode 100644
index 0000000..6e4d6fa
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_library.xmi
@@ -0,0 +1,10 @@
+<?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" epf:version="1.0.0" xmi:id="-m6mx-VR4CReQNhrf4b8ykQ" name="new_term_definition,_1xELEMaFEduMlb2cQZNTYw" guid="-m6mx-VR4CReQNhrf4b8ykQ" changeDate="2007-02-27T09:13:59.698-0800">
+ <mainDescription>A&nbsp;physical container for <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_plugin,_D4TLgMaGEduMlb2cQZNTYw.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/configuration,__V7pAMaEEduMlb2cQZNTYw.html"
+guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a> definitions. All <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">method elements</a> are stored in a method library.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_plugin.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_plugin.xmi
new file mode 100644
index 0000000..359dad7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/method_plugin.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-q0ixH8duU7qb8agEywAFHQ" name="new_term_definition,_D4TLgMaGEduMlb2cQZNTYw" guid="-q0ixH8duU7qb8agEywAFHQ" changeDate="2007-02-27T09:15:37.261-0800">
+ <mainDescription>Represents a physical container for method packages. It defines a largest granularity level for the modularization and
+organization of <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_package,_SAWgwMaFEduMlb2cQZNTYw.html"
+guid="_SAWgwMaFEduMlb2cQZNTYw">method content</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">processes</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/model.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/model.xmi
new file mode 100644
index 0000000..e7c78fd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/model.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="_yNefZNnmEdmO6L4XMImrsA" name="model,_yNefY9nmEdmO6L4XMImrsA" guid="_yNefZNnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:16:05.562-0400">
+ <mainDescription><p>
+ A model is an abstraction of a more complicated thing.
+</p>
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/model_element.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/model_element.xmi
new file mode 100644
index 0000000..33a1591
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/model_element.xmi
@@ -0,0 +1,6 @@
+<?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="_yNnpVtnmEdmO6L4XMImrsA" name="model_element,_yNnpVdnmEdmO6L4XMImrsA" guid="_yNnpVtnmEdmO6L4XMImrsA" changeDate="2006-04-13T15:20:00.937-0700">
+ <mainDescription>An element that is an abstraction drawn from the system being modeled. Contrast: <i><a class="elementLink"
+href="./../../../base_concepts/guidances/termdefinitions/view_element,_ybefKdnmEdmO6L4XMImrsA.html"
+guid="_ybefKdnmEdmO6L4XMImrsA">view element</a></i>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/outcome.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/outcome.xmi
new file mode 100644
index 0000000..1827144
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/outcome.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-SQyJsrOEI73uLZzjRVmSBA" name="outcome,_LNAAcB_iEdqAHrsQ7-jSbw" guid="-SQyJsrOEI73uLZzjRVmSBA" changeDate="2006-09-28T17:18:20.984-0400">
+ <mainDescription><p>
+ <!--StartFragment-->Primarily describes intangible <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s that are a result or state. An outcome can also be used to represent
+ an informal work product.<!--EndFragment-->
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/output.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/output.xmi
new file mode 100644
index 0000000..8d2551e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/output.xmi
@@ -0,0 +1,10 @@
+<?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="_yPaZGtnmEdmO6L4XMImrsA" name="output,_yPaZGdnmEdmO6L4XMImrsA" guid="_yPaZGtnmEdmO6L4XMImrsA">
+ <mainDescription>(1) Any <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">Work Product</a>&nbsp;that is the result of a <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>. See: <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/deliverable,_yFbWoNnmEdmO6L4XMImrsA.html"
+guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a></i>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/phase.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/phase.xmi
new file mode 100644
index 0000000..13b85c7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/phase.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-88Vj7cM5EcVnfesDYaAkww" name="new_term_definition,_K9eecMaGEduMlb2cQZNTYw" guid="-88Vj7cM5EcVnfesDYaAkww" changeDate="2007-02-27T09:19:05.139-0800">
+ <mainDescription>The time between two major project <span class="docEmphasis">milestones</span>, during which a well-defined set of
+objectives is met, and decisions are made to move or not to move into the next phase.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/practice.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/practice.xmi
new file mode 100644
index 0000000..6b6bda4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/practice.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-kxtQBsUei9KRl8Z6tOSQ-g" name="new_term_definition,_wxYvkMaGEduMlb2cQZNTYw" guid="-kxtQBsUei9KRl8Z6tOSQ-g" changeDate="2007-02-27T09:20:41.644-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that presents a proven way or strategy of doing work to achieve a goal that has
+a positive impact on work product or process quality.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process.xmi
new file mode 100644
index 0000000..4756054
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="_yQ5m2dnmEdmO6L4XMImrsA" name="process,_yQ5m2NnmEdmO6L4XMImrsA" guid="_yQ5m2dnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:18:49.609-0400">
+ <mainDescription><p>
+ (1) A general structure for particular types of development projects.&nbsp;Processes take <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>s and relate them into semi-ordered sequences that are customized to
+ specific types of projects.&nbsp;Thus, a process is a set of partially ordered work descriptions intended to reach a
+ higher development goal, such as the release of a specific software&nbsp; <!--StartFragment-->These work descriptions
+ are organized into a hierarchical&nbsp;breakdown-structure A process focuses on the lifecycle and the sequencing of
+ work in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.<br />
+</p>
+<p>
+ (2) The part of&nbsp; <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that models processes.
+</p>
+<!--EndFragment--></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process_contribution.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process_contribution.xmi
new file mode 100644
index 0000000..d9154a2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process_contribution.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-fkIJikbdLETPdu0ALqo7fw" name="new_term_definition,_3iqPEMaGEduMlb2cQZNTYw" guid="-fkIJikbdLETPdu0ALqo7fw" changeDate="2007-02-27T09:21:33.607-0800">
+ <mainDescription>A special <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that externally defines additions and changes to an existing process without
+directly modifying it.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process_package.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process_package.xmi
new file mode 100644
index 0000000..994f8cf
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/process_package.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-GBZOfgyCAdK00NMpe1N5_Q" name="new_term_definition,_MN1doMaHEduMlb2cQZNTYw" guid="-GBZOfgyCAdK00NMpe1N5_Q" changeDate="2007-02-27T09:23:38.044-0800">
+ <mainDescription>A&nbsp;method package that contains processes such as <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/capability_pattern,_2RUJACO4EdqaNq6Ptg8uyA.html"
+guid="_2RUJACO4EdqaNq6Ptg8uyA">capability patterns</a> or <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/delivery_process,_ZufeMCO3EdqaNq6Ptg8uyA.html"
+guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery processes</a> only.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/release.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/release.xmi
new file mode 100644
index 0000000..a67c2e8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/release.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-hFYlBf3iN29RqVmHB9C4ug" name="new_term_definition,_Ua93IMaHEduMlb2cQZNTYw" guid="-hFYlBf3iN29RqVmHB9C4ug" changeDate="2007-02-27T11:26:19.003-0800">
+ <mainDescription>The delivery of a functional system meeting predefined objectives.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/report.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/report.xmi
new file mode 100644
index 0000000..d06aa80
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/report.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-lEbg0SKqsikKdCRXPVvRmw" name="new_term_definition,_bDCXUMaHEduMlb2cQZNTYw" guid="-lEbg0SKqsikKdCRXPVvRmw" changeDate="2007-02-27T09:25:39.894-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that is a predefined template of a result&nbsp;generated on the basis of other
+work products.&nbsp;An output from some form of tool automation.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/reusable_asset.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/reusable_asset.xmi
new file mode 100644
index 0000000..4029abf
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/reusable_asset.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-H9RSfWhEhOJscNkDKGPcBA" name="new_term_definition,_kSKZUMaHEduMlb2cQZNTYw" guid="-H9RSfWhEhOJscNkDKGPcBA" changeDate="2007-02-27T09:27:04.167-0800">
+ <mainDescription>A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that describes an asset -&nbsp;such as source code, templates, patterns,
+architectural frameworks, domain models, and so on - that can be reused in a different context.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/roadmap.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/roadmap.xmi
new file mode 100644
index 0000000..b47445e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/roadmap.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-gCtPvpHU3vmCQKQ1ymqBvw" name="new_term_definition,_19dWYMaHEduMlb2cQZNTYw" guid="-gCtPvpHU3vmCQKQ1ymqBvw" changeDate="2007-02-27T09:28:53.098-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that summarizes a process, often from a particular perspective, such as by
+providing a walkthrough with a linear thread of a typical instantiation of activities.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/role.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/role.xmi
new file mode 100644
index 0000000..02590bf
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/role.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="_yUefQdnmEdmO6L4XMImrsA" name="role,_yUefQNnmEdmO6L4XMImrsA" guid="_yUefQdnmEdmO6L4XMImrsA" changeDate="2007-02-27T09:57:49.238-0800" version="1.0.0">
+ <mainDescription>A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/role_set.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/role_set.xmi
new file mode 100644
index 0000000..13fe6f4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/role_set.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-gOXu6EqfZHMmtekNk8IDqA" name="new_term_definition,_Fs8HAMaIEduMlb2cQZNTYw" guid="-gOXu6EqfZHMmtekNk8IDqA" changeDate="2007-02-27T09:30:38.023-0800">
+ <mainDescription>Used to group <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a> with certain commonalities together.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/stakeholder.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/stakeholder.xmi
new file mode 100644
index 0000000..0db1446
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/stakeholder.xmi
@@ -0,0 +1,8 @@
+<?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="_yWHeDdnmEdmO6L4XMImrsA" name="stakeholder,_yWHeDNnmEdmO6L4XMImrsA" guid="_yWHeDdnmEdmO6L4XMImrsA">
+ <mainDescription>An individual who is who is materially affected by the&nbsp;outcome of the <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;(i.e. the <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/deliverable,_yFbWoNnmEdmO6L4XMImrsA.html"
+guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s&nbsp;the process produces).</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/static_work_product.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/static_work_product.xmi
new file mode 100644
index 0000000..3ba979b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/static_work_product.xmi
@@ -0,0 +1,7 @@
+<?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="_yWaY99nmEdmO6L4XMImrsA" name="static_work_product,_yWaY9tnmEdmO6L4XMImrsA" guid="_yWaY99nmEdmO6L4XMImrsA" changeDate="2005-09-07T12:07:47.378-0700">
+ <mainDescription>A <a class="elementLink" href="base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;that is used, but not changed, by a <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/step.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/step.xmi
new file mode 100644
index 0000000..91de21d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/step.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-KfXoeGTRnQImE1byTBtryQ" name="step,_BqZloB_eEdqAHrsQ7-jSbw" guid="-KfXoeGTRnQImE1byTBtryQ" changeDate="2006-09-28T17:22:18.140-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a step is <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>&nbsp;used to organize <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s into parts or subunits of work.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/supporting_material.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/supporting_material.xmi
new file mode 100644
index 0000000..62a65b8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/supporting_material.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-_-iQ4eQyiQVM7YhXcb90-g" name="new_term_definition,_SwvUgMaIEduMlb2cQZNTYw" guid="-_-iQ4eQyiQVM7YhXcb90-g" changeDate="2007-02-27T09:33:31.807-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that is a catch-all for other types of guidance not specifically defined
+elsewhere.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/task.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/task.xmi
new file mode 100644
index 0000000..0ebff29
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/task.xmi
@@ -0,0 +1,6 @@
+<?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="_x459k9nmEdmO6L4XMImrsA" name="task,_x459ktnmEdmO6L4XMImrsA" guid="_x459k9nmEdmO6L4XMImrsA" changeDate="2005-08-11T21:05:04.825-0700">
+ <mainDescription>A unit of work a <i><a class="elementLink"
+href="./../../../rup/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a></i> may be asked to perform.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/team_profile.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/team_profile.xmi
new file mode 100644
index 0000000..98ab95c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/team_profile.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-0cxbeJahkc1eqGKztRpcPw" name="new_term_definition,_rZOGIMaIEduMlb2cQZNTYw" guid="-0cxbeJahkc1eqGKztRpcPw" changeDate="2007-02-27T09:34:15.884-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html"
+guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a> that groups role descriptors or composite roles, thus defining a
+nested hierarchy of teams and team members.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/template.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/template.xmi
new file mode 100644
index 0000000..6abc890
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/template.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="--SOXfR7BTPs3CqtNP8R6Rw" name="new_term_definition,_1MLN8MaIEduMlb2cQZNTYw" guid="--SOXfR7BTPs3CqtNP8R6Rw" changeDate="2007-02-27T09:35:17.199-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that specifies the structure of a work product by providing a pre-defined
+table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions on how the sections
+and packages are supposed to be used and completed.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/term_definition.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/term_definition.xmi
new file mode 100644
index 0000000..b1aef3b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/term_definition.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-4JztP2JNqE36rtSC0UoYDw" name="new_term_definition,_6SluIMaIEduMlb2cQZNTYw" guid="-4JztP2JNqE36rtSC0UoYDw" changeDate="2007-02-27T09:36:03.287-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that defines concepts that are used to build up the glossary.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/tool.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/tool.xmi
new file mode 100644
index 0000000..3c9b629
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/tool.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-XnXEM7GkN21zwj7pKPmu3A" name="new_term_definition,_BangwMaJEduMlb2cQZNTYw" guid="-XnXEM7GkN21zwj7pKPmu3A" changeDate="2007-02-27T09:36:33.570-0800">
+ <mainDescription>A&nbsp;standard category used as a container for <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/tool_mentor,_yYy-mdnmEdmO6L4XMImrsA.html"
+guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentors</a>. It can also provide general descriptions of the tool and its general
+capabilities.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/tool_mentor.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/tool_mentor.xmi
new file mode 100644
index 0000000..fa53ebc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/tool_mentor.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="_yYy-mtnmEdmO6L4XMImrsA" name="tool_mentor,_yYy-mdnmEdmO6L4XMImrsA" guid="_yYy-mtnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:23:13.140-0400">
+ <mainDescription>A tool mentor is a type of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that explains how to perform specific <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>&nbsp;or <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/step,_BqZloB_eEdqAHrsQ7-jSbw.html" guid="_BqZloB_eEdqAHrsQ7-jSbw">step</a>s using a specific software tool.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/uma.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/uma.xmi
new file mode 100644
index 0000000..21cdf8f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/uma.xmi
@@ -0,0 +1,5 @@
+<?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="-QBSZ9hFRr8q6kvRyq1cESQ" name="uma,_cj6jkB_PEdq6CKKKq4D7YA" guid="-QBSZ9hFRr8q6kvRyq1cESQ" changeDate="2005-09-07T11:44:46.648-0700">
+ <mainDescription>Stands for&nbsp;Unified Method&nbsp;Architecture. UMA is a state-of-the-art architecture for the conceiving, specifying,
+and storing of method and process metadata.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/view.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/view.xmi
new file mode 100644
index 0000000..f724b3a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/view.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-dLRBfqnBlgy_0_H13LmV3A" name="new_term_definition,_GH6WUMaJEduMlb2cQZNTYw" guid="-dLRBfqnBlgy_0_H13LmV3A" changeDate="2007-02-27T09:37:06.441-0800">
+ <mainDescription>Structured content collections designed to drive publication and facilitate browsing. They are specified using <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/custom_category,_eqw94MaFEduMlb2cQZNTYw.html"
+guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/view_element.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/view_element.xmi
new file mode 100644
index 0000000..85cbec7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/view_element.xmi
@@ -0,0 +1,6 @@
+<?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="_ybefKtnmEdmO6L4XMImrsA" name="view_element,_ybefKdnmEdmO6L4XMImrsA" guid="_ybefKtnmEdmO6L4XMImrsA" changeDate="2006-04-13T15:22:45.153-0700">
+ <mainDescription>A view element is a textual and/or graphical projection of a collection of <i><a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/model_element,_yNnpVdnmEdmO6L4XMImrsA.html"
+guid="_yNnpVdnmEdmO6L4XMImrsA">model elements</a></i>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/white_paper.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/white_paper.xmi
new file mode 100644
index 0000000..7d80d0a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/white_paper.xmi
@@ -0,0 +1,11 @@
+<?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" epf:version="1.0.0" xmi:id="-QLPRVsXtlVpWZiWmQPSsnw" name="new_term_definition,_Kc1IIMaJEduMlb2cQZNTYw" guid="-QLPRVsXtlVpWZiWmQPSsnw" changeDate="2007-02-27T09:37:42.024-0800">
+ <mainDescription><p>
+ A&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+ guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;type for externally&nbsp;published papers&nbsp;that can be read and
+ understood in isolation of other <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+ guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a> and guidance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/work_product.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/work_product.xmi
new file mode 100644
index 0000000..7fdf215
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/work_product.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-dcYwPivhczonAxeyXweyIQ" name="work_product,_H4JXwB_SEdq6CKKKq4D7YA" guid="-dcYwPivhczonAxeyXweyIQ" changeDate="2006-09-28T17:23:50.015-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a
+work product is a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>&nbsp;that represents&nbsp;anything used, produced, or modified by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/work_product_kind.xmi b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/work_product_kind.xmi
new file mode 100644
index 0000000..d8991f3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/guidances/termdefinitions/work_product_kind.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-on4oCT1DzfksdshYPKAqGg" name="new_term_definition,_QWhfYMaJEduMlb2cQZNTYw" guid="-on4oCT1DzfksdshYPKAqGg" changeDate="2007-02-27T09:39:17.894-0800">
+ <mainDescription>Standard category that represents a grouping of related work products which, in contrast to <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/domain,_yHEVYdnmEdmO6L4XMImrsA.html"
+guid="_yHEVYdnmEdmO6L4XMImrsA">domain</a>, is more presentation oriented (like <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/model,_yNefY9nmEdmO6L4XMImrsA.html"
+guid="_yNefY9nmEdmO6L4XMImrsA">models</a>, specifications, plans, and so on).</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/base_concepts/plugin.xmi b/OpenUP/OpenUP_PT/library/base_concepts/plugin.xmi
new file mode 100644
index 0000000..ca62d84
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/base_concepts/plugin.xmi
@@ -0,0 +1,502 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nIcf4fL5Edm6Nvont3uinw" guid="_nIcf4fL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nIPrkfL5Edm6Nvont3uinw" id="_6B9_MO8KEdmKSqa_gSYthg" uri="customcategories/obsolete.xmi"/>
+ <resourceDescriptors xmi:id="_nIPrlvL5Edm6Nvont3uinw" id="_972lYO8LEdmKSqa_gSYthg" uri="guidances/concepts/introduction_to_uma.xmi"/>
+ <resourceDescriptors xmi:id="_nIVyMvL5Edm6Nvont3uinw" id="_EijzoO8MEdmKSqa_gSYthg" uri="guidances/concepts/delivery_process.xmi"/>
+ <resourceDescriptors xmi:id="_vAKV4PsDEdmyhNQr5STrZQ" id="_u_Zg4PsDEdmyhNQr5STrZQ" uri="guidances/supportingmaterials/copyright.xmi"/>
+ <resourceDescriptors xmi:id="_b7_AgP1XEdmek8CQTQgrOQ" id="_rgwycf1WEdmek8CQTQgrOQ" uri="customcategories/Custom%20Categories.xmi"/>
+ <resourceDescriptors xmi:id="_RdbD0AIhEdqEutyfYo0quQ" id="_RdU9MAIhEdqEutyfYo0quQ" uri="customcategories/guidance.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE5fIwEdm7AIOuZcqunQ" id="_zaz1MtnmEdmO6L4XMImrsA" uri="guidances/concepts/tool_mentor.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE5PIwEdm7AIOuZcqunQ" id="_zaz1MNnmEdmO6L4XMImrsA" uri="guidances/concepts/work_product.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4_IwEdm7AIOuZcqunQ" id="_zaqENNnmEdmO6L4XMImrsA" uri="guidances/concepts/task.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4vIwEdm7AIOuZcqunQ" id="_zaqEMtnmEdmO6L4XMImrsA" uri="guidances/concepts/role.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4fIwEdm7AIOuZcqunQ" id="_zaqEMNnmEdmO6L4XMImrsA" uri="guidances/concepts/activity.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4PIwEdm7AIOuZcqunQ" id="_zag6RdnmEdmO6L4XMImrsA" uri="guidances/concepts/capability_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_xy2SAgIsEdqEutyfYo0quQ" id="_xy2SAQIsEdqEutyfYo0quQ" uri="customcategories/guidance%202.xmi"/>
+ <resourceDescriptors xmi:id="_4RT3pPIwEdm7AIOuZcqunQ" id="_zZxTYtnmEdmO6L4XMImrsA" uri="guidances/supportingmaterials/search_engine.xmi"/>
+ <resourceDescriptors xmi:id="_uDU1ogSEEdq61bDkWg1SXw" id="_uDU1oQSEEdq61bDkWg1SXw" uri="customcategories/method_architecture_fundamentals.xmi"/>
+ <resourceDescriptors xmi:id="_5_GjwASHEdq61bDkWg1SXw" id="_3uTl0QSHEdq61bDkWg1SXw" uri="customcategories/navigating_the_process.xmi"/>
+ <resourceDescriptors xmi:id="_4RZ-SPIwEdm7AIOuZcqunQ" id="_zag6Q9nmEdmO6L4XMImrsA" uri="guidances/concepts/discipline.xmi"/>
+ <resourceDescriptors xmi:id="_cdlH0ArjEdqtvYgC7fo_aQ" id="_xy2SAQIsEdqEutyfYo0quQ" uri="customcategories/guidance%202.xmi"/>
+ <resourceDescriptors xmi:id="_ceiKEArjEdqtvYgC7fo_aQ" id="_zZxTYNnmEdmO6L4XMImrsA" uri="guidances/supportingmaterials/keyword_index.xmi"/>
+ <resourceDescriptors xmi:id="_4R4fZfIwEdm7AIOuZcqunQ" id="_x459k9nmEdmO6L4XMImrsA" uri="guidances/termdefinitions/task.xmi"/>
+ <resourceDescriptors xmi:id="_4SQ55vIwEdm7AIOuZcqunQ" id="_x7cUNNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/artifact.xmi"/>
+ <resourceDescriptors xmi:id="_4Ud5VfIwEdm7AIOuZcqunQ" id="_yFbWodnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/deliverable.xmi"/>
+ <resourceDescriptors xmi:id="_4U2T0vIwEdm7AIOuZcqunQ" id="_yGUuitnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/discipline.xmi"/>
+ <resourceDescriptors xmi:id="_4VChEPIwEdm7AIOuZcqunQ" id="_yHEVYtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/domain.xmi"/>
+ <resourceDescriptors xmi:id="_4WkLEfIwEdm7AIOuZcqunQ" id="_yK8IydnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/input.xmi"/>
+ <resourceDescriptors xmi:id="_4YSCUPIwEdm7AIOuZcqunQ" id="_yPaZGtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/output.xmi"/>
+ <resourceDescriptors xmi:id="_4cGLVvIwEdm7AIOuZcqunQ" id="_ycE8HdnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/activity_detail_diagram.xmi"/>
+ <resourceDescriptors xmi:id="_4ZzsVvIwEdm7AIOuZcqunQ" id="_yUefQdnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/role.xmi"/>
+ <resourceDescriptors xmi:id="_4bbc8fIwEdm7AIOuZcqunQ" id="_yYy-mtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/tool_mentor.xmi"/>
+ <resourceDescriptors xmi:id="_4Yqc1fIwEdm7AIOuZcqunQ" id="_yQ5m2dnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/process.xmi"/>
+ <resourceDescriptors xmi:id="__c1VoBTLEdqrUt4zetC1gg" id="__cpIYBTLEdqrUt4zetC1gg" uri="customcategories/base_concepts_view_building_blocks.xmi"/>
+ <resourceDescriptors xmi:id="_WfwesBTMEdqrUt4zetC1gg" id="_WfkRcBTMEdqrUt4zetC1gg" uri="customcategories/method_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_ysYFcBTMEdqrUt4zetC1gg" id="_yrIvUBTMEdqrUt4zetC1gg" uri="customcategories/categories.xmi"/>
+ <resourceDescriptors xmi:id="_AtfIYBTQEdqrUt4zetC1gg" id="_AtZBwBTQEdqrUt4zetC1gg" uri="customcategories/process_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_TqVz8BTQEdqrUt4zetC1gg" id="_TqJmsBTQEdqrUt4zetC1gg" uri="customcategories/organizational_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_2w3YUBT9EdqrUt4zetC1gg" id="_2wY3MBT9EdqrUt4zetC1gg" uri="guidances/concepts/checklist.xmi"/>
+ <resourceDescriptors xmi:id="_dCZSMBUBEdqrUt4zetC1gg" id="_dCTLkBUBEdqrUt4zetC1gg" uri="guidances/concepts/example.xmi"/>
+ <resourceDescriptors xmi:id="_s0dcwRUBEdqrUt4zetC1gg" id="_s0dcwBUBEdqrUt4zetC1gg" uri="guidances/concepts/practice.xmi"/>
+ <resourceDescriptors xmi:id="_x3EbABUBEdqrUt4zetC1gg" id="_x2-UYBUBEdqrUt4zetC1gg" uri="guidances/concepts/report.xmi"/>
+ <resourceDescriptors xmi:id="_22VxYBUBEdqrUt4zetC1gg" id="_21rDABUBEdqrUt4zetC1gg" uri="guidances/concepts/reusable_asset.xmi"/>
+ <resourceDescriptors xmi:id="_80pi4RUBEdqrUt4zetC1gg" id="_80pi4BUBEdqrUt4zetC1gg" uri="guidances/concepts/supporting_material.xmi"/>
+ <resourceDescriptors xmi:id="_G_tBoBUCEdqrUt4zetC1gg" id="_G_m7ABUCEdqrUt4zetC1gg" uri="guidances/concepts/template.xmi"/>
+ <resourceDescriptors xmi:id="_Z72tIBUDEdqrUt4zetC1gg" id="_Z7wmgBUDEdqrUt4zetC1gg" uri="guidances/concepts/term_definition.xmi"/>
+ <resourceDescriptors xmi:id="_ieVrkBUDEdqrUt4zetC1gg" id="_iePk8BUDEdqrUt4zetC1gg" uri="guidances/concepts/white_paper.xmi"/>
+ <resourceDescriptors xmi:id="_IBPFMRUEEdqrUt4zetC1gg" id="_IBPFMBUEEdqrUt4zetC1gg" uri="guidances/concepts/guideline.xmi"/>
+ <resourceDescriptors xmi:id="_5WPa8BUEEdqrUt4zetC1gg" id="_5WJUUBUEEdqrUt4zetC1gg" uri="guidances/concepts/descriptor.xmi"/>
+ <resourceDescriptors xmi:id="_d7WWoBUFEdqrUt4zetC1gg" id="_d7QQABUFEdqrUt4zetC1gg" uri="guidances/concepts/configuration.xmi"/>
+ <resourceDescriptors xmi:id="_m9DnsBUFEdqrUt4zetC1gg" id="_m83acBUFEdqrUt4zetC1gg" uri="guidances/concepts/method_library.xmi"/>
+ <resourceDescriptors xmi:id="_uMitMBUFEdqrUt4zetC1gg" id="_uMcmkBUFEdqrUt4zetC1gg" uri="guidances/concepts/view.xmi"/>
+ <resourceDescriptors xmi:id="_0LCr8RUFEdqrUt4zetC1gg" id="_0LCr8BUFEdqrUt4zetC1gg" uri="guidances/concepts/method_plugin.xmi"/>
+ <resourceDescriptors xmi:id="_49tJsRUFEdqrUt4zetC1gg" id="_49tJsBUFEdqrUt4zetC1gg" uri="guidances/concepts/content_package.xmi"/>
+ <resourceDescriptors xmi:id="_DiQtkBUGEdqrUt4zetC1gg" id="_DiKm8BUGEdqrUt4zetC1gg" uri="guidances/concepts/domain.xmi"/>
+ <resourceDescriptors xmi:id="_VR5_IBUGEdqrUt4zetC1gg" id="_VRz4gBUGEdqrUt4zetC1gg" uri="guidances/concepts/work_product_kind.xmi"/>
+ <resourceDescriptors xmi:id="_u4GWMBUGEdqrUt4zetC1gg" id="_u4APkBUGEdqrUt4zetC1gg" uri="guidances/concepts/role_set.xmi"/>
+ <resourceDescriptors xmi:id="_xunQUBUGEdqrUt4zetC1gg" id="_xuhJsBUGEdqrUt4zetC1gg" uri="guidances/concepts/custom_category.xmi"/>
+ <resourceDescriptors xmi:id="_66iNUBUGEdqrUt4zetC1gg" id="_66cGsBUGEdqrUt4zetC1gg" uri="guidances/concepts/tool.xmi"/>
+ <resourceDescriptors xmi:id="_fdwAsBUJEdqrUt4zetC1gg" id="_fdds0BUJEdqrUt4zetC1gg" uri="guidances/concepts/artifact.xmi"/>
+ <resourceDescriptors xmi:id="_lCFL8BUJEdqrUt4zetC1gg" id="_lBy4EBUJEdqrUt4zetC1gg" uri="guidances/concepts/deliverable.xmi"/>
+ <resourceDescriptors xmi:id="_pRsnABUJEdqrUt4zetC1gg" id="_pRmgYBUJEdqrUt4zetC1gg" uri="guidances/concepts/outcome.xmi"/>
+ <resourceDescriptors xmi:id="_Tp7-8BUKEdqrUt4zetC1gg" id="_TpLJ8BUKEdqrUt4zetC1gg" uri="customcategories/uma_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_JCo1oBnXEdqYreeU3jqaDQ" id="_JCivABnXEdqYreeU3jqaDQ" uri="guidances/concepts/roadmap.xmi"/>
+ <resourceDescriptors xmi:id="_MUMo0BneEdqYreeU3jqaDQ" id="_MUGiMBneEdqYreeU3jqaDQ" uri="guidances/concepts/process_package.xmi"/>
+ <resourceDescriptors xmi:id="_dSHTcBtHEdqSLrJ4Ij2LVA" id="-FD4UbInbyzlaGxB9oPHdcg" uri="guidances/concepts/composite_role.xmi"/>
+ <resourceDescriptors xmi:id="_ghRXEBtHEdqSLrJ4Ij2LVA" id="-J7jcN9p3FRyhuwV5Hq42Kw" uri="guidances/concepts/team_profile.xmi"/>
+ <resourceDescriptors xmi:id="_nOZd8BtpEdqSLrJ4Ij2LVA" id="-G5kN9IUns9GPxohNmAeeyw" uri="customcategories/method_package.xmi"/>
+ <resourceDescriptors xmi:id="_sXC9UBtqEdqSLrJ4Ij2LVA" id="-x11qt8TVnuIKeMC69UP1TQ" uri="guidances/concepts/process_contribution.xmi"/>
+ <resourceDescriptors xmi:id="_3EDZoB87Edq-0cJih6RYrQ" id="_yNefZNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/model.xmi"/>
+ <resourceDescriptors xmi:id="_BHbGkB89Edq-0cJih6RYrQ" id="_ybefKtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/view_element.xmi"/>
+ <resourceDescriptors xmi:id="_IItYAB89Edq-0cJih6RYrQ" id="_yNnpVtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/model_element.xmi"/>
+ <resourceDescriptors xmi:id="_OucV4B89Edq-0cJih6RYrQ" id="_yG6kZNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/document.xmi"/>
+ <resourceDescriptors xmi:id="_FETWYB8-Edq-0cJih6RYrQ" id="_yWHeDdnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/stakeholder.xmi"/>
+ <resourceDescriptors xmi:id="_NMio0B8-Edq-0cJih6RYrQ" id="_yE05tNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/customer.xmi"/>
+ <resourceDescriptors xmi:id="_x-GsIB8-Edq-0cJih6RYrQ" id="_yWaY99nmEdmO6L4XMImrsA" uri="guidances/termdefinitions/static_work_product.xmi"/>
+ <resourceDescriptors xmi:id="_7trfoB_JEdq6CKKKq4D7YA" id="-67u6-WRUmTOB9IdLgQg6aw" uri="guidances/termdefinitions/activity.xmi"/>
+ <resourceDescriptors xmi:id="_i_kKoB_KEdq6CKKKq4D7YA" id="-TI6lqoTE1op3-SnmGa2S9Q" uri="guidances/termdefinitions/descriptor.xmi"/>
+ <resourceDescriptors xmi:id="_auhsEB_LEdq6CKKKq4D7YA" id="-We7G-7OM2QspR_i1ErwtLA" uri="guidances/termdefinitions/content_element.xmi"/>
+ <resourceDescriptors xmi:id="_BRIPMB_MEdq6CKKKq4D7YA" id="-7pbyO29v0VnsosWHabeZDQ" uri="guidances/termdefinitions/breakdown_element.xmi"/>
+ <resourceDescriptors xmi:id="_t5D8YB_NEdq6CKKKq4D7YA" id="-akU0PqDaad4Ns5MQhVBJ7Q" uri="guidances/termdefinitions/method_content.xmi"/>
+ <resourceDescriptors xmi:id="_vOY7IB_OEdq6CKKKq4D7YA" id="-CTatxBir28UK-VwWwDij-g" uri="guidances/termdefinitions/guidance.xmi"/>
+ <resourceDescriptors xmi:id="_wnDhwB_PEdq6CKKKq4D7YA" id="-QBSZ9hFRr8q6kvRyq1cESQ" uri="guidances/termdefinitions/uma.xmi"/>
+ <resourceDescriptors xmi:id="_dYLAIB_REdq6CKKKq4D7YA" id="-dpUlq7kJXlJBUjvh7lHW7Q" uri="guidances/termdefinitions/breakdown_structure.xmi"/>
+ <resourceDescriptors xmi:id="_SqguIB_SEdq6CKKKq4D7YA" id="-dcYwPivhczonAxeyXweyIQ" uri="guidances/termdefinitions/work_product.xmi"/>
+ <resourceDescriptors xmi:id="_eZBtQB_eEdqAHrsQ7-jSbw" id="-KfXoeGTRnQImE1byTBtryQ" uri="guidances/termdefinitions/step.xmi"/>
+ <resourceDescriptors xmi:id="_mWA1IB_iEdqAHrsQ7-jSbw" id="-SQyJsrOEI73uLZzjRVmSBA" uri="guidances/termdefinitions/outcome.xmi"/>
+ <resourceDescriptors xmi:id="_LzRYcB_xEdq5PKe91GlWMA" id="_TpLJ8BUKEdqrUt4zetC1gg" uri="customcategories/uma_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_8MLCkCACEdqum6ped11dHA" id="_TpLJ8BUKEdqrUt4zetC1gg" uri="customcategories/uma_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_ZwaJwCO3EdqaNq6Ptg8uyA" id="_6B9_MO8KEdmKSqa_gSYthg" uri="customcategories/cc_list.xmi"/>
+ <resourceDescriptors xmi:id="_ZwmXACO3EdqaNq6Ptg8uyA" id="_uDU1oQSEEdq61bDkWg1SXw" uri="customcategories/method_architecture_fundamentals.xmi"/>
+ <resourceDescriptors xmi:id="_ZwsdoSO3EdqaNq6Ptg8uyA" id="__cpIYBTLEdqrUt4zetC1gg" uri="customcategories/base_concepts_view_building_blocks.xmi"/>
+ <resourceDescriptors xmi:id="_ZzjkYCO3EdqaNq6Ptg8uyA" id="_m83acBUFEdqrUt4zetC1gg" uri="guidances/concepts/method_library.xmi"/>
+ <resourceDescriptors xmi:id="_ZzprACO3EdqaNq6Ptg8uyA" id="_0LCr8BUFEdqrUt4zetC1gg" uri="guidances/concepts/method_plugin.xmi"/>
+ <resourceDescriptors xmi:id="_2RyqIiO4EdqaNq6Ptg8uyA" id="-IsV3QdyMdwFlqznd4UAYhw" uri="guidances/termdefinitions/delivery_process.xmi"/>
+ <resourceDescriptors xmi:id="_b2aiECO5EdqaNq6Ptg8uyA" id="-AY7-wWpxUmZp4c-odX8e7g" uri="guidances/termdefinitions/capability_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_XS6AsC7oEdqHMdmRzC0-2g" id="-bhzuf6RMHP3d-AHkoKDg7g" uri="guidances/concepts/phase.xmi"/>
+ <resourceDescriptors xmi:id="_nCEuoC7wEdqHMdmRzC0-2g" id="-dsgUC_uXte9wj6nt8DLHtw" uri="guidances/concepts/release.xmi"/>
+ <resourceDescriptors xmi:id="_1Uo8gD_fEdqDFvujd6NHiA" id="-V2B7_NtU_O7-45ldkX0Rrw" uri="guidances/supportingmaterials/about_base_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_3AVlUEALEdqTMtYjAib0og" id="-eyFTMGu83WSs-yJedYCY3g" uri="guidances/supportingmaterials/whats_new_base_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_Hq7agMaEEduMlb2cQZNTYw" id="-d9uOWrjeHbE_1Xu2RIs-0A" uri="guidances/termdefinitions/checklist.xmi"/>
+ <resourceDescriptors xmi:id="_XR3TIMaEEduMlb2cQZNTYw" id="-KNw2PnSSEEogCvg4sj1ebg" uri="guidances/termdefinitions/composite_role.xmi"/>
+ <resourceDescriptors xmi:id="_1su6IMaEEduMlb2cQZNTYw" id="-5bvXXNVzF7mZf0R7Oez5_g" uri="guidances/termdefinitions/concept.xmi"/>
+ <resourceDescriptors xmi:id="_OjgmcMaFEduMlb2cQZNTYw" id="-kzN6-iqn9zDtfnJc7IWkIg" uri="guidances/termdefinitions/method_configuration.xmi"/>
+ <resourceDescriptors xmi:id="_aPpdcMaFEduMlb2cQZNTYw" id="-t4Xac9J5DWCA6r1b9L40Mw" uri="guidances/termdefinitions/content_package.xmi"/>
+ <resourceDescriptors xmi:id="_lsCBMMaFEduMlb2cQZNTYw" id="-G9dXZH2IkpWGi4NZK-2vEw" uri="guidances/termdefinitions/custom_category.xmi"/>
+ <resourceDescriptors xmi:id="_sOPxAMaFEduMlb2cQZNTYw" id="-WGi50KpVG9oQbP82Xvk1UA" uri="guidances/termdefinitions/example.xmi"/>
+ <resourceDescriptors xmi:id="_zB_VscaFEduMlb2cQZNTYw" id="-EEF1Y386HZ1XRsyHmGLE3g" uri="guidances/termdefinitions/guideline.xmi"/>
+ <resourceDescriptors xmi:id="_6h6D4MaFEduMlb2cQZNTYw" id="-m6mx-VR4CReQNhrf4b8ykQ" uri="guidances/termdefinitions/method_library.xmi"/>
+ <resourceDescriptors xmi:id="_JEMooMaGEduMlb2cQZNTYw" id="-q0ixH8duU7qb8agEywAFHQ" uri="guidances/termdefinitions/method_plugin.xmi"/>
+ <resourceDescriptors xmi:id="_oC-N8MaGEduMlb2cQZNTYw" id="-88Vj7cM5EcVnfesDYaAkww" uri="guidances/termdefinitions/phase.xmi"/>
+ <resourceDescriptors xmi:id="_2bAqgcaGEduMlb2cQZNTYw" id="-kxtQBsUei9KRl8Z6tOSQ-g" uri="guidances/termdefinitions/practice.xmi"/>
+ <resourceDescriptors xmi:id="_-Kk-QMaGEduMlb2cQZNTYw" id="-fkIJikbdLETPdu0ALqo7fw" uri="guidances/termdefinitions/process_contribution.xmi"/>
+ <resourceDescriptors xmi:id="_SVMdcMaHEduMlb2cQZNTYw" id="-GBZOfgyCAdK00NMpe1N5_Q" uri="guidances/termdefinitions/process_package.xmi"/>
+ <resourceDescriptors xmi:id="_jkh3QcaHEduMlb2cQZNTYw" id="-lEbg0SKqsikKdCRXPVvRmw" uri="guidances/termdefinitions/report.xmi"/>
+ <resourceDescriptors xmi:id="_zUUJ4caHEduMlb2cQZNTYw" id="-H9RSfWhEhOJscNkDKGPcBA" uri="guidances/termdefinitions/reusable_asset.xmi"/>
+ <resourceDescriptors xmi:id="_D5S_IcaIEduMlb2cQZNTYw" id="-gCtPvpHU3vmCQKQ1ymqBvw" uri="guidances/termdefinitions/roadmap.xmi"/>
+ <resourceDescriptors xmi:id="_PS1DMMaIEduMlb2cQZNTYw" id="-gOXu6EqfZHMmtekNk8IDqA" uri="guidances/termdefinitions/role_set.xmi"/>
+ <resourceDescriptors xmi:id="_pL22sMaIEduMlb2cQZNTYw" id="-_-iQ4eQyiQVM7YhXcb90-g" uri="guidances/termdefinitions/supporting_material.xmi"/>
+ <resourceDescriptors xmi:id="_vwNUgMaIEduMlb2cQZNTYw" id="-0cxbeJahkc1eqGKztRpcPw" uri="guidances/termdefinitions/team_profile.xmi"/>
+ <resourceDescriptors xmi:id="_45GysMaIEduMlb2cQZNTYw" id="--SOXfR7BTPs3CqtNP8R6Rw" uri="guidances/termdefinitions/template.xmi"/>
+ <resourceDescriptors xmi:id="__wfhQMaIEduMlb2cQZNTYw" id="-4JztP2JNqE36rtSC0UoYDw" uri="guidances/termdefinitions/term_definition.xmi"/>
+ <resourceDescriptors xmi:id="_ERlt4caJEduMlb2cQZNTYw" id="-XnXEM7GkN21zwj7pKPmu3A" uri="guidances/termdefinitions/tool.xmi"/>
+ <resourceDescriptors xmi:id="_JK7bYcaJEduMlb2cQZNTYw" id="-dLRBfqnBlgy_0_H13LmV3A" uri="guidances/termdefinitions/view.xmi"/>
+ <resourceDescriptors xmi:id="_OekfQcaJEduMlb2cQZNTYw" id="-QLPRVsXtlVpWZiWmQPSsnw" uri="guidances/termdefinitions/white_paper.xmi"/>
+ <resourceDescriptors xmi:id="_hXmawcaJEduMlb2cQZNTYw" id="-on4oCT1DzfksdshYPKAqGg" uri="guidances/termdefinitions/work_product_kind.xmi"/>
+ <resourceDescriptors xmi:id="_ZkcCocaYEduMlb2cQZNTYw" id="-hFYlBf3iN29RqVmHB9C4ug" uri="guidances/termdefinitions/release.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_WCUhAO8KEdmKSqa_gSYthg" name="base_concepts" guid="_WCUhAO8KEdmKSqa_gSYthg" briefDescription="This plug-in contains basic concepts necessary to use the method composition tooling. This plug-in should be in ALL configurations." authors="IBM Rational" changeDate="2006-01-18T23:00:35.464-0800" version="1.0.1" copyrightStatement="_uuunoPsDEdmyhNQr5STrZQ">
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCanoO8KEdmKSqa_gSYthg" name="Content" guid="_WCanoO8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQO8KEdmKSqa_gSYthg" name="Categories" guid="_WCguQO8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQe8KEdmKSqa_gSYthg" name="Domains" guid="_WCguQe8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQu8KEdmKSqa_gSYthg" name="Disciplines" guid="_WCguQu8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQ-8KEdmKSqa_gSYthg" name="RoleSets" guid="_WCguQ-8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguRO8KEdmKSqa_gSYthg" name="WP Types" guid="_WCguRO8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguRe8KEdmKSqa_gSYthg" name="Tools" guid="_WCguRe8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguRu8KEdmKSqa_gSYthg" name="StandardCategories" guid="_WCguRu8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguR-8KEdmKSqa_gSYthg" name="CustomCategories" guid="_WCguR-8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguSO8KEdmKSqa_gSYthg" name="Hidden" guid="_WCguSO8KEdmKSqa_gSYthg">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_WCguSe8KEdmKSqa_gSYthg" name="Custom Categories" guid="_WCguSe8KEdmKSqa_gSYthg" categorizedElements="_5_90EO8KEdmKSqa_gSYthg _7-x6YBTLEdqrUt4zetC1gg">
+ <presentation xmi:id="_rgwycf1WEdmek8CQTQgrOQ" href="uma://_rgwycf1WEdmek8CQTQgrOQ#_rgwycf1WEdmek8CQTQgrOQ"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_5_90EO8KEdmKSqa_gSYthg" name="cc_list" guid="_5_90EO8KEdmKSqa_gSYthg" briefDescription="This is a package of custom categories that can be used to compose views. It should never be used as a view itself." presentationName="Component Category List" categorizedElements="_3uTl0ASHEdq61bDkWg1SXw _xy2SAAIsEdqEutyfYo0quQ _AtM0gBTQEdqrUt4zetC1gg _R5Vk4BtpEdqSLrJ4Ij2LVA _Tp3S0BTQEdqrUt4zetC1gg _uDU1oASEEdq61bDkWg1SXw _WfL28BTMEdqrUt4zetC1gg _yqwU0BTMEdqrUt4zetC1gg">
+ <presentation xmi:id="_6B9_MO8KEdmKSqa_gSYthg" href="uma://_6B9_MO8KEdmKSqa_gSYthg#_6B9_MO8KEdmKSqa_gSYthg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_RdIv8AIhEdqEutyfYo0quQ" name="guidance" guid="_RdIv8AIhEdqEutyfYo0quQ" presentationName="Guidance" categorizedElements="1.0762105093945226E-304">
+ <presentation xmi:id="_RdU9MAIhEdqEutyfYo0quQ" href="uma://_RdU9MAIhEdqEutyfYo0quQ#_RdU9MAIhEdqEutyfYo0quQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_xy2SAAIsEdqEutyfYo0quQ" name="guidance" guid="_xy2SAAIsEdqEutyfYo0quQ" briefDescription="Guidance is an abstract concept that generalizes all forms of content whose primary purpose is to provide additional explanations and illustrations to elements such as Roles, Tasks, Work Products, Activities, or Processes." presentationName="Guidance" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_7vpJsMaCEduMlb2cQZNTYw _wMchYMaEEduMlb2cQZNTYw _nE6fsMaFEduMlb2cQZNTYw _uK8HMMaFEduMlb2cQZNTYw _wxYvkMaGEduMlb2cQZNTYw _bDCXUMaHEduMlb2cQZNTYw _kSKZUMaHEduMlb2cQZNTYw _19dWYMaHEduMlb2cQZNTYw _SwvUgMaIEduMlb2cQZNTYw _1MLN8MaIEduMlb2cQZNTYw _6SluIMaIEduMlb2cQZNTYw _yYy-mdnmEdmO6L4XMImrsA _Kc1IIMaJEduMlb2cQZNTYw">
+ <presentation xmi:id="_xy2SAQIsEdqEutyfYo0quQ" href="uma://_xy2SAQIsEdqEutyfYo0quQ#_xy2SAQIsEdqEutyfYo0quQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_uDU1oASEEdq61bDkWg1SXw" name="method_architecture_fundamentals" guid="_uDU1oASEEdq61bDkWg1SXw" briefDescription="Introduces fundamental UMA principles, concepts, abstractions." presentationName="Method Architecture Fundamentals" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_WfL28BTMEdqrUt4zetC1gg _xy2SAAIsEdqEutyfYo0quQ _AtM0gBTQEdqrUt4zetC1gg _Tp3S0BTQEdqrUt4zetC1gg _cj6jkB_PEdq6CKKKq4D7YA">
+ <presentation xmi:id="_uDU1oQSEEdq61bDkWg1SXw" href="uma://_uDU1oQSEEdq61bDkWg1SXw#_uDU1oQSEEdq61bDkWg1SXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_3uTl0ASHEdq61bDkWg1SXw" name="navigating_the_process" guid="_3uTl0ASHEdq61bDkWg1SXw" briefDescription="This guidance explains how to navigate a typical method Web site." presentationName="Navigating the Method Web Site" shapeicon="base_concepts/customcategories/resources/compassL.gif" nodeicon="base_concepts/customcategories/resources/compass.gif" categorizedElements="3.1789140222665413E-305 2.0088322577945588E-305">
+ <presentation xmi:id="_3uTl0QSHEdq61bDkWg1SXw" href="uma://_3uTl0QSHEdq61bDkWg1SXw#_3uTl0QSHEdq61bDkWg1SXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_7-x6YBTLEdqrUt4zetC1gg" name="base_concepts_view_building_blocks" guid="_7-x6YBTLEdqrUt4zetC1gg" briefDescription="This is a package of custom categories that can be used to compose views. It should never be used as a view itself." presentationName="Base Concepts View Building Blocks" categorizedElements="_3uTl0ASHEdq61bDkWg1SXw _uDU1oASEEdq61bDkWg1SXw">
+ <presentation xmi:id="__cpIYBTLEdqrUt4zetC1gg" href="uma://__cpIYBTLEdqrUt4zetC1gg#__cpIYBTLEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_WfL28BTMEdqrUt4zetC1gg" name="method_concepts" guid="_WfL28BTMEdqrUt4zetC1gg" briefDescription="UMA's fundamental Method Content abstractions are Work Products, Roles, Tasks, and Guidance." presentationName="Method Content Concepts" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_yqwU0BTMEdqrUt4zetC1gg _yUefQNnmEdmO6L4XMImrsA _x459ktnmEdmO6L4XMImrsA _x7cUM9nmEdmO6L4XMImrsA _yFbWoNnmEdmO6L4XMImrsA _LNAAcB_iEdqAHrsQ7-jSbw _H4JXwB_SEdq6CKKKq4D7YA">
+ <presentation xmi:id="_WfkRcBTMEdqrUt4zetC1gg" href="uma://_WfkRcBTMEdqrUt4zetC1gg#_WfkRcBTMEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_yqwU0BTMEdqrUt4zetC1gg" name="categories" guid="_yqwU0BTMEdqrUt4zetC1gg" briefDescription="Categories provide different ways to logically organize Method Content elements." presentationName="Categories and Views" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_eqw94MaFEduMlb2cQZNTYw _yGUuidnmEdmO6L4XMImrsA _yHEVYdnmEdmO6L4XMImrsA _Fs8HAMaIEduMlb2cQZNTYw _BangwMaJEduMlb2cQZNTYw _GH6WUMaJEduMlb2cQZNTYw _QWhfYMaJEduMlb2cQZNTYw">
+ <presentation xmi:id="_yrIvUBTMEdqrUt4zetC1gg" href="uma://_yrIvUBTMEdqrUt4zetC1gg#_yrIvUBTMEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_AtM0gBTQEdqrUt4zetC1gg" name="process_concepts" guid="_AtM0gBTQEdqrUt4zetC1gg" briefDescription="UMA defines concepts for defining processes. This section lists the most important ones." presentationName="Process Concepts" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_yoVhMB_IEdq6CKKKq4D7YA _2RUJACO4EdqaNq6Ptg8uyA _ZufeMCO3EdqaNq6Ptg8uyA _7rS6AB_JEdq6CKKKq4D7YA _3iqPEMaGEduMlb2cQZNTYw">
+ <presentation xmi:id="_AtZBwBTQEdqrUt4zetC1gg" href="uma://_AtZBwBTQEdqrUt4zetC1gg#_AtZBwBTQEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_Tp3S0BTQEdqrUt4zetC1gg" name="organizational_concepts" guid="_Tp3S0BTQEdqrUt4zetC1gg" briefDescription="This section lists several key concepts define in UMA for packaging and extending methods." presentationName="Organizational Concepts" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_SAWgwMaFEduMlb2cQZNTYw _1xELEMaFEduMlb2cQZNTYw _D4TLgMaGEduMlb2cQZNTYw __V7pAMaEEduMlb2cQZNTYw">
+ <presentation xmi:id="_TqJmsBTQEdqrUt4zetC1gg" href="uma://_TqJmsBTQEdqrUt4zetC1gg#_TqJmsBTQEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_R5Vk4BtpEdqSLrJ4Ij2LVA" name="method_package" guid="_R5Vk4BtpEdqSLrJ4Ij2LVA" briefDescription="This packaging structure defines how Method Elements can be physically organized into package hierarchies." presentationName="Method Package" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_SAWgwMaFEduMlb2cQZNTYw _MN1doMaHEduMlb2cQZNTYw">
+ <presentation xmi:id="-G5kN9IUns9GPxohNmAeeyw" href="uma://-G5kN9IUns9GPxohNmAeeyw#-G5kN9IUns9GPxohNmAeeyw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguSu8KEdmKSqa_gSYthg" name="CoreContent" guid="_WCguSu8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_eNnSAO8LEdmKSqa_gSYthg" name="General Guidance" guid="_eNnSAO8LEdmKSqa_gSYthg" briefDescription="This Content package concepts and other general guidance related to UMA and related tooling.">
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_uuunoPsDEdmyhNQr5STrZQ" name="copyright" guid="_uuunoPsDEdmyhNQr5STrZQ" presentationName="Copyright" nodeicon="base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif">
+ <presentation xmi:id="_u_Zg4PsDEdmyhNQr5STrZQ" href="uma://_u_Zg4PsDEdmyhNQr5STrZQ#_u_Zg4PsDEdmyhNQr5STrZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="3.1789140222665413E-305" name="search_engine" guid="3.1789140222665413E-305" briefDescription="The search engine allows you to search for pages in the published Web Site." presentationName="Search Engine" shapeicon="base_concepts/guidances/supportingmaterials/resources/bookcL.gif" nodeicon="base_concepts/guidances/supportingmaterials/resources/bookc.gif">
+ <presentation xmi:id="_zZxTYtnmEdmO6L4XMImrsA" href="uma://_zZxTYtnmEdmO6L4XMImrsA#_zZxTYtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="2.0088322577945588E-305" name="keyword_index" guid="2.0088322577945588E-305" briefDescription="The keyword index provides the ability to look-up topics based on keywords or topics." presentationName="Keyword Index" nodeicon="base_concepts/guidances/supportingmaterials/resources/bookc.gif">
+ <presentation xmi:id="_zZxTYNnmEdmO6L4XMImrsA" href="uma://_zZxTYNnmEdmO6L4XMImrsA#_zZxTYNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_x459ktnmEdmO6L4XMImrsA" name="task" guid="_x459ktnmEdmO6L4XMImrsA" presentationName="task">
+ <presentation xmi:id="_x459k9nmEdmO6L4XMImrsA" href="uma://_x459k9nmEdmO6L4XMImrsA#_x459k9nmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_x7cUM9nmEdmO6L4XMImrsA" name="artifact" guid="_x7cUM9nmEdmO6L4XMImrsA" presentationName="artifact">
+ <presentation xmi:id="_x7cUNNnmEdmO6L4XMImrsA" href="uma://_x7cUNNnmEdmO6L4XMImrsA#_x7cUNNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yFbWoNnmEdmO6L4XMImrsA" name="deliverable" guid="_yFbWoNnmEdmO6L4XMImrsA" presentationName="deliverable">
+ <presentation xmi:id="_yFbWodnmEdmO6L4XMImrsA" href="uma://_yFbWodnmEdmO6L4XMImrsA#_yFbWodnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yGUuidnmEdmO6L4XMImrsA" name="discipline" guid="_yGUuidnmEdmO6L4XMImrsA" presentationName="discipline">
+ <presentation xmi:id="_yGUuitnmEdmO6L4XMImrsA" href="uma://_yGUuitnmEdmO6L4XMImrsA#_yGUuitnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yHEVYdnmEdmO6L4XMImrsA" name="domain" guid="_yHEVYdnmEdmO6L4XMImrsA" presentationName="domain">
+ <presentation xmi:id="_yHEVYtnmEdmO6L4XMImrsA" href="uma://_yHEVYtnmEdmO6L4XMImrsA#_yHEVYtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yK8IyNnmEdmO6L4XMImrsA" name="input" guid="_yK8IyNnmEdmO6L4XMImrsA" presentationName="input">
+ <presentation xmi:id="_yK8IydnmEdmO6L4XMImrsA" href="uma://_yK8IydnmEdmO6L4XMImrsA#_yK8IydnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yPaZGdnmEdmO6L4XMImrsA" name="output" guid="_yPaZGdnmEdmO6L4XMImrsA" presentationName="output">
+ <presentation xmi:id="_yPaZGtnmEdmO6L4XMImrsA" href="uma://_yPaZGtnmEdmO6L4XMImrsA#_yPaZGtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ycE8HNnmEdmO6L4XMImrsA" name="activity_detail_diagram" guid="_ycE8HNnmEdmO6L4XMImrsA" presentationName="activity detail diagram">
+ <presentation xmi:id="_ycE8HdnmEdmO6L4XMImrsA" href="uma://_ycE8HdnmEdmO6L4XMImrsA#_ycE8HdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yUefQNnmEdmO6L4XMImrsA" name="role" guid="_yUefQNnmEdmO6L4XMImrsA" presentationName="role">
+ <presentation xmi:id="_yUefQdnmEdmO6L4XMImrsA" href="uma://_yUefQdnmEdmO6L4XMImrsA#_yUefQdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yYy-mdnmEdmO6L4XMImrsA" name="tool_mentor" guid="_yYy-mdnmEdmO6L4XMImrsA" presentationName="tool mentor">
+ <presentation xmi:id="_yYy-mtnmEdmO6L4XMImrsA" href="uma://_yYy-mtnmEdmO6L4XMImrsA#_yYy-mtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yQ5m2NnmEdmO6L4XMImrsA" name="process" guid="_yQ5m2NnmEdmO6L4XMImrsA" presentationName="process">
+ <presentation xmi:id="_yQ5m2dnmEdmO6L4XMImrsA" href="uma://_yQ5m2dnmEdmO6L4XMImrsA#_yQ5m2dnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yNefY9nmEdmO6L4XMImrsA" name="model" guid="_yNefY9nmEdmO6L4XMImrsA" presentationName="model">
+ <presentation xmi:id="_yNefZNnmEdmO6L4XMImrsA" href="uma://_yNefZNnmEdmO6L4XMImrsA#_yNefZNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ybefKdnmEdmO6L4XMImrsA" name="view_element" guid="_ybefKdnmEdmO6L4XMImrsA" presentationName="view element">
+ <presentation xmi:id="_ybefKtnmEdmO6L4XMImrsA" href="uma://_ybefKtnmEdmO6L4XMImrsA#_ybefKtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yNnpVdnmEdmO6L4XMImrsA" name="model_element" guid="_yNnpVdnmEdmO6L4XMImrsA" presentationName="model element">
+ <presentation xmi:id="_yNnpVtnmEdmO6L4XMImrsA" href="uma://_yNnpVtnmEdmO6L4XMImrsA#_yNnpVtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yG6kY9nmEdmO6L4XMImrsA" name="document" guid="_yG6kY9nmEdmO6L4XMImrsA" presentationName="document">
+ <presentation xmi:id="_yG6kZNnmEdmO6L4XMImrsA" href="uma://_yG6kZNnmEdmO6L4XMImrsA#_yG6kZNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yWHeDNnmEdmO6L4XMImrsA" name="stakeholder" guid="_yWHeDNnmEdmO6L4XMImrsA" presentationName="stakeholder">
+ <presentation xmi:id="_yWHeDdnmEdmO6L4XMImrsA" href="uma://_yWHeDdnmEdmO6L4XMImrsA#_yWHeDdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yE05s9nmEdmO6L4XMImrsA" name="customer" guid="_yE05s9nmEdmO6L4XMImrsA" presentationName="customer">
+ <presentation xmi:id="_yE05tNnmEdmO6L4XMImrsA" href="uma://_yE05tNnmEdmO6L4XMImrsA#_yE05tNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yWaY9tnmEdmO6L4XMImrsA" name="static_work_product" guid="_yWaY9tnmEdmO6L4XMImrsA" presentationName="static work product">
+ <presentation xmi:id="_yWaY99nmEdmO6L4XMImrsA" href="uma://_yWaY99nmEdmO6L4XMImrsA#_yWaY99nmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yoVhMB_IEdq6CKKKq4D7YA" name="activity" guid="_yoVhMB_IEdq6CKKKq4D7YA" presentationName="activity">
+ <presentation xmi:id="-67u6-WRUmTOB9IdLgQg6aw" href="uma://-67u6-WRUmTOB9IdLgQg6aw#-67u6-WRUmTOB9IdLgQg6aw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_7rS6AB_JEdq6CKKKq4D7YA" name="descriptor" guid="_7rS6AB_JEdq6CKKKq4D7YA" presentationName="descriptor">
+ <presentation xmi:id="-TI6lqoTE1op3-SnmGa2S9Q" href="uma://-TI6lqoTE1op3-SnmGa2S9Q#-TI6lqoTE1op3-SnmGa2S9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_N8x34B_LEdq6CKKKq4D7YA" name="content_element" guid="_N8x34B_LEdq6CKKKq4D7YA" presentationName="content element">
+ <presentation xmi:id="-We7G-7OM2QspR_i1ErwtLA" href="uma://-We7G-7OM2QspR_i1ErwtLA#-We7G-7OM2QspR_i1ErwtLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_cvdpEB_LEdq6CKKKq4D7YA" name="breakdown_element" guid="_cvdpEB_LEdq6CKKKq4D7YA" presentationName="breakdown element">
+ <presentation xmi:id="-7pbyO29v0VnsosWHabeZDQ" href="uma://-7pbyO29v0VnsosWHabeZDQ#-7pbyO29v0VnsosWHabeZDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Ts2joB_MEdq6CKKKq4D7YA" name="method_content" guid="_Ts2joB_MEdq6CKKKq4D7YA" presentationName="method content">
+ <presentation xmi:id="-akU0PqDaad4Ns5MQhVBJ7Q" href="uma://-akU0PqDaad4Ns5MQhVBJ7Q#-akU0PqDaad4Ns5MQhVBJ7Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_83ttAB_NEdq6CKKKq4D7YA" name="guidance" guid="_83ttAB_NEdq6CKKKq4D7YA" presentationName="guidance">
+ <presentation xmi:id="-CTatxBir28UK-VwWwDij-g" href="uma://-CTatxBir28UK-VwWwDij-g#-CTatxBir28UK-VwWwDij-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_cj6jkB_PEdq6CKKKq4D7YA" name="uma" guid="_cj6jkB_PEdq6CKKKq4D7YA" presentationName="UMA">
+ <presentation xmi:id="-QBSZ9hFRr8q6kvRyq1cESQ" href="uma://-QBSZ9hFRr8q6kvRyq1cESQ#-QBSZ9hFRr8q6kvRyq1cESQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_95LCoB_QEdq6CKKKq4D7YA" name="breakdown_structure" guid="_95LCoB_QEdq6CKKKq4D7YA" presentationName="breakdown structure">
+ <presentation xmi:id="-dpUlq7kJXlJBUjvh7lHW7Q" href="uma://-dpUlq7kJXlJBUjvh7lHW7Q#-dpUlq7kJXlJBUjvh7lHW7Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_H4JXwB_SEdq6CKKKq4D7YA" name="work_product" guid="_H4JXwB_SEdq6CKKKq4D7YA" presentationName="work product">
+ <presentation xmi:id="-dcYwPivhczonAxeyXweyIQ" href="uma://-dcYwPivhczonAxeyXweyIQ#-dcYwPivhczonAxeyXweyIQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_BqZloB_eEdqAHrsQ7-jSbw" name="step" guid="_BqZloB_eEdqAHrsQ7-jSbw" presentationName="step">
+ <presentation xmi:id="-KfXoeGTRnQImE1byTBtryQ" href="uma://-KfXoeGTRnQImE1byTBtryQ#-KfXoeGTRnQImE1byTBtryQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_LNAAcB_iEdqAHrsQ7-jSbw" name="outcome" guid="_LNAAcB_iEdqAHrsQ7-jSbw" presentationName="outcome">
+ <presentation xmi:id="-SQyJsrOEI73uLZzjRVmSBA" href="uma://-SQyJsrOEI73uLZzjRVmSBA#-SQyJsrOEI73uLZzjRVmSBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZufeMCO3EdqaNq6Ptg8uyA" name="delivery_process" guid="_ZufeMCO3EdqaNq6Ptg8uyA" presentationName="delivery process">
+ <presentation xmi:id="-IsV3QdyMdwFlqznd4UAYhw" href="uma://-IsV3QdyMdwFlqznd4UAYhw#-IsV3QdyMdwFlqznd4UAYhw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_2RUJACO4EdqaNq6Ptg8uyA" name="capability_pattern" guid="_2RUJACO4EdqaNq6Ptg8uyA" presentationName="capability pattern">
+ <presentation xmi:id="-AY7-wWpxUmZp4c-odX8e7g" href="uma://-AY7-wWpxUmZp4c-odX8e7g#-AY7-wWpxUmZp4c-odX8e7g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="__7xOEC7aEdqHMdmRzC0-2g" name="phase" guid="__7xOEC7aEdqHMdmRzC0-2g" briefDescription="This guidance introduces the concept of a phase and its purpose within a project." presentationName="Phase">
+ <presentation xmi:id="-bhzuf6RMHP3d-AHkoKDg7g" href="uma://-bhzuf6RMHP3d-AHkoKDg7g#-bhzuf6RMHP3d-AHkoKDg7g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_L5BIkC7uEdqHMdmRzC0-2g" name="release" guid="_L5BIkC7uEdqHMdmRzC0-2g" briefDescription="A Release is the delivery of a functional system meeting predefined objectives." presentationName="Release">
+ <presentation xmi:id="-dsgUC_uXte9wj6nt8DLHtw" href="uma://-dsgUC_uXte9wj6nt8DLHtw#-dsgUC_uXte9wj6nt8DLHtw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_uvje4D_fEdqDFvujd6NHiA" name="about_base_concepts" guid="_uvje4D_fEdqDFvujd6NHiA" presentationName="About Base Concepts" nodeicon="base_concepts/guidances/supportingmaterials/resources/about.gif">
+ <presentation xmi:id="-V2B7_NtU_O7-45ldkX0Rrw" href="uma://-V2B7_NtU_O7-45ldkX0Rrw#-V2B7_NtU_O7-45ldkX0Rrw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_qxY8MEALEdqTMtYjAib0og" name="whats_new_base_concepts" guid="_qxY8MEALEdqTMtYjAib0og" presentationName="What's New in Base Concepts" nodeicon="base_concepts/guidances/supportingmaterials/resources/whats_new.gif">
+ <presentation xmi:id="-eyFTMGu83WSs-yJedYCY3g" href="uma://-eyFTMGu83WSs-yJedYCY3g#-eyFTMGu83WSs-yJedYCY3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_7vpJsMaCEduMlb2cQZNTYw" name="checklist" guid="_7vpJsMaCEduMlb2cQZNTYw" presentationName="checklist">
+ <presentation xmi:id="-d9uOWrjeHbE_1Xu2RIs-0A" href="uma://-d9uOWrjeHbE_1Xu2RIs-0A#-d9uOWrjeHbE_1Xu2RIs-0A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_PzL7EMaEEduMlb2cQZNTYw" name="composite_role" guid="_PzL7EMaEEduMlb2cQZNTYw" presentationName="composite role">
+ <presentation xmi:id="-KNw2PnSSEEogCvg4sj1ebg" href="uma://-KNw2PnSSEEogCvg4sj1ebg#-KNw2PnSSEEogCvg4sj1ebg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_wMchYMaEEduMlb2cQZNTYw" name="concept" guid="_wMchYMaEEduMlb2cQZNTYw" presentationName="concept">
+ <presentation xmi:id="-5bvXXNVzF7mZf0R7Oez5_g" href="uma://-5bvXXNVzF7mZf0R7Oez5_g#-5bvXXNVzF7mZf0R7Oez5_g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="__V7pAMaEEduMlb2cQZNTYw" name="method_configuration" guid="__V7pAMaEEduMlb2cQZNTYw" presentationName="method configuration">
+ <presentation xmi:id="-kzN6-iqn9zDtfnJc7IWkIg" href="uma://-kzN6-iqn9zDtfnJc7IWkIg#-kzN6-iqn9zDtfnJc7IWkIg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_SAWgwMaFEduMlb2cQZNTYw" name="content_package" guid="_SAWgwMaFEduMlb2cQZNTYw" presentationName="content package">
+ <presentation xmi:id="-t4Xac9J5DWCA6r1b9L40Mw" href="uma://-t4Xac9J5DWCA6r1b9L40Mw#-t4Xac9J5DWCA6r1b9L40Mw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_eqw94MaFEduMlb2cQZNTYw" name="custom_category" guid="_eqw94MaFEduMlb2cQZNTYw" presentationName="custom category">
+ <presentation xmi:id="-G9dXZH2IkpWGi4NZK-2vEw" href="uma://-G9dXZH2IkpWGi4NZK-2vEw#-G9dXZH2IkpWGi4NZK-2vEw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_nE6fsMaFEduMlb2cQZNTYw" name="example" guid="_nE6fsMaFEduMlb2cQZNTYw" presentationName="example">
+ <presentation xmi:id="-WGi50KpVG9oQbP82Xvk1UA" href="uma://-WGi50KpVG9oQbP82Xvk1UA#-WGi50KpVG9oQbP82Xvk1UA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_uK8HMMaFEduMlb2cQZNTYw" name="guideline" guid="_uK8HMMaFEduMlb2cQZNTYw" presentationName="guideline">
+ <presentation xmi:id="-EEF1Y386HZ1XRsyHmGLE3g" href="uma://-EEF1Y386HZ1XRsyHmGLE3g#-EEF1Y386HZ1XRsyHmGLE3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_1xELEMaFEduMlb2cQZNTYw" name="method_library" guid="_1xELEMaFEduMlb2cQZNTYw" presentationName="method library">
+ <presentation xmi:id="-m6mx-VR4CReQNhrf4b8ykQ" href="uma://-m6mx-VR4CReQNhrf4b8ykQ#-m6mx-VR4CReQNhrf4b8ykQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_D4TLgMaGEduMlb2cQZNTYw" name="method_plugin" guid="_D4TLgMaGEduMlb2cQZNTYw" presentationName="method plug-in">
+ <presentation xmi:id="-q0ixH8duU7qb8agEywAFHQ" href="uma://-q0ixH8duU7qb8agEywAFHQ#-q0ixH8duU7qb8agEywAFHQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_K9eecMaGEduMlb2cQZNTYw" name="phase" guid="_K9eecMaGEduMlb2cQZNTYw" presentationName="phase">
+ <presentation xmi:id="-88Vj7cM5EcVnfesDYaAkww" href="uma://-88Vj7cM5EcVnfesDYaAkww#-88Vj7cM5EcVnfesDYaAkww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_wxYvkMaGEduMlb2cQZNTYw" name="practice" guid="_wxYvkMaGEduMlb2cQZNTYw" presentationName="practice">
+ <presentation xmi:id="-kxtQBsUei9KRl8Z6tOSQ-g" href="uma://-kxtQBsUei9KRl8Z6tOSQ-g#-kxtQBsUei9KRl8Z6tOSQ-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3iqPEMaGEduMlb2cQZNTYw" name="process_contribution" guid="_3iqPEMaGEduMlb2cQZNTYw" presentationName="process contribution">
+ <presentation xmi:id="-fkIJikbdLETPdu0ALqo7fw" href="uma://-fkIJikbdLETPdu0ALqo7fw#-fkIJikbdLETPdu0ALqo7fw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_MN1doMaHEduMlb2cQZNTYw" name="process_package" guid="_MN1doMaHEduMlb2cQZNTYw" presentationName="process package">
+ <presentation xmi:id="-GBZOfgyCAdK00NMpe1N5_Q" href="uma://-GBZOfgyCAdK00NMpe1N5_Q#-GBZOfgyCAdK00NMpe1N5_Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Ua93IMaHEduMlb2cQZNTYw" name="release" guid="_Ua93IMaHEduMlb2cQZNTYw" presentationName="release">
+ <presentation xmi:id="-hFYlBf3iN29RqVmHB9C4ug" href="uma://-hFYlBf3iN29RqVmHB9C4ug#-hFYlBf3iN29RqVmHB9C4ug"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_bDCXUMaHEduMlb2cQZNTYw" name="report" guid="_bDCXUMaHEduMlb2cQZNTYw" presentationName="report">
+ <presentation xmi:id="-lEbg0SKqsikKdCRXPVvRmw" href="uma://-lEbg0SKqsikKdCRXPVvRmw#-lEbg0SKqsikKdCRXPVvRmw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_kSKZUMaHEduMlb2cQZNTYw" name="reusable_asset" guid="_kSKZUMaHEduMlb2cQZNTYw" presentationName="reusable asset">
+ <presentation xmi:id="-H9RSfWhEhOJscNkDKGPcBA" href="uma://-H9RSfWhEhOJscNkDKGPcBA#-H9RSfWhEhOJscNkDKGPcBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_19dWYMaHEduMlb2cQZNTYw" name="roadmap" guid="_19dWYMaHEduMlb2cQZNTYw" presentationName="roadmap">
+ <presentation xmi:id="-gCtPvpHU3vmCQKQ1ymqBvw" href="uma://-gCtPvpHU3vmCQKQ1ymqBvw#-gCtPvpHU3vmCQKQ1ymqBvw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Fs8HAMaIEduMlb2cQZNTYw" name="role_set" guid="_Fs8HAMaIEduMlb2cQZNTYw" presentationName="role set">
+ <presentation xmi:id="-gOXu6EqfZHMmtekNk8IDqA" href="uma://-gOXu6EqfZHMmtekNk8IDqA#-gOXu6EqfZHMmtekNk8IDqA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_SwvUgMaIEduMlb2cQZNTYw" name="supporting_material" guid="_SwvUgMaIEduMlb2cQZNTYw" presentationName="supporting material">
+ <presentation xmi:id="-_-iQ4eQyiQVM7YhXcb90-g" href="uma://-_-iQ4eQyiQVM7YhXcb90-g#-_-iQ4eQyiQVM7YhXcb90-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_rZOGIMaIEduMlb2cQZNTYw" name="team_profile" guid="_rZOGIMaIEduMlb2cQZNTYw" presentationName="team profile">
+ <presentation xmi:id="-0cxbeJahkc1eqGKztRpcPw" href="uma://-0cxbeJahkc1eqGKztRpcPw#-0cxbeJahkc1eqGKztRpcPw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_1MLN8MaIEduMlb2cQZNTYw" name="template" guid="_1MLN8MaIEduMlb2cQZNTYw" presentationName="template">
+ <presentation xmi:id="--SOXfR7BTPs3CqtNP8R6Rw" href="uma://--SOXfR7BTPs3CqtNP8R6Rw#--SOXfR7BTPs3CqtNP8R6Rw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_6SluIMaIEduMlb2cQZNTYw" name="term_definition" guid="_6SluIMaIEduMlb2cQZNTYw" presentationName="term definition">
+ <presentation xmi:id="-4JztP2JNqE36rtSC0UoYDw" href="uma://-4JztP2JNqE36rtSC0UoYDw#-4JztP2JNqE36rtSC0UoYDw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_BangwMaJEduMlb2cQZNTYw" name="tool" guid="_BangwMaJEduMlb2cQZNTYw" presentationName="tool">
+ <presentation xmi:id="-XnXEM7GkN21zwj7pKPmu3A" href="uma://-XnXEM7GkN21zwj7pKPmu3A#-XnXEM7GkN21zwj7pKPmu3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_GH6WUMaJEduMlb2cQZNTYw" name="view" guid="_GH6WUMaJEduMlb2cQZNTYw" presentationName="view">
+ <presentation xmi:id="-dLRBfqnBlgy_0_H13LmV3A" href="uma://-dLRBfqnBlgy_0_H13LmV3A#-dLRBfqnBlgy_0_H13LmV3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Kc1IIMaJEduMlb2cQZNTYw" name="white_paper" guid="_Kc1IIMaJEduMlb2cQZNTYw" presentationName="white paper">
+ <presentation xmi:id="-QLPRVsXtlVpWZiWmQPSsnw" href="uma://-QLPRVsXtlVpWZiWmQPSsnw#-QLPRVsXtlVpWZiWmQPSsnw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_QWhfYMaJEduMlb2cQZNTYw" name="work_product_kind" guid="_QWhfYMaJEduMlb2cQZNTYw" presentationName="work product kind">
+ <presentation xmi:id="-on4oCT1DzfksdshYPKAqGg" href="uma://-on4oCT1DzfksdshYPKAqGg#-on4oCT1DzfksdshYPKAqGg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_AejKAMadEduMlb2cQZNTYw" name="to_a_method_authoring_plugin" guid="_AejKAMadEduMlb2cQZNTYw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2vVuUBT9EdqrUt4zetC1gg" name="checklist" guid="_2vVuUBT9EdqrUt4zetC1gg" briefDescription="A Checklist identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as walkthroughs or inspections." presentationName="Checklist">
+ <presentation xmi:id="_2wY3MBT9EdqrUt4zetC1gg" href="uma://_2wY3MBT9EdqrUt4zetC1gg#_2wY3MBT9EdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_8wobABUAEdqrUt4zetC1gg" name="concept2" guid="_8wobABUAEdqrUt4zetC1gg" briefDescription="A Concept outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general topics than Guidelines and span across several Work Products, Tasks, or activities." presentationName="Concept">
+ <presentation xmi:id="_8w0oQBUAEdqrUt4zetC1gg" href="uma://_8w0oQBUAEdqrUt4zetC1gg#_8w0oQBUAEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_dCG-UBUBEdqrUt4zetC1gg" name="example" guid="_dCG-UBUBEdqrUt4zetC1gg" briefDescription="This Guidance Type represents a typical, partially completed, sample instance of one or more Content Elements. Examples are most commonly provided for Work Products." presentationName="Example">
+ <presentation xmi:id="_dCTLkBUBEdqrUt4zetC1gg" href="uma://_dCTLkBUBEdqrUt4zetC1gg#_dCTLkBUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_IAwkEBUEEdqrUt4zetC1gg" name="guideline" guid="_IAwkEBUEEdqrUt4zetC1gg" briefDescription="This Guidance type provides additional detail on how to handle a particular Content Element. Guidelines most commonly apply to Tasks and Work Products." presentationName="Guideline">
+ <presentation xmi:id="_IBPFMBUEEdqrUt4zetC1gg" href="uma://_IBPFMBUEEdqrUt4zetC1gg#_IBPFMBUEEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_szl6EBUBEdqrUt4zetC1gg" name="practice" guid="_szl6EBUBEdqrUt4zetC1gg" briefDescription="This Guidance Type presents a proven way or strategy of doing work to achieve a goal that has a positive impact on Work Product or process quality." presentationName="Practice">
+ <presentation xmi:id="_s0dcwBUBEdqrUt4zetC1gg" href="uma://_s0dcwBUBEdqrUt4zetC1gg#_s0dcwBUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_x2sAgBUBEdqrUt4zetC1gg" name="report" guid="_x2sAgBUBEdqrUt4zetC1gg" briefDescription="This Guidance Type is a predefined template of a result that is generated on the basis of other Work Products as an output from some form of tool automation." presentationName="Report">
+ <presentation xmi:id="_x2-UYBUBEdqrUt4zetC1gg" href="uma://_x2-UYBUBEdqrUt4zetC1gg#_x2-UYBUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_20bs4BUBEdqrUt4zetC1gg" name="reusable_asset" guid="_20bs4BUBEdqrUt4zetC1gg" briefDescription="This Guidance Type describes an asset that can be reused in a different context." presentationName="Reusable Asset">
+ <presentation xmi:id="_21rDABUBEdqrUt4zetC1gg" href="uma://_21rDABUBEdqrUt4zetC1gg#_21rDABUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_JCQbIBnXEdqYreeU3jqaDQ" name="roadmap" guid="_JCQbIBnXEdqYreeU3jqaDQ" briefDescription="This Guidance Type summarizes a Process, often from a particular perspective." presentationName="Roadmap">
+ <presentation xmi:id="_JCivABnXEdqYreeU3jqaDQ" href="uma://_JCivABnXEdqYreeU3jqaDQ#_JCivABnXEdqYreeU3jqaDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_80XPABUBEdqrUt4zetC1gg" name="supporting_material" guid="_80XPABUBEdqrUt4zetC1gg" briefDescription="This Guidance Type is a catch-all for other types of Guidance not specifically defined elsewhere." presentationName="Supporting Material">
+ <presentation xmi:id="_80pi4BUBEdqrUt4zetC1gg" href="uma://_80pi4BUBEdqrUt4zetC1gg#_80pi4BUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_G_UnIBUCEdqrUt4zetC1gg" name="template" guid="_G_UnIBUCEdqrUt4zetC1gg" briefDescription="This Guidance Type specifies the structure of a Work Product by providing a pre-defined table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions how the sections and packages are supposed to be used and completed." presentationName="Template">
+ <presentation xmi:id="_G_m7ABUCEdqrUt4zetC1gg" href="uma://_G_m7ABUCEdqrUt4zetC1gg#_G_m7ABUCEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Z45fwBUDEdqrUt4zetC1gg" name="term_definition" guid="_Z45fwBUDEdqrUt4zetC1gg" briefDescription="This Guidance Type defines concepts that are used to build up the Glossary." presentationName="Term Definition">
+ <presentation xmi:id="_Z7wmgBUDEdqrUt4zetC1gg" href="uma://_Z7wmgBUDEdqrUt4zetC1gg#_Z7wmgBUDEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.0762105093945226E-304" name="tool_mentor" guid="1.0762105093945226E-304" briefDescription="This Guidance Type shows how to use a specific tool to create part of a Work Product either in the context of or independently from a Task or Activity." presentationName="Tool Mentor">
+ <presentation xmi:id="_zaz1MtnmEdmO6L4XMImrsA" href="uma://_zaz1MtnmEdmO6L4XMImrsA#_zaz1MtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_id9REBUDEdqrUt4zetC1gg" name="white_paper" guid="_id9REBUDEdqrUt4zetC1gg" briefDescription="This Guidance Type is an externally published paper that is incorporated as an attachment." presentationName="White Paper">
+ <presentation xmi:id="_iePk8BUDEdqrUt4zetC1gg" href="uma://_iePk8BUDEdqrUt4zetC1gg#_iePk8BUDEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_fdRfkBUJEdqrUt4zetC1gg" name="artifact" guid="_fdRfkBUJEdqrUt4zetC1gg" briefDescription="Artifact is a Work Product that provides a description and definition for tangible, non-trivial work products." presentationName="Artifact">
+ <presentation xmi:id="_fdds0BUJEdqrUt4zetC1gg" href="uma://_fdds0BUJEdqrUt4zetC1gg#_fdds0BUJEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_lBgkMBUJEdqrUt4zetC1gg" name="deliverable" guid="_lBgkMBUJEdqrUt4zetC1gg" briefDescription="A Deliverable is a Work Product that provides a description and definition for packaging other Work Products, and may be delivered to an internal or external party." presentationName="Deliverable">
+ <presentation xmi:id="_lBy4EBUJEdqrUt4zetC1gg" href="uma://_lBy4EBUJEdqrUt4zetC1gg#_lBy4EBUJEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_pROF4BUJEdqrUt4zetC1gg" name="outcome" guid="_pROF4BUJEdqrUt4zetC1gg" briefDescription="An Outcome describes intangible Work Products that are a result or state." presentationName="Outcome">
+ <presentation xmi:id="_pRmgYBUJEdqrUt4zetC1gg" href="uma://_pRmgYBUJEdqrUt4zetC1gg#_pRmgYBUJEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.132140065969088E-305" name="activity" guid="3.132140065969088E-305" briefDescription="An Activity supports the nesting and logical grouping of related process elements also referred to as Breakdown Elements (e.g. other Activities or Task Descriptors). The concepts Phase, Iteration, Delivery Process, and Capability Pattern are defined as special Activities." presentationName="Activity">
+ <presentation xmi:id="_zaqEMNnmEdmO6L4XMImrsA" href="uma://_zaqEMNnmEdmO6L4XMImrsA#_zaqEMNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.7072348895114264E-305" name="capability_pattern" guid="1.7072348895114264E-305" briefDescription="A Capability Pattern is a special Process that describes a reusable cluster of Activities in common process areas that produces a result of observable value." presentationName="Capability Pattern">
+ <presentation xmi:id="_zag6RdnmEdmO6L4XMImrsA" href="uma://_zag6RdnmEdmO6L4XMImrsA#_zag6RdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_EhgqwO8MEdmKSqa_gSYthg" name="delivery_process" guid="_EhgqwO8MEdmKSqa_gSYthg" briefDescription="A Delivery Process is a special Process describing a complete and integrated approach for performing a specific type of project." presentationName="Delivery Process">
+ <presentation xmi:id="_EijzoO8MEdmKSqa_gSYthg" href="uma://_EijzoO8MEdmKSqa_gSYthg#_EijzoO8MEdmKSqa_gSYthg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_5V9HEBUEEdqrUt4zetC1gg" name="descriptor" guid="_5V9HEBUEEdqrUt4zetC1gg" briefDescription="A Descriptor is a Process Element that represents the use or application of a Method Content element in the Process. The Descriptor provides the ability to override or add to what is defined in the original Method Content Element. Descriptors include Role, Task, and Work Product Descriptors." presentationName="Descriptor">
+ <presentation xmi:id="_5WJUUBUEEdqrUt4zetC1gg" href="uma://_5WJUUBUEEdqrUt4zetC1gg#_5WJUUBUEEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_49a10BUFEdqrUt4zetC1gg" name="content_package" guid="_49a10BUFEdqrUt4zetC1gg" briefDescription="A Content Package is a special Method Package that contains Content Elements exclusively. Examples for Content Element are Artifacts, Tasks, Roles, and so on." presentationName="Content Package">
+ <presentation xmi:id="_49tJsBUFEdqrUt4zetC1gg" href="uma://_49tJsBUFEdqrUt4zetC1gg#_49tJsBUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_MT6U8BneEdqYreeU3jqaDQ" name="process_package" guid="_MT6U8BneEdqYreeU3jqaDQ" briefDescription="A Process Package is a special Method Package that contains Processes such as Capability Patterns or Delivery Processes only." presentationName="Process Package">
+ <presentation xmi:id="_MUGiMBneEdqYreeU3jqaDQ" href="uma://_MUGiMBneEdqYreeU3jqaDQ#_MUGiMBneEdqYreeU3jqaDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_d698IBUFEdqrUt4zetC1gg" name="configuration" guid="_d698IBUFEdqrUt4zetC1gg" briefDescription="A Method Configuration specifies the selection of a logical subset of a Method Library." presentationName="Method Configuration">
+ <presentation xmi:id="_d7QQABUFEdqrUt4zetC1gg" href="uma://_d7QQABUFEdqrUt4zetC1gg#_d7QQABUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_m8lGkBUFEdqrUt4zetC1gg" name="method_library" guid="_m8lGkBUFEdqrUt4zetC1gg" briefDescription="A Method Library is a physical container for Method Plug-ins and Method Configuration definitions. All Method Elements are stored in a Method Library." presentationName="Method Library">
+ <presentation xmi:id="_m83acBUFEdqrUt4zetC1gg" href="uma://_m83acBUFEdqrUt4zetC1gg#_m83acBUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0KeEMBUFEdqrUt4zetC1gg" name="method_plugin" guid="_0KeEMBUFEdqrUt4zetC1gg" briefDescription="A Method Plugin represents a physical container for Method Packages. It defines a largest granularity level for the modularization and organization of method content and processes." presentationName="Method Plugin">
+ <presentation xmi:id="_0LCr8BUFEdqrUt4zetC1gg" href="uma://_0LCr8BUFEdqrUt4zetC1gg#_0LCr8BUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_94_eoO8LEdmKSqa_gSYthg" name="introduction_to_uma" guid="_94_eoO8LEdmKSqa_gSYthg" briefDescription="The Unified Method Architecture (UMA) is a process engineering meta-model that defines schema and terminology for representing methods consisting of method content and processes." presentationName="Key Capabilities of the Unified Method Architecture (UMA)">
+ <presentation xmi:id="_972lYO8LEdmKSqa_gSYthg" href="uma://_972lYO8LEdmKSqa_gSYthg#_972lYO8LEdmKSqa_gSYthg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.1609745730665898E-304" name="role" guid="1.1609745730665898E-304" briefDescription="A Role defines a set of related skills, competencies, and responsibilities." presentationName="Role">
+ <presentation xmi:id="_zaqEMtnmEdmO6L4XMImrsA" href="uma://_zaqEMtnmEdmO6L4XMImrsA#_zaqEMtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="7.624729048911575E-305" name="task" guid="7.624729048911575E-305" briefDescription="A Task describes a unit of work assigned to a Role that provides a meaningful result." presentationName="Task">
+ <presentation xmi:id="_zaqENNnmEdmO6L4XMImrsA" href="uma://_zaqENNnmEdmO6L4XMImrsA#_zaqENNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_xuO10BUGEdqrUt4zetC1gg" name="custom_category" guid="_xuO10BUGEdqrUt4zetC1gg" briefDescription="Custom categories are used to categorize content based on the user's criteria. One important use is for constructing Views." presentationName="Custom Category">
+ <presentation xmi:id="_xuhJsBUGEdqrUt4zetC1gg" href="uma://_xuhJsBUGEdqrUt4zetC1gg#_xuhJsBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.409251897849429E-305" name="discipline" guid="3.409251897849429E-305" briefDescription="A Discipline is a categorization of Tasks based upon similarity of concerns and cooperation of work effort." presentationName="Discipline">
+ <presentation xmi:id="_zag6Q9nmEdmO6L4XMImrsA" href="uma://_zag6Q9nmEdmO6L4XMImrsA#_zag6Q9nmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Dh4TEBUGEdqrUt4zetC1gg" name="domain" guid="_Dh4TEBUGEdqrUt4zetC1gg" briefDescription="Domain is a Standard Category that is a logical grouping of work products which have an affinity to each other based on resources, timing, or relationship." presentationName="Domain">
+ <presentation xmi:id="_DiKm8BUGEdqrUt4zetC1gg" href="uma://_DiKm8BUGEdqrUt4zetC1gg#_DiKm8BUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_u3t7sBUGEdqrUt4zetC1gg" name="role_set" guid="_u3t7sBUGEdqrUt4zetC1gg" briefDescription="This Standard Category organizes Roles into categories." presentationName="Role Set">
+ <presentation xmi:id="_u4APkBUGEdqrUt4zetC1gg" href="uma://_u4APkBUGEdqrUt4zetC1gg#_u4APkBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_66Jy0BUGEdqrUt4zetC1gg" name="tool" guid="_66Jy0BUGEdqrUt4zetC1gg" briefDescription="This Standard Category is a container for Tool Mentors. It can also provide general descriptions of the tool and its general capabilities." presentationName="Tool">
+ <presentation xmi:id="_66cGsBUGEdqrUt4zetC1gg" href="uma://_66cGsBUGEdqrUt4zetC1gg#_66cGsBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_uMKSsBUFEdqrUt4zetC1gg" name="view" guid="_uMKSsBUFEdqrUt4zetC1gg" briefDescription="Views are structured content collections designed to drive publication and facilitate browsing. They are specified using Custom Categories." presentationName="View">
+ <presentation xmi:id="_uMcmkBUFEdqrUt4zetC1gg" href="uma://_uMcmkBUFEdqrUt4zetC1gg#_uMcmkBUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VRhkoBUGEdqrUt4zetC1gg" name="work_product_kind" guid="_VRhkoBUGEdqrUt4zetC1gg" briefDescription="This Standard Category represents a grouping of related Work Products which, in contrast to Domain, is more presentation oriented." presentationName="Work Product Kind">
+ <presentation xmi:id="_VRz4gBUGEdqrUt4zetC1gg" href="uma://_VRz4gBUGEdqrUt4zetC1gg#_VRz4gBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="4.804531471620803E-306" name="work_product" guid="4.804531471620803E-306" briefDescription="A Work Product is something meaningful resulting from a process: Roles use Work Products to perform Tasks and produce Work Products in the course of performing Tasks." presentationName="Work Product">
+ <presentation xmi:id="_zaz1MNnmEdmO6L4XMImrsA" href="uma://_zaz1MNnmEdmO6L4XMImrsA#_zaz1MNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_NYASQBtqEdqSLrJ4Ij2LVA" name="process_contribution" guid="_NYASQBtqEdqSLrJ4Ij2LVA" briefDescription="A Process Contribution is a special Process that externally defines additions and changes to an existing Process without directly modifying it." presentationName="Process Contribution">
+ <presentation xmi:id="-x11qt8TVnuIKeMC69UP1TQ" href="uma://-x11qt8TVnuIKeMC69UP1TQ#-x11qt8TVnuIKeMC69UP1TQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_P9gp0BtHEdqSLrJ4Ij2LVA" name="composite_role" guid="_P9gp0BtHEdqSLrJ4Ij2LVA" briefDescription="A Composite Role is a special Role Descriptor that relates to more than one Role. It represents a grouping of Roles with the main purpose of reducing the number of Roles defined in Method Content for a Process." presentationName="Composite Role">
+ <presentation xmi:id="-FD4UbInbyzlaGxB9oPHdcg" href="uma://-FD4UbInbyzlaGxB9oPHdcg#-FD4UbInbyzlaGxB9oPHdcg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_dRKRMBtHEdqSLrJ4Ij2LVA" name="team_profile" guid="_dRKRMBtHEdqSLrJ4Ij2LVA" briefDescription="A Team Profile is a Breakdown Element that groups Role Descriptors or Composite Roles, thus defining a nested hierarchy of teams and team members." presentationName="Team Profile">
+ <presentation xmi:id="-J7jcN9p3FRyhuwV5Hq42Kw" href="uma://-J7jcN9p3FRyhuwV5Hq42Kw#-J7jcN9p3FRyhuwV5Hq42Kw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_WCguS-8KEdmKSqa_gSYthg" name="CapabilityPatterns" guid="_WCguS-8KEdmKSqa_gSYthg"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_WCguTO8KEdmKSqa_gSYthg" name="DeliveryProcesses" guid="_WCguTO8KEdmKSqa_gSYthg"/>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_WCguTe8KEdmKSqa_gSYthg" name="ProcessContributions" guid="_WCguTe8KEdmKSqa_gSYthg"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/configurations/OpenUPBasic.xmi b/OpenUP/OpenUP_PT/library/configurations/OpenUPBasic.xmi
new file mode 100644
index 0000000..e37d9a5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/configurations/OpenUPBasic.xmi
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:MethodConfiguration xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_0u-T4clgEdmt3adZL5Dmdw" name="OpenUPBasic" guid="_0u-T4clgEdmt3adZL5Dmdw" briefDescription="This configuration includes plug-ins a packages needed for the OpenUP/Basic process." version="1.0.0">
+ <methodPluginSelection href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TLvwMlgEdmt3adZL5Dmdw"/>
+ <methodPluginSelection href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCUhAO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0UCrYMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2YMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T2eIMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2YclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2Y8lgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2YslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T2eIslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0nJNkMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0uHYQMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T2eIclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0u-T4MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T8kwclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T8kwMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T8kwslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0UCrYclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_OGGKkMpyEdqC_NfSivunjA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_L79ggDR5EdutE_HNDTJk5Q"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_3E1NwDPBEduyTOpiJx8z_g"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0b4YwMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0UCrYslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_FtSMYAFjEduDPKiaP0pu-Q"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_IIPZQDRjEduU7vV49F9N0A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_5la48DR2EdutE_HNDTJk5Q"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0aQBEMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_kB42IDRiEduU7vV49F9N0A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8clgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YcDMMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_PGDx8PisEdmjyaJMRcPDWA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0cQzQMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_bxcS4B_REdq3EKSIdbj-MA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-etQOtQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-k0a-tQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_eE5nEEbpEduLBN1xMBngqw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_MWFjoE9HEdudU75l2xOQTw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-q7QOtQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y_PjEOtQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0ruyoMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rcewMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_Wq_VQPinEdmugcVr9AdHjQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rilYMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_S_IQ4CliEdqjQsaFX0CJTw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdEclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdEslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_jK8QsP77Edm1zMZYtD3GjA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0okw8MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oreoMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0q33AMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0CtdMPinEdmugcVr9AdHjQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qxwYMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_mpl9kDbmEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_TFSlkDboEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_JEyxADboEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNAslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_XzhPQDboEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7iclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAPimEdmugcVr9AdHjQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uHYQclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_xujGABOKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0SpacBOKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_3CqrABOKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_467NIROKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguSu8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCanoO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQ-8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQu8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQe8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguRe8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguS-8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguTO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguRO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguTe8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguR-8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguRu8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguSO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_eNnSAO8LEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_douywISSEdu8NaFPL8nS_w"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_AejKAMadEduMlb2cQZNTYw"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_RdM7MMXnEduywMSzPTUUwA"/>
+</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/OpenUP/OpenUP_PT/library/library.xmi b/OpenUP/OpenUP_PT/library/library.xmi
new file mode 100644
index 0000000..c7d2e0c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/library.xmi
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_mtb_FPL5Edm6Nvont3uinw" guid="_mtb_FPL5Edm6Nvont3uinw">
+ <subManagers xmi:id="_nHk9MPL5Edm6Nvont3uinw" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_nHk9MPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_ezIJEtVpEdqWcvghdb0qxA" guid="_ezIJEtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJE9VpEdqWcvghdb0qxA" guid="_ezIJE9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJFNVpEdqWcvghdb0qxA" guid="_ezIJFNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJFdVpEdqWcvghdb0qxA" guid="_ezIJFdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJFtVpEdqWcvghdb0qxA" guid="_ezIJFtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJF9VpEdqWcvghdb0qxA" guid="_ezIJF9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJGNVpEdqWcvghdb0qxA" guid="_ezIJGNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJGdVpEdqWcvghdb0qxA" guid="_ezIJGdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJGtVpEdqWcvghdb0qxA" guid="_ezIJGtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJG9VpEdqWcvghdb0qxA" guid="_ezIJG9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJHNVpEdqWcvghdb0qxA" guid="_ezIJHNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJHdVpEdqWcvghdb0qxA" guid="_ezIJHdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJHtVpEdqWcvghdb0qxA" guid="_ezIJHtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJH9VpEdqWcvghdb0qxA" guid="_ezIJH9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJINVpEdqWcvghdb0qxA" guid="_ezIJINVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJIdVpEdqWcvghdb0qxA" guid="_ezIJIdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJItVpEdqWcvghdb0qxA" guid="_ezIJItVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJI9VpEdqWcvghdb0qxA" guid="_ezIJI9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJNVpEdqWcvghdb0qxA" guid="_ezIJJNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJdVpEdqWcvghdb0qxA" guid="_ezIJJdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJtVpEdqWcvghdb0qxA" guid="_ezIJJtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJ9VpEdqWcvghdb0qxA" guid="_ezIJJ9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJKNVpEdqWcvghdb0qxA" guid="_ezIJKNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJKdVpEdqWcvghdb0qxA" guid="_ezIJKdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJKtVpEdqWcvghdb0qxA" guid="_ezIJKtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJK9VpEdqWcvghdb0qxA" guid="_ezIJK9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJLNVpEdqWcvghdb0qxA" guid="_ezIJLNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJLdVpEdqWcvghdb0qxA" guid="_ezIJLdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_nIcf4fL5Edm6Nvont3uinw" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_nIcf4fL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nIcf4fL5Edm6Nvont3uinw" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_nIcf4fL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nIcf4fL5Edm6Nvont3uinw" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_nIcf4fL5Edm6Nvont3uinw"/>
+ <resourceDescriptors xmi:id="_mtiFgPL5Edm6Nvont3uinw" id="_y62TUKVPEdmMZJIzZ1W7Pw" uri=""/>
+ <resourceDescriptors xmi:id="_muNa8PL5Edm6Nvont3uinw" id="_0TLvwMlgEdmt3adZL5Dmdw" uri="openup_basic/plugin.xmi"/>
+ <resourceDescriptors xmi:id="_muThkPL5Edm6Nvont3uinw" id="_WCUhAO8KEdmKSqa_gSYthg" uri="base_concepts/plugin.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodLibrary xmi:id="_y62TUKVPEdmMZJIzZ1W7Pw" name="library.xmi" guid="_y62TUKVPEdmMZJIzZ1W7Pw">
+ <methodPlugins xmi:id="_0TLvwMlgEdmt3adZL5Dmdw" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TLvwMlgEdmt3adZL5Dmdw"/>
+ <methodPlugins xmi:id="_WCUhAO8KEdmKSqa_gSYthg" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCUhAO8KEdmKSqa_gSYthg"/>
+ </org.eclipse.epf.uma:MethodLibrary>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi
new file mode 100644
index 0000000..f2944b1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi
@@ -0,0 +1,284 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-OC3td1csl7lqV15vimYOaw" guid="-OC3td1csl7lqV15vimYOaw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-C3RmtvThtego5U5cOk8uCA" guid="-C3RmtvThtego5U5cOk8uCA"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="-239OBD2wagT2qp8fuPWcHQ" guid="-239OBD2wagT2qp8fuPWcHQ">
+ <mainDescription><h3>
+ Introduction
+</h3>
+Iterations in Construction phase have a work breakdown structure (WBS) similar to iterations in the Elaboration phase, with
+activities happening in parallel. There is a different&nbsp;emphasis on how activities&nbsp;address the phase objectives,
+though.
+<p>
+ The <a href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> is expected to be stable when this phase starts, allowing the remaining
+ requirements to be implemented on top of it. Another advantage of validating the architecture and eliminating as many
+ risks as possible during Elaboration is to provide more predictability in Construction, which allows the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project manager</a> to focus on team efficiency and cost reduction.
+</p>
+<p>
+ Functionality is continuously implemented, tested, and integrated, resulting in <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
+ that are more and more complete and stable. A beta or prerelease may be deployed to a sampling of the intended audience
+ at the end of Construction. Delivery of the actual release is the main focus of the next phase.
+</p>
+<p>
+ The activities performed in a typical iteration during&nbsp;Construction phase are described after the following
+ introductions to each activity.
+</p>
+<h4>
+ Manage iteration
+</h4>
+<p>
+ This activity is performed throughout the project lifecycle. The goal of this activity is to identify risks and issues
+ early enough to mitigate them, to establish the goals for the iteration, and to support the development team in
+ reaching these goals.
+</p>
+<p>
+ Similarly to other phases, the project manager (supported by the team) launches the iteration, allocates work, tracks
+ status, and handles issues and risks. Although the high-priority and architecturally significant risks were mitigated
+ during Elaboration, new risks may appear during Construction, such as not having the right amount of resources to
+ obtain the desired degree of parallel&nbsp;development.
+</p>
+<p>
+ The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements)
+ takes place. project manager,&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>, and the remaining team members agree on what is supposed to be
+ developed during that iteration.
+</p>
+<p>
+ At the end of the iteration, the team performs an iteration assessment. The goal is to conduct a retrospective review
+ of the iteration that is ending. As part of this assessment, the objectives for the Construction phase are expected to
+ be demonstrated by the beta-quality release of the software, thus supporting the possibility of transitioning the
+ software to its end users.
+</p>
+<h4>
+ Manage requirements
+</h4>
+<p>
+ This activity is repeated throughout the lifecycle. The goal of this activity is to understand and prioritize
+ stakeholder needs and associated requirements for the system, as well as to capture these in a form that will support
+ effective communication and collaboration between the stakeholders and the development team.
+</p>
+<p>
+ During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated
+ (through a working architecture) during Elaboration.
+</p>
+<p>
+ During the Construction phase, requirements management demands less time from the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>.
+ There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
+</p>
+<p>
+ <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test cases</a> describe which&nbsp;requirements are being tested&nbsp;in that iteration.
+</p>
+<h4>
+ Develop solution
+</h4>
+<p>
+ This activity is repeated multiple times, in parallel, for each development task planned for that iteration. The main
+ goal of this activity is an executable system that provides the incremental quality and functionality for the specified
+ requirements, within the specified context.
+</p>
+<p>
+ The architecture &nbsp;was proposed and a baseline established at the end of Elaboration. Critical requirements were
+ expected to be implemented, tested, and integrated as part of the baseline architecture. As the remaining requirements
+ are implemented during Construction, the Architect identifies commonalities among solutions being developed by the
+ various developers and leverages reuse where possible. Some degree of refactoring of the architecture may be needed to
+ accommodate putting common pieces together.
+</p>
+<p>
+ A pattern similar to the Elaboration phase happens during Construction when it comes to breaking down requirements into
+ development tasks and assigning each requirement within a context to a developer. Requirements at this stage are mostly
+ of medium-to-low level of risk, but usually they represent the largest slice from the total amount of requirements to
+ be implemented in a project. Thus, it is expected that this activity is repeated, or instantiated, multiple times (once
+ per requirement within context),&nbsp;thus allowing&nbsp;parallel development. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ.html" guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous integration</a> allows functionality to be added to the code base constantly,
+ which helps the achievement of more and more complete <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
+ of the software.
+</p>
+<h4>
+ Validate build
+</h4>
+<p>
+ This activity is repeated throughout the project lifecycle. The main goal of this activity is to validate the current
+ increment of the system against the requirements allocated to it.
+</p>
+<p>
+ Similarly to Elaboration, this activity happens in parallel with the <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/develop_solution,_h2-iAfimEdmugcVr9AdHjQ.html" guid="_h2-iAfimEdmugcVr9AdHjQ">develop solution</a> activity. The intent is to validate that a stable beta release is
+ achieved and that users can perform acceptance tests.
+</p>
+<h4>
+ Ongoing tasks
+</h4>
+<p>
+ Similarly to any other phase, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any role</a> on
+ the team can submit <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">change requests</a>. The software being developed is achieving beta quality by this
+ point; therefore, defects of high priority&nbsp;are generally&nbsp;addressed during Construction iterations&nbsp;and
+ Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next
+ release of the product.
+</p></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-y0fMHq2z6qGyUlEC8ptYCQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-y0fMHq2z6qGyUlEC8ptYCQ">
+ <mainDescription><h3> Introduction </h3>
+<p> Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform
+ a goal-based planning and management. Work is assigned to developers and work
+ progress is tracked&nbsp;based on the goals to be achieved using
+ the designed, unit-tested, and&nbsp;integrated&nbsp;source code. </p>
+<h4> Context of what is being developed </h4>
+<p> A context can be specified when a requirement is assigned to be developed,
+ thus specifying how broadly a requirement is to be developed in a iteration.
+ Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business
+ logic, or&nbsp;database access),&nbsp;on a component, and so on. </p>
+<p> Whether a context is specified or not, the developer's
+ responsibility is to create a design and implementation for that requirement,
+ then to&nbsp;write and run unit tests against the implementation to make sure
+ the&nbsp;implementation works as designed, both as a unit&nbsp;and&nbsp;integrated
+ into the code base. </p>
+<h4> Overview of workflow </h4>
+<p> To accommodate major changes or&nbsp;major functionality to be developed,
+ architecture may have to be refined. Small changes and functionality may reflect
+ changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+ </p>
+<p> In any case, there is no strict sequence for how writing code and creating
+ or running &nbsp;developer tests should happen, because they can happen in parallel.&nbsp;You
+ may choose to create and run developer tests before the actual code is created
+ or the reverse sequence.</p></mainDescription>
+ <purpose><ul>
+ <li> <strong>For developers: </strong>To create a solution for the requirement
+ assigned to them </li>
+ <li> <strong>For project managers: </strong>To have a goal-based way of assigning
+ work and tracking project status </li>
+</ul></purpose>
+ </org.eclipse.epf.uma:ActivityDescription>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-q-X9OHGNRjU5gIyWVibSGQ" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
+ unit-tested, and&nbsp;integrated&nbsp;source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
+ or&nbsp;database access),&nbsp;on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
+ works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
+ happen, because they can happen in parallel.&nbsp;You may choose to create and run developer tests before the actual
+ code is created or the reverse sequence.
+</p></mainDescription>
+ <purpose><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul></purpose>
+ <usageNotes><p>
+ This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
+ requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
+ be assigned to a developer, and it should be renamed to include the actual requirement name.&nbsp;Optionally, the word
+ <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
+</p>
+<blockquote>
+ <p align="left">
+ Develop <font face="Courier New, Courier, mono">requirement_name</font> (within <font face="Courier New, Courier, mono">context_name</font> context)
+ </p>
+</blockquote>
+<p>
+ If&nbsp;a context&nbsp;is specified, there will be one instance of this pattern for each requirement&nbsp;for each
+ context.
+</p>
+<blockquote>
+ <p>
+ <strong>Example</strong>
+ </p>
+ <ol>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">user interface</font> context)
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">business logic and DB access</font> context)
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 2</font>
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">supplemental requirement 1</font>
+ </li>
+ </ol>
+</blockquote>
+<p>
+ Note that there are four instances of this pattern in the preceding example:
+</p>
+<ul>
+ <li>
+ The first two are related to the same requirement (scenario 1) but within two different contexts
+ </li>
+ <li>
+ The last two are related to different requirements, with no context specified.
+ </li>
+</ul></usageNotes>
+ </org.eclipse.epf.uma:ProcessDescription>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-q-X9OHGNRjU5gIyWVibSGQ" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
+ unit-tested, and&nbsp;integrated&nbsp;source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
+ or&nbsp;database access),&nbsp;on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
+ works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
+ happen, because they can happen in parallel.&nbsp;You may choose to create developer tests and run them before the actual
+ code is created or the reverse sequence.
+</p></mainDescription>
+ <purpose><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul></purpose>
+ </org.eclipse.epf.uma:ActivityDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/model.xmi
new file mode 100644
index 0000000..83f727a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/model.xmi
@@ -0,0 +1,591 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_z-Z5MOtQEdqc1LGhiSPqRg" guid="_z-Z5MOtQEdqc1LGhiSPqRg">
+ <resourceDescriptors xmi:id="_z-Z5MetQEdqc1LGhiSPqRg" id="-OC3td1csl7lqV15vimYOaw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_z-yTsOtQEdqc1LGhiSPqRg" id="-C3RmtvThtego5U5cOk8uCA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_z_2DoOtQEdqc1LGhiSPqRg" id="-239OBD2wagT2qp8fuPWcHQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_fwowIEbpEduLBN1xMBngqw" id="-Xfm5yDx3AVScrP1ZdLT-Sw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_u6fOsUbqEdu_9u69oWmeLA" id="-y0fMHq2z6qGyUlEC8ptYCQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_Gi_joE9HEdudU75l2xOQTw" id="-yIYJv-X_OmLGox-TBmsEOQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_Rk_4gU9HEdudU75l2xOQTw" id="-q-X9OHGNRjU5gIyWVibSGQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_y-etQOtQEdqc1LGhiSPqRg" name="construction_phase_iteration" guid="_y-etQOtQEdqc1LGhiSPqRg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_y-k0a-tQEdqc1LGhiSPqRg" name="manage_iteration" guid="_y-k0a-tQEdqc1LGhiSPqRg">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_y-k0bOtQEdqc1LGhiSPqRg" name="manage_iteration" guid="_y-k0bOtQEdqc1LGhiSPqRg" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_y-3IrutQEdqc1LGhiSPqRg" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="-OC3td1csl7lqV15vimYOaw" href="uma://-OC3td1csl7lqV15vimYOaw#-OC3td1csl7lqV15vimYOaw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_y-q7QOtQEdqc1LGhiSPqRg" name="validate_build" guid="_y-q7QOtQEdqc1LGhiSPqRg">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_y-3IretQEdqc1LGhiSPqRg" name="validate_build" guid="_y-3IretQEdqc1LGhiSPqRg" presentationName="Validate Build" hasMultipleOccurrences="true" superActivities="_y-3IrutQEdqc1LGhiSPqRg" variabilityType="extends">
+ <presentation xmi:id="-C3RmtvThtego5U5cOk8uCA" href="uma://-OC3td1csl7lqV15vimYOaw#-C3RmtvThtego5U5cOk8uCA"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_y_PjEOtQEdqc1LGhiSPqRg" name="ongoing_tasks" guid="_y_PjEOtQEdqc1LGhiSPqRg">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_y_PjTOtQEdqc1LGhiSPqRg" name="ongoing_tasks" guid="_y_PjTOtQEdqc1LGhiSPqRg" presentationName="Ongoing Tasks" isPlanned="false" superActivities="_y-3IrutQEdqc1LGhiSPqRg" isOngoing="true" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_eE5nEEbpEduLBN1xMBngqw" name="manage_requirements" guid="_eE5nEEbpEduLBN1xMBngqw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_eE5nEUbpEduLBN1xMBngqw" name="manage_requirements" guid="_eE5nEUbpEduLBN1xMBngqw" briefDescription="Detail a set of requirements (one or more use cases, scenarios, or supporting requirements)." presentationName="Manage Requirements" superActivities="_y-3IrutQEdqc1LGhiSPqRg" breakdownElements="_eFeO0EbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw _eFeO00bpEduLBN1xMBngqw _eGoFYkbpEduLBN1xMBngqw _eGoFY0bpEduLBN1xMBngqw _eGoFZEbpEduLBN1xMBngqw _eGuMBUbpEduLBN1xMBngqw _eGuMB0bpEduLBN1xMBngqw _eG0SoEbpEduLBN1xMBngqw _eHAf4EbpEduLBN1xMBngqw _eHAf4UbpEduLBN1xMBngqw _eHAf4kbpEduLBN1xMBngqw">
+ <presentation xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" href="uma://-OC3td1csl7lqV15vimYOaw#-Xfm5yDx3AVScrP1ZdLT-Sw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_eFeO0EbpEduLBN1xMBngqw" name="analyst" guid="_eFeO0EbpEduLBN1xMBngqw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_eE5nEUbpEduLBN1xMBngqw" responsibleFor="_eG0SoEbpEduLBN1xMBngqw _eGoFZEbpEduLBN1xMBngqw _eFeO00bpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eFeO0UbpEduLBN1xMBngqw" name="use_case" guid="_eFeO0UbpEduLBN1xMBngqw" presentationName="Use Case" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eFeO0kbpEduLBN1xMBngqw" name="vision" guid="_eFeO0kbpEduLBN1xMBngqw" presentationName="Vision" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eFeO00bpEduLBN1xMBngqw" name="uc_model" guid="_eFeO00bpEduLBN1xMBngqw" presentationName="Use-Case Model" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_eGoFYkbpEduLBN1xMBngqw" name="find_and_outline_requirements" guid="_eGoFYkbpEduLBN1xMBngqw" presentationName="Find and Outline Requirements" superActivities="_eE5nEUbpEduLBN1xMBngqw" isSynchronizedWithSource="false" additionallyPerformedBy="_eGuMB0bpEduLBN1xMBngqw" mandatoryInput="_eG0SoEbpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw" output="_eGoFY0bpEduLBN1xMBngqw _eGoFZEbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw" performedPrimarilyBy="_eFeO0EbpEduLBN1xMBngqw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_P9cMUPV_EdmdHa9MmVPgqQ"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_fDbgkCY-EdqNHcQ-rAojXw"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_0WhHsN-eEdqiM_wFaqLjNg"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_Mgb9IC4DEduBP8F-6-95NQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eGoFY0bpEduLBN1xMBngqw" name="work_items_list" guid="_eGoFY0bpEduLBN1xMBngqw" presentationName="Work Items List" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eGoFZEbpEduLBN1xMBngqw" name="supporting_requirements" guid="_eGoFZEbpEduLBN1xMBngqw" presentationName="Supporting Requirements" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_eGuMBUbpEduLBN1xMBngqw" name="detail_requirements" guid="_eGuMBUbpEduLBN1xMBngqw" presentationName="Detail Requirements" superActivities="_eE5nEUbpEduLBN1xMBngqw" isSynchronizedWithSource="false" additionallyPerformedBy="_eGuMB0bpEduLBN1xMBngqw" mandatoryInput="_eGoFZEbpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw _eG0SoEbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw _eFeO00bpEduLBN1xMBngqw" output="_eGoFZEbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw" performedPrimarilyBy="_eFeO0EbpEduLBN1xMBngqw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0e1mIMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_vWeHMCxSEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_B47VwCxTEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_BYbboN-bEdqiM_wFaqLjNg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_eGuMB0bpEduLBN1xMBngqw" name="stakeholder" guid="_eGuMB0bpEduLBN1xMBngqw" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eG0SoEbpEduLBN1xMBngqw" name="glossary" guid="_eG0SoEbpEduLBN1xMBngqw" presentationName="Glossary" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_eHAf4EbpEduLBN1xMBngqw" name="create_test_case" guid="_eHAf4EbpEduLBN1xMBngqw" presentationName="Create Test Cases" superActivities="_eE5nEUbpEduLBN1xMBngqw" isSynchronizedWithSource="false" additionallyPerformedBy="_eFeO0EbpEduLBN1xMBngqw" mandatoryInput="_eFeO0UbpEduLBN1xMBngqw" optionalInput="_eHAf4kbpEduLBN1xMBngqw" output="_eHAf4kbpEduLBN1xMBngqw" performedPrimarilyBy="_eHAf4UbpEduLBN1xMBngqw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iwc0clgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_IJFSsKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_LpbM8KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_NK18YKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_Ok_mMKuSEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_eHAf4UbpEduLBN1xMBngqw" name="tester" guid="_eHAf4UbpEduLBN1xMBngqw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_eE5nEUbpEduLBN1xMBngqw" responsibleFor="_eHAf4kbpEduLBN1xMBngqw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eHAf4kbpEduLBN1xMBngqw" name="test_case" guid="_eHAf4kbpEduLBN1xMBngqw" presentationName="Test Case" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZS-0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_MWFjoE9HEdudU75l2xOQTw" name="develop_solution" guid="_MWFjoE9HEdudU75l2xOQTw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_MWFjoU9HEdudU75l2xOQTw" name="develop_solution" guid="_MWFjoU9HEdudU75l2xOQTw" briefDescription="Design, implement, test and integrate the solution for a requirement within a given context." presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" superActivities="_y-3IrutQEdqc1LGhiSPqRg" breakdownElements="_MWFjo09HEdudU75l2xOQTw _MWFjpE9HEdudU75l2xOQTw _MWFjpU9HEdudU75l2xOQTw _MWFjpk9HEdudU75l2xOQTw _MWFjp09HEdudU75l2xOQTw _MWLqSU9HEdudU75l2xOQTw _MWLqQE9HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw _MWLqRE9HEdudU75l2xOQTw _MWLqQ09HEdudU75l2xOQTw _MWLqRU9HEdudU75l2xOQTw _MWLqRk9HEdudU75l2xOQTw _MWLqR09HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw _MWLqTU9HEdudU75l2xOQTw _-uRRkE_fEduE1dJ2XtzzkQ _-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ">
+ <ownedRules xmi:id="_MWFjok9HEdudU75l2xOQTw" name="diagram" guid="_MWFjok9HEdudU75l2xOQTw" body="ad_image_uri=|publish_ad_image=false|add_image_uri=|publish_add_image=false|wpd_image_uri=|publish_wpd_image=false"/>
+ <presentation xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" href="uma://-OC3td1csl7lqV15vimYOaw#-q-X9OHGNRjU5gIyWVibSGQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MWFjo09HEdudU75l2xOQTw" name="developer" guid="_MWFjo09HEdudU75l2xOQTw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWFjp09HEdudU75l2xOQTw _MWFjpk9HEdudU75l2xOQTw _MWFjpU9HEdudU75l2xOQTw _MWFjpE9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjpE9HEdudU75l2xOQTw" name="design" guid="_MWFjpE9HEdudU75l2xOQTw" presentationName="Design" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjpU9HEdudU75l2xOQTw" name="implementation" guid="_MWFjpU9HEdudU75l2xOQTw" presentationName="Implementation" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YoQcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjpk9HEdudU75l2xOQTw" name="developer_test" guid="_MWFjpk9HEdudU75l2xOQTw" presentationName="Developer Test" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjp09HEdudU75l2xOQTw" name="build" guid="_MWFjp09HEdudU75l2xOQTw" presentationName="Build" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqQE9HEdudU75l2xOQTw" name="design_solution" guid="_MWLqQE9HEdudU75l2xOQTw" presentationName="Design the Solution" superActivities="_MWFjoU9HEdudU75l2xOQTw" linkToPredecessor="_MWLqS09HEdudU75l2xOQTw" additionallyPerformedBy="_MWLqR09HEdudU75l2xOQTw _-uRRkE_fEduE1dJ2XtzzkQ _-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWLqQU9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw" optionalInput="_MWFjpE9HEdudU75l2xOQTw" output="_MWFjpE9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0fshwMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_4Z7WYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_Ci7aYFixEdusJoWkvSRO9Q"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_--6tYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_A_LU8KuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_ENwJwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_KNZYAKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_OGYbwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_9LeFME42EdudDeUNeAxPCQ"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_mUVt8BfnEduD353bkQ4frw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqQU9HEdudU75l2xOQTw" name="supporting_requirements" guid="_MWLqQU9HEdudU75l2xOQTw" presentationName="Supporting Requirements" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqQk9HEdudU75l2xOQTw" name="architecture" guid="_MWLqQk9HEdudU75l2xOQTw" presentationName="Architecture" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqQ09HEdudU75l2xOQTw" name="impl_developer_tests" guid="_MWLqQ09HEdudU75l2xOQTw" presentationName="Implement Developer Tests" superActivities="_MWFjoU9HEdudU75l2xOQTw" additionallyPerformedBy="_-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpU9HEdudU75l2xOQTw" optionalInput="_MWFjpE9HEdudU75l2xOQTw _MWLqTU9HEdudU75l2xOQTw" output="_MWFjpk9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iL1EMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_2LYo8KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g8npoC5UEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_5WtVcKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g1eDUC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_j30aAC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_ku06gC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_6wZFMKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqRE9HEdudU75l2xOQTw" name="implement_solution" guid="_MWLqRE9HEdudU75l2xOQTw" presentationName="Implement the Solution" superActivities="_MWFjoU9HEdudU75l2xOQTw" additionallyPerformedBy="_-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpE9HEdudU75l2xOQTw" optionalInput="_MWFjpU9HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw" output="_MWFjpU9HEdudU75l2xOQTw _MWFjp09HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hyzgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_2sxisE2iEduU655MA_3VXg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_iMMWoKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_pjehkNb7Edq_LtLvi4w2yw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_mFQ58KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_-0yzwDH4EduMqpUNhaTSRA"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_ni25UKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_q5XiIKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqRU9HEdudU75l2xOQTw" name="run_developer_tests" guid="_MWLqRU9HEdudU75l2xOQTw" presentationName="Run Developer Tests" superActivities="_MWFjoU9HEdudU75l2xOQTw" linkToPredecessor="_MWLqTk9HEdudU75l2xOQTw" additionallyPerformedBy="_-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpk9HEdudU75l2xOQTw _MWFjpU9HEdudU75l2xOQTw" output="_MWLqRk9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iYCUMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_MSnQsMP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_NkRF0MP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_SXPFkMP4EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqRk9HEdudU75l2xOQTw" name="test_log" guid="_MWLqRk9HEdudU75l2xOQTw" presentationName="Test Log" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZlSsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MWLqR09HEdudU75l2xOQTw" name="architect" guid="_MWLqR09HEdudU75l2xOQTw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWLqQk9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqSE9HEdudU75l2xOQTw" name="use_case" guid="_MWLqSE9HEdudU75l2xOQTw" presentationName="Use Case" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqSU9HEdudU75l2xOQTw" name="develop_arch" guid="_MWLqSU9HEdudU75l2xOQTw" presentationName="Develop the Architecture" superActivities="_MWFjoU9HEdudU75l2xOQTw" isSynchronizedWithSource="false" additionallyPerformedBy="_MWFjo09HEdudU75l2xOQTw _-uRRkE_fEduE1dJ2XtzzkQ _-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpE9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw" output="_MWFjpE9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw" performedPrimarilyBy="_MWLqR09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0gRJgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Vdln8MP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_G_k1kBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_LsyLkBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Zlw-QMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_aRCI0MP3EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MWLqS09HEdudU75l2xOQTw" guid="_MWLqS09HEdudU75l2xOQTw" linkType="finishToFinish" pred="_MWLqSU9HEdudU75l2xOQTw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqTU9HEdudU75l2xOQTw" name="test_script" guid="_MWLqTU9HEdudU75l2xOQTw" presentationName="Test Script" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MWLqTk9HEdudU75l2xOQTw" guid="_MWLqTk9HEdudU75l2xOQTw" linkType="finishToFinish" pred="_MWLqQ09HEdudU75l2xOQTw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_-uRRkE_fEduE1dJ2XtzzkQ" name="analyst" guid="_-uRRkE_fEduE1dJ2XtzzkQ" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWLqSE9HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_-uRRkU_fEduE1dJ2XtzzkQ" name="stakeholder" guid="_-uRRkU_fEduE1dJ2XtzzkQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_-uRRkk_fEduE1dJ2XtzzkQ" name="tester" guid="_-uRRkk_fEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWLqTU9HEdudU75l2xOQTw _MWLqRk9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <diagrams xmi:id="_MWLqT09HEdudU75l2xOQTw" guid="_MWLqT09HEdudU75l2xOQTw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqUE9HEdudU75l2xOQTw" guid="_MWLqUE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM8E9HEdudU75l2xOQTw" x="168.0" y="12.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqUU9HEdudU75l2xOQTw" guid="_MWLqUU9HEdudU75l2xOQTw" anchor="_MWLqU09HEdudU75l2xOQTw _MWLqWE9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqUk9HEdudU75l2xOQTw" guid="_MWLqUk9HEdudU75l2xOQTw" element="_MWLqS09HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_MWLqU09HEdudU75l2xOQTw" guid="_MWLqU09HEdudU75l2xOQTw" graphEdge="_MWLqUU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqVE9HEdudU75l2xOQTw" guid="_MWLqVE9HEdudU75l2xOQTw" graphEdge="_MWLqck9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqVU9HEdudU75l2xOQTw" guid="_MWLqVU9HEdudU75l2xOQTw" element="_MWLqSU9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM8U9HEdudU75l2xOQTw" width="112.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqVk9HEdudU75l2xOQTw" guid="_MWLqVk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM8k9HEdudU75l2xOQTw" x="178.0" y="99.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqV09HEdudU75l2xOQTw" guid="_MWLqV09HEdudU75l2xOQTw" anchor="_MWLqWk9HEdudU75l2xOQTw _MWLqmk9HEdudU75l2xOQTw">
+ <waypoints xmi:id="_MXDM809HEdudU75l2xOQTw" x="223.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_MWLqWE9HEdudU75l2xOQTw" guid="_MWLqWE9HEdudU75l2xOQTw" graphEdge="_MWLqUU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqWU9HEdudU75l2xOQTw" guid="_MWLqWU9HEdudU75l2xOQTw" graphEdge="_MWLqeE9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqWk9HEdudU75l2xOQTw" guid="_MWLqWk9HEdudU75l2xOQTw" graphEdge="_MWLqV09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM9E9HEdudU75l2xOQTw" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqW09HEdudU75l2xOQTw" guid="_MWLqW09HEdudU75l2xOQTw" element="_MWLqQE9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM9U9HEdudU75l2xOQTw" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqXE9HEdudU75l2xOQTw" guid="_MWLqXE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM9k9HEdudU75l2xOQTw" x="28.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqXU9HEdudU75l2xOQTw" guid="_MWLqXU9HEdudU75l2xOQTw" anchor="_MWLqX09HEdudU75l2xOQTw _MWLqkU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqXk9HEdudU75l2xOQTw" guid="_MWLqXk9HEdudU75l2xOQTw" graphEdge="_MWLqhk9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqX09HEdudU75l2xOQTw" guid="_MWLqX09HEdudU75l2xOQTw" graphEdge="_MWLqXU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM909HEdudU75l2xOQTw" x="101.0" y="286.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqYE9HEdudU75l2xOQTw" guid="_MWLqYE9HEdudU75l2xOQTw" element="_MWLqRE9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM-E9HEdudU75l2xOQTw" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqYU9HEdudU75l2xOQTw" guid="_MWLqYU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM-U9HEdudU75l2xOQTw" x="179.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqYk9HEdudU75l2xOQTw" guid="_MWLqYk9HEdudU75l2xOQTw" anchor="_MWLqZU9HEdudU75l2xOQTw _MWLqak9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqY09HEdudU75l2xOQTw" guid="_MWLqY09HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_MWLqZE9HEdudU75l2xOQTw" guid="_MWLqZE9HEdudU75l2xOQTw" graphEdge="_MWLqhU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqZU9HEdudU75l2xOQTw" guid="_MWLqZU9HEdudU75l2xOQTw" graphEdge="_MWLqYk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM-k9HEdudU75l2xOQTw" x="239.0" y="284.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqZk9HEdudU75l2xOQTw" guid="_MWLqZk9HEdudU75l2xOQTw" element="_MWLqQ09HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM-09HEdudU75l2xOQTw" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqZ09HEdudU75l2xOQTw" guid="_MWLqZ09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM_E9HEdudU75l2xOQTw" x="191.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqaE9HEdudU75l2xOQTw" guid="_MWLqaE9HEdudU75l2xOQTw" anchor="_MWLqaU9HEdudU75l2xOQTw _MWLqkk9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqaU9HEdudU75l2xOQTw" guid="_MWLqaU9HEdudU75l2xOQTw" graphEdge="_MWLqaE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM_U9HEdudU75l2xOQTw" x="374.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqak9HEdudU75l2xOQTw" guid="_MWLqak9HEdudU75l2xOQTw" graphEdge="_MWLqYk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM_k9HEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqa09HEdudU75l2xOQTw" guid="_MWLqa09HEdudU75l2xOQTw" element="_MWLqRU9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM_09HEdudU75l2xOQTw" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqbE9HEdudU75l2xOQTw" guid="_MWLqbE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNAE9HEdudU75l2xOQTw" x="24.0" y="31.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqbU9HEdudU75l2xOQTw" guid="_MWLqbU9HEdudU75l2xOQTw" anchor="_MWLqbk9HEdudU75l2xOQTw _MWLqc09HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqbk9HEdudU75l2xOQTw" guid="_MWLqbk9HEdudU75l2xOQTw" graphEdge="_MWLqbU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNAU9HEdudU75l2xOQTw" x="117.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqb09HEdudU75l2xOQTw" guid="_MWLqb09HEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_MXDNAk9HEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqcE9HEdudU75l2xOQTw" guid="_MWLqcE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNA09HEdudU75l2xOQTw" x="83.0" y="30.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqcU9HEdudU75l2xOQTw" guid="_MWLqcU9HEdudU75l2xOQTw" anchor="_MWLqdE9HEdudU75l2xOQTw _MWLqek9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqck9HEdudU75l2xOQTw" guid="_MWLqck9HEdudU75l2xOQTw" anchor="_MWLqdU9HEdudU75l2xOQTw _MWLqVE9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqc09HEdudU75l2xOQTw" guid="_MWLqc09HEdudU75l2xOQTw" graphEdge="_MWLqbU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNBE9HEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqdE9HEdudU75l2xOQTw" guid="_MWLqdE9HEdudU75l2xOQTw" graphEdge="_MWLqcU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNBU9HEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqdU9HEdudU75l2xOQTw" guid="_MWLqdU9HEdudU75l2xOQTw" graphEdge="_MWLqck9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNBk9HEdudU75l2xOQTw" x="23.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqdk9HEdudU75l2xOQTw" guid="_MWLqdk9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_MXDNB09HEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqd09HEdudU75l2xOQTw" guid="_MWLqd09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNCE9HEdudU75l2xOQTw" x="83.0" y="110.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqeE9HEdudU75l2xOQTw" guid="_MWLqeE9HEdudU75l2xOQTw" anchor="_MWLqe09HEdudU75l2xOQTw _MWLqWU9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqeU9HEdudU75l2xOQTw" guid="_MWLqeU9HEdudU75l2xOQTw" anchor="_MWLqfE9HEdudU75l2xOQTw _MWLqm09HEdudU75l2xOQTw">
+ <waypoints xmi:id="_MXDNCU9HEdudU75l2xOQTw" x="94.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_MWLqek9HEdudU75l2xOQTw" guid="_MWLqek9HEdudU75l2xOQTw" graphEdge="_MWLqcU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNCk9HEdudU75l2xOQTw" x="11.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqe09HEdudU75l2xOQTw" guid="_MWLqe09HEdudU75l2xOQTw" graphEdge="_MWLqeE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNC09HEdudU75l2xOQTw" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqfE9HEdudU75l2xOQTw" guid="_MWLqfE9HEdudU75l2xOQTw" graphEdge="_MWLqeU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNDE9HEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqfU9HEdudU75l2xOQTw" guid="_MWLqfU9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_MXDNDU9HEdudU75l2xOQTw" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqfk9HEdudU75l2xOQTw" name="Add Free Text" guid="_MWLqfk9HEdudU75l2xOQTw">
+ <property xmi:id="_MWLqf09HEdudU75l2xOQTw" guid="_MWLqf09HEdudU75l2xOQTw" key="free text" value="[major change]"/>
+ <position xmi:id="_MXDNDk9HEdudU75l2xOQTw" x="107.0" y="25.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqgE9HEdudU75l2xOQTw" guid="_MWLqgE9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_MXDND09HEdudU75l2xOQTw" width="71.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqgU9HEdudU75l2xOQTw" name="Add Free Text" guid="_MWLqgU9HEdudU75l2xOQTw">
+ <property xmi:id="_MWLqgk9HEdudU75l2xOQTw" guid="_MWLqgk9HEdudU75l2xOQTw" key="free text" value="[small change]"/>
+ <position xmi:id="_MXDNEE9HEdudU75l2xOQTw" x="106.0" y="105.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqg09HEdudU75l2xOQTw" guid="_MWLqg09HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_MXDNEU9HEdudU75l2xOQTw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqhE9HEdudU75l2xOQTw" guid="_MWLqhE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNEk9HEdudU75l2xOQTw" x="42.0" y="232.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqhU9HEdudU75l2xOQTw" guid="_MWLqhU9HEdudU75l2xOQTw" anchor="_MWLqiE9HEdudU75l2xOQTw _MWLqZE9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqhk9HEdudU75l2xOQTw" guid="_MWLqhk9HEdudU75l2xOQTw" anchor="_MWLqiU9HEdudU75l2xOQTw _MWLqXk9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqh09HEdudU75l2xOQTw" guid="_MWLqh09HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_MWLqiE9HEdudU75l2xOQTw" guid="_MWLqiE9HEdudU75l2xOQTw" graphEdge="_MWLqhU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNE09HEdudU75l2xOQTw" x="201.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqiU9HEdudU75l2xOQTw" guid="_MWLqiU9HEdudU75l2xOQTw" graphEdge="_MWLqhk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNFE9HEdudU75l2xOQTw" x="38.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqik9HEdudU75l2xOQTw" guid="_MWLqik9HEdudU75l2xOQTw" graphEdge="_MWLqmU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNFU9HEdudU75l2xOQTw" x="116.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqi09HEdudU75l2xOQTw" guid="_MWLqi09HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_MXDNFk9HEdudU75l2xOQTw" width="262.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqjE9HEdudU75l2xOQTw" name="Add Free Text" guid="_MWLqjE9HEdudU75l2xOQTw">
+ <property xmi:id="_MWLqjU9HEdudU75l2xOQTw" guid="_MWLqjU9HEdudU75l2xOQTw" key="free text" value="[trivial change]"/>
+ <position xmi:id="_MXDNF09HEdudU75l2xOQTw" x="98.0" y="153.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqjk9HEdudU75l2xOQTw" guid="_MWLqjk9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_MXDNGE9HEdudU75l2xOQTw" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqj09HEdudU75l2xOQTw" guid="_MWLqj09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNGU9HEdudU75l2xOQTw" x="42.0" y="382.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqkE9HEdudU75l2xOQTw" guid="_MWLqkE9HEdudU75l2xOQTw" anchor="_MWLqk09HEdudU75l2xOQTw _MWLqlk9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqkU9HEdudU75l2xOQTw" guid="_MWLqkU9HEdudU75l2xOQTw" graphEdge="_MWLqXU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNGk9HEdudU75l2xOQTw" x="39.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqkk9HEdudU75l2xOQTw" guid="_MWLqkk9HEdudU75l2xOQTw" graphEdge="_MWLqaE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNG09HEdudU75l2xOQTw" x="199.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqk09HEdudU75l2xOQTw" guid="_MWLqk09HEdudU75l2xOQTw" graphEdge="_MWLqkE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNHE9HEdudU75l2xOQTw" x="129.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqlE9HEdudU75l2xOQTw" guid="_MWLqlE9HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_MXDNHU9HEdudU75l2xOQTw" width="274.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqlU9HEdudU75l2xOQTw" guid="_MWLqlU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNHk9HEdudU75l2xOQTw" x="160.0" y="410.0"/>
+ <anchorage xmi:id="_MWLqlk9HEdudU75l2xOQTw" guid="_MWLqlk9HEdudU75l2xOQTw" graphEdge="_MWLqkE9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLql09HEdudU75l2xOQTw" guid="_MWLql09HEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_MXDNH09HEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqmE9HEdudU75l2xOQTw" guid="_MWLqmE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNIE9HEdudU75l2xOQTw" x="145.0" y="180.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqmU9HEdudU75l2xOQTw" guid="_MWLqmU9HEdudU75l2xOQTw" anchor="_MWLqnE9HEdudU75l2xOQTw _MWLqik9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqmk9HEdudU75l2xOQTw" guid="_MWLqmk9HEdudU75l2xOQTw" graphEdge="_MWLqV09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNIU9HEdudU75l2xOQTw" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqm09HEdudU75l2xOQTw" guid="_MWLqm09HEdudU75l2xOQTw" graphEdge="_MWLqeU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNIk9HEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqnE9HEdudU75l2xOQTw" guid="_MWLqnE9HEdudU75l2xOQTw" graphEdge="_MWLqmU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNI09HEdudU75l2xOQTw" x="13.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqnU9HEdudU75l2xOQTw" guid="_MWLqnU9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_MXDNJE9HEdudU75l2xOQTw" width="28.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqnk9HEdudU75l2xOQTw" guid="_MWLqnk9HEdudU75l2xOQTw" presentation="Workflow" element="_MWFjoU9HEdudU75l2xOQTw"/>
+ </diagrams>
+ </childPackages>
+ <diagrams xmi:id="_y-k0C-tQEdqc1LGhiSPqRg" guid="_y-k0C-tQEdqc1LGhiSPqRg">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0TutQEdqc1LGhiSPqRg" guid="_y-k0TutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1NutQEdqc1LGhiSPqRg" x="334.0" y="79.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0UetQEdqc1LGhiSPqRg" guid="_y-k0UetQEdqc1LGhiSPqRg" anchor="_y-k0UutQEdqc1LGhiSPqRg _y-k0YutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0UOtQEdqc1LGhiSPqRg" guid="_y-k0UOtQEdqc1LGhiSPqRg" graphEdge="_y-k0I-tQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0UutQEdqc1LGhiSPqRg" guid="_y-k0UutQEdqc1LGhiSPqRg" graphEdge="_y-k0UetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1N-tQEdqc1LGhiSPqRg" x="488.0" y="118.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0T-tQEdqc1LGhiSPqRg" guid="_y-k0T-tQEdqc1LGhiSPqRg" element="_y-k0bOtQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1OOtQEdqc1LGhiSPqRg" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0WOtQEdqc1LGhiSPqRg" guid="_y-k0WOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1OetQEdqc1LGhiSPqRg" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0WetQEdqc1LGhiSPqRg" guid="_y-k0WetQEdqc1LGhiSPqRg" anchor="_y-k0WutQEdqc1LGhiSPqRg _y-k0YetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0WutQEdqc1LGhiSPqRg" guid="_y-k0WutQEdqc1LGhiSPqRg" graphEdge="_y-k0WetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1OutQEdqc1LGhiSPqRg" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0W-tQEdqc1LGhiSPqRg" guid="_y-k0W-tQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1O-tQEdqc1LGhiSPqRg" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0U-tQEdqc1LGhiSPqRg" guid="_y-k0U-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1POtQEdqc1LGhiSPqRg" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0VOtQEdqc1LGhiSPqRg" guid="_y-k0VOtQEdqc1LGhiSPqRg" anchor="_y-k0V-tQEdqc1LGhiSPqRg _y-k0QetQEdqc1LGhiSPqRg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0VetQEdqc1LGhiSPqRg" guid="_y-k0VetQEdqc1LGhiSPqRg"/>
+ </contained>
+ <anchorage xmi:id="_y-k0V-tQEdqc1LGhiSPqRg" guid="_y-k0V-tQEdqc1LGhiSPqRg" graphEdge="_y-k0VOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1PetQEdqc1LGhiSPqRg" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0VutQEdqc1LGhiSPqRg" guid="_y-k0VutQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1PutQEdqc1LGhiSPqRg" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0PutQEdqc1LGhiSPqRg" guid="_y-k0PutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1P-tQEdqc1LGhiSPqRg" x="245.0" y="215.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0QutQEdqc1LGhiSPqRg" guid="_y-k0QutQEdqc1LGhiSPqRg" anchor="_y-k0P-tQEdqc1LGhiSPqRg _y-k0XetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0QetQEdqc1LGhiSPqRg" guid="_y-k0QetQEdqc1LGhiSPqRg" graphEdge="_y-k0VOtQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0QOtQEdqc1LGhiSPqRg" guid="_y-k0QOtQEdqc1LGhiSPqRg" graphEdge="_y-k0JetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0P-tQEdqc1LGhiSPqRg" guid="_y-k0P-tQEdqc1LGhiSPqRg" graphEdge="_y-k0QutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1QOtQEdqc1LGhiSPqRg" x="568.0" y="250.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0Q-tQEdqc1LGhiSPqRg" guid="_y-k0Q-tQEdqc1LGhiSPqRg" element="_y-3IretQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1QetQEdqc1LGhiSPqRg" width="96.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0FutQEdqc1LGhiSPqRg" guid="_y-k0FutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1QutQEdqc1LGhiSPqRg" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0GetQEdqc1LGhiSPqRg" guid="_y-k0GetQEdqc1LGhiSPqRg" anchor="_y-k0F-tQEdqc1LGhiSPqRg _y-k0ZutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0F-tQEdqc1LGhiSPqRg" guid="_y-k0F-tQEdqc1LGhiSPqRg" graphEdge="_y-k0GetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1Q-tQEdqc1LGhiSPqRg" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0GOtQEdqc1LGhiSPqRg" guid="_y-k0GOtQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1ROtQEdqc1LGhiSPqRg" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0MutQEdqc1LGhiSPqRg" guid="_y-k0MutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1RetQEdqc1LGhiSPqRg" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0M-tQEdqc1LGhiSPqRg" guid="_y-k0M-tQEdqc1LGhiSPqRg" anchor="_y-k0NOtQEdqc1LGhiSPqRg _y-k0Y-tQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0NutQEdqc1LGhiSPqRg" guid="_y-k0NutQEdqc1LGhiSPqRg" graphEdge="_y-k0IutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0NOtQEdqc1LGhiSPqRg" guid="_y-k0NOtQEdqc1LGhiSPqRg" graphEdge="_y-k0M-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1RutQEdqc1LGhiSPqRg" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0NetQEdqc1LGhiSPqRg" guid="_y-k0NetQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1R-tQEdqc1LGhiSPqRg" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0N-tQEdqc1LGhiSPqRg" guid="_y-k0N-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1SOtQEdqc1LGhiSPqRg" x="306.0" y="10.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0OutQEdqc1LGhiSPqRg" guid="_y-k0OutQEdqc1LGhiSPqRg" anchor="_y-k0OetQEdqc1LGhiSPqRg _y-k0HutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0OetQEdqc1LGhiSPqRg" guid="_y-k0OetQEdqc1LGhiSPqRg" graphEdge="_y-k0OutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1SetQEdqc1LGhiSPqRg" x="10.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0OOtQEdqc1LGhiSPqRg" guid="_y-k0OOtQEdqc1LGhiSPqRg" typeInfo="start node"/>
+ <size xmi:id="_z8f1SutQEdqc1LGhiSPqRg" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0O-tQEdqc1LGhiSPqRg" guid="_y-k0O-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1S-tQEdqc1LGhiSPqRg" x="298.0" y="354.0"/>
+ <anchorage xmi:id="_y-k0PetQEdqc1LGhiSPqRg" guid="_y-k0PetQEdqc1LGhiSPqRg" graphEdge="_y-k0aetQEdqc1LGhiSPqRg"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0POtQEdqc1LGhiSPqRg" guid="_y-k0POtQEdqc1LGhiSPqRg" typeInfo="end node"/>
+ <size xmi:id="_z8f1TOtQEdqc1LGhiSPqRg" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0GutQEdqc1LGhiSPqRg" guid="_y-k0GutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1TetQEdqc1LGhiSPqRg" x="42.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0KOtQEdqc1LGhiSPqRg" guid="_y-k0KOtQEdqc1LGhiSPqRg" anchor="_y-k0H-tQEdqc1LGhiSPqRg _y-k0TetQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0HetQEdqc1LGhiSPqRg" guid="_y-k0HetQEdqc1LGhiSPqRg" anchor="_y-k0K-tQEdqc1LGhiSPqRg _y-k0L-tQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0G-tQEdqc1LGhiSPqRg" guid="_y-k0G-tQEdqc1LGhiSPqRg" anchor="_y-k0KutQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0IOtQEdqc1LGhiSPqRg" guid="_y-k0IOtQEdqc1LGhiSPqRg" anchor="_y-k0JutQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0KetQEdqc1LGhiSPqRg" guid="_y-k0KetQEdqc1LGhiSPqRg" anchor="_y-k0LOtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0JetQEdqc1LGhiSPqRg" guid="_y-k0JetQEdqc1LGhiSPqRg" anchor="_y-k0HOtQEdqc1LGhiSPqRg _y-k0QOtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0I-tQEdqc1LGhiSPqRg" guid="_y-k0I-tQEdqc1LGhiSPqRg" anchor="_y-k0JOtQEdqc1LGhiSPqRg _y-k0UOtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0IutQEdqc1LGhiSPqRg" guid="_y-k0IutQEdqc1LGhiSPqRg" anchor="_y-k0J-tQEdqc1LGhiSPqRg _y-k0NutQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__jK84etQEdqc1LGhiSPqRg" guid="__jK84etQEdqc1LGhiSPqRg" anchor="__jK84OtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_p5fPcUbpEduLBN1xMBngqw" guid="_p5fPcUbpEduLBN1xMBngqw" anchor="_p5fPcEbpEduLBN1xMBngqw _p5fPckbpEduLBN1xMBngqw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_h3gEEUbrEduez5pdMGsX2w" guid="_h3gEEUbrEduez5pdMGsX2w" anchor="_h3gEEEbrEduez5pdMGsX2w"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_wm_J4U9HEdudU75l2xOQTw" guid="_wm_J4U9HEdudU75l2xOQTw" anchor="_wm_J4E9HEdudU75l2xOQTw _wm_J4k9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_y-k0HutQEdqc1LGhiSPqRg" guid="_y-k0HutQEdqc1LGhiSPqRg" graphEdge="_y-k0OutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1TutQEdqc1LGhiSPqRg" x="273.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0H-tQEdqc1LGhiSPqRg" guid="_y-k0H-tQEdqc1LGhiSPqRg" graphEdge="_y-k0KOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1T-tQEdqc1LGhiSPqRg" x="477.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0K-tQEdqc1LGhiSPqRg" guid="_y-k0K-tQEdqc1LGhiSPqRg" graphEdge="_y-k0HetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1UOtQEdqc1LGhiSPqRg" x="162.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0KutQEdqc1LGhiSPqRg" guid="_y-k0KutQEdqc1LGhiSPqRg" graphEdge="_y-k0G-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1UetQEdqc1LGhiSPqRg" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0JutQEdqc1LGhiSPqRg" guid="_y-k0JutQEdqc1LGhiSPqRg" graphEdge="_y-k0IOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1UutQEdqc1LGhiSPqRg" x="101.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0LOtQEdqc1LGhiSPqRg" guid="_y-k0LOtQEdqc1LGhiSPqRg" graphEdge="_y-k0KetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1U-tQEdqc1LGhiSPqRg" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0HOtQEdqc1LGhiSPqRg" guid="_y-k0HOtQEdqc1LGhiSPqRg" graphEdge="_y-k0JetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1VOtQEdqc1LGhiSPqRg" x="251.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0JOtQEdqc1LGhiSPqRg" guid="_y-k0JOtQEdqc1LGhiSPqRg" graphEdge="_y-k0I-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1VetQEdqc1LGhiSPqRg" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0J-tQEdqc1LGhiSPqRg" guid="_y-k0J-tQEdqc1LGhiSPqRg" graphEdge="_y-k0IutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1VutQEdqc1LGhiSPqRg" x="393.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="__jK84OtQEdqc1LGhiSPqRg" guid="__jK84OtQEdqc1LGhiSPqRg" graphEdge="__jK84etQEdqc1LGhiSPqRg">
+ <position xmi:id="__jK84-tQEdqc1LGhiSPqRg" x="407.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_p5fPcEbpEduLBN1xMBngqw" guid="_p5fPcEbpEduLBN1xMBngqw" graphEdge="_p5fPcUbpEduLBN1xMBngqw">
+ <position xmi:id="_swYkEEbpEduLBN1xMBngqw" x="59.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_h3gEEEbrEduez5pdMGsX2w" guid="_h3gEEEbrEduez5pdMGsX2w" graphEdge="_h3gEEUbrEduez5pdMGsX2w">
+ <position xmi:id="_h3gEE0brEduez5pdMGsX2w" x="159.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wm_J4E9HEdudU75l2xOQTw" guid="_wm_J4E9HEdudU75l2xOQTw" graphEdge="_wm_J4U9HEdudU75l2xOQTw">
+ <position xmi:id="_wm_J409HEdudU75l2xOQTw" x="151.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0IetQEdqc1LGhiSPqRg" guid="_y-k0IetQEdqc1LGhiSPqRg" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z8f1V-tQEdqc1LGhiSPqRg" width="523.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0XOtQEdqc1LGhiSPqRg" guid="_y-k0XOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1WOtQEdqc1LGhiSPqRg" x="47.0" y="313.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0aetQEdqc1LGhiSPqRg" guid="_y-k0aetQEdqc1LGhiSPqRg" anchor="_y-k0YOtQEdqc1LGhiSPqRg _y-k0PetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0YetQEdqc1LGhiSPqRg" guid="_y-k0YetQEdqc1LGhiSPqRg" graphEdge="_y-k0WetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1WetQEdqc1LGhiSPqRg" x="148.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0ZutQEdqc1LGhiSPqRg" guid="_y-k0ZutQEdqc1LGhiSPqRg" graphEdge="_y-k0GetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1WutQEdqc1LGhiSPqRg" x="542.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0X-tQEdqc1LGhiSPqRg" guid="_y-k0X-tQEdqc1LGhiSPqRg" graphEdge="_y-k0S-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1W-tQEdqc1LGhiSPqRg" x="472.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0XutQEdqc1LGhiSPqRg" guid="_y-k0XutQEdqc1LGhiSPqRg" graphEdge="_y-k0MOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1XOtQEdqc1LGhiSPqRg" x="151.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0ZOtQEdqc1LGhiSPqRg" guid="_y-k0ZOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1XetQEdqc1LGhiSPqRg" x="16.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0Z-tQEdqc1LGhiSPqRg" guid="_y-k0Z-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1XutQEdqc1LGhiSPqRg" x="95.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0aOtQEdqc1LGhiSPqRg" guid="_y-k0aOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_KCFy0OtREdqc1LGhiSPqRg" x="170.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0XetQEdqc1LGhiSPqRg" guid="_y-k0XetQEdqc1LGhiSPqRg" graphEdge="_y-k0QutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1YOtQEdqc1LGhiSPqRg" x="246.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0YutQEdqc1LGhiSPqRg" guid="_y-k0YutQEdqc1LGhiSPqRg" graphEdge="_y-k0UetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1YetQEdqc1LGhiSPqRg" x="328.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0Y-tQEdqc1LGhiSPqRg" guid="_y-k0Y-tQEdqc1LGhiSPqRg" graphEdge="_y-k0M-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1YutQEdqc1LGhiSPqRg" x="387.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0YOtQEdqc1LGhiSPqRg" guid="_y-k0YOtQEdqc1LGhiSPqRg" graphEdge="_y-k0aetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1Y-tQEdqc1LGhiSPqRg" x="262.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_A0fa0utREdqc1LGhiSPqRg" guid="_A0fa0utREdqc1LGhiSPqRg">
+ <position xmi:id="_A0fa1OtREdqc1LGhiSPqRg" x="403.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_qsrm8kbpEduLBN1xMBngqw" guid="_qsrm8kbpEduLBN1xMBngqw" graphEdge="_qsrm8UbpEduLBN1xMBngqw">
+ <position xmi:id="_qsrm9EbpEduLBN1xMBngqw" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_jQOKgkbrEduez5pdMGsX2w" guid="_jQOKgkbrEduez5pdMGsX2w">
+ <position xmi:id="_jQOKhEbrEduez5pdMGsX2w" x="154.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_yEykok9HEdudU75l2xOQTw" guid="_yEykok9HEdudU75l2xOQTw" graphEdge="_yEykoU9HEdudU75l2xOQTw">
+ <position xmi:id="_0v9xcE9HEdudU75l2xOQTw" x="146.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0ZetQEdqc1LGhiSPqRg" guid="_y-k0ZetQEdqc1LGhiSPqRg" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z8f1ZOtQEdqc1LGhiSPqRg" width="509.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0SetQEdqc1LGhiSPqRg" guid="_y-k0SetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1aOtQEdqc1LGhiSPqRg" x="477.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0S-tQEdqc1LGhiSPqRg" guid="_y-k0S-tQEdqc1LGhiSPqRg" anchor="_y-k0SutQEdqc1LGhiSPqRg _y-k0X-tQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0TetQEdqc1LGhiSPqRg" guid="_y-k0TetQEdqc1LGhiSPqRg" graphEdge="_y-k0KOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1aetQEdqc1LGhiSPqRg" x="38.0" y="-91.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0SutQEdqc1LGhiSPqRg" guid="_y-k0SutQEdqc1LGhiSPqRg" graphEdge="_y-k0S-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1autQEdqc1LGhiSPqRg" x="-28.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0TOtQEdqc1LGhiSPqRg" guid="_y-k0TOtQEdqc1LGhiSPqRg" element="_y_PjTOtQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1a-tQEdqc1LGhiSPqRg" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0LetQEdqc1LGhiSPqRg" guid="_y-k0LetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1bOtQEdqc1LGhiSPqRg" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0MOtQEdqc1LGhiSPqRg" guid="_y-k0MOtQEdqc1LGhiSPqRg" anchor="_y-k0MetQEdqc1LGhiSPqRg _y-k0XutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0L-tQEdqc1LGhiSPqRg" guid="_y-k0L-tQEdqc1LGhiSPqRg" graphEdge="_y-k0HetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1betQEdqc1LGhiSPqRg" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0MetQEdqc1LGhiSPqRg" guid="_y-k0MetQEdqc1LGhiSPqRg" graphEdge="_y-k0MOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1butQEdqc1LGhiSPqRg" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0LutQEdqc1LGhiSPqRg" guid="_y-k0LutQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1b-tQEdqc1LGhiSPqRg" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kEWoEEbpEduLBN1xMBngqw" guid="_kEWoEEbpEduLBN1xMBngqw">
+ <position xmi:id="_kEWoEUbpEduLBN1xMBngqw" x="48.0" y="77.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_qsrm8UbpEduLBN1xMBngqw" guid="_qsrm8UbpEduLBN1xMBngqw" anchor="_qsrm8EbpEduLBN1xMBngqw _qsrm8kbpEduLBN1xMBngqw"/>
+ <anchorage xmi:id="_p5fPckbpEduLBN1xMBngqw" guid="_p5fPckbpEduLBN1xMBngqw" graphEdge="_p5fPcUbpEduLBN1xMBngqw"/>
+ <anchorage xmi:id="_qsrm8EbpEduLBN1xMBngqw" guid="_qsrm8EbpEduLBN1xMBngqw" graphEdge="_qsrm8UbpEduLBN1xMBngqw">
+ <position xmi:id="_qsrm80bpEduLBN1xMBngqw" x="101.0" y="93.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kEWoEkbpEduLBN1xMBngqw" guid="_kEWoEkbpEduLBN1xMBngqw" element="_eE5nEUbpEduLBN1xMBngqw"/>
+ <size xmi:id="_kEWoE0bpEduLBN1xMBngqw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_r4KqUE9HEdudU75l2xOQTw" guid="_r4KqUE9HEdudU75l2xOQTw">
+ <position xmi:id="_r4KqUU9HEdudU75l2xOQTw" x="144.0" y="158.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_yEykoU9HEdudU75l2xOQTw" guid="_yEykoU9HEdudU75l2xOQTw" anchor="_yEykoE9HEdudU75l2xOQTw _yEykok9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_wm_J4k9HEdudU75l2xOQTw" guid="_wm_J4k9HEdudU75l2xOQTw" graphEdge="_wm_J4U9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_yEykoE9HEdudU75l2xOQTw" guid="_yEykoE9HEdudU75l2xOQTw" graphEdge="_yEykoU9HEdudU75l2xOQTw">
+ <position xmi:id="_yEyko09HEdudU75l2xOQTw" x="193.0" y="179.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_r4KqUk9HEdudU75l2xOQTw" guid="_r4KqUk9HEdudU75l2xOQTw" element="_MWFjoU9HEdudU75l2xOQTw"/>
+ <size xmi:id="_r4KqU09HEdudU75l2xOQTw" width="98.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0autQEdqc1LGhiSPqRg" guid="_y-k0autQEdqc1LGhiSPqRg" presentation="Workflow" element="_y-3IrutQEdqc1LGhiSPqRg"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_y-3IrutQEdqc1LGhiSPqRg" name="construction_phase_iteration" guid="_y-3IrutQEdqc1LGhiSPqRg" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Construction phase. Each activity and its goals is described." presentationName="Construction Phase Iteration" isRepeatable="true" breakdownElements="_y-k0bOtQEdqc1LGhiSPqRg _eE5nEUbpEduLBN1xMBngqw _MWFjoU9HEdudU75l2xOQTw _y-3IretQEdqc1LGhiSPqRg _y_PjTOtQEdqc1LGhiSPqRg">
+ <ownedRules xmi:id="_y-3Ir-tQEdqc1LGhiSPqRg" guid="_y-3Ir-tQEdqc1LGhiSPqRg"/>
+ <presentation xmi:id="-239OBD2wagT2qp8fuPWcHQ" href="uma://-OC3td1csl7lqV15vimYOaw#-239OBD2wagT2qp8fuPWcHQ"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/define_architecture/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/define_architecture/content.xmi
new file mode 100644
index 0000000..1d8755f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/define_architecture/content.xmi
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb_DvL5Edm6Nvont3uinw" guid="_mtb_DvL5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity is repeated in each iteration in the Elaboration phase. The main&nbsp;goal of this activity is&nbsp;to
+ propose an <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> that addresses the requirements with high architectural risks, thus
+ providing a solid, yet resilient, foundation on which to build the system functionality.
+</p>
+<p>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> analyzes the architectural constraints, identifies available assets to
+ build the system, defines how the system will be structured, and identifies the initial abstractions and mechanisms
+ that must be provided by the architecture.
+</p>
+<p>
+ Throughout all of the iterations, the architect:
+</p>
+<ul>
+ <li>
+ Identifies commonalities between different requirements to leverage reuse
+ </li>
+ <li>
+ Defines strategies for achieving requirements related to quality
+ </li>
+ <li>
+ Captures and communicates architectural decisions
+ </li>
+</ul></mainDescription>
+ <howtoStaff><p>
+ These activities are best carried out by a small team staffed by cross-functional team members. Issues that are
+ typically architecturally significant include usability, performance, scaling, process and thread synchronization, and
+ distribution. The team should also include members with domain experience who can identify key abstractions. The team
+ should also have experience with model organization and layering. The team will need to be able to pull all these
+ disparate threads into a cohesive, coherent (albeit preliminary) architecture.
+</p>
+<p>
+ Because the focus of the architecture effort is shifting toward implementation issues, greater attention needs to be
+ paid to specific technology issues. This will force the architecture team to shift members or expand to include people
+ with distribution and deployment expertise (if those issues are architecturally significant). In order to understand
+ the potential impact of the structure on the implementation model on the ease of integration, expertise in the software
+ build management process is useful to have.
+</p>
+<p>
+ At the same time, it is essential that the architecture team not be composed of a large extended team. A strategy for
+ countering this trend is to retain a relatively small core team with a satellite group of extended team members that
+ are brought in as "consultants" on key issues<b>.</b> This structure also works well for smaller projects where
+ specific expertise may be borrowed or contracted from other organizations; they can be brought in as specific issues
+ need to be addressed.
+</p></howtoStaff>
+ <usageNotes><p>
+ The work is best done in several sessions, perhaps performed over a few days (or weeks and months for very large
+ systems). The initial focus will be on the identifying <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Concept: Design Mechanism</a>s&nbsp;and&nbsp;specifiying the&nbsp;important&nbsp;design
+ elements.&nbsp;Care should also be taken to incorporate existing design elements to ensure that new&nbsp;design do not
+ duplicate existing functionality.
+</p>
+<p>
+ As the design emerges, concurrency and distribution issues are introduced. As these issues are considered, changes to
+ design elements may be required to split behavior across processes, threads or nodes.
+</p>
+<p>
+ As the individual models are refined to incorporate the architectural decisions, the results are documented in the
+ Architecture description. The resulting architecture is reviewed.
+</p></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/define_architecture/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/define_architecture/model.xmi
new file mode 100644
index 0000000..c4397f9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/define_architecture/model.xmi
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nLga8vL5Edm6Nvont3uinw" guid="_nLga8vL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nLga8fL5Edm6Nvont3uinw" id="_mtb_DvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0sx7iclgEdmt3adZL5Dmdw" name="define_architecture" guid="_0sx7iclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_d5-nQFY4EdqI9sTOt2pjHw" name="architect" guid="_d5-nQFY4EdqI9sTOt2pjHw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw" responsibleFor="_d6Q7IVY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_d6Q7IVY4EdqI9sTOt2pjHw" name="architecture" guid="_d6Q7IVY4EdqI9sTOt2pjHw" presentationName="Architecture" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_ukbHgL-EEdqb7N6KIeDL8Q" name="analyze_arch_reqs" guid="_ukbHgL-EEdqb7N6KIeDL8Q" presentationName="Analyze the Architectural Requirements" superActivities="_0sx7islgEdmt3adZL5Dmdw" additionallyPerformedBy="_ezOKIE9DEdudU75l2xOQTw _ezOKIU9DEdudU75l2xOQTw _HTBBME_dEduE1dJ2XtzzkQ _HTBBMU_dEduE1dJ2XtzzkQ _r1QxIDeqEduCsbgJNeFsSw" mandatoryInput="_VZk0YxeDEduXJrZWmtC8tg _VZk0ZBeDEduXJrZWmtC8tg _r1Xe0DeqEduCsbgJNeFsSw" optionalInput="_uknUwb-EEdqb7N6KIeDL8Q _d6Q7IVY4EdqI9sTOt2pjHw _ezOKIk9DEdudU75l2xOQTw _uknUwL-EEdqb7N6KIeDL8Q" output="_d6Q7IVY4EdqI9sTOt2pjHw _uknUwb-EEdqb7N6KIeDL8Q" performedPrimarilyBy="_d5-nQFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0f-1oMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_3nMQQA3rEduibvKwrGxWxA"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_9o6Z4CSCEdqDjNgZyGMf5w"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_B899cMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_FVrlsMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_tmvWwE5cEducxZ_XZXh-vw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_I32E4MP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_KBAsYMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_xTdYACGAEdqk6N_Ot_YEvA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_uknUwL-EEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_uknUwL-EEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_uknUwb-EEdqb7N6KIeDL8Q" name="design" guid="_uknUwb-EEdqb7N6KIeDL8Q" presentationName="Design" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_vAmGIL-EEdqb7N6KIeDL8Q" name="develop_arch" guid="_vAmGIL-EEdqb7N6KIeDL8Q" presentationName="Develop the Architecture" superActivities="_0sx7islgEdmt3adZL5Dmdw" additionallyPerformedBy="_ezOKIE9DEdudU75l2xOQTw _HTBBMU_dEduE1dJ2XtzzkQ _r1QxIDeqEduCsbgJNeFsSw _ezOKIU9DEdudU75l2xOQTw _HTBBME_dEduE1dJ2XtzzkQ" mandatoryInput="_uknUwb-EEdqb7N6KIeDL8Q _d6Q7IVY4EdqI9sTOt2pjHw _uknUwL-EEdqb7N6KIeDL8Q _ezOKIk9DEdudU75l2xOQTw _VZk0ZBeDEduXJrZWmtC8tg _m_gdUMWrEduoutjwLchi0g" output="_uknUwb-EEdqb7N6KIeDL8Q _d6Q7IVY4EdqI9sTOt2pjHw" performedPrimarilyBy="_d5-nQFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0gRJgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_P28vkMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_0qoQ8CikEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_QtKuoCilEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Vdln8MP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_G_k1kBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_xIIVkMUbEdu5GrwIlTJV7g"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_LsyLkBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Zlw-QMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_aRCI0MP3EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_VZk0YxeDEduXJrZWmtC8tg" name="glossary" guid="_VZk0YxeDEduXJrZWmtC8tg" presentationName="Glossary" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_VZk0ZBeDEduXJrZWmtC8tg" name="vision" guid="_VZk0ZBeDEduXJrZWmtC8tg" presentationName="Vision" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_r1QxIDeqEduCsbgJNeFsSw" name="project_manager" guid="_r1QxIDeqEduCsbgJNeFsSw" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_r1Xe0DeqEduCsbgJNeFsSw" name="uc_model" guid="_r1Xe0DeqEduCsbgJNeFsSw" presentationName="Use-Case Model" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_ezOKIE9DEdudU75l2xOQTw" name="analyst" guid="_ezOKIE9DEdudU75l2xOQTw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw" responsibleFor="_r1Xe0DeqEduCsbgJNeFsSw _VZk0ZBeDEduXJrZWmtC8tg _VZk0YxeDEduXJrZWmtC8tg _uknUwL-EEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_ezOKIU9DEdudU75l2xOQTw" name="stakeholder" guid="_ezOKIU9DEdudU75l2xOQTw" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_ezOKIk9DEdudU75l2xOQTw" name="use_case" guid="_ezOKIk9DEdudU75l2xOQTw" presentationName="Use Case" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_HTBBME_dEduE1dJ2XtzzkQ" name="tester" guid="_HTBBME_dEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_HTBBMU_dEduE1dJ2XtzzkQ" name="developer" guid="_HTBBMU_dEduE1dJ2XtzzkQ" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw" responsibleFor="_m_gdUMWrEduoutjwLchi0g _uknUwb-EEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_m_gdUMWrEduoutjwLchi0g" name="build" guid="_m_gdUMWrEduoutjwLchi0g" presentationName="Build" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0sx7islgEdmt3adZL5Dmdw" name="define_architecture" guid="_0sx7islgEdmt3adZL5Dmdw" briefDescription="This activity completes the architecture for an iteration." presentationName="Define the Architecture" hasMultipleOccurrences="true" breakdownElements="_d5-nQFY4EdqI9sTOt2pjHw _d6Q7IVY4EdqI9sTOt2pjHw _ukbHgL-EEdqb7N6KIeDL8Q _uknUwL-EEdqb7N6KIeDL8Q _uknUwb-EEdqb7N6KIeDL8Q _vAmGIL-EEdqb7N6KIeDL8Q _VZk0YxeDEduXJrZWmtC8tg _VZk0ZBeDEduXJrZWmtC8tg _r1QxIDeqEduCsbgJNeFsSw _r1Xe0DeqEduCsbgJNeFsSw _ezOKIE9DEdudU75l2xOQTw _ezOKIU9DEdudU75l2xOQTw _ezOKIk9DEdudU75l2xOQTw _HTBBME_dEduE1dJ2XtzzkQ _HTBBMU_dEduE1dJ2XtzzkQ _m_gdUMWrEduoutjwLchi0g">
+ <presentation xmi:id="_mtb_DvL5Edm6Nvont3uinw" href="uma://_mtb_DvL5Edm6Nvont3uinw#_mtb_DvL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.xmi
new file mode 100644
index 0000000..99fd498
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.xmi
@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb_DfL5Edm6Nvont3uinw" guid="_mtb_DfL5Edm6Nvont3uinw">
+ <howtoStaff><p>
+ As with <a class="elementLinkWithType" href="./../../openup_basic/capabilitypatterns/define_architecture,_0rcewclgEdmt3adZL5Dmdw.html" guid="_0rcewclgEdmt3adZL5Dmdw">Activity: Define the Architecture</a>, this activity is best carried out by a small team
+ staffed by cross-functional team members. Issues that are typically architecturally significant include performance,
+ scaling, process and thread synchronization, and distribution. The team should also include members with domain
+ experience who can identify key abstractions. The team should also have experience with model organization and
+ layering. From these inputs, the team will need to be able to synthesize a model, or even a prototype, of a solution.
+</p></howtoStaff>
+ <usageNotes><p>
+ The major effort occurs early in the Inception phase; thereafter, the system should be assessed at&nbsp;every iteration
+ to ensure that the design is still on track with the architecture (see <a class="elementLinkWithType" href="./../../openup_basic/capabilitypatterns/manage_iteration,_0nJNkslgEdmt3adZL5Dmdw.html" guid="_0nJNkslgEdmt3adZL5Dmdw">Capability Pattern: Plan and Manage Iteration</a>).
+</p></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.xmi
new file mode 100644
index 0000000..ab78e76
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.xmi
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nKu-4vL5Edm6Nvont3uinw" guid="_nKu-4vL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nKu-4fL5Edm6Nvont3uinw" id="_mtb_DfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0sluQclgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0sluQclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_qQROgFY4EdqI9sTOt2pjHw" name="architect" guid="_qQROgFY4EdqI9sTOt2pjHw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw" responsibleFor="_qQppAFY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_qQjiYFY4EdqI9sTOt2pjHw" name="design" guid="_qQjiYFY4EdqI9sTOt2pjHw" presentationName="Design" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_qQppAFY4EdqI9sTOt2pjHw" name="architecture" guid="_qQppAFY4EdqI9sTOt2pjHw" presentationName="Architecture" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_qoEDcFY4EdqI9sTOt2pjHw" name="developer" guid="_qoEDcFY4EdqI9sTOt2pjHw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw" responsibleFor="_NXkrwsWpEduoutjwLchi0g _qQjiYFY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_lqOzsL-EEdqb7N6KIeDL8Q" name="analyze_arch_reqs" guid="_lqOzsL-EEdqb7N6KIeDL8Q" presentationName="Analyze the Architectural Requirements" superActivities="_0sluQslgEdmt3adZL5Dmdw" additionallyPerformedBy="_PJJ3AE_dEduE1dJ2XtzzkQ _PJJ3AU_dEduE1dJ2XtzzkQ _PJJ3Ak_dEduE1dJ2XtzzkQ _qoEDcFY4EdqI9sTOt2pjHw _PJJ3A0_dEduE1dJ2XtzzkQ" mandatoryInput="_g2XAwheDEduXJrZWmtC8tg _mKmV0L-EEdqb7N6KIeDL8Q _HTpzcDSLEdursMWmT1aZyw" optionalInput="_qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw _NXkrwcWpEduoutjwLchi0g _lqbA8L-EEdqb7N6KIeDL8Q" output="_qQppAFY4EdqI9sTOt2pjHw _qQjiYFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_qQROgFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0f-1oMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_3nMQQA3rEduibvKwrGxWxA"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_9o6Z4CSCEdqDjNgZyGMf5w"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_B899cMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_FVrlsMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_tmvWwE5cEducxZ_XZXh-vw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_I32E4MP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_KBAsYMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_xTdYACGAEdqk6N_Ot_YEvA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_lqbA8L-EEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_lqbA8L-EEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_mKmV0L-EEdqb7N6KIeDL8Q" name="vision" guid="_mKmV0L-EEdqb7N6KIeDL8Q" presentationName="Vision" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_g2XAwheDEduXJrZWmtC8tg" name="glossary" guid="_g2XAwheDEduXJrZWmtC8tg" presentationName="Glossary" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_HTpzcDSLEdursMWmT1aZyw" name="uc_model" guid="_HTpzcDSLEdursMWmT1aZyw" presentationName="Use-Case Model" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3AE_dEduE1dJ2XtzzkQ" name="analyst" guid="_PJJ3AE_dEduE1dJ2XtzzkQ" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw" responsibleFor="_HTpzcDSLEdursMWmT1aZyw _g2XAwheDEduXJrZWmtC8tg _mKmV0L-EEdqb7N6KIeDL8Q _lqbA8L-EEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3AU_dEduE1dJ2XtzzkQ" name="stakeholder" guid="_PJJ3AU_dEduE1dJ2XtzzkQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3Ak_dEduE1dJ2XtzzkQ" name="tester" guid="_PJJ3Ak_dEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3A0_dEduE1dJ2XtzzkQ" name="project_manager" guid="_PJJ3A0_dEduE1dJ2XtzzkQ" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_NXkrwMWpEduoutjwLchi0g" name="develop_arch" guid="_NXkrwMWpEduoutjwLchi0g" presentationName="Develop the Architecture" superActivities="_0sluQslgEdmt3adZL5Dmdw" additionallyPerformedBy="_PJJ3AE_dEduE1dJ2XtzzkQ _qoEDcFY4EdqI9sTOt2pjHw _PJJ3A0_dEduE1dJ2XtzzkQ _PJJ3AU_dEduE1dJ2XtzzkQ _PJJ3Ak_dEduE1dJ2XtzzkQ" mandatoryInput="_qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw _lqbA8L-EEdqb7N6KIeDL8Q _NXkrwcWpEduoutjwLchi0g _mKmV0L-EEdqb7N6KIeDL8Q _NXkrwsWpEduoutjwLchi0g" output="_qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_qQROgFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0gRJgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_P28vkMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_0qoQ8CikEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_QtKuoCilEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Vdln8MP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_G_k1kBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_xIIVkMUbEdu5GrwIlTJV7g"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_LsyLkBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Zlw-QMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_aRCI0MP3EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_NXkrwcWpEduoutjwLchi0g" name="use_case" guid="_NXkrwcWpEduoutjwLchi0g" presentationName="Use Case" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_NXkrwsWpEduoutjwLchi0g" name="build" guid="_NXkrwsWpEduoutjwLchi0g" presentationName="Build" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0sluQslgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0sluQslgEdmt3adZL5Dmdw" briefDescription="Confirm that the project is feasible by constructing an architectural proof-of-concept." presentationName="Determine Architectural Feasibility" breakdownElements="_qQROgFY4EdqI9sTOt2pjHw _qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw _qoEDcFY4EdqI9sTOt2pjHw _lqOzsL-EEdqb7N6KIeDL8Q _lqbA8L-EEdqb7N6KIeDL8Q _mKmV0L-EEdqb7N6KIeDL8Q _g2XAwheDEduXJrZWmtC8tg _HTpzcDSLEdursMWmT1aZyw _PJJ3AE_dEduE1dJ2XtzzkQ _PJJ3AU_dEduE1dJ2XtzzkQ _PJJ3Ak_dEduE1dJ2XtzzkQ _PJJ3A0_dEduE1dJ2XtzzkQ _NXkrwMWpEduoutjwLchi0g _NXkrwcWpEduoutjwLchi0g _NXkrwsWpEduoutjwLchi0g">
+ <presentation xmi:id="_mtb_DfL5Edm6Nvont3uinw" href="uma://_mtb_DfL5Edm6Nvont3uinw#_mtb_DfL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/develop_solution/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/develop_solution/content.xmi
new file mode 100644
index 0000000..92dc5a1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/develop_solution/content.xmi
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_h6zSEPimEdmugcVr9AdHjQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="_h6zSEPimEdmugcVr9AdHjQ" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
+ unit-tested, and&nbsp;integrated&nbsp;source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
+ or&nbsp;database access),&nbsp;on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
+ works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
+ happen, because they can happen in parallel.&nbsp;You may choose to create developer tests and run them before the actual
+ code is created or the reverse sequence.
+</p></mainDescription>
+ <purpose><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul></purpose>
+ <usageNotes><p>
+ This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
+ requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
+ be assigned to a developer, and it should be renamed to include the actual requirement name.&nbsp;Optionally, the word
+ <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
+</p>
+<blockquote>
+ <p align="left">
+ Develop requirement_name (within context_name context)
+ </p>
+</blockquote>
+<p>
+ If&nbsp;a context&nbsp;is specified, there will be one instance of this pattern for each requirement&nbsp;for each
+ context.
+</p>
+<blockquote>
+ <p>
+ <strong>Example</strong>
+ </p>
+ <ol>
+ <li>
+ Develop scenario 1 (within user interface context)
+ </li>
+ <li>
+ Develop scenario 1 (within business logic and DB access context)
+ </li>
+ <li>
+ Develop scenario 2
+ </li>
+ <li>
+ Develop supplemental requirement 1
+ </li>
+ </ol>
+</blockquote>
+<p>
+ Note that there are four instances of this pattern in the preceding example:
+</p>
+<ul>
+ <li>
+ The first two are related to the same requirement (scenario 1) but within two different contexts
+ </li>
+ <li>
+ The last two are related to different requirements, with no context specified.
+ </li>
+</ul></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/develop_solution/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/develop_solution/model.xmi
new file mode 100644
index 0000000..91010e4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/develop_solution/model.xmi
@@ -0,0 +1,264 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_h7wUUPimEdmugcVr9AdHjQ" guid="_h7wUUPimEdmugcVr9AdHjQ">
+ <resourceDescriptors xmi:id="_h72a8PimEdmugcVr9AdHjQ" id="_h6zSEPimEdmugcVr9AdHjQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_h2-iAPimEdmugcVr9AdHjQ" name="develop_solution" guid="_h2-iAPimEdmugcVr9AdHjQ">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_9kUSEFY4EdqI9sTOt2pjHw" name="developer" guid="_9kUSEFY4EdqI9sTOt2pjHw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_AdllQFY5EdqI9sTOt2pjHw _-Y3UcFY4EdqI9sTOt2pjHw _-YrHMFY4EdqI9sTOt2pjHw _9k_AcFY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_9k_AcFY4EdqI9sTOt2pjHw" name="design" guid="_9k_AcFY4EdqI9sTOt2pjHw" presentationName="Design" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_-YrHMFY4EdqI9sTOt2pjHw" name="implementation" guid="_-YrHMFY4EdqI9sTOt2pjHw" presentationName="Implementation" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YoQcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_-Y3UcFY4EdqI9sTOt2pjHw" name="developer_test" guid="_-Y3UcFY4EdqI9sTOt2pjHw" presentationName="Developer Test" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_AdllQFY5EdqI9sTOt2pjHw" name="build" guid="_AdllQFY5EdqI9sTOt2pjHw" presentationName="Build" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_cL1KIL-FEdqb7N6KIeDL8Q" name="design_solution" guid="_cL1KIL-FEdqb7N6KIeDL8Q" presentationName="Design the Solution" superActivities="_h2-iAfimEdmugcVr9AdHjQ" linkToPredecessor="_TiPK8DLwEdueZPye-FaNgA" additionallyPerformedBy="_rQ9xIMjkEdqIm8AJUZUQYg _KAnAYE9PEdumneEH4I4Yqg _BmbHQE_cEduE1dJ2XtzzkQ _BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_cMHeAL-FEdqb7N6KIeDL8Q _cMHeAb-FEdqb7N6KIeDL8Q _QN4E4ALlEduHjPEP_YPH-g" optionalInput="_9k_AcFY4EdqI9sTOt2pjHw" output="_9k_AcFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0fshwMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_4Z7WYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_--6tYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_A_LU8KuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_ENwJwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_KNZYAKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_OGYbwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_Ci7aYFixEdusJoWkvSRO9Q"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_9LeFME42EdudDeUNeAxPCQ"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_mUVt8BfnEduD353bkQ4frw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_cMHeAL-FEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_cMHeAL-FEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_cMHeAb-FEdqb7N6KIeDL8Q" name="architecture" guid="_cMHeAb-FEdqb7N6KIeDL8Q" presentationName="Architecture" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_cnzUcL-FEdqb7N6KIeDL8Q" name="impl_developer_tests" guid="_cnzUcL-FEdqb7N6KIeDL8Q" presentationName="Implement Developer Tests" superActivities="_h2-iAfimEdmugcVr9AdHjQ" linkToPredecessor="__26sYMmIEduwrYVlQ9zp3w" additionallyPerformedBy="_BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_-YrHMFY4EdqI9sTOt2pjHw" optionalInput="_9k_AcFY4EdqI9sTOt2pjHw" output="_-Y3UcFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iL1EMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_2LYo8KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g8npoC5UEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g1eDUC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_5WtVcKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_j30aAC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_ku06gC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_6wZFMKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_dAoEIL-FEdqb7N6KIeDL8Q" name="implement_solution" guid="_dAoEIL-FEdqb7N6KIeDL8Q" presentationName="Implement the Solution" superActivities="_h2-iAfimEdmugcVr9AdHjQ" additionallyPerformedBy="_BmbHQE_cEduE1dJ2XtzzkQ _BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_9k_AcFY4EdqI9sTOt2pjHw" optionalInput="_-YrHMFY4EdqI9sTOt2pjHw _cMHeAL-FEdqb7N6KIeDL8Q _QN4E4ALlEduHjPEP_YPH-g" output="_-YrHMFY4EdqI9sTOt2pjHw _AdllQFY5EdqI9sTOt2pjHw _cMHeAL-FEdqb7N6KIeDL8Q _QN4E4ALlEduHjPEP_YPH-g" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hyzgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_2sxisE2iEduU655MA_3VXg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_iMMWoKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_pjehkNb7Edq_LtLvi4w2yw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_mFQ58KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_-0yzwDH4EduMqpUNhaTSRA"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_ni25UKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_q5XiIKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_d4GesL-FEdqb7N6KIeDL8Q" name="run_developer_tests" guid="_d4GesL-FEdqb7N6KIeDL8Q" presentationName="Run Developer Tests" superActivities="_h2-iAfimEdmugcVr9AdHjQ" linkToPredecessor="_EjyMUE9EEdudU75l2xOQTw _c84V8MmJEduwrYVlQ9zp3w" additionallyPerformedBy="_BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_-Y3UcFY4EdqI9sTOt2pjHw _-YrHMFY4EdqI9sTOt2pjHw" output="_d4k_0L-FEdqb7N6KIeDL8Q" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iYCUMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_MSnQsMP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_NkRF0MP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_SXPFkMP4EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_d4k_0L-FEdqb7N6KIeDL8Q" name="test_log" guid="_d4k_0L-FEdqb7N6KIeDL8Q" presentationName="Test Log" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZlSsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_rQ9xIMjkEdqIm8AJUZUQYg" name="architect" guid="_rQ9xIMjkEdqIm8AJUZUQYg" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_cMHeAb-FEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_QN4E4ALlEduHjPEP_YPH-g" name="use_case" guid="_QN4E4ALlEduHjPEP_YPH-g" presentationName="Use Case" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_TiPK8DLwEdueZPye-FaNgA" guid="_TiPK8DLwEdueZPye-FaNgA" linkType="finishToFinish"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_RfwvEDOvEduqsLmIADMQ9g" name="test_script" guid="_RfwvEDOvEduqsLmIADMQ9g" presentationName="Test Script" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_EjyMUE9EEdudU75l2xOQTw" guid="_EjyMUE9EEdudU75l2xOQTw" linkType="finishToFinish" pred="_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_KAnAYE9PEdumneEH4I4Yqg" name="analyst" guid="_KAnAYE9PEdumneEH4I4Yqg" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_cMHeAL-FEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_BmbHQE_cEduE1dJ2XtzzkQ" name="stakeholder" guid="_BmbHQE_cEduE1dJ2XtzzkQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_BmbHQU_cEduE1dJ2XtzzkQ" name="tester" guid="_BmbHQU_cEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_RfwvEDOvEduqsLmIADMQ9g _d4k_0L-FEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="__26sYMmIEduwrYVlQ9zp3w" guid="__26sYMmIEduwrYVlQ9zp3w" linkType="finishToFinish" pred="_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_c84V8MmJEduwrYVlQ9zp3w" guid="_c84V8MmJEduwrYVlQ9zp3w" linkType="finishToFinish" pred="_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ <diagrams xmi:id="_OqnlAERlEduP07d3x5Xi-g" guid="_OqnlAERlEduP07d3x5Xi-g">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlBkRlEduP07d3x5Xi-g" guid="_OqnlBkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlB0RlEduP07d3x5Xi-g" x="188.0" y="40.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_sJ5GcURlEduP07d3x5Xi-g" guid="_sJ5GcURlEduP07d3x5Xi-g" anchor="_sJ5GcERlEduP07d3x5Xi-g _sJ5GckRlEduP07d3x5Xi-g">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="__26sYcmIEduwrYVlQ9zp3w" guid="__26sYcmIEduwrYVlQ9zp3w"/>
+ </contained>
+ <anchorage xmi:id="_OqnlGERlEduP07d3x5Xi-g" guid="_OqnlGERlEduP07d3x5Xi-g"/>
+ <anchorage xmi:id="_X2KukkRlEduP07d3x5Xi-g" guid="_X2KukkRlEduP07d3x5Xi-g" graphEdge="_X2KukURlEduP07d3x5Xi-g"/>
+ <anchorage xmi:id="_sJ5GcERlEduP07d3x5Xi-g" guid="_sJ5GcERlEduP07d3x5Xi-g" graphEdge="_sJ5GcURlEduP07d3x5Xi-g">
+ <position xmi:id="_sJ5Gc0RlEduP07d3x5Xi-g" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlCERlEduP07d3x5Xi-g" guid="_OqnlCERlEduP07d3x5Xi-g" element="_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlCURlEduP07d3x5Xi-g" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlCkRlEduP07d3x5Xi-g" guid="_OqnlCkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlC0RlEduP07d3x5Xi-g" x="182.0" y="336.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_c8f7ccmJEduwrYVlQ9zp3w" guid="_c8f7ccmJEduwrYVlQ9zp3w" anchor="_c8f7cMmJEduwrYVlQ9zp3w _c8f7csmJEduwrYVlQ9zp3w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_c84V8cmJEduwrYVlQ9zp3w" guid="_c84V8cmJEduwrYVlQ9zp3w"/>
+ <waypoints xmi:id="_HjEDQMmKEduwrYVlQ9zp3w" x="340.0" y="359.0"/>
+ <waypoints xmi:id="_EddkQMmKEduwrYVlQ9zp3w" x="340.0" y="230.0"/>
+ </contained>
+ <anchorage xmi:id="_Q9sAEsmJEduwrYVlQ9zp3w" guid="_Q9sAEsmJEduwrYVlQ9zp3w" graphEdge="_Q9sAEcmJEduwrYVlQ9zp3w"/>
+ <anchorage xmi:id="_c8f7cMmJEduwrYVlQ9zp3w" guid="_c8f7cMmJEduwrYVlQ9zp3w" graphEdge="_c8f7ccmJEduwrYVlQ9zp3w">
+ <position xmi:id="_c8f7c8mJEduwrYVlQ9zp3w" x="207.0" y="312.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlDERlEduP07d3x5Xi-g" guid="_OqnlDERlEduP07d3x5Xi-g" element="_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlDURlEduP07d3x5Xi-g" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlDkRlEduP07d3x5Xi-g" guid="_OqnlDkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlD0RlEduP07d3x5Xi-g" x="170.0" y="128.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_SVYKEURmEduP07d3x5Xi-g" guid="_SVYKEURmEduP07d3x5Xi-g" anchor="_SVYKEERmEduP07d3x5Xi-g _SVYKEkRmEduP07d3x5Xi-g">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_EjyMUU9EEdudU75l2xOQTw" guid="_EjyMUU9EEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_SVYKEERmEduP07d3x5Xi-g" guid="_SVYKEERmEduP07d3x5Xi-g" graphEdge="_SVYKEURmEduP07d3x5Xi-g">
+ <position xmi:id="_SVYKE0RmEduP07d3x5Xi-g" x="239.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_sJ5GckRlEduP07d3x5Xi-g" guid="_sJ5GckRlEduP07d3x5Xi-g" graphEdge="_sJ5GcURlEduP07d3x5Xi-g">
+ <position xmi:id="_i7ZrsERnEduP07d3x5Xi-g" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_IWdC0kRmEduP07d3x5Xi-g" guid="_IWdC0kRmEduP07d3x5Xi-g" graphEdge="_IWdC0URmEduP07d3x5Xi-g">
+ <position xmi:id="_kCRNIERnEduP07d3x5Xi-g" x="0.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlEERlEduP07d3x5Xi-g" guid="_OqnlEERlEduP07d3x5Xi-g" element="_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlEURlEduP07d3x5Xi-g" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlEkRlEduP07d3x5Xi-g" guid="_OqnlEkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlE0RlEduP07d3x5Xi-g" x="184.0" y="208.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_aLbiAcmJEduwrYVlQ9zp3w" guid="_aLbiAcmJEduwrYVlQ9zp3w" anchor="_aLbiAMmJEduwrYVlQ9zp3w _aLbiAsmJEduwrYVlQ9zp3w"/>
+ <anchorage xmi:id="_SVYKEkRmEduP07d3x5Xi-g" guid="_SVYKEkRmEduP07d3x5Xi-g" graphEdge="_SVYKEURmEduP07d3x5Xi-g">
+ <position xmi:id="_SVYKFERmEduP07d3x5Xi-g" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_aLbiAMmJEduwrYVlQ9zp3w" guid="_aLbiAMmJEduwrYVlQ9zp3w" graphEdge="_aLbiAcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_aLbiA8mJEduwrYVlQ9zp3w" x="192.0" y="222.0"/>
+ </anchorage>
+ <anchorage xmi:id="_c8f7csmJEduwrYVlQ9zp3w" guid="_c8f7csmJEduwrYVlQ9zp3w" graphEdge="_c8f7ccmJEduwrYVlQ9zp3w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlFERlEduP07d3x5Xi-g" guid="_OqnlFERlEduP07d3x5Xi-g" element="_d4GesL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlFURlEduP07d3x5Xi-g" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_QPeqAERlEduP07d3x5Xi-g" guid="_QPeqAERlEduP07d3x5Xi-g">
+ <position xmi:id="_QPeqAURlEduP07d3x5Xi-g" x="45.0" y="12.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_WP4tQURlEduP07d3x5Xi-g" guid="_WP4tQURlEduP07d3x5Xi-g" anchor="_WP4tQERlEduP07d3x5Xi-g _WP4tQkRlEduP07d3x5Xi-g"/>
+ <anchorage xmi:id="_WP4tQERlEduP07d3x5Xi-g" guid="_WP4tQERlEduP07d3x5Xi-g" graphEdge="_WP4tQURlEduP07d3x5Xi-g">
+ <position xmi:id="_WP4tQ0RlEduP07d3x5Xi-g" x="117.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_QPeqAkRlEduP07d3x5Xi-g" guid="_QPeqAkRlEduP07d3x5Xi-g" typeInfo="start node"/>
+ <size xmi:id="_QPeqA0RlEduP07d3x5Xi-g" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_SccQ0ERlEduP07d3x5Xi-g" guid="_SccQ0ERlEduP07d3x5Xi-g">
+ <position xmi:id="_SccQ0URlEduP07d3x5Xi-g" x="93.0" y="51.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_X2KukURlEduP07d3x5Xi-g" guid="_X2KukURlEduP07d3x5Xi-g" anchor="_X2KukERlEduP07d3x5Xi-g _X2KukkRlEduP07d3x5Xi-g"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_IWdC0URmEduP07d3x5Xi-g" guid="_IWdC0URmEduP07d3x5Xi-g" anchor="_IWdC0ERmEduP07d3x5Xi-g _IWdC0kRmEduP07d3x5Xi-g">
+ <waypoints xmi:id="_L37xwMmKEduwrYVlQ9zp3w" x="104.0" y="151.0"/>
+ </contained>
+ <anchorage xmi:id="_X2KukERlEduP07d3x5Xi-g" guid="_X2KukERlEduP07d3x5Xi-g" graphEdge="_X2KukURlEduP07d3x5Xi-g">
+ <position xmi:id="_X2Kuk0RlEduP07d3x5Xi-g" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_WP4tQkRlEduP07d3x5Xi-g" guid="_WP4tQkRlEduP07d3x5Xi-g" graphEdge="_WP4tQURlEduP07d3x5Xi-g">
+ <position xmi:id="_5pI7gMmIEduwrYVlQ9zp3w" x="11.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_IWdC0ERmEduP07d3x5Xi-g" guid="_IWdC0ERmEduP07d3x5Xi-g" graphEdge="_IWdC0URmEduP07d3x5Xi-g">
+ <position xmi:id="_IWdC00RmEduP07d3x5Xi-g" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_TnZ0UsmJEduwrYVlQ9zp3w" guid="_TnZ0UsmJEduwrYVlQ9zp3w" graphEdge="_TnZ0UcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_TnZ0VMmJEduwrYVlQ9zp3w" x="0.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_SccQ0kRlEduP07d3x5Xi-g" guid="_SccQ0kRlEduP07d3x5Xi-g" typeInfo="decision node"/>
+ <size xmi:id="_SccQ00RlEduP07d3x5Xi-g" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mXzzEERlEduP07d3x5Xi-g" name="Add Free Text" guid="_mXzzEERlEduP07d3x5Xi-g">
+ <property xmi:id="_mXzzEURlEduP07d3x5Xi-g" guid="_mXzzEURlEduP07d3x5Xi-g" key="free text" value="[typical change]"/>
+ <position xmi:id="_mXzzEkRlEduP07d3x5Xi-g" x="116.0" y="46.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mXzzE0RlEduP07d3x5Xi-g" guid="_mXzzE0RlEduP07d3x5Xi-g" typeInfo="free text"/>
+ <size xmi:id="_mXzzFERlEduP07d3x5Xi-g" width="93.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JJvg8ERmEduP07d3x5Xi-g" name="Add Free Text" guid="_JJvg8ERmEduP07d3x5Xi-g">
+ <property xmi:id="_JJvg8URmEduP07d3x5Xi-g" guid="_JJvg8URmEduP07d3x5Xi-g" key="free text" value="[trivial change]"/>
+ <position xmi:id="_JJvg8kRmEduP07d3x5Xi-g" x="115.0" y="135.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JJvg80RmEduP07d3x5Xi-g" guid="_JJvg80RmEduP07d3x5Xi-g" typeInfo="free text"/>
+ <size xmi:id="_JJvg9ERmEduP07d3x5Xi-g" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_UF-lAERmEduP07d3x5Xi-g" guid="_UF-lAERmEduP07d3x5Xi-g">
+ <position xmi:id="_UF-lAURmEduP07d3x5Xi-g" x="63.0" y="378.0"/>
+ <anchorage xmi:id="_OSdI4smJEduwrYVlQ9zp3w" guid="_OSdI4smJEduwrYVlQ9zp3w" graphEdge="_OSdI4cmJEduwrYVlQ9zp3w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_UF-lAkRmEduP07d3x5Xi-g" guid="_UF-lAkRmEduP07d3x5Xi-g" typeInfo="end node"/>
+ <size xmi:id="_UF-lA0RmEduP07d3x5Xi-g" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MRCqwMmJEduwrYVlQ9zp3w" guid="_MRCqwMmJEduwrYVlQ9zp3w">
+ <position xmi:id="_MRCqwcmJEduwrYVlQ9zp3w" x="51.0" y="276.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_OSdI4cmJEduwrYVlQ9zp3w" guid="_OSdI4cmJEduwrYVlQ9zp3w" anchor="_OSdI4MmJEduwrYVlQ9zp3w _OSdI4smJEduwrYVlQ9zp3w"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_TnZ0UcmJEduwrYVlQ9zp3w" guid="_TnZ0UcmJEduwrYVlQ9zp3w" anchor="_TnZ0UMmJEduwrYVlQ9zp3w _TnZ0UsmJEduwrYVlQ9zp3w">
+ <waypoints xmi:id="_fNw-AMmKEduwrYVlQ9zp3w" x="74.0" y="79.0"/>
+ </contained>
+ <anchorage xmi:id="_OSdI4MmJEduwrYVlQ9zp3w" guid="_OSdI4MmJEduwrYVlQ9zp3w" graphEdge="_OSdI4cmJEduwrYVlQ9zp3w">
+ <position xmi:id="_OSdI48mJEduwrYVlQ9zp3w" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_RVFzcsmJEduwrYVlQ9zp3w" guid="_RVFzcsmJEduwrYVlQ9zp3w" graphEdge="_RVFzccmJEduwrYVlQ9zp3w">
+ <position xmi:id="_sJ-yQMmJEduwrYVlQ9zp3w" x="47.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_TnZ0UMmJEduwrYVlQ9zp3w" guid="_TnZ0UMmJEduwrYVlQ9zp3w" graphEdge="_TnZ0UcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_rdqe0MmJEduwrYVlQ9zp3w" x="23.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MRCqwsmJEduwrYVlQ9zp3w" guid="_MRCqwsmJEduwrYVlQ9zp3w" typeInfo="decision node"/>
+ <size xmi:id="_MRCqw8mJEduwrYVlQ9zp3w" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_P-Lq4MmJEduwrYVlQ9zp3w" guid="_P-Lq4MmJEduwrYVlQ9zp3w">
+ <position xmi:id="_P-Lq4cmJEduwrYVlQ9zp3w" x="211.0" y="276.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_RVFzccmJEduwrYVlQ9zp3w" guid="_RVFzccmJEduwrYVlQ9zp3w" anchor="_RVFzcMmJEduwrYVlQ9zp3w _RVFzcsmJEduwrYVlQ9zp3w"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Q9sAEcmJEduwrYVlQ9zp3w" guid="_Q9sAEcmJEduwrYVlQ9zp3w" anchor="_Q9sAEMmJEduwrYVlQ9zp3w _Q9sAEsmJEduwrYVlQ9zp3w"/>
+ <anchorage xmi:id="_RVFzcMmJEduwrYVlQ9zp3w" guid="_RVFzcMmJEduwrYVlQ9zp3w" graphEdge="_RVFzccmJEduwrYVlQ9zp3w">
+ <position xmi:id="_VAgVQMmJEduwrYVlQ9zp3w" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Q9sAEMmJEduwrYVlQ9zp3w" guid="_Q9sAEMmJEduwrYVlQ9zp3w" graphEdge="_Q9sAEcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_jAJf8MmJEduwrYVlQ9zp3w" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_aLbiAsmJEduwrYVlQ9zp3w" guid="_aLbiAsmJEduwrYVlQ9zp3w" graphEdge="_aLbiAcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_aLbiBMmJEduwrYVlQ9zp3w" x="23.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_P-Lq4smJEduwrYVlQ9zp3w" guid="_P-Lq4smJEduwrYVlQ9zp3w" typeInfo="decision node"/>
+ <size xmi:id="_P-Lq48mJEduwrYVlQ9zp3w" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jrCQAMmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_jrCQAMmJEduwrYVlQ9zp3w">
+ <property xmi:id="_jrCQAcmJEduwrYVlQ9zp3w" guid="_jrCQAcmJEduwrYVlQ9zp3w" key="free text" value="[fail]"/>
+ <position xmi:id="_jrCQAsmJEduwrYVlQ9zp3w" x="236.0" y="304.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_jrCQA8mJEduwrYVlQ9zp3w" guid="_jrCQA8mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_jrCQBMmJEduwrYVlQ9zp3w" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mAr4wMmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_mAr4wMmJEduwrYVlQ9zp3w">
+ <property xmi:id="_mAr4wcmJEduwrYVlQ9zp3w" guid="_mAr4wcmJEduwrYVlQ9zp3w" key="free text" value="[pass]"/>
+ <position xmi:id="_mAr4wsmJEduwrYVlQ9zp3w" x="177.0" y="269.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mAr4w8mJEduwrYVlQ9zp3w" guid="_mAr4w8mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_mAr4xMmJEduwrYVlQ9zp3w" width="30.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_tM7dAMmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_tM7dAMmJEduwrYVlQ9zp3w">
+ <property xmi:id="_tM7dAcmJEduwrYVlQ9zp3w" guid="_tM7dAcmJEduwrYVlQ9zp3w" key="free text" value="[more work to do]"/>
+ <position xmi:id="_tM7dAsmJEduwrYVlQ9zp3w" x="15.0" y="250.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_tM7dA8mJEduwrYVlQ9zp3w" guid="_tM7dA8mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_tM7dBMmJEduwrYVlQ9zp3w" width="61.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_yzpN4MmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_yzpN4MmJEduwrYVlQ9zp3w">
+ <property xmi:id="_yzpN4cmJEduwrYVlQ9zp3w" guid="_yzpN4cmJEduwrYVlQ9zp3w" key="free text" value="[requirement realized]"/>
+ <position xmi:id="_yzpN4smJEduwrYVlQ9zp3w" x="6.0" y="300.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_yzpN48mJEduwrYVlQ9zp3w" guid="_yzpN48mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_yzpN5MmJEduwrYVlQ9zp3w" width="68.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlAURlEduP07d3x5Xi-g" guid="_OqnlAURlEduP07d3x5Xi-g" presentation="Workflow" element="_h2-iAfimEdmugcVr9AdHjQ"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_h2-iAfimEdmugcVr9AdHjQ" name="develop_solution" guid="_h2-iAfimEdmugcVr9AdHjQ" briefDescription="Design, implement, test and integrate the solution for a requirement within a given context." presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" breakdownElements="_9kUSEFY4EdqI9sTOt2pjHw _9k_AcFY4EdqI9sTOt2pjHw _-YrHMFY4EdqI9sTOt2pjHw _-Y3UcFY4EdqI9sTOt2pjHw _AdllQFY5EdqI9sTOt2pjHw _cL1KIL-FEdqb7N6KIeDL8Q _cMHeAL-FEdqb7N6KIeDL8Q _cMHeAb-FEdqb7N6KIeDL8Q _dAoEIL-FEdqb7N6KIeDL8Q _cnzUcL-FEdqb7N6KIeDL8Q _d4GesL-FEdqb7N6KIeDL8Q _d4k_0L-FEdqb7N6KIeDL8Q _rQ9xIMjkEdqIm8AJUZUQYg _QN4E4ALlEduHjPEP_YPH-g _RfwvEDOvEduqsLmIADMQ9g _KAnAYE9PEdumneEH4I4Yqg _BmbHQE_cEduE1dJ2XtzzkQ _BmbHQU_cEduE1dJ2XtzzkQ">
+ <ownedRules xmi:id="_Prih4DR_EduGhYMJfagftQ" name="diagram" guid="_Prih4DR_EduGhYMJfagftQ" body="ad_image_uri=|publish_ad_image=false|add_image_uri=|publish_add_image=false|wpd_image_uri=|publish_wpd_image=false"/>
+ <presentation xmi:id="_h6zSEPimEdmugcVr9AdHjQ" href="uma://_h6zSEPimEdmugcVr9AdHjQ#_h6zSEPimEdmugcVr9AdHjQ"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.xmi
new file mode 100644
index 0000000..427aee5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.xmi
@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BfL5Edm6Nvont3uinw" guid="_mtb_BfL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_B_L5Edm6Nvont3uinw" guid="_mtb_B_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CfL5Edm6Nvont3uinw" guid="_mtb_CfL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CvL5Edm6Nvont3uinw" guid="_mtb_CvL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BvL5Edm6Nvont3uinw" guid="_mtb_BvL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_C_L5Edm6Nvont3uinw" guid="_mtb_C_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb_BPL5Edm6Nvont3uinw" guid="_mtb_BPL5Edm6Nvont3uinw">
+ <mainDescription><h3> Introduction </h3>
+<p> Most activities during a typical iteration in Elaboration phase happen in
+ parallel. Essentially, the main objectives for Elaboration are related to better
+ understanding the requirements, creating and establishing
+ a baseline for the architecture for the system, and mitigating top-priority
+ risks. </p>
+<p> The activities performed in a typical iteration during&nbsp;the
+ Elaboration phase are described below. </p>
+<h4> Manage iteration </h4>
+<p> This activity is performed throughout the project lifecycle.
+ The goal of this activity is to identify risks and issues early enough
+ that they can be mitigated, to establish the goals for the iteration,
+ and to support the development team in reaching these goals. </p>
+<p> The <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> and the team launche the iteration, allocating work items to team
+ members (some project teams will prefer to have members volunteer to perform
+ work). The project manager collaborates with the team to break down the work
+ items into development tasks to perform in that iteration. This provides a more
+ accurate estimate of time to spend on what can be realistically achieved. </p>
+<p> As the iteration runs, the project manager performs
+ monitoring and control of&nbsp;the project by regularly checking the
+ status of work completed, the work to do
+ next, and issues blocking the progress<strong>.
+ </strong>In some projects, this checking occurs
+ in daily meetings, which allows for a&nbsp;more precise&nbsp;understanding
+ of how the work in an iteration is progressing. As
+ needed, the&nbsp;team makes corrections to achieve what was planned. The overall
+ idea is that risks and issues are identified and managed throughout the iteration.
+ And everyone knows the project status.</p>
+<p>The prioritization of work for a given iteration takes place. Project manager,&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>,
+ and the remaining team members agree on what is supposed to be developed during
+ that iteration.</p>
+<p>As in any other iteration assessment, demonstration of implemented functionality
+ planned for that iteration is the key success criterion. During iteration assessments
+ in Elaboration, though, keep the phase objectives in mind. As Elaboration iterations
+ are performed, an executable architecture evolves, and you establish a baseline
+ at the end of the phase. In addition, requirements are better understood and
+ detailed. Essential risks, including the architectural ones, have been mitigated.
+ These results&nbsp;help the project manager produce more accurate estimates
+ for the project schedule and cost.</p>
+<h4> Manage requirements </h4>
+<p> This activity is repeated throughout the project lifecycle.
+ The goal of this activity is to understand and prioritize stakeholder needs
+ and associated requirements for the system, and also to
+ capture these in a form that supports effective communication and collaboration
+ between the stakeholders and development team. </p>
+<p> During the Elaboration phase,
+ requirements can still be captured and outlined as customer needs arise. The
+ prioritization of requirements determines when
+ new requirements are going to be implemented. High-risk, architecturally significant
+ requirements are detailed to the extent necessary to be
+ able to use that information as input to architecture and development
+ activities in the current iteration, plus in planning
+ for the next iteration.</p>
+<p><a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test
+ cases</a> describe which&nbsp;requirements are being tested&nbsp;in that iteration.
+</p>
+<p> <strong>Note: <br />
+ <br/>
+ </strong>The emphasis on finding, outlining and detailing requirements varies
+ from phase to phase. Iterations in Inception and early Elaboration tend to focus
+ more on identifying and outlining requirements in general and on
+ detailing high-priority and architecturally
+ significant requirements. During iterations in late Elaboration and early Construction,
+ the remaining requirements are usually outlined and detailed. </p>
+<h4> Define the architecture </h4>
+<p> This activity is repeated in each iteration in the
+ Elaboration phase. The main&nbsp;goal of this activity is&nbsp;to propose an
+ <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a>
+ that addresses the requirements with high architectural risks, thus providing
+ a solid, yet resilient, foundation on which to build the system functionality.</p>
+<p> The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a>
+ analyzes the architectural constraints, identifies available assets to build
+ the system, defines how the system will be structured, and identifies the initial
+ abstractions and mechanisms that must be provided by the architecture. </p>
+<p> Throughout all of the iterations, the architect: </p>
+<ul>
+
+ <li> Identifies commonalities between different requirements to leverage reuse
+ </li>
+ <li> Defines strategies for achieving requirements related
+ to quality</li>
+ <li> Captures and communicates architectural decisions </li>
+</ul>
+<h4> Develop solution for requirement within context</h4>
+<p> This activity is instantiated multiple times, in parallel, for each development
+ task planned for that iteration. The main goal of this activity is an executable
+ system that provides the incremental quality and functionality for the specified
+ requirements within the specified context. </p>
+<p> As the requirements planned for the iteration are broken down into development
+ tasks, these are assigned by the project managers to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>
+ (some project teams prefer to have team members sign up for development tasks
+ themselves). </p>
+<p> The solution to be developed is for a particular requirement within a context,
+ which reflects the idea of breaking down requirements into development tasks.
+ As an example, a particular use-case scenario within the context of database
+ access could be assigned to a developer; whereas, the same scenario within the
+ user interface and business logic contexts could be assigned to a different
+ developer. In this example, more than one developer is working on a particular
+ piece of functionality to be delivered in a particular iteration. As they develop
+ the requirement within the context they were assigned to, they perform&nbsp;<a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html" guid="_0YuXEclgEdmt3adZL5Dmdw">tests</a>
+ and integrate their work to create <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>.
+</p>
+<h4> Validate build </h4>
+<p> This activity is repeated throughout the project
+ lifecycle. The main goal of this activity is to validate the current increment
+ of the system against the requirements allocated to it. </p>
+<p> The intent is to validate that the high-priority requirements implemented
+ reflect a robust architecture so that remaining requirements can be implemented
+ on top of that architecture. As developer develop the solution for the requirements
+ in a given iteration, the integrated source code is unit-tested. Then, a separate
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">tester</a>
+ conducts system-level testing in parallel with development to make sure that
+ the solution, which is continuously being integrated, matches what is specified
+ in the requirements. Then, the tester defines what techniques to use, what the
+ data input is, what <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/test_suite,_0aDz0MlgEdmt3adZL5Dmdw.html" guid="_0aDz0MlgEdmt3adZL5Dmdw">test
+ suites</a> to create. As tests are performed, defects found are reported and
+ added to the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">work
+ items list</a>, so they can be prioritized and assigned to team members. </p>
+<h4> Ongoing tasks </h4>
+<p> This activity includes tasks that happen throughout the iteration on an ongoing
+ basis but are not necessarily part of a plan. For example, at any time, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any
+ role</a> in the project team can issue a <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">change
+ request</a>, either because there are requests for enhancements, or defects
+ are found. These change requests are part of the work items list and are prioritized
+ and assigned to team members. Anyone can be assigned to make changes that develop
+ enhancements or fix defects. </p>
+<h4>&nbsp; </h4></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.xmi
new file mode 100644
index 0000000..58e08f3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.xmi
@@ -0,0 +1,422 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nNCE8PL5Edm6Nvont3uinw" guid="_nNCE8PL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_b7urcPe9Edm6qtYFDZ-o3w" id="_mtb_B_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b7urcfe9Edm6qtYFDZ-o3w" id="_mtb_CfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b7urcve9Edm6qtYFDZ-o3w" id="_mtb_CvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b7urc_e9Edm6qtYFDZ-o3w" id="_mtb_BvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b8fgcPe9Edm6qtYFDZ-o3w" id="_mtb_CPL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b8x0UPe9Edm6qtYFDZ-o3w" id="_mtb_C_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_cA-X0Pe9Edm6qtYFDZ-o3w" id="_mtb_BPL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_ozOm4EsCEdqj8KrJkiMlfA" id="_mtb_BfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0rWYIMlgEdmt3adZL5Dmdw" name="elaboration_phase_iteration" guid="_0rWYIMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0rWYIclgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0rWYIclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0rWYIslgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0rWYIslgEdmt3adZL5Dmdw" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="_mtb_BfL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_BfL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0rcewMlgEdmt3adZL5Dmdw" name="define_architecture" guid="_0rcewMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0rcewclgEdmt3adZL5Dmdw" name="define_architecture" guid="_0rcewclgEdmt3adZL5Dmdw" presentationName="Define the Architecture" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_B_L5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_B_L5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0rilYMlgEdmt3adZL5Dmdw" name="validate_build" guid="_0rilYMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0rilYclgEdmt3adZL5Dmdw" name="validate_build" guid="_0rilYclgEdmt3adZL5Dmdw" presentationName="Validate Build" hasMultipleOccurrences="true" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_CfL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_CfL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0ruyoMlgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0ruyoMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0ruyoclgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0ruyoclgEdmt3adZL5Dmdw" presentationName="Manage Requirements" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_BvL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_BvL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_Wq_VQPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_Wq_VQPinEdmugcVr9AdHjQ">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_WrXvwPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_WrXvwPinEdmugcVr9AdHjQ" presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ </processElements>
+ <diagrams xmi:id="_rsGFwDSDEduGhYMJfagftQ" guid="_rsGFwDSDEduGhYMJfagftQ">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts0E9EEdudU75l2xOQTw" guid="_z9Ts0E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts0U9EEdudU75l2xOQTw" x="190.0" y="63.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts0k9EEdudU75l2xOQTw" guid="_z9Ts0k9EEdudU75l2xOQTw" anchor="_z9Ts1E9EEdudU75l2xOQTw _z9Ts3E9EEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts009EEdudU75l2xOQTw" guid="_z9Ts009EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_TiPK8DLwEdueZPye-FaNgA"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_z9Ts1E9EEdudU75l2xOQTw" guid="_z9Ts1E9EEdudU75l2xOQTw" graphEdge="_z9Ts0k9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts1U9EEdudU75l2xOQTw" guid="_z9Ts1U9EEdudU75l2xOQTw" graphEdge="_z9TtBk9EEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts1k9EEdudU75l2xOQTw" guid="_z9Ts1k9EEdudU75l2xOQTw"/>
+ <size xmi:id="_z9Ts109EEdudU75l2xOQTw" width="112.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts2E9EEdudU75l2xOQTw" guid="_z9Ts2E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts2U9EEdudU75l2xOQTw" x="200.0" y="150.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts2k9EEdudU75l2xOQTw" guid="_z9Ts2k9EEdudU75l2xOQTw" anchor="_z9Ts3k9EEdudU75l2xOQTw _z9TtS09EEdudU75l2xOQTw">
+ <waypoints xmi:id="_z9Ts209EEdudU75l2xOQTw" x="245.0" y="242.0"/>
+ </contained>
+ <anchorage xmi:id="_z9Ts3E9EEdudU75l2xOQTw" guid="_z9Ts3E9EEdudU75l2xOQTw" graphEdge="_z9Ts0k9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts3U9EEdudU75l2xOQTw" guid="_z9Ts3U9EEdudU75l2xOQTw" graphEdge="_z9TtEU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts3k9EEdudU75l2xOQTw" guid="_z9Ts3k9EEdudU75l2xOQTw" graphEdge="_z9Ts2k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts309EEdudU75l2xOQTw" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts4E9EEdudU75l2xOQTw" guid="_z9Ts4E9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts4U9EEdudU75l2xOQTw" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts4k9EEdudU75l2xOQTw" guid="_z9Ts4k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts409EEdudU75l2xOQTw" x="50.0" y="320.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts5E9EEdudU75l2xOQTw" guid="_z9Ts5E9EEdudU75l2xOQTw" anchor="_z9Ts5k9EEdudU75l2xOQTw _z9TtO09EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_wHZQ8c6VEdu_q7xi9VPgyA" guid="_wHZQ8c6VEdu_q7xi9VPgyA" anchor="_wHZQ8M6VEdu_q7xi9VPgyA _wHZQ8s6VEdu_q7xi9VPgyA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_wHZQ886VEdu_q7xi9VPgyA" guid="_wHZQ886VEdu_q7xi9VPgyA">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_c84V8MmJEduwrYVlQ9zp3w"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_z9Ts5U9EEdudU75l2xOQTw" guid="_z9Ts5U9EEdudU75l2xOQTw" graphEdge="_z9TtKU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts5k9EEdudU75l2xOQTw" guid="_z9Ts5k9EEdudU75l2xOQTw" graphEdge="_z9Ts5E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts509EEdudU75l2xOQTw" x="101.0" y="286.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wHZQ8M6VEdu_q7xi9VPgyA" guid="_wHZQ8M6VEdu_q7xi9VPgyA" graphEdge="_wHZQ8c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts6E9EEdudU75l2xOQTw" guid="_z9Ts6E9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts6U9EEdudU75l2xOQTw" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts6k9EEdudU75l2xOQTw" guid="_z9Ts6k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts609EEdudU75l2xOQTw" x="201.0" y="304.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts7E9EEdudU75l2xOQTw" guid="_z9Ts7E9EEdudU75l2xOQTw" anchor="_z9Ts709EEdudU75l2xOQTw _z9Ts-E9EEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts7U9EEdudU75l2xOQTw" guid="_z9Ts7U9EEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_z9Ts7k9EEdudU75l2xOQTw" guid="_z9Ts7k9EEdudU75l2xOQTw" graphEdge="_z9TtKE9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts709EEdudU75l2xOQTw" guid="_z9Ts709EEdudU75l2xOQTw" graphEdge="_z9Ts7E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts8E9EEdudU75l2xOQTw" x="239.0" y="284.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts8U9EEdudU75l2xOQTw" guid="_z9Ts8U9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts8k9EEdudU75l2xOQTw" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts809EEdudU75l2xOQTw" guid="_z9Ts809EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts9E9EEdudU75l2xOQTw" x="213.0" y="368.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts9U9EEdudU75l2xOQTw" guid="_z9Ts9U9EEdudU75l2xOQTw" anchor="_z9Ts9k9EEdudU75l2xOQTw _z9TtPU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts9k9EEdudU75l2xOQTw" guid="_z9Ts9k9EEdudU75l2xOQTw" graphEdge="_z9Ts9U9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts909EEdudU75l2xOQTw" x="374.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9Ts-E9EEdudU75l2xOQTw" guid="_z9Ts-E9EEdudU75l2xOQTw" graphEdge="_z9Ts7E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts-U9EEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wHZQ8s6VEdu_q7xi9VPgyA" guid="_wHZQ8s6VEdu_q7xi9VPgyA" graphEdge="_wHZQ8c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts-k9EEdudU75l2xOQTw" guid="_z9Ts-k9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_d4GesL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts-09EEdudU75l2xOQTw" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts_E9EEdudU75l2xOQTw" guid="_z9Ts_E9EEdudU75l2xOQTw" briefDescription="_QPeqAERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9Ts_U9EEdudU75l2xOQTw" x="46.0" y="82.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts_k9EEdudU75l2xOQTw" guid="_z9Ts_k9EEdudU75l2xOQTw" anchor="_z9Ts_09EEdudU75l2xOQTw _z9TtB09EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts_09EEdudU75l2xOQTw" guid="_z9Ts_09EEdudU75l2xOQTw" graphEdge="_z9Ts_k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtAE9EEdudU75l2xOQTw" x="117.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtAU9EEdudU75l2xOQTw" guid="_z9TtAU9EEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_z9TtAk9EEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtA09EEdudU75l2xOQTw" guid="_z9TtA09EEdudU75l2xOQTw" briefDescription="_RCR_8ERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtBE9EEdudU75l2xOQTw" x="105.0" y="81.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtBU9EEdudU75l2xOQTw" guid="_z9TtBU9EEdudU75l2xOQTw" anchor="_z9TtCU9EEdudU75l2xOQTw _z9TtFE9EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtBk9EEdudU75l2xOQTw" guid="_z9TtBk9EEdudU75l2xOQTw" anchor="_z9TtC09EEdudU75l2xOQTw _z9Ts1U9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9TtB09EEdudU75l2xOQTw" guid="_z9TtB09EEdudU75l2xOQTw" graphEdge="_z9Ts_k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtCE9EEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtCU9EEdudU75l2xOQTw" guid="_z9TtCU9EEdudU75l2xOQTw" graphEdge="_z9TtBU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtCk9EEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtC09EEdudU75l2xOQTw" guid="_z9TtC09EEdudU75l2xOQTw" graphEdge="_z9TtBk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtDE9EEdudU75l2xOQTw" x="23.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtDU9EEdudU75l2xOQTw" guid="_z9TtDU9EEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_z9TtDk9EEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtD09EEdudU75l2xOQTw" guid="_z9TtD09EEdudU75l2xOQTw" briefDescription="_SccQ0ERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtEE9EEdudU75l2xOQTw" x="105.0" y="161.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtEU9EEdudU75l2xOQTw" guid="_z9TtEU9EEdudU75l2xOQTw" anchor="_z9TtFk9EEdudU75l2xOQTw _z9Ts3U9EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtEk9EEdudU75l2xOQTw" guid="_z9TtEk9EEdudU75l2xOQTw" anchor="_z9TtGE9EEdudU75l2xOQTw _z9TtTU9EEdudU75l2xOQTw">
+ <waypoints xmi:id="_z9TtE09EEdudU75l2xOQTw" x="116.0" y="242.0"/>
+ </contained>
+ <anchorage xmi:id="_z9TtFE9EEdudU75l2xOQTw" guid="_z9TtFE9EEdudU75l2xOQTw" graphEdge="_z9TtBU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtFU9EEdudU75l2xOQTw" x="11.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtFk9EEdudU75l2xOQTw" guid="_z9TtFk9EEdudU75l2xOQTw" graphEdge="_z9TtEU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtF09EEdudU75l2xOQTw" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtGE9EEdudU75l2xOQTw" guid="_z9TtGE9EEdudU75l2xOQTw" graphEdge="_z9TtEk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtGU9EEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtGk9EEdudU75l2xOQTw" guid="_z9TtGk9EEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_z9TtG09EEdudU75l2xOQTw" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtHE9EEdudU75l2xOQTw" name="Add Free Text" guid="_z9TtHE9EEdudU75l2xOQTw" briefDescription="_jEpZMERlEduP07d3x5Xi-g">
+ <property xmi:id="_z9TtHU9EEdudU75l2xOQTw" guid="_z9TtHU9EEdudU75l2xOQTw" key="free text" value="[major change]"/>
+ <position xmi:id="_z9TtHk9EEdudU75l2xOQTw" x="129.0" y="76.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtH09EEdudU75l2xOQTw" guid="_z9TtH09EEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_z9TtIE9EEdudU75l2xOQTw" width="71.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtIU9EEdudU75l2xOQTw" name="Add Free Text" guid="_z9TtIU9EEdudU75l2xOQTw" briefDescription="_mXzzEERlEduP07d3x5Xi-g">
+ <property xmi:id="_z9TtIk9EEdudU75l2xOQTw" guid="_z9TtIk9EEdudU75l2xOQTw" key="free text" value="[small change]"/>
+ <position xmi:id="_z9TtI09EEdudU75l2xOQTw" x="128.0" y="156.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtJE9EEdudU75l2xOQTw" guid="_z9TtJE9EEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_z9TtJU9EEdudU75l2xOQTw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtJk9EEdudU75l2xOQTw" guid="_z9TtJk9EEdudU75l2xOQTw" briefDescription="_pfsxEERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtJ09EEdudU75l2xOQTw" x="64.0" y="283.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtKE9EEdudU75l2xOQTw" guid="_z9TtKE9EEdudU75l2xOQTw" anchor="_z9TtK09EEdudU75l2xOQTw _z9Ts7k9EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtKU9EEdudU75l2xOQTw" guid="_z9TtKU9EEdudU75l2xOQTw" anchor="_z9TtLU9EEdudU75l2xOQTw _z9Ts5U9EEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9TtKk9EEdudU75l2xOQTw" guid="_z9TtKk9EEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_z9TtK09EEdudU75l2xOQTw" guid="_z9TtK09EEdudU75l2xOQTw" graphEdge="_z9TtKE9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtLE9EEdudU75l2xOQTw" x="201.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtLU9EEdudU75l2xOQTw" guid="_z9TtLU9EEdudU75l2xOQTw" graphEdge="_z9TtKU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtLk9EEdudU75l2xOQTw" x="38.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtL09EEdudU75l2xOQTw" guid="_z9TtL09EEdudU75l2xOQTw" graphEdge="_z9TtSk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtME9EEdudU75l2xOQTw" x="116.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtMU9EEdudU75l2xOQTw" guid="_z9TtMU9EEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z9TtMk9EEdudU75l2xOQTw" width="262.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtM09EEdudU75l2xOQTw" name="Add Free Text" guid="_z9TtM09EEdudU75l2xOQTw" briefDescription="_JJvg8ERmEduP07d3x5Xi-g">
+ <property xmi:id="_z9TtNE9EEdudU75l2xOQTw" guid="_z9TtNE9EEdudU75l2xOQTw" key="free text" value="[trivial change]"/>
+ <position xmi:id="_z9TtNU9EEdudU75l2xOQTw" x="120.0" y="204.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtNk9EEdudU75l2xOQTw" guid="_z9TtNk9EEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_z9TtN09EEdudU75l2xOQTw" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtOE9EEdudU75l2xOQTw" guid="_z9TtOE9EEdudU75l2xOQTw" briefDescription="_MViukERmEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtOU9EEdudU75l2xOQTw" x="64.0" y="433.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtOk9EEdudU75l2xOQTw" guid="_z9TtOk9EEdudU75l2xOQTw" anchor="_z9TtP09EEdudU75l2xOQTw _z9TtRU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9TtO09EEdudU75l2xOQTw" guid="_z9TtO09EEdudU75l2xOQTw" graphEdge="_z9Ts5E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtPE9EEdudU75l2xOQTw" x="39.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtPU9EEdudU75l2xOQTw" guid="_z9TtPU9EEdudU75l2xOQTw" graphEdge="_z9Ts9U9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtPk9EEdudU75l2xOQTw" x="199.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtP09EEdudU75l2xOQTw" guid="_z9TtP09EEdudU75l2xOQTw" graphEdge="_z9TtOk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtQE9EEdudU75l2xOQTw" x="129.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtQU9EEdudU75l2xOQTw" guid="_z9TtQU9EEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z9TtQk9EEdudU75l2xOQTw" width="274.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtQ09EEdudU75l2xOQTw" guid="_z9TtQ09EEdudU75l2xOQTw" briefDescription="_UF-lAERmEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtRE9EEdudU75l2xOQTw" x="182.0" y="461.0"/>
+ <anchorage xmi:id="_z9TtRU9EEdudU75l2xOQTw" guid="_z9TtRU9EEdudU75l2xOQTw" graphEdge="_z9TtOk9EEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtRk9EEdudU75l2xOQTw" guid="_z9TtRk9EEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_z9TtR09EEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtSE9EEdudU75l2xOQTw" guid="_z9TtSE9EEdudU75l2xOQTw" briefDescription="_gEnEwERnEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtSU9EEdudU75l2xOQTw" x="167.0" y="231.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtSk9EEdudU75l2xOQTw" guid="_z9TtSk9EEdudU75l2xOQTw" anchor="_z9TtT09EEdudU75l2xOQTw _z9TtL09EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9TtS09EEdudU75l2xOQTw" guid="_z9TtS09EEdudU75l2xOQTw" graphEdge="_z9Ts2k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtTE9EEdudU75l2xOQTw" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtTU9EEdudU75l2xOQTw" guid="_z9TtTU9EEdudU75l2xOQTw" graphEdge="_z9TtEk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtTk9EEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtT09EEdudU75l2xOQTw" guid="_z9TtT09EEdudU75l2xOQTw" graphEdge="_z9TtSk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtUE9EEdudU75l2xOQTw" x="13.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtUU9EEdudU75l2xOQTw" guid="_z9TtUU9EEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_z9TtUk9EEdudU75l2xOQTw" width="28.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_rsGGPDSDEduGhYMJfagftQ" guid="_rsGGPDSDEduGhYMJfagftQ" presentation="Workflow" element="_WrXvwPinEdmugcVr9AdHjQ"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_S_IQ4CliEdqjQsaFX0CJTw" name="ongoing_tasks" guid="_S_IQ4CliEdqjQsaFX0CJTw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_TAVx0CliEdqjQsaFX0CJTw" name="ongoing_tasks" guid="_TAVx0CliEdqjQsaFX0CJTw" presentationName="Ongoing Tasks" isPlanned="false" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <diagrams xmi:id="_ohS1wNIWEdm9Cql_SeWu_A" guid="_ohS1wNIWEdm9Cql_SeWu_A">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1wdIWEdm9Cql_SeWu_A" guid="_ohS1wdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1wtIWEdm9Cql_SeWu_A" x="338.0" y="74.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__10NIdSIEdqANo9Ox5ktZQ" guid="__10NIdSIEdqANo9Ox5ktZQ" anchor="__10NINSIEdqANo9Ox5ktZQ __10NItSIEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="__cmb4tSIEdqANo9Ox5ktZQ" guid="__cmb4tSIEdqANo9Ox5ktZQ" graphEdge="__cmb4dSIEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="__10NINSIEdqANo9Ox5ktZQ" guid="__10NINSIEdqANo9Ox5ktZQ" graphEdge="__10NIdSIEdqANo9Ox5ktZQ">
+ <position xmi:id="__10NI9SIEdqANo9Ox5ktZQ" x="449.0" y="218.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1w9IWEdm9Cql_SeWu_A" guid="_ohS1w9IWEdm9Cql_SeWu_A" element="_0rWYIslgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS1xNIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1xdIWEdm9Cql_SeWu_A" guid="_ohS1xdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1xtIWEdm9Cql_SeWu_A" x="-58.0" y="81.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5REOER_bEdq3EKSIdbj-MA" guid="_5REOER_bEdq3EKSIdbj-MA" anchor="_5REOEB_bEdq3EKSIdbj-MA _5REOEh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_43sr0h_bEdq3EKSIdbj-MA" guid="_43sr0h_bEdq3EKSIdbj-MA" graphEdge="_43sr0R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_43sr1B_bEdq3EKSIdbj-MA" x="75.0" y="-62.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5REOEB_bEdq3EKSIdbj-MA" guid="_5REOEB_bEdq3EKSIdbj-MA" graphEdge="_5REOER_bEdq3EKSIdbj-MA">
+ <position xmi:id="_5REOEx_bEdq3EKSIdbj-MA" x="78.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1x9IWEdm9Cql_SeWu_A" guid="_ohS1x9IWEdm9Cql_SeWu_A" element="_0ruyoclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS1yNIWEdm9Cql_SeWu_A" width="236.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1ydIWEdm9Cql_SeWu_A" guid="_ohS1ydIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1ytIWEdm9Cql_SeWu_A" x="63.0" y="120.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_55VvAR_bEdq3EKSIdbj-MA" guid="_55VvAR_bEdq3EKSIdbj-MA" anchor="_55VvAB_bEdq3EKSIdbj-MA _55VvAh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_5mRCAh_bEdq3EKSIdbj-MA" guid="_5mRCAh_bEdq3EKSIdbj-MA" graphEdge="_5mRCAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_5mRCBB_bEdq3EKSIdbj-MA" x="18.0" y="-88.0"/>
+ </anchorage>
+ <anchorage xmi:id="_55VvAB_bEdq3EKSIdbj-MA" guid="_55VvAB_bEdq3EKSIdbj-MA" graphEdge="_55VvAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_55VvAx_bEdq3EKSIdbj-MA" x="32.0" y="26.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1y9IWEdm9Cql_SeWu_A" guid="_ohS1y9IWEdm9Cql_SeWu_A" element="_0rcewclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS1zNIWEdm9Cql_SeWu_A" width="146.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1zdIWEdm9Cql_SeWu_A" guid="_ohS1zdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1ztIWEdm9Cql_SeWu_A" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1z9IWEdm9Cql_SeWu_A" guid="_ohS1z9IWEdm9Cql_SeWu_A"/>
+ <size xmi:id="_ohS10NIWEdm9Cql_SeWu_A" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS10dIWEdm9Cql_SeWu_A" guid="_ohS10dIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS10tIWEdm9Cql_SeWu_A" x="245.0" y="221.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mDxSccmzEdqibaSI8nt1Ng" guid="_mDxSccmzEdqibaSI8nt1Ng" anchor="_mDxScMmzEdqibaSI8nt1Ng _mDxScsmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_lukegsmzEdqibaSI8nt1Ng" guid="_lukegsmzEdqibaSI8nt1Ng" graphEdge="_lukegcmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_mDxScMmzEdqibaSI8nt1Ng" guid="_mDxScMmzEdqibaSI8nt1Ng" graphEdge="_mDxSccmzEdqibaSI8nt1Ng">
+ <position xmi:id="_mDxSc8mzEdqibaSI8nt1Ng" x="612.0" y="243.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS109IWEdm9Cql_SeWu_A" guid="_ohS109IWEdm9Cql_SeWu_A" element="_0rilYclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS11NIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS11dIWEdm9Cql_SeWu_A" guid="_ohS11dIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS11tIWEdm9Cql_SeWu_A" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_82IQQR_bEdq3EKSIdbj-MA" guid="_82IQQR_bEdq3EKSIdbj-MA" anchor="_82IQQB_bEdq3EKSIdbj-MA _82IQQh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_82IQQB_bEdq3EKSIdbj-MA" guid="_82IQQB_bEdq3EKSIdbj-MA" graphEdge="_82IQQR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_82IQQx_bEdq3EKSIdbj-MA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS119IWEdm9Cql_SeWu_A" guid="_ohS119IWEdm9Cql_SeWu_A"/>
+ <size xmi:id="_ohS12NIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5VDG0NIWEdm9Cql_SeWu_A" guid="_5VDG0NIWEdm9Cql_SeWu_A">
+ <position xmi:id="_5VDG0dIWEdm9Cql_SeWu_A" x="309.0" y="351.0"/>
+ <anchorage xmi:id="_BQKrQtSJEdqANo9Ox5ktZQ" guid="_BQKrQtSJEdqANo9Ox5ktZQ" graphEdge="_BQKrQdSJEdqANo9Ox5ktZQ"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5VDG0tIWEdm9Cql_SeWu_A" guid="_5VDG0tIWEdm9Cql_SeWu_A" typeInfo="end node"/>
+ <size xmi:id="_5VDG09IWEdm9Cql_SeWu_A" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_vsKsEPfpEdmRMap9i-t5rw" guid="_vsKsEPfpEdmRMap9i-t5rw">
+ <position xmi:id="_vsKsEffpEdmRMap9i-t5rw" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_u3pLsfiVEdmiedAQWF94Dw" guid="_u3pLsfiVEdmiedAQWF94Dw" anchor="_u3pLsPiVEdmiedAQWF94Dw"/>
+ <anchorage xmi:id="_u3pLsPiVEdmiedAQWF94Dw" guid="_u3pLsPiVEdmiedAQWF94Dw" graphEdge="_u3pLsfiVEdmiedAQWF94Dw">
+ <position xmi:id="_u3pLs_iVEdmiedAQWF94Dw" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_vsKsEvfpEdmRMap9i-t5rw" guid="_vsKsEvfpEdmRMap9i-t5rw"/>
+ <size xmi:id="_vsKsE_fpEdmRMap9i-t5rw" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_cbi-oPinEdmugcVr9AdHjQ" guid="_cbi-oPinEdmugcVr9AdHjQ">
+ <position xmi:id="_cbi-ofinEdmugcVr9AdHjQ" x="159.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_lPt_UcmzEdqibaSI8nt1Ng" guid="_lPt_UcmzEdqibaSI8nt1Ng" anchor="_lPt_UMmzEdqibaSI8nt1Ng _lPt_UsmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_kx6pAsmzEdqibaSI8nt1Ng" guid="_kx6pAsmzEdqibaSI8nt1Ng" graphEdge="_kx6pAcmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_lPt_UMmzEdqibaSI8nt1Ng" guid="_lPt_UMmzEdqibaSI8nt1Ng" graphEdge="_lPt_UcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_lPt_U8mzEdqibaSI8nt1Ng" x="466.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_cbi-ovinEdmugcVr9AdHjQ" guid="_cbi-ovinEdmugcVr9AdHjQ" element="_WrXvwPinEdmugcVr9AdHjQ"/>
+ <size xmi:id="_cbi-o_inEdmugcVr9AdHjQ" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_pKjjgPr6EdmyhNQr5STrZQ" guid="_pKjjgPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_pKjjgfr6EdmyhNQr5STrZQ" x="11.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_43sr0R_bEdq3EKSIdbj-MA" guid="_43sr0R_bEdq3EKSIdbj-MA" anchor="_43sr0B_bEdq3EKSIdbj-MA _43sr0h_bEdq3EKSIdbj-MA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5mRCAR_bEdq3EKSIdbj-MA" guid="_5mRCAR_bEdq3EKSIdbj-MA" anchor="_5mRCAB_bEdq3EKSIdbj-MA _5mRCAh_bEdq3EKSIdbj-MA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_khkz8SliEdqjQsaFX0CJTw" guid="_khkz8SliEdqjQsaFX0CJTw" anchor="_khkz8CliEdqjQsaFX0CJTw _khkz8iliEdqjQsaFX0CJTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_kx6pAcmzEdqibaSI8nt1Ng" guid="_kx6pAcmzEdqibaSI8nt1Ng" anchor="_kx6pAMmzEdqibaSI8nt1Ng _kx6pAsmzEdqibaSI8nt1Ng"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_lukegcmzEdqibaSI8nt1Ng" guid="_lukegcmzEdqibaSI8nt1Ng" anchor="_lukegMmzEdqibaSI8nt1Ng _lukegsmzEdqibaSI8nt1Ng"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__cmb4dSIEdqANo9Ox5ktZQ" guid="__cmb4dSIEdqANo9Ox5ktZQ" anchor="__cmb4NSIEdqANo9Ox5ktZQ __cmb4tSIEdqANo9Ox5ktZQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_AMu4UdSJEdqANo9Ox5ktZQ" guid="_AMu4UdSJEdqANo9Ox5ktZQ" anchor="_AMu4UNSJEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_3eQzsh_bEdq3EKSIdbj-MA" guid="_3eQzsh_bEdq3EKSIdbj-MA" graphEdge="_3eQzsR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_n8v6UCliEdqjQsaFX0CJTw" x="312.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_43sr0B_bEdq3EKSIdbj-MA" guid="_43sr0B_bEdq3EKSIdbj-MA" graphEdge="_43sr0R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_jKl-0NSIEdqANo9Ox5ktZQ" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5mRCAB_bEdq3EKSIdbj-MA" guid="_5mRCAB_bEdq3EKSIdbj-MA" graphEdge="_5mRCAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_6GkyYNSIEdqANo9Ox5ktZQ" x="125.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_khkz8CliEdqjQsaFX0CJTw" guid="_khkz8CliEdqjQsaFX0CJTw" graphEdge="_khkz8SliEdqjQsaFX0CJTw">
+ <position xmi:id="_51qF0EqaEduiL77U_PmnmA" x="474.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_kx6pAMmzEdqibaSI8nt1Ng" guid="_kx6pAMmzEdqibaSI8nt1Ng" graphEdge="_kx6pAcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_oO8pgNSIEdqANo9Ox5ktZQ" x="197.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lukegMmzEdqibaSI8nt1Ng" guid="_lukegMmzEdqibaSI8nt1Ng" graphEdge="_lukegcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_sfVgoNSIEdqANo9Ox5ktZQ" x="276.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__cmb4NSIEdqANo9Ox5ktZQ" guid="__cmb4NSIEdqANo9Ox5ktZQ" graphEdge="__cmb4dSIEdqANo9Ox5ktZQ">
+ <position xmi:id="__cmb49SIEdqANo9Ox5ktZQ" x="369.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_AMu4UNSJEdqANo9Ox5ktZQ" guid="_AMu4UNSJEdqANo9Ox5ktZQ" graphEdge="_AMu4UdSJEdqANo9Ox5ktZQ">
+ <position xmi:id="_Fh4_INSJEdqANo9Ox5ktZQ" x="440.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_pKjjgvr6EdmyhNQr5STrZQ" guid="_pKjjgvr6EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_pKjjg_r6EdmyhNQr5STrZQ" width="563.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_zkKboPr6EdmyhNQr5STrZQ" guid="_zkKboPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_zkKbofr6EdmyhNQr5STrZQ" x="313.0" y="6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3eQzsR_bEdq3EKSIdbj-MA" guid="_3eQzsR_bEdq3EKSIdbj-MA" anchor="_3eQzsB_bEdq3EKSIdbj-MA _3eQzsh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_3eQzsB_bEdq3EKSIdbj-MA" guid="_3eQzsB_bEdq3EKSIdbj-MA" graphEdge="_3eQzsR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_3eQzsx_bEdq3EKSIdbj-MA" x="-30.0" y="13.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_zkKbovr6EdmyhNQr5STrZQ" guid="_zkKbovr6EdmyhNQr5STrZQ" typeInfo="start node"/>
+ <size xmi:id="_zkKbo_r6EdmyhNQr5STrZQ" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_045Z8Pr6EdmyhNQr5STrZQ" guid="_045Z8Pr6EdmyhNQr5STrZQ">
+ <position xmi:id="_045Z8fr6EdmyhNQr5STrZQ" x="6.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_BQKrQdSJEdqANo9Ox5ktZQ" guid="_BQKrQdSJEdqANo9Ox5ktZQ" anchor="_BQKrQNSJEdqANo9Ox5ktZQ _BQKrQtSJEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_5REOEh_bEdq3EKSIdbj-MA" guid="_5REOEh_bEdq3EKSIdbj-MA" graphEdge="_5REOER_bEdq3EKSIdbj-MA">
+ <position xmi:id="_ihuA8NSIEdqANo9Ox5ktZQ" x="53.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_55VvAh_bEdq3EKSIdbj-MA" guid="_55VvAh_bEdq3EKSIdbj-MA" graphEdge="_55VvAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_779msNSIEdqANo9Ox5ktZQ" x="130.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_82IQQh_bEdq3EKSIdbj-MA" guid="_82IQQh_bEdq3EKSIdbj-MA" graphEdge="_82IQQR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_eMr2MB_lEdq3EKSIdbj-MA" x="647.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lPt_UsmzEdqibaSI8nt1Ng" guid="_lPt_UsmzEdqibaSI8nt1Ng" graphEdge="_lPt_UcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_ow8jUNSIEdqANo9Ox5ktZQ" x="201.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_mDxScsmzEdqibaSI8nt1Ng" guid="_mDxScsmzEdqibaSI8nt1Ng" graphEdge="_mDxSccmzEdqibaSI8nt1Ng">
+ <position xmi:id="_9SfUwNSIEdqANo9Ox5ktZQ" x="280.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__10NItSIEdqANo9Ox5ktZQ" guid="__10NItSIEdqANo9Ox5ktZQ" graphEdge="__10NIdSIEdqANo9Ox5ktZQ">
+ <position xmi:id="__10NJNSIEdqANo9Ox5ktZQ" x="373.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_AoJB8tSJEdqANo9Ox5ktZQ" guid="_AoJB8tSJEdqANo9Ox5ktZQ">
+ <position xmi:id="_O7ytwNSJEdqANo9Ox5ktZQ" x="445.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_BQKrQNSJEdqANo9Ox5ktZQ" guid="_BQKrQNSJEdqANo9Ox5ktZQ" graphEdge="_BQKrQdSJEdqANo9Ox5ktZQ">
+ <position xmi:id="_BQKrQ9SJEdqANo9Ox5ktZQ" x="315.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-1HpckqaEduiL77U_PmnmA" guid="_-1HpckqaEduiL77U_PmnmA" graphEdge="_-1HpcUqaEduiL77U_PmnmA">
+ <position xmi:id="_-1HpdEqaEduiL77U_PmnmA" x="480.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_045Z8vr6EdmyhNQr5STrZQ" guid="_045Z8vr6EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_045Z8_r6EdmyhNQr5STrZQ" width="578.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_TCxawCliEdqjQsaFX0CJTw" guid="_TCxawCliEdqjQsaFX0CJTw">
+ <position xmi:id="_TCxawSliEdqjQsaFX0CJTw" x="436.0" y="164.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-1HpcUqaEduiL77U_PmnmA" guid="_-1HpcUqaEduiL77U_PmnmA" anchor="_-1HpcEqaEduiL77U_PmnmA _-1HpckqaEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_khkz8iliEdqjQsaFX0CJTw" guid="_khkz8iliEdqjQsaFX0CJTw" graphEdge="_khkz8SliEdqjQsaFX0CJTw">
+ <position xmi:id="_khkz9CliEdqjQsaFX0CJTw" x="651.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-1HpcEqaEduiL77U_PmnmA" guid="_-1HpcEqaEduiL77U_PmnmA" graphEdge="_-1HpcUqaEduiL77U_PmnmA">
+ <position xmi:id="_-1Hpc0qaEduiL77U_PmnmA" x="548.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_TCxawiliEdqjQsaFX0CJTw" guid="_TCxawiliEdqjQsaFX0CJTw" element="_TAVx0CliEdqjQsaFX0CJTw"/>
+ <size xmi:id="_TCxawyliEdqjQsaFX0CJTw" width="100.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS13dIWEdm9Cql_SeWu_A" guid="_ohS13dIWEdm9Cql_SeWu_A" presentation="Workflow" element="_0sTaYMlgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0sTaYMlgEdmt3adZL5Dmdw" name="elaboration_phase_iteration" guid="_0sTaYMlgEdmt3adZL5Dmdw" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Elaboration phase. Each activity and related goals are described." presentationName="Elaboration Phase Iteration" isRepeatable="true" breakdownElements="_0rWYIslgEdmt3adZL5Dmdw _0ruyoclgEdmt3adZL5Dmdw _0rcewclgEdmt3adZL5Dmdw _WrXvwPinEdmugcVr9AdHjQ _0rilYclgEdmt3adZL5Dmdw _TAVx0CliEdqjQsaFX0CJTw">
+ <presentation xmi:id="_mtb_BPL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_BPL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/inception_phase_iteration/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/inception_phase_iteration/content.xmi
new file mode 100644
index 0000000..982faec
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/inception_phase_iteration/content.xmi
@@ -0,0 +1,124 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-7PL5Edm6Nvont3uinw" guid="_mtb-7PL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-7_L5Edm6Nvont3uinw" guid="_mtb-7_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-8PL5Edm6Nvont3uinw" guid="_mtb-8PL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-8vL5Edm6Nvont3uinw" guid="_mtb-8vL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb-6_L5Edm6Nvont3uinw" guid="_mtb-6_L5Edm6Nvont3uinw">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The project starts with the assumption that the business case has been created, the <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> has been identified, the team (at least for the first iteration) has been defined, the development
+ environment (including tools and infrastructure) is in place, and the process to be followed is the <a
+ class="elementlinkwithusertext"
+ href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">delivery process</a> suggested by OpenUP/Basic. The number and length of each Inception
+ iteration will vary, depending upon the needs of the project.
+</p>
+<p>
+ In the next sections we describe the activities performed in a typical iteration during Inception phase.
+</p>
+<h4>
+ Initiate project
+</h4>
+<p>
+ This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity
+ is to establish the vision for the project and the project plan at a high level of granularity.
+</p>
+<p>
+ The people in the roles involved at this time collaborate to perform this activity:
+</p>
+<ul>
+ <li>
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html"
+ guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholder</a> roles work together to define the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> for the project, capturing the customer needs and features for the system
+ under development. Needs and features are captured to the extent required to reach agreement about the scope of the
+ project.
+ </li>
+ <li>
+ Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level <a
+ class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html"
+ guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases and time-boxed iterations for each phase. This
+ plan and the allocation of staff to the project evolve throughout the phases to reflect the project pace, as
+ necessary.
+ </li>
+</ul>
+<h4>
+ Manage iteration
+</h4>
+<p>
+ This activity is about the ongoing work performed by the project manager and the development team to initiate and
+ conduct a given iteration. It consists of status reporting, handling of exceptions and problems, identifying risks, and
+ reprioritizing work, as needed.
+</p>
+<p>
+ At the end of the iteration, the project manager conducts a&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html"
+ guid="_0bA2EMlgEdmt3adZL5Dmdw">status assessment</a> with the development team and stakeholders.
+</p>
+<p>
+ If the iteration end coincides with the phase end, meeting the objectives for that phase should be used as success
+ criteria for leaving the iteration. The iteration assessment should verify that the objectives&nbsp;for
+ the&nbsp;Iteration phase&nbsp;have been achieved, including agreement on the key functionalities and at least one
+ possible solution for the system under development, as well as a reasonable understanding of cost, schedule and risks
+ associated with the project.
+</p>
+<p>
+ Based on demonstration of key functionalities and architectural feasibility during the assessment, it becomes clear
+ that either the project can proceed at the given pace or that a reprioritization of work needs to happen. As a
+ consequence, the project manager may need to refine the project scope and duration.
+</p>
+<h4>
+ Manage requirements
+</h4>
+<p>
+ This activity is first performed in the first iteration, and repeated throughout the lifecycle.&nbsp; The goal of this
+ activity is to understand and prioritize stakeholder needs, and associated requirements for the system, and capture
+ these in a form that will support effective communications and collaboration between the stakeholders and development
+ team.
+</p>
+<p>
+ As the project is initiated, the&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>
+ gathers <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html"
+ guid="_0Wh-sMlgEdmt3adZL5Dmdw">requirements</a> from&nbsp;stakeholders and captures associated&nbsp;work items&nbsp;for
+ development in the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">work items list</a>&nbsp;to facilitate prioritization and planning. As needed,
+ requirements are outlined and detailed in&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">use-case</a> specifications and <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">supporting requirements</a>&nbsp;to the extent needed to provide information for the <a
+ class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> to create a prototype of the architecture and for the project manager to
+ scope and plan the next iteration.
+</p>
+<h4>
+ Determine architectural feasibility
+</h4>
+<p>
+ This activity is initiated in the Inception phase and completed in the Elaboration phase. The goal of this activity is
+ to establish an architecture for the system that provides the high-level design that maximizes&nbsp;stakeholder
+ benefit, while respecting the constraints placed on the system and the development team.
+</p>
+<p>
+ Based on requirements being captured and detailed in parallel with this activity, the architect analyzes the
+ architectural constraints and leverages the available assets and technology to propose an architectural
+ proof-of-concept. This early architectural prototype is used both to demonstrate the feasibility of the project, by
+ using the selected candidate architecture, and to mitigate one or more architecturally significant <a
+ class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html"
+ guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a>.
+</p></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/inception_phase_iteration/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/inception_phase_iteration/model.xmi
new file mode 100644
index 0000000..cc234ae
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/inception_phase_iteration/model.xmi
@@ -0,0 +1,193 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nJr2APL5Edm6Nvont3uinw" guid="_nJr2APL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nJHOQ_L5Edm6Nvont3uinw" id="_mtb-7PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74PilEdmugcVr9AdHjQ" id="_mtb-7_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74filEdmugcVr9AdHjQ" id="_mtb-8PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74vilEdmugcVr9AdHjQ" id="_mtb-8fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74_ilEdmugcVr9AdHjQ" id="_mtb-8vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf75PilEdmugcVr9AdHjQ" id="_mtb-6_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0oSdEclgEdmt3adZL5Dmdw" name="inception_phase_iteration" guid="_0oSdEclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0oSdEslgEdmt3adZL5Dmdw" name="initiate_project" guid="_0oSdEslgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0oSdE8lgEdmt3adZL5Dmdw" name="initiate_project" guid="_0oSdE8lgEdmt3adZL5Dmdw" presentationName="Initiate Project" superActivities="_0o3r4slgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb-7PL5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-7PL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNA8lgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0okw8MlgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0okw8MlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0okw8clgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0okw8clgEdmt3adZL5Dmdw" presentationName="Manage Requirements" superActivities="_0o3r4slgEdmt3adZL5Dmdw" linkToPredecessor="_IWodoClhEdqjQsaFX0CJTw" variabilityType="extends">
+ <presentation xmi:id="_mtb-7_L5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-7_L5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_IWodoClhEdqjQsaFX0CJTw" guid="_IWodoClhEdqjQsaFX0CJTw" linkType="finishToFinish" pred="_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0oreoMlgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0oreoMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0oreoclgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0oreoclgEdmt3adZL5Dmdw" presentationName="Determine Architectural Feasibility" isOptional="true" superActivities="_0o3r4slgEdmt3adZL5Dmdw" linkToPredecessor="_IW0q4ClhEdqjQsaFX0CJTw" variabilityType="extends">
+ <presentation xmi:id="_mtb-8PL5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-8PL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_IW0q4ClhEdqjQsaFX0CJTw" guid="_IW0q4ClhEdqjQsaFX0CJTw" linkType="finishToFinish" pred="_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_jK8QsP77Edm1zMZYtD3GjA" name="manage_iteration" guid="_jK8QsP77Edm1zMZYtD3GjA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_jLaKwP77Edm1zMZYtD3GjA" name="manage_iteration" guid="_jLaKwP77Edm1zMZYtD3GjA" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_0o3r4slgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <diagrams xmi:id="_GRgRUMlzEdmkFIUsXH7ISQ" guid="_GRgRUMlzEdmkFIUsXH7ISQ">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRUclzEdmkFIUsXH7ISQ" guid="_GRgRUclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRUslzEdmkFIUsXH7ISQ" x="111.0" y="102.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_lY0Msfr5EdmyhNQr5STrZQ" guid="_lY0Msfr5EdmyhNQr5STrZQ" anchor="_lY0MsPr5EdmyhNQr5STrZQ _lY0Msvr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_kAcrkvr5EdmyhNQr5STrZQ" guid="_kAcrkvr5EdmyhNQr5STrZQ" graphEdge="_kAcrkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_kAcrlPr5EdmyhNQr5STrZQ" x="26.0" y="-28.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lY0MsPr5EdmyhNQr5STrZQ" guid="_lY0MsPr5EdmyhNQr5STrZQ" graphEdge="_lY0Msfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_lY0Ms_r5EdmyhNQr5STrZQ" x="25.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRU8lzEdmkFIUsXH7ISQ" guid="_GRgRU8lzEdmkFIUsXH7ISQ" element="_0oSdE8lgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_GRgRVMlzEdmkFIUsXH7ISQ" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRVclzEdmkFIUsXH7ISQ" guid="_GRgRVclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRVslzEdmkFIUsXH7ISQ" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRV8lzEdmkFIUsXH7ISQ" guid="_GRgRV8lzEdmkFIUsXH7ISQ"/>
+ <size xmi:id="_GRgRWMlzEdmkFIUsXH7ISQ" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRWclzEdmkFIUsXH7ISQ" guid="_GRgRWclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRWslzEdmkFIUsXH7ISQ" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRW8lzEdmkFIUsXH7ISQ" guid="_GRgRW8lzEdmkFIUsXH7ISQ"/>
+ <size xmi:id="_GRgRXMlzEdmkFIUsXH7ISQ" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRXclzEdmkFIUsXH7ISQ" guid="_GRgRXclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRXslzEdmkFIUsXH7ISQ" x="-25.0" y="204.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nSH3sfr5EdmyhNQr5STrZQ" guid="_nSH3sfr5EdmyhNQr5STrZQ" anchor="_nSH3sPr5EdmyhNQr5STrZQ _nSN-UPr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_m14novr5EdmyhNQr5STrZQ" guid="_m14novr5EdmyhNQr5STrZQ" graphEdge="_m14nofr5EdmyhNQr5STrZQ">
+ <position xmi:id="_m14npPr5EdmyhNQr5STrZQ" x="100.0" y="-13.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nSH3sPr5EdmyhNQr5STrZQ" guid="_nSH3sPr5EdmyhNQr5STrZQ" graphEdge="_nSH3sfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_nSUE8Pr5EdmyhNQr5STrZQ" x="97.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRX8lzEdmkFIUsXH7ISQ" guid="_GRgRX8lzEdmkFIUsXH7ISQ" element="_0okw8clgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_GRgRYMlzEdmkFIUsXH7ISQ" width="207.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRYclzEdmkFIUsXH7ISQ" guid="_GRgRYclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRYslzEdmkFIUsXH7ISQ" x="108.0" y="238.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oB5u0fr5EdmyhNQr5STrZQ" guid="_oB5u0fr5EdmyhNQr5STrZQ" anchor="_oB5u0Pr5EdmyhNQr5STrZQ _oB5u0vr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_nxJWAvr5EdmyhNQr5STrZQ" guid="_nxJWAvr5EdmyhNQr5STrZQ" graphEdge="_nxJWAfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_nxJWBPr5EdmyhNQr5STrZQ" x="73.0" y="-85.0"/>
+ </anchorage>
+ <anchorage xmi:id="_oB5u0Pr5EdmyhNQr5STrZQ" guid="_oB5u0Pr5EdmyhNQr5STrZQ" graphEdge="_oB5u0fr5EdmyhNQr5STrZQ">
+ <position xmi:id="_oB5u0_r5EdmyhNQr5STrZQ" x="79.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRY8lzEdmkFIUsXH7ISQ" guid="_GRgRY8lzEdmkFIUsXH7ISQ" element="_0oreoclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_GRgRZMlzEdmkFIUsXH7ISQ" width="164.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRZclzEdmkFIUsXH7ISQ" guid="_GRgRZclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRZslzEdmkFIUsXH7ISQ" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mESLkfr5EdmyhNQr5STrZQ" guid="_mESLkfr5EdmyhNQr5STrZQ" anchor="_mESLkPr5EdmyhNQr5STrZQ _mESLkvr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_mESLkPr5EdmyhNQr5STrZQ" guid="_mESLkPr5EdmyhNQr5STrZQ" graphEdge="_mESLkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_mESLk_r5EdmyhNQr5STrZQ" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRZ8lzEdmkFIUsXH7ISQ" guid="_GRgRZ8lzEdmkFIUsXH7ISQ"/>
+ <size xmi:id="_GRgRaMlzEdmkFIUsXH7ISQ" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_UGg-cPr5EdmyhNQr5STrZQ" guid="_UGg-cPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_UGg-cfr5EdmyhNQr5STrZQ" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_UGg-cvr5EdmyhNQr5STrZQ" guid="_UGg-cvr5EdmyhNQr5STrZQ"/>
+ <size xmi:id="_UGg-c_r5EdmyhNQr5STrZQ" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_boMAIPr5EdmyhNQr5STrZQ" guid="_boMAIPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_boMAIfr5EdmyhNQr5STrZQ" x="5.0" y="68.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_kAcrkfr5EdmyhNQr5STrZQ" guid="_kAcrkfr5EdmyhNQr5STrZQ" anchor="_kAcrkPr5EdmyhNQr5STrZQ _kAcrkvr5EdmyhNQr5STrZQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_i_klQQheEdqqjIx6JFygWA" guid="_i_klQQheEdqqjIx6JFygWA" anchor="_i_klQAheEdqqjIx6JFygWA _i_klQgheEdqqjIx6JFygWA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__xwpAdSHEdqANo9Ox5ktZQ" guid="__xwpAdSHEdqANo9Ox5ktZQ" anchor="__xwpANSHEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_kAcrkPr5EdmyhNQr5STrZQ" guid="_kAcrkPr5EdmyhNQr5STrZQ" graphEdge="_kAcrkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_87PH0NSHEdqANo9Ox5ktZQ" x="145.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_i_klQAheEdqqjIx6JFygWA" guid="_i_klQAheEdqqjIx6JFygWA" graphEdge="_i_klQQheEdqqjIx6JFygWA">
+ <position xmi:id="_41Pi0NSHEdqANo9Ox5ktZQ" x="332.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_OMFr8h_bEdq3EKSIdbj-MA" guid="_OMFr8h_bEdq3EKSIdbj-MA" graphEdge="_OMFr8R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_eJhJUMBKEdqSgKaj2SZBmg" x="179.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__xwpANSHEdqANo9Ox5ktZQ" guid="__xwpANSHEdqANo9Ox5ktZQ" graphEdge="__xwpAdSHEdqANo9Ox5ktZQ">
+ <position xmi:id="_DOlVMNSIEdqANo9Ox5ktZQ" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_boMAIvr5EdmyhNQr5STrZQ" guid="_boMAIvr5EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_boMAI_r5EdmyhNQr5STrZQ" width="454.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_cV9FEPr5EdmyhNQr5STrZQ" guid="_cV9FEPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_cWDLsPr5EdmyhNQr5STrZQ" x="26.0" y="169.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_m14nofr5EdmyhNQr5STrZQ" guid="_m14nofr5EdmyhNQr5STrZQ" anchor="_m14noPr5EdmyhNQr5STrZQ _m14novr5EdmyhNQr5STrZQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nxJWAfr5EdmyhNQr5STrZQ" guid="_nxJWAfr5EdmyhNQr5STrZQ" anchor="_nxJWAPr5EdmyhNQr5STrZQ _nxJWAvr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_m14noPr5EdmyhNQr5STrZQ" guid="_m14noPr5EdmyhNQr5STrZQ" graphEdge="_m14nofr5EdmyhNQr5STrZQ">
+ <position xmi:id="_9yf8gMA6EdqSgKaj2SZBmg" x="52.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nxJWAPr5EdmyhNQr5STrZQ" guid="_nxJWAPr5EdmyhNQr5STrZQ" graphEdge="_nxJWAfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_y3M3ENSHEdqANo9Ox5ktZQ" x="163.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lY0Msvr5EdmyhNQr5STrZQ" guid="_lY0Msvr5EdmyhNQr5STrZQ" graphEdge="_lY0Msfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_6JfY8NSHEdqANo9Ox5ktZQ" x="124.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_cWDLsfr5EdmyhNQr5STrZQ" guid="_cWDLsfr5EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_cWDLsvr5EdmyhNQr5STrZQ" width="225.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_f4q94Pr5EdmyhNQr5STrZQ" guid="_f4q94Pr5EdmyhNQr5STrZQ">
+ <position xmi:id="_f4q94fr5EdmyhNQr5STrZQ" x="4.0" y="344.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__Ubz0dSHEdqANo9Ox5ktZQ" guid="__Ubz0dSHEdqANo9Ox5ktZQ" anchor="__Ubz0NSHEdqANo9Ox5ktZQ __Ubz0tSHEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_mESLkvr5EdmyhNQr5STrZQ" guid="_mESLkvr5EdmyhNQr5STrZQ" graphEdge="_mESLkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_zY-UwPr5EdmyhNQr5STrZQ" x="134.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nSN-UPr5EdmyhNQr5STrZQ" guid="_nSN-UPr5EdmyhNQr5STrZQ" graphEdge="_nSH3sfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_vakYINSHEdqANo9Ox5ktZQ" x="74.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_oB5u0vr5EdmyhNQr5STrZQ" guid="_oB5u0vr5EdmyhNQr5STrZQ" graphEdge="_oB5u0fr5EdmyhNQr5STrZQ">
+ <position xmi:id="_zzkYsNSHEdqANo9Ox5ktZQ" x="186.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_jasbAgheEdqqjIx6JFygWA" guid="_jasbAgheEdqqjIx6JFygWA" graphEdge="_jasbAQheEdqqjIx6JFygWA">
+ <position xmi:id="_16__QNSHEdqANo9Ox5ktZQ" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__Ubz0NSHEdqANo9Ox5ktZQ" guid="__Ubz0NSHEdqANo9Ox5ktZQ" graphEdge="__Ubz0dSHEdqANo9Ox5ktZQ">
+ <position xmi:id="__Ubz09SHEdqANo9Ox5ktZQ" x="189.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_AIfG8tSIEdqANo9Ox5ktZQ" guid="_AIfG8tSIEdqANo9Ox5ktZQ">
+ <position xmi:id="_AIfG9NSIEdqANo9Ox5ktZQ" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_f4q94vr5EdmyhNQr5STrZQ" guid="_f4q94vr5EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_f4q94_r5EdmyhNQr5STrZQ" width="463.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_iEptQPr5EdmyhNQr5STrZQ" guid="_iEptQPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_iEptQfr5EdmyhNQr5STrZQ" x="175.0" y="19.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_OMFr8R_bEdq3EKSIdbj-MA" guid="_OMFr8R_bEdq3EKSIdbj-MA" anchor="_OMFr8B_bEdq3EKSIdbj-MA _OMFr8h_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_OMFr8B_bEdq3EKSIdbj-MA" guid="_OMFr8B_bEdq3EKSIdbj-MA" graphEdge="_OMFr8R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_OMFr8x_bEdq3EKSIdbj-MA" x="8.0" y="-1.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_iEptQvr5EdmyhNQr5STrZQ" guid="_iEptQvr5EdmyhNQr5STrZQ" typeInfo="start node"/>
+ <size xmi:id="_iEptQ_r5EdmyhNQr5STrZQ" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_idu7oPr5EdmyhNQr5STrZQ" guid="_idu7oPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_idu7ofr5EdmyhNQr5STrZQ" x="182.0" y="382.0"/>
+ <anchorage xmi:id="__Ubz0tSHEdqANo9Ox5ktZQ" guid="__Ubz0tSHEdqANo9Ox5ktZQ" graphEdge="__Ubz0dSHEdqANo9Ox5ktZQ"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_idu7ovr5EdmyhNQr5STrZQ" guid="_idu7ovr5EdmyhNQr5STrZQ" typeInfo="end node"/>
+ <size xmi:id="_idu7o_r5EdmyhNQr5STrZQ" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_aYcXYAheEdqqjIx6JFygWA" guid="_aYcXYAheEdqqjIx6JFygWA">
+ <position xmi:id="_aYcXYQheEdqqjIx6JFygWA" x="296.0" y="145.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_jasbAQheEdqqjIx6JFygWA" guid="_jasbAQheEdqqjIx6JFygWA" anchor="_jasbAAheEdqqjIx6JFygWA _jasbAgheEdqqjIx6JFygWA"/>
+ <anchorage xmi:id="_i_klQgheEdqqjIx6JFygWA" guid="_i_klQgheEdqqjIx6JFygWA" graphEdge="_i_klQQheEdqqjIx6JFygWA">
+ <position xmi:id="_i_klRAheEdqqjIx6JFygWA" x="33.0" y="-129.0"/>
+ </anchorage>
+ <anchorage xmi:id="_jasbAAheEdqqjIx6JFygWA" guid="_jasbAAheEdqqjIx6JFygWA" graphEdge="_jasbAQheEdqqjIx6JFygWA">
+ <position xmi:id="_jasbAwheEdqqjIx6JFygWA" x="39.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_aYieAAheEdqqjIx6JFygWA" guid="_aYieAAheEdqqjIx6JFygWA" element="_jLaKwP77Edm1zMZYtD3GjA"/>
+ <size xmi:id="_aYieAQheEdqqjIx6JFygWA" width="83.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRbclzEdmkFIUsXH7ISQ" guid="_GRgRbclzEdmkFIUsXH7ISQ" presentation="Workflow" element="_0o3r4slgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0o3r4slgEdmt3adZL5Dmdw" name="inception_phase_iteration" guid="_0o3r4slgEdmt3adZL5Dmdw" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Inception phase. Each activity and related goals are described." presentationName="Inception Phase Iteration" breakdownElements="_0oSdE8lgEdmt3adZL5Dmdw _jLaKwP77Edm1zMZYtD3GjA _0okw8clgEdmt3adZL5Dmdw _0oreoclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_mtb-6_L5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-6_L5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/initiate_project/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/initiate_project/content.xmi
new file mode 100644
index 0000000..02b0e2b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/initiate_project/content.xmi
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-9fL5Edm6Nvont3uinw" guid="_mtb-9fL5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity
+ is to establish the vision for the project and the project plan at a high level of granularity.
+</p>
+<p>
+ The people in the roles involved at this time collaborate to perform this activity:
+</p>
+<ul>
+ <li>
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholder</a> roles work together to define the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> for the project, capturing the customer needs and features for the system
+ under development. Needs and features are captured to the extent required to reach agreement about the scope of the
+ project.
+ </li>
+ <li>
+ Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases and time-boxed iterations for each phase. This
+ plan and the allocation of staff to the project evolve throughout the phases&nbsp;and defines the pace of the
+ project.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/initiate_project/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/initiate_project/model.xmi
new file mode 100644
index 0000000..fddbfc9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/initiate_project/model.xmi
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nJx8oPL5Edm6Nvont3uinw" guid="_nJx8oPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nJr2A_L5Edm6Nvont3uinw" id="_mtb-9fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0pWNAslgEdmt3adZL5Dmdw" name="initiate_project" guid="_0pWNAslgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_VNpT0FY5EdqI9sTOt2pjHw" name="analyst" guid="_VNpT0FY5EdqI9sTOt2pjHw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" responsibleFor="_PFnTkOB7EdqnKu908IEluw _VNvacFY5EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_VNvacFY5EdqI9sTOt2pjHw" name="vision" guid="_VNvacFY5EdqI9sTOt2pjHw" presentationName="Vision" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_XKDWIFY5EdqI9sTOt2pjHw" name="plan_the_project" guid="_XKDWIFY5EdqI9sTOt2pjHw" presentationName="Plan the Project" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" additionallyPerformedBy="_S8dNQMBFEdqSgKaj2SZBmg _VNpT0FY5EdqI9sTOt2pjHw _S8dNQsBFEdqSgKaj2SZBmg _J8-00MAZEdqX-s4mWhkyqQ" mandatoryInput="_VNvacFY5EdqI9sTOt2pjHw _4Y1wML3JEdqfrv3k16plXw" optionalInput="_XKbwoFY5EdqI9sTOt2pjHw _hhnXEDeqEduCsbgJNeFsSw" output="_XKbwoFY5EdqI9sTOt2pjHw _4Y1wML3JEdqfrv3k16plXw _hhnXEDeqEduCsbgJNeFsSw" performedPrimarilyBy="_XKVqAFY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0lC70MlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_lrYj0MBAEdqSgKaj2SZBmg"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_k1bY4MMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_OfFTEABjEdqHlpDr8LcRqg"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_F2dQYABjEdqHlpDr8LcRqg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_XKVqAFY5EdqI9sTOt2pjHw" name="project_manager" guid="_XKVqAFY5EdqI9sTOt2pjHw" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" responsibleFor="_hhnXEDeqEduCsbgJNeFsSw _4Y1wML3JEdqfrv3k16plXw _XKbwoFY5EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_XKbwoFY5EdqI9sTOt2pjHw" name="project_plan" guid="_XKbwoFY5EdqI9sTOt2pjHw" presentationName="Project Plan" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a6vcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_4Y1wML3JEdqfrv3k16plXw" name="work_items_list" guid="_4Y1wML3JEdqfrv3k16plXw" presentationName="Work Items List" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_J8-00MAZEdqX-s4mWhkyqQ" name="stakeholder" guid="_J8-00MAZEdqX-s4mWhkyqQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_S8dNQMBFEdqSgKaj2SZBmg" name="architect" guid="_S8dNQMBFEdqSgKaj2SZBmg" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_S8dNQsBFEdqSgKaj2SZBmg" name="tester" guid="_S8dNQsBFEdqSgKaj2SZBmg" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_PFnTkOB7EdqnKu908IEluw" name="glossary" guid="_PFnTkOB7EdqnKu908IEluw" presentationName="Glossary" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_hhnXEDeqEduCsbgJNeFsSw" name="risk_list" guid="_hhnXEDeqEduCsbgJNeFsSw" presentationName="Risk List" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Ckay8Cc_EduIsqH1Q6ZuqA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_79bQ4DoCEdu0yYZ2bsCXog" name="define_vision" guid="_79bQ4DoCEdu0yYZ2bsCXog" presentationName="Define Vision" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" additionallyPerformedBy="_J8-00MAZEdqX-s4mWhkyqQ" optionalInput="_VNvacFY5EdqI9sTOt2pjHw" output="_VNvacFY5EdqI9sTOt2pjHw _PFnTkOB7EdqnKu908IEluw" performedPrimarilyBy="_VNpT0FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0fOAoMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_tvzDULwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_sa5F4LwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_rliOAOz2Edq2wJOsmRwmhg"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_vGg-oLwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_z7ZC4LwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_1LVn0LwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_2VixILwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_AhjmAL-GEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <diagrams xmi:id="_CYoF0Ml0EdmkFIUsXH7ISQ" guid="_CYoF0Ml0EdmkFIUsXH7ISQ">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_CYoF0cl0EdmkFIUsXH7ISQ" guid="_CYoF0cl0EdmkFIUsXH7ISQ" presentation="Work Product Dependency">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ </diagrams>
+ <diagrams xmi:id="_RTY08Ml0EdmkFIUsXH7ISQ" guid="_RTY08Ml0EdmkFIUsXH7ISQ">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_RTY08cl0EdmkFIUsXH7ISQ" guid="_RTY08cl0EdmkFIUsXH7ISQ" presentation="Activity Detail">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0pWNA8lgEdmt3adZL5Dmdw" name="initiate_project" guid="_0pWNA8lgEdmt3adZL5Dmdw" briefDescription="This capability pattern bundles tasks required to define the vision and create a project plan." presentationName="Initiate Project" breakdownElements="_VNpT0FY5EdqI9sTOt2pjHw _VNvacFY5EdqI9sTOt2pjHw _79bQ4DoCEdu0yYZ2bsCXog _XKDWIFY5EdqI9sTOt2pjHw _XKVqAFY5EdqI9sTOt2pjHw _XKbwoFY5EdqI9sTOt2pjHw _4Y1wML3JEdqfrv3k16plXw _J8-00MAZEdqX-s4mWhkyqQ _S8dNQMBFEdqSgKaj2SZBmg _S8dNQsBFEdqSgKaj2SZBmg _PFnTkOB7EdqnKu908IEluw _hhnXEDeqEduCsbgJNeFsSw">
+ <presentation xmi:id="_mtb-9fL5Edm6Nvont3uinw" href="uma://_mtb-9fL5Edm6Nvont3uinw#_mtb-9fL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_iteration/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_iteration/content.xmi
new file mode 100644
index 0000000..6b9e88e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_iteration/content.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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="_mtb-6PL5Edm6Nvont3uinw" guid="_mtb-6PL5Edm6Nvont3uinw"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_iteration/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_iteration/model.xmi
new file mode 100644
index 0000000..0abaee4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_iteration/model.xmi
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nI06YvL5Edm6Nvont3uinw" guid="_nI06YvL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nI06YfL5Edm6Nvont3uinw" id="_mtb-6PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0nJNkclgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0nJNkclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_mZDP4FY5EdqI9sTOt2pjHw" name="project_manager" guid="_mZDP4FY5EdqI9sTOt2pjHw" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw" responsibleFor="_TPsdoUmSEduO0bs89Khm8Q _DUCuoDk-EduFTqg5hiiQIw _oNnk0FY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _mZVjwFY5EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_mZVjwFY5EdqI9sTOt2pjHw" name="iteration_plan" guid="_mZVjwFY5EdqI9sTOt2pjHw" presentationName="Iteration Plan" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0aQBEslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_mZt-QFY5EdqI9sTOt2pjHw" name="project_plan" guid="_mZt-QFY5EdqI9sTOt2pjHw" presentationName="Project Plan" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a6vcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_oNJDsFY5EdqI9sTOt2pjHw" name="manage_iteration" guid="_oNJDsFY5EdqI9sTOt2pjHw" presentationName="Manage Iteration" superActivities="_0nJNkslgEdmt3adZL5Dmdw" additionallyPerformedBy="_DT8oADk-EduFTqg5hiiQIw _DT8oATk-EduFTqg5hiiQIw _DT8oAjk-EduFTqg5hiiQIw _DT8oAzk-EduFTqg5hiiQIw _DT8oBDk-EduFTqg5hiiQIw _DT8oBTk-EduFTqg5hiiQIw" mandatoryInput="_mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw _DUCuoDk-EduFTqg5hiiQIw" output="_mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw _DUCuoDk-EduFTqg5hiiQIw" performedPrimarilyBy="_mZDP4FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_8S2aICbYEdqh1LYUOGRh2A"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_OE65ICuxEdqTIKp3l5PtzQ"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_ztF0UCuxEdqTIKp3l5PtzQ"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_oIZdkCbZEdqh1LYUOGRh2A"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_xiFJwCbZEdqh1LYUOGRh2A"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_Br6VECuxEdqTIKp3l5PtzQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_oNnk0FY5EdqI9sTOt2pjHw" name="work_items_list" guid="_oNnk0FY5EdqI9sTOt2pjHw" presentationName="Work Items List" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oADk-EduFTqg5hiiQIw" name="analyst" guid="_DT8oADk-EduFTqg5hiiQIw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw" responsibleFor="_SZOIoUmSEduO0bs89Khm8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oATk-EduFTqg5hiiQIw" name="architect" guid="_DT8oATk-EduFTqg5hiiQIw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw" responsibleFor="_SZOIoEmSEduO0bs89Khm8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oAjk-EduFTqg5hiiQIw" name="tester" guid="_DT8oAjk-EduFTqg5hiiQIw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oAzk-EduFTqg5hiiQIw" name="developer" guid="_DT8oAzk-EduFTqg5hiiQIw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oBDk-EduFTqg5hiiQIw" name="any_role" guid="_DT8oBDk-EduFTqg5hiiQIw" presentationName="Any Role" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0dsWoMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oBTk-EduFTqg5hiiQIw" name="stakeholder" guid="_DT8oBTk-EduFTqg5hiiQIw" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_DUCuoDk-EduFTqg5hiiQIw" name="risk_list" guid="_DUCuoDk-EduFTqg5hiiQIw" presentationName="Risk List" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Ckay8Cc_EduIsqH1Q6ZuqA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_SZICAEmSEduO0bs89Khm8Q" name="plan_iteration" guid="_SZICAEmSEduO0bs89Khm8Q" presentationName="Plan Iteration" superActivities="_0nJNkslgEdmt3adZL5Dmdw" additionallyPerformedBy="_DT8oATk-EduFTqg5hiiQIw _DT8oADk-EduFTqg5hiiQIw _DT8oAjk-EduFTqg5hiiQIw _DT8oAzk-EduFTqg5hiiQIw _DT8oBTk-EduFTqg5hiiQIw" mandatoryInput="_mZt-QFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw" optionalInput="_SZOIoEmSEduO0bs89Khm8Q _SZOIoUmSEduO0bs89Khm8Q" output="_mZVjwFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw" performedPrimarilyBy="_mZDP4FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0keUEMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_CtKCMMBHEdqSgKaj2SZBmg"/>
+ <selectedSteps href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_307v0MMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_7Hqr4MMsEdmdo9HxCRR_Gw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_SZOIoEmSEduO0bs89Khm8Q" name="architecture" guid="_SZOIoEmSEduO0bs89Khm8Q" presentationName="Architecture" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_SZOIoUmSEduO0bs89Khm8Q" name="vision" guid="_SZOIoUmSEduO0bs89Khm8Q" presentationName="Vision" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_TPsdoEmSEduO0bs89Khm8Q" name="assess_results" guid="_TPsdoEmSEduO0bs89Khm8Q" presentationName="Assess Results" superActivities="_0nJNkslgEdmt3adZL5Dmdw" additionallyPerformedBy="_DT8oBTk-EduFTqg5hiiQIw _DT8oBDk-EduFTqg5hiiQIw" mandatoryInput="_mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw" optionalInput="_TPsdoUmSEduO0bs89Khm8Q _SZOIoUmSEduO0bs89Khm8Q" output="_TPsdoUmSEduO0bs89Khm8Q" performedPrimarilyBy="_mZDP4FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0l53cMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_o28GgMMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_PABe4MQIEdmaiYJe8-Eaqg"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_YdoAAM1DEdmLoKw_mVTvhQ"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_wp2CIMMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_1YHH8DLqEdueZPye-FaNgA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_TPsdoUmSEduO0bs89Khm8Q" name="status_assessment" guid="_TPsdoUmSEduO0bs89Khm8Q" presentationName="Status Assessment" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0bA2EMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0nJNkslgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0nJNkslgEdmt3adZL5Dmdw" briefDescription="Initiate the iteration and assign work to team members. Monitor and communicate project status to external stakeholders. Identify and handle exceptions and problems." presentationName="Plan and Manage Iteration" isPlanned="false" hasMultipleOccurrences="true" isOngoing="true" breakdownElements="_mZDP4FY5EdqI9sTOt2pjHw _mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _SZICAEmSEduO0bs89Khm8Q _oNJDsFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw _DT8oADk-EduFTqg5hiiQIw _DT8oATk-EduFTqg5hiiQIw _DT8oAjk-EduFTqg5hiiQIw _DT8oAzk-EduFTqg5hiiQIw _DT8oBDk-EduFTqg5hiiQIw _DT8oBTk-EduFTqg5hiiQIw _DUCuoDk-EduFTqg5hiiQIw _SZOIoEmSEduO0bs89Khm8Q _SZOIoUmSEduO0bs89Khm8Q _TPsdoEmSEduO0bs89Khm8Q _TPsdoUmSEduO0bs89Khm8Q">
+ <presentation xmi:id="_mtb-6PL5Edm6Nvont3uinw" href="uma://_mtb-6PL5Edm6Nvont3uinw#_mtb-6PL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_requirements/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_requirements/content.xmi
new file mode 100644
index 0000000..f011a27
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_requirements/content.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-8_L5Edm6Nvont3uinw" guid="_mtb-8_L5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity describes the tasks performed to&nbsp;gather, specify, analyze and&nbsp;validate&nbsp;a subset of
+ system's&nbsp;requirements&nbsp;prior to&nbsp;implementation and verification. This does not imply that all
+ requirements are detailed prior to commencing implementation. Rather, this activity is performed throughout the
+ lifecycle with <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s and the entire development team collaborating to ensure that a clear,
+ consistent, correct, verifiable, and feasible&nbsp;set of requirements&nbsp;is available, as needed, to drive
+ implementation and verification.
+</p>
+<p>
+ During Inception, the focus is on&nbsp;gaining agreement on&nbsp;the problem to be solved, gathering stakeholder needs
+ and capturing high-level system features&nbsp;(see activity <a class="elementLink" href="./../../openup_basic/capabilitypatterns/initiate_project,_0pWNA8lgEdmt3adZL5Dmdw.html" guid="_0pWNA8lgEdmt3adZL5Dmdw">Initiate Project</a>).
+</p>
+<p>
+ During Elaboration, the focus shifts to defining the solution. This consists of&nbsp;finding those requirements that
+ have most value to stakeholders, that are particularly challenging or risky, or that are architecturally significant
+ (See <a class="elementLinkWithType" href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>).&nbsp;Requirements&nbsp;that
+ are&nbsp;prioritized, via the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>,&nbsp;for implementation in the early iterations are then described
+ in sufficient detail to validate the development teams understanding of the requirements, to ensure concurrence with
+ stakeholders, and to permit software development to begin (see <a class="elementLinkWithType" href="./../../openup_basic/tasks/detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw.html" guid="_0e1mIMlgEdmt3adZL5Dmdw">Task: Detail Requirements</a>). For each of these requirements, associated test cases are defined to ensure that the
+ requirements are verifiable and to provide the guidance needed for verification and validation (see <a class="elementLinkWithType" href="./../../openup_basic/tasks/create_test_case,_0iwc0clgEdmt3adZL5Dmdw.html" guid="_0iwc0clgEdmt3adZL5Dmdw">Task: Create Test Cases</a>).
+</p>
+<p>
+ During Construction, the focus shifts to refining the system definition<em>.</em> This consists of detailing the
+ remaining requirements and associated test cases as needed to drive implementation and verification, and managing
+ requirements change (see&nbsp;activity <a class="elementLink" href="./../../openup_basic/capabilitypatterns/ongoing_tasks,_0pJ_xslgEdmt3adZL5Dmdw.html" guid="_0pJ_xslgEdmt3adZL5Dmdw">Ongoing Tasks</a>).
+</p></mainDescription>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_requirements/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_requirements/model.xmi
new file mode 100644
index 0000000..c468b7a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/manage_requirements/model.xmi
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nKQdwPL5Edm6Nvont3uinw" guid="_nKQdwPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nKKXI_L5Edm6Nvont3uinw" id="_mtb-8_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0o9ygMlgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0o9ygMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_wGSUwFY6EdqI9sTOt2pjHw" name="analyst" guid="_wGSUwFY6EdqI9sTOt2pjHw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw" responsibleFor="_86w-oOB4EdqnKu908IEluw _Y5DAMb-EEdqb7N6KIeDL8Q _wG28gFY6EdqI9sTOt2pjHw _wGw14FY6EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_wGeiAFY6EdqI9sTOt2pjHw" name="use_case" guid="_wGeiAFY6EdqI9sTOt2pjHw" presentationName="Use Case" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_wGw14FY6EdqI9sTOt2pjHw" name="vision" guid="_wGw14FY6EdqI9sTOt2pjHw" presentationName="Vision" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_wG28gFY6EdqI9sTOt2pjHw" name="uc_model" guid="_wG28gFY6EdqI9sTOt2pjHw" presentationName="Use-Case Model" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_Y42y8L-EEdqb7N6KIeDL8Q" name="find_and_outline_requirements" guid="_Y42y8L-EEdqb7N6KIeDL8Q" presentationName="Find and Outline Requirements" superActivities="_0o9ygclgEdmt3adZL5Dmdw" additionallyPerformedBy="_2tHGoMAYEdqX-s4mWhkyqQ _F6WiEMEQEduTGJ8i4u8TMw _F6WiEcEQEduTGJ8i4u8TMw _kF8tYDbsEduMn613sF6-Uw" mandatoryInput="_86w-oOB4EdqnKu908IEluw _wGw14FY6EdqI9sTOt2pjHw" output="_Y5DAML-EEdqb7N6KIeDL8Q _Y5DAMb-EEdqb7N6KIeDL8Q _86w-oOB4EdqnKu908IEluw _wGeiAFY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw" performedPrimarilyBy="_wGSUwFY6EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_P9cMUPV_EdmdHa9MmVPgqQ"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_ckG-cCY-EdqNHcQ-rAojXw"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_GAr3IOz3Edq2wJOsmRwmhg"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_fDbgkCY-EdqNHcQ-rAojXw"/>
+ <selectedSteps href="uma://-Yt8TXGkE1rwydXR34apsrg#_XRKgkAFoEduDPKiaP0pu-Q"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_0WhHsN-eEdqiM_wFaqLjNg"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_Mgb9IC4DEduBP8F-6-95NQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_Y5DAML-EEdqb7N6KIeDL8Q" name="work_items_list" guid="_Y5DAML-EEdqb7N6KIeDL8Q" presentationName="Work Items List" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_Y5DAMb-EEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_Y5DAMb-EEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_ZRfVYL-EEdqb7N6KIeDL8Q" name="detail_requirements" guid="_ZRfVYL-EEdqb7N6KIeDL8Q" presentationName="Detail Requirements" superActivities="_0o9ygclgEdmt3adZL5Dmdw" additionallyPerformedBy="_2tHGoMAYEdqX-s4mWhkyqQ _F6WiEMEQEduTGJ8i4u8TMw _F6WiEcEQEduTGJ8i4u8TMw _kF8tYDbsEduMn613sF6-Uw" mandatoryInput="_Y5DAMb-EEdqb7N6KIeDL8Q _wGw14FY6EdqI9sTOt2pjHw _86w-oOB4EdqnKu908IEluw _wGeiAFY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw" output="_Y5DAMb-EEdqb7N6KIeDL8Q _86w-oOB4EdqnKu908IEluw _wGeiAFY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw" performedPrimarilyBy="_wGSUwFY6EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0e1mIMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_vWeHMCxSEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_B47VwCxTEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_2389cOz2Edq2wJOsmRwmhg"/>
+ <selectedSteps href="uma://-_mfd9ziTwQV_5LE80jJw4g#_w2JYgEf6EduISP1GQDlvVQ"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_BYbboN-bEdqiM_wFaqLjNg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_2tHGoMAYEdqX-s4mWhkyqQ" name="stakeholder" guid="_2tHGoMAYEdqX-s4mWhkyqQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_86w-oOB4EdqnKu908IEluw" name="glossary" guid="_86w-oOB4EdqnKu908IEluw" presentationName="Glossary" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_kFwgIDbsEduMn613sF6-Uw" name="create_test_cases" guid="_kFwgIDbsEduMn613sF6-Uw" presentationName="Create Test Cases" superActivities="_0o9ygclgEdmt3adZL5Dmdw" additionallyPerformedBy="_wGSUwFY6EdqI9sTOt2pjHw _2tHGoMAYEdqX-s4mWhkyqQ _F6WiEcEQEduTGJ8i4u8TMw" mandatoryInput="_wGeiAFY6EdqI9sTOt2pjHw" optionalInput="_kF8tYTbsEduMn613sF6-Uw _Y5DAMb-EEdqb7N6KIeDL8Q" output="_kF8tYTbsEduMn613sF6-Uw" performedPrimarilyBy="_kF8tYDbsEduMn613sF6-Uw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iwc0clgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_IJFSsKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_aDe_ILGcEdubqf8m_Zrvvg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_LpbM8KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_NK18YKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_Ok_mMKuSEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_kF8tYDbsEduMn613sF6-Uw" name="tester" guid="_kF8tYDbsEduMn613sF6-Uw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw" responsibleFor="_kF8tYTbsEduMn613sF6-Uw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_kF8tYTbsEduMn613sF6-Uw" name="test_case" guid="_kF8tYTbsEduMn613sF6-Uw" presentationName="Test Case" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZS-0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_F6WiEMEQEduTGJ8i4u8TMw" name="architect" guid="_F6WiEMEQEduTGJ8i4u8TMw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_F6WiEcEQEduTGJ8i4u8TMw" name="developer" guid="_F6WiEcEQEduTGJ8i4u8TMw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0o9ygclgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0o9ygclgEdmt3adZL5Dmdw" briefDescription="Detail a set of requirements (one or more use cases, scenarios or supporting requirements)." presentationName="Manage Requirements" hasMultipleOccurrences="true" breakdownElements="_wGSUwFY6EdqI9sTOt2pjHw _wGeiAFY6EdqI9sTOt2pjHw _wGw14FY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw _Y42y8L-EEdqb7N6KIeDL8Q _Y5DAML-EEdqb7N6KIeDL8Q _Y5DAMb-EEdqb7N6KIeDL8Q _ZRfVYL-EEdqb7N6KIeDL8Q _2tHGoMAYEdqX-s4mWhkyqQ _86w-oOB4EdqnKu908IEluw _kFwgIDbsEduMn613sF6-Uw _kF8tYDbsEduMn613sF6-Uw _kF8tYTbsEduMn613sF6-Uw _F6WiEMEQEduTGJ8i4u8TMw _F6WiEcEQEduTGJ8i4u8TMw">
+ <presentation xmi:id="_mtb-8_L5Edm6Nvont3uinw" href="uma://_mtb-8_L5Edm6Nvont3uinw#_mtb-8_L5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/ongoing_tasks/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/ongoing_tasks/content.xmi
new file mode 100644
index 0000000..aa0a0b3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/ongoing_tasks/content.xmi
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-9PL5Edm6Nvont3uinw" guid="_mtb-9PL5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity&nbsp;includes a single task, <a class="elementLink" href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request Change</a>. This task&nbsp;may occur anytime during the lifecycle in response to an observed defect, a desired
+ enhancement, or a change request. It is not planned,&nbsp;which means it does&nbsp;not appear as a scheduled activity
+ on the project plan, iteration plan or work items list. Nevertheless, it is a critical activity that must be performed
+ to ensure project success in an environment that is not static.
+</p>
+<p>
+ <a class="elementLink" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">Any Role</a>&nbsp;may perform this task, however the most common sources of&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> are&nbsp;<a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s (enhancement requests and change requests) and&nbsp;<a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>s (defect reports).
+</p></mainDescription>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/ongoing_tasks/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/ongoing_tasks/model.xmi
new file mode 100644
index 0000000..76b14ef
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/ongoing_tasks/model.xmi
@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nK7zMvL5Edm6Nvont3uinw" guid="_nK7zMvL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nK7zMfL5Edm6Nvont3uinw" id="_mtb-9PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0pJ_xclgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0pJ_xclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_4x060FY1EdqI9sTOt2pjHw" name="any_role" guid="_4x060FY1EdqI9sTOt2pjHw" presentationName="Any Role" hasMultipleOccurrences="true" superActivities="_0pJ_xslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0dsWoMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_5LsMUFY1EdqI9sTOt2pjHw" name="request_change" guid="_5LsMUFY1EdqI9sTOt2pjHw" presentationName="Request Change" superActivities="_0pJ_xslgEdmt3adZL5Dmdw" optionalInput="_5M7icFY1EdqI9sTOt2pjHw" output="_5M7icFY1EdqI9sTOt2pjHw" performedPrimarilyBy="_4x060FY1EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0mwzEclgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Nr0S4KeqEdmKDbQuyzCoqQ#_qEkewKuoEdmEGLSmmpF1Sg"/>
+ <selectedSteps href="uma://_Nr0S4KeqEdmKDbQuyzCoqQ#_r2aP0KuoEdmEGLSmmpF1Sg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_5M7icFY1EdqI9sTOt2pjHw" name="work_items_list" guid="_5M7icFY1EdqI9sTOt2pjHw" presentationName="Work Items List" superActivities="_0pJ_xslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0pJ_xslgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0pJ_xslgEdmt3adZL5Dmdw" briefDescription="Perform ongoing tasks that are not necessarily part of project schedule." presentationName="Ongoing Tasks" isPlanned="false" hasMultipleOccurrences="true" isOngoing="true" isEventDriven="true" breakdownElements="_4x060FY1EdqI9sTOt2pjHw _5LsMUFY1EdqI9sTOt2pjHw _5M7icFY1EdqI9sTOt2pjHw">
+ <presentation xmi:id="_mtb-9PL5Edm6Nvont3uinw" href="uma://_mtb-9PL5Edm6Nvont3uinw#_mtb-9PL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/test/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/test/content.xmi
new file mode 100644
index 0000000..bfa947c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/test/content.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-6vL5Edm6Nvont3uinw" guid="_mtb-6vL5Edm6Nvont3uinw" version="1.0.0">
+ <keyConsiderations><p>
+ &nbsp;
+</p></keyConsiderations>
+ <purpose>To create and run tests that validate that the system conforms to the intent.</purpose>
+ <howtoStaff><p>
+ The staff performing this activity must be integrated into the team.
+</p></howtoStaff>
+ <usageNotes><p>
+ Testing must occur throughout the process and <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ throughout&nbsp;each iteration.&nbsp;It is not some final inspection to be done at the end. As requirements are de<span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ veloped and integrated into the build they should be tested as soon as possible.</span></span>
+</p></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/test/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/test/model.xmi
new file mode 100644
index 0000000..a0fc5a9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/test/model.xmi
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nJHOQPL5Edm6Nvont3uinw" guid="_nJHOQPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nJBHo_L5Edm6Nvont3uinw" id="_mtb-6vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0nz79MlgEdmt3adZL5Dmdw" name="test" guid="_0nz79MlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_a6qBUFY2EdqI9sTOt2pjHw" name="tester" guid="_a6qBUFY2EdqI9sTOt2pjHw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0nz79clgEdmt3adZL5Dmdw" responsibleFor="_oSQYEL3SEdqfrv3k16plXw _a_F1YFY2EdqI9sTOt2pjHw _a8fNUFY2EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_a8fNUFY2EdqI9sTOt2pjHw" name="test_case" guid="_a8fNUFY2EdqI9sTOt2pjHw" presentationName="Test Case" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZS-0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_a_F1YFY2EdqI9sTOt2pjHw" name="test_script" guid="_a_F1YFY2EdqI9sTOt2pjHw" presentationName="Test Script" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_nykLZL3SEdqfrv3k16plXw" name="implement_tests" guid="_nykLZL3SEdqfrv3k16plXw" presentationName="Implement Tests" superActivities="_0nz79clgEdmt3adZL5Dmdw" mandatoryInput="_a8fNUFY2EdqI9sTOt2pjHw" optionalInput="_a_F1YFY2EdqI9sTOt2pjHw _ny2fQL3SEdqfrv3k16plXw" output="_a_F1YFY2EdqI9sTOt2pjHw" performedPrimarilyBy="_a6qBUFY2EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0jO98MlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_S8JzsKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_VN5M0KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_WvBoYKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_X0dmcKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_Y-ABYKuSEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_ny2fQL3SEdqfrv3k16plXw" name="build" guid="_ny2fQL3SEdqfrv3k16plXw" presentationName="Build" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_oR39mb3SEdqfrv3k16plXw" name="run_tests" guid="_oR39mb3SEdqfrv3k16plXw" presentationName="Run Tests" superActivities="_0nz79clgEdmt3adZL5Dmdw" mandatoryInput="_ny2fQL3SEdqfrv3k16plXw _a_F1YFY2EdqI9sTOt2pjHw" output="_oSQYEL3SEdqfrv3k16plXw _os33gL3SEdqfrv3k16plXw" performedPrimarilyBy="_a6qBUFY2EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0jVEkMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_fR4aQKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_gV408KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_hfVJQKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_sQaC4DO2EduqsLmIADMQ9g"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_0XzAwDO2EduqsLmIADMQ9g"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_3t6oADO2EduqsLmIADMQ9g"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_oSQYEL3SEdqfrv3k16plXw" name="test_log" guid="_oSQYEL3SEdqfrv3k16plXw" presentationName="Test Log" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZlSsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_os33gL3SEdqfrv3k16plXw" name="work_items_list" guid="_os33gL3SEdqfrv3k16plXw" presentationName="Work Items List" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0nz79clgEdmt3adZL5Dmdw" name="test" guid="_0nz79clgEdmt3adZL5Dmdw" briefDescription="Test and evaluate the requirements developed, from system perspective." presentationName="Test" hasMultipleOccurrences="true" breakdownElements="_a6qBUFY2EdqI9sTOt2pjHw _a8fNUFY2EdqI9sTOt2pjHw _a_F1YFY2EdqI9sTOt2pjHw _nykLZL3SEdqfrv3k16plXw _ny2fQL3SEdqfrv3k16plXw _oR39mb3SEdqfrv3k16plXw _oSQYEL3SEdqfrv3k16plXw _os33gL3SEdqfrv3k16plXw">
+ <presentation xmi:id="_mtb-6vL5Edm6Nvont3uinw" href="uma://_mtb-6vL5Edm6Nvont3uinw#_mtb-6vL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/transition_phase_iteration/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/transition_phase_iteration/content.xmi
new file mode 100644
index 0000000..0a44854
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/transition_phase_iteration/content.xmi
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_AfL5Edm6Nvont3uinw" guid="_mtb_AfL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_AvL5Edm6Nvont3uinw" guid="_mtb_AvL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_APL5Edm6Nvont3uinw" guid="_mtb_APL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_A_L5Edm6Nvont3uinw" guid="_mtb_A_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb-__L5Edm6Nvont3uinw" guid="_mtb-__L5Edm6Nvont3uinw">
+ <mainDescription><h3> Introduction&nbsp; </h3>
+<p> In the Transition phase,
+ most activities happen in parallel. The main objectives are to fine-tune functionality,
+ performance, and overall quality of the beta product from
+ the end of Construction phase. </p>
+<p> The activities performed in a typical iteration during
+ the&nbsp;Transition phase are described below. </p>
+<h4> Manage iteration </h4>
+<p> This activity is performed throughout the lifecycle. The goal of this activity
+ is to identify risks and issues early enough that they can be mitigated, to
+ establish the goals for the iteration, and to support the development team in
+ reaching these goals. </p>
+<p> Similar to other phases, this is an activity led by the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> (in collaboration with the team) to launch the iteration, to allocate
+ work, to track status, and to handle risks and issues. It’s unlikely that risks
+ of high impact will happen during the Transition, but it is recommended that
+ the project manager and team identify any potential issues&nbsp;while delivering
+ the product to the end users. </p>
+<p>If this is the last iteration of the project, the main goal is to achieve final
+ acceptance of the system. At the end of the iteration, results are assessed
+ against phase objectives<em>,</em> and <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders'</a>
+ concurrence on the project objectives is obtained. The team conducts a retrospective
+ review to capture lessons learned and make improvements to the process for subsequent
+ <strong> </strong>projects. The project is then closed.</p>
+<h4>Ongoing tasks </h4>
+<p> Submission of change requests during the Transition phase <strong></strong>works&nbsp;differently
+ than in other phases. New requirements will rarely be identified at late stages
+ of the software development lifecycle in a way they can be implemented in the
+ current release. If there are enhancement requests, though, they can be captured
+ in the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">work
+ items list</a> and allocated to a future release, when a new software development
+ lifecycle begins. In that case, requirements will be outlined and detailed accordingly.
+</p>
+<p> However, defects are typically dealt with during the Transition phase,&nbsp;thus
+ a stable release can be accepted by the user community. If there is general
+ agreement from stakeholders, correction of low-priority defects can be postponed
+ to subsequent evolutionary releases. </p>
+<h4> Develop solution for requirement within context</h4>
+<p> This activity is repeated multiple times, in parallel, for each development
+ task planned for that iteration. The main goal of this activity is an executable
+ system that provides the incremental quality and functionality for the specified
+ requirements within the specified context. </p>
+<p> During the Transition phase, most requirements will have been already implemented
+ and validated, which is the focus of the previous phase. Nevertheless, there
+ may be a few low-priority requirements that could be accommodated in the release
+ being developed. However, enhancement requests and defects found in previous
+ iterations may need to be allocated to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
+</p>
+<h4> Validate build </h4>
+<p> This activity is repeated throughout the lifecycle. The main goal of this
+ activity is to validate the current increment of the system against the requirements
+ allocated to it. </p>
+<p> This activity happens in parallel with development of the
+ solutions for enhancement requests and defects
+ (and possibly remaining requirements), to make sure that
+ a stable release can be presented to the user community. Users can be involved
+ in performing <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/test,_0nz79clgEdmt3adZL5Dmdw.html" guid="_0nz79clgEdmt3adZL5Dmdw">tests</a>
+ to accept the release. </p>
+<h4></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/transition_phase_iteration/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/transition_phase_iteration/model.xmi
new file mode 100644
index 0000000..525f334
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/transition_phase_iteration/model.xmi
@@ -0,0 +1,335 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nMRP8PL5Edm6Nvont3uinw" guid="_nMRP8PL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nLsoM_L5Edm6Nvont3uinw" id="_mtb_AfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQPinEdmugcVr9AdHjQ" id="_mtb_AvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQfinEdmugcVr9AdHjQ" id="_mtb_APL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQvinEdmugcVr9AdHjQ" id="_mtb_A_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQ_inEdmugcVr9AdHjQ" id="_mtb-__L5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0qrpwMlgEdmt3adZL5Dmdw" name="transition_phase_iteration" guid="_0qrpwMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0qrpwclgEdmt3adZL5Dmdw" name="validate_build" guid="_0qrpwclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0qrpwslgEdmt3adZL5Dmdw" name="validate_build" guid="_0qrpwslgEdmt3adZL5Dmdw" presentationName="Validate Build" hasMultipleOccurrences="true" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_AfL5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb_AfL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0qxwYMlgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0qxwYMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0qxwYclgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0qxwYclgEdmt3adZL5Dmdw" presentationName="Ongoing Tasks" isPlanned="false" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="_mtb_AvL5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb_AvL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0q33AMlgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0q33AMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0q33AclgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0q33AclgEdmt3adZL5Dmdw" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="_mtb_APL5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb_APL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0CtdMPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_0CtdMPinEdmugcVr9AdHjQ">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0DMlYPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_0DMlYPinEdmugcVr9AdHjQ" presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ </processElements>
+ <diagrams xmi:id="_m0ZXADSDEduGhYMJfagftQ" guid="_m0ZXADSDEduGhYMJfagftQ">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69oE9HEdudU75l2xOQTw" guid="_6t69oE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69oU9HEdudU75l2xOQTw" x="168.0" y="12.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69ok9HEdudU75l2xOQTw" guid="_6t69ok9HEdudU75l2xOQTw" anchor="_6t69pE9HEdudU75l2xOQTw _6t69rE9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69o09HEdudU75l2xOQTw" guid="_6t69o09HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_TiPK8DLwEdueZPye-FaNgA"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_6t69pE9HEdudU75l2xOQTw" guid="_6t69pE9HEdudU75l2xOQTw" graphEdge="_6t69ok9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69pU9HEdudU75l2xOQTw" guid="_6t69pU9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69pk9HEdudU75l2xOQTw" guid="_6t69pk9HEdudU75l2xOQTw"/>
+ <size xmi:id="_6t69p09HEdudU75l2xOQTw" width="112.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69qE9HEdudU75l2xOQTw" guid="_6t69qE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69qU9HEdudU75l2xOQTw" x="178.0" y="99.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69qk9HEdudU75l2xOQTw" guid="_6t69qk9HEdudU75l2xOQTw" anchor="_6t69rk9HEdudU75l2xOQTw _6uBEQU9HEdudU75l2xOQTw">
+ <waypoints xmi:id="_6t69q09HEdudU75l2xOQTw" x="223.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_6t69rE9HEdudU75l2xOQTw" guid="_6t69rE9HEdudU75l2xOQTw" graphEdge="_6t69ok9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69rU9HEdudU75l2xOQTw" guid="_6t69rU9HEdudU75l2xOQTw" graphEdge="_6t694U9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69rk9HEdudU75l2xOQTw" guid="_6t69rk9HEdudU75l2xOQTw" graphEdge="_6t69qk9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69r09HEdudU75l2xOQTw" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69sE9HEdudU75l2xOQTw" guid="_6t69sE9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69sU9HEdudU75l2xOQTw" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69sk9HEdudU75l2xOQTw" guid="_6t69sk9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69s09HEdudU75l2xOQTw" x="28.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69tE9HEdudU75l2xOQTw" guid="_6t69tE9HEdudU75l2xOQTw" anchor="_6t69tk9HEdudU75l2xOQTw _6t6-C09HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_wbDz0c6VEdu_q7xi9VPgyA" guid="_wbDz0c6VEdu_q7xi9VPgyA" anchor="_wbDz0M6VEdu_q7xi9VPgyA _wbDz0s6VEdu_q7xi9VPgyA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_wbDz086VEdu_q7xi9VPgyA" guid="_wbDz086VEdu_q7xi9VPgyA">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_c84V8MmJEduwrYVlQ9zp3w"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_6t69tU9HEdudU75l2xOQTw" guid="_6t69tU9HEdudU75l2xOQTw" graphEdge="_6t69-U9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69tk9HEdudU75l2xOQTw" guid="_6t69tk9HEdudU75l2xOQTw" graphEdge="_6t69tE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69t09HEdudU75l2xOQTw" x="101.0" y="286.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wbDz0M6VEdu_q7xi9VPgyA" guid="_wbDz0M6VEdu_q7xi9VPgyA" graphEdge="_wbDz0c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69uE9HEdudU75l2xOQTw" guid="_6t69uE9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69uU9HEdudU75l2xOQTw" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69uk9HEdudU75l2xOQTw" guid="_6t69uk9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69u09HEdudU75l2xOQTw" x="179.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69vE9HEdudU75l2xOQTw" guid="_6t69vE9HEdudU75l2xOQTw" anchor="_6t69v09HEdudU75l2xOQTw _6t69yE9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69vU9HEdudU75l2xOQTw" guid="_6t69vU9HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_6t69vk9HEdudU75l2xOQTw" guid="_6t69vk9HEdudU75l2xOQTw" graphEdge="_6t69-E9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69v09HEdudU75l2xOQTw" guid="_6t69v09HEdudU75l2xOQTw" graphEdge="_6t69vE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69wE9HEdudU75l2xOQTw" x="239.0" y="284.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69wU9HEdudU75l2xOQTw" guid="_6t69wU9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69wk9HEdudU75l2xOQTw" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69w09HEdudU75l2xOQTw" guid="_6t69w09HEdudU75l2xOQTw">
+ <position xmi:id="_6t69xE9HEdudU75l2xOQTw" x="191.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69xU9HEdudU75l2xOQTw" guid="_6t69xU9HEdudU75l2xOQTw" anchor="_6t69xk9HEdudU75l2xOQTw _6t6-DU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69xk9HEdudU75l2xOQTw" guid="_6t69xk9HEdudU75l2xOQTw" graphEdge="_6t69xU9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69x09HEdudU75l2xOQTw" x="374.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t69yE9HEdudU75l2xOQTw" guid="_6t69yE9HEdudU75l2xOQTw" graphEdge="_6t69vE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69yU9HEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wbDz0s6VEdu_q7xi9VPgyA" guid="_wbDz0s6VEdu_q7xi9VPgyA" graphEdge="_wbDz0c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69yk9HEdudU75l2xOQTw" guid="_6t69yk9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_d4GesL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69y09HEdudU75l2xOQTw" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69zE9HEdudU75l2xOQTw" guid="_6t69zE9HEdudU75l2xOQTw" briefDescription="_QPeqAERlEduP07d3x5Xi-g">
+ <position xmi:id="_6t69zU9HEdudU75l2xOQTw" x="25.0" y="111.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_BzU6EU9IEdudU75l2xOQTw" guid="_BzU6EU9IEdudU75l2xOQTw" anchor="_BzU6EE9IEdudU75l2xOQTw _BzU6Ek9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_BzU6EE9IEdudU75l2xOQTw" guid="_BzU6EE9IEdudU75l2xOQTw" graphEdge="_BzU6EU9IEdudU75l2xOQTw">
+ <position xmi:id="_BzU6E09IEdudU75l2xOQTw" x="37.0" y="119.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t690U9HEdudU75l2xOQTw" guid="_6t690U9HEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_6t690k9HEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69309HEdudU75l2xOQTw" guid="_6t69309HEdudU75l2xOQTw" briefDescription="_SccQ0ERlEduP07d3x5Xi-g">
+ <position xmi:id="_6t694E9HEdudU75l2xOQTw" x="83.0" y="110.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t694U9HEdudU75l2xOQTw" guid="_6t694U9HEdudU75l2xOQTw" anchor="_6t695k9HEdudU75l2xOQTw _6t69rU9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t694k9HEdudU75l2xOQTw" guid="_6t694k9HEdudU75l2xOQTw" anchor="_6t696E9HEdudU75l2xOQTw _6uBEQ09HEdudU75l2xOQTw">
+ <waypoints xmi:id="_6t69409HEdudU75l2xOQTw" x="94.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_6t695k9HEdudU75l2xOQTw" guid="_6t695k9HEdudU75l2xOQTw" graphEdge="_6t694U9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69509HEdudU75l2xOQTw" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t696E9HEdudU75l2xOQTw" guid="_6t696E9HEdudU75l2xOQTw" graphEdge="_6t694k9HEdudU75l2xOQTw">
+ <position xmi:id="_6t696U9HEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_BzU6Ek9IEdudU75l2xOQTw" guid="_BzU6Ek9IEdudU75l2xOQTw" graphEdge="_BzU6EU9IEdudU75l2xOQTw">
+ <position xmi:id="_BzU6FE9IEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t696k9HEdudU75l2xOQTw" guid="_6t696k9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_6t69609HEdudU75l2xOQTw" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t698U9HEdudU75l2xOQTw" name="Add Free Text" guid="_6t698U9HEdudU75l2xOQTw" briefDescription="_mXzzEERlEduP07d3x5Xi-g">
+ <property xmi:id="_6t698k9HEdudU75l2xOQTw" guid="_6t698k9HEdudU75l2xOQTw" key="free text" value="[small change]"/>
+ <position xmi:id="_6t69809HEdudU75l2xOQTw" x="106.0" y="105.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t699E9HEdudU75l2xOQTw" guid="_6t699E9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_6t699U9HEdudU75l2xOQTw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t699k9HEdudU75l2xOQTw" guid="_6t699k9HEdudU75l2xOQTw" briefDescription="_pfsxEERlEduP07d3x5Xi-g">
+ <position xmi:id="_6t69909HEdudU75l2xOQTw" x="42.0" y="232.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69-E9HEdudU75l2xOQTw" guid="_6t69-E9HEdudU75l2xOQTw" anchor="_6t69-09HEdudU75l2xOQTw _6t69vk9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69-U9HEdudU75l2xOQTw" guid="_6t69-U9HEdudU75l2xOQTw" anchor="_6t69_U9HEdudU75l2xOQTw _6t69tU9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69-k9HEdudU75l2xOQTw" guid="_6t69-k9HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_6t69-09HEdudU75l2xOQTw" guid="_6t69-09HEdudU75l2xOQTw" graphEdge="_6t69-E9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69_E9HEdudU75l2xOQTw" x="201.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t69_U9HEdudU75l2xOQTw" guid="_6t69_U9HEdudU75l2xOQTw" graphEdge="_6t69-U9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69_k9HEdudU75l2xOQTw" x="38.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t69_09HEdudU75l2xOQTw" guid="_6t69_09HEdudU75l2xOQTw" graphEdge="_6uBEQE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-AE9HEdudU75l2xOQTw" x="116.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-AU9HEdudU75l2xOQTw" guid="_6t6-AU9HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_6t6-Ak9HEdudU75l2xOQTw" width="262.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-A09HEdudU75l2xOQTw" name="Add Free Text" guid="_6t6-A09HEdudU75l2xOQTw" briefDescription="_JJvg8ERmEduP07d3x5Xi-g">
+ <property xmi:id="_6t6-BE9HEdudU75l2xOQTw" guid="_6t6-BE9HEdudU75l2xOQTw" key="free text" value="[trivial change]"/>
+ <position xmi:id="_6t6-BU9HEdudU75l2xOQTw" x="98.0" y="153.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-Bk9HEdudU75l2xOQTw" guid="_6t6-Bk9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_6t6-B09HEdudU75l2xOQTw" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-CE9HEdudU75l2xOQTw" guid="_6t6-CE9HEdudU75l2xOQTw" briefDescription="_MViukERmEduP07d3x5Xi-g">
+ <position xmi:id="_6t6-CU9HEdudU75l2xOQTw" x="42.0" y="382.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t6-Ck9HEdudU75l2xOQTw" guid="_6t6-Ck9HEdudU75l2xOQTw" anchor="_6t6-D09HEdudU75l2xOQTw _6t6-FU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t6-C09HEdudU75l2xOQTw" guid="_6t6-C09HEdudU75l2xOQTw" graphEdge="_6t69tE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-DE9HEdudU75l2xOQTw" x="39.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t6-DU9HEdudU75l2xOQTw" guid="_6t6-DU9HEdudU75l2xOQTw" graphEdge="_6t69xU9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-Dk9HEdudU75l2xOQTw" x="199.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t6-D09HEdudU75l2xOQTw" guid="_6t6-D09HEdudU75l2xOQTw" graphEdge="_6t6-Ck9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-EE9HEdudU75l2xOQTw" x="129.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-EU9HEdudU75l2xOQTw" guid="_6t6-EU9HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_6t6-Ek9HEdudU75l2xOQTw" width="274.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-E09HEdudU75l2xOQTw" guid="_6t6-E09HEdudU75l2xOQTw" briefDescription="_UF-lAERmEduP07d3x5Xi-g">
+ <position xmi:id="_6t6-FE9HEdudU75l2xOQTw" x="160.0" y="410.0"/>
+ <anchorage xmi:id="_6t6-FU9HEdudU75l2xOQTw" guid="_6t6-FU9HEdudU75l2xOQTw" graphEdge="_6t6-Ck9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-Fk9HEdudU75l2xOQTw" guid="_6t6-Fk9HEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_6t6-F09HEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-GE9HEdudU75l2xOQTw" guid="_6t6-GE9HEdudU75l2xOQTw" briefDescription="_gEnEwERnEduP07d3x5Xi-g">
+ <position xmi:id="_6t6-GU9HEdudU75l2xOQTw" x="145.0" y="180.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6uBEQE9HEdudU75l2xOQTw" guid="_6uBEQE9HEdudU75l2xOQTw" anchor="_6uBERU9HEdudU75l2xOQTw _6t69_09HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6uBEQU9HEdudU75l2xOQTw" guid="_6uBEQU9HEdudU75l2xOQTw" graphEdge="_6t69qk9HEdudU75l2xOQTw">
+ <position xmi:id="_6uBEQk9HEdudU75l2xOQTw" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6uBEQ09HEdudU75l2xOQTw" guid="_6uBEQ09HEdudU75l2xOQTw" graphEdge="_6t694k9HEdudU75l2xOQTw">
+ <position xmi:id="_6uBERE9HEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6uBERU9HEdudU75l2xOQTw" guid="_6uBERU9HEdudU75l2xOQTw" graphEdge="_6uBEQE9HEdudU75l2xOQTw">
+ <position xmi:id="_6uBERk9HEdudU75l2xOQTw" x="13.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6uBER09HEdudU75l2xOQTw" guid="_6uBER09HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_6uBESE9HEdudU75l2xOQTw" width="28.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_m0ZXfDSDEduGhYMJfagftQ" guid="_m0ZXfDSDEduGhYMJfagftQ" presentation="Workflow" element="_0DMlYPinEdmugcVr9AdHjQ"/>
+ </diagrams>
+ </childPackages>
+ <diagrams xmi:id="_ZMDKENIWEdm9Cql_SeWu_A" guid="_ZMDKENIWEdm9Cql_SeWu_A">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKEdIWEdm9Cql_SeWu_A" guid="_ZMDKEdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKEtIWEdm9Cql_SeWu_A" x="205.0" y="96.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_GUJvodIZEdm9Cql_SeWu_A" guid="_GUJvodIZEdm9Cql_SeWu_A" anchor="_GUJvoNIZEdm9Cql_SeWu_A _GUJvotIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="_GA1LAtIZEdm9Cql_SeWu_A" guid="_GA1LAtIZEdm9Cql_SeWu_A" graphEdge="_GA1LAdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_GA1LBNIZEdm9Cql_SeWu_A" x="38.0" y="-15.0"/>
+ </anchorage>
+ <anchorage xmi:id="_GUJvoNIZEdm9Cql_SeWu_A" guid="_GUJvoNIZEdm9Cql_SeWu_A" graphEdge="_GUJvodIZEdm9Cql_SeWu_A">
+ <position xmi:id="_GUJvo9IZEdm9Cql_SeWu_A" x="38.0" y="31.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKE9IWEdm9Cql_SeWu_A" guid="_ZMDKE9IWEdm9Cql_SeWu_A" element="_0q33AclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ZMDKFNIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKFdIWEdm9Cql_SeWu_A" guid="_ZMDKFdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKFtIWEdm9Cql_SeWu_A" x="226.0" y="170.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_s1YcwdbaEdm9COXJE3Cq0g" guid="_s1YcwdbaEdm9COXJE3Cq0g" anchor="_s1YcwNbaEdm9COXJE3Cq0g _s1YcwtbaEdm9COXJE3Cq0g">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_s1w3QNbaEdm9COXJE3Cq0g" guid="_s1w3QNbaEdm9COXJE3Cq0g"/>
+ </contained>
+ <anchorage xmi:id="_s1YcwNbaEdm9COXJE3Cq0g" guid="_s1YcwNbaEdm9COXJE3Cq0g" graphEdge="_s1YcwdbaEdm9COXJE3Cq0g">
+ <position xmi:id="_s1Ycw9baEdm9COXJE3Cq0g" x="119.0" y="22.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKF9IWEdm9Cql_SeWu_A" guid="_ZMDKF9IWEdm9Cql_SeWu_A"/>
+ <size xmi:id="_ZMDKGNIWEdm9Cql_SeWu_A" width="246.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKGdIWEdm9Cql_SeWu_A" guid="_ZMDKGdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKGtIWEdm9Cql_SeWu_A" x="113.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Z0Cwwcm0EdqibaSI8nt1Ng" guid="_Z0Cwwcm0EdqibaSI8nt1Ng" anchor="_Z0CwwMm0EdqibaSI8nt1Ng _Z0Cwwsm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_s1YcwtbaEdm9COXJE3Cq0g" guid="_s1YcwtbaEdm9COXJE3Cq0g" graphEdge="_s1YcwdbaEdm9COXJE3Cq0g"/>
+ <anchorage xmi:id="_Y5ZGYsm0EdqibaSI8nt1Ng" guid="_Y5ZGYsm0EdqibaSI8nt1Ng" graphEdge="_Y5ZGYcm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_Z0CwwMm0EdqibaSI8nt1Ng" guid="_Z0CwwMm0EdqibaSI8nt1Ng" graphEdge="_Z0Cwwcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_Z0Cww8m0EdqibaSI8nt1Ng" x="484.0" y="257.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKG9IWEdm9Cql_SeWu_A" guid="_ZMDKG9IWEdm9Cql_SeWu_A" element="_0qrpwslgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ZMDKHNIWEdm9Cql_SeWu_A" width="80.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKHdIWEdm9Cql_SeWu_A" guid="_ZMDKHdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKHtIWEdm9Cql_SeWu_A" x="360.0" y="135.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Wi-usdIZEdm9Cql_SeWu_A" guid="_Wi-usdIZEdm9Cql_SeWu_A" anchor="_Wi-usNIZEdm9Cql_SeWu_A _Wi-ustIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="_WOz1gtIZEdm9Cql_SeWu_A" guid="_WOz1gtIZEdm9Cql_SeWu_A" graphEdge="_WOz1gdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_WOz1hNIZEdm9Cql_SeWu_A" x="36.0" y="-101.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Wi-usNIZEdm9Cql_SeWu_A" guid="_Wi-usNIZEdm9Cql_SeWu_A" graphEdge="_Wi-usdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_Wi-us9IZEdm9Cql_SeWu_A" x="37.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKH9IWEdm9Cql_SeWu_A" guid="_ZMDKH9IWEdm9Cql_SeWu_A" element="_0qxwYclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ZMDKINIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="__-SZwNIYEdm9Cql_SeWu_A" guid="__-SZwNIYEdm9Cql_SeWu_A">
+ <position xmi:id="__-SZwdIYEdm9Cql_SeWu_A" x="77.0" y="8.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_FwkhcdIZEdm9Cql_SeWu_A" guid="_FwkhcdIZEdm9Cql_SeWu_A" anchor="_FwkhcNIZEdm9Cql_SeWu_A _FwkhctIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="_FwkhcNIZEdm9Cql_SeWu_A" guid="_FwkhcNIZEdm9Cql_SeWu_A" graphEdge="_FwkhcdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_Fwkhc9IZEdm9Cql_SeWu_A" x="7.0" y="10.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="__-SZwtIYEdm9Cql_SeWu_A" guid="__-SZwtIYEdm9Cql_SeWu_A" typeInfo="start node"/>
+ <size xmi:id="__-SZw9IYEdm9Cql_SeWu_A" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ATOvANIZEdm9Cql_SeWu_A" guid="_ATOvANIZEdm9Cql_SeWu_A">
+ <position xmi:id="_ATOvAdIZEdm9Cql_SeWu_A" x="72.0" y="301.0"/>
+ <anchorage xmi:id="_G02o8tIZEdm9Cql_SeWu_A" guid="_G02o8tIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="__hx1okmeEduO0bs89Khm8Q" guid="__hx1okmeEduO0bs89Khm8Q" graphEdge="__hx1oUmeEduO0bs89Khm8Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_ATOvAtIZEdm9Cql_SeWu_A" guid="_ATOvAtIZEdm9Cql_SeWu_A" typeInfo="end node"/>
+ <size xmi:id="_ATOvA9IZEdm9Cql_SeWu_A" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_AyNxENIZEdm9Cql_SeWu_A" guid="_AyNxENIZEdm9Cql_SeWu_A">
+ <position xmi:id="_AyNxEdIZEdm9Cql_SeWu_A" x="20.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_GA1LAdIZEdm9Cql_SeWu_A" guid="_GA1LAdIZEdm9Cql_SeWu_A" anchor="_GA1LANIZEdm9Cql_SeWu_A _GA1LAtIZEdm9Cql_SeWu_A"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_WOz1gdIZEdm9Cql_SeWu_A" guid="_WOz1gdIZEdm9Cql_SeWu_A" anchor="_WOz1gNIZEdm9Cql_SeWu_A _WOz1gtIZEdm9Cql_SeWu_A"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_XdIjwcm0EdqibaSI8nt1Ng" guid="_XdIjwcm0EdqibaSI8nt1Ng" anchor="_XdIjwMm0EdqibaSI8nt1Ng _XdIjwsm0EdqibaSI8nt1Ng"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Y5ZGYcm0EdqibaSI8nt1Ng" guid="_Y5ZGYcm0EdqibaSI8nt1Ng" anchor="_Y5ZGYMm0EdqibaSI8nt1Ng _Y5ZGYsm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_FwkhctIZEdm9Cql_SeWu_A" guid="_FwkhctIZEdm9Cql_SeWu_A" graphEdge="_FwkhcdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_FwkhdNIZEdm9Cql_SeWu_A" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_GA1LANIZEdm9Cql_SeWu_A" guid="_GA1LANIZEdm9Cql_SeWu_A" graphEdge="_GA1LAdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_4-gsMNSKEdqANo9Ox5ktZQ" x="227.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_WOz1gNIZEdm9Cql_SeWu_A" guid="_WOz1gNIZEdm9Cql_SeWu_A" graphEdge="_WOz1gdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_8H10oNSKEdqANo9Ox5ktZQ" x="382.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_XdIjwMm0EdqibaSI8nt1Ng" guid="_XdIjwMm0EdqibaSI8nt1Ng" graphEdge="_XdIjwcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_wkOAcNSKEdqANo9Ox5ktZQ" x="49.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Y5ZGYMm0EdqibaSI8nt1Ng" guid="_Y5ZGYMm0EdqibaSI8nt1Ng" graphEdge="_Y5ZGYcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_13Lu4NSKEdqANo9Ox5ktZQ" x="133.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_AyNxEtIZEdm9Cql_SeWu_A" guid="_AyNxEtIZEdm9Cql_SeWu_A" typeInfo="synchnonization bar"/>
+ <size xmi:id="_AyNxE9IZEdm9Cql_SeWu_A" width="431.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_BocOcNIZEdm9Cql_SeWu_A" guid="_BocOcNIZEdm9Cql_SeWu_A">
+ <position xmi:id="_BocOcdIZEdm9Cql_SeWu_A" x="19.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_GhiEUdIZEdm9Cql_SeWu_A" guid="_GhiEUdIZEdm9Cql_SeWu_A" anchor="_GhiEUNIZEdm9Cql_SeWu_A"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__hx1oUmeEduO0bs89Khm8Q" guid="__hx1oUmeEduO0bs89Khm8Q" anchor="__hx1oEmeEduO0bs89Khm8Q __hx1okmeEduO0bs89Khm8Q"/>
+ <anchorage xmi:id="_GUJvotIZEdm9Cql_SeWu_A" guid="_GUJvotIZEdm9Cql_SeWu_A" graphEdge="_GUJvodIZEdm9Cql_SeWu_A">
+ <position xmi:id="_5o00gNSKEdqANo9Ox5ktZQ" x="227.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_GhiEUNIZEdm9Cql_SeWu_A" guid="_GhiEUNIZEdm9Cql_SeWu_A" graphEdge="_GhiEUdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_s3b98B_mEdqg2MzaRmO8tg" x="72.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Wi-ustIZEdm9Cql_SeWu_A" guid="_Wi-ustIZEdm9Cql_SeWu_A" graphEdge="_Wi-usdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_7l160NSKEdqANo9Ox5ktZQ" x="383.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Ye14Ysm0EdqibaSI8nt1Ng" guid="_Ye14Ysm0EdqibaSI8nt1Ng" graphEdge="_Ye14Ycm0EdqibaSI8nt1Ng">
+ <position xmi:id="_tY4F0NSKEdqANo9Ox5ktZQ" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Z0Cwwsm0EdqibaSI8nt1Ng" guid="_Z0Cwwsm0EdqibaSI8nt1Ng" graphEdge="_Z0Cwwcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_0D_6ANSKEdqANo9Ox5ktZQ" x="133.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__hx1oEmeEduO0bs89Khm8Q" guid="__hx1oEmeEduO0bs89Khm8Q" graphEdge="__hx1oUmeEduO0bs89Khm8Q">
+ <position xmi:id="_Ze_lkEmfEduO0bs89Khm8Q" x="65.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_BocOctIZEdm9Cql_SeWu_A" guid="_BocOctIZEdm9Cql_SeWu_A" typeInfo="synchnonization bar"/>
+ <size xmi:id="_BocOc9IZEdm9Cql_SeWu_A" width="442.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_VAZscPr8EdmyhNQr5STrZQ" guid="_VAZscPr8EdmyhNQr5STrZQ">
+ <position xmi:id="_VAZscfr8EdmyhNQr5STrZQ" x="24.0" y="97.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ye14Ycm0EdqibaSI8nt1Ng" guid="_Ye14Ycm0EdqibaSI8nt1Ng" anchor="_Ye14YMm0EdqibaSI8nt1Ng _Ye14Ysm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_XdIjwsm0EdqibaSI8nt1Ng" guid="_XdIjwsm0EdqibaSI8nt1Ng" graphEdge="_XdIjwcm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_Ye14YMm0EdqibaSI8nt1Ng" guid="_Ye14YMm0EdqibaSI8nt1Ng" graphEdge="_Ye14Ycm0EdqibaSI8nt1Ng">
+ <position xmi:id="_Ye14Y8m0EdqibaSI8nt1Ng" x="320.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_VAZscvr8EdmyhNQr5STrZQ" guid="_VAZscvr8EdmyhNQr5STrZQ" element="_0DMlYPinEdmugcVr9AdHjQ"/>
+ <size xmi:id="_VAZsc_r8EdmyhNQr5STrZQ" width="90.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKJdIWEdm9Cql_SeWu_A" guid="_ZMDKJdIWEdm9Cql_SeWu_A" presentation="Workflow" element="_0rQRgMlgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0rQRgMlgEdmt3adZL5Dmdw" name="transition_phase_iteration" guid="_0rQRgMlgEdmt3adZL5Dmdw" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Transition phase. Each activity and the related goals are described." presentationName="Transition Phase Iteration" isRepeatable="true" breakdownElements="_0q33AclgEdmt3adZL5Dmdw _0DMlYPinEdmugcVr9AdHjQ _0qrpwslgEdmt3adZL5Dmdw _0qxwYclgEdmt3adZL5Dmdw">
+ <ownedRules xmi:id="_1J_ocEbrEduez5pdMGsX2w" guid="_1J_ocEbrEduez5pdMGsX2w"/>
+ <presentation xmi:id="_mtb-__L5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb-__L5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/Custom Categories.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/Custom Categories.xmi
new file mode 100644
index 0000000..2982bfa
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/Custom Categories.xmi
@@ -0,0 +1,2 @@
+<?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="_cyZ5EMfLEdmg9p6Pf0sWyw" name="Custom Categories,_pJXEIcfKEdmg9p6Pf0sWyw" guid="_cyZ5EMfLEdmg9p6Pf0sWyw"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/collab_commun_subprocess.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/collab_commun_subprocess.xmi
new file mode 100644
index 0000000..28fcef3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/collab_commun_subprocess.xmi
@@ -0,0 +1,23 @@
+<?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" epf:version="1.0.0" xmi:id="-NMF-a9hwKjzWNfHzzseDYQ" name="new_custom_category,_r8cVIEmbEdu0xduwSKie-w" guid="-NMF-a9hwKjzWNfHzzseDYQ" changeDate="2006-10-13T14:56:55.821-0700" version="1.0.0">
+ <mainDescription><p>
+ The communication and collaboration layer is the foundation for OpenUP, reflecting the collaborative nature of the
+ process. It contains all of the roles in OpenUP/Basic: Stakeholder, Analyst, Developer, Architect, Tester, Project
+ Manager, and Any Role.&nbsp;Team members taking on these roles need to collaborate to jointly capture and define the
+ intent of the stakeholders, to jointly develop the solution, and to jointly manage the project.
+</p>
+<p>
+ This foundational layer reflects and enables us to express the nature of self-organized teams, where team members must
+ broaden their perspectives of what their roles&nbsp;are and where their responsibilities end. As an example, the
+ Analyst cannot say “I documented the requirements, now it is up to the Developer to implement them.” The Analyst's job
+ is not primarily to document requirements; it is to communicate that the stakeholder intent is understood and reflected
+ in a validated build. Documenting requirements may help you&nbsp;achieve&nbsp;that objective, but it is only one of
+ many available tools. Other tools to use include working with developers on the design, working with testers on what
+ needs to be tested, and using the build to ensure that&nbsp;it does what the stakeholders need it to do.
+</p>
+<p>
+ To help the team to collaborate effectively, the foundational collaboration layer provides you with a set of <a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" guid="_HEu9QBOHEduCNqgZdt_OaA">practices</a> that have been shown to motivate effective collaboration. These practices
+ apply to work done in all sub-processes.<br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/core_principles_category.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/core_principles_category.xmi
new file mode 100644
index 0000000..feb6890
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/core_principles_category.xmi
@@ -0,0 +1,58 @@
+<?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" epf:version="1.0.0" xmi:id="-I2j8LuHkworb0Y3EIlWfDQ" name="core_principles,_HEu9QBOHEduCNqgZdt_OaA" guid="-I2j8LuHkworb0Y3EIlWfDQ" changeDate="2006-11-13T10:02:46.356-0800" version="1.0.0">
+ <mainDescription><h3>
+ OpenUP Core Principles
+</h3>
+<p>
+ OpenUP is based on four mutually supporting core principles:
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Collaborate to align interests and share understanding
+</h4>
+<p>
+ Software is created by people with different interests and skills who must work together to create software
+ effectively.
+</p>
+<p>
+ Therefore, practices that foster a healthy team environment are key to success. A healthy team environment enables
+ effective collaboration that align the interests of project participants (development team, quality assurance, product
+ stakeholders, customers) and helps project participants develop a shared understanding of the project.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Balance competing priorities to maximize stakeholder value
+</h4>
+<p>
+ Systems need to be developed by balancing different, and sometimes competing,&nbsp;perspectives. For example, do you
+ want to minimize cost by reusing an existing capability, or by custom developing the capability to get it to do exactly
+ what you want?
+</p>
+<p>
+ Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes Stakeholder
+ benefits and is compliant with constraints placed on the project. Achieving balance is a dynamic process, because, as
+ both the stakeholders and project participants learn more about the system, their priorities and constraints change.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Focus on articulating the architecture
+</h4>
+<p>
+ Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
+ proves difficult to evolve, reuse, or integrate without substantial rework. It’s also difficult to organize the team or
+ communicate ideas without the common technical focus that the architecture provides.
+</p>
+<p>
+ Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
+ essential technical decisions through the growing architecture.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<h4>
+ Evolve to continuously obtain feedback and improve
+</h4>
+<p>
+ It is usually not possible to know all stakeholders needs, be aware of all project risks, comprehend all project
+ technologies, or know how to effectively work with your colleagues. Even if it were possible to know all of this, some
+ of it is likely to change over the life of the project.
+</p>
+<p>
+ Therefore, divide the project into short, time-boxed iterations to demonstrate incremental value and to get early and
+ continuous feedback.<span style="mso-spacerun: yes">&nbsp;</span>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/getting_started_with_openup.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/getting_started_with_openup.xmi
new file mode 100644
index 0000000..57e10bf
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/getting_started_with_openup.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-zy1Q3NXKXbiCP_zrjTxwaQ" name="getting_started,_cp6ycBOGEduCNqgZdt_OaA" guid="-zy1Q3NXKXbiCP_zrjTxwaQ" authors="Jim Ruehlin" changeDate="2007-03-01T13:31:38.471-0800" version="1.0.0">
+ <keyConsiderations><p>
+ OpenUP/Basic is a process for small, co-located teams. It can be used as-is, but if your team has significantly
+ different characteristics the process should be modified or extended to address those needs.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/intent_subprocess.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/intent_subprocess.xmi
new file mode 100644
index 0000000..4b3d1dc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/intent_subprocess.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="-QRnsN2e6IQlSMaRts-wFNw" name="new_custom_category,_57_ZMEmbEdu0xduwSKie-w" guid="-QRnsN2e6IQlSMaRts-wFNw" changeDate="2006-09-29T14:16:21.596-0400" version="1.0.0">
+ <mainDescription><p>
+ The intent sub-process deals with how to channel the intent of stakeholders to the rest of the development team, to
+ ensure that validated builds with incremental capabilities reflect stakeholder intents. This is done by capturing and
+ communicating the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a>&nbsp;to all team members, and by translating the vision into test cases and
+ requirements of different types to allow the team to understand what capabilities needs to be delivered to address
+ stakeholder intent.
+</p>
+<p>
+ You find the most tasks for the intent sub-process in the <strong>Requirements</strong> discipline, and the task Create
+ Test Cases in the <strong>Test</strong> discipline. The corresponding work products are found under
+ <strong>Requirements</strong> and <strong>Test</strong> domains.
+</p>
+<p>
+ The intent sub-process is built upon the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">&nbsp;</a>layer. That layer constitutes the backbone of OpenUP in order to reflect the
+ following:
+</p>
+<ul>
+ <li>
+ all roles in OpenUP are involved in intent development to ensure that as a minimum, all team members properly
+ understand stakeholders’ intent.
+ </li>
+ <li>
+ make sure that the best practices for collaborative development provided in the collaboration layer guides any work
+ related to intent.
+ </li>
+</ul>
+<p>
+ The intent sub-process is written in such a way that your organization can modify it to fit your style of development
+ and stakeholder collaboration, without necessarily impacting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">Management</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">&nbsp;</a>and <a class="elementLink" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">Solution</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">&nbsp;</a>development .
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/introduction_to_openup_basic.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/introduction_to_openup_basic.xmi
new file mode 100644
index 0000000..051d531
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/introduction_to_openup_basic.xmi
@@ -0,0 +1,222 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-TfxeHO_AJxYCzXVva0kSzQ" name="new_custom_category,_BTJ_YMXwEduywMSzPTUUwA" guid="-TfxeHO_AJxYCzXVva0kSzQ" changeDate="2007-03-12T09:47:01.871-0700" version="1.0.0">
+ <mainDescription><table width="589" align="center" border="0">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <a
+ href="./../../openup_basic/customcategories/getting_started_with_openup,__cft0MXxEduywMSzPTUUwA.html"
+ guid="__cft0MXxEduywMSzPTUUwA"><img height="48" alt="getting started" src="./resources/GetStarted_48.gif" width="48"
+ usemap="#Map" border="0" /></a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA"><img height="48" alt="core principles" src="./resources/CorePrinciples_48.gif"
+ width="48" usemap="#Map2" border="0" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a href="./../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg"><img height="48" alt="roles" src="./resources/Roles_48.gif" width="48"
+ usemap="#Map3" border="0" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg"><img height="48" alt="work products" src="./resources/WorkProducts_48.gif" width="48"
+ usemap="#Map4" border="0" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a
+ href="./../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ"><img height="48" alt="disciplines" src="./resources/Disciplines_48.gif" width="48"
+ usemap="#Map5" border="0" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw"><img height="48" alt="lifecycle" src="./resources/LifeCycle_48.gif" width="48"
+ usemap="#Map6" border="0" /></a>
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/customcategories/getting_started_with_openup,__cft0MXxEduywMSzPTUUwA.html"
+ guid="__cft0MXxEduywMSzPTUUwA">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA">Core Principles</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ">Disciplines</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">Lifecycle</a>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ <strong>What is OpenUP/Basic?</strong>
+</p>
+<p>
+ OpenUP/Basic is an open source software development process designed for small, co-located teams who want to take an <a
+ class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/guidelines/agile_and_unified,_qg1IAK__EduMeuOwJ2MpeQ.html"
+ guid="_qg1IAK__EduMeuOwJ2MpeQ">agile approach</a> to development. OpenUP/Basic is an iterative process that is <a
+ class="elementLink"
+ href="./../../openup_basic/guidances/guidelines/minimal_complete_extensible,_Nm5vUK__EduMeuOwJ2MpeQ.html"
+ guid="_Nm5vUK__EduMeuOwJ2MpeQ">Minimal, Complete, and Extensible</a>. It&nbsp;values collaboration and stakeholder
+ value over unnecessary deliverables and formality.
+</p>
+<p>
+ OpenUP/Basic is organized into four major areas of content: Communication&nbsp;and Collaboration, Intent, Solution, and
+ Management.
+</p>
+<p align="center">
+ <img height="350" alt="Four major areas upon which the OpenUP/Basic content is organized"
+ src="./resources/OpenUp1_350.jpg" width="350" usemap="#Map7" border="0" /> <map id="Map7" name="Map7">
+ <area shape="RECT" alt="Stakeholder" coords="144,5,207,62"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ" />
+ <area shape="POLY" alt="Tester" coords="336,242,310,287,254,256,278,209"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw" />
+ <area shape="RECT" alt="Developer" coords="148,282,201,347"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmd" />
+ <area shape="POLY" alt="Architect" coords="66,199,14,232,40,283,96,249"
+ href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Project Manager" coords="11,118,68,146,99,91,50,52"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Analyst" coords="258,99,312,66,338,114,284,145"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw" />
+ <area shape="CIRCLE" alt="Communication and Collaboration" coords="176,176,47"
+ href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Management" coords="85,219,70,163,115,89,169,72,169,117,124,144,120,197"
+ href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Intent" coords="181,116,223,143,229,196,264,219,283,160,245,94,181,70"
+ href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Solution" coords="129,211,176,235,221,210,257,231,214,271,133,272,94,232"
+ href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" />
+ </map><br />
+ &nbsp;
+</p>
+<br />
+<br />
+<p>
+ OpenUP is characterized by four mutually supporting core principles:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA.html"
+ guid="_KkTIsMp7EdqC_NfSivunjA">Collaborate</a> to align interests and share understanding
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_balance,_ssG6MMvpEdqukPpotm3DYg.html"
+ guid="_ssG6MMvpEdqukPpotm3DYg">Balance</a> competing priorities (needs and technical costs) to maximize stakeholder
+ value
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_focus,_9gocwMvoEdqukPpotm3DYg.html"
+ guid="_9gocwMvoEdqukPpotm3DYg">Focus</a> on articulating the architecture to facilitate technical collaboration,
+ reduce risk, and minimize scrap and rework.
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_evolve,_GXiogMvoEdqukPpotm3DYg.html"
+ guid="_GXiogMvoEdqukPpotm3DYg">Evolve</a> continuously to reduce risk, demonstrate results, and gain feedback from
+ the customer<br />
+ </li>
+</ul>
+<p>
+ OpenUP/Basic is ready to use as-is; nothing needs to be added or removed. It can also be extended in large and small
+ ways to add new development content or customize the process for your specific environment.
+</p>
+<p>
+ <strong>Who should use OpenUP/Basic?</strong>
+</p>
+<p>
+ OpenUP/Basic is most useful for four primary groups of users:
+</p>
+<ul>
+ <li>
+ Software development practitioners (developers, project managers, analysts, and testers) working together as a
+ project team
+ </li>
+ <li>
+ Stakeholders
+ </li>
+ <li>
+ Software process engineers
+ </li>
+ <li>
+ Instructors
+ </li>
+</ul>
+<p>
+ Software development practitioners can find guidance on what is required of them in the roles defined by OpenUP/Basic.
+ Each role describes a set of activities and artifacts that the role is responsible for. Guidance is also given on how
+ those roles collaborate.
+</p>
+<p>
+ Stakeholders will find guidance on what they may expect from the software development team and how the software will be
+ created. OpenUP/Basic also describes the stakeholders' responsibilities and how they can best work with the development
+ team to obtain software that meets their needs.
+</p>
+<p>
+ Software process engineers can use EPF Composer to extend and modify OpenUP/Basic. Modification may be as simple as
+ altering templates for work products or as sophisticated as adding activities necessary for creating software in your
+ specific environment, such as audits for safety-critical systems. In addition to modifying method content, process
+ engineers can add, change, or remove process flows to add organization-specific capability patterns.
+</p>
+<p>
+ OpenUP/Basic is appropriate for academic organizations also. As an open source process, it can serve as the basis for
+ software engineering courses and, when combined with the EPF Composer, courses in software process engineering.<br />
+</p></mainDescription>
+ <keyConsiderations><p>
+ Use OpenUP/Basic as-is when you have a small,&nbsp;co-located team.
+</p>
+<p>
+ Modify OpenUP/Basic for small teams with different circumstances, for instance a novel project or geographically
+ distributed team members.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/management_subprocess.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/management_subprocess.xmi
new file mode 100644
index 0000000..540b595
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/management_subprocess.xmi
@@ -0,0 +1,28 @@
+<?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" epf:version="1.0.0" xmi:id="-q8ubSlQ5miYcY1JXdj1fbQ" name="new_custom_category,_Aoz2gEmcEdu0xduwSKie-w" guid="-q8ubSlQ5miYcY1JXdj1fbQ" changeDate="2006-09-29T14:03:50.721-0400" version="1.0.0">
+ <mainDescription><p>
+ It is important to note that the Management sub-process is built on the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a>&nbsp;layer&nbsp;to reflect the collaborative nature
+ of management of an OpenUP project. The manager should not plan an iteration in isolation, and then tell the team
+ members their assignments. Instead, the manager should be more of a coach, involving the entire team in the planning
+ process to ensure that:
+</p>
+<ul>
+ <li>
+ Everybody’s knowledge is reflected in the plan
+ </li>
+ <li>
+ All team members estimate their own work
+ </li>
+ <li>
+ Each team member signs up to take on a task, rather than being told exactly what to do.
+ </li>
+</ul>
+<p>
+ You will find the tasks for the Management sub-process in the <strong>Project Management</strong> discipline and the
+ corresponding work products under Project Management domain.
+</p>
+<p>
+ The Management sub-process is written in such a way that your organization can modify it to fit your style of
+ development, without necessarily affecting how you deal with the other sub-processes of&nbsp;<a class="elementLink" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">Solution</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">&nbsp;</a>and <a class="elementLink" href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" guid="_57_ZMEmbEdu0xduwSKie-w">Intent</a>.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/openup_basic_deprecated.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/openup_basic_deprecated.xmi
new file mode 100644
index 0000000..42e633e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/openup_basic_deprecated.xmi
@@ -0,0 +1,2 @@
+<?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" epf:version="1.0.0" xmi:id="-nY50CawHefla4zauYddVfw" name="openup_basic,_SEztkBOJEduCNqgZdt_OaA" guid="-nY50CawHefla4zauYddVfw" changeDate="2006-09-21T10:48:17.894-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/openup_basic_views.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/openup_basic_views.xmi
new file mode 100644
index 0000000..5b7d359
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/openup_basic_views.xmi
@@ -0,0 +1,4 @@
+<?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="-8uqXjzIOnt6LVDae6Uv_0w" name="openup_basic_views,_NIIYMBOJEduCNqgZdt_OaA" guid="-8uqXjzIOnt6LVDae6Uv_0w" changeDate="2006-08-22T15:16:33.704-0700">
+ <mainDescription>[to do]</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/CorePrinciples_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/CorePrinciples_48.gif
new file mode 100644
index 0000000..da5215c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/CorePrinciples_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/Disciplines_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/Disciplines_48.gif
new file mode 100644
index 0000000..36f36b4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/Disciplines_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/GetStarted_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/GetStarted_48.gif
new file mode 100644
index 0000000..5839c94
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/GetStarted_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/LifeCycle_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/LifeCycle_48.gif
new file mode 100644
index 0000000..f7f4665
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/LifeCycle_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/OpenUp1_350.jpg b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/OpenUp1_350.jpg
new file mode 100644
index 0000000..0bb0b38
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/OpenUp1_350.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/Roles_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/Roles_48.gif
new file mode 100644
index 0000000..3fb662d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/Roles_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/WorkProducts_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/WorkProducts_48.gif
new file mode 100644
index 0000000..9554964
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/WorkProducts_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/about.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/about.gif
new file mode 100644
index 0000000..1316610
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/about.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/bookc.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/bookc.gif
new file mode 100644
index 0000000..7f2ab85
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/bookc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/bookcL.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/bookcL.gif
new file mode 100644
index 0000000..6c5b064
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/bookcL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/concept_dgm32.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/concept_dgm32.gif
new file mode 100644
index 0000000..fa195bd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/concept_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/concept_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/concept_obj.gif
new file mode 100644
index 0000000..03af38b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/concept_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/icon_introL.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/icon_introL.gif
new file mode 100644
index 0000000..1826cbd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/icon_introL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/mic.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/mic.gif
new file mode 100644
index 0000000..0b316db
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/mic.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/processicon.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/processicon.gif
new file mode 100644
index 0000000..c396682
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/processicon.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/roles_dgm32.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/roles_dgm32.gif
new file mode 100644
index 0000000..baa3d33
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/roles_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/roles_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/roles_obj.gif
new file mode 100644
index 0000000..90b1aae
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/roles_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproduct_dgm32.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproduct_dgm32.gif
new file mode 100644
index 0000000..009c9af
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproduct_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproduct_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproduct_obj.gif
new file mode 100644
index 0000000..3e58c6f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproduct_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproducts_lg_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproducts_lg_obj.gif
new file mode 100644
index 0000000..deca591
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproducts_lg_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproducts_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproducts_obj.gif
new file mode 100644
index 0000000..2e097ce
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproducts_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproductstype_lg_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproductstype_lg_obj.gif
new file mode 100644
index 0000000..626c9fd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproductstype_lg_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproductstype_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproductstype_obj.gif
new file mode 100644
index 0000000..d04a7ad
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/resources/workproductstype_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/solution_subprocess.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/solution_subprocess.xmi
new file mode 100644
index 0000000..c0f5041
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/solution_subprocess.xmi
@@ -0,0 +1,51 @@
+<?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" epf:version="1.0.0" xmi:id="-qwWeiX7WrSVHSluBe-J7yw" name="new_custom_category,_HEVvgEmcEdu0xduwSKie-w" guid="-qwWeiX7WrSVHSluBe-J7yw" changeDate="2006-09-29T14:25:13.091-0400" version="1.0.0">
+ <mainDescription><p>
+ The Solution sub-process, among others, guides how you perform the following actions:
+</p>
+<ul>
+ <li>
+ Determine architectural feasibility
+ </li>
+ <li>
+ Define architecture
+ </li>
+ <li>
+ Develop the architecture for, design, implement, and test a major change
+ </li>
+ <li>
+ Design, implement, and test a small change
+ </li>
+ <li>
+ Implement and test a trivial change
+ </li>
+ <li>
+ Test and validate builds of incrementally improved quality
+ </li>
+</ul>
+<p>
+ You find the tasks for this&nbsp;sub-process in the disciplines&nbsp;<strong>Analysis and Design,
+ Implementation,</strong> and <strong>Test</strong>, and the corresponding work products under the <strong>Architecture,
+ Development</strong>, and <strong>Test</strong> domains.
+</p>
+<p>
+ The Solution sub-process is built upon the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a>&nbsp;layer. This layer constitutes the backbone of
+ OpenUP to ensure that:
+</p>
+<ul>
+ <li>
+ All roles in OpenUP are involved in solution development
+ </li>
+ <li>
+ Validated builds are the responsibility of the entire team
+ </li>
+ <li>
+ Best practices for collaborative development guide development of the solution<strong>.</strong>
+ </li>
+</ul>
+<p>
+ The Solution sub-process is written in such a way that your organization can modify it to fit your style of
+ development, without necessarily affecting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">Management</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">&nbsp;</a>and <a class="elementLink" href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" guid="_57_ZMEmbEdu0xduwSKie-w">Intent</a>.<br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/customcategories/sub_processes.xmi b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/sub_processes.xmi
new file mode 100644
index 0000000..7fb7de3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/customcategories/sub_processes.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-1ZoXO1IRfkXUKej4bNv8cw" name="new_custom_category,_V2BQkEmbEdu0xduwSKie-w" guid="-1ZoXO1IRfkXUKej4bNv8cw" changeDate="2006-09-21T11:05:33.613-0700">
+ <mainDescription>&nbsp;</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/deliveryprocesses/openup_basic_process/content.xmi b/OpenUP/OpenUP_PT/library/openup_basic/deliveryprocesses/openup_basic_process/content.xmi
new file mode 100644
index 0000000..14062d2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/deliveryprocesses/openup_basic_process/content.xmi
@@ -0,0 +1,269 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:DeliveryProcessDescription xmi:id="_mtb-4PL5Edm6Nvont3uinw" guid="_mtb-4PL5Edm6Nvont3uinw">
+ <mainDescription><p> OpenUP/Basic is an iterative process with <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/concepts/core_principle_evolve,_GXiogMvoEdqukPpotm3DYg.html" guid="_GXiogMvoEdqukPpotm3DYg">iterations</a>&nbsp;distributed
+ throughout four <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html" guid="__7xOEC7aEdqHMdmRzC0-2g">phases</a>:
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html" guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>,
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html" guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>,
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html" guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>,
+ and <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html" guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>.
+</p>
+<p> Each phase may have as many iterations as needed, depending on degree of novelty
+ of the business domain, technology being used, architectural complexity, and
+ project size, to name a few factors. </p>
+<p> To offer a quick start for teams to plan their iterations,&nbsp;OpenUP/Basic
+ provides&nbsp;work breakdown structure (WBS) templates for each iteration and
+ a WBS template for an end-to-end process. </p>
+<p> Iterations may have variable lengths, depending on project characteristics.
+ One-month iterations are typically recommended, because
+ this timeframe provides: </p>
+<ul>
+ <li> A reasonable amount of time for projects to
+ deliver meaningful increments in functionality. </li>
+ <li> Early and frequent customer feedback. </li>
+ <li> Timely management of risks and issues during the course of the project.
+ </li>
+</ul>
+<p> OpenUP/Basic is intended<strong> </strong>to
+ offer process guidance to small projects: </p>
+<ul>
+ <li>
+
+ <div class="O" style="mso-margin-left-alt: 216; mso-char-wrap: 1; mso-kinsoku-overflow: 1" v:shape="_x0000_s1026">
+ 3&nbsp;to&nbsp;6 people on the team </div>
+ </li>
+ <li>
+
+ <div class="O" style="mso-margin-left-alt: 216; mso-char-wrap: 1; mso-kinsoku-overflow: 1" v:shape="_x0000_s1026">
+ 3&nbsp;to&nbsp;6 months of work</div>
+ </li>
+</ul></mainDescription>
+ <purpose><p>
+ The purposes of this delivery process are to:
+</p>
+<ul>
+ <li>
+ Offer process guidance for small-scale projects
+ </li>
+ <li>
+ Allow project managers to create project plans based on the proposed work breakdown structures
+ </li>
+ <li>
+ Allow project managers to track status based on goals
+ </li>
+ <li>
+ Allow&nbsp;team members&nbsp;to understand how to perform their work to achieve project goals
+ </li>
+ <li>
+ Provide a complete, end-to-end delivery process that serves as an example for defining alternative delivery
+ processes
+ </li>
+</ul></purpose>
+ </org.eclipse.epf.uma:DeliveryProcessDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-aXO_Hxa-5gvaRMvpx9cngQ" name="lifecycle_objectives,_mRwHoMA9EdqSgKaj2SZBmg" guid="-aXO_Hxa-5gvaRMvpx9cngQ">
+ <mainDescription><p>
+ The Lifecycle Objectives Milestone is the first major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>, the following evaluation criteria should be met <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stakeholder concurrence on
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ scope definition,
+ </li>
+ <li>
+ initial cost/schedule estimates,
+ </li>
+ <li>
+ initial set of requirements defined and prioritized,
+ </li>
+ <li>
+ risks identified and mitigation strategies proposed.
+ </li>
+ </ul>
+ </li>
+</ul>
+<br />
+The project may be aborted or reconsidered if it fails to reach this milestone.<br /></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-KD_OqyKE74agcRb6I4YuAg" name="lifecycle_architecture,_RYHw4MA-EdqSgKaj2SZBmg" guid="-KD_OqyKE74agcRb6I4YuAg">
+ <mainDescription><p>
+ The Lifecycle Architecture Milestone is the&nbsp;second major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Elaboration, you should keep these&nbsp;evaluation
+ criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stability of Vision, requirements and Architecture.
+ </li>
+ <li>
+ Major risk elements addressed and resolved by testing and evaluating executable prototypes.
+ </li>
+ <li>
+ Construction iterations planned in sufficient detail and&nbsp;credibly estimated&nbsp;to allow the work to proceed.
+ </li>
+ <li>
+ Agreement of stakeholders that the current vision can be met if plans are executed to develop complete system on
+ top of current architecture.
+ </li>
+ <li>
+ Resourse expenditures versus planned expenditures are acceptable.<br />
+ </li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-zGLnE1j7yvWoX9mok6lLLQ" name="product_release,_X3F_cMA-EdqSgKaj2SZBmg" guid="-zGLnE1j7yvWoX9mok6lLLQ">
+ <mainDescription><p>
+ The Product Release Milestone is the last major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>, you decide if the objectives were met and <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/close_out_project,_0mMLUMlgEdmt3adZL5Dmdw.html" guid="_0mMLUMlgEdmt3adZL5Dmdw">close</a> the project.&nbsp;The evaluation criteria to keep in mind are <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Users satisfaction and product acceptance.
+ </li>
+ <li>
+ Stakeholders concurrence on acceptable resource expenditures versus planned expenditures.
+ </li>
+ <li>
+ Product is in production. A new development cycle for enhancements or maintenance may start.
+ </li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-R8Q0YMat1l4nMKZaSg7Law" name="initial_operational_capability,_TV_y0MA-EdqSgKaj2SZBmg" guid="-R8Q0YMat1l4nMKZaSg7Law">
+ <mainDescription><p>
+ The Initial Operational Capability&nbsp;Milestone is the&nbsp;third major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Construction, you should keep these&nbsp;evaluation
+ criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Product release stable and mature enough to be deployed in the user community
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ the product is ready to be handed over to&nbsp;the users&nbsp;(beta)
+ </li>
+ <li>
+ all functionality has been developed and all alpha testing (if any) has been completed
+ </li>
+ <li>
+ in addition to the software, a user manual has been developed, and there is a description of the current
+ release
+ </li>
+ </ul>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <br />
+ </li>
+ <li>
+ Actual resource expenditures versus planned expenditures are acceptable
+ </li>
+</ul>
+<p>
+ In case the project fails to reach this milestone, an iteration can be added to Construction, thus postponing
+ Transition.
+</p></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-qk_QXyoSxOb2C-boCISB5g" name="lifecycle_objectives,_mRwHoMA9EdqSgKaj2SZBmg" guid="-qk_QXyoSxOb2C-boCISB5g">
+ <mainDescription><p> The Lifecycle Objectives Milestone is the first major project milestone. During
+ the iteration<a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw"> assessment</a>, the following evaluation criteria
+ should be met <a
+ class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>: </p>
+<ul>
+ <li>
+ Stakeholder concurrence on
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+
+ <li> scope definition</li>
+ <li> initial cost and schedule estimates</li>
+ <li>definitions and priorities for initial set of requirements</li>
+ <li>
+ risks identified and mitigation strategies proposed.
+ </li>
+ </ul>
+ </li>
+</ul>
+<p><br />
+ Note:<strong> </strong></p>
+<p>The project may be aborted or reconsidered if it fails to reach this milestone.<br /></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-3Ul1iAI1nkD0C5AsRtjHFA" name="lifecycle_architecture,_RYHw4MA-EdqSgKaj2SZBmg" guid="-3Ul1iAI1nkD0C5AsRtjHFA">
+ <mainDescription><p>
+ The Lifecycle Architecture Milestone is the&nbsp;second major project milestone. During iteration <a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Elaboration, you should keep these&nbsp;evaluation
+ criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stability of Vision, requirements and Architecture.
+ </li>
+ <li>
+ Major risk elements addressed and resolved by testing and evaluating executable prototypes.
+ </li>
+ <li>
+ Construction iterations planned in sufficient detail and&nbsp;credibly estimated&nbsp;to allow the work to proceed.
+ </li>
+ <li>
+ Agreement of stakeholders that the current vision can be met if plans are executed to develop complete system on
+ top of current architecture.
+ </li>
+ <li>
+ Resourse expenditures versus planned expenditures are acceptable.<br />
+ </li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-Q37Qy6ke_PQDK4jr1EIdcA" name="initial_operational_capability,_TV_y0MA-EdqSgKaj2SZBmg" guid="-Q37Qy6ke_PQDK4jr1EIdcA">
+ <mainDescription><p> The Initial Operational Capability&nbsp;Milestone is the&nbsp;third major
+ project milestone. During iteration <a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Construction, keep
+ these&nbsp;evaluation criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>: </p>
+<ul>
+
+ <li> Product release is stable and mature enough to be deployed in the user
+ community.</li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+
+ <li> The beta product is ready to be handed over to&nbsp;the users.</li>
+ <li> All functionality has been developed and all alpha testing (if any)
+ has been completed.</li>
+ <li> In addition to the software, a user manual has been developed, and
+ there is a description of the current release. </li>
+ </ul>
+ </li>
+ <li style="LIST-STYLE-TYPE: none"> </li>
+ <li> Actual resource expenditures compared to planned expenditures are acceptable.</li>
+</ul>
+<p> Note:<strong> </strong></p>
+<p>In case the project fails to reach this milestone, an iteration can be added
+ to Construction, thus postponing Transition. </p></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-Gt2aCyZVy4q1BvcJRM2E-A" name="product_release,_X3F_cMA-EdqSgKaj2SZBmg" guid="-Gt2aCyZVy4q1BvcJRM2E-A">
+ <mainDescription><p> The Product Release Milestone is the last major project milestone. During
+ iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>,
+ you decide if the objectives were met, and&nbsp;then close the project.&nbsp;These
+ are the evaluation criteria to keep in mind <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+
+ <li> Users satisfaction and product acceptance</li>
+
+ <li> Stakeholder concurrence on acceptable resource expenditures compared to
+ planned expenditures</li>
+
+ <li> Product is in production; therefore, a new development cycle for enhancements
+ or maintenance may start</li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/deliveryprocesses/openup_basic_process/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/deliveryprocesses/openup_basic_process/model.xmi
new file mode 100644
index 0000000..963d474
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/deliveryprocesses/openup_basic_process/model.xmi
@@ -0,0 +1,1426 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nNtaYPL5Edm6Nvont3uinw" guid="_nNtaYPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nNCE8_L5Edm6Nvont3uinw" id="_mtb-4fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4PVgEdmdHa9MmVPgqQ" id="_mtb-4vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4fVgEdmdHa9MmVPgqQ" id="_mtb-4_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4vVgEdmdHa9MmVPgqQ" id="_mtb-5PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4_VgEdmdHa9MmVPgqQ" id="_mtb-5fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUq6gPVgEdmdHa9MmVPgqQ" id="_mtb-5vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUq6gfVgEdmdHa9MmVPgqQ" id="_mtb-5_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUq6gvVgEdmdHa9MmVPgqQ" id="_mtb-4PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_sW9V0OqDEdqKGv75AZ0adQ" id="-aXO_Hxa-5gvaRMvpx9cngQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_fY-vkOqbEdqKGv75AZ0adQ" id="-KD_OqyKE74agcRb6I4YuAg" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_LMpNkOqlEdqS7vuq4kvZhg" id="-zGLnE1j7yvWoX9mok6lLLQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_X1zsgOqwEdqS7vuq4kvZhg" id="-R8Q0YMat1l4nMKZaSg7Law" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_CN-F0BOLEduCNqgZdt_OaA" id="-qk_QXyoSxOb2C-boCISB5g" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_COEMcBOLEduCNqgZdt_OaA" id="-3Ul1iAI1nkD0C5AsRtjHFA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_COQZsBOLEduCNqgZdt_OaA" id="-Q37Qy6ke_PQDK4jr1EIdcA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_COWgUBOLEduCNqgZdt_OaA" id="-Gt2aCyZVy4q1BvcJRM2E-A" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0uHYQclgEdmt3adZL5Dmdw" name="openup_basic_process" guid="_0uHYQclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_xujGABOKEduCNqgZdt_OaA" name="inception_phase_iteration" guid="_xujGABOKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_xupMvxOKEduCNqgZdt_OaA" name="inception_phase_iteration" guid="_xupMvxOKEduCNqgZdt_OaA" presentationName="Inception Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0o3r4slgEdmt3adZL5Dmdw"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hmKgBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <diagrams xmi:id="_xujGAROKEduCNqgZdt_OaA" guid="_xujGAROKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGEhOKEduCNqgZdt_OaA" guid="_xujGEhOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMwhOKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGExOKEduCNqgZdt_OaA" guid="_xujGExOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMwxOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMtxOKEduCNqgZdt_OaA" guid="_xupMtxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMxBOKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xupMuROKEduCNqgZdt_OaA" guid="_xupMuROKEduCNqgZdt_OaA" anchor="_xupMuhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xupMuhOKEduCNqgZdt_OaA" guid="_xupMuhOKEduCNqgZdt_OaA" graphEdge="_xupMuROKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMxROKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMuBOKEduCNqgZdt_OaA" guid="_xupMuBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMxhOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGEBOKEduCNqgZdt_OaA" guid="_xujGEBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMxxOKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGEROKEduCNqgZdt_OaA" guid="_xujGEROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMyBOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGGhOKEduCNqgZdt_OaA" guid="_xujGGhOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMyROKEduCNqgZdt_OaA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGGxOKEduCNqgZdt_OaA" guid="_xujGGxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMyhOKEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGHBOKEduCNqgZdt_OaA" guid="_xujGHBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMyxOKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGHROKEduCNqgZdt_OaA" guid="_xujGHROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMzBOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMpROKEduCNqgZdt_OaA" guid="_xupMpROKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMzROKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xupMphOKEduCNqgZdt_OaA" guid="_xupMphOKEduCNqgZdt_OaA" anchor="_xupMqBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xupMqBOKEduCNqgZdt_OaA" guid="_xupMqBOKEduCNqgZdt_OaA" graphEdge="_xupMphOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMzhOKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMpxOKEduCNqgZdt_OaA" guid="_xupMpxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTQBOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGDhOKEduCNqgZdt_OaA" guid="_xujGDhOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTQROKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGDxOKEduCNqgZdt_OaA" guid="_xujGDxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTQhOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMqROKEduCNqgZdt_OaA" guid="_xupMqROKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTQxOKEduCNqgZdt_OaA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMqhOKEduCNqgZdt_OaA" guid="_xupMqhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTRBOKEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMuxOKEduCNqgZdt_OaA" guid="_xupMuxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTRROKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMvBOKEduCNqgZdt_OaA" guid="_xupMvBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTRhOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGQBOKEduCNqgZdt_OaA" guid="_xujGQBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTRxOKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xujGQxOKEduCNqgZdt_OaA" guid="_xujGQxOKEduCNqgZdt_OaA" anchor="_xujGQhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xujGQhOKEduCNqgZdt_OaA" guid="_xujGQhOKEduCNqgZdt_OaA" graphEdge="_xujGQxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTSBOKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGQROKEduCNqgZdt_OaA" guid="_xujGQROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTSROKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGRBOKEduCNqgZdt_OaA" guid="_xujGRBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTShOKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMoBOKEduCNqgZdt_OaA" guid="_xupMoBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTSxOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGFBOKEduCNqgZdt_OaA" guid="_xujGFBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTUBOKEduCNqgZdt_OaA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGFROKEduCNqgZdt_OaA" guid="_xujGFROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTUROKEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGDBOKEduCNqgZdt_OaA" guid="_xujGDBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTUhOKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGDROKEduCNqgZdt_OaA" guid="_xujGDROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTUxOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMoROKEduCNqgZdt_OaA" guid="_xupMoROKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTXBOKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xupMpBOKEduCNqgZdt_OaA" guid="_xupMpBOKEduCNqgZdt_OaA" anchor="_xupMoxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xupMoxOKEduCNqgZdt_OaA" guid="_xupMoxOKEduCNqgZdt_OaA" graphEdge="_xupMpBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTXROKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMohOKEduCNqgZdt_OaA" guid="_xupMohOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTXhOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGBxOKEduCNqgZdt_OaA" guid="_xujGBxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTXxOKEduCNqgZdt_OaA" x="368.0" y="300.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xujGChOKEduCNqgZdt_OaA" guid="_xujGChOKEduCNqgZdt_OaA" anchor="_xujGCROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xujGCxOKEduCNqgZdt_OaA" guid="_xujGCxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xujGCROKEduCNqgZdt_OaA" guid="_xujGCROKEduCNqgZdt_OaA" graphEdge="_xujGChOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTYBOKEduCNqgZdt_OaA" x="464.0" y="312.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGCBOKEduCNqgZdt_OaA" guid="_xujGCBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTYROKEduCNqgZdt_OaA" width="149.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMvROKEduCNqgZdt_OaA" guid="_xupMvROKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTYhOKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMvhOKEduCNqgZdt_OaA" guid="_xupMvhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTYxOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2QEqbEduiL77U_PmnmA" guid="_5gR2QEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2QUqbEduiL77U_PmnmA" x="111.0" y="102.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2QkqbEduiL77U_PmnmA" guid="_5gR2QkqbEduiL77U_PmnmA" anchor="_5gR2RUqbEduiL77U_PmnmA _5gR2hUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2Q0qbEduiL77U_PmnmA" guid="_5gR2Q0qbEduiL77U_PmnmA" graphEdge="_5gR2cEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2REqbEduiL77U_PmnmA" x="26.0" y="-28.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2RUqbEduiL77U_PmnmA" guid="_5gR2RUqbEduiL77U_PmnmA" graphEdge="_5gR2QkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2RkqbEduiL77U_PmnmA" x="25.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2R0qbEduiL77U_PmnmA" guid="_5gR2R0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_5gR2SEqbEduiL77U_PmnmA" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2SUqbEduiL77U_PmnmA" guid="_5gR2SUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2SkqbEduiL77U_PmnmA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2S0qbEduiL77U_PmnmA" guid="_5gR2S0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2TEqbEduiL77U_PmnmA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2TUqbEduiL77U_PmnmA" guid="_5gR2TUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2TkqbEduiL77U_PmnmA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2T0qbEduiL77U_PmnmA" guid="_5gR2T0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2UEqbEduiL77U_PmnmA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2UUqbEduiL77U_PmnmA" guid="_5gR2UUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2UkqbEduiL77U_PmnmA" x="-25.0" y="204.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2U0qbEduiL77U_PmnmA" guid="_5gR2U0qbEduiL77U_PmnmA" anchor="_5gR2VkqbEduiL77U_PmnmA _5gR2jkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2VEqbEduiL77U_PmnmA" guid="_5gR2VEqbEduiL77U_PmnmA" graphEdge="_5gR2f0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2VUqbEduiL77U_PmnmA" x="100.0" y="-13.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2VkqbEduiL77U_PmnmA" guid="_5gR2VkqbEduiL77U_PmnmA" graphEdge="_5gR2U0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2V0qbEduiL77U_PmnmA" x="97.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2WEqbEduiL77U_PmnmA" guid="_5gR2WEqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0okw8clgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_5gR2WUqbEduiL77U_PmnmA" width="207.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2WkqbEduiL77U_PmnmA" guid="_5gR2WkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2W0qbEduiL77U_PmnmA" x="108.0" y="238.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2XEqbEduiL77U_PmnmA" guid="_5gR2XEqbEduiL77U_PmnmA" anchor="_5gR2X0qbEduiL77U_PmnmA _5gR2kEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2XUqbEduiL77U_PmnmA" guid="_5gR2XUqbEduiL77U_PmnmA" graphEdge="_5gR2gEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2XkqbEduiL77U_PmnmA" x="73.0" y="-85.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2X0qbEduiL77U_PmnmA" guid="_5gR2X0qbEduiL77U_PmnmA" graphEdge="_5gR2XEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2YEqbEduiL77U_PmnmA" x="79.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2YUqbEduiL77U_PmnmA" guid="_5gR2YUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oreoclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_5gR2YkqbEduiL77U_PmnmA" width="164.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2Y0qbEduiL77U_PmnmA" guid="_5gR2Y0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2ZEqbEduiL77U_PmnmA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2ZUqbEduiL77U_PmnmA" guid="_5gR2ZUqbEduiL77U_PmnmA" anchor="_5gR2ZkqbEduiL77U_PmnmA _5gR2jEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2ZkqbEduiL77U_PmnmA" guid="_5gR2ZkqbEduiL77U_PmnmA" graphEdge="_5gR2ZUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2Z0qbEduiL77U_PmnmA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2aEqbEduiL77U_PmnmA" guid="_5gR2aEqbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2aUqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2akqbEduiL77U_PmnmA" guid="_5gR2akqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2a0qbEduiL77U_PmnmA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2bEqbEduiL77U_PmnmA" guid="_5gR2bEqbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2bUqbEduiL77U_PmnmA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2bkqbEduiL77U_PmnmA" guid="_5gR2bkqbEduiL77U_PmnmA" briefDescription="_boMAIPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2b0qbEduiL77U_PmnmA" x="5.0" y="68.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2cEqbEduiL77U_PmnmA" guid="_5gR2cEqbEduiL77U_PmnmA" anchor="_5gR2c0qbEduiL77U_PmnmA _5gR2Q0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2cUqbEduiL77U_PmnmA" guid="_5gR2cUqbEduiL77U_PmnmA" anchor="_5gR2dUqbEduiL77U_PmnmA _5gR2qUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2ckqbEduiL77U_PmnmA" guid="_5gR2ckqbEduiL77U_PmnmA" anchor="_5gR2eUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2c0qbEduiL77U_PmnmA" guid="_5gR2c0qbEduiL77U_PmnmA" graphEdge="_5gR2cEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2dEqbEduiL77U_PmnmA" x="145.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2dUqbEduiL77U_PmnmA" guid="_5gR2dUqbEduiL77U_PmnmA" graphEdge="_5gR2cUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2dkqbEduiL77U_PmnmA" x="332.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2d0qbEduiL77U_PmnmA" guid="_5gR2d0qbEduiL77U_PmnmA" graphEdge="_5gR2nEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2eEqbEduiL77U_PmnmA" x="179.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2eUqbEduiL77U_PmnmA" guid="_5gR2eUqbEduiL77U_PmnmA" graphEdge="_5gR2ckqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2ekqbEduiL77U_PmnmA" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2e0qbEduiL77U_PmnmA" guid="_5gR2e0qbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_5gR2fEqbEduiL77U_PmnmA" width="454.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2fUqbEduiL77U_PmnmA" guid="_5gR2fUqbEduiL77U_PmnmA" briefDescription="_cV9FEPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2fkqbEduiL77U_PmnmA" x="26.0" y="169.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2f0qbEduiL77U_PmnmA" guid="_5gR2f0qbEduiL77U_PmnmA" anchor="_5gR2gUqbEduiL77U_PmnmA _5gR2VEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2gEqbEduiL77U_PmnmA" guid="_5gR2gEqbEduiL77U_PmnmA" anchor="_5gR2g0qbEduiL77U_PmnmA _5gR2XUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2gUqbEduiL77U_PmnmA" guid="_5gR2gUqbEduiL77U_PmnmA" graphEdge="_5gR2f0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2gkqbEduiL77U_PmnmA" x="52.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2g0qbEduiL77U_PmnmA" guid="_5gR2g0qbEduiL77U_PmnmA" graphEdge="_5gR2gEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2hEqbEduiL77U_PmnmA" x="163.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2hUqbEduiL77U_PmnmA" guid="_5gR2hUqbEduiL77U_PmnmA" graphEdge="_5gR2QkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2hkqbEduiL77U_PmnmA" x="124.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2h0qbEduiL77U_PmnmA" guid="_5gR2h0qbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_5gR2iEqbEduiL77U_PmnmA" width="225.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2iUqbEduiL77U_PmnmA" guid="_5gR2iUqbEduiL77U_PmnmA" briefDescription="_f4q94Pr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2ikqbEduiL77U_PmnmA" x="4.0" y="344.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2i0qbEduiL77U_PmnmA" guid="_5gR2i0qbEduiL77U_PmnmA" anchor="_5gR2lEqbEduiL77U_PmnmA _5gR2o0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2jEqbEduiL77U_PmnmA" guid="_5gR2jEqbEduiL77U_PmnmA" graphEdge="_5gR2ZUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2jUqbEduiL77U_PmnmA" x="134.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2jkqbEduiL77U_PmnmA" guid="_5gR2jkqbEduiL77U_PmnmA" graphEdge="_5gR2U0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2j0qbEduiL77U_PmnmA" x="74.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2kEqbEduiL77U_PmnmA" guid="_5gR2kEqbEduiL77U_PmnmA" graphEdge="_5gR2XEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2kUqbEduiL77U_PmnmA" x="186.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2kkqbEduiL77U_PmnmA" guid="_5gR2kkqbEduiL77U_PmnmA" graphEdge="_5gR2qEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2k0qbEduiL77U_PmnmA" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2lEqbEduiL77U_PmnmA" guid="_5gR2lEqbEduiL77U_PmnmA" graphEdge="_5gR2i0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2lUqbEduiL77U_PmnmA" x="189.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2lkqbEduiL77U_PmnmA" guid="_5gR2lkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2l0qbEduiL77U_PmnmA" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2mEqbEduiL77U_PmnmA" guid="_5gR2mEqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_5gR2mUqbEduiL77U_PmnmA" width="463.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2mkqbEduiL77U_PmnmA" guid="_5gR2mkqbEduiL77U_PmnmA" briefDescription="_iEptQPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2m0qbEduiL77U_PmnmA" x="175.0" y="19.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2nEqbEduiL77U_PmnmA" guid="_5gR2nEqbEduiL77U_PmnmA" anchor="_5gR2nUqbEduiL77U_PmnmA _5gR2d0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2nUqbEduiL77U_PmnmA" guid="_5gR2nUqbEduiL77U_PmnmA" graphEdge="_5gR2nEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2nkqbEduiL77U_PmnmA" x="8.0" y="-1.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2n0qbEduiL77U_PmnmA" guid="_5gR2n0qbEduiL77U_PmnmA" typeInfo="start node"/>
+ <size xmi:id="_5gR2oEqbEduiL77U_PmnmA" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2oUqbEduiL77U_PmnmA" guid="_5gR2oUqbEduiL77U_PmnmA" briefDescription="_idu7oPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2okqbEduiL77U_PmnmA" x="182.0" y="382.0"/>
+ <anchorage xmi:id="_5gR2o0qbEduiL77U_PmnmA" guid="_5gR2o0qbEduiL77U_PmnmA" graphEdge="_5gR2i0qbEduiL77U_PmnmA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2pEqbEduiL77U_PmnmA" guid="_5gR2pEqbEduiL77U_PmnmA" typeInfo="end node"/>
+ <size xmi:id="_5gR2pUqbEduiL77U_PmnmA" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2pkqbEduiL77U_PmnmA" guid="_5gR2pkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2p0qbEduiL77U_PmnmA" x="296.0" y="145.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2qEqbEduiL77U_PmnmA" guid="_5gR2qEqbEduiL77U_PmnmA" anchor="_5gR2q0qbEduiL77U_PmnmA _5gR2kkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2qUqbEduiL77U_PmnmA" guid="_5gR2qUqbEduiL77U_PmnmA" graphEdge="_5gR2cUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2qkqbEduiL77U_PmnmA" x="33.0" y="-129.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2q0qbEduiL77U_PmnmA" guid="_5gR2q0qbEduiL77U_PmnmA" graphEdge="_5gR2qEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2rEqbEduiL77U_PmnmA" x="39.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2rUqbEduiL77U_PmnmA" guid="_5gR2rUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_jLaKwP77Edm1zMZYtD3GjA"/>
+ </semanticModel>
+ <size xmi:id="_5gR2rkqbEduiL77U_PmnmA" width="83.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGPxOKEduCNqgZdt_OaA" guid="_xujGPxOKEduCNqgZdt_OaA" presentation="Workflow" element="_xupMvxOKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0SpacBOKEduCNqgZdt_OaA" name="elaboration_phase_iteration" guid="_0SpacBOKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0Spa4BOKEduCNqgZdt_OaA" name="elaboration_phase_iteration" guid="_0Spa4BOKEduCNqgZdt_OaA" presentationName="Elaboration Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" isRepeatable="true" linkToPredecessor="_8bf3QBOSEduCNqgZdt_OaA" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0sTaYMlgEdmt3adZL5Dmdw"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_2plxwBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_8bf3QBOSEduCNqgZdt_OaA" guid="_8bf3QBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_y1uwgBOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_0SpacROKEduCNqgZdt_OaA" guid="_0SpacROKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpalxOKEduCNqgZdt_OaA" guid="_0SpalxOKEduCNqgZdt_OaA">
+ <position xmi:id="_0Spa5xOKEduCNqgZdt_OaA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpamBOKEduCNqgZdt_OaA" guid="_0SpamBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0Spa6BOKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpavhOKEduCNqgZdt_OaA" guid="_0SpavhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0Spa6ROKEduCNqgZdt_OaA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpawROKEduCNqgZdt_OaA" guid="_0SpawROKEduCNqgZdt_OaA" anchor="_0SpavxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpavxOKEduCNqgZdt_OaA" guid="_0SpavxOKEduCNqgZdt_OaA" graphEdge="_0SpawROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhEBOKEduCNqgZdt_OaA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpawBOKEduCNqgZdt_OaA" guid="_0SpawBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhEROKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0Spa0BOKEduCNqgZdt_OaA" guid="_0Spa0BOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhEhOKEduCNqgZdt_OaA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0Spa0hOKEduCNqgZdt_OaA" guid="_0Spa0hOKEduCNqgZdt_OaA" anchor="_0Spa0ROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0Spa0ROKEduCNqgZdt_OaA" guid="_0Spa0ROKEduCNqgZdt_OaA" graphEdge="_0Spa0hOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhExOKEduCNqgZdt_OaA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0Spa0xOKEduCNqgZdt_OaA" guid="_0Spa0xOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhFBOKEduCNqgZdt_OaA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpamROKEduCNqgZdt_OaA" guid="_0SpamROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhFROKEduCNqgZdt_OaA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpamhOKEduCNqgZdt_OaA" guid="_0SpamhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhFhOKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpauhOKEduCNqgZdt_OaA" guid="_0SpauhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhFxOKEduCNqgZdt_OaA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpavROKEduCNqgZdt_OaA" guid="_0SpavROKEduCNqgZdt_OaA" anchor="_0SpavBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpavBOKEduCNqgZdt_OaA" guid="_0SpavBOKEduCNqgZdt_OaA" graphEdge="_0SpavROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhGBOKEduCNqgZdt_OaA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpauxOKEduCNqgZdt_OaA" guid="_0SpauxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhGROKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0Spa3BOKEduCNqgZdt_OaA" guid="_0Spa3BOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhGhOKEduCNqgZdt_OaA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0Spa3ROKEduCNqgZdt_OaA" guid="_0Spa3ROKEduCNqgZdt_OaA" anchor="_0Spa3xOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0Spa3xOKEduCNqgZdt_OaA" guid="_0Spa3xOKEduCNqgZdt_OaA" graphEdge="_0Spa3ROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhGxOKEduCNqgZdt_OaA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0Spa3hOKEduCNqgZdt_OaA" guid="_0Spa3hOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhHBOKEduCNqgZdt_OaA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpaqhOKEduCNqgZdt_OaA" guid="_0SpaqhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhKBOKEduCNqgZdt_OaA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpaqxOKEduCNqgZdt_OaA" guid="_0SpaqxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhKROKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpasROKEduCNqgZdt_OaA" guid="_0SpasROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhLROKEduCNqgZdt_OaA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpasxOKEduCNqgZdt_OaA" guid="_0SpasxOKEduCNqgZdt_OaA" anchor="_0SpashOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpashOKEduCNqgZdt_OaA" guid="_0SpashOKEduCNqgZdt_OaA" graphEdge="_0SpasxOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhLhOKEduCNqgZdt_OaA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpatBOKEduCNqgZdt_OaA" guid="_0SpatBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhLxOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpamxOKEduCNqgZdt_OaA" guid="_0SpamxOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhNROKEduCNqgZdt_OaA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpanhOKEduCNqgZdt_OaA" guid="_0SpanhOKEduCNqgZdt_OaA" anchor="_0SpanBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpanBOKEduCNqgZdt_OaA" guid="_0SpanBOKEduCNqgZdt_OaA" graphEdge="_0SpanhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhNhOKEduCNqgZdt_OaA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpanROKEduCNqgZdt_OaA" guid="_0SpanROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhNxOKEduCNqgZdt_OaA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lfukbtEduTiINs4_IZ_Q" guid="_32lfukbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfu0btEduTiINs4_IZ_Q" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lfvEbtEduTiINs4_IZ_Q" guid="_32lfvEbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lfvUbtEduTiINs4_IZ_Q" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lfxkbtEduTiINs4_IZ_Q" guid="_32lfxkbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfx0btEduTiINs4_IZ_Q" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_32lfyEbtEduTiINs4_IZ_Q" guid="_32lfyEbtEduTiINs4_IZ_Q" anchor="_32lfyUbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lfyUbtEduTiINs4_IZ_Q" guid="_32lfyUbtEduTiINs4_IZ_Q" graphEdge="_32lfyEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfykbtEduTiINs4_IZ_Q" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lfy0btEduTiINs4_IZ_Q" guid="_32lfy0btEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lfzEbtEduTiINs4_IZ_Q" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lfzUbtEduTiINs4_IZ_Q" guid="_32lfzUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfzkbtEduTiINs4_IZ_Q" x="387.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_32lfz0btEduTiINs4_IZ_Q" guid="_32lfz0btEduTiINs4_IZ_Q" anchor="_32lf0UbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lf0EbtEduTiINs4_IZ_Q" guid="_32lf0EbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lf0UbtEduTiINs4_IZ_Q" guid="_32lf0UbtEduTiINs4_IZ_Q" graphEdge="_32lfz0btEduTiINs4_IZ_Q">
+ <position xmi:id="_32lf0kbtEduTiINs4_IZ_Q" x="525.0" y="388.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lf00btEduTiINs4_IZ_Q" guid="_32lf00btEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lf1EbtEduTiINs4_IZ_Q" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lf2kbtEduTiINs4_IZ_Q" guid="_32lf2kbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lf20btEduTiINs4_IZ_Q" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_32lf3EbtEduTiINs4_IZ_Q" guid="_32lf3EbtEduTiINs4_IZ_Q" anchor="_32lf3UbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lf3UbtEduTiINs4_IZ_Q" guid="_32lf3UbtEduTiINs4_IZ_Q" graphEdge="_32lf3EbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lf3kbtEduTiINs4_IZ_Q" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lf30btEduTiINs4_IZ_Q" guid="_32lf30btEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lf4EbtEduTiINs4_IZ_Q" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzIEqbEduiL77U_PmnmA" guid="_7BJzIEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzIUqbEduiL77U_PmnmA" x="338.0" y="74.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzIkqbEduiL77U_PmnmA" guid="_7BJzIkqbEduiL77U_PmnmA" anchor="_7BJzJEqbEduiL77U_PmnmA _7BJzkEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzI0qbEduiL77U_PmnmA" guid="_7BJzI0qbEduiL77U_PmnmA" graphEdge="_7BJzaEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzJEqbEduiL77U_PmnmA" guid="_7BJzJEqbEduiL77U_PmnmA" graphEdge="_7BJzIkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzJUqbEduiL77U_PmnmA" x="449.0" y="218.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzJkqbEduiL77U_PmnmA" guid="_7BJzJkqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIslgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzJ0qbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzKEqbEduiL77U_PmnmA" guid="_7BJzKEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzKUqbEduiL77U_PmnmA" x="-58.0" y="81.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzKkqbEduiL77U_PmnmA" guid="_7BJzKkqbEduiL77U_PmnmA" anchor="_7BJzLUqbEduiL77U_PmnmA _7BJzhkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzK0qbEduiL77U_PmnmA" guid="_7BJzK0qbEduiL77U_PmnmA" graphEdge="_7BJzY0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzLEqbEduiL77U_PmnmA" x="75.0" y="-62.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzLUqbEduiL77U_PmnmA" guid="_7BJzLUqbEduiL77U_PmnmA" graphEdge="_7BJzKkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzLkqbEduiL77U_PmnmA" x="78.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzL0qbEduiL77U_PmnmA" guid="_7BJzL0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0ruyoclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzMEqbEduiL77U_PmnmA" width="236.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzMUqbEduiL77U_PmnmA" guid="_7BJzMUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzMkqbEduiL77U_PmnmA" x="63.0" y="120.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzM0qbEduiL77U_PmnmA" guid="_7BJzM0qbEduiL77U_PmnmA" anchor="_7BJzNkqbEduiL77U_PmnmA _7BJziEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzNEqbEduiL77U_PmnmA" guid="_7BJzNEqbEduiL77U_PmnmA" graphEdge="_7BJzZEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzNUqbEduiL77U_PmnmA" x="18.0" y="-88.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzNkqbEduiL77U_PmnmA" guid="_7BJzNkqbEduiL77U_PmnmA" graphEdge="_7BJzM0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzN0qbEduiL77U_PmnmA" x="32.0" y="26.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzOEqbEduiL77U_PmnmA" guid="_7BJzOEqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rcewclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzOUqbEduiL77U_PmnmA" width="146.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzOkqbEduiL77U_PmnmA" guid="_7BJzOkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzO0qbEduiL77U_PmnmA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzPEqbEduiL77U_PmnmA" guid="_7BJzPEqbEduiL77U_PmnmA"/>
+ <size xmi:id="_7BJzPUqbEduiL77U_PmnmA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzPkqbEduiL77U_PmnmA" guid="_7BJzPkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzP0qbEduiL77U_PmnmA" x="245.0" y="221.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzQEqbEduiL77U_PmnmA" guid="_7BJzQEqbEduiL77U_PmnmA" anchor="_7BJzQkqbEduiL77U_PmnmA _7BJzjkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzQUqbEduiL77U_PmnmA" guid="_7BJzQUqbEduiL77U_PmnmA" graphEdge="_7BJzZ0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzQkqbEduiL77U_PmnmA" guid="_7BJzQkqbEduiL77U_PmnmA" graphEdge="_7BJzQEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzQ0qbEduiL77U_PmnmA" x="612.0" y="243.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzREqbEduiL77U_PmnmA" guid="_7BJzREqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rilYclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzRUqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzRkqbEduiL77U_PmnmA" guid="_7BJzRkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzR0qbEduiL77U_PmnmA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzSEqbEduiL77U_PmnmA" guid="_7BJzSEqbEduiL77U_PmnmA" anchor="_7BJzSUqbEduiL77U_PmnmA _7BJzikqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzSUqbEduiL77U_PmnmA" guid="_7BJzSUqbEduiL77U_PmnmA" graphEdge="_7BJzSEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzSkqbEduiL77U_PmnmA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzS0qbEduiL77U_PmnmA" guid="_7BJzS0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_7BJzTEqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzTUqbEduiL77U_PmnmA" guid="_7BJzTUqbEduiL77U_PmnmA" briefDescription="_5VDG0NIWEdm9Cql_SeWu_A">
+ <position xmi:id="_7BJzTkqbEduiL77U_PmnmA" x="309.0" y="351.0"/>
+ <anchorage xmi:id="_7BJzT0qbEduiL77U_PmnmA" guid="_7BJzT0qbEduiL77U_PmnmA" graphEdge="_7BJzhUqbEduiL77U_PmnmA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzUEqbEduiL77U_PmnmA" guid="_7BJzUEqbEduiL77U_PmnmA" typeInfo="end node"/>
+ <size xmi:id="_7BJzUUqbEduiL77U_PmnmA" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzUkqbEduiL77U_PmnmA" guid="_7BJzUkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzU0qbEduiL77U_PmnmA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzVEqbEduiL77U_PmnmA" guid="_7BJzVEqbEduiL77U_PmnmA" anchor="_7BJzVUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzVUqbEduiL77U_PmnmA" guid="_7BJzVUqbEduiL77U_PmnmA" graphEdge="_7BJzVEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzVkqbEduiL77U_PmnmA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzV0qbEduiL77U_PmnmA" guid="_7BJzV0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_7BJzWEqbEduiL77U_PmnmA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzWUqbEduiL77U_PmnmA" guid="_7BJzWUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzWkqbEduiL77U_PmnmA" x="159.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzW0qbEduiL77U_PmnmA" guid="_7BJzW0qbEduiL77U_PmnmA" anchor="_7BJzXUqbEduiL77U_PmnmA _7BJzjEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzXEqbEduiL77U_PmnmA" guid="_7BJzXEqbEduiL77U_PmnmA" graphEdge="_7BJzZkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzXUqbEduiL77U_PmnmA" guid="_7BJzXUqbEduiL77U_PmnmA" graphEdge="_7BJzW0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzXkqbEduiL77U_PmnmA" x="466.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzX0qbEduiL77U_PmnmA" guid="_7BJzX0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_WrXvwPinEdmugcVr9AdHjQ"/>
+ </semanticModel>
+ <size xmi:id="_7BJzYEqbEduiL77U_PmnmA" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzYUqbEduiL77U_PmnmA" guid="_7BJzYUqbEduiL77U_PmnmA" briefDescription="_pKjjgPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_7BJzYkqbEduiL77U_PmnmA" x="11.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzY0qbEduiL77U_PmnmA" guid="_7BJzY0qbEduiL77U_PmnmA" anchor="_7BJzbEqbEduiL77U_PmnmA _7BJzK0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZEqbEduiL77U_PmnmA" guid="_7BJzZEqbEduiL77U_PmnmA" anchor="_7BJzbkqbEduiL77U_PmnmA _7BJzNEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZUqbEduiL77U_PmnmA" guid="_7BJzZUqbEduiL77U_PmnmA" anchor="_7BJzcEqbEduiL77U_PmnmA _7BJznUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZkqbEduiL77U_PmnmA" guid="_7BJzZkqbEduiL77U_PmnmA" anchor="_7BJzckqbEduiL77U_PmnmA _7BJzXEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZ0qbEduiL77U_PmnmA" guid="_7BJzZ0qbEduiL77U_PmnmA" anchor="_7BJzdEqbEduiL77U_PmnmA _7BJzQUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzaEqbEduiL77U_PmnmA" guid="_7BJzaEqbEduiL77U_PmnmA" anchor="_7BJzdkqbEduiL77U_PmnmA _7BJzI0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzaUqbEduiL77U_PmnmA" guid="_7BJzaUqbEduiL77U_PmnmA" anchor="_7BJzeEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzakqbEduiL77U_PmnmA" guid="_7BJzakqbEduiL77U_PmnmA" graphEdge="_7BJzfkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJza0qbEduiL77U_PmnmA" x="312.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzbEqbEduiL77U_PmnmA" guid="_7BJzbEqbEduiL77U_PmnmA" graphEdge="_7BJzY0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzbUqbEduiL77U_PmnmA" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzbkqbEduiL77U_PmnmA" guid="_7BJzbkqbEduiL77U_PmnmA" graphEdge="_7BJzZEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzb0qbEduiL77U_PmnmA" x="125.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzcEqbEduiL77U_PmnmA" guid="_7BJzcEqbEduiL77U_PmnmA" graphEdge="_7BJzZUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzcUqbEduiL77U_PmnmA" x="474.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzckqbEduiL77U_PmnmA" guid="_7BJzckqbEduiL77U_PmnmA" graphEdge="_7BJzZkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzc0qbEduiL77U_PmnmA" x="197.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzdEqbEduiL77U_PmnmA" guid="_7BJzdEqbEduiL77U_PmnmA" graphEdge="_7BJzZ0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzdUqbEduiL77U_PmnmA" x="276.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzdkqbEduiL77U_PmnmA" guid="_7BJzdkqbEduiL77U_PmnmA" graphEdge="_7BJzaEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzd0qbEduiL77U_PmnmA" x="369.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzeEqbEduiL77U_PmnmA" guid="_7BJzeEqbEduiL77U_PmnmA" graphEdge="_7BJzaUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzeUqbEduiL77U_PmnmA" x="440.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzekqbEduiL77U_PmnmA" guid="_7BJzekqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_7BJze0qbEduiL77U_PmnmA" width="563.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzfEqbEduiL77U_PmnmA" guid="_7BJzfEqbEduiL77U_PmnmA" briefDescription="_zkKboPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_7BJzfUqbEduiL77U_PmnmA" x="313.0" y="6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzfkqbEduiL77U_PmnmA" guid="_7BJzfkqbEduiL77U_PmnmA" anchor="_7BJzf0qbEduiL77U_PmnmA _7BJzakqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzf0qbEduiL77U_PmnmA" guid="_7BJzf0qbEduiL77U_PmnmA" graphEdge="_7BJzfkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzgEqbEduiL77U_PmnmA" x="-30.0" y="13.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzgUqbEduiL77U_PmnmA" guid="_7BJzgUqbEduiL77U_PmnmA" typeInfo="start node"/>
+ <size xmi:id="_7BJzgkqbEduiL77U_PmnmA" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzg0qbEduiL77U_PmnmA" guid="_7BJzg0qbEduiL77U_PmnmA" briefDescription="_045Z8Pr6EdmyhNQr5STrZQ">
+ <position xmi:id="_7BJzhEqbEduiL77U_PmnmA" x="6.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzhUqbEduiL77U_PmnmA" guid="_7BJzhUqbEduiL77U_PmnmA" anchor="_7BJzlEqbEduiL77U_PmnmA _7BJzT0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzhkqbEduiL77U_PmnmA" guid="_7BJzhkqbEduiL77U_PmnmA" graphEdge="_7BJzKkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzh0qbEduiL77U_PmnmA" x="53.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJziEqbEduiL77U_PmnmA" guid="_7BJziEqbEduiL77U_PmnmA" graphEdge="_7BJzM0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJziUqbEduiL77U_PmnmA" x="130.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzikqbEduiL77U_PmnmA" guid="_7BJzikqbEduiL77U_PmnmA" graphEdge="_7BJzSEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzi0qbEduiL77U_PmnmA" x="647.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzjEqbEduiL77U_PmnmA" guid="_7BJzjEqbEduiL77U_PmnmA" graphEdge="_7BJzW0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzjUqbEduiL77U_PmnmA" x="201.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzjkqbEduiL77U_PmnmA" guid="_7BJzjkqbEduiL77U_PmnmA" graphEdge="_7BJzQEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzj0qbEduiL77U_PmnmA" x="280.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzkEqbEduiL77U_PmnmA" guid="_7BJzkEqbEduiL77U_PmnmA" graphEdge="_7BJzIkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzkUqbEduiL77U_PmnmA" x="373.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzkkqbEduiL77U_PmnmA" guid="_7BJzkkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzk0qbEduiL77U_PmnmA" x="445.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzlEqbEduiL77U_PmnmA" guid="_7BJzlEqbEduiL77U_PmnmA" graphEdge="_7BJzhUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzlUqbEduiL77U_PmnmA" x="315.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzlkqbEduiL77U_PmnmA" guid="_7BJzlkqbEduiL77U_PmnmA" graphEdge="_7BJznEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzl0qbEduiL77U_PmnmA" x="480.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzmEqbEduiL77U_PmnmA" guid="_7BJzmEqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_7BJzmUqbEduiL77U_PmnmA" width="578.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzmkqbEduiL77U_PmnmA" guid="_7BJzmkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzm0qbEduiL77U_PmnmA" x="436.0" y="164.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJznEqbEduiL77U_PmnmA" guid="_7BJznEqbEduiL77U_PmnmA" anchor="_7BJzn0qbEduiL77U_PmnmA _7BJzlkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJznUqbEduiL77U_PmnmA" guid="_7BJznUqbEduiL77U_PmnmA" graphEdge="_7BJzZUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJznkqbEduiL77U_PmnmA" x="651.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzn0qbEduiL77U_PmnmA" guid="_7BJzn0qbEduiL77U_PmnmA" graphEdge="_7BJznEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzoEqbEduiL77U_PmnmA" x="548.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzoUqbEduiL77U_PmnmA" guid="_7BJzoUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_TAVx0CliEdqjQsaFX0CJTw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzokqbEduiL77U_PmnmA" width="100.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpapBOKEduCNqgZdt_OaA" guid="_0SpapBOKEduCNqgZdt_OaA" presentation="Workflow" element="_0Spa4BOKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_3CqrABOKEduCNqgZdt_OaA" name="construction_phase_iteration" guid="_3CqrABOKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_3CqrAROKEduCNqgZdt_OaA" name="construction_phase_iteration" guid="_3CqrAROKEduCNqgZdt_OaA" presentationName="Construction Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" isRepeatable="true" linkToPredecessor="_88coMBOSEduCNqgZdt_OaA" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-3IrutQEdqc1LGhiSPqRg"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_48EKsBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_88coMBOSEduCNqgZdt_OaA" guid="_88coMBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_16nd0BOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_3CqrAhOKEduCNqgZdt_OaA" guid="_3CqrAhOKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrVxOKEduCNqgZdt_OaA" guid="_3CqrVxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrhROKEduCNqgZdt_OaA" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrWROKEduCNqgZdt_OaA" guid="_3CqrWROKEduCNqgZdt_OaA" anchor="_3CqrWBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrWBOKEduCNqgZdt_OaA" guid="_3CqrWBOKEduCNqgZdt_OaA" graphEdge="_3CqrWROKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrhhOKEduCNqgZdt_OaA" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrWhOKEduCNqgZdt_OaA" guid="_3CqrWhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrhxOKEduCNqgZdt_OaA" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrXxOKEduCNqgZdt_OaA" guid="_3CqrXxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqriBOKEduCNqgZdt_OaA" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrYROKEduCNqgZdt_OaA" guid="_3CqrYROKEduCNqgZdt_OaA" anchor="_3CqrYxOKEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrYhOKEduCNqgZdt_OaA" guid="_3CqrYhOKEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_3CqrYxOKEduCNqgZdt_OaA" guid="_3CqrYxOKEduCNqgZdt_OaA" graphEdge="_3CqrYROKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqriROKEduCNqgZdt_OaA" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrYBOKEduCNqgZdt_OaA" guid="_3CqrYBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrihOKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrWxOKEduCNqgZdt_OaA" guid="_3CqrWxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrjhOKEduCNqgZdt_OaA" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrXhOKEduCNqgZdt_OaA" guid="_3CqrXhOKEduCNqgZdt_OaA" anchor="_3CqrXBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrXBOKEduCNqgZdt_OaA" guid="_3CqrXBOKEduCNqgZdt_OaA" graphEdge="_3CqrXhOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrjxOKEduCNqgZdt_OaA" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrXROKEduCNqgZdt_OaA" guid="_3CqrXROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrkBOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrAxOKEduCNqgZdt_OaA" guid="_3CqrAxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrsxOKEduCNqgZdt_OaA" x="175.0" y="147.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrBxOKEduCNqgZdt_OaA" guid="_3CqrBxOKEduCNqgZdt_OaA" anchor="_3CqrBBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrBhOKEduCNqgZdt_OaA" guid="_3CqrBhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrBBOKEduCNqgZdt_OaA" guid="_3CqrBBOKEduCNqgZdt_OaA" graphEdge="_3CqrBxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrtBOKEduCNqgZdt_OaA" x="409.0" y="213.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrBROKEduCNqgZdt_OaA" guid="_3CqrBROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrtROKEduCNqgZdt_OaA" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrUhOKEduCNqgZdt_OaA" guid="_3CqrUhOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqruhOKEduCNqgZdt_OaA" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrUxOKEduCNqgZdt_OaA" guid="_3CqrUxOKEduCNqgZdt_OaA" anchor="_3CqrVBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrVROKEduCNqgZdt_OaA" guid="_3CqrVROKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqruxOKEduCNqgZdt_OaA" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_3CqrVBOKEduCNqgZdt_OaA" guid="_3CqrVBOKEduCNqgZdt_OaA" graphEdge="_3CqrUxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrvBOKEduCNqgZdt_OaA" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrVhOKEduCNqgZdt_OaA" guid="_3CqrVhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrvROKEduCNqgZdt_OaA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrPxOKEduCNqgZdt_OaA" guid="_3CqrPxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrvhOKEduCNqgZdt_OaA" x="10.0" y="78.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrQxOKEduCNqgZdt_OaA" guid="_3CqrQxOKEduCNqgZdt_OaA" anchor="_3CqrQROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrQhOKEduCNqgZdt_OaA" guid="_3CqrQhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrQROKEduCNqgZdt_OaA" guid="_3CqrQROKEduCNqgZdt_OaA" graphEdge="_3CqrQxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CwxoBOKEduCNqgZdt_OaA" x="275.0" y="187.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrQBOKEduCNqgZdt_OaA" guid="_3CqrQBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CwxoROKEduCNqgZdt_OaA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrHBOKEduCNqgZdt_OaA" guid="_3CqrHBOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CwxohOKEduCNqgZdt_OaA" x="75.0" y="106.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrHhOKEduCNqgZdt_OaA" guid="_3CqrHhOKEduCNqgZdt_OaA" anchor="_3CqrHxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrHROKEduCNqgZdt_OaA" guid="_3CqrHROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrHxOKEduCNqgZdt_OaA" guid="_3CqrHxOKEduCNqgZdt_OaA" graphEdge="_3CqrHhOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CwxoxOKEduCNqgZdt_OaA" x="385.0" y="244.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrIBOKEduCNqgZdt_OaA" guid="_3CqrIBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CwxpBOKEduCNqgZdt_OaA" width="136.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nZpLcETREduPB9JnYhkxmQ" guid="_nZpLcETREduPB9JnYhkxmQ">
+ <position xmi:id="_nZpLcUTREduPB9JnYhkxmQ" x="294.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nZpLckTREduPB9JnYhkxmQ" guid="_nZpLckTREduPB9JnYhkxmQ"/>
+ <size xmi:id="_nZpLc0TREduPB9JnYhkxmQ" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nZpLdETREduPB9JnYhkxmQ" guid="_nZpLdETREduPB9JnYhkxmQ">
+ <position xmi:id="_nZpLdUTREduPB9JnYhkxmQ" x="10.0" y="389.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nZpLdkTREduPB9JnYhkxmQ" guid="_nZpLdkTREduPB9JnYhkxmQ"/>
+ <size xmi:id="_nZpLd0TREduPB9JnYhkxmQ" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAWEbtEduTiINs4_IZ_Q" guid="_6YSAWEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAWUbtEduTiINs4_IZ_Q" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAWkbtEduTiINs4_IZ_Q" guid="_6YSAWkbtEduTiINs4_IZ_Q" anchor="_6YSAW0btEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAW0btEduTiINs4_IZ_Q" guid="_6YSAW0btEduTiINs4_IZ_Q" graphEdge="_6YSAWkbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAXEbtEduTiINs4_IZ_Q" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAXUbtEduTiINs4_IZ_Q" guid="_6YSAXUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAXkbtEduTiINs4_IZ_Q" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAX0btEduTiINs4_IZ_Q" guid="_6YSAX0btEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAYEbtEduTiINs4_IZ_Q" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAYUbtEduTiINs4_IZ_Q" guid="_6YSAYUbtEduTiINs4_IZ_Q" anchor="_6YSAY0btEduTiINs4_IZ_Q">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAYkbtEduTiINs4_IZ_Q" guid="_6YSAYkbtEduTiINs4_IZ_Q"/>
+ </contained>
+ <anchorage xmi:id="_6YSAY0btEduTiINs4_IZ_Q" guid="_6YSAY0btEduTiINs4_IZ_Q" graphEdge="_6YSAYUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAZEbtEduTiINs4_IZ_Q" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAZUbtEduTiINs4_IZ_Q" guid="_6YSAZUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAZkbtEduTiINs4_IZ_Q" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAcEbtEduTiINs4_IZ_Q" guid="_6YSAcEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAcUbtEduTiINs4_IZ_Q" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAckbtEduTiINs4_IZ_Q" guid="_6YSAckbtEduTiINs4_IZ_Q" anchor="_6YSAc0btEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAc0btEduTiINs4_IZ_Q" guid="_6YSAc0btEduTiINs4_IZ_Q" graphEdge="_6YSAckbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAdEbtEduTiINs4_IZ_Q" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAdUbtEduTiINs4_IZ_Q" guid="_6YSAdUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAdkbtEduTiINs4_IZ_Q" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAd0btEduTiINs4_IZ_Q" guid="_6YSAd0btEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAeEbtEduTiINs4_IZ_Q" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAeUbtEduTiINs4_IZ_Q" guid="_6YSAeUbtEduTiINs4_IZ_Q" anchor="_6YSAe0btEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAekbtEduTiINs4_IZ_Q" guid="_6YSAekbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAe0btEduTiINs4_IZ_Q" guid="_6YSAe0btEduTiINs4_IZ_Q" graphEdge="_6YSAeUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAfEbtEduTiINs4_IZ_Q" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAfUbtEduTiINs4_IZ_Q" guid="_6YSAfUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAfkbtEduTiINs4_IZ_Q" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YYHQUbtEduTiINs4_IZ_Q" guid="_6YYHQUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHQkbtEduTiINs4_IZ_Q" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YYHQ0btEduTiINs4_IZ_Q" guid="_6YYHQ0btEduTiINs4_IZ_Q" anchor="_6YYHRkbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YYHREbtEduTiINs4_IZ_Q" guid="_6YYHREbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHRUbtEduTiINs4_IZ_Q" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6YYHRkbtEduTiINs4_IZ_Q" guid="_6YYHRkbtEduTiINs4_IZ_Q" graphEdge="_6YYHQ0btEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHR0btEduTiINs4_IZ_Q" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YYHSEbtEduTiINs4_IZ_Q" guid="_6YYHSEbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YYHSUbtEduTiINs4_IZ_Q" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YYHSkbtEduTiINs4_IZ_Q" guid="_6YYHSkbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHS0btEduTiINs4_IZ_Q" x="385.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YYHTEbtEduTiINs4_IZ_Q" guid="_6YYHTEbtEduTiINs4_IZ_Q" anchor="_6YYHTkbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YYHTUbtEduTiINs4_IZ_Q" guid="_6YYHTUbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YYHTkbtEduTiINs4_IZ_Q" guid="_6YYHTkbtEduTiINs4_IZ_Q" graphEdge="_6YYHTEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHT0btEduTiINs4_IZ_Q" x="445.0" y="262.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YYHUEbtEduTiINs4_IZ_Q" guid="_6YYHUEbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YYHUUbtEduTiINs4_IZ_Q" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehiEqbEduiL77U_PmnmA" guid="_8jehiEqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehiUqbEduiL77U_PmnmA" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehikqbEduiL77U_PmnmA" guid="_8jehikqbEduiL77U_PmnmA" anchor="_8jehi0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jehi0qbEduiL77U_PmnmA" guid="_8jehi0qbEduiL77U_PmnmA" graphEdge="_8jehikqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehjEqbEduiL77U_PmnmA" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehjUqbEduiL77U_PmnmA" guid="_8jehjUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehjkqbEduiL77U_PmnmA" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehj0qbEduiL77U_PmnmA" guid="_8jehj0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jehkEqbEduiL77U_PmnmA" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehkUqbEduiL77U_PmnmA" guid="_8jehkUqbEduiL77U_PmnmA" anchor="_8jehk0qbEduiL77U_PmnmA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehkkqbEduiL77U_PmnmA" guid="_8jehkkqbEduiL77U_PmnmA"/>
+ </contained>
+ <anchorage xmi:id="_8jehk0qbEduiL77U_PmnmA" guid="_8jehk0qbEduiL77U_PmnmA" graphEdge="_8jehkUqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehlEqbEduiL77U_PmnmA" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehlUqbEduiL77U_PmnmA" guid="_8jehlUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehlkqbEduiL77U_PmnmA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehoEqbEduiL77U_PmnmA" guid="_8jehoEqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehoUqbEduiL77U_PmnmA" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehokqbEduiL77U_PmnmA" guid="_8jehokqbEduiL77U_PmnmA" anchor="_8jeho0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeho0qbEduiL77U_PmnmA" guid="_8jeho0qbEduiL77U_PmnmA" graphEdge="_8jehokqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehpEqbEduiL77U_PmnmA" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehpUqbEduiL77U_PmnmA" guid="_8jehpUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehpkqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehp0qbEduiL77U_PmnmA" guid="_8jehp0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jehqEqbEduiL77U_PmnmA" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehqUqbEduiL77U_PmnmA" guid="_8jehqUqbEduiL77U_PmnmA" anchor="_8jehq0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jehqkqbEduiL77U_PmnmA" guid="_8jehqkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jehq0qbEduiL77U_PmnmA" guid="_8jehq0qbEduiL77U_PmnmA" graphEdge="_8jehqUqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehrEqbEduiL77U_PmnmA" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehrUqbEduiL77U_PmnmA" guid="_8jehrUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehrkqbEduiL77U_PmnmA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jeiDEqbEduiL77U_PmnmA" guid="_8jeiDEqbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiDUqbEduiL77U_PmnmA" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jeiDkqbEduiL77U_PmnmA" guid="_8jeiDkqbEduiL77U_PmnmA" anchor="_8jeiEUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeiD0qbEduiL77U_PmnmA" guid="_8jeiD0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiEEqbEduiL77U_PmnmA" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_8jeiEUqbEduiL77U_PmnmA" guid="_8jeiEUqbEduiL77U_PmnmA" graphEdge="_8jeiDkqbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiEkqbEduiL77U_PmnmA" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jeiE0qbEduiL77U_PmnmA" guid="_8jeiE0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jeiFEqbEduiL77U_PmnmA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jeiHUqbEduiL77U_PmnmA" guid="_8jeiHUqbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiHkqbEduiL77U_PmnmA" x="156.0" y="145.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jeiH0qbEduiL77U_PmnmA" guid="_8jeiH0qbEduiL77U_PmnmA" anchor="_8jeiIUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeiIEqbEduiL77U_PmnmA" guid="_8jeiIEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeiIUqbEduiL77U_PmnmA" guid="_8jeiIUqbEduiL77U_PmnmA" graphEdge="_8jeiH0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiIkqbEduiL77U_PmnmA" x="203.0" y="165.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jeiI0qbEduiL77U_PmnmA" guid="_8jeiI0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jeiJEqbEduiL77U_PmnmA" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQZ8E9IEdudU75l2xOQTw" guid="_nEQZ8E9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ8U9IEdudU75l2xOQTw" x="334.0" y="79.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQZ8k9IEdudU75l2xOQTw" guid="_nEQZ8k9IEdudU75l2xOQTw" anchor="_nEQZ9E9IEdudU75l2xOQTw _nEQaaE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQZ809IEdudU75l2xOQTw" guid="_nEQZ809IEdudU75l2xOQTw" graphEdge="_nEQaM09IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQZ9E9IEdudU75l2xOQTw" guid="_nEQZ9E9IEdudU75l2xOQTw" graphEdge="_nEQZ8k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ9U9IEdudU75l2xOQTw" x="488.0" y="118.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQZ9k9IEdudU75l2xOQTw" guid="_nEQZ9k9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-k0bOtQEdqc1LGhiSPqRg"/>
+ </semanticModel>
+ <size xmi:id="_nEQZ909IEdudU75l2xOQTw" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQZ-E9IEdudU75l2xOQTw" guid="_nEQZ-E9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ-U9IEdudU75l2xOQTw" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQZ-k9IEdudU75l2xOQTw" guid="_nEQZ-k9IEdudU75l2xOQTw" anchor="_nEQZ-09IEdudU75l2xOQTw _nEQaWE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQZ-09IEdudU75l2xOQTw" guid="_nEQZ-09IEdudU75l2xOQTw" graphEdge="_nEQZ-k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ_E9IEdudU75l2xOQTw" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQZ_U9IEdudU75l2xOQTw" guid="_nEQZ_U9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQZ_k9IEdudU75l2xOQTw" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQZ_09IEdudU75l2xOQTw" guid="_nEQZ_09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaAE9IEdudU75l2xOQTw" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaAU9IEdudU75l2xOQTw" guid="_nEQaAU9IEdudU75l2xOQTw" anchor="_nEQaA09IEdudU75l2xOQTw _nEQaCk9IEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaAk9IEdudU75l2xOQTw" guid="_nEQaAk9IEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_nEQaA09IEdudU75l2xOQTw" guid="_nEQaA09IEdudU75l2xOQTw" graphEdge="_nEQaAU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaBE9IEdudU75l2xOQTw" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaBU9IEdudU75l2xOQTw" guid="_nEQaBU9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaBk9IEdudU75l2xOQTw" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaB09IEdudU75l2xOQTw" guid="_nEQaB09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaCE9IEdudU75l2xOQTw" x="245.0" y="215.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaCU9IEdudU75l2xOQTw" guid="_nEQaCU9IEdudU75l2xOQTw" anchor="_nEQaDE9IEdudU75l2xOQTw _nEQaZk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaCk9IEdudU75l2xOQTw" guid="_nEQaCk9IEdudU75l2xOQTw" graphEdge="_nEQaAU9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaC09IEdudU75l2xOQTw" guid="_nEQaC09IEdudU75l2xOQTw" graphEdge="_nEQaMk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaDE9IEdudU75l2xOQTw" guid="_nEQaDE9IEdudU75l2xOQTw" graphEdge="_nEQaCU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaDU9IEdudU75l2xOQTw" x="568.0" y="250.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaDk9IEdudU75l2xOQTw" guid="_nEQaDk9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-3IretQEdqc1LGhiSPqRg"/>
+ </semanticModel>
+ <size xmi:id="_nEQaD09IEdudU75l2xOQTw" width="96.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaEE9IEdudU75l2xOQTw" guid="_nEQaEE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaEU9IEdudU75l2xOQTw" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaEk9IEdudU75l2xOQTw" guid="_nEQaEk9IEdudU75l2xOQTw" anchor="_nEQaE09IEdudU75l2xOQTw _nEQaWk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaE09IEdudU75l2xOQTw" guid="_nEQaE09IEdudU75l2xOQTw" graphEdge="_nEQaEk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaFE9IEdudU75l2xOQTw" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaFU9IEdudU75l2xOQTw" guid="_nEQaFU9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaFk9IEdudU75l2xOQTw" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaF09IEdudU75l2xOQTw" guid="_nEQaF09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaGE9IEdudU75l2xOQTw" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaGU9IEdudU75l2xOQTw" guid="_nEQaGU9IEdudU75l2xOQTw" anchor="_nEQaG09IEdudU75l2xOQTw _nEQaak9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaGk9IEdudU75l2xOQTw" guid="_nEQaGk9IEdudU75l2xOQTw" graphEdge="_nEQaNE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaG09IEdudU75l2xOQTw" guid="_nEQaG09IEdudU75l2xOQTw" graphEdge="_nEQaGU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaHE9IEdudU75l2xOQTw" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaHU9IEdudU75l2xOQTw" guid="_nEQaHU9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaHk9IEdudU75l2xOQTw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaH09IEdudU75l2xOQTw" guid="_nEQaH09IEdudU75l2xOQTw" briefDescription="_y-k0N-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaIE9IEdudU75l2xOQTw" x="306.0" y="10.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaIU9IEdudU75l2xOQTw" guid="_nEQaIU9IEdudU75l2xOQTw" anchor="_nEQaIk9IEdudU75l2xOQTw _nEQaOU9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaIk9IEdudU75l2xOQTw" guid="_nEQaIk9IEdudU75l2xOQTw" graphEdge="_nEQaIU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaI09IEdudU75l2xOQTw" x="10.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQaJE9IEdudU75l2xOQTw" guid="_nEQaJE9IEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_nEQaJU9IEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaJk9IEdudU75l2xOQTw" guid="_nEQaJk9IEdudU75l2xOQTw" briefDescription="_y-k0O-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaJ09IEdudU75l2xOQTw" x="298.0" y="354.0"/>
+ <anchorage xmi:id="_nEQaKE9IEdudU75l2xOQTw" guid="_nEQaKE9IEdudU75l2xOQTw" graphEdge="_nEQaV09IEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQaKU9IEdudU75l2xOQTw" guid="_nEQaKU9IEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_nEQaKk9IEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaK09IEdudU75l2xOQTw" guid="_nEQaK09IEdudU75l2xOQTw" briefDescription="_y-k0GutQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaLE9IEdudU75l2xOQTw" x="42.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaLU9IEdudU75l2xOQTw" guid="_nEQaLU9IEdudU75l2xOQTw" anchor="_nEQaO09IEdudU75l2xOQTw _nEQae09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaLk9IEdudU75l2xOQTw" guid="_nEQaLk9IEdudU75l2xOQTw" anchor="_nEQaPU9IEdudU75l2xOQTw _nEQahE9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaL09IEdudU75l2xOQTw" guid="_nEQaL09IEdudU75l2xOQTw" anchor="_nEQaP09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaME9IEdudU75l2xOQTw" guid="_nEQaME9IEdudU75l2xOQTw" anchor="_nEQaQU9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaMU9IEdudU75l2xOQTw" guid="_nEQaMU9IEdudU75l2xOQTw" anchor="_nEQaQ09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaMk9IEdudU75l2xOQTw" guid="_nEQaMk9IEdudU75l2xOQTw" anchor="_nEQaRU9IEdudU75l2xOQTw _nEQaC09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaM09IEdudU75l2xOQTw" guid="_nEQaM09IEdudU75l2xOQTw" anchor="_nEQaR09IEdudU75l2xOQTw _nEQZ809IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaNE9IEdudU75l2xOQTw" guid="_nEQaNE9IEdudU75l2xOQTw" anchor="_nEQaSU9IEdudU75l2xOQTw _nEQaGk9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaNU9IEdudU75l2xOQTw" guid="_nEQaNU9IEdudU75l2xOQTw" anchor="_nEQaS09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaNk9IEdudU75l2xOQTw" guid="_nEQaNk9IEdudU75l2xOQTw" anchor="_nEQaTU9IEdudU75l2xOQTw _nEQajU9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaN09IEdudU75l2xOQTw" guid="_nEQaN09IEdudU75l2xOQTw" anchor="_nEQaT09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaOE9IEdudU75l2xOQTw" guid="_nEQaOE9IEdudU75l2xOQTw" anchor="_nEQaUU9IEdudU75l2xOQTw _nEQalU9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaOU9IEdudU75l2xOQTw" guid="_nEQaOU9IEdudU75l2xOQTw" graphEdge="_nEQaIU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaOk9IEdudU75l2xOQTw" x="273.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaO09IEdudU75l2xOQTw" guid="_nEQaO09IEdudU75l2xOQTw" graphEdge="_nEQaLU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaPE9IEdudU75l2xOQTw" x="477.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaPU9IEdudU75l2xOQTw" guid="_nEQaPU9IEdudU75l2xOQTw" graphEdge="_nEQaLk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaPk9IEdudU75l2xOQTw" x="162.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaP09IEdudU75l2xOQTw" guid="_nEQaP09IEdudU75l2xOQTw" graphEdge="_nEQaL09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaQE9IEdudU75l2xOQTw" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaQU9IEdudU75l2xOQTw" guid="_nEQaQU9IEdudU75l2xOQTw" graphEdge="_nEQaME9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaQk9IEdudU75l2xOQTw" x="101.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaQ09IEdudU75l2xOQTw" guid="_nEQaQ09IEdudU75l2xOQTw" graphEdge="_nEQaMU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaRE9IEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaRU9IEdudU75l2xOQTw" guid="_nEQaRU9IEdudU75l2xOQTw" graphEdge="_nEQaMk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaRk9IEdudU75l2xOQTw" x="251.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaR09IEdudU75l2xOQTw" guid="_nEQaR09IEdudU75l2xOQTw" graphEdge="_nEQaM09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaSE9IEdudU75l2xOQTw" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaSU9IEdudU75l2xOQTw" guid="_nEQaSU9IEdudU75l2xOQTw" graphEdge="_nEQaNE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaSk9IEdudU75l2xOQTw" x="393.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaS09IEdudU75l2xOQTw" guid="_nEQaS09IEdudU75l2xOQTw" graphEdge="_nEQaNU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaTE9IEdudU75l2xOQTw" x="407.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaTU9IEdudU75l2xOQTw" guid="_nEQaTU9IEdudU75l2xOQTw" graphEdge="_nEQaNk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaTk9IEdudU75l2xOQTw" x="59.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaT09IEdudU75l2xOQTw" guid="_nEQaT09IEdudU75l2xOQTw" graphEdge="_nEQaN09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaUE9IEdudU75l2xOQTw" x="159.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaUU9IEdudU75l2xOQTw" guid="_nEQaUU9IEdudU75l2xOQTw" graphEdge="_nEQaOE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaUk9IEdudU75l2xOQTw" x="151.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQaU09IEdudU75l2xOQTw" guid="_nEQaU09IEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nEQaVE9IEdudU75l2xOQTw" width="523.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaVU9IEdudU75l2xOQTw" guid="_nEQaVU9IEdudU75l2xOQTw" briefDescription="_y-k0XOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaVk9IEdudU75l2xOQTw" x="47.0" y="313.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaV09IEdudU75l2xOQTw" guid="_nEQaV09IEdudU75l2xOQTw" anchor="_nEQabE9IEdudU75l2xOQTw _nEQaKE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaWE9IEdudU75l2xOQTw" guid="_nEQaWE9IEdudU75l2xOQTw" graphEdge="_nEQZ-k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaWU9IEdudU75l2xOQTw" x="148.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaWk9IEdudU75l2xOQTw" guid="_nEQaWk9IEdudU75l2xOQTw" graphEdge="_nEQaEk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaW09IEdudU75l2xOQTw" x="542.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaXE9IEdudU75l2xOQTw" guid="_nEQaXE9IEdudU75l2xOQTw" graphEdge="_nEQaek9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaXU9IEdudU75l2xOQTw" x="472.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaXk9IEdudU75l2xOQTw" guid="_nEQaXk9IEdudU75l2xOQTw" graphEdge="_nEQag09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaX09IEdudU75l2xOQTw" x="151.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaYE9IEdudU75l2xOQTw" guid="_nEQaYE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaYU9IEdudU75l2xOQTw" x="16.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaYk9IEdudU75l2xOQTw" guid="_nEQaYk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaY09IEdudU75l2xOQTw" x="95.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaZE9IEdudU75l2xOQTw" guid="_nEQaZE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaZU9IEdudU75l2xOQTw" x="170.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaZk9IEdudU75l2xOQTw" guid="_nEQaZk9IEdudU75l2xOQTw" graphEdge="_nEQaCU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaZ09IEdudU75l2xOQTw" x="246.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaaE9IEdudU75l2xOQTw" guid="_nEQaaE9IEdudU75l2xOQTw" graphEdge="_nEQZ8k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaaU9IEdudU75l2xOQTw" x="328.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaak9IEdudU75l2xOQTw" guid="_nEQaak9IEdudU75l2xOQTw" graphEdge="_nEQaGU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaa09IEdudU75l2xOQTw" x="387.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQabE9IEdudU75l2xOQTw" guid="_nEQabE9IEdudU75l2xOQTw" graphEdge="_nEQaV09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQabU9IEdudU75l2xOQTw" x="262.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQabk9IEdudU75l2xOQTw" guid="_nEQabk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQab09IEdudU75l2xOQTw" x="403.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQacE9IEdudU75l2xOQTw" guid="_nEQacE9IEdudU75l2xOQTw" graphEdge="_nEQajE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQacU9IEdudU75l2xOQTw" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQack9IEdudU75l2xOQTw" guid="_nEQack9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQac09IEdudU75l2xOQTw" x="154.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQadE9IEdudU75l2xOQTw" guid="_nEQadE9IEdudU75l2xOQTw" graphEdge="_nEQalE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQadU9IEdudU75l2xOQTw" x="146.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQadk9IEdudU75l2xOQTw" guid="_nEQadk9IEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nEQad09IEdudU75l2xOQTw" width="509.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaeE9IEdudU75l2xOQTw" guid="_nEQaeE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaeU9IEdudU75l2xOQTw" x="477.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaek9IEdudU75l2xOQTw" guid="_nEQaek9IEdudU75l2xOQTw" anchor="_nEQafU9IEdudU75l2xOQTw _nEQaXE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQae09IEdudU75l2xOQTw" guid="_nEQae09IEdudU75l2xOQTw" graphEdge="_nEQaLU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQafE9IEdudU75l2xOQTw" x="38.0" y="-91.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQafU9IEdudU75l2xOQTw" guid="_nEQafU9IEdudU75l2xOQTw" graphEdge="_nEQaek9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQafk9IEdudU75l2xOQTw" x="-28.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaf09IEdudU75l2xOQTw" guid="_nEQaf09IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y_PjTOtQEdqc1LGhiSPqRg"/>
+ </semanticModel>
+ <size xmi:id="_nEQagE9IEdudU75l2xOQTw" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQagU9IEdudU75l2xOQTw" guid="_nEQagU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQagk9IEdudU75l2xOQTw" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQag09IEdudU75l2xOQTw" guid="_nEQag09IEdudU75l2xOQTw" anchor="_nEQahk9IEdudU75l2xOQTw _nEQaXk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQahE9IEdudU75l2xOQTw" guid="_nEQahE9IEdudU75l2xOQTw" graphEdge="_nEQaLk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQahU9IEdudU75l2xOQTw" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQahk9IEdudU75l2xOQTw" guid="_nEQahk9IEdudU75l2xOQTw" graphEdge="_nEQag09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQah09IEdudU75l2xOQTw" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaiE9IEdudU75l2xOQTw" guid="_nEQaiE9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaiU9IEdudU75l2xOQTw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaik9IEdudU75l2xOQTw" guid="_nEQaik9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQai09IEdudU75l2xOQTw" x="48.0" y="77.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQajE9IEdudU75l2xOQTw" guid="_nEQajE9IEdudU75l2xOQTw" anchor="_nEQajk9IEdudU75l2xOQTw _nEQacE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQajU9IEdudU75l2xOQTw" guid="_nEQajU9IEdudU75l2xOQTw" graphEdge="_nEQaNk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQajk9IEdudU75l2xOQTw" guid="_nEQajk9IEdudU75l2xOQTw" graphEdge="_nEQajE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaj09IEdudU75l2xOQTw" x="101.0" y="93.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQakE9IEdudU75l2xOQTw" guid="_nEQakE9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_eE5nEUbpEduLBN1xMBngqw"/>
+ </semanticModel>
+ <size xmi:id="_nEQakU9IEdudU75l2xOQTw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQakk9IEdudU75l2xOQTw" guid="_nEQakk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQak09IEdudU75l2xOQTw" x="144.0" y="158.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQalE9IEdudU75l2xOQTw" guid="_nEQalE9IEdudU75l2xOQTw" anchor="_nEQalk9IEdudU75l2xOQTw _nEQadE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQalU9IEdudU75l2xOQTw" guid="_nEQalU9IEdudU75l2xOQTw" graphEdge="_nEQaOE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQalk9IEdudU75l2xOQTw" guid="_nEQalk9IEdudU75l2xOQTw" graphEdge="_nEQalE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQal09IEdudU75l2xOQTw" x="193.0" y="179.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQamE9IEdudU75l2xOQTw" guid="_nEQamE9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_MWFjoU9HEdudU75l2xOQTw"/>
+ </semanticModel>
+ <size xmi:id="_nEQamU9IEdudU75l2xOQTw" width="98.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrdxOKEduCNqgZdt_OaA" guid="_3CqrdxOKEduCNqgZdt_OaA" presentation="Workflow" element="_3CqrAROKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_467NIROKEduCNqgZdt_OaA" name="transition_phase_iteration" guid="_467NIROKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_467NIhOKEduCNqgZdt_OaA" name="transition_phase_iteration" guid="_467NIhOKEduCNqgZdt_OaA" presentationName="Transition Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" isRepeatable="true" linkToPredecessor="_9abksBOSEduCNqgZdt_OaA" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0rQRgMlgEdmt3adZL5Dmdw"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#__ca5UBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9abksBOSEduCNqgZdt_OaA" guid="_9abksBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_31E_YBOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_467NIxOKEduCNqgZdt_OaA" guid="_467NIxOKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="__rUnY0btEduTiINs4_IZ_Q" guid="__rUnY0btEduTiINs4_IZ_Q">
+ <position xmi:id="__rUnZEbtEduTiINs4_IZ_Q" x="18.0" y="301.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__rUnZUbtEduTiINs4_IZ_Q" guid="__rUnZUbtEduTiINs4_IZ_Q" anchor="__rUnaEbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="__rUnZkbtEduTiINs4_IZ_Q" guid="__rUnZkbtEduTiINs4_IZ_Q">
+ <position xmi:id="__rUnZ0btEduTiINs4_IZ_Q" x="66.0" y="-25.0"/>
+ </anchorage>
+ <anchorage xmi:id="__rUnaEbtEduTiINs4_IZ_Q" guid="__rUnaEbtEduTiINs4_IZ_Q" graphEdge="__rUnZUbtEduTiINs4_IZ_Q">
+ <position xmi:id="__rUnaUbtEduTiINs4_IZ_Q" x="69.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="__rUnakbtEduTiINs4_IZ_Q" guid="__rUnakbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="__rUna0btEduTiINs4_IZ_Q" width="144.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafYEqbEduiL77U_PmnmA" guid="_9zafYEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafYUqbEduiL77U_PmnmA" x="205.0" y="96.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafYkqbEduiL77U_PmnmA" guid="_9zafYkqbEduiL77U_PmnmA" anchor="_9zafZUqbEduiL77U_PmnmA _9zafpkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafY0qbEduiL77U_PmnmA" guid="_9zafY0qbEduiL77U_PmnmA" graphEdge="_9zafkkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafZEqbEduiL77U_PmnmA" x="38.0" y="-15.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafZUqbEduiL77U_PmnmA" guid="_9zafZUqbEduiL77U_PmnmA" graphEdge="_9zafYkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafZkqbEduiL77U_PmnmA" x="38.0" y="31.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafZ0qbEduiL77U_PmnmA" guid="_9zafZ0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0q33AclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_9zafaEqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafaUqbEduiL77U_PmnmA" guid="_9zafaUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafakqbEduiL77U_PmnmA" x="226.0" y="170.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafa0qbEduiL77U_PmnmA" guid="_9zafa0qbEduiL77U_PmnmA" anchor="_9zafbUqbEduiL77U_PmnmA _9zafdEqbEduiL77U_PmnmA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafbEqbEduiL77U_PmnmA" guid="_9zafbEqbEduiL77U_PmnmA"/>
+ </contained>
+ <anchorage xmi:id="_9zafbUqbEduiL77U_PmnmA" guid="_9zafbUqbEduiL77U_PmnmA" graphEdge="_9zafa0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafbkqbEduiL77U_PmnmA" x="119.0" y="22.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafb0qbEduiL77U_PmnmA" guid="_9zafb0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_9zafcEqbEduiL77U_PmnmA" width="246.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafcUqbEduiL77U_PmnmA" guid="_9zafcUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafckqbEduiL77U_PmnmA" x="113.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafc0qbEduiL77U_PmnmA" guid="_9zafc0qbEduiL77U_PmnmA" anchor="_9zafdkqbEduiL77U_PmnmA _9zafrkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafdEqbEduiL77U_PmnmA" guid="_9zafdEqbEduiL77U_PmnmA" graphEdge="_9zafa0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafdUqbEduiL77U_PmnmA" guid="_9zafdUqbEduiL77U_PmnmA" graphEdge="_9zaflUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafdkqbEduiL77U_PmnmA" guid="_9zafdkqbEduiL77U_PmnmA" graphEdge="_9zafc0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafd0qbEduiL77U_PmnmA" x="484.0" y="257.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafeEqbEduiL77U_PmnmA" guid="_9zafeEqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwslgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_9zafeUqbEduiL77U_PmnmA" width="80.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafekqbEduiL77U_PmnmA" guid="_9zafekqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafe0qbEduiL77U_PmnmA" x="360.0" y="135.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaffEqbEduiL77U_PmnmA" guid="_9zaffEqbEduiL77U_PmnmA" anchor="_9zaff0qbEduiL77U_PmnmA _9zafqkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zaffUqbEduiL77U_PmnmA" guid="_9zaffUqbEduiL77U_PmnmA" graphEdge="_9zafk0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zaffkqbEduiL77U_PmnmA" x="36.0" y="-101.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zaff0qbEduiL77U_PmnmA" guid="_9zaff0qbEduiL77U_PmnmA" graphEdge="_9zaffEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafgEqbEduiL77U_PmnmA" x="37.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafgUqbEduiL77U_PmnmA" guid="_9zafgUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qxwYclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_9zafgkqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafg0qbEduiL77U_PmnmA" guid="_9zafg0qbEduiL77U_PmnmA" briefDescription="__-SZwNIYEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafhEqbEduiL77U_PmnmA" x="77.0" y="8.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafhUqbEduiL77U_PmnmA" guid="_9zafhUqbEduiL77U_PmnmA" anchor="_9zafhkqbEduiL77U_PmnmA _9zaflkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafhkqbEduiL77U_PmnmA" guid="_9zafhkqbEduiL77U_PmnmA" graphEdge="_9zafhUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafh0qbEduiL77U_PmnmA" x="7.0" y="10.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafiEqbEduiL77U_PmnmA" guid="_9zafiEqbEduiL77U_PmnmA" typeInfo="start node"/>
+ <size xmi:id="_9zafiUqbEduiL77U_PmnmA" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafikqbEduiL77U_PmnmA" guid="_9zafikqbEduiL77U_PmnmA" briefDescription="_ATOvANIZEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafi0qbEduiL77U_PmnmA" x="72.0" y="301.0"/>
+ <anchorage xmi:id="_9zafjEqbEduiL77U_PmnmA" guid="_9zafjEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafjUqbEduiL77U_PmnmA" guid="_9zafjUqbEduiL77U_PmnmA" graphEdge="_9zafpUqbEduiL77U_PmnmA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafjkqbEduiL77U_PmnmA" guid="_9zafjkqbEduiL77U_PmnmA" typeInfo="end node"/>
+ <size xmi:id="_9zafj0qbEduiL77U_PmnmA" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafkEqbEduiL77U_PmnmA" guid="_9zafkEqbEduiL77U_PmnmA" briefDescription="_AyNxENIZEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafkUqbEduiL77U_PmnmA" x="20.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafkkqbEduiL77U_PmnmA" guid="_9zafkkqbEduiL77U_PmnmA" anchor="_9zafmEqbEduiL77U_PmnmA _9zafY0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafk0qbEduiL77U_PmnmA" guid="_9zafk0qbEduiL77U_PmnmA" anchor="_9zafmkqbEduiL77U_PmnmA _9zaffUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaflEqbEduiL77U_PmnmA" guid="_9zaflEqbEduiL77U_PmnmA" anchor="_9zafnEqbEduiL77U_PmnmA _9zaft0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaflUqbEduiL77U_PmnmA" guid="_9zaflUqbEduiL77U_PmnmA" anchor="_9zafnkqbEduiL77U_PmnmA _9zafdUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zaflkqbEduiL77U_PmnmA" guid="_9zaflkqbEduiL77U_PmnmA" graphEdge="_9zafhUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafl0qbEduiL77U_PmnmA" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafmEqbEduiL77U_PmnmA" guid="_9zafmEqbEduiL77U_PmnmA" graphEdge="_9zafkkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafmUqbEduiL77U_PmnmA" x="227.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafmkqbEduiL77U_PmnmA" guid="_9zafmkqbEduiL77U_PmnmA" graphEdge="_9zafk0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafm0qbEduiL77U_PmnmA" x="382.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafnEqbEduiL77U_PmnmA" guid="_9zafnEqbEduiL77U_PmnmA" graphEdge="_9zaflEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafnUqbEduiL77U_PmnmA" x="49.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafnkqbEduiL77U_PmnmA" guid="_9zafnkqbEduiL77U_PmnmA" graphEdge="_9zaflUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafn0qbEduiL77U_PmnmA" x="133.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafoEqbEduiL77U_PmnmA" guid="_9zafoEqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_9zafoUqbEduiL77U_PmnmA" width="431.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafokqbEduiL77U_PmnmA" guid="_9zafokqbEduiL77U_PmnmA" briefDescription="_BocOcNIZEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafo0qbEduiL77U_PmnmA" x="19.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafpEqbEduiL77U_PmnmA" guid="_9zafpEqbEduiL77U_PmnmA" anchor="_9zafqEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafpUqbEduiL77U_PmnmA" guid="_9zafpUqbEduiL77U_PmnmA" anchor="_9zafsEqbEduiL77U_PmnmA _9zafjUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafpkqbEduiL77U_PmnmA" guid="_9zafpkqbEduiL77U_PmnmA" graphEdge="_9zafYkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafp0qbEduiL77U_PmnmA" x="227.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafqEqbEduiL77U_PmnmA" guid="_9zafqEqbEduiL77U_PmnmA" graphEdge="_9zafpEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafqUqbEduiL77U_PmnmA" x="72.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafqkqbEduiL77U_PmnmA" guid="_9zafqkqbEduiL77U_PmnmA" graphEdge="_9zaffEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafq0qbEduiL77U_PmnmA" x="383.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafrEqbEduiL77U_PmnmA" guid="_9zafrEqbEduiL77U_PmnmA" graphEdge="_9zaftkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafrUqbEduiL77U_PmnmA" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafrkqbEduiL77U_PmnmA" guid="_9zafrkqbEduiL77U_PmnmA" graphEdge="_9zafc0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafr0qbEduiL77U_PmnmA" x="133.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafsEqbEduiL77U_PmnmA" guid="_9zafsEqbEduiL77U_PmnmA" graphEdge="_9zafpUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafsUqbEduiL77U_PmnmA" x="65.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafskqbEduiL77U_PmnmA" guid="_9zafskqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_9zafs0qbEduiL77U_PmnmA" width="442.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zaftEqbEduiL77U_PmnmA" guid="_9zaftEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zaftUqbEduiL77U_PmnmA" x="24.0" y="97.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaftkqbEduiL77U_PmnmA" guid="_9zaftkqbEduiL77U_PmnmA" anchor="_9zafuEqbEduiL77U_PmnmA _9zafrEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zaft0qbEduiL77U_PmnmA" guid="_9zaft0qbEduiL77U_PmnmA" graphEdge="_9zaflEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafuEqbEduiL77U_PmnmA" guid="_9zafuEqbEduiL77U_PmnmA" graphEdge="_9zaftkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafuUqbEduiL77U_PmnmA" x="320.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafukqbEduiL77U_PmnmA" guid="_9zafukqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0DMlYPinEdmugcVr9AdHjQ"/>
+ </semanticModel>
+ <size xmi:id="_9zafu0qbEduiL77U_PmnmA" width="90.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_467NSROKEduCNqgZdt_OaA" guid="_467NSROKEduCNqgZdt_OaA" presentation="Workflow" element="_467NIhOKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_y1uwgBOKEduCNqgZdt_OaA" name="lifecycle_objectives" guid="_y1uwgBOKEduCNqgZdt_OaA" briefDescription="The end of the Inception phase is the first major project milestone, the Lifecycle Objectives Milestone." presentationName="Lifecycle Objectives Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_8Kfm0BOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-qk_QXyoSxOb2C-boCISB5g" href="uma://_mtb-4PL5Edm6Nvont3uinw#-qk_QXyoSxOb2C-boCISB5g"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_16nd0BOKEduCNqgZdt_OaA" name="lifecycle_architecture" guid="_16nd0BOKEduCNqgZdt_OaA" briefDescription="At the end of the Elaboration phase is the second important project milestone, the Lifecycle Architecture Milestone." presentationName="Lifecycle Architecture Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_8s37IBOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-3Ul1iAI1nkD0C5AsRtjHFA" href="uma://_mtb-4PL5Edm6Nvont3uinw#-3Ul1iAI1nkD0C5AsRtjHFA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_31E_YBOKEduCNqgZdt_OaA" name="initial_operational_capability" guid="_31E_YBOKEduCNqgZdt_OaA" briefDescription="The end of Construction phase is the third important project milestone, the Initial Operational Capability Milestone." presentationName="Initial Operational Capability Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_9L0g8BOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-Q37Qy6ke_PQDK4jr1EIdcA" href="uma://_mtb-4PL5Edm6Nvont3uinw#-Q37Qy6ke_PQDK4jr1EIdcA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_5v0NwBOKEduCNqgZdt_OaA" name="product_release" guid="_5v0NwBOKEduCNqgZdt_OaA" briefDescription="The end of the Transition phase is the fourth important project milestone, the Product Release Milestone, which is the result of the customer reviewing and accepting the project deliverables." presentationName="Product Release Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_9toNgBOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-Gt2aCyZVy4q1BvcJRM2E-A" href="uma://_mtb-4PL5Edm6Nvont3uinw#-Gt2aCyZVy4q1BvcJRM2E-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_8Kfm0BOSEduCNqgZdt_OaA" guid="_8Kfm0BOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_xupMvxOKEduCNqgZdt_OaA"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_8s37IBOSEduCNqgZdt_OaA" guid="_8s37IBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_0Spa4BOKEduCNqgZdt_OaA"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9L0g8BOSEduCNqgZdt_OaA" guid="_9L0g8BOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_3CqrAROKEduCNqgZdt_OaA"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9toNgBOSEduCNqgZdt_OaA" guid="_9toNgBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_467NIhOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_PrVJgFYzEdqI9sTOt2pjHw" guid="_PrVJgFYzEdqI9sTOt2pjHw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJgVYzEdqI9sTOt2pjHw" guid="_PrVJgVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJglYzEdqI9sTOt2pjHw" x="10.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJg1YzEdqI9sTOt2pjHw" guid="_PrVJg1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJhFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJhVYzEdqI9sTOt2pjHw" guid="_PrVJhVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJhlYzEdqI9sTOt2pjHw" x="183.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJh1YzEdqI9sTOt2pjHw" guid="_PrVJh1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJiFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJiVYzEdqI9sTOt2pjHw" guid="_PrVJiVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJilYzEdqI9sTOt2pjHw" x="366.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJi1YzEdqI9sTOt2pjHw" guid="_PrVJi1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJjFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJjVYzEdqI9sTOt2pjHw" guid="_PrVJjVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJjlYzEdqI9sTOt2pjHw" x="557.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJj1YzEdqI9sTOt2pjHw" guid="_PrVJj1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJkFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0MMA_EdqSgKaj2SZBmg" guid="_HZM0MMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0McA_EdqSgKaj2SZBmg" x="-63.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KUNMwcA_EdqSgKaj2SZBmg" guid="_KUNMwcA_EdqSgKaj2SZBmg" anchor="_KUNMwMA_EdqSgKaj2SZBmg _KUNMwsA_EdqSgKaj2SZBmg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_KVQVoMA_EdqSgKaj2SZBmg" guid="_KVQVoMA_EdqSgKaj2SZBmg"/>
+ </contained>
+ <anchorage xmi:id="_KGW-AsA_EdqSgKaj2SZBmg" guid="_KGW-AsA_EdqSgKaj2SZBmg" graphEdge="_KGW-AcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_KUNMwMA_EdqSgKaj2SZBmg" guid="_KUNMwMA_EdqSgKaj2SZBmg" graphEdge="_KUNMwcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_KUNMw8A_EdqSgKaj2SZBmg" x="184.0" y="77.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0MsA_EdqSgKaj2SZBmg" guid="_HZM0MsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0M8A_EdqSgKaj2SZBmg" width="43.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0NMA_EdqSgKaj2SZBmg" guid="_HZM0NMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0NcA_EdqSgKaj2SZBmg" x="20.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KiJiIcA_EdqSgKaj2SZBmg" guid="_KiJiIcA_EdqSgKaj2SZBmg" anchor="_KiJiIMA_EdqSgKaj2SZBmg _KiJiIsA_EdqSgKaj2SZBmg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_KjGkYMA_EdqSgKaj2SZBmg" guid="_KjGkYMA_EdqSgKaj2SZBmg"/>
+ </contained>
+ <anchorage xmi:id="_KUNMwsA_EdqSgKaj2SZBmg" guid="_KUNMwsA_EdqSgKaj2SZBmg" graphEdge="_KUNMwcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_KiJiIMA_EdqSgKaj2SZBmg" guid="_KiJiIMA_EdqSgKaj2SZBmg" graphEdge="_KiJiIcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_KiJiI8A_EdqSgKaj2SZBmg" x="274.0" y="77.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0NsA_EdqSgKaj2SZBmg" guid="_HZM0NsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0N8A_EdqSgKaj2SZBmg" width="53.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0OMA_EdqSgKaj2SZBmg" guid="_HZM0OMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0OcA_EdqSgKaj2SZBmg" x="113.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Kw2sgcA_EdqSgKaj2SZBmg" guid="_Kw2sgcA_EdqSgKaj2SZBmg" anchor="_Kw2sgMA_EdqSgKaj2SZBmg _Kw2sgsA_EdqSgKaj2SZBmg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_Kx51YMA_EdqSgKaj2SZBmg" guid="_Kx51YMA_EdqSgKaj2SZBmg"/>
+ </contained>
+ <anchorage xmi:id="_KiJiIsA_EdqSgKaj2SZBmg" guid="_KiJiIsA_EdqSgKaj2SZBmg" graphEdge="_KiJiIcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_Kw2sgMA_EdqSgKaj2SZBmg" guid="_Kw2sgMA_EdqSgKaj2SZBmg" graphEdge="_Kw2sgcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_Kw2sg8A_EdqSgKaj2SZBmg" x="378.0" y="82.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0OsA_EdqSgKaj2SZBmg" guid="_HZM0OsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0O8A_EdqSgKaj2SZBmg" width="61.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0PMA_EdqSgKaj2SZBmg" guid="_HZM0PMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0PcA_EdqSgKaj2SZBmg" x="214.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_K-5IgcA_EdqSgKaj2SZBmg" guid="_K-5IgcA_EdqSgKaj2SZBmg" anchor="_K-5IgMA_EdqSgKaj2SZBmg _K-5IgsA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_Kw2sgsA_EdqSgKaj2SZBmg" guid="_Kw2sgsA_EdqSgKaj2SZBmg" graphEdge="_Kw2sgcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_K-5IgMA_EdqSgKaj2SZBmg" guid="_K-5IgMA_EdqSgKaj2SZBmg" graphEdge="_K-5IgcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_K-5Ig8A_EdqSgKaj2SZBmg" x="463.0" y="83.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0PsA_EdqSgKaj2SZBmg" guid="_HZM0PsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0P8A_EdqSgKaj2SZBmg" width="47.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JS-ZQMA_EdqSgKaj2SZBmg" guid="_JS-ZQMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_JS-ZQcA_EdqSgKaj2SZBmg" x="568.0" y="177.0"/>
+ <anchorage xmi:id="_K-5IgsA_EdqSgKaj2SZBmg" guid="_K-5IgsA_EdqSgKaj2SZBmg" graphEdge="_K-5IgcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_Amoa8hOTEduCNqgZdt_OaA" guid="_Amoa8hOTEduCNqgZdt_OaA" graphEdge="_Amoa8ROTEduCNqgZdt_OaA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JS-ZQsA_EdqSgKaj2SZBmg" guid="_JS-ZQsA_EdqSgKaj2SZBmg" typeInfo="end node"/>
+ <size xmi:id="_JS-ZQ8A_EdqSgKaj2SZBmg" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JrCT8MA_EdqSgKaj2SZBmg" guid="_JrCT8MA_EdqSgKaj2SZBmg">
+ <position xmi:id="_JrCT8cA_EdqSgKaj2SZBmg" x="-73.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KGW-AcA_EdqSgKaj2SZBmg" guid="_KGW-AcA_EdqSgKaj2SZBmg" anchor="_KGW-AMA_EdqSgKaj2SZBmg _KGW-AsA_EdqSgKaj2SZBmg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_73xfIROSEduCNqgZdt_OaA" guid="_73xfIROSEduCNqgZdt_OaA" anchor="_73xfIBOSEduCNqgZdt_OaA _73xfIhOSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_KGW-AMA_EdqSgKaj2SZBmg" guid="_KGW-AMA_EdqSgKaj2SZBmg" graphEdge="_KGW-AcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_KGW-A8A_EdqSgKaj2SZBmg" x="128.0" y="84.0"/>
+ </anchorage>
+ <anchorage xmi:id="_73xfIBOSEduCNqgZdt_OaA" guid="_73xfIBOSEduCNqgZdt_OaA" graphEdge="_73xfIROSEduCNqgZdt_OaA">
+ <position xmi:id="_73xfIxOSEduCNqgZdt_OaA" x="21.0" y="65.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JrCT8sA_EdqSgKaj2SZBmg" guid="_JrCT8sA_EdqSgKaj2SZBmg" typeInfo="start node"/>
+ <size xmi:id="_JrCT88A_EdqSgKaj2SZBmg" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz8BOLEduCNqgZdt_OaA" guid="_OWWz8BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz8ROLEduCNqgZdt_OaA" x="-20.0" y="32.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8IfbsROSEduCNqgZdt_OaA" guid="_8IfbsROSEduCNqgZdt_OaA" anchor="_8IfbsBOSEduCNqgZdt_OaA _8IfbshOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8Kfm0ROSEduCNqgZdt_OaA" guid="_8Kfm0ROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_73xfIhOSEduCNqgZdt_OaA" guid="_73xfIhOSEduCNqgZdt_OaA" graphEdge="_73xfIROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_8IfbsBOSEduCNqgZdt_OaA" guid="_8IfbsBOSEduCNqgZdt_OaA" graphEdge="_8IfbsROSEduCNqgZdt_OaA">
+ <position xmi:id="_8IfbsxOSEduCNqgZdt_OaA" x="117.0" y="64.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz8hOLEduCNqgZdt_OaA" guid="_OWWz8hOLEduCNqgZdt_OaA" element="_xupMvxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz8xOLEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz9BOLEduCNqgZdt_OaA" guid="_OWWz9BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz9ROLEduCNqgZdt_OaA" x="-16.0" y="157.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZY-cROSEduCNqgZdt_OaA" guid="_8ZY-cROSEduCNqgZdt_OaA" anchor="_8ZY-cBOSEduCNqgZdt_OaA _8ZY-chOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8bl94BOSEduCNqgZdt_OaA" guid="_8bl94BOSEduCNqgZdt_OaA"/>
+ <waypoints xmi:id="_ZRybwBjmEduxUfEVCtmW4Q" x="123.0" y="142.0"/>
+ </contained>
+ <anchorage xmi:id="_8IfbshOSEduCNqgZdt_OaA" guid="_8IfbshOSEduCNqgZdt_OaA" graphEdge="_8IfbsROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_8ZY-cBOSEduCNqgZdt_OaA" guid="_8ZY-cBOSEduCNqgZdt_OaA" graphEdge="_8ZY-cROSEduCNqgZdt_OaA">
+ <position xmi:id="_8ZY-cxOSEduCNqgZdt_OaA" x="158.0" y="132.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz9hOLEduCNqgZdt_OaA" guid="_OWWz9hOLEduCNqgZdt_OaA" element="_y1uwgBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz9xOLEduCNqgZdt_OaA" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz-BOLEduCNqgZdt_OaA" guid="_OWWz-BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz-ROLEduCNqgZdt_OaA" x="125.0" y="32.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8qxpYROSEduCNqgZdt_OaA" guid="_8qxpYROSEduCNqgZdt_OaA" anchor="_8qxpYBOSEduCNqgZdt_OaA _8qxpYhOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8s37IROSEduCNqgZdt_OaA" guid="_8s37IROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_8ZY-chOSEduCNqgZdt_OaA" guid="_8ZY-chOSEduCNqgZdt_OaA" graphEdge="_8ZY-cROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_8qxpYBOSEduCNqgZdt_OaA" guid="_8qxpYBOSEduCNqgZdt_OaA" graphEdge="_8qxpYROSEduCNqgZdt_OaA">
+ <position xmi:id="_8qxpYxOSEduCNqgZdt_OaA" x="264.0" y="66.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz-hOLEduCNqgZdt_OaA" guid="_OWWz-hOLEduCNqgZdt_OaA" element="_0Spa4BOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz-xOLEduCNqgZdt_OaA" width="109.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz_BOLEduCNqgZdt_OaA" guid="_OWWz_BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz_ROLEduCNqgZdt_OaA" x="130.0" y="158.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_86VvYROSEduCNqgZdt_OaA" guid="_86VvYROSEduCNqgZdt_OaA" anchor="_86VvYBOSEduCNqgZdt_OaA _86VvYhOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_88coMROSEduCNqgZdt_OaA" guid="_88coMROSEduCNqgZdt_OaA"/>
+ <waypoints xmi:id="_Z_czABjmEduxUfEVCtmW4Q" x="286.0" y="144.0"/>
+ </contained>
+ <anchorage xmi:id="_8qxpYhOSEduCNqgZdt_OaA" guid="_8qxpYhOSEduCNqgZdt_OaA" graphEdge="_8qxpYROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_86VvYBOSEduCNqgZdt_OaA" guid="_86VvYBOSEduCNqgZdt_OaA" graphEdge="_86VvYROSEduCNqgZdt_OaA">
+ <position xmi:id="_86VvYxOSEduCNqgZdt_OaA" x="339.0" y="132.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz_hOLEduCNqgZdt_OaA" guid="_OWWz_hOLEduCNqgZdt_OaA" element="_16nd0BOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz_xOLEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0ABOLEduCNqgZdt_OaA" guid="_OWW0ABOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0AROLEduCNqgZdt_OaA" x="285.0" y="31.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9JiB8ROSEduCNqgZdt_OaA" guid="_9JiB8ROSEduCNqgZdt_OaA" anchor="_9JiB8BOSEduCNqgZdt_OaA _9JiB8hOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9L0g8ROSEduCNqgZdt_OaA" guid="_9L0g8ROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_86VvYhOSEduCNqgZdt_OaA" guid="_86VvYhOSEduCNqgZdt_OaA" graphEdge="_86VvYROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9JiB8BOSEduCNqgZdt_OaA" guid="_9JiB8BOSEduCNqgZdt_OaA" graphEdge="_9JiB8ROSEduCNqgZdt_OaA">
+ <position xmi:id="_9JiB8xOSEduCNqgZdt_OaA" x="429.0" y="68.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0AhOLEduCNqgZdt_OaA" guid="_OWW0AhOLEduCNqgZdt_OaA" element="_3CqrAROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0AxOLEduCNqgZdt_OaA" width="117.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0BBOLEduCNqgZdt_OaA" guid="_OWW0BBOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0BROLEduCNqgZdt_OaA" x="300.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9YVS8ROSEduCNqgZdt_OaA" guid="_9YVS8ROSEduCNqgZdt_OaA" anchor="_9YVS8BOSEduCNqgZdt_OaA _9YVS8hOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9abksROSEduCNqgZdt_OaA" guid="_9abksROSEduCNqgZdt_OaA"/>
+ <waypoints xmi:id="_agGpABjmEduxUfEVCtmW4Q" x="446.0" y="135.0"/>
+ </contained>
+ <anchorage xmi:id="_9JiB8hOSEduCNqgZdt_OaA" guid="_9JiB8hOSEduCNqgZdt_OaA" graphEdge="_9JiB8ROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9YVS8BOSEduCNqgZdt_OaA" guid="_9YVS8BOSEduCNqgZdt_OaA" graphEdge="_9YVS8ROSEduCNqgZdt_OaA">
+ <position xmi:id="_9YVS8xOSEduCNqgZdt_OaA" x="502.0" y="132.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0BhOLEduCNqgZdt_OaA" guid="_OWW0BhOLEduCNqgZdt_OaA" element="_31E_YBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0BxOLEduCNqgZdt_OaA" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0CBOLEduCNqgZdt_OaA" guid="_OWW0CBOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0CROLEduCNqgZdt_OaA" x="438.0" y="30.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9rh7wROSEduCNqgZdt_OaA" guid="_9rh7wROSEduCNqgZdt_OaA" anchor="_9rh7wBOSEduCNqgZdt_OaA _9rh7whOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9toNgROSEduCNqgZdt_OaA" guid="_9toNgROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_9YVS8hOSEduCNqgZdt_OaA" guid="_9YVS8hOSEduCNqgZdt_OaA" graphEdge="_9YVS8ROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9rh7wBOSEduCNqgZdt_OaA" guid="_9rh7wBOSEduCNqgZdt_OaA" graphEdge="_9rh7wROSEduCNqgZdt_OaA">
+ <position xmi:id="_9rh7wxOSEduCNqgZdt_OaA" x="578.0" y="68.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0ChOLEduCNqgZdt_OaA" guid="_OWW0ChOLEduCNqgZdt_OaA" element="_467NIhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0CxOLEduCNqgZdt_OaA" width="103.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0DBOLEduCNqgZdt_OaA" guid="_OWW0DBOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0DROLEduCNqgZdt_OaA" x="456.0" y="152.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Amoa8ROTEduCNqgZdt_OaA" guid="_Amoa8ROTEduCNqgZdt_OaA" anchor="_Amoa8BOTEduCNqgZdt_OaA _Amoa8hOTEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9rh7whOSEduCNqgZdt_OaA" guid="_9rh7whOSEduCNqgZdt_OaA" graphEdge="_9rh7wROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_Amoa8BOTEduCNqgZdt_OaA" guid="_Amoa8BOTEduCNqgZdt_OaA" graphEdge="_Amoa8ROTEduCNqgZdt_OaA">
+ <position xmi:id="_Amoa8xOTEduCNqgZdt_OaA" x="661.0" y="136.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0DhOLEduCNqgZdt_OaA" guid="_OWW0DhOLEduCNqgZdt_OaA" element="_5v0NwBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0DxOLEduCNqgZdt_OaA" width="67.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_eqypIBjYEduxUfEVCtmW4Q" name="Add Free Text" guid="_eqypIBjYEduxUfEVCtmW4Q">
+ <property xmi:id="_eqypIRjYEduxUfEVCtmW4Q" guid="_eqypIRjYEduxUfEVCtmW4Q" key="free text" value="[last iteration in Inception]"/>
+ <position xmi:id="_eqypIhjYEduxUfEVCtmW4Q" x="33.0" y="108.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_eqypIxjYEduxUfEVCtmW4Q" guid="_eqypIxjYEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_eqypJBjYEduxUfEVCtmW4Q" width="66.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_EXh7QBjZEduxUfEVCtmW4Q" name="Add Free Text" guid="_EXh7QBjZEduxUfEVCtmW4Q">
+ <property xmi:id="_EXh7QRjZEduxUfEVCtmW4Q" guid="_EXh7QRjZEduxUfEVCtmW4Q" key="free text" value="[last iteration in Elaboration]"/>
+ <position xmi:id="_EXh7QhjZEduxUfEVCtmW4Q" x="182.0" y="104.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_EXh7QxjZEduxUfEVCtmW4Q" guid="_EXh7QxjZEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_EXh7RBjZEduxUfEVCtmW4Q" width="71.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_d66ZcBjaEduxUfEVCtmW4Q" name="Add Free Text" guid="_d66ZcBjaEduxUfEVCtmW4Q">
+ <property xmi:id="_d66ZcRjaEduxUfEVCtmW4Q" guid="_d66ZcRjaEduxUfEVCtmW4Q" key="free text" value="[last iteration in Construction]"/>
+ <position xmi:id="_d66ZchjaEduxUfEVCtmW4Q" x="349.0" y="102.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_d66ZcxjaEduxUfEVCtmW4Q" guid="_d66ZcxjaEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_d66ZdBjaEduxUfEVCtmW4Q" width="77.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5bCFkBjlEduxUfEVCtmW4Q" name="Add Free Text" guid="_5bCFkBjlEduxUfEVCtmW4Q">
+ <property xmi:id="_5bCFkRjlEduxUfEVCtmW4Q" guid="_5bCFkRjlEduxUfEVCtmW4Q" key="free text" value="[last iteration in Transition]"/>
+ <position xmi:id="_5bCFkhjlEduxUfEVCtmW4Q" x="491.0" y="101.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5bCFkxjlEduxUfEVCtmW4Q" guid="_5bCFkxjlEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_5bCFlBjlEduxUfEVCtmW4Q" width="69.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJkVYzEdqI9sTOt2pjHw" guid="_PrVJkVYzEdqI9sTOt2pjHw" presentation="Workflow" element="_0uyGoMlgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:DeliveryProcess" xmi:id="_0uyGoMlgEdmt3adZL5Dmdw" name="openup_basic_process" guid="_0uyGoMlgEdmt3adZL5Dmdw" briefDescription="This delivery process defines a software development process that supports the core principles of OpenUP. It is designed to support small co-located teams, consisting of 3 to 6 team members, working on a project that will last between 3 and 6 months." presentationName="OpenUP/Basic Lifecycle" isPlanned="false" breakdownElements="_xupMvxOKEduCNqgZdt_OaA _y1uwgBOKEduCNqgZdt_OaA _0Spa4BOKEduCNqgZdt_OaA _16nd0BOKEduCNqgZdt_OaA _3CqrAROKEduCNqgZdt_OaA _31E_YBOKEduCNqgZdt_OaA _467NIhOKEduCNqgZdt_OaA _5v0NwBOKEduCNqgZdt_OaA">
+ <ownedRules xmi:id="_u_X-YOETEdqMu-vDNOTdSg" name="diagram" guid="_u_X-YOETEdqMu-vDNOTdSg" body="ad_image_uri=_Pt_fYBjoEduxUfEVCtmW4Q|publish_ad_image=true|add_image_uri=|publish_add_image=false|wpd_image_uri=|publish_wpd_image=false"/>
+ <presentation xmi:id="_mtb-4PL5Edm6Nvont3uinw" href="uma://_mtb-4PL5Edm6Nvont3uinw#_mtb-4PL5Edm6Nvont3uinw"/>
+ <supportingMaterials href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Pt_fYBjoEduxUfEVCtmW4Q"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_48EKsBOMEduCNqgZdt_OaA"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_2plxwBOMEduCNqgZdt_OaA"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hmKgBOMEduCNqgZdt_OaA"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#__ca5UBOMEduCNqgZdt_OaA"/>
+ <includesPatterns href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0o3r4slgEdmt3adZL5Dmdw"/>
+ <includesPatterns href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0sTaYMlgEdmt3adZL5Dmdw"/>
+ <includesPatterns href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0rQRgMlgEdmt3adZL5Dmdw"/>
+ <includesPatterns href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-3IrutQEdqc1LGhiSPqRg"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplinegroupings/openup_basic_disciplines.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplinegroupings/openup_basic_disciplines.xmi
new file mode 100644
index 0000000..309f2b0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplinegroupings/openup_basic_disciplines.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="_AYGfoP1VEdmek8CQTQgrOQ" name="openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ" guid="_AYGfoP1VEdmek8CQTQgrOQ" changeDate="2006-10-09T16:19:05.242-0700">
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>, organized by <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/discipline,_yGUuidnmEdmO6L4XMImrsA.html" guid="_yGUuidnmEdmO6L4XMImrsA">disciplines</a>. You can see the&nbsp;tasks that have been included,&nbsp;and visit
+ each&nbsp;task page to see its definition and relationships to other elements.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplines/analysis_and_design.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/analysis_and_design.xmi
new file mode 100644
index 0000000..08dd4d0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/analysis_and_design.xmi
@@ -0,0 +1,40 @@
+<?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" epf:version="1.0.0" xmi:id="_Bbq2MLv-EdmmUvZAZjqE3g" name="architecture,_0TX9AMlgEdmt3adZL5Dmdw" guid="_Bbq2MLv-EdmmUvZAZjqE3g" changeDate="2007-01-27T09:43:38.921-0800" version="1.0.0">
+ <mainDescription><p>
+ The purposes of Analysis &amp; Design are:
+</p>
+<ul>
+ <li>
+ To transform the requirements into a design of the system-to-be.
+ </li>
+ <li>
+ To evolve a robust architecture for the system.
+ </li>
+ <li>
+ To adapt the design to match the implementation environment.
+ </li>
+</ul>
+<p>
+ The Analysis &amp; Design discipline is related to other disciplines, as follows:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline provides the primary input for Analysis and Design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/implementation,_0TeDoMlgEdmt3adZL5Dmdw.html" guid="_0TeDoMlgEdmt3adZL5Dmdw">Implementation</a> discipline implements the design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a> discipline tests system designed during Analysis and Design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project, and each iteration.
+ </li>
+</ul></mainDescription>
+ <keyConsiderations><p>
+ Creating and applying architectural mechanisms is essential for creating a robust architecture. See more on
+ architectural mechanisms at <a class="elementLink"
+ href="./../../openup_basic/customcategories/architectural_mechanisms,_2l8U4K4sEdudp4CB-AFxtw.html"
+ guid="_2l8U4K4sEdudp4CB-AFxtw">Architectural Mechanisms</a>.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplines/config_and_change_management.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/config_and_change_management.xmi
new file mode 100644
index 0000000..3e26139
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/config_and_change_management.xmi
@@ -0,0 +1,50 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_H9TXMLv-EdmmUvZAZjqE3g" name="change_management,_0TwXgMlgEdmt3adZL5Dmdw" guid="_H9TXMLv-EdmmUvZAZjqE3g" changeDate="2006-09-28T10:05:40.519-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Maintain a consistent set of work products as they evolve.
+ </li>
+ <li>
+ Maintain consistent builds of the software.
+ </li>
+ <li>
+ Provide an efficient means to adapt to changes and issues and re-plan work accordingly.
+ </li>
+ <li>
+ Provide data for measuring progress.
+ </li>
+</ul>
+<p>
+ In many organizations, the term "configuration management" implies all of these things.
+</p>
+<p>
+ Within the context of this process, configuration management refers to the ability to maintain&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/termdefinitions/version,_eX8K8ElyEducWJcS4yanqg.html" guid="_eX8K8ElyEducWJcS4yanqg">version</a>s of artifacts and consistent&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/termdefinitions/configuration,__Cw30ElxEducWJcS4yanqg.html" guid="__Cw30ElxEducWJcS4yanqg">configuration</a>s of artifacts, addressing the first two objectives listed above.
+ Change Management refers to the process of managing changes to configuration controlled artifacts, addressing the
+ latter two objectives listed above.
+</p>
+<p>
+ Although it is important to keep up to date versions and configurations of all work product, the primary work products
+ of concern&nbsp;are the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Artifact: Implementation</a>&nbsp;and&nbsp;the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Artifact: Build</a>.
+</p>
+<p>
+ Changes are managed via the <a class="elementLinkWithType" href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a>&nbsp;and subsequent prioritization and disposition of change requests via the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.
+</p>
+<p>
+ This discipline spans the entire lifecycle. Every other discipline relies upon the configuration and change management
+ discipline to maintain a consistent, up to date, set of work products and to prioritize and track changes to those work
+ products throughout the lifecycle.
+</p>
+<p>
+ Configuration and change management is done by everyone on the development team. Because of the importance and
+ pervasiveness of this discipline, configuration and change management guidance is associated with tasks and work
+ products in all other disciplines.
+</p></mainDescription>
+ <keyConsiderations><p>
+ It is assumed that the project has some form of configuration management system, such as CVS, to maintain version and
+ configuration information and enable collaborative development of the system. Without this, all but the most trivial of
+ development will be virtually impossible.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplines/implementation.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/implementation.xmi
new file mode 100644
index 0000000..a210cad
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/implementation.xmi
@@ -0,0 +1,45 @@
+<?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" epf:version="1.0.0" xmi:id="_D5dHQLv-EdmmUvZAZjqE3g" name="development,_0TeDoMlgEdmt3adZL5Dmdw" guid="_D5dHQLv-EdmmUvZAZjqE3g" changeDate="2006-09-29T13:39:25.971-0400" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Incrementally build the system.
+ </li>
+ <li>
+ Verify that the technical units used to build the system work as specified.
+ </li>
+</ul>
+<p>
+ With each iteration, the tasks in this discipline will evolve an ever more capable and ever more stable <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>.
+</p>
+<p>
+ When working on the system, the <a class="elementLink" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a>&nbsp;will use the architecture and also be constrained by the
+ architecture.
+</p>
+<p>
+ This&nbsp;discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;discipline defines&nbsp;what will be implemented.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis & Design</a>&nbsp;discipline organizes and constrains the
+ implementation.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a>&nbsp;discipline validates that system&nbsp;built meets
+ the&nbsp;requirements.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration & Change Management</a>&nbsp;discipline provides the mechanisms to
+ manage changes to the system built.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a>&nbsp;discipline plans what functionality will be implemented
+ in each iteration.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplines/project_management.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/project_management.xmi
new file mode 100644
index 0000000..90833d3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/project_management.xmi
@@ -0,0 +1,67 @@
+<?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" epf:version="1.0.0" xmi:id="_GybfgLv-EdmmUvZAZjqE3g" name="project_management,_0TqQ4MlgEdmt3adZL5Dmdw" guid="_GybfgLv-EdmmUvZAZjqE3g" changeDate="2006-09-28T15:15:05.712-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Keep the team focused on continually delivering tested software product for stakeholder evaluation
+ </li>
+ <li>
+ Help prioritize the sequence of work
+ </li>
+ <li>
+ Help create an effective working environment to maximize team productivity
+ </li>
+ <li>
+ Keep stakeholders and the team informed on project progress
+ </li>
+ <li>
+ Provide a framework to manage project risk and continually adapt to change
+ </li>
+</ul>
+<p>
+ Project management acts as a bridge between the stakeholders and the development team. It is important that project
+ management activities add value to creating a high performance work environment where
+</p>
+<ul>
+ <li>
+ Stakeholders have confidence in the team’s ability to successfully deliver value and understand the capabilities
+ and tradeoffs of the technical platform
+ </li>
+ <li>
+ Project team members understand stakeholder intentions and confirm that understanding by continually producing a
+ working software product for evaluation
+ </li>
+</ul>
+<p>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> works with <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> to create a coarse-grained <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Project Plan</a> based on the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>
+ for the project. This project plan describes the lengths and objectives of the four <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html" guid="__7xOEC7aEdqHMdmRzC0-2g">Phases</a> and the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Iterations</a> within each phase.
+</p>
+<p>
+ At the beginning of each iteration, the project manager works with stakeholders and the development team to prioritize
+ requirements, change requests, and defects in the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Item List</a> and allocate them to the upcoming iteration.
+</p>
+<p>
+ The project manager then works with the development team to create a fine-grained <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> based on the objectives in the project plan and the work items
+ assigned to the iteration. Team members volunteer to collaborate on allocated work items and provide the project
+ manager with tasks and time estimates to deliver those work items.
+</p>
+<p>
+ The team demonstrates they understand stakeholder intentions throughout each iteration by building a working software
+ product that is demonstrated to stakeholders to affirm understanding and elicit feedback. At the end of each iteration,
+ the evaluation of the final <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>
+ must include test results and should be captured in a <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a> and communicated to all stakeholders and team members.
+</p>
+<p>
+ The development team demonstrates continual progress to stakeholders by reporting closed-out work items in each
+ iteration through the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/reports/project_burndown,_ePrt8Dj3EduxovfWMDsntw.html" guid="_ePrt8Dj3EduxovfWMDsntw">Project Burndown</a>. The team can use <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Iteration Burndown</a> to demonstrate progress during an iteration.
+</p>
+<p>
+ Project management needs to consider the uncertainties facing the project (i.e. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Risks</a>) and pro-actively work with stakeholders and the team to continually adapt to
+ changes in business needs, system requirements, and technical capabilities.
+</p>
+<p>
+ Project Management is an umbrella discipline which has impact and is impacted by all other disciplines.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplines/requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/requirements.xmi
new file mode 100644
index 0000000..ea1719b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/requirements.xmi
@@ -0,0 +1,63 @@
+<?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" epf:version="1.0.0" xmi:id="__rFCULv9EdmmUvZAZjqE3g" name="requirements,_0TR2ZMlgEdmt3adZL5Dmdw" guid="__rFCULv9EdmmUvZAZjqE3g" changeDate="2006-09-20T13:00:00.125-0400">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Understand the problem to be solved
+ </li>
+ <li>
+ Understand stakeholder needs (what users want)&nbsp;
+ </li>
+ <li>
+ Define the requirements for the solution (what the system must do)
+ </li>
+ <li>
+ Define the boundaries (scope) of the system
+ </li>
+ <li>
+ Identify external interfaces for the system
+ </li>
+ <li>
+ Identify technical constraints on the solution
+ </li>
+ <li>
+ Provide the basis for planning iterations
+ </li>
+ <li>
+ Provide the initial basis for estimating cost and schedule
+ </li>
+</ul>
+<p>
+ To achieve these goals, it is important to understand the definition and scope of the problem&nbsp;that we are trying
+ to solve.&nbsp; <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>&nbsp;are identified and the problem to be solved is defined.
+</p>
+<p>
+ Having agreed on the problem to be solved, the <a class="elementLink" href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;for the system are elicited, organized, analyzed, validated and
+ specified.
+</p>
+<p>
+ Throughout the lifecycle, changes to the requirements are managed.
+</p>
+<p>
+ The Requirements discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis & Design</a>&nbsp;discipline gets its primary input from the
+ Requirements discipline
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a>&nbsp;discipline validates the system against the requirements
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration & Change Management</a>&nbsp;discipline provides the mechanisms to
+ manage changes to the requirements
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a>&nbsp;discipline plans the project and assigns
+ requirements&nbsp;to each iteration by analyzing the prioritized requirements and assigning work.&nbsp;
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/disciplines/test.xmi b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/test.xmi
new file mode 100644
index 0000000..830f69f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/disciplines/test.xmi
@@ -0,0 +1,64 @@
+<?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" epf:version="1.0.0" xmi:id="_FuQswLv-EdmmUvZAZjqE3g" name="test,_0TkKQMlgEdmt3adZL5Dmdw" guid="_FuQswLv-EdmmUvZAZjqE3g" changeDate="2006-09-29T09:24:16.091-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Find and document defects.
+ </li>
+ <li>
+ Validate and prove the assumptions made in design and requirement specifications through concrete demonstration.
+ </li>
+ <li>
+ Validate that the software product works as designed.
+ </li>
+ <li>
+ Validate that the requirements are implemented appropriately.
+ </li>
+</ul>
+<p>
+ A good test effort is based on the philosophy of test early and test often. In addition, it is driven by questions such
+ as:
+</p>
+<ul>
+ <li>
+ How could this software break?
+ </li>
+ <li>
+ In what possible situations could this software fail to work predictably?
+ </li>
+</ul>
+<p>
+ Testing challenges the assumptions, risks, and uncertainty inherent in the work of other disciplines, and addresses
+ those concerns using concrete demonstration and impartial evaluation.
+</p>
+<p>
+ The Test discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline captures requirements for the software product, which is
+ one of the primary inputs for identifying what tests to perform.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis and Design</a> discipline determines the appropriate design for the
+ software product, which is another important input for identifying what tests to perform.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/implementation,_0TeDoMlgEdmt3adZL5Dmdw.html" guid="_0TeDoMlgEdmt3adZL5Dmdw">Implementation</a> discipline produces builds of the software product that are
+ validated by the Test discipline. Within an iteration, multiple builds will be tested - typically one per test
+ cycle.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project and the necessary work in each
+ iteration. Described in an Iteration Plan, this artifact is an important input used when you define the correct
+ evaluation mission for the test effort.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration and Change Management</a> discipline controls changes within the
+ project. The test effort verifies that each change has been completed appropriately. Test assets are kept
+ under&nbsp;configuration management.<br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/architecture.xmi
new file mode 100644
index 0000000..1bbb12a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/architecture.xmi
@@ -0,0 +1,2 @@
+<?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="-9qPK9k01PN_COE9YPXpw8Q" name="architecture,_xITr8MWXEdqWePvIjHInwg" guid="-9qPK9k01PN_COE9YPXpw8Q" changeDate="2006-04-06T11:51:46.047-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/change_management.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/change_management.xmi
new file mode 100644
index 0000000..e144c6a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/change_management.xmi
@@ -0,0 +1,2 @@
+<?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="-X9nP8esP9nWMvx1wmMaJAA" name="new_domain,_vUzp0MWeEdqiT9CqkRksWQ" guid="-X9nP8esP9nWMvx1wmMaJAA" changeDate="2006-04-06T11:54:47.268-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/development.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/development.xmi
new file mode 100644
index 0000000..fc45528
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/development.xmi
@@ -0,0 +1,2 @@
+<?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="-xO3vqWsd3W98UXFsyp-wGA" name="new_domain,_A9k3UMWfEdqiT9CqkRksWQ" guid="-xO3vqWsd3W98UXFsyp-wGA" changeDate="2006-04-06T11:56:28.463-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/openup_basic_wp.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/openup_basic_wp.xmi
new file mode 100644
index 0000000..dff2db6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/openup_basic_wp.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-15BvSftWbF7VdZ_W8YycBQ" name="openup_basic_domains,_s4Z9AMWXEdqWePvIjHInwg" guid="-15BvSftWbF7VdZ_W8YycBQ" changeDate="2006-10-09T16:14:59.437-0700">
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>, organized by <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/domain,_yHEVYdnmEdmO6L4XMImrsA.html" guid="_yHEVYdnmEdmO6L4XMImrsA">domains</a>. You can see the work products that have been included, and visit each work
+ product page to see its definition and relationships to other elements.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/project_management.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/project_management.xmi
new file mode 100644
index 0000000..0104954
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/project_management.xmi
@@ -0,0 +1,2 @@
+<?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="-N4r_U0LZhZ_K-8gfHON9BA" name="new_domain,_QxjGYMWfEdqiT9CqkRksWQ" guid="-N4r_U0LZhZ_K-8gfHON9BA" changeDate="2006-04-06T11:58:20.214-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/requirements.xmi
new file mode 100644
index 0000000..05c8de8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/requirements.xmi
@@ -0,0 +1,2 @@
+<?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="-d5O4LFNaAs4YRDxfxH3CRw" name="new_domain,_allMQMWfEdqiT9CqkRksWQ" guid="-d5O4LFNaAs4YRDxfxH3CRw" changeDate="2006-04-06T11:59:52.857-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/domains/test.xmi b/OpenUP/OpenUP_PT/library/openup_basic/domains/test.xmi
new file mode 100644
index 0000000..9e1cc97
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/domains/test.xmi
@@ -0,0 +1,2 @@
+<?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="-Mxgu9hq0upbMqZlq1xBFYw" name="new_domain,_ou4CMMWfEdqiT9CqkRksWQ" guid="-Mxgu9hq0upbMqZlq1xBFYw" changeDate="2006-04-06T12:00:58.171-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/actor.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/actor.xmi
new file mode 100644
index 0000000..aad7465
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/actor.xmi
@@ -0,0 +1,30 @@
+<?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="_KEldgMM1EdmSIPI87WLu3g" name="actor,_0VrDEMlgEdmt3adZL5Dmdw" guid="_KEldgMM1EdmSIPI87WLu3g" changeDate="2005-07-07T13:18:05.934-0700">
+ <sections xmi:id="_ytiigAYQEdubLa3RRn5f4A" name="Have you found all the actors" guid="_ytiigAYQEdubLa3RRn5f4A">
+ <sectionDescription>Have you accounted for all roles in the systems environment?&nbsp; See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for some questions that may help
+identify actors.</sectionDescription>
+ </sections>
+ <sections xmi:id="_AcjQMAYREdubLa3RRn5f4A" name="Is each actor involved with at least one use case" guid="_AcjQMAYREdubLa3RRn5f4A">
+ <sectionDescription>If you cannot identify a use case associated with a given actor perhaps the actor should be removed, or perhaps you are
+missing a use case.</sectionDescription>
+ </sections>
+ <sections xmi:id="_P3mo8AYREdubLa3RRn5f4A" name="Can you identify at least two people, or external systems, that would play the role of a particular actor" guid="_P3mo8AYREdubLa3RRn5f4A">
+ <sectionDescription>If you cannot, check if the role that the actor represents is part of another actor.&nbsp; If that is the case, you should
+merge the actors.</sectionDescription>
+ </sections>
+ <sections xmi:id="_b640oAYREdubLa3RRn5f4A" name="Will a particular actor use the system in several completely different ways" guid="_b640oAYREdubLa3RRn5f4A">
+ <sectionDescription><p>
+ If true, you should probably have more than one actor.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_iOHtQAYREdubLa3RRn5f4A" name="Does the actor have several completely different purposes for using the system" guid="_iOHtQAYREdubLa3RRn5f4A">
+ <sectionDescription>If true, there may be more than one actor.</sectionDescription>
+ </sections>
+ <sections xmi:id="_ptfB0AYREdubLa3RRn5f4A" name="Have you considered maintenance and administrative roles" guid="_ptfB0AYREdubLa3RRn5f4A">
+ <sectionDescription>It is common to focus on the daily users of the system, and forget about administrative and maintenance roles such as
+setting up user accounts, managing access rights, performing backups, etc.&nbsp; Ensure you have captured these actors.</sectionDescription>
+ </sections>
+ <sections xmi:id="_2i_UoAYREdubLa3RRn5f4A" name="Does each actor have a clear description of its role" guid="_2i_UoAYREdubLa3RRn5f4A">
+ <sectionDescription>Each actor should have a short description of the role and the main goal the actor has in using the system.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/architecture.xmi
new file mode 100644
index 0000000..c894e97
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/architecture.xmi
@@ -0,0 +1,141 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_17Ve8Nd6EdmIm-bsRSNCgw" name="architecture,_17PYUNd6EdmIm-bsRSNCgw" guid="_17Ve8Nd6EdmIm-bsRSNCgw" authors="Chris Doyle, Mark Dickson" changeDate="2007-03-03T09:34:09.111-0800" changeDescription="(Mark Dickson) formatted & applied changes from Chris Doyle |Major re-|Major re-write in line with Supporting Requirements checklist" version="1.3">
+ <mainDescription><p>
+ The items in this checklist represent good practices for creating and communicating a robust architecture. It may not
+ be possible to address every item, and some items may only be able to be addressed to a limited extent. In these cases,
+ be sure that there are good reasons for only partially addressing an item, or not addressing an item at all.
+</p>
+<p>
+ Architecture can be performed every day. Use this checklist regularly to ensure the results are robust, consistent, and
+ understandable. Make the architecture good enough for the specific goals being addressed by using this checklist to
+ identify areas that have been skipped, ignored, or not sufficiently addressed.
+</p></mainDescription>
+ <sections xmi:id="_LqpmkCALEduY2JH31Kkn-A" name="Is the overall structure of the architecture clear?" guid="_LqpmkCALEduY2JH31Kkn-A">
+ <sectionDescription><ul>
+ <li>
+ Are the key abstractions adequately defined?
+ </li>
+ <li>
+ Have&nbsp;necessary&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s been identified and described?
+ </li>
+ <li>
+ Does the architecture divide the system’s responsibilities into well-defined subsystems with well-defined
+ interfaces?
+ </li>
+ <li>
+ Does the packaging approach reduce complexity and improve understanding?
+ </li>
+ <li>
+ Is subsystem and package partitioning and layering logically consistent?
+ </li>
+ <li>
+ Are packages defined to be highly cohesive within the package, while the packages themselves are loosely coupled?
+ </li>
+ <li>
+ Are all of the subsystem components for the iteration identified?
+ </li>
+ <li>
+ Do the dependencies between subsystems and packages correspond to dependency relationships between the contained
+ classes?
+ </li>
+ <li>
+ Do the classes in a subsystem support the services identified for the subsystem?
+ </li>
+ <li>
+ Are the number and types of components reasonable?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_pWBfQMm9EduiAPR4gd-qxA" name="Have the supporting requirements been adequately addressed?" guid="_pWBfQMm9EduiAPR4gd-qxA">
+ <sectionDescription><ul>
+ <li>
+ Does the architecture adequately address&nbsp;the global Functional requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Usability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Reliability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Performance requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Supportability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the other needs identified in the&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_PHv_kCALEduY2JH31Kkn-A" name="Can the architecture be delivered by the team?" guid="_PHv_kCALEduY2JH31Kkn-A">
+ <sectionDescription><ul>
+ <li>
+ Does the component architecture provide a suitable basis for organizing the development teams?
+ </li>
+ <li>
+ Does each team have the skills required to implement their allocated components?
+ </li>
+ <li>
+ Are responsibilities divided well between teams?
+ </li>
+ <li>
+ Do all team members share the same understanding of the architecture as the one presented by the architect?
+ </li>
+ <li>
+ Can team members understand enough from the architecture to successfully design and code their allocated
+ components?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_A8m2YMm7EduiAPR4gd-qxA" name="Is architecture showing appropriate stability?" guid="_A8m2YMm7EduiAPR4gd-qxA">
+ <sectionDescription><ul>
+ <li>
+ If in Inception, is&nbsp;a candidate&nbsp;architecture emerging?
+ </li>
+ <li>
+ If in Elaboration, is the architecture beginning to stabilize?
+ </li>
+ <li>
+ If in Construction, is the architecture generally stable?
+ </li>
+ <li>
+ If in Transition, is the architecture very stable?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_aOKkwMm8EduiAPR4gd-qxA" name="In general, does the architecture seem sensible?" guid="_aOKkwMm8EduiAPR4gd-qxA">
+ <sectionDescription><ul class="noindent">
+ <li>
+ Is the&nbsp;architecture&nbsp;at an appropriate level of detail, given the objectives?
+ </li>
+ <li>
+ Are concepts&nbsp;handled in the simplest way possible?
+ </li>
+ <li>
+ Can the&nbsp;architecture easily evolve,&nbsp;so that&nbsp;expected changes can be easily accommodated?
+ </li>
+ <li>
+ At the same time, has the&nbsp;architecture been overly structured to handle unlikely change at the expense of
+ simplicity and comprehensibility? (Hint: "Yes" to this question is not good).
+ </li>
+ <li>
+ Are the key assumptions and decisions that the&nbsp;architecture is based on documented and visible to reviewers
+ and consumers of the architecture?
+ </li>
+ <li>
+ Is the architecture description current?
+ </li>
+ <li>
+ Have the design guidelines been followed?
+ </li>
+ <li>
+ Are all technical risks either mitigated or addressed in a contingency plan?
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/design.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/design.xmi
new file mode 100644
index 0000000..4b511b6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/design.xmi
@@ -0,0 +1,131 @@
+<?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" epf:version="1.0.0" xmi:id="_YIYIYMM1EdmSIPI87WLu3g" name="design,_0XSzsMlgEdmt3adZL5Dmdw" guid="_YIYIYMM1EdmSIPI87WLu3g" changeDate="2006-09-15T15:28:43.942-0400" version="1.0.0">
+ <mainDescription><p>
+ The items in this checklist represent good practices for creating and communicating a robust design. Try to address
+ every item to the greatest extent possible to create the best design. It may not be possible to address every item, and
+ some items may only be able to be addressed to a limited extent. In these cases, be sure that there are good reasons
+ for only partially addressing an item, or not addressing an item at all.
+</p>
+<p>
+ Design can be performed every day. Use this checklist regularly to assure the design is robust, consistent, and
+ understandable. Make the design good enough for the specific goals being addressed by using this checklist to identify
+ areas that have been skipped, ignored, or not sufficiently addressed.
+</p></mainDescription>
+ <sections xmi:id="_cKSvsD6SEduAL-bCqar_dg" name="General" guid="_cKSvsD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Do separate design elements have low coupling? Does each design element have high internal cohesion?
+</p>
+<p>
+ Does the design reflect the architectural objectives of the system?
+</p>
+<p>
+ Can the system be implemented from the information in the design? Has sufficient detail been included?
+</p>
+<p>
+ Is the design consistent? Does any part of the design contradict another part of it in such a way that puts the project
+ at risk?
+</p>
+<p>
+ Is the design able to accommodate future changes?
+</p>
+<p>
+ Is the design appropriate to the experience level of other team members and stakeholders, neither too simple nor too
+ advanced?
+</p>
+<p>
+ Is the design written in such a way, and is it structured well enough, so it can be maintained easily?
+</p>
+<p>
+ Does the design constrain the implementation only as much as is necessary?
+</p>
+<p>
+ Does the design describe all the behavior of the system for the requirements that are currently being addressed?
+</p>
+<p>
+ Can all parts of the design be traced back to the requirements? Can the requirements (for the current iteration) be
+ traced to design elements?
+</p>
+<p>
+ Is there an unambiguous place or places&nbsp;in the design where each behavior exists?
+</p>
+<p>
+ Are the use case flows that are currently being addressed described in the design?
+</p>
+<p>
+ Are&nbsp;complex flows outside the Basic Flow&nbsp;addressed, including exceptional cases?
+</p>
+<p>
+ Has the behavior described in the requirements that are currently being addressed&nbsp;been distributed to the correct
+ design elements?
+</p>
+<p>
+ Does the design provide enough information for test design? For example, are the collaborations between design elements
+ clear enough to create integration tests?
+</p>
+<p>
+ Have redundant areas of the design been removed so the Implementation does not contain redundant code?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="__4O2AD6WEduAL-bCqar_dg" name="Organization and Clarity" guid="__4O2AD6WEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Does the design describe the system at the appropriate level of abstraction, given the objectives? This usually means
+ the system is described at a number of different levels of&nbsp;abstraction and perspectives.
+</p>
+<p>
+ Does the design use common vocabulary and terms from the business and technical domains?
+</p>
+<p>
+ Does the design describe the behavior of the elements unambiguously to the extent that developer tests can be created
+ toverify the implementation?
+</p>
+<p>
+ Are the design's constructs, vocabulary, and semantics appropriate to the problem being solved? This usually means the
+ customer's vocabulary is used, and elements of the design are referenced in a consistent manner.
+</p>
+<p>
+ Is the design organized in a way that team members can easily find the information they're looking for?
+</p>
+Is the notation used to&nbsp;describe the design&nbsp;used consistently?<br />
+<p>
+ Is the design organized in a way that helps team members modify it without contending for the same part of the design?
+ That is, can mulitple people work on the design in parallel?
+</p>
+<p>
+ Are the names of elements within the design consistent and easy to interpret?
+</p>
+<p>
+ Does each design element represent a clearly defined abstraction?
+</p>
+<p>
+ Is the design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to
+ implementers?
+</p>
+<p>
+ Is the design clear enough and contain enough detail so it can be implemented?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_dahBcD6SEduAL-bCqar_dg" name="Architecture" guid="_dahBcD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Is the architecture clearly called out in the design ? Can team members and stakeholders clearly identify the portion
+ of the design that is the architecture?
+</p>
+<p>
+ Are architectural mechanisms (patterns) clearly defined in the design so they're reusable and understandable?
+</p>
+<p>
+ Are architectural mechanisms used appropriately? Are they applied in all applicable circumstances?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_kWnQ4D6SEduAL-bCqar_dg" name="Subsystems" guid="_kWnQ4D6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the&nbsp;only
+ way to access the behavior of elements inside the subsystem?
+</p>
+<p>
+ Is the interface for each subsystem clearly defined in the design?
+</p>
+<p>
+ Are the subsystem dependencies documented?&nbsp;
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/design_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/design_vm.xmi
new file mode 100644
index 0000000..838d45e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/design_vm.xmi
@@ -0,0 +1,114 @@
+<?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" epf:version="1.0.0" xmi:id="-HQSI39vBrjpmQL1qHYOJtA" name="new_checklist,_nnSXcD6SEduAL-bCqar_dg" guid="-HQSI39vBrjpmQL1qHYOJtA" version="1.0.0">
+ <sections xmi:id="_sG8ZoD6SEduAL-bCqar_dg" name="Packages and Organization" guid="_sG8ZoD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Is the package partitioning logical and consistent? Does it make sense to team members and stakeholders?
+</p>
+<p>
+ Do package names accurately describe the contents of the package and the role they play in the architecture? Do they
+ follow naming conventions?
+</p>
+<p>
+ Do public packages and interfaces provide a logically cohesive set of services?
+</p>
+<p>
+ Are all the contents of a package listed? Are the classes within a package cohesive?
+</p>
+<p>
+ Do package dependencies correspond to the dependencies of the contained classes?
+</p>
+<p>
+ Are there packages or classes within a package that can be separated into and independent or sub-package?<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_tx6tsD6SEduAL-bCqar_dg" name="Views" guid="_tx6tsD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Does each diagram help the designer reason about the design, or communicate key design decisions to the team?
+</p>
+<p>
+ Are the relationships between diagrams clear when several diagrams are used to describe behavior?
+</p>
+<p>
+ Is it easy to navigate between related diagrams?
+</p>
+<p>
+ Does each diagram focus on a relevant perspective? For instance, does a set of diagrams show a single class and its
+ direct relationships, rather than using&nbsp;one or two diagrams to show all classes?
+</p>
+<p>
+ Is each diagram complete and minimal? Does it show everything relevant to that view and nothing more?
+</p>
+<p>
+ Are the diagrams tidy and easy to interpret, with a minimum of clutter?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_yeFh4D6SEduAL-bCqar_dg" name="UML" guid="_yeFh4D6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Does the visual model conform to UML standards so all stakeholders can understand the model over time? See the&nbsp;<a href="http://www.uml.org/" target="_blank">OMG UML Resource Page</a>&nbsp;for more information.
+</p>
+<p>
+ Does the visual model conform to project or organization specific modeling standards?
+</p>
+Is the visual model internally consistent? For instance, if an object diagram shows a relationship between objects, does a
+corresponding relationship exist between the appropriate classes?<br />
+<p>
+ Does the name of each class clearly reflect the role it plays?
+</p>
+<p>
+ Does each class offer the required behavior?
+</p>
+<p>
+ Is there at least one&nbsp;realization association defined for each interface? The realization may represent a 3rd
+ party implementation of the subsystem.
+</p>
+<p>
+ Are&nbsp;there dependency associations from each subsystem to the interfaces it uses?
+</p>
+<p>
+ Is each operation in a subsystem interface described in a sequence diagram? Or at least mapped directly to an operation
+ in a class?
+</p>
+<p>
+ Does each class represent a single well defined abstraction?
+</p>
+<p>
+ Are generalization relationships used only to inherit definitions, not behavior (implementation)? In other words, is
+ behavior shared through the use of association, aggregation and containment relationships instead of generalization?
+</p>
+<p>
+ Are parent classes in generalization relationships abstract? Are the "leaf" classes in a generalization hierarchy the
+ only concrete classes?
+</p>
+<p>
+ Are stereotypes used consistently and meaningfully?
+</p>
+<p>
+ Do&nbsp;statecharts exist for classes with complex or restrictive state changes?
+</p>
+<p>
+ Do relationships have descriptive role or association names (one or the other but not both), and&nbsp;correct
+ multiplicities?
+</p>
+<p>
+ Are relationships between classes unidirectional whenever possible?<br />
+ &nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_IsDY4D6TEduAL-bCqar_dg" name="Non-UML Visual Modeling" guid="_IsDY4D6TEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Are the semantics of the visual modeling language clearly defined, documented, and accessible to team members? The
+ semantics should be meaninful to the users of the model.
+</p>
+<p>
+ Can the semantics of the modeling language be understood over time? Is the language documented well enough so that team
+ members can understand the model long after design decisions have taken place?
+</p>
+<p>
+ Are team members and stakeholders trained in the modeling language being used?
+</p>
+<p>
+ Does the visual model conform to the semantics of the visual modeling language? In other words, are the meanings
+ of&nbsp;the symbols in the diagrams&nbsp;consistent across the model and diagrams?&nbsp;
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/good_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/good_requirements.xmi
new file mode 100644
index 0000000..915dac0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/good_requirements.xmi
@@ -0,0 +1,79 @@
+<?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" epf:version="1.0.0" xmi:id="-2o1pXjHpSEPN_rohLce5jA" name="good_requirements_1,_jxn9EO0HEdqHTdbLTmC5IQ" guid="-2o1pXjHpSEPN_rohLce5jA" authors="Chris Sibbald" changeDate="2006-04-10T11:07:04.339-0400" changeDescription="Added checklist for good requirements in accordance with Feb. 23, 2006 minutes of RM SIG." version="0.1">
+ <sections xmi:id="_jxuDsu0HEdqHTdbLTmC5IQ" name="Is the requirement correct?" guid="_jxuDsu0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Does the requirement specify a true need, desire, or obligation?
+</p>
+<p>
+ Have you identified the "root cause" for the requirement?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDs-0HEdqHTdbLTmC5IQ" name="Is the requirement complete?" guid="_jxuDs-0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement stated as a complete sentence?
+</p>
+<p>
+ Is the requirement stated entirely in one place, in a manner that does not force the reader to look at additional
+ information to understand the requirement?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDse0HEdqHTdbLTmC5IQ" name="Is the requirement clear?" guid="_jxuDse0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement unambiguous and not confusing?
+</p>
+<p>
+ Does everyone agree on the meaning of the requirement?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDt-0HEdqHTdbLTmC5IQ" name="Is the requirement consistent" guid="_jxuDt-0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement in conflict with other requirements?
+</p>
+<p>
+ Is the terminology used consistent with other requirements and glossary terms?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDte0HEdqHTdbLTmC5IQ" name="Is the requirement verifiable?" guid="_jxuDte0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Can we determine whether the system satisfies the requirement?
+</p>
+<p>
+ Is it possible to define a clear, unambiguous&nbsp;pass/fail criterion?
+</p>
+<p>
+ Is it possible to determine if the requirement has been met via inspection, analysis, demonstration or test?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDtu0HEdqHTdbLTmC5IQ" name="Is the requirement traceable?" guid="_jxuDtu0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement uniquely identified so it can be unambiguously referenced?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDtO0HEdqHTdbLTmC5IQ" name="Is the requirement feasible?" guid="_jxuDtO0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Can the requirement be satisfied within cost and on schedule?
+</p>
+<p>
+ Is the requirement technically feasible with current technology?
+</p>
+<p>
+ Is the requirement physically achievable?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDsO0HEdqHTdbLTmC5IQ" name="Is the requirement design independent?" guid="_jxuDsO0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Are all requirements that impose constraints on the design, limiting design options,&nbsp;justified?
+</p>
+<p>
+ Is the requirement stated in such that there is more than one way that it can be satisfied?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_gRb_IJEvEdui_vx06Mo1eg" name="Is the requirement atomic?" guid="_gRb_IJEvEdui_vx06Mo1eg">
+ <sectionDescription><p>
+ Does the requirement statement define exactly one requirement?
+</p>
+<p>
+ Is the requirement statement free of conjunctions (and, or, but) that may indicate multiple requirements?
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/risk_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/risk_list.xmi
new file mode 100644
index 0000000..c8e1473
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/risk_list.xmi
@@ -0,0 +1,36 @@
+<?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="-gqNN4DnROmJpgKtrdguhpg" name="new_checklist,_7BZa0DIdEduDTv4Y1akVTA" guid="-gqNN4DnROmJpgKtrdguhpg" changeDate="2006-08-22T13:38:14.915-0700">
+ <sections xmi:id="_qO41ADIfEduDTv4Y1akVTA" name="Have all potential risks to the project been identified" guid="_qO41ADIfEduDTv4Y1akVTA">
+ <sectionDescription>Have you identified anything that can be on the path to the project success? List all potential risks, giving a description
+and type (direct or indirect). See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <sections xmi:id="_5RiSkDe2EduD7J48kKN20g" name="Are risks described without ambiguity" guid="_5RiSkDe2EduD7J48kKN20g">
+ <sectionDescription>Make sure you capture and describe risks in a clear, concise and unambiguous way. Also follow these rules when describing
+mitigation strategies for risks. This will avoid unnecessary work and - more importantly -&nbsp;that a risks are
+effectively identified and managed.</sectionDescription>
+ </sections>
+ <sections xmi:id="_2rpQoDIfEduDTv4Y1akVTA" name="What is the probability of happening and impact of each risk" guid="_2rpQoDIfEduDTv4Y1akVTA">
+ <sectionDescription>Determine&nbsp;the probability of the risk happening and its impact on the project. This gives you the order of magnitude
+of risks (probability x impact), allowing you to address the high magnitude risks early in the project. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <sections xmi:id="_x-gbwDe0EduD7J48kKN20g" name="Have the risks been properly prioritized and sorted" guid="_x-gbwDe0EduD7J48kKN20g">
+ <sectionDescription>The risk list is a prioritized list with the highest risk at the top and the rest in descending order.&nbsp; They should be
+sorted according to their magnitude of risk.</sectionDescription>
+ </sections>
+ <sections xmi:id="_hSFaYDe3EduD7J48kKN20g" name="Are there interdependencies between risks" guid="_hSFaYDe3EduD7J48kKN20g">
+ <sectionDescription><p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Make sure you establish interdependencies between risks as
+ appropriate. For example, the consequence of a risk happening may raise the probability of another risk happening, or
+ raise the impact that other risk brings to the project. If risks depend on each other, you may need to
+ mitigate&nbsp;all interdependent risks&nbsp;at the same time, or revisit the risk list to update the magnitude of
+ dependent risks.</span>
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_LATHgDIeEduDTv4Y1akVTA" name="Is there a mitigation strategy for each risk" guid="_LATHgDIeEduDTv4Y1akVTA">
+ <sectionDescription><p>
+ Propose a mitigation strategy for each identified risk. You can either transfer the risk, avoid it, accept it or
+ mitigate it (by minimizing the probability&nbsp;of happening or impact&nbsp;that the risk brings to the project). See
+ <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk_management,_VNxL4ACsEdu8m4dIntu6jA.html" guid="_VNxL4ACsEdu8m4dIntu6jA">Concept: Risk Management</a> for more information.
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/supporting_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/supporting_requirements.xmi
new file mode 100644
index 0000000..fdd61b1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/supporting_requirements.xmi
@@ -0,0 +1,98 @@
+<?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" epf:version="1.0.0" xmi:id="-kw2vYHKDkWv2tZrDMrBPNA" name="new_checklist,_Vael8CGMEdu3VKXZx45D3A" guid="-kw2vYHKDkWv2tZrDMrBPNA" version="1.0.0">
+ <sections xmi:id="_kTZiACGMEdu3VKXZx45D3A" name="Have global Functional requirements that will be implemented in the next iteration been captured and validated?" guid="_kTZiACGMEdu3VKXZx45D3A">
+ <sectionDescription><ul>
+ <li>
+ Are functional requirements that affect multiple Use Cases identified? For example, all Use Cases may be subject to
+ access control, audit trail, general responses to abnormal situations (overflow, communication facilities, error
+ handling and recovery) and so on.
+ </li>
+ <li>
+ For each of these requirements, are they behavioral and better captured in a common Use Case?
+ </li>
+ <li>
+ For each of these functions, is it clear how input and shared data generate output and shared data?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_-eJXoCGMEdu5QMD9IAHRNg" name="Have Usability requirements that will be implemented in the next iteration been captured and validated?" guid="_-eJXoCGMEdu5QMD9IAHRNg">
+ <sectionDescription><ul>
+ <li>
+ Have the efficiency and usability factors of user tasks been considered?&nbsp;
+ </li>
+ <li>
+ Are the requirements specified in a way that is verifiable, including metrics and target values?
+ </li>
+ <li>
+ Have&nbsp;novice as well as expert users been considered?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_QCbtwCGNEdubdKsr57an1g" name="Have Reliability requirements that will be implemented in the next iteration been captured and validated?" guid="_QCbtwCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Have reliability requirements been specified as measurable requirements or prioritized design goals?
+ </li>
+ <li>
+ Is error checking and recovery required?
+ </li>
+ <li>
+ Are undesired events considered and their required responses specified?
+ </li>
+ <li>
+ Are initial or special states considered (such as cold starts or abnormal termination)?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_e3pOgCGNEdubdKsr57an1g" name="Have Performance requirements that will be implemented in the next iteration been captured and validated?" guid="_e3pOgCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Have the resource and performance margin requirements been stated (speed, response time, recovery time of various
+ software functions)?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_l8CeUCGNEdubdKsr57an1g" name="Have Supportability requirements that will be implemented in the next iteration been captured and validated?" guid="_l8CeUCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Are there any requirements that will enhance the supportability or maintainability of the system being built?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_wIttsCGNEdubdKsr57an1g" name="Have Constraints that must be considered in the next iteration been captured and validated?" guid="_wIttsCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Are there any required standards in effect, implementation language, policies for database integrity, resource
+ limits, operating environment(s), etc.?
+ </li>
+ <li>
+ Has the use of inherited design or code or pre-selected tools been specified?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_5j6c0CGNEdubdKsr57an1g" name="Have External Interfaces that must be considered in the next iteration been identified?" guid="_5j6c0CGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Is it clear how the software interacts with people, the system's hardware, other hardware, and other software?
+ </li>
+ <li>
+ Have all critical data elements that cross system boundaries been identified for those scenarios that will be
+ implemented in the next iteration?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_H052MCGOEdubdKsr57an1g" name="Have Business Rules that will be implemented in the next iteration been captured and validated?" guid="_H052MCGOEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Are the rules relevant to the use cases identified (data validation rules, formulas, flow decisions)?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_NBM78CGOEdubdKsr57an1g" name="Have applicable Standards and Regulatory Compliance requirements that must be considered in the next iteration been identified?" guid="_NBM78CGOEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Have all requirements derived from existing standard and regulations been specified?
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/test_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/test_case.xmi
new file mode 100644
index 0000000..eca756f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/test_case.xmi
@@ -0,0 +1,53 @@
+<?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" epf:version="1.0.0" xmi:id="_kwHAgMPbEdmbOvqy4O0adg" name="test_case,_0Zxf8MlgEdmt3adZL5Dmdw" guid="_kwHAgMPbEdmbOvqy4O0adg" changeDate="2005-07-07T16:45:15.861-0400" version="1.0.0">
+ <sections xmi:id="_yXujsLcOEduFFo_97woSMw" name="General" guid="_yXujsLcOEduFFo_97woSMw">
+ <sectionDescription><ul>
+ <li>
+ Does the Test Case identify the requirement it evaluates?&nbsp; This linking might be informal through a naming
+ convention or formalized through a requirements traceability matrix.
+ </li>
+ <li>
+ Does the Test Case reference the preconditions and postconditions that apply to it?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_Hv2n0BBbEduXULqRagzBHA" name="Name" guid="_Hv2n0BBbEduXULqRagzBHA">
+ <sectionDescription><ul>
+ <li>
+ Is the&nbsp;Test Case name unique?
+ </li>
+ <li>
+ Does&nbsp;the name express a test condition or&nbsp;an expected result?
+ </li>
+ <li>
+ Is&nbsp;it unambiguous to a stakeholder?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_3i-gkLcOEduFFo_97woSMw" name="Brief Description" guid="_3i-gkLcOEduFFo_97woSMw">
+ <sectionDescription><ul class="noindent">
+ <li>
+ Is the logical test condition clearly identified in the description?
+ </li>
+ <li>
+ Does the description clearly&nbsp;state the expected result?
+ </li>
+ <li>
+ Is the expected result stated as a concrete&nbsp;outcome?
+ </li>
+ <li>
+ Can a casual reader distinguish this Test Case from a similar one?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_4uresLcOEduFFo_97woSMw" name="Test Data Needs" guid="_4uresLcOEduFFo_97woSMw">
+ <sectionDescription><ul>
+ <li>
+ Does the Test Case note the kinds of test data required to implement a detailed Test Script?
+ </li>
+ <li>
+ Are&nbsp;the test data type, uniqueness, and quality sufficiently explained?
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/test_script.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/test_script.xmi
new file mode 100644
index 0000000..f051632
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/test_script.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="_4LuPMMPcEdmbOvqy4O0adg" name="test_script,_0Z9tMMlgEdmt3adZL5Dmdw" guid="_4LuPMMPcEdmbOvqy4O0adg" changeDate="2005-07-26T16:21:21.082-0400" version="1.0.0">
+ <sections xmi:id="_DiPTsE_cEduqM_QlWBlZ_g" name="Does the test script conform to the related test case" guid="_DiPTsE_cEduqM_QlWBlZ_g">
+ <sectionDescription>Ensure that the test script conforms to the specification established in the test case if one is associated with the test
+script.&nbsp; The test case captures the intent of the test; the test script must conform to this intent.</sectionDescription>
+ </sections>
+ <sections xmi:id="_KS930Bg9EduxCP6DVVLxsA" name="Is the test script testable" guid="_KS930Bg9EduxCP6DVVLxsA"/>
+ <sections xmi:id="_H-q58Bg9EduxCP6DVVLxsA" name="Is the test script reusable" guid="_H-q58Bg9EduxCP6DVVLxsA">
+ <sectionDescription>Ensure that your test scripts can be reused by designing your test scripts to maximize reuse.&nbsp; Promoting reuse takes
+different forms depending on whether you are generating, programming, or recording test scripts.</sectionDescription>
+ </sections>
+ <sections xmi:id="_5_92wE_cEduqM_QlWBlZ_g" name="Is the test script prescriptive and unambiguous" guid="_5_92wE_cEduqM_QlWBlZ_g">
+ <sectionDescription>Ensure that the test script represents clear instructions on how the test must be run and how the results should be
+analyzed.&nbsp; While non-automated tests can be written in such a way that the tester can have leeway in how the test is
+precisely run, there is no room for creativity in how the test results are to be analyzed for success or failure.</sectionDescription>
+ </sections>
+ <sections xmi:id="_La5wQBg9EduxCP6DVVLxsA" name="Is the test script named consistently with your other test work products" guid="_La5wQBg9EduxCP6DVVLxsA">
+ <sectionDescription>Ensure that the naming of your test scripts is consistent with other test-related work products.&nbsp; For example, if you
+are creating test classes for each of your test cases, ensure that the naming represents this relationship.&nbsp;
+Alternatively, if you are building test scripts inside of a library, use a consistent naming convention to reflect the
+library or libraries.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Ng5zcBg9EduxCP6DVVLxsA" name="Does your test script provide test coverage" guid="_Ng5zcBg9EduxCP6DVVLxsA">
+ <sectionDescription>Ensure that your test scripts provide test coverage consistent with the system under test.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/uc_model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/uc_model.xmi
new file mode 100644
index 0000000..050988c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/uc_model.xmi
@@ -0,0 +1,92 @@
+<?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" epf:version="1.0.0" xmi:id="_MqODAMM1EdmSIPI87WLu3g" name="uc_model,_0U6OEMlgEdmt3adZL5Dmdw" guid="_MqODAMM1EdmSIPI87WLu3g" changeDate="2005-07-07T14:50:06.005-0400" version="1.0.0">
+ <sections xmi:id="_rLdVMAeREduWycDgioo5rg" name="Is it easy to understand what the system does by reviewing the model?" guid="_rLdVMAeREduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ The Use-Case Survey provides a clear, concise overview of the purpose and functionality of the system.
+ </li>
+ <li>
+ There are no long chains of include relationships, such as when an included use case&nbsp;includes other use
+ cases.&nbsp; These can obscure comprehensibility.
+ </li>
+ <li>
+ Included use cases should not make assumptions about use cases that include them.
+ </li>
+ <li>
+ If several use cases contain similar&nbsp;sub-flows investigate if&nbsp;factoring this&nbsp;common behavior into an
+ included use case will simplify the model.&nbsp;
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="__kgR8AeREduWycDgioo5rg" name="Have all use cases been identified?" guid="__kgR8AeREduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ The use cases identified collectively account for all required behavior of the system.
+ </li>
+ <li>
+ All features identified in the Vision document for this iteration have been addressed by at least one use case.
+ </li>
+ <li>
+ All non-functional requirements that must be satisfied by a specific use case have been captured in that use case
+ </li>
+ <li>
+ The use-case model contains no superfluous behavior (gold-platting).
+ </li>
+ <li>
+ Each concrete use case must be associated with at least one actor.
+ </li>
+ <li>
+ Every actor should be associated with at least on use case.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_fknU0Jz1EduBcbjYtLtItQ" name="Is the model consistent?" guid="_fknU0Jz1EduBcbjYtLtItQ">
+ <sectionDescription><ul>
+ <li>
+ Under the same conditions, and with the same input, the system behavior should be consistent.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_KowpkAeSEduWycDgioo5rg" name="Are all relationships between use cases required?" guid="_KowpkAeSEduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ Each included use case should make the model easier to understand, implement and maintain.
+ </li>
+ <li>
+ Each concrete use case (i.e. not an included use case) should be independent of other use cases.
+ </li>
+</ul>
+<p>
+ <br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jyHeMAeTEduWycDgioo5rg" name="Are use-case packages used appropriately?" guid="_jyHeMAeTEduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ Cross-package dependencies have been reduced or eliminated to prevent model ownership conflicts
+ </li>
+ <li>
+ Packaging is intuitive and makes the model easier to understand and implement
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_i-S-ADeKEdu6VLD0YaVLog" name="Do all model elements have appropriate names?" guid="_i-S-ADeKEdu6VLD0YaVLog">
+ <sectionDescription><ul>
+ <li>
+ No two use cases can have the same name.
+ </li>
+ <li>
+ Each actor has a name that effectively describes the role.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_IYRUkJz2EduBcbjYtLtItQ" name="Are individual use cases properly specified?" guid="_IYRUkJz2EduBcbjYtLtItQ">
+ <sectionDescription><ul>
+ <li>
+ Review the quality of each&nbsp;use case specification using the <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html"
+ guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>.
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/use_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/use_case.xmi
new file mode 100644
index 0000000..f14699e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/use_case.xmi
@@ -0,0 +1,111 @@
+<?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" epf:version="1.0.0" xmi:id="-T2IeqdOunweffIDgL-aM0w" name="use_case,_0Vk8cMlgEdmt3adZL5Dmdw" guid="-T2IeqdOunweffIDgL-aM0w" authors="Paul Bramble" changeDate="2006-05-01T13:13:56.264-0400" version="0.1">
+ <copyrightStatement href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uuunoPsDEdmyhNQr5STrZQ"/>
+ <sections xmi:id="_663wMNk1Edq2Q8qZoWbvGA" name="Is the use-case name meaningful and un-ambiguous?" guid="_663wMNk1Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ Does the use case have a unique name?
+</p>
+<p>
+ Is the name a verb + noun phrase (for example, Withdraw Cash)?
+</p>
+<p>
+ Does the name accurately&nbsp;summarize the&nbsp;main goal&nbsp;of the use case?
+</p>
+<p>
+ Is the name "actor independent"?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_ZTA8QJznEduBcbjYtLtItQ" name="Does the brief description clearly describe the primary goal of the use case?" guid="_ZTA8QJznEduBcbjYtLtItQ">
+ <sectionDescription><p>
+ Is it clear from the brief description what the main purpose of the use case is?
+</p>
+<p>
+ Is the "observable result of value" obvious?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_4wJRgJznEduBcbjYtLtItQ" name="Are associated actors and information exchanged clearly defined?" guid="_4wJRgJznEduBcbjYtLtItQ">
+ <sectionDescription><p>
+ Is the use case associated with one or more actors?
+</p>
+<p>
+ Is the primary, or initiating actor, defined?
+</p>
+<p>
+ Is it clear who wishes to perform the use case?
+</p>
+<p>
+ Is all information exchanged between the actor(s) and the system clearly specified?
+</p>
+<p>
+ If a "time" actor is used, are you sure you did not miss an important actor and associated use cases (such as
+ administrative or maintenance personnel that define schedule events)?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Qys_INk2Edq2Q8qZoWbvGA" name="Are the pre-conditions specified?" guid="_Qys_INk2Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ Does each pre-condition represent a tangible&nbsp;state&nbsp;of&nbsp;the system (for example, the Withdraw Cash use
+ case for an automated teller machine has a precondition that the user has an account)?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_q3qV0Nk2Edq2Q8qZoWbvGA" name="Are the Basic Flow and Alternate Flows complete, correct and consistent?" guid="_q3qV0Nk2Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ Is it clear how the use case is started?
+</p>
+<p>
+ Is the triggering event clearly described?
+</p>
+<p>
+ Does the flow have a definite ending?
+</p>
+<p>
+ Does&nbsp;each step in the scenario contain&nbsp;the same level of abstraction?&nbsp;&nbsp;
+</p>
+<p>
+ Does each step in the scenario describe something that can actually happen and that the system can reasonably detect?
+</p>
+<p>
+ Does each step make&nbsp;progress towards the goal?
+</p>
+<p>
+ Are there any missing steps? Is it clear how to go from one step to the next? Does the sequence of communication
+ between the actors and the use case conform to the user's expectations?
+</p>
+<p>
+ Does each step describe how the step helps the actor achieve their goal?
+</p>
+<p>
+ Is each step technology independent? Is it free of technical details, and design decisions?
+</p>
+<p>
+ Are the steps correctly numbered?
+</p>
+<p>
+ For each alternate flow is the condition(s) for initiation of the flow clearly defined?
+</p>
+<p>
+ For each alternate flow is it clear how the use case ends or where in the basic flow that the use case resumes?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_dnLXMNk2Edq2Q8qZoWbvGA" name="Are the post-conditions specified?" guid="_dnLXMNk2Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ If "Minimal Guarantees" are present, do they always happen when the use case completes, regardless of success? (A
+ Minimal Guarantee represents&nbsp;a condition&nbsp;that will be true when the use case ends, regardless of how it
+ terminates.)
+</p>
+<p>
+ If "Success Guarantees" are present, do they always happen when the use case completes successfully? (A Success
+ Guarantee represents a condition that will be true when the use case ends successfully, regardless of which path it
+ takes.)
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_vkbMAJzrEduBcbjYtLtItQ" name="Are applicable non-functional requirements captured?" guid="_vkbMAJzrEduBcbjYtLtItQ">
+ <sectionDescription><p>
+ Are non-functional requirements (such as performance criteria) that are&nbsp;applicable to the&nbsp;use case captured
+ in the use case?
+</p>
+<p>
+ Are these non-functional requirements applicable to many use cases?&nbsp; It they are, consider capturing them in the
+ supporting requirements specification to simplify maintenance.
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/vision.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/vision.xmi
new file mode 100644
index 0000000..fe57d55
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/checklists/vision.xmi
@@ -0,0 +1,48 @@
+<?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" epf:version="1.0.0" xmi:id="_qktWQMM0EdmSIPI87WLu3g" name="vision,_0WoFUMlgEdmt3adZL5Dmdw" guid="_qktWQMM0EdmSIPI87WLu3g" changeDate="2005-07-07T16:30:32.042-0400" version="1.0.0">
+ <sections xmi:id="_VwoioAeiEduWycDgioo5rg" name="Have you fully explored what the problem behind the problem is?" guid="_VwoioAeiEduWycDgioo5rg">
+ <sectionDescription><p>
+ Make sure that you have found the root cause of the Stakeholder's problem or need. Often, Stakeholders define solutions
+ rather than stating the problem that they are experiencing or the pain they are experiencing. Subsequently, they may
+ not have identified the problem correctly or the correct solution for it.
+</p>
+<p>
+ For example, "We can't support customers who want to buy online" is better than "We need an on-line purchasing system".
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_dBs8gAeiEduWycDgioo5rg" name="Is the problem statement correctly formulated?" guid="_dBs8gAeiEduWycDgioo5rg">
+ <sectionDescription>Make sure that you have agreement on the problem to be solved.</sectionDescription>
+ </sections>
+ <sections xmi:id="_jGUxYAeiEduWycDgioo5rg" name="Is the list of Stakeholders complete and correct?" guid="_jGUxYAeiEduWycDgioo5rg">
+ <sectionDescription>Make sure you didn't miss any Stakeholders. If you did, you probably do not yet have all of the perspectives that you need
+to consider.</sectionDescription>
+ </sections>
+ <sections xmi:id="_s-be8AeiEduWycDgioo5rg" name="Does everyone agree on the definition of the system boundaries?" guid="_s-be8AeiEduWycDgioo5rg">
+ <sectionDescription>Define what is <strong>in</strong> and what is <strong>out</strong> of system boundaries. This is a critical step in
+defining the scope of work.</sectionDescription>
+ </sections>
+ <sections xmi:id="_z1uG4AeiEduWycDgioo5rg" name="Have you sufficiently explored constraints to put on the system?" guid="_z1uG4AeiEduWycDgioo5rg">
+ <sectionDescription>Don't forget about the non-functional requirements and constraints. These are often the largest cost of development.</sectionDescription>
+ </sections>
+ <sections xmi:id="_7KzeEAeiEduWycDgioo5rg" name="Have you covered all kinds of constraints, including political, economic, and environmental?" guid="_7KzeEAeiEduWycDgioo5rg">
+ <sectionDescription><p>
+ These non-technical constraints often lead to problems later.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_DymaUAejEduWycDgioo5rg" name="Have all key features of the system been identified and defined?" guid="_DymaUAejEduWycDgioo5rg">
+ <sectionDescription>Do a completeness check, comparing the features with the problem statement, to make sure that you didn't miss a critical
+feature.</sectionDescription>
+ </sections>
+ <sections xmi:id="_LRX5AAejEduWycDgioo5rg" name="Will the features solve the problems that are identified?" guid="_LRX5AAejEduWycDgioo5rg">
+ <sectionDescription>Are all the features really necessary?&nbsp; Perhaps you can reduce the scope.</sectionDescription>
+ </sections>
+ <sections xmi:id="_UGRdIAejEduWycDgioo5rg" name="Are the features consistent with constraints that you've identified?" guid="_UGRdIAejEduWycDgioo5rg">
+ <sectionDescription><p>
+ Check that conflicting requirements do not exist. If you find conflicts, resolve them now.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_5y4uAAhUEduRe8TeoBmuGg" name="Can someone who is not familiar with the project understand what you hope the project will achieve by reading the Vision document?" guid="_5y4uAAhUEduRe8TeoBmuGg">
+ <sectionDescription>The purpose of the Vision document is to describe the objectives of the project in terms that non-technical people, who are
+not closely involved with the project, can understand.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/actor.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/actor.xmi
new file mode 100644
index 0000000..7226c65
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/actor.xmi
@@ -0,0 +1,53 @@
+<?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" epf:version="1.0.0" xmi:id="-aN0zy068ovKHgmkkoYqoYQ" name=",_zGqO0MDpEduTGJ8i4u8TMw" guid="-aN0zy068ovKHgmkkoYqoYQ" changeDate="2007-02-20T08:56:57.450-0500">
+ <mainDescription><p>
+ To fully understand the system's purpose, you must know who the system is for, that is: Who will use the system? The
+ answer to this question is: the Actors.
+</p>
+<p>
+ An Actor is a role that a person or external system plays&nbsp;when interacting with the system.&nbsp; Instances of an
+ Actor can be an individual or an external system, however each Actor&nbsp;provides a
+ unique&nbsp;and&nbsp;important&nbsp;perspective on the system that is shared by every instance of the Actor.
+</p>
+<p>
+ This difference between an actor and an instance of an actor is illustrated below.&nbsp;&nbsp;Figure 1 shows a case in
+ which Ivar and Mark are operators of a recycling machine. When they are using the machine in this capacity, each is
+ represented by an instance of the actor called Operator that expects certain functionality of the system (Print Daily
+ Reports in this example).
+</p>
+<p>
+ <img height="322" alt="" src="./resources/md_acto2.gif" width="396" />&nbsp;
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <strong>Figure 1:&nbsp;Example Actor with multiple instances</strong>&nbsp;
+ </p>
+</blockquote>
+<p>
+ Conversely, the same user can act as several actors (that is, the same person can take on different roles). In Figure
+ 2, Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the Depot-Handling
+ System as an ordinary Depot Staff member. Each of these actors expects different functionality of the system.
+</p>
+<p>
+ <img height="139" alt="" src="./resources/md_acto3.gif" width="367" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <strong>Figure 2: Example of user playing different roles</strong><br />
+ </p>
+</blockquote>
+<p>
+ Actors help you to identify external interfaces and to determine the scope the system (what is in the system, vs. what
+ is outside the system boundary).&nbsp; Each&nbsp;Actor has associated use cases which describe what that
+ particular&nbsp;actor expects of the system.&nbsp; It will be very difficult, if not impossible,&nbsp;to assess the
+ completeness of the set of Use Cases without the context provided by the associated Actors. Furthermore, missing an
+ actor may result in&nbsp;missing important stakeholder perspectives, resulting&nbsp;in a solution that does not meet
+ all&nbsp;stakeholder needs.
+</p>
+<p>
+ Hence, identifying the Actors for the system&nbsp;should be done early in the lifecycle.&nbsp;&nbsp;Actors are
+ captured, including their names, brief descriptions, and relationships to use cases,&nbsp;in the <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/uc_model,_W2SgEDR5EdutE_HNDTJk5Q.html"
+ guid="_W2SgEDR5EdutE_HNDTJk5Q">Artifact: Use-Case Model</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/analysis_mechanism.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/analysis_mechanism.xmi
new file mode 100644
index 0000000..2abecc4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/analysis_mechanism.xmi
@@ -0,0 +1,74 @@
+<?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" epf:version="1.0.0" xmi:id="_S8KCcMP2EdmWKcx6ixEiwg" name="analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw" guid="_S8KCcMP2EdmWKcx6ixEiwg" changeDate="2007-02-26T13:44:38.859+0000" version="1.0.0">
+ <mainDescription><p>
+ An Analysis Mechanism is a conceptual representation of an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. Over time, Analysis Mechanisms are refined into <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s&nbsp;and, later, into <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/implementation_mechanism,_0LcUkA4LEduibvKwrGxWxA.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>s.
+</p>
+<p>
+ Analysis Mechanisms&nbsp;allow the developer to focus on understanding the requirements without getting distracted by
+ the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people
+ can better comprehend the problem.
+</p>
+<p>
+ Analysis Mechanisms are described in simple terms:
+</p>
+<ul>
+ <li>
+ <strong>Name:</strong> Identifies the mechanism.
+ </li>
+ <li>
+ <strong>Basic attributes:</strong> Define the requirements of the mechanism.
+ </li>
+</ul>
+<p>
+ You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as
+ you proceed.
+</p>
+<p>
+ In the top-down mode, experience guides the <a class="elementLink"
+ href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a>, who knows that certain problems are present in the domain and will
+ require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms
+ during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The
+ common aspect of all of these is that each is a general capability of a broad class of systems, and each provides
+ functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support
+ capabilities required in the basic functional requirements of the system, regardless of the platform that it is
+ deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different
+ ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may
+ also be more than one way of implementing each design mechanism.
+</p>
+<p>
+ The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the <a
+ class="elementLink" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> sees, perhaps faintly at first, a common theme emerging from a set of
+ solutions to various problems. For example: There is a need to provide a way for elements in different threads to
+ synchronize their clocks, and there is a need for a common way of allocating resources. <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>, which simplify the language of analysis, emerge from these
+ patterns.
+</p>
+<p>
+ Identifying an Analysis Mechanism means that you identify a common, perhaps implicit&nbsp;subproblem, and you give it a
+ name. Initially, the name might be all that exists. For example, the system will require a persistence
+ mechanism.&nbsp;Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
+ which do not deliver application functionality directly, but exist only to support it. Very often these support classes
+ are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
+ application-level classes.
+</p>
+<p>
+ If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be
+ instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis
+ Mechanism produced this way will be abstract, and it will require further refinement throughout design and
+ implementation work.
+</p>
+<p>
+ You can see examples of how Architectural Mechanisms can be represented in <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/example_analysis_mechanisms_descr,_4k_HsA4LEduibvKwrGxWxA.html"
+ guid="_4k_HsA4LEduibvKwrGxWxA">Example Analysis Mechanism Descriptions</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/arch_mech.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/arch_mech.xmi
new file mode 100644
index 0000000..17a9f77
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/arch_mech.xmi
@@ -0,0 +1,105 @@
+<?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" epf:version="1.0.0" xmi:id="-SJrpVySJ2npYs8NwGvnHjw" name="arch_mech,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson" changeDate="2007-02-26T13:36:32.171+0000" changeDescription="Simplified text explaining mechanism concept" version="1.0.0">
+ <mainDescription><p>
+ Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements.&nbsp;When fully described,
+ Architectural Mechanisms show patterns of structure and behavior in the software. They&nbsp;form the basis
+ of&nbsp;common software&nbsp;that will be&nbsp;consistently applied&nbsp;across the product being developed. They also
+ form the basis for standardizing the way that the software works; therefore, they are an important element of the
+ overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing
+ software components can be leveraged to provide the required behaviour; or whether new software should be bought or
+ built.
+</p>
+<p>
+ The key point to take on board when discussing architecture mechanisms is that the defining them is all about making
+ choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about
+ producing detailed design or software. This is a common misunderstanding. The creation of detailed design
+ and&nbsp;software that&nbsp;shows&nbsp;*how* specific mechanisms&nbsp;are satisfied&nbsp;is&nbsp;a development task.
+</p>
+<p>
+ The value in defining architecture mechanisms is that it
+</p>
+<ol>
+ <li>
+ explicitly calls out&nbsp;aspects of the solution mechanics that are common across the system. This aids planning.
+ </li>
+ <li>
+ puts down markers for the developers to build those aspects of the system once and then re-use them. This reduces
+ the workload.
+ </li>
+ <li>
+ promotes the development of a consistent set of services. This makes the system easier to maintain.
+ </li>
+</ol>
+<p>
+ An&nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&nbsp;These
+ categories&nbsp;reflect the state of the architectural mechanism over time. The state changes as successive levels of
+ detail are uncovered during the refinement of architecturally significant requirements into working software. The
+ categories are summarized in the table that follows.
+</p>
+<strong>States of an Architectural Mechanism</strong>
+<table style="WIDTH: 806px; HEIGHT: 228px" cellspacing="0" cellpadding="2" width="806"
+summary="Types of Architectural Mechanism" border="1">
+ <tbody valign="top">
+ <tr>
+ <th scope="col">
+ State
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Analysis
+ </td>
+ <td>
+ A conceptual solution to a common technical problem. For example,&nbsp;persistence is an abstract solution
+ to the common requirement to store data. The purpose of this category is simply to identify the need for an
+ Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Design
+ </td>
+ <td>
+ A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this
+ category is to enable initial design specifications to be produced and to guide precise product or
+ technology selection.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Implementation
+ </td>
+ <td>
+ <p>
+ A further refinement of a Design Mechanism into a&nbsp;specific technology or product that implements
+ the required Architectural Mechanism. For example, MySQL, as a database product, implements the
+ Analysis Mechanism <strong>Persistence</strong> and Design Mechanism <strong>RDBMS.</strong>
+ </p>
+ <p>
+ This essentially represents the point at which the decision is made to re-use, buy or build specific
+ software to provide the services defined by the mechanism.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<p>
+ Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
+ mechanisms.&nbsp;These are synonyms and merely represent the architecture mechanisms in different states of
+ development. The transition from one state to another&nbsp;can often be obvious or intuitive. Therefore, it can be
+ achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The
+ following diagram illustrates the transition of Architectural Mechanisms from one state to another.
+</p>
+<p>
+ <strong>State Machine for Architectural Mechanisms</strong>
+</p>
+<p>
+ <img style="WIDTH: 876px; HEIGHT: 115px" height="113" alt="Architectural Mechanism States"
+ src="./resources/ArchMechanismsStatemachine.JPG" width="600" />&nbsp;<br />
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/architecturally_significant_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/architecturally_significant_requirements.xmi
new file mode 100644
index 0000000..d50e0fd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/architecturally_significant_requirements.xmi
@@ -0,0 +1,22 @@
+<?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="-EytH4BCNGiHF6pZrp8ISCw" name="new_concept,_eFElAOK2EdqHEo0wLIc5jg" guid="-EytH4BCNGiHF6pZrp8ISCw" authors="Mark Dickson" changeDate="2006-07-07T04:53:04.786-0700" changeDescription="First Draft" version="1.0">
+ <mainDescription><p> Not all requirements have equal significance in the architecture.&nbsp;Some
+ play an important role in determining the architecture of the
+ system, but others do not. </p>
+<p> Deciding whether a specific requirement is architecturally significant is
+ often a matter of judgment. Typically, these are requirements that are
+ technically challenging, technically constraining, or central to the
+ system's purpose. </p>
+<p> These are good examples of Architecturally Significant Requirements:</p>
+
+<ul>
+ <li> The system must record every modification to customer records for audit
+ purposes.</li>
+ <li> The system must respond within 5 seconds.</li>
+ <li> The system must&nbsp;deploy on Microsoft Windows XP and Linux. </li>
+ <li> The system must encrypt all network traffic.</li>
+ <li> The ATM system must dispense cash on&nbsp;demand&nbsp;to validated account
+ holders with sufficient cleared funds.</li>
+</ul>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/business_pattern.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/business_pattern.xmi
new file mode 100644
index 0000000..05323f8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/business_pattern.xmi
@@ -0,0 +1,22 @@
+<?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="-Of51hmgdsO_U2-pnbJ67Cg" name="new_concept,_RoSdMBWYEduCK502eDgjUQ" guid="-Of51hmgdsO_U2-pnbJ67Cg" changeDate="2006-07-21T11:59:56.413-0700">
+ <mainDescription><p> Business Patterns are a form of Design Pattern&nbsp;(see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>) and are the business-domain
+ counterpart of <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/architecture_mechanism,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>. Just as
+ similar problems in the technical domain may be solved by using Architecture
+ Mechanisms, similar problems in the business domain can be solved by using Business
+ Patterns. </p>
+<p> Business Patterns are often found in COTS products. For example, packaged
+ applications that support Enterprise Resource Planning or Customer Relationship
+ Management ship with functionality to support a variety of generic business
+ processes. Similarly, it is frequently possible to identify related or similar
+ behavior in the Use Case&nbsp;Scenarios&nbsp;and thereby derive generic designs
+ that you can use in the design of the system. These elements of generic behavior
+ can be&nbsp;expressed as Design&nbsp;Patterns and applied to the system design.
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/change_requests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/change_requests.xmi
new file mode 100644
index 0000000..7185661
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/change_requests.xmi
@@ -0,0 +1,15 @@
+<?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" epf:version="1.0.0" xmi:id="-BsXK3ZGMm-mUT0KnkdoYBg" name="change_requests,_6jdvECb3Edqh1LYUOGRh2A" guid="-BsXK3ZGMm-mUT0KnkdoYBg" changeDate="2007-02-22T15:13:54.919-0500">
+ <mainDescription><p>
+ A change request represents any request to change a work product. This includes items commonly called defect reports,
+ enhancement requests, requirements change request, implementation requests, and stakeholder requests.
+</p>
+<p>
+ In this process, change request are captured in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/work_items_list,_7vEXEMA4EdqSgKaj2SZBmg.html"
+ guid="_7vEXEMA4EdqSgKaj2SZBmg">Guideline: Work Items List</a>&nbsp;for more information on the recommended
+ attributes&nbsp;of change requests.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/coding_standard.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/coding_standard.xmi
new file mode 100644
index 0000000..37fa9f7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/coding_standard.xmi
@@ -0,0 +1,25 @@
+<?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" epf:version="1.0.0" xmi:id="-vlYpfwIYlF_ZCk5s4Dsqdg" name="new_concept,_0lnRMMqOEduwrYVlQ9zp3w" guid="-vlYpfwIYlF_ZCk5s4Dsqdg" changeDate="2007-03-04T15:29:08.886-0500">
+ <mainDescription><p>
+ Using a coding standard is a software development practice that has been widely accepted in the industry. The need for
+ this practice takes on added importance in&nbsp;a highly collaborative environment. The team should have a standard way
+ of naming and formatting things so they can understand the code quickly and know where to look at all times.
+</p>
+<p>
+ Ideally, the coding standard should be the result of team consensus. In some cases, decisions will be arbitrary (like
+ how much to indent). Each item in the standard should support one or more goals, improved communication being one of
+ the most critical goals. Once the team agrees on a standard, all members of the teams are expected to follow it. With
+ time, the team will use and modify the standard to develop a style that is well adapted to their environment.
+</p>
+<p>
+ Benefits
+</p>
+<ul>
+ <li>
+ Improved communication: increases the ability to read each other's code.
+ </li>
+ <li>
+ Refactoring support: provides consistently shaped code.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/component.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/component.xmi
new file mode 100644
index 0000000..767b163
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/component.xmi
@@ -0,0 +1,99 @@
+<?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" epf:version="1.0.0" xmi:id="_TZiasMM1EdmSIPI87WLu3g" name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2007-01-23T11:49:37.968+0000" version="1.0.0">
+ <mainDescription><p align="left">
+ The software industry and literature use the term <strong>componen</strong>t to refer to many different things. It is
+ often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote
+ specific characteristics that enable replacement and assembly in larger systems.
+</p>
+<p align="left">
+ Here. we use <em>component</em> to mean <strong>an encapsulated part of a system</strong> that is, ideally, a
+ nontrivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of
+ well-defined architecture. This includes two types of components:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Design component.</strong> A significant encapsulated part of the design that includes design
+ subsystems and, sometimes, significant design classes and design packages.
+ </p>
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Implementation component.</strong> A significant encapsulated part of the implementation, generally
+ code that implements a design component.
+ </p>
+ </div>
+ </li>
+</ul>
+<p align="left">
+ Ideally, the design reflects the implementation; therefore, you can simply refer to <em>components</em>, with each
+ component having a design and an implementation.
+</p>
+<h4 align="left">
+ Component replaceability
+</h4>
+<p align="left">
+ In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
+ interfaces that hide an underlying implementation.
+</p>
+<p align="left">
+ There are other, stronger, kinds of replaceability: .
+</p>
+<div align="left">
+ <ul>
+ <li>
+ <p>
+ <strong>Source file replaceability:</strong> If two classes are implemented in a single source code file,
+ then those classes cannot usually be separately versioned and controlled. However, if a set of files fully
+ implements a single component (and no other component), then the component source files are replaceable.
+ This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
+ source file.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Deployment replaceability:</strong> If two classes are deployed in a single executable file, then
+ each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
+ components to be replaceable during deployment, which allows new versions of the component to be deployed
+ without having to rebuild the other components. This usually means that there is one file or one set of
+ files that deploy the component, and no other component.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Run-time replaceability:</strong> If a component can be redeployed into a running system, then it
+ is referred to as <em>run-time replaceable</em>. This enables you to upgrade software without loss of
+ availability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Location transparency:</strong> Components with network-addressable interfaces are referred to as
+ having <em>location transparency</em>. This allows components to be relocated to other servers or to be
+ replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of
+ components are often referred to as <em>distributed</em> or <em>distributable</em> components.
+ </p>
+ </li>
+ </ul>
+</div>
+<h4 align="left">
+ Component instantiation
+</h4>
+<p align="left">
+ A component may or may not be directly instantiated at run time.
+</p>
+<p align="left">
+ An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
+ component itself does not appear in the implementation; it merely serves as a design that an implementation must
+ follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
+ provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
+</p>
+<p align="left">
+ A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
+ object, which means that a design component has a corresponding construct in the implementation language; therefore, it
+ can be referenced explicitly.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/component_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/component_vm.xmi
new file mode 100644
index 0000000..250a29a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/component_vm.xmi
@@ -0,0 +1,119 @@
+<?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" epf:version="1.0.0" xmi:id="-zfl87vJBFdinDB02ArLXOQ" name="new_concept,_HZGFsKrPEdu6T6WyNqBzqQ" guid="-zfl87vJBFdinDB02ArLXOQ" changeDate="2007-01-23T11:48:34.453+0000">
+ <mainDescription><p align="left">
+ The Unified Modeling Language [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">UML05</a>] defines <em>component</em> as follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p>
+ A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment. A component defines its behavior in terms of provided and required interfaces. As such, a
+ component serves as a type, whose conformance is defined by these provided and required interfaces
+ (encompassing both their static as well as dynamic semantics). (See <strong>UML representation</strong> at the
+ end of this section for definitions from earlier versions of UML.)
+ </p>
+ <p>
+ A <em>component</em> is defined as a subtype of structured class. Therefore, a component has attributes and
+ operations, is able to participate in associations and generalizations, and has internal structure and ports.
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ A number of UML standard stereotypes exist that apply to components, including &lt;&lt;subsystem&gt;&gt; to model
+ large-scale components, and &lt;&lt;specification&gt;&gt; and &lt;&lt;realization&gt;&gt; to model components with
+ distinct specification and realization definitions, where one specification may have multiple realizations.
+</p>
+<p align="left">
+ Here, we use&nbsp;the term <em>component&nbsp;</em>in a&nbsp;broader way than the UML definition. Rather than defining
+ components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
+ as desirable characteristics of components. See the section on Component Replaceability.
+</p>
+<h4 align="left">
+ Modeling of components
+</h4>
+<p align="left">
+ The UML component is a modeling construct that provides the following capabilities:
+</p>
+<div align="left">
+ <ul>
+ <li>
+ Group classes to define a larger granularity part of a system
+ </li>
+ <li>
+ Separate the visible interfaces from internal implementation
+ </li>
+ <li>
+ Execute instances run-time
+ </li>
+ </ul>
+</div>
+<p align="left">
+ A component includes <strong>provided</strong> and <strong>required</strong> interfaces that form the basis for wiring
+ components together. A <strong>provided interface</strong> is one that is either implemented directly by the component
+ or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A
+ <strong>required interface</strong> is designated by a usage dependency of the component or one of its realizing
+ classes or subcomponents, or it is the type of a required port.
+</p>
+<p align="left">
+ A component has an external view (or <em>black box</em> view) through its publicly visible properties and operations
+ .Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component
+ itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls
+ explicit. The wiring between components in a system or other context can be structurally defined by using dependencies
+ between component interfaces (typically on component diagrams).
+</p>
+<p align="left">
+ Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in
+ composite structures to specify the role or instance-level collaboration between components. That is the component's
+ internal view (or <em>white-box</em> view) through its private properties and realizing classes or subcomponents. This
+ view shows how the external behavior is realized internally. The mapping between external and internal views is by
+ dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.
+</p>
+<p align="left">
+ The recommendation is to&nbsp;use components as the representation for design subsystems.
+</p>
+<h4 align="left">
+ UML representation
+</h4>
+<p align="left">
+ The definition of <em>component</em> with the UML has changed over time with the release of different versions. The
+ version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the
+ definitions from 1.3 to 2.0 are provided here.
+</p>
+<p align="left">
+ UML 2.0 defined <em>component</em> as the following:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p align="left">
+ ...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment.
+ </p>
+ <p align="left">
+ A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a
+ type whose conformance is defined by these provided and required interfaces (encompassing both their static as
+ well as dynamic semantics).
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ UML 1.5 defined <em>component</em> as the following:
+</p>
+<blockquote>
+ <blockquote>
+ <div align="left">
+ A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of
+ interfaces. A component is typically specified by one or more classes or subcomponents that reside on it and
+ may be implemented by one or more artifacts (e.g., binary, executable, or script files).
+ </div>
+ <div align="left">
+ <p>
+ In UML 1.3 and earlier versions of the UML, the component notation was used to represent files in the
+ implementation. Files are no longer considered components by the latest UML definitions. However, many
+ tools and UML profiles still use the component notation to represent files.
+ </p>
+ </div>
+ </blockquote>
+</blockquote></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/construction_phase.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/construction_phase.xmi
new file mode 100644
index 0000000..931d9cc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/construction_phase.xmi
@@ -0,0 +1,89 @@
+<?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" epf:version="1.0.0" xmi:id="-bbpT_BdDRrv6waNI365Qhg" name=",_48EKsBOMEduCNqgZdt_OaA" guid="-bbpT_BdDRrv6waNI365Qhg" changeDate="2006-09-29T13:10:26.950-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose in this phase is to complete the development of the system based upon the baselined architecture.
+</p>
+<p>
+ There are objectives for the Construction phase that help us to&nbsp;have cost-efficient development of a complete
+ product - an operational version of your system - that can be deployed&nbsp;in the user community&nbsp;<a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ Iteratively develop a complete product that is ready to transition to its user community. Describe remaining
+ requirements, fill in design details, complete the implementation and test the software. Release the first
+ operational version (beta) of the system and determine if users are ready for the application to be deployed.
+ </li>
+ <li>
+ Minimize development costs and achieve some degree of parallelism. Optimize resources and leverage development
+ parallelism between developers or teams of developers, by for example, assigning components that can be developed
+ independently of one another.
+ </li>
+</ol>
+<p>
+ The following table summarizes the&nbsp;Construction phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <br />
+ <strong>Construction phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Iteratively develop a complete product that is ready to transition to the user community<br />
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/manage_requirements,_eE5nEUbpEduLBN1xMBngqw.html" guid="_eE5nEUbpEduLBN1xMBngqw">Manage Requirements</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/develop_solution,_MWFjoU9HEdudU75l2xOQTw.html" guid="_MWFjoU9HEdudU75l2xOQTw">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/validate_build,_y-3IretQEdqc1LGhiSPqRg.html" guid="_y-3IretQEdqc1LGhiSPqRg">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Minimize development costs and achieve some degree of parallelism<br />
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/develop_solution,_MWFjoU9HEdudU75l2xOQTw.html" guid="_MWFjoU9HEdudU75l2xOQTw">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/validate_build,_y-3IretQEdqc1LGhiSPqRg.html" guid="_y-3IretQEdqc1LGhiSPqRg">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of
+ projects:
+</p>
+<ul>
+ <li>
+ Simple project: One iteration to build the product (to a beta release)
+ </li>
+ <li>
+ More substantial project: One iteration to expose a partial system and one to mature it to beta testing
+ </li>
+ <li>
+ Large project: Three or more iterations, given the size of the project (number of requirements to implement for a
+ beta release)
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/continuous_integration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/continuous_integration.xmi
new file mode 100644
index 0000000..5415cc9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/continuous_integration.xmi
@@ -0,0 +1,35 @@
+<?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="-dhAMzNZNWufBnW0fPYQtBA" name="continuous_integration,_NApSVdtxEdq7ovUqqSoGBQ" guid="-dhAMzNZNWufBnW0fPYQtBA" changeDate="2006-08-21T14:39:56.533-0400">
+ <mainDescription><p>
+ Continuous integration is an implementation practice where team members compile and test (integrate) their work
+ frequently (at least daily). Integration errors should be detected as quickly as possible, either from compiler errors
+ or errors reported by&nbsp;the test suite. Ideally the integration is done automatically when an updated version of
+ source code is checked into&nbsp;the configuration management system.
+</p>
+<p>
+ Benefits:
+</p>
+<ol>
+ <li>
+ Improved error detection.&nbsp; Continuous integration enables you to detect and address errors early, often
+ minutes after they’ve been injected into the product.&nbsp; Note that you still need a good test suite.
+ </li>
+ <li>
+ Improved system integration.&nbsp; By integrating continuously throughout your project you know that you can
+ actually build it, thereby mitigating integration surprises at the end of the lifecycle.
+ </li>
+ <li>
+ Reduced technical risk.&nbsp; You always have an up-to-date system against which to test.
+ </li>
+ <li>
+ Reduced management risk.&nbsp; By continuously integrating your system you know exactly how much functionality that
+ you’ve built to date, improving your ability to predict when and if you’re actually going to be able to deliver the
+ necessary functionality.
+ </li>
+ <li>
+ Improved collaboration.&nbsp; Continuous integration enables team members to work together safely.&nbsp; They know
+ that they can make a change to their code, integrate the system, and determine very quickly whether or not their
+ change worked.<br />
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_balance.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_balance.xmi
new file mode 100644
index 0000000..34eab13
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_balance.xmi
@@ -0,0 +1,152 @@
+<?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" epf:version="1.0.0" xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" name="core_principle_balance,_ssG6MMvpEdqukPpotm3DYg" guid="-I4IbR1GW6IFBCdq9SiMUsw" changeDate="2006-09-27T16:34:53.658-0700" changeDescription="Removed metaphoric photo Removed open_up from page name." version="0.02">
+ <mainDescription><h3 style="MARGIN: 12pt 0in 3pt">
+ Introduction
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ Systems are rarely all things to all people. Often, attempts to make them so are wasteful and result in bloated
+ systems.
+</p>
+<p>
+ Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes stakeholder
+ benefits and complies with constraints placed on the project. Achieving balance is a dynamic process because as both
+ the stakeholders and project participants learn more about the system, their priorities and constraints change.
+</p>
+<p>
+ To be successful, stakeholders and the project participants must converge on a clear understanding and agreement of
+ these three factors:
+</p>
+<ul>
+ <li>
+ Problem to be solved
+ </li>
+ <li>
+ Constraints places on the development team (cost, schedule, resources, regulations)
+ </li>
+ <li>
+ Constraints placed on the solution
+ </li>
+</ul>
+<p>
+ Collectively, these three items represent the requirements for the development of the system. The challenge for all
+ project participants is creating a solution that maximizes value delivered to the stakeholders, subject to the
+ constraints. Balance is about making the critical cost-benefit trade-offs between desired features and the subsequent
+ design decisions that define the a<span>rchitecture of the system.</span>
+</p>
+<p>
+ Discovering the balance point is challenging, elusive, and ongoing, because the balance point is dynamic. As the system
+ evolves, stakeholder needs change, new opportunities appear, risks are resolved, new risks appear, and the development
+ team discovers new realities about the system. Change happens throughout the development cycle. Therefore, stakeholders
+ and developers must be prepared to re-evaluate commitments, reset expectations, and adjust plans accordingly as the
+ system evolves.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Know your audience
+</h4>
+<p>
+ You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want.
+</p>
+<p>
+ Therefore, know your stakeholders. Better yet, work closely with them to ensure that you know their needs. Start by
+ identifying all stakeholders, and then maintain open and frequent communication and collaboration between them and the
+ development team.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Separate the problem from the solution
+</h4>
+<p>
+ Too often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve
+ problems, not how to define problems, so that's easier. However, this limits our understanding of the problem, imposes
+ artificial constraints,&nbsp;and makes it difficult to balance trade-offs, or to even know what the trade-offs are.
+</p>
+<p>
+ Therefore, make sure that you understand the problem before you define the solution. By clearly separating the problem
+ (what the customer needs) from the solution (what the system must do), it is easier to maintain the proper focus and
+ easier to accommodate alternate ways of solving the problem.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Create a shared understanding of the domain
+</h4>
+<p>
+ Domain experts often have limited technical expertise; developers, architects and testers often have limited domain
+ expertise; and reviewers and other stakeholders often have limited time to commit to the project and learn the problem
+ domain. As a result, people often have an inconsistent or poor understanding of the problem domain, which causes
+ communication problems and increases the likelihood of delivering poor value to the stakeholders.
+</p>
+<p>
+ Therefore, enhance and share all parties’ understandings of the domain. A concise and shared understanding of the
+ problem domain enhances communication and project effectiveness. Start by defining the problem in the Vision document.
+ As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent
+ shared use of the language of the domain.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Use scenarios and use cases to capture requirements
+</h4>
+<p>
+ Many companies still document requirements as a list of declarative statements, which are sometimes called the ”shall
+ statements.” These lists are often difficult for stakeholders to understand, because they require the end user to read
+ through and mentally translate the list into a visualization of how the requirements will interact with the system. .
+</p>
+<p>
+ Therefore, use scenarios and use cases to capture functional requirements in a form that is easy for stakeholders to
+ understand. Nonfunctional requirements, such as performance, stability, or usability requirements, are important and
+ can be documented in the Supporting Requirements, using traditional techniques.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Establish and maintain agreement on priorities
+</h4>
+<p>
+ Making poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that are
+ never used, or identifying problems late in the project that result in delays and even project failure.
+</p>
+<p>
+ Therefore, prioritize requirements for implementation by regularly working with the stakeholders during product
+ evolution. Make choices that deliver value and reduce risks, while building a system that can evolve.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Make the trade-offs to maximize value
+</h4>
+<p>
+ Cost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the
+ system to the stakeholder, while architecture establishes the cost. The cost of a benefit may influence the
+ stakeholder's perceived value of the benefit.
+</p>
+<p>
+ Therefore, work with the stakeholders and developers to prioritize requirements and develop candidate architectures to
+ implement those solutions. Use the candidate architectures to evaluate the cost of the benefits. Candidate solutions
+ are considered at a high level when determining architectural feasibility. Different architectural perspectives can
+ result in different assessment of cost versus benefit. The&nbsp;candidate architecture&nbsp;that provides the most
+ coverage at the lowest cost is selected for further development.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Manage scope
+</h4>
+<p>
+ Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change will
+ result in a bloated, deficient system and unmet stakeholder needs.
+</p>
+<p>
+ Therefore, manage change while maintaining the agreements with the stakeholders. Modern processes always manage change,
+ continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making
+ trade-offs, and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned throughout
+ the development lifecycle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Know when to stop
+</h4>
+<p>
+ Over-engineering a system not only wastes resources but also leads to an overly complex system.
+</p>
+<p>
+ Therefore, stop developing the system when the desired quality is achieved. Remember that “Quality is conformance to
+ the requirements” <a href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[CRO79]</a>. This is what gives a sense of closure to the practice. Separate the problem
+ from the solution, ensuring that the solution does, indeed, solve the problem. After the critical requirements are
+ implemented and validated, the system is ready for stakeholder acceptance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_collaborate.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_collaborate.xmi
new file mode 100644
index 0000000..1432696
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_collaborate.xmi
@@ -0,0 +1,142 @@
+<?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" epf:version="1.0.0" xmi:id="-IXfkG-XfnoEo0xgux482Kw" name="core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA" guid="-IXfkG-XfnoEo0xgux482Kw" authors="Steve Adolph" changeDate="2006-09-27T16:35:17.403-0700" changeDescription="Initial Version |Removed metaphoric photo. Removed "Don't go dark" collaborative practice.|Removed metaphoric photo. Removed "Don't go dark" collaborative practice. Removed open_up from page name.|Added "organize around the architecture practice"" version="0.03">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Software is created by people with different interests and skills who must work together to create software
+ effectively.
+</p>
+<p>
+ Therefore, develop practices that foster a healthy team environment. A healthy team environment enables effective
+ collaboration, which aligns the interests of project participants (development team, quality assurance, product
+ stakeholders, customers) and helps project participants develop a shared understanding of the project.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Maintain a common understanding
+</h4>
+<p>
+ Project participants require a common understanding of a project to cooperate effectively. Otherwise, disorder sets in,
+ because the team members cannot align their understanding and interests and will work with different purposes.
+</p>
+<p>
+ Be proactive communicating and sharing information with project participants and do not assume that everyone will just
+ find what they need to know or that each person has the same understanding of the project as everyone else. Use work
+ products, such as the Vision, Work Items List, and Requirements to align the understanding between the stakeholders and
+ developers. Use the architecture to focus and align the interests of the developers. At the end of each iteration, get
+ agreement on whether the iteration goals have been reached, and, if not, what actions must be taken.
+</p>
+<h4 style="MARGIN: auto 0in">
+ Foster a high-trust environment
+</h4>
+<p>
+ People who do not feel safe will not communicate their ideas, take the initiative, or admit their ignorance. In these
+ low-trust work environments, activities must be laboriously planned in detailed, carefully supervised, and extensively
+ audited. A team working in a low-trust environment may not be able to keep up with rapid change.
+</p>
+<p>
+ Therefore, take actions that foster a high-trust environment:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Manage by intent.</strong> Create an environment where teams manage themselves, and managers serve as
+ mentors to teams to help them complete their objectives.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Tear down the walls.</strong> Work to remove both the physical and mental barriers that inhibit
+ development of a common understanding among project participants.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Walk a mile (or 1.6 kilometers) in someone else's shoes.</strong> Respect and try to understand the
+ perspectives of others before criticizing their ideas or responding to their criticism.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Respond to conversations with relevance.</strong> People, especially technical workers, often respond
+ with argument or disagreement, which leads to rivalry and the establishment of a pecking order in which only a
+ few people contribute to the discussion. Develop and encourage behavior that values curiosity and relevance
+ over argument and disagreement.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Always look to yourself first for the source of communication problems.</strong> Understand that
+ everyone has a perspective that is largely invisible to the individual (although it is often obvious to
+ everyone else). Develop the habit of identifying the assumptions and prejudices within yourself that lead to
+ argument or lack of communication. Learn to overcome these in the moment of the conversation. This takes
+ practice. There are times when others may be intractable, but often the problem can be addressed by wrestling
+ with your own perspective.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand the constraints of the workplace culture.</strong> Some organizations operate in a way that
+ allows people to admit mistakes, ask questions, and experiment. Some organizations limit these expressions, but
+ they may change, with time and effort. Some organizations have no tolerance for error, and workers put
+ themselves in danger by admitting mistakes or experimenting. Understand your environment and protect yourself
+ accordingly. Understand that low-trust organizations have more problems in achieving their goals and provide a
+ less satisfying environment.
+ </p>
+ </li>
+</ul>
+<h4 style="MARGIN: auto 0in">
+ Share responsibility
+</h4>
+<p>
+ There may be disadvantages for individuals when they work alone. Communication with the team can become sporadic, and
+ then stop. People may get into trouble and not ask for help, or not realize that the team is in trouble and needs their
+ help. Their understanding of the project may become misaligned with the rest of the team. In the worse situations,
+ trust breaks down as individuals see the team working at different purposes to their interests.
+</p>
+<p>
+ Therefore, while individuals have primary responsibility for their work products, responsibility for work products is
+ shared. Nothing is someone else's responsibility. This may mean either taking up slack and working with someone who is
+ lagging for some reason or asking for help. Experienced staff should be extra-vigilant and watch over less-experienced
+ staff, encouraging them to ask for help if necessary.
+</p>
+<h4 style="MARGIN: auto 0in">
+ Learn continuously
+</h4>
+<p>
+ Not only is software development a fast-developing field where technical skills rapidly become obsolete, it is also an
+ empirical process, where software is developed in a manner that sometimes resembles trial and error. Furthermore,
+ software is developed by teams of people who must work together to achieve results.
+</p>
+<p>
+ Therefore, continuously develop both your technical and interpersonal skills. Learn from the examples of your
+ colleagues. Take the opportunity to be both a student of your colleagues, as well as a teacher to them. Always increase
+ your personal ability to overcome your own antagonism toward other team members.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Organize around the architecture
+</h4>
+<br />
+<p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ As projects grow in size, communication between team members becomes increasingly complex.<span style="mso-spacerun: yes">&nbsp;</span>While all team members understand the overall system, they can focus primarily
+ on the one or more subsystems they are responsible for. Organizing around the architecture also helps with
+ communication by providing the team with a common vocabulary and shared mental model of the system<strong>.</strong>
+ Communication between team members becomes increasingly complex. Therefore, organize the team around the architecture
+ and the vocabulary and shared mental model of the system. However, be watchful that individuals and teams organized
+ this way do not form a so-called <em>silo mentality</em>, where they focus strictly on their subsystems and become
+ ignorant of the other subsystems.
+</p>
+<p>
+ An architecture that reflects the organization’s structure is not evidence that the team has successfully organized
+ around the architecture. If organizations and teams are not organized around the architecture, then the architecture
+ will naturally conform to the organization, as a result of political and cultural influences. In the end, the
+ architecture and the organization will almost always be a reflection of each other. The goal is to guide team
+ organization from the needs of the architecture as much as possible.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_evolve.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_evolve.xmi
new file mode 100644
index 0000000..f24f88c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_evolve.xmi
@@ -0,0 +1,133 @@
+<?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" epf:version="1.0.0" xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" name="core_principle_evolve,_GXiogMvoEdqukPpotm3DYg" guid="-aMD1wQVJLzzlMARfHBdOBQ" changeDate="2006-09-27T16:35:31.654-0700" changeDescription="removed OpenUP from page name." version="0.02">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ It is usually not possible to know all stakeholders' needs, be aware of all project risks, comprehend all project
+ technologies, or know how to work with your colleagues. Even if it were possible to know all of these things, they are
+ likely to change over the life of the project. Therefore, divide the project into short, time-boxed iterations to
+ demonstrate incremental value and to get early and continuous feedback.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p>
+ The intention behind this principle is to continuously get feedback and to improve both the product and the process of
+ the project team. When you provide structure and create a mindset for continuous feedback and improvement, changes are
+ accommodated more easily, feedback is captured early and often, high-priority risks are confronted early in the
+ project. By constantly identifying and attacking risks, there is more confidence in project progress and quality.
+</p>
+<p>
+ Not only does the product evolve, but the team also finds better ways to work together and get involved with
+ stakeholders.<span style="mso-spacerun: yes">&nbsp;</span> The process followed by the team can be adjusted accordingly
+ to leverage lessons learned and adjust project pace and needs.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Develop your project in iterations
+</h4>
+<p>
+ Developing a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new
+ knowledge. Worse, it can delay the discovery and mitigation of risks, because development efforts are scheduled later
+ in the lifecycle.
+</p>
+<p>
+ Therefore, divide your project into a series of time-boxed iterations, and plan your project iteratively. This
+ iterative strategy enables you to incrementally deliver capabilities (such as an executable, usable subset of
+ implemented and tested requirements) that can be assessed by stakeholders at the end of each iteration. This provides
+ rapid and timely feedback loops so that issues can be addressed and improvements made at a lower cost. Also, this is
+ accomplished while you still have sufficient budget and time left to do so, and you have not gone so far ahead that
+ major rework is required. Iterative development enables teams to continuously improve software throughout the
+ development <a href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">lifecycle</a>.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Focus iterations on meeting the next management milestone
+</h4>
+<p>
+ Without a focus to bring closure to important project issues, such as stakeholder concurrence regarding scope and
+ proving the proposed architecture, a project can appear to make progress while risks and unresolved issues pile up.
+</p>
+<p>
+ Therefore, divide the project into phases (such as Inception, Elaboration, Construction, and Transition), with each
+ phase having a clearly visible management milestone. The focus of each iteration within a phase is on achieving that
+ milestone. <span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Manage risks
+</h4>
+<p>
+ Deferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such
+ procrastination may lead to investing in the wrong technologies, a bad design, or a set of requirements that may not
+ address stakeholder needs.
+</p>
+<p>
+ Therefore, attack <a href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a> early, or they will attack you. Continuously identify and prioritize risks,
+ and then devise strategies to mitigate them. Determine the focus of iterations based on risks. For example,
+ architecturally significant risks should be addressed early in the project, no later than the end of Elaboration phase,
+ when the architecture has been proven and baselined.
+</p>
+<p>
+ At the beginning of each iteration, the entire team should consider what risks they are facing, and update the risk
+ list. Make it each team member’s and stakeholder’s responsibility to have the courage to speak up and openly discuss
+ risks, as well as to have the courage not to criticize the people who do speak up, even though the risk may point to a
+ flaw in their area of responsibility. For each risk, articulate a plan for tracking and mitigating the risk.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Embrace and manage change
+</h4>
+<p>
+ Change is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will
+ result in a bloated, deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a
+ change is made, the more the change is likely to cost.
+</p>
+<p>
+ Therefore, both embrace and manage change. Embracing change helps you to build a system that addresses stakeholder
+ needs, and managing change allows you to reduce costs and improve predictability of those changes. Changes made early
+ in the project can usually be made with limited cost. As you progress in your project, changes can become increasingly
+ costly.
+</p>
+<p>
+ To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware
+ of the impact that those changes have on the project cost and schedule. Understand the impact of a change in the
+ current phase, and isolate team members from disruptive changes during the current iteration. Change requests are
+ reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration.
+</p>
+<p>
+ If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Measure progress objectively
+</h4>
+<p>
+ If you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding.
+ Uncertainty and change make a software project’s progress difficult to measure objectively, and people have a most
+ amazing ability to believe all is well in the face of catastrophe.
+</p>
+<p>
+ Therefore, get a clear picture of project status by objectively measuring progress. The best measure of progress is the
+ delivery of working software, which is something that you do by taking an evolutionary approach.<span style="mso-spacerun: yes">&nbsp;</span>You can also define a set of objective <a href="./../../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html" guid="_0mYYkMlgEdmt3adZL5Dmdw">metrics</a> to collect during an iteration (for example, requirements that were
+ implemented and validated, number of defects issued compared with number fixed) and review them as part of the <a href="./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw"><span style="COLOR: windowtext">iteration assessment</span></a>. Do not rely on single metrics. Rather, use a combination of
+ metrics and look for trends.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Continuously re-evaluate what you do
+</h4>
+<p>
+ People make mistakes during a project. If we chose to hide those mistakes, then we risk repeating the same mistakes. In
+ addition, such repressed social dynamic issues can poison the team.
+</p>
+<p>
+ Therefore, on a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team
+ to&nbsp;track status and identify risks and issues. This can be done daily when the team gathers to share the status of
+ individual responsibilities and identify and address issues. At the end of iterations, <a href="./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw"><span style="COLOR: windowtext">assess the status</span></a> of what has been done and look for areas of improvement that can
+ be addressed in the next iteration. Have a retrospective review at the end of the project and capture lessons learned
+ to run future projects in a more efficient way.
+</p>
+<p>
+ If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads
+ to improved project results.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_focus.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_focus.xmi
new file mode 100644
index 0000000..5209806
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/core_principle_focus.xmi
@@ -0,0 +1,93 @@
+<?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" epf:version="1.0.0" xmi:id="-HTMJFV29MTZkKWqnIo01Gg" name="core_principle_focus,_9gocwMvoEdqukPpotm3DYg" guid="-HTMJFV29MTZkKWqnIo01Gg" authors="Steve Adolph" changeDate="2006-09-27T16:35:45.896-0700" changeDescription="Added first draft of content." version="0.02">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
+ proves difficult to evolve, reuse, or integrate without substantial rework. It is also difficult to organize the team
+ or communicate ideas without the common technical focus that the architecture provides.
+</p>
+<p>
+ Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
+ essential technical decisions through the growing architecture.
+</p>
+<h3>
+ Practices
+</h3>
+<p>
+ The next sections describe the practices associated with this principle.
+</p>
+<h4>
+ Create the architecture for what you know today
+</h4>
+<p>
+ As Albert Einstein said, make everything as simple as possible but no simpler. Software projects are
+ resource-constrained, and the desire of developers to create elegant solutions may lead to a system of greater
+ complexity than the stakeholder requires. Efforts to future-proof a system in a turbulent or uncertain environment will
+ likely lead to code bloat , thus increasing overall cost with little actual benefit to show for it.
+</p>
+<p>
+ Therefore, create architectures that address the stakeholder’s real needs, and provide appropriate flexibility and
+ speed for the requirements as they are known today. Avoid the desire, no matter how well intentioned, to speculate on
+ future requirements and thereby over-engineer the architecture: if you have the skill to architect something today,
+ then clearly you must also have the skill to architect it tomorrow when you actually need to.
+</p>
+<h4>
+ Cope with complexity by raising the level of abstraction
+</h4>
+<p>
+ Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it becomes
+ difficult for the team to develop a common understanding of the system, because it is hard to see the bigger picture.
+</p>
+<p>
+ Therefore, use models to raise the level of abstraction to focus on important high-level issues, such as relationships
+ and patterns, rather than getting bogged down in details. Modeling raises the level of abstraction and allows the
+ system to be more easily understood from different perspectives.
+</p>
+<h4>
+ Let the problem drive the solution
+</h4>
+<p>
+ The architecture may become difficult to maintain and adapt to new stakeholder needs when technology, rather than the
+ problem, drives the solution.
+</p>
+<p>
+ Therefore, let the needs of the stakeholders guide the architecture, instead.
+</p>
+<h4>
+ Organize the architecture into loosely coupled, highly cohesive components
+</h4>
+<p>
+ Tight coupling between components makes a system fragile and difficult to understand. Software is expensive to create,
+ so if existing components can be reused, that may reduce effort required to create a system.
+</p>
+<p>
+ Therefore, organize the architecture of the system into components that to maximize cohesion and minimize coupling.
+ This improves comprehension, increases flexibility, and increases opportunities for re-use.
+</p>
+<h4>
+ Reuse existing assets
+</h4>
+<p>
+ It is wasteful to build what you can simply reuse, download, or even buy.
+</p>
+<p>
+ Therefore, make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those
+ assets do not exactly meet their needs or those assets are of poor quality. Be prepared to balance the savings you can
+ realize using an existing asset, even if the asset requires distorting the architecture or relaxing a constraint.
+</p>
+<h4>
+ Leverage the architecture as a collaborative tool
+</h4>
+<p>
+ Lack of a common understanding by developers about a system leads to indecision and contrary opinions among developers
+ and can quickly paralyze the project. Developers may have different mental models of the system and work at cross
+ purposes to each other.
+</p>
+<p>
+ Therefore, create and evolve the system architecture with the intention of using it to align the developer’s competing
+ mental models of the system. A good architecture facilitates collaboration by providing a common vocabulary for all
+ discussions regarding the system under development.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/design_mechanism.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/design_mechanism.xmi
new file mode 100644
index 0000000..3d12365
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/design_mechanism.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="-EG22TRyJ5TDKW6U88AXfhw" name="design_mechanism,_hNXugOUuEdqGCpzGJ4tJOw" guid="-EG22TRyJ5TDKW6U88AXfhw" changeDate="2007-02-26T13:41:09.500+0000" version="1.0.0">
+ <mainDescription><p align="left">
+ A Design Mechanism is a concrete representation of an&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. It is refined from an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>&nbsp;and is further refined into an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/implementation_mechanism,_0LcUkA4LEduibvKwrGxWxA.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>&nbsp;as the design becomes more detailed.
+</p>
+<p align="left">
+ Design Mechanisms can be&nbsp;represented as specific design patterns and frameworks&nbsp;in the <a class="elementLink"
+ href="./../../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. They are used&nbsp;to guide development&nbsp;(see <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Using Patterns</a>). Design Mechanisms should still be relatively independent of
+ implementation but provide enough detailed information for implementation choices to be made and software to be
+ developed with confidence.
+</p>
+<p align="left">
+ See <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/example_design_mechanisms,_4k_Hsg4LEduibvKwrGxWxA.html"
+ guid="_4k_Hsg4LEduibvKwrGxWxA">Example: Design Mechanisms</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/developer_testing.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/developer_testing.xmi
new file mode 100644
index 0000000..aac8804
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/developer_testing.xmi
@@ -0,0 +1,121 @@
+<?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" epf:version="1.0.0" xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q" name="new_concept,_aFeZgJquEdukqcRKZBQN9w" guid="-Ff1JwbrGt1laexkOB6ZM1Q" changeDate="2007-01-03T17:00:23.980-0500" version="1.0.0">
+ <mainDescription><p>
+ Developer testing is the act of regression testing source code by developers.&nbsp; This is sometimes called "unit
+ regression testing" but many developer tests go beyond unit testing to address integration testing instead.
+</p>
+<h3>
+ Testing Philosophies
+</h3>
+<p>
+ Here are some important philosophies with regard to developer&nbsp;testing:
+</p>
+<ol>
+ <li>
+ The goal is to find defects. Successful tests find bugs, but correcting the bugs&nbsp;falls into other areas.
+ </li>
+ <li>
+ Test&nbsp;early and often. The cost of change rises exponentially the longer it takes to find and then remove a
+ defect. The implication is that you want to test as early as possible (the earliest you could possibly test is
+ first, see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw.html"
+ guid="_0Y6kUMlgEdmt3adZL5Dmdw">Concept: Test-first Design</a>).
+ </li>
+ <li>
+ Testing builds confidence. Many people fear making a change to their code because they are afraid that they will
+ break it, but with a full test suite in place if you do break something you know you will detect it and then fix
+ it.
+ </li>
+ <li>
+ One test is worth a thousand opinions. You can&nbsp;say that your application works, but until you show the test
+ results&nbsp;you might&nbsp;not be believed.
+ </li>
+ <li>
+ Test to the risk. The riskier something is, the more it needs to be reviewed and tested. In other words you should
+ invest significant effort testing in the algorithm for estimating radiation doses but nowhere near as much effort
+ testing the "change font size" function of the same application.
+ </li>
+ <li>
+ You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of
+ this guidance is testing code.
+ </li>
+</ol>
+<h3>
+ Qualities of a Good Developer Test
+</h3>
+These are the qualities of&nbsp;a good developer test:
+<ul class="noindent">
+ <li>
+ It runs fast.&nbsp;It has&nbsp;short setup, run time, and clean-up.
+ </li>
+ <li>
+ It runs in isolation. You should be able to reorder your tests.
+ </li>
+ <li>
+ It is understandable. Good tests have consistent and informative names and use data that makes them easy to read
+ and to understand.
+ </li>
+ <li>
+ It uses real data. E.g. Use copies of production data when appropriate, but remember that you'll also have to
+ create some specific "artificial" test data as well.
+ </li>
+ <li>
+ It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and
+ one only issue.
+ </li>
+</ul>
+<h3>
+ Approaches for Test Setup
+</h3>
+<p>
+ To successfully run a test, the system must be in a known state.&nbsp; To do this you will need objects or components
+ in memory, rows in your database, etc.&nbsp;that you will test against.&nbsp; The easiest approach is to hardcode the
+ required data and the setup code within the test itself.&nbsp; The primary advantage&nbsp;is that all the information
+ that you need about the test is in one place and that the test is potentially self-sufficient.
+</p>
+<p>
+ Another approach is to define an external data set which&nbsp;is loaded into memory or into&nbsp;the database at the
+ beginning of&nbsp;the test run.&nbsp; There are several advantages to this approach:
+</p>
+<ul>
+ <li>
+ It decouples the test data from the test.&nbsp;
+ </li>
+ <li>
+ More than one test&nbsp;can use the same data set.&nbsp;
+ </li>
+ <li>
+ It is easy to modify and/or multiply the test data.&nbsp;
+ </li>
+</ul>
+<p>
+ There are some disadvantages to this approach:
+</p>
+<ul>
+ <li>
+ Increased complexity for maintaining the external data
+ </li>
+ <li>
+ Potential coupling between test cases.&nbsp; When&nbsp;they share a common test data bed it becomes very easy to
+ write tests&nbsp;that depend on other tests running first, thereby coupling them together.<br />
+ </li>
+</ul>
+<h3>
+ Coding for Testability
+</h3>
+<p>
+ Add&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/termdefinitions/code_instrumentation,_JiqnEJt1EdutoZjlV3a4Lg.html"
+ guid="_JiqnEJt1EdutoZjlV3a4Lg">Code Instrumentation</a> for testing and debugging.&nbsp; Pay special attention to the
+ implementation of the observation/control points, such as critical functions or&nbsp;objects,&nbsp;as these aspects
+ might need special support that has to be implemented in the component under test.
+</p>
+<h3>
+ Reviewing Tests
+</h3>
+<p>
+ If a test will be long-lived, ask a person with less inside knowledge of the component to run it and check if there is
+ enough support information. Review it with other people within the development team and other interested parties as
+ needed.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/elaboration_phase.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/elaboration_phase.xmi
new file mode 100644
index 0000000..1b63e2c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/elaboration_phase.xmi
@@ -0,0 +1,107 @@
+<?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" epf:version="1.0.0" xmi:id="-F-eWIBzxEXE1jygbN3nrrQ" name=",_2plxwBOMEduCNqgZdt_OaA" guid="-F-eWIBzxEXE1jygbN3nrrQ" changeDate="2006-09-27T16:28:27.954-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this phase is to establish the baseline of the architecture of the system and provide a stable basis for
+ the bulk of the&nbsp;development effort in the next phase.
+</p>
+<p>
+ There are objectives for the Elaboration phase that help you address risks associated with requirements, architecture,
+ costs, and schedule <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Get a more detailed understanding of the requirements.</strong> Having a good understanding of the
+ majority of requirements allows you to create a more detailed plan and to get buy-in from stakeholders. Be sure
+ to gain an in-depth understanding of the most critical requirements to be validated by&nbsp;the architecture.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design, implement, validate, and establish the baseline for the architecture.</strong> Design,
+ implement, and test a skeleton structure of the system. Although the functionality is not complete yet, most of
+ the interfaces between the building blocks are implemented and tested. This is referred to <strong>an
+ executable architecture</strong>.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Mitigate essential risks, and produce accurate schedule and cost estimates.</strong> Many technical
+ risks are addressed as a result of detailing the requirements and of designing, implementing, and testing the
+ architecture. Refine and detail the high-level project plan.
+ </p>
+ </li>
+</ul>
+<p>
+ The following table summarizes the&nbsp;Elaboration phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <strong>Elaboration phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Get a more detailed understanding of the requirements
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0ruyoclgEdmt3adZL5Dmdw.html" guid="_0ruyoclgEdmt3adZL5Dmdw">Manage Requirements</a> <br />
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Design, implement, validate, and baseline an architecture
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../define_architecture,_0rcewclgEdmt3adZL5Dmdw.html" guid="_0rcewclgEdmt3adZL5Dmdw">Define the Architecture</a><br />
+ <a class="elementLinkWithUserText" href="./../../../develop_requirement_within_context,_WrXvwPinEdmugcVr9AdHjQ.html" guid="_WrXvwPinEdmugcVr9AdHjQ">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0rilYclgEdmt3adZL5Dmdw.html" guid="_0rilYclgEdmt3adZL5Dmdw">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Mitigate essential risks, and produce accurate schedule and cost estimates
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a> <br />
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ The number of iterations in the Elaboration phase is dependent on, but not limited to, factors such as green-field
+ development versus maintenance cycle, unprecedented system versus well-known technology and architecture, and so on.
+</p>
+<p>
+ Typically, on the first iteration, you should design, implement, and test a small number of critical scenarios to
+ identify what type of architecture and architectural mechanisms you need, so you can mitigate the most crucial risks.
+ You also detail high-risk requirements that have to be addressed early in the project. You test enough to validate that
+ the architectural risks are mitigated.
+</p>
+<p>
+ On the following iterations, you fix whatever was not right from the previous iteration. You design, implement, and
+ test the remaining architecturally significant scenarios, ensuring that you check all major areas of the system
+ (architectural coverage), so potential hidden risks arise as early as possible. <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>
+</p>
+<p>
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/entity_control_boundary_pattern.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/entity_control_boundary_pattern.xmi
new file mode 100644
index 0000000..2fcf31d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/entity_control_boundary_pattern.xmi
@@ -0,0 +1,180 @@
+<?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" epf:version="1.0.0" xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" name="finding_analysis_classes,_uF-QYEAhEdq_UJTvM1DM2Q" guid="-awaQ_2dwhGyKRoVKQ-esPQ" changeDate="2006-09-28T10:02:50.694-0700">
+ <mainDescription><p>
+ When identifying the elements for some scenario of system behavior, you can align each participating element with one
+ of three key perspectives: Entity, Control, or Boundary.
+</p>
+<p>
+ This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>] among other places), but the Entity Control Boundary pattern is not solely
+ appropriate for dealing with user interfaces and it gives the controller a slightly different role to play.
+</p>
+<h5>
+ ECB&nbsp;Pattern Example
+</h5>
+<p>
+ &nbsp;<img height="233" alt="" src="./resources/EBCDiagram.JPG" width="493" />
+</p>
+<h3>
+ Entity Elements
+</h3>
+<p>
+ An entity is a long-lived, passive element that is responsible for some meaningful chunk of information. This is not to
+ say that entities are "data" while other&nbsp;design elements&nbsp;are "function". Entities perform behavior organized
+ around some cohesive amount of data.
+</p>
+<p>
+ An example entity for a customer service application would be a Customer entity that manages all information about a
+ customer.&nbsp; A design element for&nbsp;this entity would include data on the customer, behavior to manage the data,
+ behavior to validate customer information&nbsp;and perform other business calculations such as "is this customer
+ allowed to purchase product X?"
+</p>
+<p>
+ The identification of the entities as part of this pattern can be done many times at different levels of abstraction
+ from the code, at different levels of granularity in size, and from the perspectives of different contexts.&nbsp; For
+ example you could do an analysis pass on a scenario of creating a marketing campaign and identify the customer element
+ with various customer data elements such as name and address plus various required behaviors such as the management of
+ the name and address data and the ability to&nbsp;rate the customer based on some algorithm&nbsp;(such an application
+ of this pattern would be abstract from code, coarse-grained, and have no specific context).&nbsp; Later you could do a
+ pass on the same scenario applying an architectural mechanism for database access that breaks the address out into its
+ own element, moves the responsibility for storing and retrieving customers to a new control element, and identifies
+ some specific database decisions&nbsp;such as&nbsp;the usage of primary keys in the entities (such an application of
+ this pattern would be closer to the code, finer-grained, and aligned with a database&nbsp;context).
+</p>
+<h3>
+ Control Elements
+</h3>
+<p>
+ A control element manages the flow of interaction of the scenario. A control element could manage the end-to-end
+ behavior of a scenario or it could manage the interactions between a subset of the elements.&nbsp; Behavior and
+ business rules relating to the information relevant to the scenario should be assigned to the entities; the control
+ elements are just responsible for the flow of the scenario.
+</p>
+<p>
+ An example&nbsp;control element&nbsp;for a customer service application would be CreateMarketingCapmpaign.&nbsp; This
+ design element would&nbsp;be responsive to certain front-end boundary elements and would collaborate with other
+ entities, control&nbsp;elements, and back-end boundary elements to support the creation of a marketing campaign.
+</p>
+<p>
+ As with the entity example above, there might be many passes over the identification of control elements.&nbsp; A first
+ pass might be an analysis pass that identifies one control element for a&nbsp;scenario with behavior to make sure the
+ design can support the flow of events, a&nbsp;subsequent pass might find controllers to manage reusable collaborations
+ of low level elements that will map to a specific code&nbsp;unit to be written.
+</p>
+<h3>
+ Boundary Elements
+</h3>
+<p>
+ A boundary element lies on the periphery of a system or subsystem, but within it. For any scenario being considered
+ either across the whole system or within some subsystem, some boundary elements will be "front-end" elements that
+ accept input from outside the area under design and other elements will be "back-end" managing communication to
+ supporting elements outside the system or subsystem.
+</p>
+<p>
+ Two example boundary elements for a customer service application might be a front-end MarketingCampaignForm and a
+ back-end BugdetSystem element.&nbsp; The MarketingCampaignForm would manage the exchange of information between a user
+ and the system and the BugdetSystem would manage the exchange of information between the system and an external system
+ that manages budgets.
+</p>
+<p>
+ An analysis pass could identify one boundary element for each external relevant to a scenario; subsequently these could
+ be broken down into multiple boundary elements or&nbsp;small communities made up of collaborating&nbsp;elements&nbsp;of
+ all three stereotypes.
+</p>
+<h3>
+ Walking the Scenario
+</h3>
+<p>
+ One can walk through a scenario initiated by something outside the bounds of the system or subsystem being designed and
+ distribute the responsibility to perform behavior supporting the scenario to the elements identified of each
+ type.&nbsp; The appropriate design element responsible for each action in the scenario will be as described in the
+ definition of each of the element types described above.
+</p>
+<p>
+ In addition to identifying the behavior necessary to perform the scenario, the initiation of this behavior from design
+ element to design element&nbsp;identifies the necessary relationships.&nbsp; There are certain
+ appropriate&nbsp;relations between the participating elements.&nbsp;&nbsp;An element can communicate to other elements
+ of the same kind.&nbsp; Control&nbsp;elements can communicate with each of the other two kinds, but entities and
+ boundary elements should not directly communicate.&nbsp;
+</p>
+<p>
+ The table below shows appropriate links between design elements.
+</p>
+<table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ <center>
+ Entity
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Boundary
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Control
+ </center>
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ Entity
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Boundary
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Control
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ By&nbsp;applying this pattern, a robust design can be put together that identifies the elements, behavior, and
+ relationships&nbsp;necessary to support&nbsp;a scenario.&nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation 2.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation 2.xmi
new file mode 100644
index 0000000..9980637
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation 2.xmi
@@ -0,0 +1,76 @@
+<?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" epf:version="1.0.0" xmi:id="-9gUpkUYqONF3x8UWwAO_zw" name="failure_analysis_rpt_creation,_0jhR0MlgEdmt3adZL5Dmdw" guid="-9gUpkUYqONF3x8UWwAO_zw" changeDate="2006-09-29T13:52:52.340-0700" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ During testing, you will encounter failures related to the execution of your tests in different forms, such as code
+ defects, user errors, program malfunctions, and general problems. This&nbsp;concept discusses some ways to conduct
+ failure analysis and then to report your findings.
+</p>
+<h3>
+ Failure Analysis
+</h3>
+<p>
+ After you have run your tests, it is good practice to identify inputs for review of the results of the testing effort.
+ Some likely sources are defects that occurred during the execution of test scripts, change request metrics, and test
+ log details.
+</p>
+<p>
+ Running test scripts results in errors of different kinds such as uncovered defects, unexpected behavior, or general
+ failure of the test script to run properly. When you run test scripts, one of the most important things to do is to
+ identify causes and effects of failure. It is important to differentiate failures in the system under test&nbsp;from
+ those related to the tests themselves.
+</p>
+<p>
+ Change request metrics are useful in analyzing and correcting failures in the testing. Select metrics that will
+ facilitate creation of incident reports from a collection of change requests.
+</p>
+<p>
+ Change request metrics that you may find useful in your failure analysis include:
+</p>
+<ul>
+ <li>
+ test coverage
+ </li>
+ <li>
+ priority
+ </li>
+ <li>
+ impact
+ </li>
+ <li>
+ defect trends
+ </li>
+ <li>
+ density
+ </li>
+</ul>
+<p>
+ Finally, one of the most critical sources of your failure analysis is the test log. Start by gathering the test log's
+ output during the implementation and execution of the tests. Relevant logs might come from many sources; they might be
+ captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines your
+ team has developed, output from the target test items themselves, and recorded manually be the tester. Gather all of
+ the available test log sources and examine their content. Check that all the scheduled testing executed to completion,
+ and that all the needed tests&nbsp;have been scheduled.
+</p>
+<h3>
+ Self-Documenting Tests
+</h3>
+<p>
+ For automated tests it is a best practice for the test itself to examine the results and clearly report itself as
+ passing or failing. This provides the most efficient way to run tests such that whole suites of tests can be run with
+ each test in turn determining whether it has passed or failed without the need for human intervention. When authoring
+ self-documenting tests, take extra care to ensure that the analysis of the results considers all possibilities.
+</p>
+<h3>
+ Recording Your Findings
+</h3>
+<p>
+ Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
+ your findings in a report. There are several factors that go into deciding whether to record your failure analysis in a
+ report. Some of the key factors include: level of testing formality, complexity of the testing effort, and the need to
+ communicate the testing results to the entire development team. In less formal environments, it may be sufficient to
+ record your failure analysis in&nbsp;a test evaluation summary.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation.xmi
new file mode 100644
index 0000000..b084730
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation.xmi
@@ -0,0 +1,49 @@
+<?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" epf:version="1.0.0" xmi:id="_qS8JcMM3EdmSIPI87WLu3g" name="failure_analisys_rpt_creation,_0jhR0MlgEdmt3adZL5Dmdw" guid="_qS8JcMM3EdmSIPI87WLu3g" changeDate="2006-09-20T15:57:59.790-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ During testing, you will encounter failures related to the execution of your tests&nbsp;in different&nbsp;forms, such
+ as, code defects, user errors, program malfunctions, and general problems.&nbsp;This concept page describes some ways
+ to conduct failure analysis and then to report your findings.
+</p>
+<h3>
+ Failure Analysis
+</h3>
+<p>
+ After you have run your tests, it is good practice to identify inputs for review of the results of the testing
+ effort.&nbsp;Some likely sources are defects that occured during the execution of test scripts, change request metrics,
+ and&nbsp;test log details.
+</p>
+<p>
+ Running test scripts may results in errors of different kinds such as uncovered defects, unexpected behavior, or
+ general failure of the test script to run properly.&nbsp;When you run test scripts, one of the most important things to
+ do is to identify causes and effects of failure.&nbsp;It is important to differentiate failures in the system under
+ test as well as those related to the tests themselves.
+</p>
+<p>
+ Change request metrics are useful in analyzing and correcting failures in the testing.&nbsp;Select metrics that will
+ facilitate creation of incident reports from a collection of change requests.&nbsp;Change request metrics that you may
+ find useful in your failure analysis include: test coverage, priority, impact, defect trends and density.
+</p>
+<p>
+ Finally, one of the most critical sources of your failure analysis is the test log.&nbsp;Start by gathering the test
+ logs output during the implementation and execution of the tests. Relevant logs might come from many sources - they
+ might be captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines
+ your team has developed, output from the target-of-test items themselves, and recorded manually by the tester. Gather
+ all of the available test log sources and examine their content. Check that all the scheduled testing executed to
+ completion, and that all the tests that should have been scheduled actually were.
+</p>
+<h3>
+ Recording Your Findings
+</h3>
+<p>
+ Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
+ your findings in a report.&nbsp;There are several factors that go into deciding whether to record your failure analysis
+ in a report.&nbsp;Some of the key factors include:&nbsp;level of testing formality, complexity of the testing effort,
+ and the need to communicate the testing results to the entire development team.&nbsp;In less formal environments, it
+ may be sufficient to record your failure analysis in the form of a change request.&nbsp;In this case, it is convenient
+ to be able to cull relevant failure analysis information of change requests and put this into&nbsp;a report format.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/implementation_mechanism.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/implementation_mechanism.xmi
new file mode 100644
index 0000000..ff10d5e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/implementation_mechanism.xmi
@@ -0,0 +1,40 @@
+<?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" epf:version="1.0.0" xmi:id="-Rex8oOBv985RruZNrCW0rg" name="implementation_mechanisms,_3ANskOK5EdqHEo0wLIc5jg" guid="-Rex8oOBv985RruZNrCW0rg" changeDate="2006-09-25T21:09:13.255+0100" version="1.0.0">
+ <mainDescription><p>
+ An Implementation Mechanism is a refinement of a corresponding Design Mechanism that uses, for example, a particular
+ programming language and other implementation technology (such as a particular vendor's middleware product). An
+ Implementation Mechanism may instantiate one or more idioms or implementation patterns.
+</p>
+<p>
+ Review these points when you are considering Implementation Mechanisms:
+</p>
+<ul>
+ <li>
+ <p>
+ <b>Determine the ranges of characteristics.</b> Take the characteristics that you identified for the Design
+ Mechanisms into consideration to determine reasonable, economical, or feasible ranges of values to use in the
+ Implementation Mechanism candidate.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Consider the cost of purchased components</b>. For Implementation Mechanism candidates, consider the cost of
+ licensing, the maturity of the product, your history or relationship with the vendor, support, and so forth in
+ addition to purely technical criteria.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Conduct a search for the right components, or build the components.</b> You will often find that there is no
+ apparently suitable Implementation Mechanism for a particular Design Mechanism. This will either trigger a
+ search for the right product or make the need for in-house development apparent. You may also find that some
+ Implementation Mechanisms are not used at all.<br />
+ <br />
+ The choice of Implementation Mechanisms is based not only on a good match for the technical characteristics,
+ but also on the non-technical characteristics, such as cost. Some of the choices may be provisional. Almost all
+ have some risks attached to them. Performance, robustness, and scalability are nearly always concerns and must
+ be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype.
+ </p>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/inception_phase.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/inception_phase.xmi
new file mode 100644
index 0000000..ed97ba6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/inception_phase.xmi
@@ -0,0 +1,110 @@
+<?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" epf:version="1.0.0" xmi:id="-GRJW_KNOJoEQF3r6lmBrEw" name=",_0hmKgBOMEduCNqgZdt_OaA" guid="-GRJW_KNOJoEQF3r6lmBrEw" changeDate="2006-11-06T11:29:38.552-0800" version="1.0.0">
+ <mainDescription><p>
+ The purpose&nbsp;in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the
+ project.
+</p>
+<p>
+ There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the
+ intended solution <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Understand what to build.</strong> Determine the <a class="elementLinkWithUserText" href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>, the scope of the system, and its boundaries. Identify who is
+ interested in this system and why (see <a class="elementLinkWithUserText" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Identify key system functionality.</strong> Decide which requirements are most critical.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Determine at least one possible solution.</strong> Identify at least one candidate architecture and its
+ feasibility.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand</strong> the cost, schedule, and risks associated with the project.
+ </p>
+ </li>
+</ol>
+<p>
+ The following table summarizes the&nbsp;Inception phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <strong>Inception phase objectives and activities</strong>
+</p>
+<table cellspacing="1" cellpadding="0" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ <b>Phase objectives</b>
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <b>Activities that address objectives</b>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Understand what to build
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0okw8clgEdmt3adZL5Dmdw.html" guid="_0okw8clgEdmt3adZL5Dmdw">Manage Requirements</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Identify key system functionality
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../initiate_project,_0oSdE8lgEdmt3adZL5Dmdw.html" guid="_0oSdE8lgEdmt3adZL5Dmdw">Initiate Project</a><br />
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0okw8clgEdmt3adZL5Dmdw.html" guid="_0okw8clgEdmt3adZL5Dmdw">Manage Requirements</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Determine at least one possible solution
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../determine_architectural_feasibility,_0oreoclgEdmt3adZL5Dmdw.html" guid="_0oreoclgEdmt3adZL5Dmdw">Determine Architectural Feasibility</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Understand the cost, schedule, and risks associated with the project
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../initiate_project,_0oSdE8lgEdmt3adZL5Dmdw.html" guid="_0oSdE8lgEdmt3adZL5Dmdw">Initiate Project</a><br />
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ Projects may have one or more iterations in the Inception phase. Among reasons for multiple iterations in Inception,
+ you find:
+</p>
+<ul>
+ <li>
+ Project is large, and it is&nbsp;hard to define its scope.
+ </li>
+ <li>
+ Unprecedented system.
+ </li>
+ <li>
+ Too many stakeholders with competing needs and complex relationships.
+ </li>
+ <li>
+ Major technical risks demand the creation of a prototype or proof of concept.
+ </li>
+</ul>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/iteration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/iteration.xmi
new file mode 100644
index 0000000..0d4baa0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/iteration.xmi
@@ -0,0 +1,73 @@
+<?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" epf:version="1.0.0" xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" name="new_concept,_lam4ADkBEduxovfWMDsntw" guid="-vi8wxwxVZLY0SMPFxZjD7A" changeDate="2006-10-31T13:46:17.066-0800">
+ <mainDescription><H3>What is an Iteration </H3>
+<P>An iteration is a set period of time within a project in which you produce a stable, executable version of the product, together with any other supporting documentation, install scripts, or similar, necessary to use this release. The executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, get feedback on how they are doing so that they can improve their understanding of what needs to be done, and how to do it, Each iteration builds upon the results of previous iteration, and will produce a product increment one step closer to the final product. Iterations are timeboxed, meaning the schedule for an iteration should be regarded as fixed, and the scope of the iteration's content actively managed to meet that schedule. </P>
+<P>At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates. </P>
+<P>Iterative development is very disciplined: the iteration length is fixed; the objectives of iterations are carefully planned; the evaluation criteria are established when each iteration is planned; and the tasks and responsibilities of participants are well defined. Additionally, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this too is done in a structured fashion. </P>
+<P>Each iteration should address the most critical risks, and implement the highest-priority Work Items. This ensures that each iteration adds maximum stakeholder value, while reducing uncertainty. Iterative development is typically combined with frequent or continuous integration: as unit-tested components become available, they are integrated, then a build is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the iteration proceeds, towards the goals set when the iteration was planned. Regular builds, such as daily or more frequent builds, let you break down the integration and test issues and spread them across the development cycle. These issues have often been the downfall of large projects because all problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team. </P>
+<H3>What Problem Do Iterations Address? </H3>
+<P>Today’s software applications are too complex to allow you to sequentially define the requirements, come up with an architecture and design, do an implementation, carry out testing, and get it all right. Whether you use waterfall or iterative development approaches, your initial requirements, architecture, design, and code will be suboptimal. With waterfall development, you typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is too costly to make them. By contrast, dividing the project into a series of time-boxed iterations allows you to deliver capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely feedback loops enabling issues to be addressed and improvements made at a lower cost while budget and time still allow, and before the project has gone so far ahead that major rework is required. </P>
+<H3>Iteration Length </H3>
+<P>Iterations are typically 4 weeks long, although some teams will work with iterations as short as a week or as long as six weeks. For factors driving iteration length, see Table X. </P>
+<P><STRONG><EM>Table X. Factors Impacting Iteration Length.</EM></STRONG><BR>&nbsp;<BR></P>
+<TABLE style="WIDTH: 547px; HEIGHT: 356px" cellSpacing=2 cellPadding=2 width=547 border=1>
+<TBODY>
+<TR>
+<TH scope=col>Factors leading to reduced iteration length&nbsp; </TH>
+<TH scope=col>Factors leading to increased iteration length </TH></TR>
+<TR>
+<TD>Small teams&nbsp; </TD>
+<TD>Large teams </TD></TR>
+<TR>
+<TD>Collocated teams&nbsp; </TD>
+<TD>Distributed teams </TD></TR>
+<TR>
+<TD>Strong configuration management system&nbsp; </TD>
+<TD>Poor configuration management system </TD></TR>
+<TR>
+<TD>Dedicated, full-time resources </TD>
+<TD>Matrixed or part-time resources </TD></TR>
+<TR>
+<TD>Automated testing </TD>
+<TD>Lack of automated testing </TD></TR>
+<TR>
+<TD>Integrated tool environment&nbsp; </TD>
+<TD>Absence of good automation and tool integration </TD></TR>
+<TR>
+<TD>Team experienced with iterative development </TD>
+<TD>Team inexperienced with iterative development </TD></TR>
+<TR>
+<TD>Fast decision making </TD>
+<TD>Policies and bureaucracy preventing fast decision making </TD></TR>
+<TR>
+<TD>Unclear requirements </TD>
+<TD>Well-understood requirements </TD></TR>
+<TR>
+<TD>Unclear or brittle architecture </TD>
+<TD>Well-defined and stable architecture </TD></TR>
+<TR>
+<TD>New and poorly understood technology </TD>
+<TD>Well-understood technology </TD></TR></TBODY></TABLE><BR><BR>
+<H3>Why Iterate? </H3>
+<P>The iterative approach has proven itself superior to the waterfall approach for a number of reasons: </P>
+<UL>
+<LI>You are more likely to build an application that addresses user needs. Early specification of requirements often leads to unused features. The Standish Group has researched thousands of application development projects and has found that more than 45 percent of features are never used, while another 19 percent are used rarely&nbsp; (see Figure 2.3). In other words, typically more than half of the development effort is wasted on developing nonessential capabilities. To avoid this problem, you need to involve the customer in the development project and use an iterative approach that allows you to implement and validate the capabilities deemed most essential in each iteration. This approach allows not only early validation of key capabilities but also addition of new capabilities late in the project.
+<LI>Integration is not one “big bang” at the end of a project. Leaving integration to the end results in time- and budget-consuming rework. To avoid this, an iterative approach breaks a project down into smaller iterations, each evolving executable code that is continuously integrated to enable rapid feedback and minimize later revision.
+<LI>Risks are usually discovered or addressed during early iterations. With the iterative approach, risks are more likely to be identified and addressed in early iterations. As an example, if there is a risk that a stakeholder will not be happy with the functionality you are developing, iterative development will encourage you to&nbsp; implement the most essential capabilities partially and demonstrate them to key stakeholders to make sure that you are on the right track.
+<LI>Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all lifecycle activities, from requirements capture and test definition to development, implementation, and testing. Consequently, they can make sure they have the tools, skills, organizational structure, and so on to work effectively.
+<LI>Management has a way of making tactical changes to the product. Management can make changes to the product along the way—to compete with other new products, for example. Iterative development allows you to evolve partial implementations of the end product quickly and use these for quick release of a reduced-scope product to counter a competitor's move.
+<LI>Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in iterations than to recognize them at the beginning. Discussions and reviews of the design in early iterations allow team members to spot potential opportunities for reuse and then develop a mature common code for these opportunities in subsequent iterations.
+<LI>Defects can be found and corrected over several iterations. This capability results in a robust architecture and a high-quality application. Flaws are detected in early iterations, rather than during a massive testing phase at the end. Performance bottlenecks are discovered while they can still be addressed instead of creating panic on the eve of delivery.
+<LI>Project personnel are better used. Many organizations match their use of a waterfall approach with a pipeline organization: the analysts send the completed requirements to designers, who send a completed design to programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of errors and misunderstandings and make people feel less responsible for the final product. An iterative process encourages widening the scope of expertise of the team members, allowing them to play many roles and thus enabling a project manager to make better use of the available staff and simultaneously remove problematic handoffs.
+<LI>Team members learn along the way. The project members have several opportunities within a development cycle to learn from their mistakes and improve their skills from one iteration to another. More training opportunities can be discovered as a result of assessing the earlier iterations.
+<LI>The development process itself is improved and refined along the way. The end of iteration assessment not only looks at the project status from a product or scheduling perspective but also analyzes what can be improved in the next iteration in both the organization and the process.&nbsp; One technique for doing so is to hold a retrospective. </LI></UL><BR><SPAN class=E1><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><STRONG><IMG height=307 alt="45 percent of featues implemented are never ever used" src="./resources/iteration_1.GIF" width=489></STRONG></v:shapetype></SPAN></SPAN><BR>&nbsp;
+<P><STRONG><EM>Figure 2.3. Most Features Implemented Are Never or Rarely Used.<BR></EM></STRONG><EM>An amazing 45 percent of features implemented are never used, while another 19 percent are used only rarely. If features never used were not implemented in the first place, development time would be cut in about half. Further, since productivity is typically measured in the form of lines of code or functionality delivered, this improvement would not register as a productivity increase using standard productivity measures.<BR></EM>&nbsp; </P>
+<H3>Iteration and Phases </H3>
+<P>The purpose of iterations is to produce an executable which can be assessed so you can get feedback and make course corrections. This executable brings you one step closer to the final product. Phases provide a focus for a team on meeting a certain management objective. OpenUP has four phases, each ending with answering a specific question: </P>
+<UL>
+<LI><STRONG>Inception</STRONG>—Do we agree on the problem we are trying to solve?
+<LI><STRONG>Elaboration</STRONG>—Do we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?
+<LI><STRONG>Construction</STRONG>—Do we agree that we have a system that addresses key stakeholder needs?
+<LI><STRONG>Transition</STRONG>—Do we agree that we can release the system and end the project? </LI></UL>
+<P>Within each phase, you may have one or several iterations, where the iterations aim at producing the results required to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and test some key aspects of the system so that we understand what architecture we need, what Commercial Off-The-Shelf (COTS) components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These needs will steer how we prioritize what is to be done in an Elaboration iteration. </P></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/metrics.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/metrics.xmi
new file mode 100644
index 0000000..223c64a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/metrics.xmi
@@ -0,0 +1,86 @@
+<?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="_7ygXoMM3EdmSIPI87WLu3g" name="metrics,_0mYYkMlgEdmt3adZL5Dmdw" guid="_7ygXoMM3EdmSIPI87WLu3g" changeDate="2006-08-29T17:19:12.494-0700">
+ <mainDescription><h3>
+ What is a Metric?
+</h3>
+<p>
+ We distinguish between measure and metric.&nbsp; To clarify, let’s start by defining what is meant by measure and by
+ metric.
+</p>
+<ul>
+ <li>
+ <strong>Measure</strong>:&nbsp;a raw data item that is directly measured and that will be used to calculate a
+ metric.&nbsp;
+ </li>
+ <li>
+ <strong>Metric</strong>:&nbsp;an interpretation of a measure or a set of measures that you use to guide your
+ project.
+ </li>
+</ul>
+<p>
+ For example, recording how many test cases have passed and how many have failed are <strong>measures</strong>.
+ Interpreting what level of quality this indicates and how it reflects the team's progress within the current iteration
+ is a <strong>metric</strong>.
+</p>
+<h3>
+ Why Measure?
+</h3>
+<p>
+ Measurements will mainly help you to:
+</p>
+<ul>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Communicate effectively</strong>. Measurement supports effective communication among team members and
+ project stakeholders.&nbsp;
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Identify and correct problems early</strong>. Measurement enables you to identify and manage potential
+ problems early in the development lifecycle.&nbsp;
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Make informed trade-offs</strong>. Measurement helps assess objectively the impact of decisions,
+ helping managers to make trade-off decisions to best meet project goals.&nbsp;&nbsp;
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Tune estimations</strong>. Recording schedule, progress, and expenditures for projects will help team
+ members to make more reliable estimations in the future.
+ </div>
+ </li>
+</ul>
+<h3 align="left">
+ Potential Challenges
+</h3>
+<p align="left">
+ There are several dangers when it comes to metrics:
+</p>
+<div style="margin-left: 2em">
+ <ul>
+ <li>
+ <div align="left">
+ They can be too costly.&nbsp;The benefit provided by the metric must exceed the cost of collecting
+ it.&nbsp;Keep your measurements simple and easy to collect.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ They’re a poor substitute for communication.&nbsp;The best way to determine the current status of a project
+ is to ask the people involved, not to look at a report summarizing key metrics.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ They can be misleading.&nbsp; No metric or collection of metrics is perfect.&nbsp;Furthermore, the
+ measurements upon which they are based can be manipulated by the people capturing them.&nbsp;Don’t rely
+ simply upon metrics to manage a project.<br />
+ </div>
+ </li>
+ </ul>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/milestones.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/milestones.xmi
new file mode 100644
index 0000000..8e119ee
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/milestones.xmi
@@ -0,0 +1,50 @@
+<?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" epf:version="1.0.0" xmi:id="-DG8mYMnTGosWIxjPQFUoTA" name="milestones,_HNxbwMBJEdqSgKaj2SZBmg" guid="-DG8mYMnTGosWIxjPQFUoTA" changeDate="2006-10-31T12:53:11.446-0800">
+ <mainDescription><p>
+ Milestones are&nbsp;the point at which an iteration or phase formally ends.
+</p>
+<p>
+ From a&nbsp;development perspective, each iteration provides an increment of functionality to the product. Thus, the
+ end of each iteration corresponds to a checkpoint where the project team demonstrates to stakeholders that the
+ objectives for that iteration have been met.
+</p>
+<p>
+ However, there are four major milestones that provide evaluation criteria at the end of each phase. From a management
+ perspective, the software lifecycle&nbsp;is decomposed over time into four sequential phases, each concluded by a major
+ milestone [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BOE95</a>].
+</p>
+<p class="banner" align="center">
+ <img height="156" alt="Click on text for more information about phases and milestones" src="./resources/co_phas1.gif" width="406" border="0" />
+</p>
+<p class="picturetext" align="center">
+ The phases and milestones of a project
+</p>
+<p>
+ Each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed to
+ determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to
+ the next phase.
+</p>
+<p>
+ At the end of the <strong>Inception</strong> phase is the first major project milestone or <strong>Lifecycle Objectives
+ Milestone</strong>. At this point, you examine the cost versus benefits of the project, and decide either to proceed
+ with the project or to cancel it.
+</p>
+<p>
+ At the end of the <strong>Elaboration</strong> phase is the second important project milestone, the <strong>Lifecycle
+ Architecture Milestone</strong>. At this point, a baseline of requirements is agreed to, you examine the detailed
+ system objectives and scope, the choice of architecture, and the resolution of the major risks.
+</p>
+<p>
+ At the end of the <strong>Construction</strong> phase is the third important project milestone, the <strong>Initial
+ Operational Capability Milestone</strong>. At this point, the product is ready to be handed over to the transition
+ team. All functionality has been developed and all alpha testing (if any) has been completed. In addition to the
+ software, a user manual has been developed, and there is a description of the current release. The product is ready for
+ beta testing.
+</p>
+<p>
+ At the end of the <strong>Transition</strong> phase is the fourth important project milestone, the <strong>Product
+ Release Milestone</strong>. At this point, you decide if the objectives were met, and if you should start another
+ development cycle. The Product Release Milestone is the result of the customer reviewing and accepting the project
+ deliverables.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/pattern.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/pattern.xmi
new file mode 100644
index 0000000..35b7540
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/pattern.xmi
@@ -0,0 +1,288 @@
+<?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" epf:version="1.0.0" xmi:id="_QvmkAMM1EdmSIPI87WLu3g" name="patterns,_0YJvUMlgEdmt3adZL5Dmdw" guid="_QvmkAMM1EdmSIPI87WLu3g" changeDate="2007-02-26T09:45:45.531+0000" version="1.0.0">
+ <mainDescription><h4>
+ Origins
+</h4>
+<p>
+ The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
+ written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
+ books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE79</a>] have had the greatest impact on the software community and the adoption of
+ software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
+ capture of software design expertise in a form that can then be reapplied in recurring situations.
+</p>
+<h4>
+ A definition of patterns
+</h4>
+<p>
+ Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]:
+</p>
+<blockquote>
+ <p>
+ "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
+ and classes, when to apply the solution, and the consequences of applying the solution."
+ </p>
+</blockquote>
+<p>
+ This definition often serves only as a starting point, however. A richer definition, based on Alexander’s work, is
+ offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
+ among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
+ configuration that allows these forces to resolve themselves.
+</p>
+<h4>
+ Describing patterns
+</h4>
+<p>
+ It is commonplace to describe patterns&nbsp;using the&nbsp;format made popular by Erich Gamma and his three colleagues
+ [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
+ description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
+ object-oriented design patterns:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
+ abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
+ of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
+ address?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Also known as:</strong> Other names for the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
+ the problem.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
+ applicable.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Structure:</strong> A graphical representation of the classes in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Collaborations:</strong> How participants collaborate to fulfil their responsibilities.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation:</strong> Guidance on the implementation of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Sample code:</strong> Code fragments that illustrate the pattern’s implementation.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Known uses:</strong> Where to find real-world examples of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
+ </p>
+ </li>
+</ul>
+<p>
+ Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
+ modification, to address other software patterns. A more general keyword format for software patterns based on
+ Alexander’s principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
+</p>
+<h4>
+ Pattern catalogs
+</h4>
+<p>
+ To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
+ the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] uses three classifiers: granularity, functionality, and structured
+ principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
+ classifies patterns into three levels of abstraction:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
+ scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
+ pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
+ are described by design patterns. The GoF pattern is an example of a design pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
+ </p>
+ </li>
+</ul>
+<p>
+ Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
+</p>
+<ul>
+ <li>
+ Structure
+ </li>
+ <li>
+ Distributed systems
+ </li>
+ <li>
+ Interactive systems
+ </li>
+ <li>
+ Adaptable systems
+ </li>
+</ul>
+<p>
+ The following table shows the categorization of their architectural patterns.
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1"
+valign="top">
+ <caption>
+ <strong>Categories for Architectural Patterns<br />
+ </strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ <div align="center">
+ <strong>Category</strong>
+ </div>
+ </th>
+ <th scope="col">
+ <div align="center">
+ <strong>Pattern</strong>
+ </div>
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Structure
+ </td>
+ <td>
+ <p>
+ Layers<br />
+ Pipes and filters<br />
+ Blackboard
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Distributed systems
+ </td>
+ <td>
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Interactive systems
+ </td>
+ <td>
+ Model view controller<br />
+ Presentation abstraction control
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p>
+ Adaptable systems
+ </p>
+ </td>
+ <td>
+ <p>
+ Reflection<br />
+ Micro kernel
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
+</p>
+<ul>
+ <li>
+ Creational
+ </li>
+ <li>
+ Structural
+ </li>
+ <li>
+ Behavioral
+ </li>
+</ul>
+<h4>
+ Pattern languages
+</h4>
+<p>
+ In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
+ The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
+ allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
+ buildings. Alexander explains that when using a pattern language:
+</p>
+<blockquote>
+ <p>
+ We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
+ always from the ones that create structure to the ones which then embellish those structures, and then to those
+ that embellish the embellishments.
+ </p>
+</blockquote>
+<p>
+ In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
+ initial context, would always lead to good design.&nbsp; Alexander&nbsp;states:
+</p>
+<blockquote>
+ <p>
+ Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of
+ arrangement, but shows us how to construct arrangements — as many as we want — which satisfies the rules.
+ </p>
+</blockquote>
+<p>
+ In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
+ The sequential application of patterns finds application in software design processes, both waterfall and iterative,
+ that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
+ a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
+ application of patterns, rather than a generative pattern language.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/refactoring.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/refactoring.xmi
new file mode 100644
index 0000000..ae3e83c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/refactoring.xmi
@@ -0,0 +1,44 @@
+<?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="-fj_9xjbrpaYNSETyCz5yJg" name="refactoring,_Poc7IPDzEdqYgerqi84oCA" guid="-fj_9xjbrpaYNSETyCz5yJg" changeDate="2006-08-21T14:03:50.568-0700">
+ <mainDescription><p>
+ Refactoring is a disciplined way to restructure code&nbsp;when small changes are made to&nbsp;the code to improve its
+ design.&nbsp; An important aspect of a refactoring is that it improves the design while not changing the semantics
+ of&nbsp;the design; a refactoring neither adds nor removes functionality.
+</p>
+<p>
+ Refactoring enables you to evolve&nbsp;the code slowly over time, to take an iterative and incremental approach to
+ implementation.
+</p>
+<p>
+ These are the types of refactoring:
+</p>
+<ol>
+ <li>
+ Code refactoring.&nbsp; Often referred to simply as refactoring, this is the refactoring of programming source
+ code.&nbsp; Examples of code refactorings include Rename Method, Encapsulate Field, Extract Class, Introduce
+ Assertion, and Pushdown Method.
+ </li>
+ <li>
+ Database refactoring.&nbsp; A database refactoring is a simple change to a database schema that improves its design
+ while retaining both its behavioral and informational semantics.&nbsp; Examples of database refactorings include
+ Rename Column, Split Table, Move Method to Database, Replace LOB with Table, Introduce Column Constraint, and Use
+ Official Data Source.
+ </li>
+ <li>
+ User interface (UI) refactoring.&nbsp; A UI refactoring is a simple change to the UI which retains its
+ semantics.&nbsp; Examples of UI refactorings include Align Entry Fields, Apply Common Button Size, Apply Common
+ Font, Indicate Format, Reword in Active Voice, and Increase Color Contrast.
+ </li>
+</ol>
+<p>
+ These are suggested resources:
+</p>
+<ul>
+ <li>
+ <a href="http://www.refactoring.com" target="_blank" >http://www.refactoring.com</a>
+ </li>
+ <li>
+ <a href="http://www.agiledata.org/essays/databaseRefactoring.html" >http://www.agiledata.org/essays/databaseRefactoring.html</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/requirement_attributes.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/requirement_attributes.xmi
new file mode 100644
index 0000000..a9ed8f5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/requirement_attributes.xmi
@@ -0,0 +1,67 @@
+<?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" epf:version="1.0.0" xmi:id="-fCBrf_5JlrmuKgyrCaKGOA" name="requirement_attributes_1,_VQ268O0KEdqHTdbLTmC5IQ" guid="-fCBrf_5JlrmuKgyrCaKGOA" authors="Chris Sibbald" changeDate="2006-09-20T14:41:34.651-0400" version="0.2">
+ <mainDescription><p>
+ Attributes are a very important source of requirements information. Just as every person has attributes (age, hair
+ color, gender), each requirement has a source, a relative importance, and time it was created. Attributes do more than
+ simply clarify a&nbsp;requirement.&nbsp; If created properly, they can yield significant information about the state of
+ the system. Just as you can run a database query to find all men with brown hair over age 30, given our human example,
+ you can run queries on the status of requirements to find&nbsp;all high-priority requirements from the customer in the
+ last 30 days. <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</p>
+<h4>
+ Examples of attributes
+</h4>
+<p>
+ Listed below is a partial list of some common attributes and a brief description of their meaning. Some attributes are
+ best described as a number, date, Boolean (true or false) or a text field for entering free format comments. Other
+ attributes can be expressed as lists. For instance, priority type is a list of high, medium, and low; Weekday is a list
+ which includes Monday, Tuesday, and so on.
+</p>
+<p>
+ <em>Source</em> - Person, document or other origin of a given requirement.&nbsp; This is&nbsp;useful&nbsp;for
+ determining whom to call for questions or for grouping&nbsp;requirements according to the person making the demands.
+</p>
+<p>
+ <em>Priority</em> - Statement of relative importance of the requirement, either to the system (mandatory, critical,
+ optional) or to other requirements (high, medium, low). It is good to track the mandatory or high-priority
+ items&nbsp;as an indication of how well the system will meet the greatest needs or for compliance-related metrics.
+</p>
+<p>
+ <em>Assigned to</em> - Who in the organization is responsible for making sure the requirement is met (person's name or
+ organizational name).
+</p>
+<p>
+ <em>Comments</em> - Reviewer's or writer's comments on a requirement.
+</p>
+<p>
+ <em>Difficulty</em> - An indication of the level of effort needed or how hard it will be to implement the requirement
+ (high, medium, low).
+</p>
+<p>
+ <em>Status</em> - Degree of completeness (completed, partial, not started).
+</p>
+<p>
+ <em>Risk</em> - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium,
+ low or the integers one through ten.
+</p>
+<p>
+ <em>Due By</em> - Date the requirement must be provided.
+</p>
+<p>
+ <em>Method of verification</em> - Qualification type to be used to verify that a requirement has been met: analysis,
+ demonstration, inspection, test, and walkthrough.
+</p>
+<p>
+ <em>Level of Test</em> - Describes the verification lifecycle stage at which the requirement is determined to be met:
+ unit test, component, system or product.
+</p>
+<p>
+ <em>Subsystem Allocation</em> - Name of system or subsystem a requirement is to be assigned to (for instance, flight
+ control module, wing assembly, passenger cabin).
+</p>
+<p>
+ <em>Test Number</em> - Identification of a specific test or other method of verification.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/requirements.xmi
new file mode 100644
index 0000000..e49ae58
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/requirements.xmi
@@ -0,0 +1,70 @@
+<?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" epf:version="1.0.0" xmi:id="_eUfzwMMyEdmdo9HxCRR_Gw" name="requirements,_0Wh-sMlgEdmt3adZL5Dmdw" guid="_eUfzwMMyEdmdo9HxCRR_Gw" changeDate="2006-12-21T11:21:47.640-0500" version="1.0.0">
+ <mainDescription><p>
+ Requirements are the project team's to-do list.
+</p>
+<p align="left">
+ Requirements define what is needed and focus the project team. They are the primary method used to communicate the
+ goals of the project to everyone on the team.
+</p>
+<div class="O" v:shape="_x0000_s1026">
+ <div style="mso-line-spacing: '100 30 0'">
+ Requirements define:
+ </div>
+</div>
+<ul>
+ <li>
+ What the&nbsp;stakeholders&nbsp;need; and
+ </li>
+ <li>
+ What the system must include to satisfy the stakeholder needs.
+ </li>
+</ul>
+<p align="left">
+ Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning
+ work, verifying and validating the system (acceptance), and managing the scope of the project.
+</p>
+<p align="left">
+ Requirements may take different forms, including Use Cases and Scenarios, unstructured text, structured text, or a
+ combination, and they may be stated at different levels of granularity. At the highest level of granularity,&nbsp;<a
+ class="elementLink" href="./../../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">Feature</a>s define the services that the system must provide to solve the customer's
+ problem. These are captured as structured or unstructured text in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>. At the next level of granularity, Use Cases define the
+ functionality that the system must provide to&nbsp;deliver the required features. These are captured&nbsp;as Use Cases
+ (see <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>)&nbsp;that describe the sequence of actions performed by the
+ system to yield an observable result of value.
+</p>
+<p>
+ A system must perform according to the behavior that Use Cases specify. However, there are system requirements that do
+ not represent a specific behavior:
+</p>
+<ul>
+ <li>
+ Legal and regulatory requirements, as well as application standards
+ </li>
+ <li>
+ Quality attributes of the system to be built, including usability, reliability, performance, and supportability
+ requirements
+ </li>
+ <li>
+ Interface requirements to be able to communicate with external systems
+ </li>
+ <li>
+ Design constraints, such as those for operating systems and environments and for compatibility with other software
+ </li>
+</ul>
+<p>
+ These quality requirements are often referred to as <strong>non-functional</strong> requirements.
+</p>
+<p>
+ Quality requirements that apply to the system as a whole are captured as structured text in <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>.&nbsp; Quality requirements that are closely
+ associated with a particular Use Case are often captured in the Use Case itself to simplify review, understanding, and
+ maintenance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF
new file mode 100644
index 0000000..c3428b5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG
new file mode 100644
index 0000000..a1b1f17
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/EBCDiagram.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/EBCDiagram.JPG
new file mode 100644
index 0000000..67970fe
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/EBCDiagram.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/co_phas1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/co_phas1.gif
new file mode 100644
index 0000000..919e282
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/co_phas1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/extend1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/extend1.gif
new file mode 100644
index 0000000..586ded0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/extend1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/im_uc.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/im_uc.gif
new file mode 100644
index 0000000..f271c09
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/im_uc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/include1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/include1.gif
new file mode 100644
index 0000000..aa80996
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/include1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/iteration_1.GIF b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/iteration_1.GIF
new file mode 100644
index 0000000..1f1a19b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/iteration_1.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_actg2.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_actg2.gif
new file mode 100644
index 0000000..547c9ae
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_actg2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_acto2.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_acto2.gif
new file mode 100644
index 0000000..29ede3a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_acto2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_acto3.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_acto3.gif
new file mode 100644
index 0000000..43fbf21
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_acto3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_ucmo2.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_ucmo2.gif
new file mode 100644
index 0000000..19e278e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/md_ucmo2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/testFirstDesign.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/testFirstDesign.jpg
new file mode 100644
index 0000000..6da383c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/testFirstDesign.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucgen1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucgen1.gif
new file mode 100644
index 0000000..cd77583
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucgen1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucmex3.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucmex3.gif
new file mode 100644
index 0000000..137ba23
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucmex3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucprepst.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucprepst.gif
new file mode 100644
index 0000000..5f9e869
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucprepst.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucstrct.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucstrct.gif
new file mode 100644
index 0000000..4458bcb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/ucstrct.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/visual.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/visual.gif
new file mode 100644
index 0000000..6f4674c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/resources/visual.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk.xmi
new file mode 100644
index 0000000..4db93e7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk.xmi
@@ -0,0 +1,96 @@
+<?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" epf:version="1.0.0" xmi:id="_u6enMMM1EdmSIPI87WLu3g" name="risk,_0bsLgMlgEdmt3adZL5Dmdw" guid="_u6enMMM1EdmSIPI87WLu3g" changeDate="2006-10-31T11:18:15.095-0800">
+ <mainDescription><h3>
+ What is a Risk?
+</h3>
+<p>
+ Many decisions are driven by risk mitigation&nbsp;in well managed projects. You are trying to mitigate or tackle the
+ most critical risks as early as possible in the project. In order to achieve this you need to get a good grip on the
+ risks the project is faced with, and have clear strategies on how to mitigate or deal with them.
+</p>
+<p>
+ In everyday life a risk is an exposure to loss or injury; a factor, thing, element, or course involving uncertain
+ danger.&nbsp;Similarly, in&nbsp;software development a risk is something that can compromise the success of a project.
+ Examples of potential sources of risk in software development are listed below (see [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>] for more details):
+</p>
+<ul>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Design
+ </li>
+ <li>
+ Development process
+ </li>
+ <li>
+ Work environment
+ </li>
+ <li>
+ Resources
+ </li>
+ <li>
+ Contract
+ </li>
+ <li>
+ Project interdependencies
+ </li>
+ <li>
+ etc.
+ </li>
+</ul>
+<p>
+ Risks can be seen as opportunities. If there are benefits associated to an opportunity, then certain degrees of risk
+ must be taken&nbsp;for a&nbsp;project to be&nbsp;successful [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>].
+</p>
+<h3>
+ Risk Attributes
+</h3>
+<p>
+ You can record as much information as you like or need about your risks, you will find below a list of common risk
+ attributes.
+</p>
+<ul>
+ <li>
+ <strong>Risk Description:</strong> A description of the risk detailing the impact for the project if this risk
+ becomes a problem (i.e. it becomes a reality).
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Type:</strong> Used to classify the risk as:
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <strong>Direct risk</strong>: a risk that the project has a large degree of control over.
+ </li>
+ <li>
+ <strong>Indirect risk</strong>: a risk with little or no project control.
+ </li>
+ </ul>
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Probability</strong> (of occurence): how many chances do we have that this risk will become
+ a&nbsp;problem or an issue, This is usually represented as a scale of values (for example: High, Medium, Low).
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Impact</strong> (level): if this risk become an problem what will be the impact&nbsp;on
+ the&nbsp;project. This is not the actual description of the impact but the level of impact. As the risk
+ probability, it is usually represented as a scale.&nbsp;This&nbsp;attribute is&nbsp;also sometimes called the
+ <strong>severity</strong> of the risk.
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Magnitude</strong>: To be able to rank and to define which ones need to be mitigate first,&nbsp;the
+ <strong>Risk Probability&nbsp;</strong> and <strong>Risk Impact</strong> attributes are often combined in a
+ single&nbsp;<strong>Risk</strong> <strong>Magnitude</strong> indicator represented as a scale similar to the
+ combined attributes.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk_management.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk_management.xmi
new file mode 100644
index 0000000..d4431be
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk_management.xmi
@@ -0,0 +1,83 @@
+<?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" epf:version="1.0.0" xmi:id="-HhGIkAPjHSIxnPzI3cyDnQ" name="new_concept,_VNxL4ACsEdu8m4dIntu6jA" guid="-HhGIkAPjHSIxnPzI3cyDnQ" changeDate="2006-10-31T11:44:13.295-0800">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Every project contains some measure of uncertainty. The role of <strong>Risk Management</strong> is to deal with this
+ uncertainty to try to understand its&nbsp;potential influence on the project. Project risks may be seen as threats or
+ opportunities. The former means the risk should be mitigated (see risk management strategies below) where the latter
+ means that&nbsp;taking a&nbsp;calculated risk may bring, for example, competitive advantage for a product or
+ organization [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>].
+</p>
+<p>
+ Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. A
+ common mistake is to identify risks only at the beginning of the project and then only track the status of these
+ initial risks. The risk list should be revisited weekly, or as a minimum once per iteration, to add any newly
+ discovered risk.
+</p>
+<h3>
+ Risks Prioritization
+</h3>
+<p>
+ A good approach for prioritizing risks is to have an attribute called risk magnitude, a combination of the risk
+ probability and the risk impact. Each iteration provides a chance&nbsp;for better understanding of stakeholder needs,
+ the team capabilities, the technology at hand, and so on. Capture, quantify&nbsp;and prioritize risks as they arise.
+ High magnitude risks are&nbsp;attacked first, thus&nbsp;improving the chances of project success and minimizing
+ uncertainty. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/templates/risk_list,_MIUO0C8FEduzydamRseoUw.html" guid="_MIUO0C8FEduzydamRseoUw">Template: Risk List</a>&nbsp;for more information.
+</p>
+<h3>
+ Risk Management Strategies
+</h3>
+<p>
+ Once you have chosen a set of risks to focus on, choose a mitigation strategy, as described below. Then, identify and
+ assign tasks to apply the strategy to the given risk. Follow up regularly on risk-mitigation actions. Try another
+ strategy if your chosen strategy does not reduce the magnitude of a risk.
+</p>
+<p>
+ Common mitigation strategies are:
+</p>
+<ul>
+ <li>
+ Risk avoidance: reorganize the project so that it cannot be affected by that risk.
+ <ul>
+ <li>
+ For example: you need to use a new framework. A risk avoidance strategy could be to drop this new framework
+ and using another one that is already understood by the team.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk transfer: reorganize the project so that someone or something else bears the risk.
+ <ul>
+ <li>
+ For example: the application you are developing needs to communicate with a legacy system. A risk transfer
+ strategy&nbsp;would make the legacy support team responsible of providing the APIs to access the legacy
+ system.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk mitigation: define a mitigation plan to&nbsp;reduce the probability or the impact of the risk.
+ <ul>
+ <li>
+ For example: you need to use a new middleware. A risk mitigation strategy could be to build a prototype
+ using this new middleware to validate that&nbsp;it will provide the features you need for your
+ application.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk acceptance: decide to live with the risk, and define a contingency plan.
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ For example: your integrator is the only one who knows how to integrate the different components of your
+ application. A contingency plan could be to identify a resource on another project that you could bring on
+ if your integrator is sick, leaves the company, etc.
+ </li>
+ </ul>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/software_architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/software_architecture.xmi
new file mode 100644
index 0000000..873ede0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/software_architecture.xmi
@@ -0,0 +1,210 @@
+<?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" epf:version="1.0.0" xmi:id="-UQ_e8kozIP11Xu008RJd-A" name="new_concept,__O7tAMVvEduLYZUGfgZrkQ" guid="-UQ_e8kozIP11Xu008RJd-A" changeDate="2007-02-26T09:06:26.812+0000">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially
+ with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line
+ between design and architecture-architecture is one aspect of design that concentrates on some specific features.
+</p>
+<p>
+ In An Introduction to Software Architecture, David Garlan and Mary Shaw suggest that software architecture is a level
+ of design concerned with issues: "Beyond the algorithms and data structures of the computation; designing and
+ specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization
+ and global control structure; protocols for communication, synchronization, and data access; assignment of
+ functionality to design elements; physical distribution; composition of design elements; scaling and performance; and
+ selection among design alternatives." <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[GAR93]</a>
+</p>
+<p>
+ But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the
+ highest-level concept of a system in its environment" <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[IEP1471]</a>. It also encompasses the "fit" with system integrity, with economical
+ constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into
+ consideration the system as a whole in its user environment and its development environment - an outward focus.
+</p>
+<p>
+ In OpenUP, the architecture of a software system (at a given point) is the organization or structure of the system's
+ significant components interacting through interfaces, with components composed of successively smaller components and
+ interfaces.
+</p>
+<h3>
+ Architecture Description
+</h3>
+<p>
+ To speak and reason about software architecture, you must first define an architectural representation, a way of
+ describing important aspects of an architecture. In OpenUP, this description is captured in the <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
+</p>
+<h3>
+ Architectural Views
+</h3>
+<p>
+ We have chosen to represent software architecture in multiple architectural views. Each architectural view addresses
+ some specific set of concerns, specific to stakeholders in the development process: users, designers, managers, system
+ engineers, maintainers, and so on.
+</p>
+<p>
+ The views capture the major structural design decisions by showing how the software architecture is decomposed into
+ components, and how components are connected by connectors to produce useful forms <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the Requirements, functional, and
+ supplementary, and other constraints. But these choices in turn put further constraints on the requirements and on
+ future design decisions at a lower level.
+</p>
+<h3>
+ Architectural Focus
+</h3>
+<p>
+ Although the views above could represent the whole design of a system, the architecture concerns itself only with some
+ specific aspects:
+</p>
+<ul>
+ <li>
+ The structure of the model - the organizational patterns, for example, Layering.
+ </li>
+ <li>
+ The essential elements - critical use cases, main classes, common mechanisms, and so on, as opposed to all the
+ elements present in the model.
+ </li>
+ <li>
+ A few key scenarios showing the main control flows throughout the system.
+ </li>
+ <li>
+ The services, to capture modularity, optional features, product-line aspects.
+ </li>
+</ul>
+<p>
+ In essence, architectural views are abstractions, or simplifications, of the entire design, in which important
+ characteristics are made more visible by leaving details aside. These characteristics are important when reasoning
+ about:
+</p>
+<ul>
+ <li>
+ System evolution-going to the next development cycle.
+ </li>
+ <li>
+ Reuse of the architecture, or parts of it, in the context of a product line.
+ </li>
+ <li>
+ Assessment of supplementary qualities, such as performance, availability, portability, and safety.
+ </li>
+ <li>
+ Assignment of development work to teams or subcontractors.
+ </li>
+ <li>
+ Decisions about including off-the-shelf components.
+ </li>
+ <li>
+ Insertion in a wider system.&nbsp;
+ </li>
+</ul>
+<h3>
+ Architectural Patterns
+</h3>
+<p>
+ Architectural patterns are ready-made forms that solve recurring architectural problems. An architectural framework or
+ an architectural infrastructure (middleware) is a set of components on which you can build a certain kind of
+ architecture. Many of the major architectural difficulties should be resolved in the framework or in the
+ infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.
+</p>
+<h4>
+ Examples of Architectural Patterns
+</h4>
+<p>
+ <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> groups architectural patterns according to the characteristics of the
+ systems in which they are most applicable, with one category dealing with more general structuring issues. The table
+ shows the categories presented in <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> and the patterns they contain.
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th id="col1" width="50%">
+ Category
+ </th>
+ <th id="col2" width="50%">
+ Pattern
+ </th>
+ </tr>
+ <tr>
+ <th id="row2" align="left" headers="col1" width="50%" rowspan="3">
+ Structure
+ </th>
+ <td headers="row2 col2" width="50%">
+ Layers
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Pipes and Filters
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Blackboard
+ </td>
+ </tr>
+ <tr>
+ <th id="row3" align="left" headers="col1" width="50%">
+ Distributed Systems
+ </th>
+ <td headers="row3 col2" width="50%">
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <th id="row4" align="left" headers="col1" width="50%" rowspan="2">
+ Interactive Systems
+ </th>
+ <td headers="row4 col2" width="50%">
+ Model-View-Controller
+ </td>
+ </tr>
+ <tr>
+ <td headers="row4 col2" width="50%">
+ Presentation-Abstraction-Control
+ </td>
+ </tr>
+ <tr>
+ <th id="row5" align="left" headers="col1" width="50%" rowspan="2">
+ Adaptable Systems
+ </th>
+ <td headers="row5 col2" width="50%">
+ Reflection
+ </td>
+ </tr>
+ <tr>
+ <td headers="row5 col2" width="50%">
+ Microkernel
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ Refer to <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> for a complete description of these patterns.
+</p>
+<h3>
+ <a id="Architectural Style" name="Architectural Style">Architectural Style</a>
+</h3>
+<p>
+ A software architecture, or only an architectural view, may have an attribute called <b>architectural style</b>, which
+ reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The
+ style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building
+ blocks.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/supporting_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/supporting_requirements.xmi
new file mode 100644
index 0000000..4530903
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/supporting_requirements.xmi
@@ -0,0 +1,101 @@
+<?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" epf:version="1.0.0" xmi:id="-3SXuKijeVOZalgLPgWRyFA" name="supporting_requirements_1,_VXZ5wO0IEdqHTdbLTmC5IQ" guid="-3SXuKijeVOZalgLPgWRyFA" authors="Chris Sibbald" changeDate="2006-12-21T12:31:36.206-0500" version="0.2">
+ <mainDescription><h3>
+ Definition
+</h3>
+<p>
+ Supporting requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
+ usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral
+ requirements artifacts such as use-cases.
+</p>
+<h3>
+ Supporting Requirements Categories
+</h3>
+<p>
+ Supporting requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability, Performance,
+ Supportability + constraints). Constraints&nbsp;include design, implementation, interfaces, physical constraints, and
+ business rules. A description of each of these types of requirements follows.
+</p>
+<p>
+ Supporting requirements and Use Cases, together, define the requirements of the system. These requirements support the
+ features listed in the Vision statement. Each requirement should&nbsp;support at least one feature, and each feature
+ should be supported by at least one to requirement.
+</p>
+<p>
+ In general, <strong>functional</strong> requirements describe behavior and are captured in&nbsp;Use Cases (see&nbsp;<a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>). <strong>Non-functional</strong> requirements are captured in
+ the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. However, nonfunctional requirements that are
+ closely associated with a particular Use Case are often captured within the Use Case itself to simplify communication
+ and maintenance.&nbsp; Similarly, there are global, or system-wide, functional requirements that are often captured
+ among the supporting requirements for the same reasons.&nbsp;
+</p>
+<h4>
+ Functional requirements
+</h4>
+<p>
+ Functionality requirements include all the overarching, system wide functional requirements. These functional
+ requirements represent the main system features that are familiar within the business domain or technically oriented
+ requirements such as auditing, licensing, localization, mail, online help, printing, reporting, security, system
+ management, or workflow.
+</p>
+<h4>
+ Usability requirements
+</h4>
+<p>
+ Usability requirements include requirements based on human factors and user interface issues such as accessibility,
+ interface aesthetics, and consistency within the user interface.
+</p>
+<h4>
+ Reliability requirements
+</h4>
+<p>
+ Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or
+ recoverability of the system from shut-down failure.
+</p>
+<h4>
+ Performance requirements
+</h4>
+<p>
+ Performance requirements address concerns such as throughput of information through the system, system response time
+ and resource usage.
+</p>
+<h4>
+ Supportability requirements
+</h4>
+<p>
+ Supportability requirements include requirements such as compatibility and the abilities to test, adapt, maintain,
+ configure, install, scale, localize, and so on.
+</p>
+<h4>
+ + Constraints
+</h4>
+<p>
+ The <strong>+</strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,
+ interfaces, physical constraints, and business rules:
+</p>
+<ul>
+ <li>
+ <strong>Design constraints</strong> limit the design and state requirements on the approach that should be taken in
+ developing the system.
+ </li>
+ <li>
+ <strong>Implementation constraints</strong> put limits on coding or construction (required standards, languages,
+ tools, or platform)
+ </li>
+ <li>
+ <strong>Interface constraints</strong> are requirements to interact with external systems, describing protocols or
+ the nature of the information that is passed across that interface.
+ </li>
+ <li>
+ <strong>Physical constraints</strong> affect the hardware or packaging housing the system (shape, size, and
+ weight).
+ </li>
+ <li>
+ <strong>Business rules</strong> are policies or decisions that govern how the business operates. They may constrain
+ the steps described in the Use Case flow.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/test_first_design.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/test_first_design.xmi
new file mode 100644
index 0000000..c5df2b4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/test_first_design.xmi
@@ -0,0 +1,83 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_Hg5UUMPbEdmbOvqy4O0adg" name="test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw" guid="_Hg5UUMPbEdmbOvqy4O0adg" changeDate="2006-08-15T17:49:28.248-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ With Test-First Design (TFD) you do detailed design in a just-in-time (JIT) manner&nbsp;via writing a single test
+ before writing just enough production code to fulfill that test.&nbsp; When you have new functionality to add to your
+ system, perform the following steps:
+</p>
+<ol>
+ <li>
+ <strong>Quickly add a test</strong>.&nbsp; You need just enough code to fail.&nbsp;
+ </li>
+ <li>
+ <strong>Run your tests</strong>.&nbsp; You will&nbsp;typically run the complete test suite, although for sake of
+ speed you may decide to run only a subset.&nbsp; The goal is&nbsp;to ensure that the new test does in fact
+ fail.&nbsp;
+ </li>
+ <li>
+ <strong>Update your production code</strong>.&nbsp;&nbsp;The goal is to add just enough functionality so that
+ your&nbsp;code&nbsp;passes the new test.&nbsp;
+ </li>
+ <li>
+ <strong>Run your test suite&nbsp;again</strong>.&nbsp; If they tests fail you need to update your functional code
+ and retest.&nbsp; Once the tests pass, start over.&nbsp;
+ </li>
+</ol>
+<br />
+<p>
+ <img height="600" alt="Test First Design Flow" src="./resources/testFirstDesign.jpg" width="294" />&nbsp;
+</p>
+<h4>
+ Why TFD?
+</h4>
+<p>
+ A significant advantage of TFD is that it enables you to take small steps when writing software, which is not only
+ safer it is also far more productive than writing code&nbsp;in large steps.<span style="mso-spacerun: yes">&nbsp;</span> For example, assume you add some new functional code, compile, and test
+ it.<span style="mso-spacerun: yes">&nbsp;</span> Chances are pretty good that your tests will be broken by defects that
+ exist in the new code.<span style="mso-spacerun: yes">&nbsp;</span> It is much easier to find, and then fix, those
+ defects if you've written five new lines of code than in fifty lines. The implication is that the faster your compiler
+ and regression test suite, the more attractive it is to proceed in smaller and smaller steps.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p>
+ There are three other common testing strategies (in order of effectiveness).
+</p>
+<ol>
+ <li>
+ <strong>Write&nbsp;several tests first</strong>.&nbsp; This is a variant of TFD where you write more than one test
+ before writing just enough production code to fulfill those tests.&nbsp; The advantage is that you don't need to
+ build your system as often,&nbsp;potentially saving time.&nbsp; It&nbsp;has the disadvantage that you will write
+ more&nbsp;production code at once, increasing the difficulty of finding any new bugs that you do introduce.
+ </li>
+ <li>
+ <strong>Test after the fact</strong>.&nbsp; With this approach you write some production code then you write enough
+ testing code to validate it.&nbsp; This has the advantage that you're at least still validating the code but has
+ the disadvantage that you lose the design benefit inherent in writing the testing code first.
+ </li>
+ <li>
+ <strong>Don't test at all</strong>.&nbsp; This is a really bad idea.
+ </li>
+</ol>
+<br />
+<h3>
+ Good Things to Know
+</h3>
+<p>
+ 1. An underlying assumption of TDD is that you have a unit-testing framework available to you.<span style="mso-spacerun: yes">&nbsp;</span> Agile software developers often use the xUnit family of open source tools, such
+ as <a href="http://www.junit.org/" ><strong>JUnit</strong></a> or <a href="http://www.vbunit.org/" ><strong>VBUnit</strong></a>, although commercial tools are
+ also viable options.<span style="mso-spacerun: yes">&nbsp;&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p>
+ 2. Test-Driven Design (TDD) = TFD + <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
+</p>
+<p>
+ 3. TFD/TDD is commonly used with object-oriented business code, although you can also take this approach with
+ procedural code, user-interface code, and your database code if you choose to.
+</p>
+<p>
+ 4. A more thorough discussion of TFD and TDD is presented at <a href="http://www.agiledata.org/essays/tdd.html" target="_blank" >Introduction to Test Driven Development (TDD)</a>.
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/test_ideas.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/test_ideas.xmi
new file mode 100644
index 0000000..e63ea87
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/test_ideas.xmi
@@ -0,0 +1,37 @@
+<?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="_uqL2gMM3EdmSIPI87WLu3g" name="test_ideas,_0jnYcMlgEdmt3adZL5Dmdw" guid="_uqL2gMM3EdmSIPI87WLu3g" changeDate="2006-07-20T15:10:39.401-0700">
+ <mainDescription><p>
+ <strong>Test Ideas List</strong> - A list of brief statements identifying tests that are potentially useful to conduct.
+</p>
+<p>
+ <strong>Test Ideas Catalog</strong> - A catalog of common faults and mistakes done when developing software.
+</p>
+<ul>
+ <li>
+ Test Ideas will describe any of the elements of an executable test.&nbsp;
+ </li>
+ <li>
+ Test ideas ensure the important ideas are not forgotten and are detailed later in test cases.&nbsp;&nbsp;
+ </li>
+ <li>
+ Test Ideas are to be captured at a less-specific level in an intermediate form.
+ </li>
+ <li>
+ Test ideas are more reviewable and understandable then complete tests.&nbsp; Making the reasoning behind the test
+ idea clearer.&nbsp;
+ </li>
+ <li>
+ Test ideas support more powerful test, by not constraining the tester.&nbsp; Making it easier to create tests that
+ validate more then just the defined requirements.
+ </li>
+ <li>
+ Test Ideas are often based on explicit and implicit fault modules, to include but not limited to Booleans,
+ boundaries and method calls.&nbsp; Test Ideas Lists will contain test ideas from many faults models derived for one
+ or many work products.
+ </li>
+</ul>
+<p>
+ Creating test ideas before testing for review and inspection of design work products assists in discovering design or
+ analysis errors.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/traceability.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/traceability.xmi
new file mode 100644
index 0000000..d4ec53b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/traceability.xmi
@@ -0,0 +1,62 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-TksCtMgc0b4QqzwzniGvIw" name="traceability_1,_eYtQQO0KEdqHTdbLTmC5IQ" guid="-TksCtMgc0b4QqzwzniGvIw" authors="Chris Sibbald" changeDate="2006-05-01T15:37:44.378-0700" changeDescription="Added concept in accordance with Feb 23, 2006 minutes of RM SIG meeting." version="0.1">
+ <mainDescription><p align="left"> Traceability is about understanding how high-level requirements
+ (objectives, goals, aims, aspirations, expectations, needs) are transformed
+ into low-level requirements, how they are implemented, and how they are verified.
+</p>
+<p>
+ Using traceability can provide the following benefits <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#HUL05"
+ guid="_9ToeIB83Edqsvps02rpOOg">[HUL05]</a>:
+</p>
+<ul>
+
+ <li> <strong>Greater confidence in meeting objectives </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Establishing traceability engenders greater reflection on how objectives
+ are satisfied.&nbsp; Traceability permits coverage analysis to ensure that
+ everything you have done everything that you agreed to do and only what you
+ agreed to do.</p>
+</blockquote>
+<ul>
+
+ <li> <strong>Ability to assess the impact of change </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p> Traceability permits various forms of impact analysis that can be used to
+ assess the impact of a proposed change on the cost, schedule, and technical
+ aspects of the project.</p>
+</blockquote>
+<ul>
+
+ <li><strong> Improved accountability </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Traceability provides great clarity about how work contributes to the
+ whole. </p>
+</blockquote>
+<ul>
+ <li><strong> Ability to track progress </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> It is notoriously difficult to measure progress when all that you are doing
+ is creating and revising artifacts. Traceability processes allow precise measures
+ of progress, such as: Is there a design artifact for each requirement? Is
+ there a test case for each requirement?. </p>
+</blockquote>
+<ul>
+
+ <li><strong> Ability to balance cost against benefit </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Relating product components to the requirements allows you to compare benefits
+ to costs. </p>
+</blockquote>
+<br dir="ltr" />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/transition_phase.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/transition_phase.xmi
new file mode 100644
index 0000000..f3da272
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/transition_phase.xmi
@@ -0,0 +1,97 @@
+<?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" epf:version="1.0.0" xmi:id="-FrUmsKsGW4bnNmb9uaNOkg" name=",__ca5UBOMEduCNqgZdt_OaA" guid="-FrUmsKsGW4bnNmb9uaNOkg" changeDate="2006-09-27T16:29:45.049-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose in this phase is to ensure that the software is ready for delivery to users.
+</p>
+<p>
+ There are objectives for the Transition phase that help you to&nbsp;fine-tune functionality, performance, and overall
+ quality of the beta product from the end of&nbsp;the previous phase <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Beta test to validate that user expectations are met.</strong> This typically requires some fine-tuning
+ activities, such as bug-fixing and making enhancements for performance and usability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Achieve stakeholder concurrence that deployment is complete.</strong> This may involve various levels
+ of tests for product acceptance, including formal and informal tests and beta tests.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Improve future project performance through lessons learned.</strong> Document lessons learned and
+ improve the process and tool environment for the project.
+ </p>
+ </li>
+</ol>
+<p>
+ The following table summarizes the&nbsp;Transition phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <strong>Transition phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300" height="62">
+ Beta test to validate that user expectations are met
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../ongoing_tasks,_0qxwYclgEdmt3adZL5Dmdw.html" guid="_0qxwYclgEdmt3adZL5Dmdw">Ongoing Tasks</a><br />
+ <a class="elementLinkWithUserText" href="./../../../develop_requirement_within_context,_0DMlYPinEdmugcVr9AdHjQ.html" guid="_0DMlYPinEdmugcVr9AdHjQ">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0qrpwslgEdmt3adZL5Dmdw.html" guid="_0qrpwslgEdmt3adZL5Dmdw">Validate Build</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Achieve stakeholder concurrence that deployment is complete
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0qrpwslgEdmt3adZL5Dmdw.html" guid="_0qrpwslgEdmt3adZL5Dmdw">Validate Build</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Improve future project performance through lessons learned
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<h4>
+ <br />
+ Key considerations<br />
+</h4>
+<p>
+ The Transition phase can include running old and new systems in parallel, migrating data, training users, and adjusting
+ business processes.
+</p>
+<p>
+ The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily
+ minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to
+ make the business transition from using the old system to using the new system.
+</p>
+<p>
+ When the Transition phase objectives are met, the project is in position to be closed.&nbsp;For some products, the end
+ of the current project lifecycle may coincide with the beginning of the next lifecycle, leading to the next generation
+ of the same product.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/types_of_test.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/types_of_test.xmi
new file mode 100644
index 0000000..9fab0f1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/types_of_test.xmi
@@ -0,0 +1,148 @@
+<?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" epf:version="1.0.0" xmi:id="_y-_PIMPdEdmbOvqy4O0adg" name="types_of_test,_0aJ6cMlgEdmt3adZL5Dmdw" guid="_y-_PIMPdEdmbOvqy4O0adg" changeDate="2006-09-20T15:37:14.071-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ There is much more to testing computer software than simply evaluating the functions, interface, and response-time
+ characteristics of a target-of-test.&nbsp;Additional tests must focus on characteristics and attributes, such as the
+ target-of-test.
+</p>
+<ul>
+ <li>
+ integrity (resistance to failure)
+ </li>
+ <li>
+ ability to be installed and executed on different platforms
+ </li>
+ <li>
+ ability to handle many requests simultaneously
+ </li>
+</ul>
+<p>
+ To achieve this, many different types of tests are implemented and executed.&nbsp;Each test type has a specific
+ objective and support technique.&nbsp;Each technique focuses on testing one or more characteristics or attributes of
+ the target-of-test.
+</p>
+<p>
+ The following sections list the types of test based on the most obvious <strong>quality dimensions</strong> they
+ address.
+</p>
+<h3>
+ Quality Dimension: Functionality
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Function test:</strong>&nbsp;Tests focused on validating the target-of-test functions as intended, providing
+ the required services, methods, or use cases. This test is implemented and executed against different targets-of-test,
+ including units, integrated units, applications, and systems.
+</p>
+<p>
+ <strong>Security test:</strong>&nbsp;Tests focused on ensuring the target-of-test data (or systems) are accessible only
+ to those actors for which they are intended. This test is implemented and executed on various targets-of-test.
+</p>
+<p>
+ <strong>Volume test:</strong>&nbsp;Tests focused on verifying the target-of-test's ability to handle large amounts of
+ data, either as input and output or resident within the database.&nbsp;Volume testing includes test strategies such as
+ creating queries that would return the entire contents of the database, or that would have so many restrictions that no
+ data is returned, or where the data entry has the maximum amount of data for each field.
+</p>
+<h3>
+ Quality Dimension:&nbsp;Usability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Usability test:</strong>&nbsp;Tests that focus on:
+</p>
+<ul>
+ <li>
+ human factors
+ </li>
+ <li>
+ esthetics
+ </li>
+ <li>
+ consistency in the user interface
+ </li>
+ <li>
+ online and context-sensitive help
+ </li>
+ <li>
+ wizards and agents
+ </li>
+ <li>
+ user documentation
+ </li>
+ <li>
+ training materials
+ </li>
+</ul>
+<p>
+ <strong>Integrity test:</strong>&nbsp;Tests that focus on assessing the target-of-test's robustness (resistance to
+ failure), and technical compliance to language, syntax, and resource usage.&nbsp;This test is implemented and executed
+ against different targets-of-tests, including units and integrated units.
+</p>
+<p>
+ <strong>Structure test</strong>: Tests that focus on assessing the target-of-test's adherence to its design and
+ formation.&nbsp;Typically, this test is done for Web-enabled applications ensuring that all links are connected,
+ appropriate content is displayed, and no content is orphaned.
+</p>
+<h3>
+ Quality Dimension: Reliability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Stress test:</strong>&nbsp; A type of reliability test that focuses on evaluating how the system responds under
+ abnormal conditions.&nbsp;Stresses on the system could include extreme workloads, insufficient memory, unavailable
+ services and hardware, or limited shared resources.&nbsp;These tests are often performed to gain a better understanding
+ of how and in what areas the system will break, so that contingency plans and upgrade maintenance can be planned and
+ budgeted for well in advance.
+</p>
+<p>
+ <strong>Benchmark test:</strong>&nbsp; A type of performance test that compares the performance of a new or unknown
+ target-of-test to a known reference-workload and system.
+</p>
+<p>
+ <strong>Contention test:</strong>&nbsp; Tests focused on validating the target-of-test's ability to acceptably handle
+ multiple actor demands on the same resource (data records, memory, and so on).
+</p>
+<h3>
+ Quality Dimension: Performance
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Load test:</strong>&nbsp; A type of performance test used to validate and assess acceptability of the
+ operational limits of a system under varying workloads while the system-under-test remains constant.&nbsp;In some
+ variants, the workload remains constant and the configuration of the system-under-test is varied.&nbsp; Measurements
+ are usually taken based on the workload throughout and in-line transaction response time.&nbsp;The variations in
+ workload usually include emulation of average and peak workloads that occur within normal operational tolerances.
+</p>
+<p>
+ <strong>Performance profile:</strong> A test in which the target-of-test's timing profile is monitored, including
+ execution flow, data access, function and system calls to identify and address both performance bottlenecks and
+ inefficient processes.
+</p>
+<p>
+ <strong>Configuration test:</strong>&nbsp; Tests focused on ensuring the target-of-test functions as intended on
+ different hardware and software configurations.&nbsp;This test might also be implemented as a system performance test.
+</p>
+<h3>
+ Quality Dimension: Supportability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Installation test:</strong>&nbsp; Tests focused on ensuring the target-of-test installs as intended on
+ different hardware and software configurations, and under different conditions (such as insufficient disk space or
+ power interruptions).&nbsp;This test is implemented and executed against applications and systems.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/use_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/use_case.xmi
new file mode 100644
index 0000000..96484ff
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/use_case.xmi
@@ -0,0 +1,828 @@
+<?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" epf:version="1.0.0" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2006-11-03T12:00:52.609-0500">
+ <mainDescription><h3>
+ <a id="Definitions" name="Definitions">Definitions</a>
+</h3>
+<h4>
+ Use Case
+</h4>
+<p>
+ A use case instance defines a sequence of actions performed by the system that yields an observable result of value to
+ a particular actor. There are several key words in this definition:
+</p>
+<ul>
+ <li>
+ <b>"use case instance"</b> The sequence referred to in the definition is actually a specific flow of events through
+ the system, or an instance. Many flows of events are possible, and many may be very similar. To make a use-case
+ understandable, you should group similar flows of events into one use case. Therefore, identifying and describing a
+ use case really means identifying and describing a group of related flows of events.
+ </li>
+ <li>
+ <strong>"actions"</strong> An action is a computational or algorithmic procedure. It is invoked either when the
+ actor provides a signal to the system or when the system gets a time event. An action may imply signal
+ transmissions to either the invoking actor or other actors. An action is atomic, which means it is performed either
+ entirely or not at all.
+ </li>
+ <li>
+ <b>"performed by the system"</b> This means that the system provides the use case. An actor communicates with a
+ use-case instance of the system.
+ </li>
+ <li>
+ <b>"an observable result of value"</b> You can put a value on a successfully performed use case. A use case should
+ make sure that an actor can perform a task that has an identifiable value. This is very important in determining
+ the correct level or granularity for a use case. <em>Correct level</em> refers to achieving use cases that are not
+ too small.&nbsp;&nbsp;
+ </li>
+ <li>
+ <b>"a&nbsp;particular actor"</b> The actor is key to finding the correct use case, especially because the actor
+ helps you avoid use cases that are too large. As an example, consider a visual modeling tool. There are really two
+ actors&nbsp;in this application: a developer, who develops systems using the tool as support; and a system
+ administrator, who manages the tool. Each of these actors has his own demands on the system, and will therefore
+ require his own set of use cases.
+ </li>
+</ul>
+<p>
+ The functionality of a system is defined by different use cases, each of which represents a specific goal (observable
+ result of value) for a particular actor. The description of a use case defines what happens in the system when the use
+ case is performed.
+</p>
+<p class="picturecenter" align="center">
+ <img height="173" alt="Diagram described in caption." src="./resources/im_uc.gif" width="325" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="picturetext">
+ Figure 1: ATM use case example.
+ </p>
+ </blockquote>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p>
+ In an automated teller machine the client can, for instance, withdraw money from an account, transfer money to an
+ account, or check the balance of an account. These correspond to specific goals that the actor has in using the system.
+</p>
+<p>
+ Each use case has a task of its own to perform. The collected use cases constitute all the possible ways of using the
+ system. You should be able to&nbsp;determine the goal&nbsp;of a use-case task simply by observing its name.&nbsp;&nbsp;
+</p>
+<h4>
+ <a id="A Use-Case has Many Possible Instances" name="A Use-Case has Many Possible Instances">Use-Case</a>
+ Instance&nbsp;
+</h4>
+<p>
+ A use-case can follow an almost unlimited, but enumerable, number of paths. These paths represent the choices open to
+ the use-case in the description of its flow of events. The path chosen depends on events. Types of events include:
+</p>
+<ul>
+ <li>
+ <strong>Input from an actor&nbsp;</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ For example, an actor can decide, from several options, what to do next. In the use case Recycle Items in the
+ Recycling-Machine System the Customer always has two options: insert another deposit item or get the
+ receipt&nbsp;for returned items.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>A check of values or types of an internal object or attribute</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ For example, the flow of events may differ if a value is greater or less than a certain value.&nbsp;In the use case
+ Withdraw Money in an automated teller machine system, the flow of events will differ if the Client asks for more
+ money than he has in his account. In that situation, the use-case instance follows a&nbsp;different path.
+ </p>
+</blockquote>
+<h4>
+ Scenario
+</h4>
+<p>
+ A scenario is a specific sequence of actions that illustrates a behavior.&nbsp; A scenario may be used to illustrate a
+ use-case instance and to specify test cases.
+</p>
+<h4>
+ Use-Case Realization
+</h4>
+<p>
+ A use case describes what happens in the system when an actor interacts with the system. The use case does not define
+ how the system&nbsp;performs its tasks, in terms of collaborating objects. This is left for the use-case realizations
+ to show.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In the telephone example, the use case would indicate (among other things) that the system issues a signal when the
+ actor lifts the receiver,&nbsp; and that the system then receives digits, finds the receiving party, rings his
+ telephone, connects the call, transmits speech, and so on.
+ </p>
+</blockquote>
+<p>
+ In a running&nbsp;system, an instance of a use case does not correspond to any particular object in the implementation
+ model (for example, an instance of a class in the code). Instead, it corresponds to a specific flow of events that is
+ invoked by an actor and&nbsp;performed as a sequence of events among a set of objects. In other words, instances of use
+ cases correspond to communicating instances of implemented objects. We call this the <strong>realization of the use
+ case</strong>. Often, the same objects participate in realizations of more than one use case. For example, both the use
+ cases Deposit and Withdrawal in a banking system may use a certain account object in their realization. This does not
+ mean that the two use cases communicate, but only that they use the same object in their realization.
+</p>
+<p>
+ You can&nbsp;think of&nbsp;a flow of events as consisting of several subflows that,&nbsp;taken together, yield the
+ total flow of events. You can reuse the description of a subflow in other flows of events for other use cases. Subflows
+ in the description of one use case's flow of events may be common to those of other use cases. In the design you should
+ have the same objects perform this common behavior for all the relevant use cases. That is, only one set of objects
+ should perform this behavior no matter which use case is running.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In an automated teller machine system, the initial subflow is the same in the flow of events of the use cases
+ Withdraw Money and Check Balance. The flow of events of both use cases start by checking the identity of the card
+ and the client's personal access code.
+ </p>
+</blockquote>
+<h3>
+ Properties of Use Cases
+</h3>
+<h4>
+ <a id="Name" name="Name">Name</a>
+</h4>
+<p>
+ Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have
+ to be several words to be understood. Note: No two use cases can have the same name.
+</p>
+<blockquote>
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ These are examples of variations of the name for the use case Recycle Items in the Recycling Machine example:
+ </p>
+ <ul>
+ <li>
+ Return Deposit Items
+ </li>
+ <li>
+ Deposit Items
+ </li>
+ </ul>
+</blockquote>
+<h4>
+ <a id="Brief Description" name="Brief Description">Brief Description</a>
+</h4>
+<p>
+ The brief description of the use case should reflect its purpose. As you write the description, refer to the actors
+ involved in the use case and the glossary.&nbsp;If you need to, define new concepts.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ Following are sample brief descriptions of the use cases Recycle Items and Add New Bottle Type in the
+ Recycling-Machine system.
+ </p>
+ <p class="example">
+ <b>Recycle Items</b>: The user uses this machine to automatically have all the return items (bottles, cans, and
+ crates) counted, and receives a receipt. The receipt is to be cashed at a cash register (another machine).
+ </p>
+ <p class="example">
+ <b>Add New Bottle Type</b>: The manager can add options for the user to return new kinds of bottles can be added to
+ the machine by starting it in <em>learning</em> mode and inserting 5 samples, just&nbsp;as when the customers
+ return items. The machine can measure the bottles and learns to identify them. The manager specifies the refund
+ value for the new bottle type.
+ </p>
+</blockquote>
+<h4>
+ Flow of Events
+</h4>
+<h5>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of
+ Events - Contents</a>
+</h5>
+<p>
+ The f<b>low of events</b> of a use case contains the most important information derived from use-case modeling work. It
+ should describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow
+ of events should represent <em>what</em> the system does, not <em>how</em> the system is design to perform the required
+ behavior.
+</p>
+<p>
+ Follow these guidelines for the contents of the flow of events:
+</p>
+<ul>
+ <li>
+ Describe how the use case starts and ends.
+ </li>
+ <li>
+ Describe what data is exchanged between the actor and the use case.
+ </li>
+ <li>
+ Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system.
+ For example, it is often good to use a limited set of web-specific terminology when it is known beforehand that the
+ application is going to be web-based. Otherwise, your run the risk that the use-case text is being perceived as too
+ abstract. Words to include in your terminology could be "navigate", "browse", "hyperlink" "page", "submit", and
+ "browser". However, it is not advisable to include references to "frames" or "web pages" in such a way that you are
+ making assumptions about the boundaries between them; this is a critical design decision.&nbsp;
+ </li>
+ <li>
+ Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
+ ... ".
+ </li>
+ <li>
+ Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
+ system.
+ </li>
+ <li>
+ Avoid vague terminology.
+ </li>
+ <li>
+ Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
+ test cases.
+ </li>
+</ul>
+<p>
+ If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
+ that&nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary.
+</p>
+<h5>
+ <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a>
+</h5>
+<p>
+ The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><b>alternative flows of
+ events</b>. The basic flow of events should cover what "normally" happens when the use case is performed. The
+ alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and
+ also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow
+ of events, some of which will return to the basic flow of events and some of which will end the execution of the use
+ case.
+</p>
+<p align="center">
+ <img height="212" alt="Diagram described in caption." src="./resources/ucstrct.gif" width="231" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="picturetext">
+ Figure 2: Typical structure of a use case flow of events
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p class="picturetext">
+ The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
+ relation to the normal. Some alternative paths return to the basic flow of events, whereas,&nbsp;others end the use
+ case.
+</p>
+<p>
+ Both the basic and alternative flows should be further structured into steps or subflows. In doing this, your main goal
+ should be readability of the text (see the <em>Flow of Events - Style</em> section, which follows). A&nbsp;guideline is
+ that a subflow should be a segment of behavior within the use case that has a clear purpose, and is "atomic" in the
+ sense that you do either all or none of the actions described. You may need to have several levels of subflows,
+ but&nbsp;avoid that if you can,&nbsp;since it makes the text more complex and harder to understand.
+</p>
+<p>
+ The nature of this type of written text, structured into consecutive subsections,&nbsp;implies to the reader that there
+ is a sequence between the subflows. To avoid misunderstandings, you should always point out whether the order of the
+ subflows is fixed or not. Considerations of this kind are often related to factors such as:
+</p>
+<ul>
+ <li>
+ <strong>Business rules</strong>. For example, the user has to be authorized before the system can make certain data
+ available.
+ </li>
+ <li>
+ <strong>User-interface design.</strong> For example, the system should not enforce a certain sequence of behavior
+ that may be intuitive to some but not to other users.
+ </li>
+</ul>
+<p>
+ To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
+ detour to the basic flow of events:
+</p>
+<ul>
+ <li>
+ Where the alternative flow can be inserted in the basic flow of events.
+ </li>
+ <li>
+ The condition that needs to be fulfilled for the alternative behavior to start.
+ </li>
+ <li>
+ How and where the basic flow of events is resumed, or how the use case ends.
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
+ </p>
+ <p class="example">
+ 2.1. Bottle Stuck
+ </p>
+ <p class="example">
+ If in section 1.5, Insert Deposit Items, a bottle gets stuck in the gate, the sensors around the gate and the
+ measuring gate will detect this problem. The conveyer belt is stopped and the machine issues an alarm to call for
+ the operator. The machine will wait for the operator to indicate that the problem has been fixed. The machine then
+ continues in section 1.9 of the basic flow.
+ </p>
+</blockquote>
+<p dir="ltr">
+ In the example above, the alternative flow of events is inserted at a specific location in the basic flow of events.
+ There are also alternative flow of events that can be inserted at more than one location, some can even be inserted at
+ any location in the basic flow of events.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
+ </p>
+ <p>
+ 2.2. Front Panel is Removed
+ </p>
+ <p class="example">
+ If somebody removes the front panel to the Recycling machine, the can compression is deactivated. It will not be
+ possible to start the can compression with the front panel off. The removal will also activate an
+ alarm&nbsp;for&nbsp;operator attention. When the front panel is closed again, the machine resumes operation from
+ the point where it stopped in&nbsp;the basic flow of events.
+ </p>
+</blockquote>
+<p>
+ It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
+ section (using some informal "if-then-else" construct). This should be avoided. Too many alternatives will make the
+ normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
+ text more pseudo-code like and harder to read.
+</p>
+<p>
+ In general, extracting parts of the flow of events and describing these parts separately, can increase the readability
+ of the basic flow of events and improve the structure of the use case and the use-case model. You can model extracted
+ parts as the situation requires:
+</p>
+<ul>
+ <li>
+ An <strong>alternative</strong> flow of events within the base use case if it is a simple variant, option, or
+ exception to the basic flow of events.
+ </li>
+ <li>
+ As an <strong>explicit</strong> inclusion in the base use case, if it is something that you wish to encapsulate so
+ that it can be reused by other use cases.
+ </li>
+ <li>
+ As an <strong>implicit</strong> inclusion in the base use case, if the basic flow of events of the base use case is
+ complete, that is, has a defined beginning and end. The nature of the extending flow should be such that you prefer
+ to conceal it in the description of the base use case to render it less complex.
+ </li>
+ <li>
+ A <strong>subflow</strong> in the basic flow of events, possibly as another option, if none of the above
+ alternatives applies. For example, in a Maintain Employee Information use case, there may be separate subflows for
+ adding, deleting and modifying employee information.
+ </li>
+</ul>
+<h5>
+ <a id="Flow of Events - Style" name="Flow of Events - Style">Flow of Events - Style</a>
+</h5>
+<p>
+ You can describe use cases in many styles. As an example we show the basic flow of events of the use case Administer
+ Order described in three different styles, varying primarily in how formal they are.
+</p>
+<p>
+ The first style, shown in Example 1, is the recommended one, because it is easy to understand, and the order in which
+ things happen is clearly evident. The text is divided into numbered and named subsections. Numbers are there to make it
+ easy to refer to a subsection. Names of subsections will let the reader get a quick overview of the flow of events by
+ browsing through the text reading only the headers.
+</p>
+<p>
+ In Example 2, the description of the flow of events fails to clarify the order in which things happen. If you write in
+ this style, you and others might miss important things that concern the system.
+</p>
+<p>
+ Example 3 below shows a yet another style, which can be useful if you find it difficult to express the sequence of
+ events clearly. This pseudo-code style is more precise, but the text is hard to read and absorb for a non-technical
+ person, especially if you want to grasp the flow of events quickly.
+</p>
+<p>
+ Finally,&nbsp;Example 4&nbsp;provides an example of a complete description of a use case flow of events.&nbsp;
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 1:" name="Example 1:"><strong>Example 1:</strong></a> <strong>Recommended style for describing a use
+ case</strong>
+ </p>
+ <p>
+ In this style, the text is easy to read and the flow of events is easy to follow.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <b>1.1. Start of Use Case</b>
+ <p>
+ This use case starts when the actor Operator tells the system to create a measurement order. The
+ system will then retrieve all Network Element actors, their measurement objects and corresponding
+ measurement functions that are available to this particular Operator. Available Network Elements
+ are those that are in operation, and that the Operator has the authority to access. The
+ availability of measurement functions depends on what has been set up for a particular type of
+ measurement object.
+ </p>
+ <p>
+ <b>1.2. Configure Measurement Order</b>
+ </p>
+ <p>
+ The system allows the actor Operator to select which Network Elements to measure and then shows
+ which measurement objects are available for the selected Network Elements. The system allows the
+ Operator to select from the measurement objects, and then select which measurement functions to set
+ up for each measurement object.
+ </p>
+ <p>
+ The system allows the Operator to enter a textual comment on the measurement order.
+ </p>
+ <p>
+ The Operator tells the system to complete the measurement order. The system will respond by
+ generating a unique name for the measurement order and setting up default values for when, how
+ often, and for how long the measurement should be made. The default values are unique to each
+ Operator. The system then allows the Operator to edit these default values.
+ </p>
+ <p>
+ <b>1.3. Initialize Order</b>
+ </p>
+ <p>
+ The Operator tells the system to initialize the measurement order. The system will then record the
+ identity of the creating Operator, the date of creation, and the "Scheduled" status of the
+ measurement order.
+ </p>
+ <p>
+ <b>1.4. Use Case Ends</b>
+ </p>
+ <p>
+ The system confirms initialization of the measurement order to the Operator, and the measurement
+ order is made available for other actors to view.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<div align="center">
+ <br />
+</div>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 2:" name="Example 2:"><strong>Example 2:</strong></a> <strong>Alternative way of describing a use
+ case</strong>
+ </p>
+ <p>
+ This style is readable, but there is no clear flow of events.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ Orderers can create Orders to collect measurement data from the Network Elements.
+ <p>
+ The system will assign the Order a unique name as well as default values that indicate the length
+ and time of the measurement and also how often it is to be repeated. The Orderer will be able to
+ edit these values.
+ </p>
+ <p>
+ The Orderer must further specify which measurement function, network element and measurements
+ objects are applicable. The Orderer can also add a personal comment to the order.
+ </p>
+ <p>
+ When the necessary information had been defined, a new Order is created and initialized with the
+ defined attributes, the name of the creator, and the date of creation. The status of the order will
+ be set to "scheduled". (Possible values for the status are: Scheduled, Executing, Completed,
+ Canceled, and Erroneous.)
+ </p>
+ <p>
+ The user interface is then notified that a new Order has been created and receives a reference to
+ the new Order so that it can be displayed.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 3:" name="Example 3:"><strong>Example 3:</strong></a> <strong>Another way of describing a use
+ case</strong>
+ </p>
+ <p>
+ Here the writer has chosen a formal style using pseudocode. This style makes it hard to quickly grasp the process
+ steps, but can be useful if the flow of events is difficult to capture precisely.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="50%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+<pre>
+<font size="2"><small>'Administrate order' (User identity)
+REPEAT
+ &lt;='Show administer order menu'
+ IF (=&gt; 'Creating an Order' (Measurement function, network element, measurement object)) THEN
+ The system finds a unique name, default values for when and how long the measurement should be executed.
+ &lt;= 'Show order' (Default attributes)
+ REPEAT
+ IF (=&gt; 'Edit order' (Attribute to change, New value of attribute)) THEN
+ &lt;= 'Update screen' (New attributes)
+ ELSIF (=&gt; 'Save order' (Order identity, Attributes)) THEN
+ The order is created and initialized in the system with
+ the defined attributes, the name of the creator,
+ date of creation and the status 'scheduled'.
+ &lt;= 'New order created' (The order)
+ ENDIF
+ UNTIL (=&gt; 'Quit')
+ ENDIF
+UNTIL 'Quit administer order'</small>
+</font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<h5>
+ <a id="Example 3:" name="Example 3:">Example 4:</a>&nbsp;Complete description fo the flow of events&nbsp;
+</h5>
+<p>
+ The complete description of the flow of events of the use case Administer Order, including its alternative flows, could
+ look like the example that follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <b>1.&nbsp;BASIC FLOW&nbsp;OF EVENTS</b>&nbsp;
+ </p>
+ <p>
+ <b>1.1. Start use case</b>
+ </p>
+ <p>
+ This use case starts when the actor Operator tells the system to create a measurement order. The system will then
+ retrieve all Network Element actors, their measurement objects and corresponding measurement functions that are
+ available to this particular Operator. Available Network Elements are those that are in operation, and that the
+ Operator has the authority to access. The availability of measurement functions depends on what has been set up for
+ a particular type of measurement object.
+ </p>
+ <p>
+ <b>1.2. Configure measurement order</b>
+ </p>
+ <p>
+ The system allows the actor Operator to select which Network Elements to measure and then shows which measurement
+ objects are available for the selected Network Elements. The system allows the Operator to select from these
+ measurement objects, and then select which measurement functions to set up for each measurement object.
+ </p>
+ <p>
+ The system allows the Operator to enter a textual comment on the measurement order.
+ </p>
+ <p>
+ The Operator tells the system to complete the measurement order. The system will respond by generating a unique
+ name for the measurement order and setting up default values for when, how often, and for how long the measurement
+ should be made. The default values are unique to each Operator. The system then allows the Operator to edit these
+ default values.
+ </p>
+ <p>
+ <b>1.3. Initialize order</b>
+ </p>
+ <p>
+ The Operator tells the system to initialize the measurement order. The system will then record the identity of the
+ creating Operator, the date of creation, and the "Scheduled" status of the measurement order.
+ </p>
+ <p>
+ <b>1.4. End use case</b>
+ </p>
+ <p>
+ The system confirms initialization of the measurement order to the Operator, and the measurement order is made
+ available for other actors to view.
+ </p>
+ <p>
+ <b>2.&nbsp;ALTERNATIVE FLOW OF EVENTS</b>&nbsp;
+ </p>
+ <p>
+ <b>2.1. No network elements available</b>
+ </p>
+ <p>
+ If in 1.1, Start use case, it turns out that no Network Elements are available to measure for this Operator, the
+ system will inform the Operator. The use case then ends.
+ </p>
+ <p>
+ <b>2.2. No measurement functions available</b>
+ </p>
+ <p>
+ If in 1.2, Configure measurement order, no measurement functions are available for the selected Network Elements,
+ the system will inform the Operator and allow the Operator to select other Network elements.
+ </p>
+ <p>
+ <b>2.3. Cancel measurement order</b>
+ </p>
+ <p>
+ The system will allow the Operator to cancel all actions at any point during the execution of the use case. The
+ system will then return to the state it was in before the use case was started, and end the use case.
+ </p>
+</blockquote>
+<h4>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Special Requirements" name="Special Requirements">Special
+ Requirements</a>
+</h4>
+<p>
+ In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by
+ the flow of events. These are non-functional requirements that will influence the design model. See also the discussion
+ on non-functional requirements in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>. You could organize these requirements in categories such as
+ Usability, Reliability, Performance, and Substitutability, but normally there are so few of them that such grouping is
+ not particularly value-adding.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Example
+ </h5>
+ <p class="example">
+ In the Recycling-Machine System, a special requirement of the Return Deposit Items use case could be:
+ </p>
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="example">
+ The machine has to be able to recognize deposit items with a reliability of more than 95 percent.
+ </p>
+ </blockquote>
+</blockquote>
+<h4>
+ <a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
+</h4>
+<p>
+ A <strong>precondition</strong> is the state of the system and its surroundings that is required before the use case
+ can be started.&nbsp;Post-Conditions are&nbsp;the states the system can be in after the use case has ended. It can
+ be&nbsp;helpful to use the&nbsp;concepts of <b>precondition</b> and <b>post-condition</b> to clarify how the flow of
+ events starts and ends. However, only use them only if the audience for the description of the use case agrees that it
+ is helpful.
+</p>
+<p align="center">
+ <img height="278" alt="Diagram described in caption." src="./resources/ucprepst.gif" width="344" />
+</p>
+<br class="picturetext" />
+<br />
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Figure 3: Illustration of preconditions and resulting post-conditions
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p>
+ Consider the following when specifying preconditions and post-conditions:
+</p>
+<ul>
+ <li>
+ The states described by pre- or post-conditions should be states that the user can observe. "The user has logged on
+ to the system" or "The user has opened the document" are examples of observable states.
+ </li>
+ <li>
+ A precondition is a constraint on when a use case can start. It is not the event that starts the use case.
+ </li>
+ <li>
+ A precondition for a use case is not a precondition for only one subflow, although you can define preconditions and
+ post-conditions at the subflow level.
+ </li>
+ <li>
+ A post-condition for a use case should be true regardless of which alternative flows were executed; it should not
+ be true only for the main flow. If something could fail, you would cover that in the post-condition by saying "The
+ action is completed, or if something failed, the action is not performed", rather than just "The action is
+ completed".
+ </li>
+ <li>
+ When you use post-conditions together with <em>extend</em> relationships, you should take care that the extending
+ use case does not introduce a subflow that violates the post-condition in the base use case.
+ </li>
+ <li>
+ Post-conditions can be a powerful tool for describing use cases. You first define what the use case is supposed to
+ achieve, which is the post-condition. You can then describe the necessary flow of events, or how to reach this
+ condition.
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ Examples
+ </p>
+ <p class="example">
+ <strong>A precondition for the use case Cash Withdrawal in the ATM machine:</strong> The customer has a personally
+ issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
+ </p>
+ <p class="example">
+ <strong>A pos-tcondition for the use case Cash Withdrawal in the ATM machine:</strong> At the end of the use case,
+ all account and transaction logs are balanced, communication with the banking system is reinitialized and the card
+ is returned to the customer.
+ </p>
+</blockquote>
+<h4>
+ <a id="Extension Points" name="Extension Points">Extension Points</a>
+</h4>
+<p>
+ An <b>extension point</b> opens up the use case to the possibility of an extension. It has a name and a list of
+ references to one or more locations within the flow of events of the use case. An extension point may reference a
+ single location between two behavior steps within the use case. It may also reference a set of discrete locations.
+</p>
+<p>
+ Using&nbsp;named extension points will help you separate the specification of the behavior of the extending use case
+ from the internal details of the base use case. The base use case can be modified or rearranged, as long as the names
+ of the extension points remain the same, it will not affect the extending use case. At the same time, you are not
+ complicating the text describing the flow of events of the base use case with details of where behavior might be
+ extended into it.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In a phone system, the use case Place Call can be extended by the abstract use case Show Caller Identity. This is
+ an optional service, often referred to as "Caller ID", that may or may not have been requested by the receiving
+ party. A description of the extension point in the use case Place Call could look like the following:
+ </p>
+ <p class="example">
+ <b>Name</b>: Show Identity
+ </p>
+ <p class="example">
+ <b>Location</b>: After section 1.9 Ring Receiving Party's Telephone.
+ </p>
+</blockquote>
+<h3>
+ Specifying Use Cases
+</h3>
+<h4>
+ <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a>
+</h4>
+<p>
+ See the&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for guidance on finding Actors
+ and Use Cases.
+</p>
+<h4>
+ <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a>
+</h4>
+<p>
+ See the <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance on evolving use cases.
+</p>
+<h4>
+ Level of detail necessary in use cases&nbsp;
+</h4>
+<p>
+ There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
+ of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
+ disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
+ the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
+ of some data from the system.
+</p>
+<p>
+ For more information on possible formats and level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
+</p>
+<h4>
+ <a id="XE_use_case__scope_of_a_use_case" name="XE_use_case__scope_of_a_use_case"></a><a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a>
+</h4>
+<p>
+ It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
+ use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
+ machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
+ exchange this receipt for money.
+</p>
+<p>
+ Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
+ There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
+ with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
+ complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
+ case of use, a use case.
+</p>
+<p>
+ Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
+ together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
+ larger systems.
+</p>
+<h3>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Use-Case Diagrams" name="Use-Case Diagrams">Use-Case Diagrams</a>
+</h3>
+<p>
+ You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual
+ cases, more than one diagram). This is useful if the use case is involved with many actors, or has relationships to
+ many other use cases. A diagram of this kind is of "local" character, since it shows the use-case model from the
+ perspective of one use case only and is not intended to explain any general facts about the whole use-case model. Refer
+ to&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/use_case_model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/use_case_model.xmi
new file mode 100644
index 0000000..b7da59b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/use_case_model.xmi
@@ -0,0 +1,169 @@
+<?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" epf:version="1.0.0" xmi:id="-yEWkrWZ3VUcjZPhq6bvScg" name="new_concept,_2jyfUAhVEduRe8TeoBmuGg" guid="-yEWkrWZ3VUcjZPhq6bvScg" changeDate="2007-02-27T14:29:36.889-0500" version="1.0.0">
+ <mainDescription><h3>
+ Explanation
+</h3>
+<p>
+ A use-case model is a model of how different types of users interact with the system to solve a problem.&nbsp; As such,
+ it describes the goals of the users, the interactions between the users and the system, and the required behavior of
+ the system in satisfying these goals.
+</p>
+<p>
+ A use-case model consists of a number of model elements.&nbsp; The most important model elements are: use cases, actors
+ and the relationships between them.
+</p>
+<p>
+ A use-case diagram is used to graphically depict a subset of the model to simplify communications.&nbsp; There will
+ typically be several use-case diagrams associated with a given model, each showing a subset of the model elements
+ relevant for a particular purpose.&nbsp; The same model element may be shown on several use-case diagrams, but each
+ instance must be consistent.&nbsp; If tools are used to maintain the use-case model, this consistency constraint is
+ automated so that any changes to the model element (changing the name for example) will be automatically reflected on
+ every use-case diagram that shows that element.
+</p>
+<p>
+ The use-case model may contain packages that are used to structure the model to simplify analysis, communications,
+ navigation, development, maintenance and planning.
+</p>
+<p>
+ Much of the use-case model is in fact textual, with the text captured in the&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/templates/uc_specification,_0cpNwMlgEdmt3adZL5Dmdw.html"
+ guid="_0cpNwMlgEdmt3adZL5Dmdw">Use-Case Specification</a>s that are associated with each use-case model
+ element.&nbsp;These specifications describe the flow of events of the use case.
+</p>
+<p>
+ The use-case model serves as a unifying thread throughout system development. It is used as the primary specification
+ of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning,
+ as the basis of defining test cases and as the basis for user documentation&nbsp;&nbsp;
+</p>
+<h3>
+ Basic model elements
+</h3>
+<p>
+ The use-case model contains, as a minimum, the following basic model elements.
+</p>
+<h4>
+ Actor
+</h4>
+<p>
+ A model element representing&nbsp;each actor. Properties include the actors name and brief description. See&nbsp;<a
+ class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information.
+</p>
+<h4>
+ Use Case
+</h4>
+<p>
+ A model element representing&nbsp;each use case. Properties include the use case name and use case specification. See
+ <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for more information.
+</p>
+<h4>
+ Associations
+</h4>
+<p>
+ Associations are used to describe the relationships between actors and the use cases they participate in. This
+ relationship is commonly known as a “communicates-association”.
+</p>
+<h3>
+ Advanced model elements
+</h3>
+<p>
+ The use-case model may also contain the following advanced model elements.
+</p>
+<h4>
+ Subject
+</h4>
+<p>
+ A model element that represents the boundary of the system of interest.&nbsp;&nbsp;
+</p>
+<h4>
+ Use-Case Package
+</h4>
+<p>
+ A model element used to structure the use case model to simplify analysis, communications, navigation, and
+ planning.&nbsp; If there are many use cases or actors, you can use use-case packages to further structure the use-case
+ model in much the same manner you use folders or directories to structure the information on your hard-disk.
+</p>
+<p>
+ You can partition a use-case model into use-case packages for several reasons, including:
+</p>
+<ul>
+ <li>
+ To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
+ </li>
+ <li>
+ To support parallel development by dividing the problem into bite-sized pieces.
+ </li>
+ <li>
+ To simplify communication with different stakeholders by creating packages for containing use cases and actors
+ relevant to a particular stakeholder.
+ </li>
+</ul>
+<h4>
+ Generalizations
+</h4>
+<p>
+ A relationship&nbsp;between actors to support re-use of common properties.
+</p>
+<h4>
+ Dependencies
+</h4>
+<p>
+ A number of dependency types between use cases are defined in UML. In particular, &lt;&lt;extend&gt;&gt; and
+ &lt;&lt;include&gt;&gt;.
+</p>
+<p>
+ &lt;&lt;extend&gt;&gt; is used to include optional behavior from an extending use case in an extended use case.
+</p>
+<p>
+ &lt;&lt;include&gt;&gt; is used to include common behavior from an included use case into a base use case in order to
+ support re-use of common behavior.
+</p>
+<p>
+ The latter is the most widely used dependency and is useful for:
+</p>
+<ul>
+ <li>
+ Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of
+ the use case to simplify communications.
+ </li>
+ <li>
+ Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and
+ ensure consistency.
+ </li>
+</ul>
+<h3>
+ Example Use-Case Diagram
+</h3>
+<p>
+ Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
+</p>
+<p>
+ &nbsp;<img height="410" alt="Figure 1: ATM Use-Case Diagram" src="./resources/ATMUCdiagram.GIF" width="565" />
+</p>
+<p>
+ Figure 1: ATM Use-Case Diagram
+</p>
+<p>
+ This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use
+ cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three &lt;&lt;includes&gt;&gt;
+ dependencies, and the associations between the performing actors and the use cases.
+</p>
+<p>
+ The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to
+ the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use
+ cases &lt;&lt;include&gt;&gt;. The base use cases are independent of the method used for identification, and it is
+ therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter
+ whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on
+ the result of Validate Customer.
+</p>
+<p>
+ Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions
+ of each actor, descriptions of each use case, and use-case specifications for each use case.&nbsp; For a more complete
+ example of this use case model see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/examples/uc_model_evolve,_t4QdAMNqEdu2IdAIaWZyAw.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: Evolution of the Use-Case Model</a>.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/visual_modeling.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/visual_modeling.xmi
new file mode 100644
index 0000000..f8da80f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/visual_modeling.xmi
@@ -0,0 +1,147 @@
+<?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" epf:version="1.0.0" xmi:id="_SB1n8MM1EdmSIPI87WLu3g" name="visual_modeling,_0XY6UMlgEdmt3adZL5Dmdw" guid="_SB1n8MM1EdmSIPI87WLu3g" changeDate="2007-03-03T12:12:42.271-0500" version="1.0.0">
+ <mainDescription><p align="center">
+ <img height="229" alt="visual modelling" src="./resources/visual.gif" width="447" />
+</p>
+<p align="center">
+ Visual modeling raises the level of abstraction
+</p>
+<p>
+ Visual modeling is the use of semantically rich, graphical and textual design notations to capture software designs. A
+ notation, such as UML, allows the level of abstraction to be raised, while maintaining rigorous syntax and semantics.
+ In this way, it improves communication in the team as the design is formed and reviewed, allowing the reader to reason
+ about the design, and it provides an unambiguous basis for implementation.
+</p>
+<h3>
+ How visual models help
+</h3>
+<p>
+ A model is a simplified view of a system. It shows the essentials of the system from a particular perspective and hides
+ the nonessential details. Visual models help you:
+</p>
+<ul>
+ <li>
+ Increase understanding of complex systems
+ </li>
+ <li>
+ Explore and compare design alternatives at a low cost
+ </li>
+ <li>
+ Form a foundation for implementation
+ </li>
+ <li>
+ Capture requirements precisely
+ </li>
+ <li>
+ Communicate decisions unambiguously
+ </li>
+</ul>
+<h4>
+ Increase understanding of complex systems
+</h4>
+<p>
+ The importance of models increases as systems become more complex. For example, you can build a doghouse without
+ blueprints. However, as you progress to building houses and then to skyscrapers, your need for blueprints becomes
+ pronounced.
+</p>
+<p>
+ Similarly, a small application built by one person in a few days may be easily understood in its entirety. However, an
+ e-commerce system with tens of thousands of source lines of code (SLOCs) or an air traffic control system with hundreds
+ of thousands of SLOCs can no longer be easily understood by one person. Constructing models allows a developer to focus
+ on the big picture, understand how components interact, and identify fatal flaws.&nbsp;
+</p>
+<p>
+ Among the various types of models are these examples:
+</p>
+<ul>
+ <li>
+ Use cases to specify behavior unambiguously
+ </li>
+ <li>
+ Class diagrams and data model diagrams to capture design
+ </li>
+ <li>
+ State transition diagrams to model dynamic behavior
+ </li>
+</ul>
+<p>
+ Modeling is important because it helps the team visualize, construct, and document the structure and behavior of the
+ system without getting lost in complexity.
+</p>
+<h4>
+ Explore and compare design alternatives at a low cost
+</h4>
+<p>
+ You can create and modify simple models inexpensively to explore design alternatives. Innovative ideas can be captured
+ and reviewed by other developers before investing in costly code development. When coupled with iterative development,
+ visual modeling helps developers assess design changes and communicate these changes to the entire development team.
+</p>
+<h4>
+ Form a foundation for implementation
+</h4>
+<p>
+ Today, many projects employ object-oriented programming languages to build reusable, change-tolerant, and stable
+ systems. To get these benefits, it is even more important to use object technology in design.
+</p>
+<p>
+ The creation of visual models, whether on paper; around a whiteboard; or in a modeling tool, can help a team to gain
+ agreement on key aspects of the system before investing time in proving their ideas with code. Having a shared model of
+ the system promotes collaboration within the team, encouraging everyone to work towards the same goal.
+</p>
+<p>
+ With the support of appropriate tools, you can use a design model to generate an initial code for implementation. This
+ is referred to as <strong>forward engineering</strong> or <strong>code generation</strong>. You can also enhance design
+ models to include enough information to build the system.
+</p>
+<p>
+ <strong>Reverse engineering</strong> may also be applied to generate design models from existing implementations. You
+ can use this method to evaluate existing implementations.
+</p>
+<p>
+ <strong>Round-trip engineering</strong> combines both forward and reverse engineering techniques to ensure consistent
+ design and code. Combined with an iterative process and the right tools, round-trip engineering allows you to
+ synchronize the design and code during each iteration.
+</p>
+<h4>
+ Capture requirements precisely
+</h4>
+<p>
+ Before building a system, it's critical to capture the requirements. Specifying the requirements using a precise and
+ unambiguous model helps to ensure that all stakeholders can understand and agree on the requirements.
+</p>
+<p>
+ A model that separates the external behavior of the system from the implementation of it helps you focus on the
+ intended use of the system, without getting bogged down in implementation details.
+</p>
+<h4>
+ Communicate decisions unambiguously
+</h4>
+<p>
+ The Unified Modeling Language (UML) is&nbsp;a consistent notation that can be applied for system engineering, as well
+ as for business engineering. According to these excerpts from the UML specification, a standard notation:
+</p>
+<ul>
+ <li>
+ <p>
+ Serves as a language for communicating decisions that are not obvious or cannot be inferred from the code
+ itself.
+ </p>
+ </li>
+ <li>
+ <p>
+ Provides semantics that are rich enough to capture all important strategic and tactical decisions.
+ </p>
+ </li>
+ <li>
+ <p>
+ Offers a form concrete enough for humans to reason [about] and for tools to manipulate.
+ </p>
+ </li>
+</ul>
+<p>
+ UML represents the convergence of the best practice in software modeling throughout the object-technology industry. For
+ more information on the UML, see <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[UML05]</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/workspace.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/workspace.xmi
new file mode 100644
index 0000000..7cb5972
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/workspace.xmi
@@ -0,0 +1,50 @@
+<?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" epf:version="1.0.0" xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" name="workspace,_0cEmAMlgEdmt3adZL5Dmdw" guid="_Dfmk8MPiEdmbOvqy4O0adg" changeDate="2006-09-21T15:22:51.449-0400" version="1.0.0">
+ <mainDescription><p align="left">
+ On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
+ conflicts.
+</p>
+<p align="left">
+ A better approach is for each developer to have a reasonably private area for the development and testing of their work
+ products. This workspace should be insulated&nbsp;so that destabilizing or conflicting changes made by others do not
+ interfere with&nbsp;progress. However, it should&nbsp;not be isolated to the extent that&nbsp;the developer's work is
+ unavailable to the team.
+</p>
+<p align="left">
+ In addition, insulated&nbsp;workspaces can be created for each test phase, such as integration testing and system
+ testing. This approach to workspaces provides several benefits <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[WIB04]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ Developers can develop, test, and debug software changes without being affected by others team
+ members'&nbsp;changes until they are ready. When ready, developers can update their insulated environments to
+ test the latest changes from other developers.
+ </p>
+ </li>
+ <li>
+ <p>
+ With separate workspaces for integration and system testing, a team could use a methodology that ensures
+ changes have passed integration testing before other developers get them, thereby minimizing the time spent
+ solving integration problems.&nbsp; For example, if two team members check in incompatible changes without
+ realizing it, and both changes are immediately available to everyone on the team, all team members&nbsp;might
+ waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
+ being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
+ team.
+ </p>
+ </li>
+ <li>
+ <p>
+ By setting up an integration area to collect and build the latest changes, the team can integrate early and
+ often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
+ </p>
+ </li>
+ <li>
+ <p>
+ The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
+ contains only configurations that have passed integration testing. This lets you control the content of the
+ release while still enabling developers to continue working.
+ </p>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/iteration_plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/iteration_plan.xmi
new file mode 100644
index 0000000..7df5eb3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/iteration_plan.xmi
@@ -0,0 +1,4 @@
+<?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="-nDr0XNiUWBo6VS1YS6KAqA" name=",_TuNhIEE4EdulKujnGUuxbg" guid="-nDr0XNiUWBo6VS1YS6KAqA" changeDate="2006-09-10T22:11:20.945-0400">
+ <mainDescription><a href="./resources/ex_iteration_plan.doc" target="_blank">ex_iteration_plan.doc</a></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/project_plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/project_plan.xmi
new file mode 100644
index 0000000..f85df31
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/project_plan.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-IdlCQXdDNYGrGJU4TBwvCA" name="new_example,_Nzv5kDoAEdusGsHODb-STA" guid="-IdlCQXdDNYGrGJU4TBwvCA" changeDate="2006-09-27T17:07:10.301-0400">
+ <mainDescription><p>
+ This example is the actual project plan used for the development of OpenUP/Basic.
+</p>
+<p>
+ <a href="./resources/project_plan.doc" target="_blank">project_plan.doc</a>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ATM UC Model Elaboration.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ATM UC Model Elaboration.doc
new file mode 100644
index 0000000..c1c6442
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ATM UC Model Elaboration.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ATM UC Model Inception.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ATM UC Model Inception.doc
new file mode 100644
index 0000000..d6cb7d3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ATM UC Model Inception.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Deposit Funds Outline.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Deposit Funds Outline.doc
new file mode 100644
index 0000000..69abe36
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Deposit Funds Outline.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Transfer Funds Outline.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Transfer Funds Outline.doc
new file mode 100644
index 0000000..e1e26f6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Transfer Funds Outline.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Use Case Spec - Validate User.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Use Case Spec - Validate User.doc
new file mode 100644
index 0000000..3c4ec9e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Use Case Spec - Validate User.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Use Case Spec - Withdraw Cash.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Use Case Spec - Withdraw Cash.doc
new file mode 100644
index 0000000..a2d147c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Use Case Spec - Withdraw Cash.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Withdraw Cash Outline.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Withdraw Cash Outline.doc
new file mode 100644
index 0000000..bd23ee1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/Withdraw Cash Outline.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ex_iteration_plan.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ex_iteration_plan.doc
new file mode 100644
index 0000000..5802f01
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ex_iteration_plan.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ex_work_items_list.xls b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ex_work_items_list.xls
new file mode 100644
index 0000000..234f2a5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/ex_work_items_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/project_plan.doc b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/project_plan.doc
new file mode 100644
index 0000000..5b4a2f6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/resources/project_plan.doc
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/uc_model_evolve.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/uc_model_evolve.xmi
new file mode 100644
index 0000000..9ac0951
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/uc_model_evolve.xmi
@@ -0,0 +1,116 @@
+<?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" epf:version="1.0.0" xmi:id="-JviMIao63C7w9C8W6iPJrw" name="new_example,_t4QdAMNqEdu2IdAIaWZyAw" guid="-JviMIao63C7w9C8W6iPJrw" authors="Chris Sibbald" changeDate="2007-02-23T13:23:26.346-0500">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ This example illustrates how the use-case model and associated use-case specification will evolve during the
+ lifecycle.&nbsp; It shows the state of the use case model at two points in the lifecycle: early inception and towards
+ the end of elaboration.&nbsp; The purpose is to illustrate how one would&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find and Outline Requirements</a> and&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/tasks/detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw.html"
+ guid="_0e1mIMlgEdmt3adZL5Dmdw">Detail Requirements</a> so as to maximize stakeholder value and minimize risk early in
+ the project as well as to minimize re-work later.
+</p>
+<p>
+ The example uses an Automated Teller Machine as the example system because it is familiar to most people.&nbsp; This
+ familiarity&nbsp;simplifies understanding the principles without&nbsp;getting lost in domain specific terminology.
+</p>
+<h4>
+ Early Inception
+</h4>
+<p>
+ Assume you have just started on the project as the Analyst.&nbsp; You have identified the key stakeholders and met with
+ them to discuss their needs.&nbsp; During your meetings, you identified a number of key actors,&nbsp;use cases and
+ supporting requirements for the ATM system.&nbsp; You captured the use cases and actors, with names and brief
+ descriptions only, in the use-case model.&nbsp; An example of this work is given in the document <a
+ href="./resources/ATM%20UC%20Model%20Inception.doc" target="_blank">ATM UC Model Inception.doc</a>.
+</p>
+<p>
+ Prior to committing significant time to detailing these use cases now, you recognize that a “breadth before depth”
+ approach can save you valuable time and permit you to identify the highest value and/or highest risk items so you can
+ concentrate on those first.
+</p>
+<p>
+ You hold a brainstorming session with the stakeholders and outline the basic flow of each of the main use cases.&nbsp;
+ As you are working through, you may identify some additional alternative flows.&nbsp; Fight the urge to “dive-in” to
+ the details on these alternative flows at this point, simply list them and come back later when you have a better
+ understanding of the “big picture”.
+</p>
+<p>
+ Examples of the notes you took during this exercise are attached below.&nbsp;(Note the choice of font is intentional to
+ illustrate that these are notes, not formal documents).
+</p>
+<p>
+ <a href="./resources/Withdraw%20Cash%20Outline.doc" target="_blank">Withdraw Cash Outline.doc</a>
+</p>
+<p>
+ <a href="./resources/Deposit%20Funds%20Outline.doc" target="_blank">Deposit Funds Outline.doc</a>
+</p>
+<p>
+ <a href="./resources/Transfer%20Funds%20Outline.doc" target="_blank">Transfer Funds Outline.doc</a>
+</p>
+<p>
+ Reviewing your notes, you recognize that there is some behavior that is common to most of the use cases, namely the
+ steps required to validate the Bank Customer.&nbsp; Factoring this behavior out into an &lt;&lt;included&gt;&gt; use
+ case will simplify communications, iteration planning,&nbsp;and maintenance.
+</p>
+<p>
+ You update the use case model accordingly: <a href="./resources/ATM%20UC%20Model%20Elaboration.doc" target="_blank">ATM
+ UC Model Elaboration.doc</a>.
+</p>
+<h4>
+ Elaboration
+</h4>
+<p>
+ With a better understanding of the system, you can now prioritize your effort to maximize value and minimize
+ risk.&nbsp; You start by detailing the common behavior captured in the use case: Validate User.&nbsp; This use case
+ captures key architectural requirements that will exercise a significant portion of the system (communications with the
+ Bank, card reader interface, etc.).&nbsp; Implementing this one key scenario will go a long way to reducing risk.
+</p>
+<p>
+ An example of the Validate User Specification is given below:<br />
+ <br />
+ <a href="./resources/Use%20Case%20Spec%20-%20Validate%20User.doc" target="_blank">Use Case Spec - Validate
+ User.doc</a>
+</p>
+<p>
+ Note that there may still be some un-answered questions, but that’s OK.&nbsp; Capture these directly in the use-case
+ specification and get them answered (see Section 5.6 of the Validate User UC Specification, above for an example).
+</p>
+<p>
+ Continuing with another architecturally significant thread, you detail the basic flow and some key alternate flows of
+ the use case: Withdraw Cash.&nbsp; You know that if the team can implement this, much of the other functionality will
+ be low risk.
+</p>
+<p>
+ An example of the Withdraw Cash Specification is given below:
+</p>
+<p>
+ <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use Case Spec - Withdraw Cash.doc</a>
+</p>
+<h3>
+ Summary
+</h3>
+<p>
+ By following a breadth before depth approach to outlining and detailing use cases one can make better decisions on
+ priorities.&nbsp; Start by identifying actors.&nbsp; Then for each actor, ask “What is the main purpose this actor
+ would like to use the system?”.&nbsp; This will lead to the identification of the use cases.&nbsp; Capture the actors
+ and use cases in the use-case model along with a brief description.
+</p>
+<p>
+ Prioritize the use cases, and then draft the main scenario or basic flow.&nbsp; As you are working through this you may
+ identify alternate flows (what can go wrong, what options are available, etc.).&nbsp; Capture these, along with a brief
+ description.
+</p>
+<p>
+ Review the use-case model and reprioritize and assess risk.&nbsp; For the high priority (based on value to the
+ stakeholders) and/or high risk use cases detail the main scenario and the critical alternate flows.
+</p>
+<p>
+ If you follow this approach, you will increase the likelihood of delivering value early, minimizing risk, and
+ minimizing re-work.<br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/use_case_spec.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/use_case_spec.xmi
new file mode 100644
index 0000000..79349e1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/use_case_spec.xmi
@@ -0,0 +1,18 @@
+<?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" epf:version="1.0.0" xmi:id="-qq-9Brh5oa6H3lsdp-m8mQ" name=",_JLOiIMNvEdu2IdAIaWZyAw" guid="-qq-9Brh5oa6H3lsdp-m8mQ" changeDate="2007-02-23T13:55:56.270-0500">
+ <mainDescription><p>
+ The attached document provides an example of a use-case specification for an Automated Teller Machine (ATM).&nbsp; The
+ ATM was selected as an example system since it is familiar to most people.&nbsp; This familiarity&nbsp;simplifies
+ understanding the principles without&nbsp;getting lost in domain specific terminology.
+</p>
+<p>
+ Example use-case specification: <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use
+ Case Spec - Withdraw Cash.doc</a>
+</p>
+<p>
+ A companion example, <a class="elementLink"
+ href="./../../../openup_basic/guidances/examples/uc_model_evolve,_t4QdAMNqEdu2IdAIaWZyAw.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Evolution of the Use-Case Model</a>, shows how the use-case model as a whole evolves
+ over time.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/work_items_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/work_items_list.xmi
new file mode 100644
index 0000000..ac2595e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/examples/work_items_list.xmi
@@ -0,0 +1,4 @@
+<?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="-qunTPN3vqTIGpELwajXpLA" name="work_items_list,_nHomIDgzEdu4E8ZdmlYjtA" guid="-qunTPN3vqTIGpELwajXpLA" changeDate="2006-08-31T10:50:15.463-0400">
+ <mainDescription><a href="./resources/ex_work_items_list.xls" target="_blank">ex_work_items_list.xls</a></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/abstract_away_complexity.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/abstract_away_complexity.xmi
new file mode 100644
index 0000000..77c1c83
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/abstract_away_complexity.xmi
@@ -0,0 +1,50 @@
+<?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" epf:version="1.0.0" xmi:id="-X7QSjItNBz7w8603yBCv0Q" name="abstract_away_complexity,_we3F4ACpEdu8m4dIntu6jA" guid="-X7QSjItNBz7w8603yBCv0Q" changeDate="2007-02-07T16:14:04.351-0800" version="1.0.0">
+ <mainDescription><p>
+ Software&nbsp;development is a pursuit characterized by complexity. This can take many forms, such as accommodating
+ complex requirements, technology, or team dynamics. Elevating the level of abstraction helps you manage this complexity
+ and make measurable progress, despite the inherent difficulty of the task.
+</p>
+<p>
+ Suggestions for several strategies that help abstract away complexity follow.
+</p>
+<h4>
+ Leverage patterns
+</h4>
+<p>
+ Patterns help you take advantage of proven techniques for solving common problems. You can benefit from the experience
+ of seasoned practitioners and avoid "re-inventing the wheel," as the saying goes. The use of patterns is a crucial
+ aspect of an architecture-centric approach to development, because it helps reduce the novelty and diversity of a
+ solution, thus improves quality.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/pattern,_0YJvUMlgEdmt3adZL5Dmdw.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
+</p>
+<h4>
+ Design the architecture with components and services
+</h4>
+<p>
+ This strategy helps manage software complexity through&nbsp;partitioning&nbsp;a system into a set of loosely coupled
+ and highly cohesive subsystems. The benefits of this approach include the ability to organize the team around a set of
+ smaller, more manageable objectives, and the ability to substitute parts of the system without disturbing the overall
+ cohesion of the system. Exposing services encourages re-use by making the functionality of the system easier to
+ comprehend. Focusing on services makes it possible to understand what the system does from a technical perspective
+ without necessarily having to understand the details of how the system works.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/component,_0YP18MlgEdmt3adZL5Dmdw.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>&nbsp;for more information.
+</p>
+<h4>
+ Actively promote reuse
+</h4>
+<p>
+ Incorporating existing software into an overall architecture helps reduce cost and improve quality by reusing proven
+ working software, rather than developing from scratch. It also helps reduce the burden of maintenance by eliminating
+ duplication in the software. Although often difficult to manage, a project or enterprise can reap significant benefits
+ from a well-executed re-use strategy.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/abstract_away_complexity_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/abstract_away_complexity_vm.xmi
new file mode 100644
index 0000000..567f111
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/abstract_away_complexity_vm.xmi
@@ -0,0 +1,48 @@
+<?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" epf:version="1.0.0" xmi:id="-OcMsciNn-UtD9fTHj26LGA" name="new_guideline,_34jWsLcIEduRNaXpzCOLXQ" guid="-OcMsciNn-UtD9fTHj26LGA" changeDate="2007-02-07T16:14:24.390-0800">
+ <mainDescription><h4>
+ Model key perspectives
+</h4>
+<p>
+ Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
+ illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
+ software. The Unified Modeling Language (UML) provides an industry-standard approach to software modeling.
+</p>
+<p>
+ When applying this strategy, you can use various techniques:
+</p>
+<ul>
+ <li>
+ <strong>Identify the key perspectives:</strong> Focus on modeling the things that count. Few (if any) projects
+ benefit from modeling the entire design to a great level of detail. Make sure that you understand why you are
+ modeling something and who will benefit.
+ </li>
+ <li>
+ <strong>Communicate key architectural perspectives:</strong> Even if you choose to model very little&nbsp;of your
+ design, it is often advantageous to produce diagrams that communicate the key architectural aspects of the system.
+ Conveying the "big picture" to the rest of the team helps them understand the overall approach and develop cohesive
+ software.&nbsp;
+ </li>
+ <li>
+ <strong>Sketch the design:</strong> Not all models need to be detailed completely and presented in a software
+ modeling tool. It is often perfectly acceptable (if not desirable) to produce hand-drawn sketches on paper or on a
+ whiteboard when you are exploring and communicating the architecture and design with your team. You can use a
+ digital camera or an electronic whiteboard to capture these diagrams and share them. For many small projects, this
+ is often all you need. See <a href="http://www.agilemodeling.com/">http://www.agilemodeling.com/</a> for more
+ information.
+ </li>
+ <li>
+ <strong>Use a modeling tool as needed</strong>:&nbsp;If the team members are changing models throughout the
+ project, sharing patterns/structure, debugging design, describing behavior, etc., then static photos or paper will
+ become difficult to work with. The team may want to capture design in a software modeling tool. Other than
+ communicating the design to the team, another benefit of a such a tool is the&nbsp;generation of structural code
+ from the models. Many software development tools allow you to view the code as models, making it easier to
+ comprehend static and dynamic aspects of a complex code base.
+ </li>
+ <li>
+ <strong>Agree on a standard notation:</strong> In a team environment, it is important that others can understand
+ your diagrams without much explanation. Choosing a standard notation enables others to quickly comprehend your
+ diagrams without ambiguity. The Unified Modeling Language is an example of a widely understood notation.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/agile_and_unified.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/agile_and_unified.xmi
new file mode 100644
index 0000000..d9d3b48
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/agile_and_unified.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-l-ZsqrXu2nmVE1giLpI6iw" name=",_qg1IAK__EduMeuOwJ2MpeQ" guid="-l-ZsqrXu2nmVE1giLpI6iw">
+ <mainDescription>Describe differences between unified processes and Agile methods<br />
+Describe how OpenUP is a Unified Process that incorporates some Agile<br />
+methods that have proven effective<br />
+Describe what Agile elements are incorporated into OpenUP</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/agile_estimation.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/agile_estimation.xmi
new file mode 100644
index 0000000..6ee7358
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/agile_estimation.xmi
@@ -0,0 +1,131 @@
+<?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" epf:version="1.0.0" xmi:id="_CYRMgBEdEdqY7JB6N6CW2w" name="agile_estimation,_CGHskBEdEdqY7JB6N6CW2w" guid="_CYRMgBEdEdqY7JB6N6CW2w" changeDate="2006-10-31T14:31:48.634-0800">
+ <mainDescription><h3>
+ Agile Estimation
+</h3>
+<p>
+ There are three main concepts you need to understand to do agile estimation:
+</p>
+<ul>
+ <li>
+ <strong>Estimation of Size</strong> gives you a high-level estimate for the work item, typically measured using a
+ neutral unit such as points
+ </li>
+ <li>
+ <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
+ </li>
+ <li>
+ <strong>Estimation of Effort</strong> translates the size (measured in points) to a detailed estimate of effort
+ typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take
+ the team member(s) assigned to the work item to do the work.
+ </li>
+</ul>
+<h4>
+ Estimation of Size
+</h4>
+<p>
+ Agile estimation of size is typically done using a relative measure called <strong>points</strong>.&nbsp; You decide
+ how big a point is, and based on that size, you determine how many points each work item is. To make estimation go
+ fast, you want to use only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65
+ points. To get started, look at 10 or so representative work items, give the smallest the size of one point, and then
+ go through all other work items and give them a relative point estimate based on that point. Note that points are used
+ for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of
+ lower priority, since you would then waste effort on things that are unlikely to be addressed within the current
+ iteration.
+</p>
+<p>
+ A key benefit of points is that they are neutral and relative. Let’s say that Ann is 3 times more productive than Jack.
+ If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,
+ they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours,
+ while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do
+ it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use
+ Velocity to determine how much ‘size’, or how many points, the team can take on within an iteration.
+</p>
+<p>
+ One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the
+ same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project.
+ You&nbsp;want to make sure that the entire team is involved in assessing size, or at least that the same people are
+ involved in all your size estimates, to ensure consistency within your project. We will see how the concept of velocity
+ will fix also this discrepancy in a point meaning different things to different project teams.
+</p>
+<p>
+ You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
+</p>
+<h4>
+ Velocity
+</h4>
+<p>
+ Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an
+ iteration for a certain team and project. As an example, a team may plan for taking on 20 points in the first
+ iteration. At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence
+ 14. For the next iteration, they may plan for fewer points, let’s say 18 points, since they think they can do a little
+ better than in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.
+</p>
+<p>
+ You should expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and
+ points are not always identical in terms of effort. Some team members are more effective than others, and some problems
+ end up being harder than others. Also, changes to the team structure, learning new skills, changes to the tool
+ environment, better teaming, or more overhead with meetings or tasks external to the project will all impact velocity.
+ In general, velocity typically increases during tha project as the team builds skills and becomes more cohesive.
+</p>
+<p>
+ Velocity compensates for differences between teams in terms of how big a point is. Let’s assume that project team Alpha
+ and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team
+ Alpha, however, assesses all work items as being worth 3 times as many points. Team Alpha assesses work item A, B, C,
+ and D to correspond to 30 points, and team Beta estimates the same work items to correspond to 10 points. Both teams
+ deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and team Beta a velocity of
+ 10. It may sound as if team Alpha is more effective, but let’s look at what happens when they plan the next iteration.
+ They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and team Beta as normal has
+ estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many points as indicated by
+ their velocity, they can both take on all of E-H. The end result is that it does not matter how big a point is, as long
+ as you are consistent within your team.
+</p>
+<p>
+ Velocity also averages out the efficiency of different team members. Let’s look at an example; Let’s assume that Ann
+ always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3
+ points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may
+ not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since
+ the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.
+ As you switch team members, or as team members become more or less efficient, your velocity will change, and you can
+ hence take on more or less points. This does however not require you to change the estimate of the size. The size is
+ still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand
+ for that iteration.
+</p>
+<h4>
+ Estimation of Effort
+</h4>
+<p>
+ As you plan an iteration, you will take on a work item, such as detail, design, implement and test a scenario, which
+ may be sized to 5 points. Typically you at this time break down this still reasonably big work item into a number of
+ smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and Testing Server portion,
+ and Implementing and Testing Client portion of the scenario. You would now do a detailed estimate of the actual effort,
+ measured in hours or days, associated with each of those 4 tasks. This estimate should be done by the person assigned
+ to do the task. In this case you may assign the following actual estimates (with person responsible within
+ parenthesis):
+</p>
+<ul>
+ <li>
+ Detailing scenario (Ann): 4 hours
+ </li>
+ <li>
+ Designing scenario (Ann and Jack):&nbsp; 6 hours
+ </li>
+ <li>
+ Implementing and Testing Server portion of scenario (Jack): 22 hours&nbsp;
+ </li>
+ <li>
+ Implementing and Testing Client portion of scenario (Ann): 12 hours
+ </li>
+ <li>
+ <strong>Total Effort Estimate for Scenario:</strong> 44 hours
+ </li>
+</ul>
+<p>
+ If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no
+ point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,
+ you have to do some level of analysis and design of the work item before you can come up with a reasonable estimate.
+ Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to
+ re-estimate the effort required to complete the task, so we have a realistic view of progress within an
+ iteration.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/analyze_arch_reqs.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/analyze_arch_reqs.xmi
new file mode 100644
index 0000000..3bf77a8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/analyze_arch_reqs.xmi
@@ -0,0 +1,204 @@
+<?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" epf:version="1.0.0" xmi:id="-YeVRerdEixh4HgHOuw2KRQ" name="analyze_arch_reqs,_42UD4A3tEduibvKwrGxWxA" guid="-YeVRerdEixh4HgHOuw2KRQ" changeDate="2007-02-26T11:12:32.578+0000" version="1.0.0">
+ <mainDescription><h4>
+ Identify architectural goals
+</h4>
+<p>
+ Architectural goals provide the motivation and rationale&nbsp;for decisions. These goals are&nbsp;often driven
+ by&nbsp;the software requirements, particularly in&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>, because they are not always&nbsp;obvious from&nbsp;the use
+ cases alone [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALL02</a>].
+</p>
+<p>
+ Architectural goals define how the system needs to respond to change over time. Consider these questions when writing
+ your goals:
+</p>
+<ul>
+ <li>
+ What is the expected lifespan of the system?
+ </li>
+ <li>
+ Will the system need to respond to technological changes over that time, such as new versions of middleware or
+ other products?
+ </li>
+ <li>
+ How&nbsp;frequently is&nbsp;the system&nbsp;expected to adapt to change?
+ </li>
+ <li>
+ What changes can we anticipate in the future, and how can we make them easier to accommodate?
+ </li>
+</ul>
+<p>
+ These considerations will have a significant effect on the structure of the system.
+</p>
+<h4>
+ Identify architectural constraints
+</h4>
+<p>
+ Ginformation about the existing&nbsp;environment and identify any constraints in the solution. This will ease
+ integration with the environment; and m ay reduce risk, cost and duplication of solution elements.
+</p>
+<p>
+ Architectural constraints can arise from various factors:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Network topology
+ </li>
+ <li>
+ Use of a given database vendor or an existing database
+ </li>
+ <li>
+ Web environment (server configurations, firewall, DMZs, and so forth)
+ </li>
+ <li>
+ Servers (hardware model, operating system)
+ </li>
+ <li>
+ Use of third-party software or a particular technology
+ </li>
+ <li>
+ Compliance with existing standards
+ </li>
+ </ul>
+</div>
+<p>
+ For example, if the company uses only one type of database, you will probably try to use it as much as possible to
+ leverage&nbsp;the existing database administration skills, rather than introducing a new one.
+</p>
+<p>
+ These architectural constraints, combined with the requirements, help you define&nbsp;an appropriate&nbsp;candidate for
+ the system architecture.
+</p>
+<h4>
+ Survey, assess, and select from available assets
+</h4>
+<p>
+ To assess and select assets to reuse on your project, you need to understand the requirements of the system's
+ environment. You also need to understand the scope and general functionality of the system that the Stakeholders
+ require. There are several types of assets to consider, including (but not limited to): reference architectures;
+ frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&nbsp;repositories (internal or
+ external to your organization) and industry literature to identify assets or similar projects.
+</p>
+<p>
+ You need to assess whether available assets contribute to solving the key challenges of the current project and whether
+ they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
+ between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
+ asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
+ tradeoffs in adopting it are, in terms of cost, risk, and functionality.
+</p>
+<p>
+ Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
+</p>
+<h4>
+ Define approach for structuring the system
+</h4>
+<p>
+ Structuring your system helps you manage its complexity by using the well-known "divide and conquer" strategy. By
+ breaking the process into smaller and more manageable pieces, you make development easier.
+</p>
+<p>
+ Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems. Each
+ layer groups similar classes or components, which communicate insofar as possible only with adjacent layers.&nbsp; See
+ <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.html"
+ guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a> for more information.
+</p>
+<p>
+ You do not define which layers contain which classes or components. Instead, you define how many layers you will need
+ and which kinds of layers you will use. For example, if you are developing a new middleware system, you probably do not
+ need a business layer. Later, during&nbsp;design activities, you decide which classes and components will populate
+ these layers.
+</p>
+<h4>
+ Define approach for deploying the system
+</h4>
+<p>
+ Develop a high level overview of how the software is deployed. For example, determine if the system needs to be
+ accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to
+ consider are:
+</p>
+<ul>
+ <li>
+ users at geographical locations
+ </li>
+ <li>
+ organization of business data
+ </li>
+ <li>
+ service level requirements
+ </li>
+ <li>
+ constraints (such as requirements to interface with legacy systems)
+ </li>
+</ul>
+<p>
+ Validate that the deployment overview supports users (especially those users at remote locations if this is required)
+ performing typical&nbsp;usage scenarios&nbsp;while satisfying nonfunctional requirements and constraints. Validate that
+ the nodes and connections are adequate to support the interactions between components on different nodes, and between
+ components and their stored data.
+</p>
+<h4>
+ Identify key abstractions
+</h4>
+<p>
+ Requirements and analysis tasks usually uncover key concepts that the system must be able to handle. These concepts
+ manifest in design as key abstractions.&nbsp;The <a class="elementLink"
+ href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> and <a class="elementLink"
+ href="./../../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html"
+ guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> work products are good sources for key abstractions. These abstractions are
+ often easily identified because they represent things that are significant to the business. For example, Customer and
+ Account are typical key abstractions in the banking business.
+</p>
+<p>
+ The abstractions that&nbsp;are identified at this point will also probably change and evolve during the course of the
+ project. The purpose of this step is not to identify&nbsp;the complete&nbsp;set of classes and relationships that will
+ survive throughout design.&nbsp;Rather, it is&nbsp;to identify the&nbsp;important&nbsp;concepts that the system must
+ handle. The value in calling them out arly in the project is that everyone on the team understands the importance of
+ these&nbsp;concepts and develops&nbsp;coherant software to handle them consistently.
+</p>
+<p>
+ Don't spend too much time describing&nbsp;abstractions in detail at this initial stage, because there is a risk that
+ spending too much time will result in identifying classes and relationships that the solution does not actually need.
+ When&nbsp;identifying&nbsp;key abstractions, it can be useful to also define any obvious relationships that exist
+ between them.&nbsp;These can be captured in a table or&nbsp;in diagrams (in a tool or whiteboard), and create a short
+ description for each abstraction.&nbsp;In general, it is not worth agonizing over defining a highly detailed set of
+ relationships at this early stage in design. The relationships will become more concrete and detailed later and
+ will&nbsp;probably modify&nbsp;these early&nbsp;assumptions.
+</p>
+<h4>
+ Identify&nbsp;architecture mechanisms
+</h4>
+<p>
+ See&nbsp;<a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>.
+</p>
+<h4>
+ Capture architectural decisions
+</h4>
+<p>
+ It is often useful to record key architectural decisions and working assumptions on an architectural overview diagram
+ to make it easier to communicate the architecture to the project team and stakeholders.&nbsp;This information should be
+ part of the description of the architecture, but it can vary in format to suit the needs of the project.&nbsp;For
+ example, on an agile and low-ceremony project the overview diagram can be an informal picture story board or a graph
+ with icons on either a whiteboard or a drawing tool. The illustration needs to show the nature of the proposed
+ solution, convey the governing ideas, and represent the major building blocks.
+</p>
+<p>
+ Architecture decisions should be captured in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
+</p>
+<p>
+ If a more complex system is required, then the architecture can be represented as a more comprehensive set
+ of&nbsp;views that describe the architecture from a number of viewpoints. See <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html"
+ guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>&nbsp;for more information.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.xmi
new file mode 100644
index 0000000..c3f2ad4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.xmi
@@ -0,0 +1,21 @@
+<?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" epf:version="1.0.0" xmi:id="-I-2SvZtjELUYDQO0jvdxEA" name="new_guideline,_SYDjUMUKEdu5GrwIlTJV7g" guid="-I-2SvZtjELUYDQO0jvdxEA" changeDate="2007-02-25T20:57:17.640+0000">
+ <mainDescription><h4>
+ Capture architectural decisions (Visual Modeling)
+</h4>
+<p>
+ You will find it useful to develop these three Unified Modeling Language (UML) diagrams at this stage:
+</p>
+<ul>
+ <li>
+ <strong>Layer map</strong> (represented as a class diagram using packages) that describes the upper-level layers of
+ the architecture
+ </li>
+ <li>
+ <strong>Draft deployment diagram</strong> that outlines the&nbsp;expected network topology
+ </li>
+ <li>
+ <strong>Simple class diagram</strong> that shows the key abstractions and any obvious relationships among them
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/architectural_view.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/architectural_view.xmi
new file mode 100644
index 0000000..c2b230f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/architectural_view.xmi
@@ -0,0 +1,58 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-cnGBBA4NXmhTIjHjlHx4Mw" name=",_T9nygClEEduLGM8dfVsrKg" guid="-cnGBBA4NXmhTIjHjlHx4Mw" changeDate="2006-08-22T11:29:43.831-0700" version="1.0.0">
+ <mainDescription><p> As an Architect, you may want to consider the following views (not all views
+ are relevant to all systems or all the Stakeholders). This set of views is known
+ as the 4+1 Views of Software Architecture</strong> [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">KRU95</a>]..
+</p>
+<p>
+ <img height="254" alt="4+1 Views of Software Architecture" src="./resources/4plus1_2.jpg" width="405" />
+</p>
+<ul>
+ <li>
+ <p> Use-case view:</strong> Describes functionality of the system,
+ its external interfaces, and its principal users. The use-case view&nbsp;contains
+ the <a class="elementLink" href="./../../../openup_basic/workproducts/uc_model,_0UCrZclgEdmt3adZL5Dmdw.html" guid="_0UCrZclgEdmt3adZL5Dmdw">Use-Case
+ Model</a>. This view is mandatory when using the 4+1 Views, because all
+ elements of the architecture should be derived from requirements. </p>
+ </li>
+ <li>
+ <p> Logical view: </strong>Describes how the system is structured
+ in terms of units of implementation. The elements are packages, classes,
+ and interfaces. The relationship between elements shows dependencies, interface
+ realizations, part-whole relationships, and so forth. Note: </strong>This
+ view is mandatory when using the 4+1 Views of Software Architecture. </p>
+ </li>
+ <li>
+ <p>Implementation view: </strong>Describes how development artifacts
+ are organized in the file system. The elements are files and directories
+ (any configuration items). This includes development artifacts and deployment
+ artifacts. This view is optional when using the 4+1 Views. </p>
+ </li>
+ <li>
+ <p>Process view: </strong>Describes how the run-time system is structured
+ as a set of elements that have run-time behavior and interactions. Run-time
+ structure often bears little resemblance to the code structure. It consists
+ of rapidly changing networks of communication objects. The elements are
+ components that have run-time presence (processes, threads, Enterprise JavaBeans&#8482;
+ (EJB&#8482;), servlets, DLLs, and so on), data stores, and complex connectors,
+ such as queues. Interaction between elements varies, based on technology.
+ This view is useful for thinking </strong>about
+ run-time system quality attributes, such as performance and reliability.
+ This view is optional when using the 4+1 Views. </p>
+ </li>
+ <li>
+ <p> Deployment views: </strong>Describe how the system is mapped to
+ the hardware. This view is optional when using the 4+1 Views. </p>
+ </li>
+</ul>
+<p>In addition, you may wish to represent the following, </p>
+<ul>
+ <li>
+ <p> Data view:</strong> A specialization of the logical view. Use
+ this view if persistence is a significant aspect of the system, and the
+ translation from the design model to the data model is not done automatically
+ by the persistence mechanism. </p>
+ </li>
+</ul>
+<p><br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi
new file mode 100644
index 0000000..a30712d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi
@@ -0,0 +1,27 @@
+<?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" epf:version="1.0.0" xmi:id="-bUmvEAAtFf6B0aUCux8k9Q" name="changes_at_iter_bound,__yQQ4L6REdqti4GwqTkbsQ" guid="-bUmvEAAtFf6B0aUCux8k9Q" changeDate="2006-09-22T10:37:52.530-0700">
+ <mainDescription><p>
+ Most iterative software development processes recommend that changes not be introduced during an iteration. The main
+ idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.
+</p>
+<p>
+ To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not
+ assigned for implementation until a future iteration via the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.
+</p>
+<p>
+ Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change
+ requests.
+</p>
+<p>
+ Consider the following when choosing the future iteration where the change request will be addressed:
+</p>
+<ul>
+ <li>
+ Group similar change requests in the same iteration. For example multiple change requests focused on the same
+ functionality or that are dependent on each other.
+ </li>
+ <li>
+ Assign change requests that mitigate high risks to the earliest iteration possible.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/continuous_integration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/continuous_integration.xmi
new file mode 100644
index 0000000..06d443d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/continuous_integration.xmi
@@ -0,0 +1,32 @@
+<?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="-DlaqJu4sEqMPk84qhJ6IEA" name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" changeDate="2006-05-31T15:26:30.329-0700">
+ <mainDescription><p>
+ [ Don't forget to talk about running developer tests. ]
+</p>
+<p>
+ [Content below taken from step “Accept Integrated Elements and Promote Build" in the Task “Integrate and Create
+ Build"... this Main Description needs to be cleaned up ]
+</p>
+<p>
+ Depending on the complexity and number of&nbsp;components to be integrated, it is often more efficient to produce the
+ target build in a number of steps, adding more&nbsp;components with each step, and producing a series of intermediate
+ 'mini' builds - thus, each build planned for an iteration may, in turn, have its own sequence of transient intermediate
+ builds. These are subjected to a minimal integration test&nbsp;to ensure that what is added is compatible with what
+ already exists in the system integration workspace. It should be easier to isolate and diagnose problems using this
+ approach.&nbsp;
+</p>
+<p>
+ Delivered&nbsp;components are accepted&nbsp;incrementally into the system integration workspace,&nbsp;having any merge
+ conflicts being resolved.&nbsp;It is recommended that this&nbsp;is done in a bottom-up approach with respect to the
+ layered structure, making sure that the versions of the&nbsp;components are consistent, taking imports into
+ consideration. The increment of&nbsp;components is compiled and linked into an intermediate build, which is then
+ provided to the tester to execute a minimal system integration test.
+</p>
+<p>
+ <font size="1"><img height="172" alt="" src="./resources/ac_intsy.gif" width="501" /></font>
+</p>
+<p>
+ This diagram shows a build produced in three increments. Some&nbsp;components are only needed as stubs, to make it
+ possible to compile and link the other components, and provide the essential minimal run-time behavior.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/data_modeling.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/data_modeling.xmi
new file mode 100644
index 0000000..448d846
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/data_modeling.xmi
@@ -0,0 +1,173 @@
+<?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" epf:version="1.0.0" xmi:id="-XMbxFU8M85cRlf3C4iwAGw" name="new_guideline,_ienXEEyAEdu-df7p0PuRvQ" guid="-XMbxFU8M85cRlf3C4iwAGw" authors="Scott Ambler" changeDate="2006-12-01T13:53:01.285-0800" version="1.0.0">
+ <mainDescription><h3>
+ Overview
+</h3>
+Physical data models (PDMs) are used to design the structure of a persistent data store. Typically a PDM is created for a
+single data store, although sometimes a PDM will cover several related data stores (this is particularly true when the data
+storage mechanism is file based). The assumption in this guideline is that you are modeling the schema of a single
+relational database.
+<h3>
+ The Data Model in OpenUP
+</h3>
+The PDM is part of the Work Product: Design. It’s described as different views or perspectives of a portion of the design.
+<h3>
+ Data Model Types
+</h3>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Traditionally, there are three types of data models:
+</p>
+<ol>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ Conceptual. A conceptual model, also referred to as a domain model, depicts the critical business entities and
+ the relationships between them.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ Logical. A logical data model (LDM) adds detail, in particular data attributes and more entities. LDMs will
+ optionally indicate candidate keys (one or more attributes of an entity which uniquely identify it) of an
+ entity. LDMs describe how the design of the system handles the data that will be actually maintained in the
+ PDM.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ <p>
+ Physical. A PDM depicts the table structure (in the case of a relational database design), the
+ relationships between the tables, and the primary and foreign keys implemented by the tables. PDMs
+ potentially indicate views, stored procedures, and other database elements.
+ </p>
+ </div>
+ </li>
+</ol>
+<p>
+ For systems built using object and/or component-based technology, the LDM is usually not created in favor of a class
+ model.
+</p>
+<h4 style="MARGIN-RIGHT: 0px">
+ Physical Data Modeling
+</h4>
+<p>
+ The PDM consists of the detailed database table designs and their relationships. The tables in the PDM have
+ well-defined columns, as well as keys and indexes as needed. The tables might also have triggers defined as necessary
+ to support the database functionality and referential integrity of the system. In addition to the tables, stored
+ procedures have been created, documented, and associated with the database in which the stored procedure will reside.
+</p>
+<p>
+ The diagram below shows an example of some of the elements of a PDM. A UML-based notation is used, although other
+ notations such as “crow's feet” or Information Engineering (IE) are also common. This example model is a part of the
+ PDM of a fictional order entry system. It depicts three tables (Order, OrderItem, and Item), three stored procedures
+ (GetOrders, GetTotalBusiness, and TestDatabase), and a trigger on Order named deleteOrderItems. The figure also depicts
+ the columns of each table, the primary key for each table, and any foreign keys to other tables.
+</p>
+<p>
+ <strong>Example Physical Data Model</strong>
+</p>
+<p>
+ &nbsp;<img height="309" alt="" src="./resources/PDMSample.JPG" width="597" />
+</p>
+<p>
+ An existing database can be reverse-engineered to populate the PDM if the team has access to a tool that can transform
+ a database into a model.
+</p>
+<h3>
+ How to Model Database Schemas
+</h3>
+<p>
+ Perform the following in an iterative manner:
+</p>
+<ol>
+ <li>
+ Identify tables. A table is similar conceptually to object-orientation’s concept of a class – a table contains a
+ collection of rows of data whereas a class defines a collection of objects. A table could contain rows representing
+ people, places, things, events, or concepts. Examples of tables include Customer, Order, and OrderItem.
+ </li>
+ <li>
+ Identify columns. Each table has one or more columns. A column stores a single data attribute for each row. For
+ example, the Customer table may have columns such as First Name and Surname. A column has a single data type, such
+ as INT, DATETIME, or VARCHAR.
+ </li>
+ <li>
+ Follow accepted modeling conventions. Your organization should have standards and guidelines applicable to data
+ modeling, in particular naming conventions,&nbsp;that you should follow.
+ </li>
+ <li>
+ Identify relationships between tables. In the real world entities have relationships with other entities. For
+ example, customers PLACE orders, customers LIVE AT addresses, and line items ARE PART OF orders. These
+ relationships will exist between the rows of data stored in the corresponding tables.
+ </li>
+ <li>
+ Assign keys. A key is one or more columns that uniquely identify a row in a table. A primary key is the preferred
+ key for a table. For example, the Customer table may have two potential keys, CustomerID and SocialSecurityNumber.
+ You could choose to use CustomerID as the primary key, thereby making SocialSecurityNumber a secondary key. Foreign
+ keys are used to maintain relationships between rows.
+ </li>
+ <li>
+ Normalize to reduce data redundancy. Data normalization is a process in which columns within a PDM are organized to
+ increase the cohesion of tables. In other words, the goal of data normalization is to reduce and even eliminate
+ data redundancy, an important consideration for application developers because it is incredibly difficult to store
+ objects in a relational database that maintains the same information in several places.
+ </li>
+ <li>
+ De-normalize to improve performance. Normalized data schemas, when put into production, often suffer from
+ performance problems. An important part of data modeling is to de-normalize portions of&nbsp;the data schema, to
+ increase data redundancy by storing the same information in several places or manners, to improve database access
+ times.
+ </li>
+</ol>
+<h3>
+ Data Modeling Throughout the Lifecycle
+</h3>
+<h4>
+ Inception Phase
+</h4>
+<p>
+ During the Inception phase the goal is to identify high-level requirements for the system so that the scope may be
+ identified and project funding obtained. Little, if any, data modeling is performed at this point although some
+ conceptual modeling may occur. Detailed data models are usually not needed at this point.
+</p>
+<h4>
+ Elaboration Phase
+</h4>
+<p>
+ The goal of the Elaboration phase is to eliminate technical risk and to produce a stable (baselined) architecture for
+ the system. One of several architectural issues that is likely to arise is data architecture. To support this effort,
+ you will need to model the major database structures (tables, indexes, and primary and foreign key columns) and then
+ create the database schema from the model (ideally it would be generated from a modeling tool).
+</p>
+<p>
+ Additionally, representative data volumes may be loaded into the database to support performance testing. Based on the
+ results of performance testing, the PDM might need to be adjusted with optimization techniques, including but not
+ limited to de-normalizing, optimizing physical storage attributes, or distribution and indexing.
+</p>
+<h4>
+ Construction Phase
+</h4>
+<p>
+ During the Construction phase the goal is to build a working system that is ready to be released. During each
+ iteration&nbsp;the&nbsp;design, implementation, and tests are fleshed out to implement that iteration's requirements.
+ In other words development artifacts, including your data-oriented artifacts, evolve over time. To support data model
+ changes you may discover the need to refactor your existing database schema.
+</p>
+<h4>
+ Transition Phase
+</h4>
+<p>
+ The PDM is maintained during the Transition phase in response to approved change requests. You should keep the PDM
+ synchronized with the database as the application goes through final acceptance test and is deployed into production.
+</p>
+<h3>
+ Round-trip Engineering Considerations
+</h3>
+<p>
+ If a development team is using modern visual modeling tools that have the ability to convert classes to tables (and
+ vice versa) or has the ability to reverse and forward engineer databases, then the team needs to establish guidelines
+ for managing the transformation and engineering processes. The development team must define the points in the
+ development of the application (build-and-release cycle) at which it will be appropriate to perform the class-to-table
+ transformations and to forward-engineer the database. Once the initial database is created, the development team must
+ define guidelines for the team to manage the synchronization of the PDM and database as the design and code of the
+ system evolve throughout the project.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/design.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/design.xmi
new file mode 100644
index 0000000..d1039cc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/design.xmi
@@ -0,0 +1,218 @@
+<?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="_Qo7pYMM3EdmSIPI87WLu3g" name="design,_0X3bcMlgEdmt3adZL5Dmdw" guid="_Qo7pYMM3EdmSIPI87WLu3g" changeDate="2006-09-09T09:28:07.410-0400">
+ <mainDescription><p>
+ The design represents the behavior and structure of the system at various levels of abstraction – most notably not
+ solely at the code level of abstraction.&nbsp; This will help the designer reason&nbsp;about the quality, structure,
+ and behavior&nbsp;of the design.
+</p>
+<h3>
+ Multiple Passes
+</h3>
+<p>
+ The design will be revisited many times throughout the iterative lifecycle and even within an iteration.&nbsp;
+</p>
+<p>
+ Each time some design activity is being performed, it will be performed with some specific goal.&nbsp; The goal might
+ be to identify a notional set of participants in a collaboration that can be exercised to realize the behavior required
+ (an analysis pass).&nbsp; The goal might be in the identification of some coarse-grained elements that are required to
+ act out some scenario (an architectural pass).&nbsp; Then a pass might be done within one of those components to
+ identify the elements within that will collaborate together to perform the behavior required (a more detailed design
+ pass).
+</p>
+<p>
+ Design might be performed in a particular context such as database context, user-interface context, or perhaps the
+ context of how some existing library will be applied.&nbsp; In these cases the design steps will be performed just to
+ make and communicate decisions regarding that context.
+</p>
+<p>
+ Avoid analysis paralysis.&nbsp; Avoid refining, extending, and improving the design beyond a minimal version that
+ suffices to cover the needs of the requirements within the architecture.&nbsp; Design should be done in small chunks,
+ proven via implementation, improved via refactoring, and integrated into the baseline to provide value to the
+ stakeholders.
+</p>
+<h3>
+ Identification of&nbsp;Elements
+</h3>
+<p>
+ Identify the&nbsp;elements based on needs of the requirements.
+</p>
+<p>
+ The identification of elements can stem from a static perspective of walking through the requirements and identifying
+ elements clearly called out, a form of domain modeling.&nbsp; It can pull in other elements identified as being in the
+ application domain or deemed necessary from examining the requirements for the portion of the system being
+ designed.&nbsp; This can also pull from key abstractions identified while defining the architecture.
+</p>
+<p>
+ The identification of&nbsp;elements&nbsp;should&nbsp;apply a dynamic perspective&nbsp;by&nbsp;walking through scenarios
+ of usage of the system (or subsystem) identifying elements needed to support&nbsp;the behavior.&nbsp; That behavior
+ might be a scenario of usage from an external user perspective or, while designing a subsystem, a responsibility
+ assigned to the subsystem that has complex algorithmic behavior. Consider applying the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;to identify the elements necessary to support
+ the scenario or apply other patterns identified in the architecture that specify the elements that will be used to
+ support specific aspects of the scenario.
+</p>
+<p>
+ If the system being designed is a real-time system, include elements representing events and signals that allow us to
+ describe the asynchronous triggers of behavior to which the system must respond.&nbsp; Events are specifications of
+ interesting occurrences in time and space that usually (if they are noteworthy) require some response from the
+ system.&nbsp; Signals represent asynchronous mechanisms used to communicate certain types of events within the system.
+</p>
+<p>
+ If there are existing&nbsp;elements from previous passes over the design or from selected frameworks or other reusable
+ elements, those should be reused whenever possible.
+</p>
+<p>
+ Having identified the elements, each should be given a meaningful name.&nbsp; Each element should also have a
+ description so that the team members that work together to refine the design and implement from&nbsp;the
+ design&nbsp;will understand the role the&nbsp;element will play.
+</p>
+<p>
+ Based on the above, this identification of&nbsp;elements&nbsp;could be applied a number of times in designing just one
+ part of the system.&nbsp; While there is no&nbsp;one correct&nbsp;strategy for multiple passes, they could be done at a
+ coarse-grained level and then a fine-grained level or at an analysis (abstract) level and then a design level.
+</p>
+<h3>
+ Behavior&nbsp;of&nbsp;Elements
+</h3>
+<p>
+ To&nbsp;identify the behavior&nbsp;of the elements, walk through scenarios assigning behavior to the appropriate
+ collaborating participant.&nbsp; If a particular usage of the system or subsystem can have&nbsp;multiple possible
+ outcomes or variant sequences, cover enough scenarios to ensure that the design is robust enough to support the
+ necessary possibilities.
+</p>
+<p>
+ When assigning behavior to elements, consider applying the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;or other patterns identified in the
+ architecture.
+</p>
+<p>
+ Behavior can be&nbsp;represented as&nbsp;a simple statement of responsibility or it can be a detailed operation
+ specification.&nbsp; Use the appropriate level of detail to communicate important design decisions while&nbsp;giving
+ the freedom to make appropriate implementation decisions as those tasks ensue.
+</p>
+<p>
+ Behavior must be understood as a responsibility on an element, and as an interaction between two&nbsp;elements in the
+ context of some broader behavior of the system or subsystem.&nbsp; The latter part of this will lead the developer to
+ identify relationships needed between the elements.
+</p>
+<p>
+ Avoid too much&nbsp;identification of behavior solely from the perspective of domain modeling.&nbsp; Only include
+ behavior that is really needed, behavior identified by walking through required scenarios of system usage.
+</p>
+<h3>
+ Design&nbsp;Element Relationships
+</h3>
+<p>
+ The relationships between the&nbsp;elements necessary for the behavior must be designed.&nbsp; This can simply be the
+ identification of&nbsp;the ability&nbsp;to traverse from one&nbsp;element to another or a need to manage an association
+ between the elements.
+</p>
+<p>
+ More detailed design can be performed on the relationships as appropriate.&nbsp; This can include optionality,
+ multiplicity, whether the relationship is a simple dependency or managed association, etc. These decisions that drive
+ implementation details are best made at the design level when it is&nbsp;easier to see how all the pieces fit
+ together.&nbsp;
+</p>
+<p>
+ As with the behavior discussion above, avoid defining too many relationships based on relationships in the application
+ domain.&nbsp; Only include the relationships that are really needed based on the requirements.&nbsp; On the other hand,
+ a combination of requirements knowledge and domain knowledge can lead to some detailed decisions on the relationships
+ such as optionality and multiplicity.
+</p>
+<h3>
+ Refine Design
+</h3>
+<p>
+ Having identified a design&nbsp;including a set of collaborating&nbsp;elements with the behavior and relationships
+ robust enough to handle the requirements under consideration, the design can be improved and transformed into an
+ implementable system through refinement.
+</p>
+<p>
+ The visibility of each operation should be selected to be as&nbsp;restrictive as possible.&nbsp; Based on walking
+ through the scenario it should be clear which operations must be&nbsp;available to other elements in the design and
+ which can be considered private behavior inside the element that has the operation.&nbsp; Minimizing the number of
+ public operations creates a more maintainable and understandable design.
+</p>
+<p>
+ With respect to parameters, the return value, and&nbsp;a description of how it will go about performing the behavior,
+ operations can be detailed at a lower level that drives the actual implementation or that detail might be left to
+ be&nbsp;handled when writing the code.
+</p>
+<p>
+ Data attributes can be identified based on information needed to support behavior or based on additional requirements
+ such as information to be presented to the user or transmitted to another system.&nbsp; Avoid indiscriminate domain
+ analysis; there might be a great deal of data in the domain that is not needed to support the requirements.&nbsp; Data
+ attributes can simply be identified or they can be designed in detail with attribute types, initial values, and
+ constraints. Decide on the visibility of the data attribute; operations to access and update the data can be added or
+ deferred to implementation.
+</p>
+<p>
+ Generalization&nbsp;and interfaces can be applied to simplify or otherwise improve the design.&nbsp; Ensure that the
+ usage of these techniques actually improves the design rather than muddling it with complexity.&nbsp; For example,
+ common behavior can be factored into a parent class via generalization or out to a helper class via delegation; the
+ latter solution can be more understandable and maintainable as generalization is an inflexible relationship.
+</p>
+<p>
+ The refinement of any portion of the design could include another pass through the design process.&nbsp; One might find
+ that what was initially identified as a single behavior on an&nbsp;element&nbsp;warrants a detailed walkthrough of the
+ collaborating&nbsp;elements to realize that behavior.
+</p>
+<p>
+ When updating an existing design <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ –</span> especially one that has had portions already implemented <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ –</span> apply <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> to ensure that the improved design continues to perform as expected.
+</p>
+<h4>
+ Organization of&nbsp;Elements (package-level)
+</h4>
+<p>
+ In a design of any notable size, the&nbsp;elements must be organized into packages.&nbsp; Assign the&nbsp;elements to
+ existing or new packages and ensure that the visibility relationships between the packages support
+ the&nbsp;navigability required between the elements.&nbsp; Decide whether each element should be visible to elements
+ outside its package.
+</p>
+<p>
+ When structuring the design into packages, consider <a class="elementLink" href="./../../../openup_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Layering</a>&nbsp;and other patterns.&nbsp; Though all design work must conform to
+ existing architectural decisions, the allocation of&nbsp;elements to packages and possible updates to package
+ visibility is an area of&nbsp;significant architectural concern.&nbsp; The developer should collaborate with the
+ architect to ensure that package-level decisions are in accordance with the rest of the architecture.
+</p>
+<p>
+ This guideline first talks about the identification and design of the&nbsp;elements and then about organizing
+ the&nbsp;elements into packages.&nbsp; This is not a strict order of events.&nbsp; There is nothing wrong with
+ identifying a package structure for the system and then populating that structure with identified&nbsp;elements&nbsp;as
+ long as the actual&nbsp;elements identified are allowed to influence the resulting package structure.
+</p>
+<h3>
+ Reviewing the Design
+</h3>
+<p>
+ Design is best done collaboratively as it is a problem-solving activity with a range parts and perspectives.&nbsp;
+ There should be a constant level of review to ensure that the decisions make sense within the area being designed and
+ in the design of the system overall.&nbsp; There also might be occasions where the review of some area of design is
+ reviewed by a set of interested or knowledgeable parties such as the architect who will verify that the design conforms
+ to some architectural decision or a developer&nbsp;who will be expected to implement the design.&nbsp;
+</p>
+<p>
+ The design should be examined to ensure that it follows heuristics of quality design such as loose coupling and high
+ cohesion.&nbsp; Responsibilities should be appropriately&nbsp;distributed to elements such that there are no elements
+ with too much responsibility and no elements are left without any responsibilities.&nbsp; The design should be able to
+ clearly&nbsp;communicate the design decisions while not delving into concerns best dealt with during implementation of
+ code.
+</p>
+<p>
+ Ensure the design follows any project-specific guidelines and conforms to the architecture.
+</p>
+<p>
+ Modifications to the design to improve it based on issues identified in reviewing it should apply <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> to ensure that the design and any existing implementation of the design
+ continues to fulfill its responsibilities.
+</p>
+<h3>
+ Relationship of Design to Architecture
+</h3>
+<p>
+ This guideline remarks on conforming to the architecture in various ways; it is written as though one is designing
+ within a pre-existing architecture.&nbsp; Though projects will often have pre-existing architectures available, a
+ particular architecture is the result of design activities.&nbsp; Therefore, in addition to discussing conformance to
+ some existing architecture, one must also consider the creation of the architecture and updates and improvements to the
+ architecture based on the work of design.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/design_components.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/design_components.xmi
new file mode 100644
index 0000000..7fb5834
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/design_components.xmi
@@ -0,0 +1,4 @@
+<?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="-6ep_EyK3ZO6vRGWtAqoJ-A" name="design_components,_CFAswNbzEdqu5o2S60g5LA" guid="-6ep_EyK3ZO6vRGWtAqoJ-A" changeDate="2006-04-28T13:31:47.784-0700">
+ <mainDescription>&nbsp;</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/designing_visually.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/designing_visually.xmi
new file mode 100644
index 0000000..ae797b0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/designing_visually.xmi
@@ -0,0 +1,189 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-1xE2ZW3MjNAJ7jkaZNbkww" name="visual_modeling,_1fM3AC9_EduW5uTjiIcspQ" guid="-1xE2ZW3MjNAJ7jkaZNbkww" changeDate="2006-11-21T11:21:26.464-0800" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Using visual modeling techniques to design software can help break down complex problems into a series of smaller,
+ easier to manage tasks. Sharing pictures rather than written documents or source code also helps the understanding and
+ communication of difficult concepts. Adopting standard modeling notations such as the UML increases this capability by
+ helping to make diagrams precise and unambiguous.
+</p>
+<p>
+ The degree of formality used when producing and disseminating models should vary according to your needs. Small,
+ collaborative teams modeling around whiteboards and capturing the results on a sheet of paper or with digital cameras
+ can yield good results. This can also help the team focus on producing software with the help of models; rather than
+ becoming sidetracked into over-engineering both the models and the solution. Modeling tools provide additional value to
+ projects, especially for more complex systems. Their specifics of use are outside the scope of this guideline, however.
+</p>
+<p>
+ This guideline does not describe a formal sequential progression through prescriptive design steps. Whether some or all
+ of these techniques are needed, or how long is spent on them will vary depending on real-world issues such as the
+ complexity of the requirements; the experience of the designer; and the way the team works.
+</p>
+<p>
+ This guideline uses a simplified scenario (Login) to help keep the focus on understanding the techniques rather than
+ the specific requirements. In the real-world, it is doubtful that much time would be spent modeling a simple problem.
+ Here is the use case diagram, for reference;
+</p>
+<p>
+ <img height="142" alt="User Login Use Case Model" src="./resources/UserLoginUCM.JPG" width="472" />
+</p>
+<h3>
+ Identify elements
+</h3>
+<p>
+ Render the identified design elements as classes in a UML diagram.&nbsp; Apply appropriate stereotypes and optionally
+ render the class using an icon specific to the stereotype to characterize the intent of the class in the design.&nbsp;
+ Name and briefly describe the classes in a few sentences. Do not spend too much time working on associations, as these
+ will be developed through working on collaborations in the next step.
+</p>
+<p>
+ Classes can be drawn as a basic UML rectangle or with a specific symbol associated with a particular stereotype.
+</p>
+<p>
+ The resulting class diagram should be conceptually similar to this one:
+</p>
+<p>
+ <img height="228" alt="Identify Elements - Initial Class Model" src="./resources/IdentifyElementsBCE.JPG" width="290" />
+</p>
+<p>
+ For this example, the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> has been used to derive two classes (LoginUI and
+ LoginController). In addition, two design elements already identified in the architecture (SecuritySystemInterface and
+ User) have also been incorporated.
+</p>
+<h3>
+ Determine how elements collaborate to realize the scenario.
+</h3>
+<p>
+ When determining collaboration, two kinds of diagrams are useful.
+</p>
+<ul>
+ <li>
+ A dynamic object diagram, showing how the design elements collaborate to realize the requirements.
+ </li>
+ <li>
+ A static class diagram, showing the classes involved in realizing the requirements.
+ </li>
+</ul>
+<p>
+ Remember to also update any other impacted diagrams as appropriate, based on modifications or additions to the design.
+</p>
+<p>
+ Create a number of dynamic object diagrams that walk through how a set of objects collaborate to perform the behavior
+ of the scenarios.&nbsp; Even if just one scenario is being designed, this might take multiple diagrams to render it in
+ smaller, understandable chunks or from multiple contexts.
+</p>
+<p>
+ <img style="WIDTH: 776px; HEIGHT: 355px" height="355" alt="User Login Sequence Diagram" src="./resources/UserLoginSeq.JPG" width="776" />
+</p>
+<p>
+ The above sequence diagram shows the user credentials being passed through to the security system for authentication.
+ Steps in the use case scenario are transformed into messages between the participating objects. The messages in this
+ example are not yet fully formed (there are no parameters or return values), so they are prefixed with “//” to show
+ that more work is needed.&nbsp; A sequence diagram was used in this example, but a communication diagram could have
+ been used.
+</p>
+<p>
+ It&nbsp;can be&nbsp;useful to create one or more static class diagrams that show the classes in the design that support
+ the realization.&nbsp; These class diagrams are often called View of Participating Classes diagrams, they provide a
+ focused view on the overall design by only showing the classes, relationships, operations, and attributes relevant to
+ the collaboration.
+</p>
+<p>
+ <img height="469" alt="Login VOPC" src="./resources/login_vopc.jpg" width="448" />
+</p>
+<p>
+ This diagram shows the operations and relationships that were identified by drawing the sequence diagram. The
+ relationships in this example&nbsp;have not been refined yet, so they are just shown as simple associations. Remember
+ to examine the diagram to verify that the design can support the behavior in the sequence diagram.
+</p>
+<p>
+ Working at this level of detail in the model during the early stages of design can be helpful. It keeps the diagrams
+ relatively simple and easy to understand. It makes them easier to draw in a workshop and easier to change during
+ discussion. It is often easier to add the detail once there is agreement on the fundamentals.
+</p>
+<h3>
+ Refine design decisions
+</h3>
+<p>
+ Once the fundamentals of the design are relatively stable, you can begin to add detail to the design. Some of this can
+ be performed in code or in the model. If modeling is chosen, then refine attributes, responsibilities and
+ relationships.
+</p>
+<h4>
+ Describe responsibilities
+</h4>
+<p>
+ Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to other
+ objects. Each class will typically have several responsibilities; each responsibility will evolve into one or more
+ operations during design.
+</p>
+<p>
+ Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has
+ to support. Document a responsibility by giving it a name, and optionally a brief description (what it does).
+</p>
+<p>
+ These operations can be left as self-evident from their context, they can be given textual descriptions of the
+ algorithm required to perform the behavior, or they could spawn off another whole pass of this technique where a set of
+ classes that collaborate together to perform the internals of the operation are identified, etc.
+</p>
+<h4>
+ Describe attributes and associations
+</h4>
+<p>
+ A class may have to store simple data information, like: string, integer, and the like. For such simple type of
+ information, attributes are defined for classes. For a more complex or "behavioral” attribute, consider creating an
+ extra class and establish an association to it.
+</p>
+<p>
+ To perform their responsibilities, classes may depend on other classes to supply needed behavior. These other classes
+ might be ones already identified in this design session, they might be existing classes pulled from the architecture,
+ or the need for new classes might be conceived. Associations in a class diagram can be used to represent inter-class
+ relationships.
+</p>
+<p>
+ <img height="439" alt="Login VOPC (Refined)" src="./resources/login_vopc_refined.jpg" width="557" />
+</p>
+<p>
+ This diagram shows a number of refinements. The LoginUI class has been replaced by LoginForm. The User class has been
+ renamed UserCredentials and is created by the LoginForm class rather than LoginController. It is then used as a
+ parameter for subsequent messages rather than passing the individual attributes. The SecuritySystemInterface class has
+ been refined into two elements, ISystemSecurity, which provides a simple façade for interaction with the rests of the
+ design; and SecuritySystemProxy, which handles interaction with the external security system.
+</p>
+<h3>
+ Design internals
+</h3>
+<p>
+ The classes in the design are likely to need to be distributed amongst different packages and subsystems or components.
+</p>
+<p>
+ <img height="304" alt="User Login - Design Packages" src="./resources/dv_Packaging.JPG" width="571" />
+</p>
+<p>
+ In this example, the LoginForm, LoginController and UserCredentials elements have been placed in a package called
+ LocalSecurity. The SecuritySystemProxy is a part of a subsystem called SecuritySystemAdapter which realizes the
+ ISecuritySystem interface. The SecuritySystemAdapter wraps the legacy SecuritySystem, expressed here as a component
+ offering a validateUser interface.
+</p>
+<p>
+ Each of these packaged elements can be distributed amongst the team for further development work.
+</p>
+<h3>
+ Conclusion
+</h3>
+<p>
+ This guideline walked through the techniques in a concrete manner started with a scenario of a use case through to
+ distributing the classes identified into a set of packages. This example demonstrates a technique for designing
+ visually, but it should be considered as just one conceptual pass of design.&nbsp; One could as easily apply this
+ technique when defining the internals of how the SecuritySystemProxy class will collaborate with a set of classes to
+ validate the credentials.
+</p>
+<p>
+ When applying this guideline, work in small chunks and keep in mind the goal of delivering software to the users that
+ provides value. To deliver high-quality software requires consideration of how the pieces will work together to deliver
+ that value. But as soon as key decisions have been made and the decisions have been communicated to the appropriate
+ team members, the team should move on to implementing the source code to verify the design and deliver the value.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.xmi
new file mode 100644
index 0000000..c896cda
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.xmi
@@ -0,0 +1,183 @@
+<?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" epf:version="1.0.0" xmi:id="-78ko4CuOJERKJF9ZvwMUBQ" name="detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q" guid="-78ko4CuOJERKJF9ZvwMUBQ" changeDate="2007-01-05T13:31:41.729-0500" version="1.0.0">
+ <mainDescription><h4>
+ Most efficient way to write use cases
+</h4>
+<p>
+ Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we
+ learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in
+ others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary work
+ and rewriting.
+</p>
+<p>
+ An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an
+ effective way to write use cases. This breadth-first approach involves two aspects: writing the set of use cases and
+ writing individual use cases.
+</p>
+<p>
+ <strong>Writing sets of use cases:</strong> Use cases exist in sets, and the relationships between the various use
+ cases and Actors&nbsp;are important. As you learn more about the Actors, you also learn more about the system's
+ boundaries and transactions. Likewise, as you learn more about the system's transactions, you learn more about its
+ Actors. Therefore, it is more efficient to write several use cases simultaneously than to write them sequentially. This
+ way, you can identify and understand the effects of the various use cases upon each other as you write them, rather
+ than as afterthoughts that require rewriting or elimination of previous work.
+</p>
+<p>
+ <strong>Writing individual use cases.</strong> Similarly, it makes sense to write each individual use case iteratively.
+ Starting with the main scenario, you can then identify various alternative and error flows that the use case might
+ follow, then evaluate, rearrange or eliminate them, and then add the details of the surviving scenarios.
+</p>
+<p>
+ The level of detail that you capture depends on a number of factors. See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html"
+ guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a> for guidance on selecting the correct format for your
+ use cases.
+</p>
+<h4>
+ Detail the flow of events of the main scenario
+</h4>
+<p>
+ As a starting point, use the step-by-step description of the main scenario that you created during <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>. Then, gradually add details to this scenario,
+ describing <strong>what</strong> the use case does, <strong>not how</strong> to solve problems internal to the system.
+</p>
+<p>
+ A flow of events description explores:
+</p>
+<ul>
+ <li>
+ How and when the use case starts
+ </li>
+ <li>
+ When the use case interacts with the Actors, and what data they exchange
+ </li>
+ <li>
+ When the use case uses data stored in the system or stores data in the system
+ </li>
+ <li>
+ How and when the use case ends
+ </li>
+</ul>
+<p>
+ It does not describe:
+</p>
+<ul>
+ <li>
+ The GUI
+ </li>
+ <li>
+ Technical details of hardware or software
+ </li>
+ <li>
+ Design issues
+ </li>
+</ul>
+<h4>
+ Identify alternate flows
+</h4>
+<p>
+ A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to
+ specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways
+ that the system provides a behavior, or it may describe failure or exception cases.
+</p>
+<p>
+ As you detail the main scenario, identify alternate flows by asking these questions:
+</p>
+<ul>
+ <li>
+ Are there different options available, depending on input from the Actor? (for example, if the Actor enters an
+ invalid PIN number while accessing an ATM)
+ </li>
+ <li>
+ What business rules may come into play? (for instance, the Actor requests more money from the ATM than is available
+ in her account)
+ </li>
+ <li>
+ What could go wrong? (such as no network connection available when required to perform a transaction)
+ </li>
+</ul>
+<p>
+ It is best to develop these scenarios iteratively, as well. Begin by identifying them. Examine each possible scenario
+ to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios.
+ Eliminate redundant or unnecessary scenarios, and then start elaborating on the more important ones.
+</p>
+<h4>
+ Structure the use case
+</h4>
+<p>
+ It is useful to structure the use case according to scenarios. This helps both to simplify communication and
+ maintenance and to permit the use cases to be implemented iteratively.
+</p>
+<p>
+ In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios
+ themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress.
+ Unless a sub-flow involves only a minor part of the complete flow of events (which can be described in the body of the
+ text), it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Sub-flows
+ that should be in a separate section include these examples:
+</p>
+<ul>
+ <li>
+ Sub-flows that occupy a large segment of a given flow of events.
+ </li>
+ <li>
+ Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more
+ clearly.
+ </li>
+ <li>
+ Any sub-flow that can be executed at several intervals in the same flow of events.
+ </li>
+</ul>
+<p>
+ For more information, see the "Flow of Events - Structure"&nbsp;section in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<h4>
+ Describe special requirements
+</h4>
+<p>
+ You should also capture any requirements that are related to the use case, but are not taken into consideration in the
+ flow of events of the use case. Such requirements are likely to be nonfunctional.
+</p>
+<p>
+ Typically, nonfunctional requirements that refer to a specific use case are captured in the special requirements
+ section of the use case. For more information, see the "Special Requirements" section in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<p>
+ If there are nonfunctional requirements that apply to more than one use case, capture these in the <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. For more information on supporting requirements
+ see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html"
+ guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.<br />
+</p>
+<h4>
+ Describe preconditions and postconditions
+</h4>
+<p>
+ A <strong>precondition</strong> on a use case explains the state that the system must be in for the use case to be able
+ to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that
+ may already have taken place.
+</p>
+<p>
+ A <strong>postcondition</strong> on a use case lists possible states that the system can be in at the end of the use
+ case execution. The system must be in one of those states. A postcondition also states actions that the system performs
+ at the end of the use case, regardless of what occurred in the use case. Post-Conditions may be categorized as Minimal
+ Guarantees&nbsp;or Success Guarantees.&nbsp; A Minimal Guarantee represents a condition that will be true when the use
+ case ends, regardless of how it terminates.&nbsp; A Success Guarantee represents a condition that will be true when the
+ use case ends successfully, regardless of which path it took.
+</p>
+<p>
+ Neither preconditions nor postconditions should be used to create a sequence of use cases. As a general rule, there
+ should never be a case where you have to first perform one use case and then another to have a meaningful flow of
+ events. If that is the case, correct the problem by reviewing the use cases.&nbsp;For more information, see the
+ "Preconditions" and "Postconditions" sections in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/develop_architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/develop_architecture.xmi
new file mode 100644
index 0000000..8fe9c7c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/develop_architecture.xmi
@@ -0,0 +1,195 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-t7mQSRPYITkMoYRVNz7jQg" name="develop_architecture,_mDf2EBapEduSTJywppIxVQ" guid="-t7mQSRPYITkMoYRVNz7jQg" changeDate="2007-02-26T03:44:53.453-0800" version="1.0.0">
+ <mainDescription><h4>
+ Identify architectural priorities
+</h4>
+<p>
+ Architecture&nbsp;priorities&nbsp;can take the form of&nbsp;one or more <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s brought into scope by association to the scenarios
+ prioritized for the current iteration. Other drivers may also be apparent. For example, it may be necessary to move
+ certain aspects of the architecture from prototypical to production quality implementation; or explore certain aspects
+ of the architecture to inform future iterations.
+</p>
+<p>
+ The architectural&nbsp;priorities are often&nbsp;driven by&nbsp;the development of software that implements an&nbsp;<a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>.&nbsp;It is important to specify the qualities of these
+ mechasnisms precisely and this may lead you to supplement the usage scenarios with quality attributes. As more than one
+ usage scenario may plkace demands on the same mechanisms, it may be helpful to consolidate these into quality
+ scenarios.
+</p>
+<p>
+ For example, if you want a system to be secure, specify the types of threats. Quality scenarios are one way to express
+ desired qualities in collaboration with the system stakeholders [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">KAZ04</a>]. Walk through things that could happen to the system and How it would
+ respond. <strong>Use-case scenarios</strong> focus on run-time behavior where the stakeholder is the user.
+ <strong>Quality scenarios</strong> encompass other interactions with the system as well, such as system maintenance
+ staff modifying the system.
+</p>
+<p>
+ Several scenarios may be devised for each quality attribute (such as usability, reliability, performance,
+ or&nbsp;security). For instance, security scenarios for denial of service and unauthorized access. A good scenario
+ makes clear what the stimulus is, what causes it, and what responses are appropriate.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ During peak operation, an unauthorized intruder tries to download prohibited data through the system
+ administrator’s interface. The system detects the attempt, blocks access, and notifies the supervisor within 15
+ seconds.
+ </p>
+</blockquote>
+<p>
+ After you have collected the scenarios, you need to establish priorities for them. Use scenarios to realize
+ requirements, so that their mapping onto the architecture, their impact, and their interactions can be understood.
+</p>
+<h4>
+ Refine &nbsp;the architecture mechanisms
+</h4>
+<p>
+ Consider each high-priority quality scenario, and map each of these onto the architecture mechanisms. Refine the
+ mechanisms to identify the specific technology&nbsp;to be used&nbsp;to handle each mechanism in scope. For example, for
+ the Persistence mechasnism, it may be appropriate to&nbsp;use a relational database management system such as
+ MySQL.&nbsp;Consider the selection of technology in the context of the requirements and constraints.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a> for more information.
+</p>
+<h4>
+ Identify Business Patterns
+</h4>
+<p>
+ The&nbsp;architecture of&nbsp;a software system can often be characterised by a small number of essential scenarios.
+ For example, for an on-line book store describing the way the software handles the scenarios for ordering a book and
+ checking out the shopping cart are often enough to communicate the essence of the architecture. Such business patterns
+ also provide a useful blueprint for similar functionality throughout the system.
+</p>
+<h4>
+ Identify reuse opportunities
+</h4>
+<p>
+ After looking for similar behavior and returned values, then look for similarity of parameters. If their
+ interfaces&nbsp;are not an exact match for the component interfaces being proposed, you can modify the
+ proposed&nbsp;signatures to increase the degree of reuse. Some design mechanisms, such as performance or security
+ requirements, may disqualify a component from reuse even when there is&nbsp;a perfect match between operation
+ signatures.
+</p>
+<p align="left">
+ A common set of components may exist that provides many of the <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> that you need&nbsp;for the new system. These components may
+ be available either because they were developed or purchased previously for&nbsp;similar systems. Given their
+ suitability and compatibility within the software architecture, there may be a need to reverse-engineer these
+ components to represent them in a design model and reuse them in a project.
+</p>
+<p align="left">
+ Similar thinking applies to&nbsp;existing databases. Part of the information to be used by the application under
+ development may already reside in a database. You may be able to get the classes that represent the database structures
+ that hold this information by reverse-engineering the database.
+</p>
+<h4 align="left">
+ Identify architecturally significant design elements
+</h4>
+<p align="left">
+ Consider&nbsp;each high-priority&nbsp;scenario in scope. Walk through the actions that the&nbsp;scenario initiates and
+ highlight the areas of the architecture that participate in realizing, or implementing, the requirements.
+</p>
+<p>
+ Identifying components will help hide the complexity of the system and help you work at a higher level. Components need
+ to be internally cohesive and to provide external services through a limited interface. Component identification can
+ be&nbsp;based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions:
+</p>
+<ul>
+ <li>
+ What is logically or functionally related (same use case or service, for example)?
+ </li>
+ <li>
+ What entities provide services to multiple others?
+ </li>
+ <li>
+ What entities depend on each other? Strongly or weakly?
+ </li>
+ <li>
+ What entities should you be able to exchange independently from others?
+ </li>
+ <li>
+ What will run on the same processor or network node?
+ </li>
+ <li>
+ What parts are constrained by similar performance requirements?
+ </li>
+</ul>
+<p>
+ Each component includes entities from the problem domain, control classes that coordinate complex tasks within
+ components, and interfaces that handle communication with the environment. The interface for each instantiated element
+ is identified. At this point, interfaces do not need to be as detailed as a signature, but they do need to document
+ what the elements need, what they can use, and what they can depend on.
+</p>
+<p>
+ Identified patterns define the types of elements, but not a specific number. Apply the chosen patterns to define a new
+ set of elements that conform to the patterns. Functionality will be allocated to the instantiated elements.
+</p>
+<h4>
+ Define development and test architectures
+</h4>
+<p>
+ The development and test architectures may be different from the target production implementation.
+</p>
+<ul>
+ <li>
+ Additional software may need to be developed to support testing.
+ </li>
+ <li>
+ Alternative deployment configurations may need to be defined in response to constraints on development hardware.
+ </li>
+ <li>
+ Multiple environments may be required to support different categories of tests.
+ </li>
+</ul>
+<p>
+ In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall
+ architecture.
+</p>
+<h4>
+ Validate the architecture
+</h4>
+<p>
+ The surest way to validate the architecture is through software. The software developed up to the end of the
+ Elbaoration Phase is largely aiming to validate the architecture, to the point where it can be baselined, thereby
+ providing some level of stability during the Construction phase.
+</p>
+<p>
+ It can also be useful to perform simple validation by walking through the main design concepts and models, perhaps
+ around a whiteboard or through other collaborative techniques. This can help refine thinking but will not act as a
+ subsitute for building some software.
+</p>
+<h4>
+ Communicate decisions
+</h4>
+<p>
+ You can document and communicate your decisions as many ways as you wish:
+</p>
+<ul>
+ <li>
+ Publication of&nbsp;reference source code.
+ </li>
+ <li>
+ Publication of&nbsp;reference models.
+ </li>
+ <li>
+ Publication of&nbsp;software architecture documentation.
+ </li>
+ <li>
+ Formal&nbsp;presentations of the material.
+ </li>
+ <li>
+ Informal walkthroughs of the architecture
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/effective_req_reviews.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/effective_req_reviews.xmi
new file mode 100644
index 0000000..0b3184e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/effective_req_reviews.xmi
@@ -0,0 +1,103 @@
+<?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" epf:version="1.0.0" xmi:id="-pNA0DbSdSoUqnjQIiOeHcQ" name="achieving_concurrence,_E-dPIL-GEdqb7N6KIeDL8Q" guid="-pNA0DbSdSoUqnjQIiOeHcQ" changeDate="2006-09-22T09:09:40.793-0400" version="1.0.0">
+ <mainDescription><p>
+ The cost of correcting errors increases exponentially throughout the development lifecycle <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[BOE88]</a>. Therefore, it is important to discover problems early enough to solve them
+ quickly and inexpensively.
+</p>
+<p>
+ Requirements reviews are intended to discover problems with the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;before you spend significant time and work in implementing the
+ wrong thing. This is not to say that you must have a complete set of requirements before implementation, but be sure to
+ review, internally and with stakeholders, those that are selected for implementation in the early iterations and those
+ that will have a broad impact on the system (often called <a class="elementLink" href="./../../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>) to ensure everyone's concurrence before
+ investing significant effort in implementation.
+</p>
+<h4>
+ Informal reviews
+</h4>
+<p>
+ Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a
+ prototype.
+</p>
+<p>
+ These informal reviews are excellent for getting the structure of the requirements correct and removing obvious
+ mistakes. By keeping the review team small, it is easier to make rapid progress. However, informal reviews can miss
+ important perspectives&nbsp;of&nbsp;critical stakeholders.
+</p>
+<h4>
+ Formal reviews
+</h4>
+<p>
+ Requirement reviews can be formal meetings. Start with careful preparation, so that you receive and organize comments
+ before the meeting. The meeting itself should produce decisions on all review items. After the meeting, you must pursue
+ the review actions to completion. If these actions involve a substantial amount of work or require a change to an
+ artifact that is under configuration control, consider submitting <a class="elementLink" href="./../../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> to prioritize and track the work. See&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a>&nbsp;and the associated&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">Guideline: Change Requests</a>&nbsp;for more information on change requests.
+</p>
+<p>
+ Formal reviews are more wide-ranging and expensive. They provide for more balanced reviews from multiple
+ perspectives.&nbsp; However, formal reviews involve more people, which makes them more difficult to coordinate (thus
+ the need for formality) and expensive in terms of work hours.
+</p>
+<h4>
+ Two-tier reviews
+</h4>
+<p>
+ One technique to get the best of both worlds is to use staged, or "two-tier", reviews&nbsp;<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO03]</a>. The&nbsp;first tier is informal and performed by a smaller team, possibly
+ many times. The second&nbsp;tier is more formal and performed by the complete group, perhaps only once.
+</p>
+<p>
+ <strong>First-tier review:</strong> The authors of the requirements and the development team&nbsp;review the
+ requirements during the first-tier reviews to ensure that they are&nbsp;unambiguous, complete&nbsp;and
+ consistent.&nbsp; It is important to include testers and developers to ensure that the requirements are verifiable and
+ feasible.&nbsp;These reviews&nbsp;determine whether the requirements are ready for the larger community to
+ review.&nbsp; First-tier reviews may be informal, formal, or a combination of the two.
+</p>
+<p>
+ <strong>Second-tier review:</strong> Involve the larger group during the higher-tier review to get more minds working
+ on the problem and to achieve concurrence that the requirements are suitable for implementation and validation.&nbsp;
+ It is best to have one formal requirement review at the Lifecycle Objective (LCO) milestone and, optionally, one at the
+ Lifecycle Architecture (LCA) milestone if significant changes have occurred that introduce unacceptable risk.
+</p>
+<p>
+ At both stages, these two resources will be helpful: <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/good_requirements,_jxn9EO0HEdqHTdbLTmC5IQ.html" guid="_jxn9EO0HEdqHTdbLTmC5IQ">Checklist: Qualities of Good Requirements</a>&nbsp;and <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html" guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>
+</p>
+<p>
+ Tiered reviews offer several benefits:
+</p>
+<ol>
+ <li>
+ Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on
+ functionality
+ </li>
+ <li>
+ Provide a professional look to the requirements, presenting both the requirements and their authors in the best
+ possible light
+ </li>
+ <li>
+ Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or
+ diminished effectiveness from overload and stress
+ </li>
+ <li>
+ Provide the best opportunity for full, effective reviews.
+ </li>
+</ol>
+<h4>
+ Golden rules of reviewing
+</h4>
+<p>
+ Follow these golden&nbsp;rules of reviewing <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>:
+</p>
+<ol>
+ <li>
+ <strong>Encourage criticism:</strong> Remember that people are improving the requirements, not criticizing you.
+ Even the harshest criticism often contains a grain of truth. Adopt the attitude that every suggestion is a gift.
+ </li>
+ <li>
+ <strong>Choose your best reviewers:</strong> A few specific people make the best reviewers, time and again.
+ Cultivate them.
+ </li>
+ <li>
+ <strong>Allow adequate time:</strong> It's not over until you have agreed upon and made the corrections.<br />
+ &nbsp;
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.xmi
new file mode 100644
index 0000000..4d99645
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.xmi
@@ -0,0 +1,59 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-CJ--jlBqXi3FzdOM_dw5_w" name="new_guideline,_V4qNUAn_Edu0OeEVPFogVA" guid="-CJ--jlBqXi3FzdOM_dw5_w" changeDate="2006-07-10T15:10:58.826-0700">
+ <mainDescription><p> The following shows how to capture information for <a class="elementLinkWithType"
+ href="file:///c|/documents%20and%20settings/rbalduino/my%20documents/tng/beacon/copyedit/structure_for_importing/openup_basic/openup_basic/guidances/concepts/analysis_mechanism,_0gvqomlgedmt3adzl5dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Concept: Analysis Mechanism</a>. </p>
+<h3> Persistence </h3>
+<p>For all classes with instances that may become persistent, you need to identify:
+
+<ul>
+ <li>
+ <p><b>Granularity</b><strong>:</strong> What is the range of size of the objects
+ to keep persistent?</p>
+ </li>
+ <li>
+ <p><b>Volume</b><strong>: </strong>How many objects (number) do you need to
+ keep persistent?</p>
+ </li>
+ <li>
+ <p><b>Duration</b><strong>:</strong> How long does the object typically need
+ to be kept?</p>
+ </li>
+ <li>
+ <p><b>Retrieval mechanism</b><strong>: </strong>How is a given object uniquely
+ identified and retrieved? </p>
+ </li>
+ <li>
+ <p><b>Update frequency</b><strong>: </strong>Are the objects more or less
+ constant? Are they permanently updated? </p>
+ </li>
+ <li>
+ <p><b>Reliability</b><strong>: </strong>Do the objects need to survive a crash
+ of the process, the processor, or the whole system? </li>
+</ul>
+<h3>Communication </h3>
+<p>For all model elements that need
+ to communicate with components or services that are running in other processes
+ or threads, you need to identify </p>
+<ul>
+ <li>
+ <p><b>Latency</b><strong>: </strong>How
+ fast must processes communicate with another? </p>
+ </li>
+ <li>
+ <p><b>Synchronicity</b><strong>:
+ </strong>Asynchronous communication. </p>
+ </li>
+ <li>
+ <p><b>Size of message</b><strong>:
+ </strong>A spectrum might be more appropriate than a single number. </p>
+ </li>
+ <li>
+ <p><strong>Protocol:</strong> Flow control, buffering,
+ and so on.</p>
+ </li>
+</ul>
+<p> Notice that there is no design-level
+ information or specification here. Instead, this is more about collating and
+ refining architecturally significant requirements. </p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_architectural_mechanisms.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_architectural_mechanisms.xmi
new file mode 100644
index 0000000..a4b9f99
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_architectural_mechanisms.xmi
@@ -0,0 +1,258 @@
+<?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" epf:version="1.0.0" xmi:id="-FqP5LgLVrlhvFC_eeYd_vA" name="example_architectural_mechanisms,_4k_HsQ4LEduibvKwrGxWxA" guid="-FqP5LgLVrlhvFC_eeYd_vA" changeDate="2006-09-19T13:56:22.466-0700">
+ <mainDescription><p>
+ Here are some examples of commonly encountered architectural mechanisms.<br />
+ <br />
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Example Architectural Mechanisms" border="1" valign="top">
+ <caption>
+ <strong>Example Architectural Mechanisms</strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ Architectural Mechanism
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Availability
+ </td>
+ <td>
+ The percentage of time that the system must be available for use, including planned outages.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Archiving
+ </td>
+ <td>
+ Provides a means to move data from active storage when it has reached a specific state.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Auditing
+ </td>
+ <td>
+ Provides audit trails of system execution.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Communication
+ </td>
+ <td>
+ A mechanism for handling inter-process communication.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Debugging
+ </td>
+ <td>
+ Provides elements to support application debugging.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Disaster Recovery
+ </td>
+ <td>
+ Provides facilities to recover systems, application, data and networks.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Error Management
+ </td>
+ <td>
+ Allows errors to be detected, propagated, and reported.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Event Management
+ </td>
+ <td>
+ Supports the use of asynchronous events within a system.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Graphics
+ </td>
+ <td>
+ Supports user interface services, such as 3D rendering.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Information Exchange
+ </td>
+ <td>
+ Supports information interchange accross technical and organisational boundaries, with appropriate semantic
+ and format translations.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Licensing
+ </td>
+ <td>
+ Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as
+ part of authorising corporate bodies.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Localisation / Internationalisation
+ </td>
+ <td>
+ Provides facilities for supporting multiple human languages and rendering the language preffered by the
+ user.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mail
+ </td>
+ <td>
+ Services that allow applications to send and receive electronic mail.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mega-data
+ </td>
+ <td>
+ Support for handling very large amounts of data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Memory Management
+ </td>
+ <td>
+ Services for abstracting how memory is allocated and freed.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Meta-data
+ </td>
+ <td>
+ Supports the runtime introspection of components and data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Online help
+ </td>
+ <td>
+ Provides online help capability
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Persistence
+ </td>
+ <td>
+ Services to&nbsp;handle&nbsp;the reading and&nbsp;writing of&nbsp;stored&nbsp;data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Printing
+ </td>
+ <td>
+ Provides facilities for interfacing with printers.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Process Management
+ </td>
+ <td>
+ Provides support for the management of processes and threads.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Reporting
+ </td>
+ <td>
+ Provides flexible reporting facilities
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Resource Management
+ </td>
+ <td>
+ Provides support for the management of expensive resources, such as database connections.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Scheduling
+ </td>
+ <td>
+ Provides the ability to execute tasks at a specified time.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Security
+ </td>
+ <td>
+ Provides services to protect access to certain resources or information.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ System Management
+ </td>
+ <td>
+ Services that facilitate management of applications in an operational environment.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Time
+ </td>
+ <td>
+ Services to synchronise time on a network, and to translate times into different time zones.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Transaction Management
+ </td>
+ <td>
+ A mechanism for handling ACID transactions.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Workflow
+ </td>
+ <td>
+ Support for the movement of documents and other items of work, typically through an organisation.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<br />
+<br />
+<br />
+
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_design_mechanisms.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_design_mechanisms.xmi
new file mode 100644
index 0000000..fcbf77f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/example_design_mechanisms.xmi
@@ -0,0 +1,268 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-mAo18f36rZ1R98kpZX7HMw" name="new_guideline,_K32gYAoBEdu0OeEVPFogVA" guid="-mAo18f36rZ1R98kpZX7HMw" changeDate="2006-07-10T15:11:18.051-0700" version="1.0.0">
+ <mainDescription><h3> Design
+ Mechanism Characteristics and Mapping</h3>
+<p> Consider the analysis mechanism for <strong>persistence</strong>. </p>
+<ul>
+ <li> There might be a need for many (2,000) small objects (200 bytes each) to
+ be stored for a few seconds, with no need for them to
+ survive thereafter. </li>
+ <li> There might be a need for several <strong></strong>very large <strong></strong>
+ objects to be stored permanently on disk for several months, never updated,
+ but with sophisticated means of retrieval. </li>
+</ul>
+<p> These objects require different support
+ for persistency. The best option depends on the characteristics
+ of the design mechanism:</p>
+<ul>
+
+ <li> <b>In-memory storag</b><strong>e: </strong>For up to 1 Mb total (size x
+ volume); very fast access for read, write, update. </li>
+ <li> <b>Flash card</b><strong>:</strong> For up to 8 Mb; slow update and write
+ access; moderate read access. </li>
+ <li> <b>Binary file</b><strong>:</strong> For 100 Kb to 200 Mb; slow update;
+ slow read-and-write access. </li>
+ <li> <b>Database management system (DBMS)</b><strong>: </strong>For 100 Kb and
+ upward (essentially no upper limit); even slower update and read-and-write
+ access. </li>
+</ul>
+<p> Note that these speeds are rated as slow only as compared
+ to in-memory storage. Obviously, in some environments, caching can improve
+ apparent access times. (See Figure 1.)</p>
+<blockquote>
+
+ <p align="center"> <img height="221" title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" alt="Mapping Analyis Mechanisms to Design Mechanisms and Classes" src="./resources/co_dmec1.gif"
+ width="372" /> </p>
+</blockquote>
+<div align="center">
+ <p><strong>Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes</strong></p>
+ <h3 align="left">Mapping Design Mechanisms to Implementation Mechanisms </h3>
+ <p align="left"> The <b>persistence</b> design mechanisms can be mapped to implementation
+ mechanisms as Figure 2 shows: </p>
+ <p align="center"> <img height="216" title="Figure 2. How persistence design mechanism map to implementation mechanism" alt="How persistence design mechanism map to implementation mechanism" src="./resources/co_dmec2.gif" width="325" /></p>
+ <p align="center"><strong>Figure 2. How persistence design
+ mechanism map to implementation mechanism</strong> </p>
+ <p align="left">A possible mapping between analysis mechanisms and design mechanisms.
+ Dotted arrows mean "is specialized by," implying that the characteristics
+ of the design mechanisms are inherited from the analysis mechanisms but that
+ they will be specialized and refined. </p>
+ <p align="left"> After you have finished optimizing the mechanisms, the following
+ mappings exist (see Figure 3): </p>
+ <blockquote>
+ <p align="center"> <img height="110" title="Figure 3. Mapping structure after optimizing the mechanisms" alt="Illustration of mapping structure after optimizing the mechanisms" src="./resources/co_dmec3.gif" width="418" />
+ </p>
+ <p align="center" class="picturetext"><strong>Figure 3. Mapping structure
+ after optimizing the mechanisms </strong></p>
+ <p align="left" class="picturetext">The design decisions for a client class
+ in terms of mappings between mechanisms. The Flight
+ class needs two forms of persistency<strong>:</strong> <strong>in-memory
+ storage</strong>, implemented by a predefined
+ library routine, and <strong>a database,</strong> implemented with an off-the-shelf
+ ObjectStorage product. </p>
+ </blockquote>
+ <p align="left"> The map must be navigable in both directions to make it easy
+ to determine client classes when changing implementation mechanisms. </p>
+ <h4 align="left">Refining
+ the mapping between design and implementation mechanisms </h4>
+</div>
+<p> Initially, the mapping between design mechanisms and implementation mechanisms
+ is likely to be less than optimal, but it will get the project running, identify
+ unforeseen risks, and trigger further investigations and evaluations. As the
+ project continues and you gain more knowledge, you will need to refine the mapping.
+</p>
+<p> Proceed iteratively to refine the mapping between design and implementation
+ mechanisms. Eliminate <strong></strong>redundant
+ paths, working both top-down and bottom-up. </p>
+<p> <b>Working top-down: </b>When working top-down (from top to bottom), new and
+ refined use-case realizations will put new requirements on the necessary design
+ mechanisms through the analysis mechanisms that you need. These new requirements
+ might uncover additional characteristics of a design mechanism, forcing a split
+ between mechanisms. A compromise between the system's complexity and its performance
+ is also necessary: </p>
+<ul>
+ <li>
+ Too many different design mechanisms make the system too complex.
+ </li>
+ <li> Too few design mechanisms can create performance problems for implementation
+ mechanisms that stretch the limits of the reasonable ranges of the values
+ of their characteristics. </li>
+</ul>
+<p> <b>Working bottom-up: </b>When working bottom-up (from bottom to top) and
+ investigating the available implementation mechanisms, you might find products
+ that satisfy several design mechanisms at once, but force some adaptation or
+ repartitioning of your design mechanisms. You want to minimize the number of
+ implementation mechanisms you use, but too few of them can also lead to performance
+ problems. </p>
+<p> After you decide to use a DBMS to store class A objects, you might be tempted
+ to use it to store all objects in the system. This could be very inefficient
+ or very cumbersome. Not all objects that require persistency need to be stored
+ in the DBMS. Some objects may be persistent, but one application may access
+ them frequently, while other applications access them only infrequently. A hybrid
+ strategy, in which the object is read from the DBMS into memory and periodically
+ synchronized, may be the best approach. </p>
+<blockquote>
+ <p class="example"> <b>Example</b> </p>
+ <p class="example"> A flight can be stored both in memory for fast access and
+ in a DBMS for long-term persistency. However, this triggers a need for a mechanism
+ to synchronize both. </p>
+</blockquote>
+<p> It is not uncommon to have more than one design mechanism associated with
+ a client class as a compromise between different characteristics. </p>
+<p> Because implementation mechanisms often come in bundles in off-the-shelf components
+ (operating systems and middleware products), some optimization based on cost,
+ impedance mismatch, or uniformity of style needs to occur. Also, mechanisms
+ are often interdependent, which makes clear separation of services into design
+ mechanisms difficult. </p>
+<blockquote>
+ <p class="example"> <b>Examples</b> </p>
+ <ul>
+ <li> The notification mechanism can be based on the inter-process communication
+ mechanism. </li>
+ <li> The error reporting mechanism can be based on the persistency mechanism.
+ </li>
+ </ul>
+</blockquote>
+<p> Refinement continues over the whole Elaboration phase, and is always a compromise
+ between: </p>
+<ul>
+
+ <li> An exact fit with the requirements of the clients of the design mechanism,
+ in terms of the expected characteristics. </li>
+ <li>
+ The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
+ </li>
+</ul>
+<p> The overall goal is always to have a simple, clean set of mechanisms that
+ give conceptual integrity, simplicity, and elegance to a large system. </p>
+<h3> Describing Design Mechanisms </h3>
+<p>
+ As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
+ architectural or design patterns (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>).
+</p>
+<blockquote>
+ <p> <strong>Example: A persistence mechanism </strong></p>
+ <p> This example uses an instance of a pattern for RDBMS-based persistency drawn
+ from <strong></strong><a
+ href="http://java.sun.com/products/jdbc/index.html" target="_blank" ><u>Java&#8482;
+ Database Connectivity (JDBC)</u></a>. Although we present the design here,
+ JDBC supplies actual code for some of the classes. Therefore, it is a short
+ step from what is presented here to an implementation mechanism. </p>
+</blockquote>
+<p> Figure 4, titled <strong> JDBC: Static view,</strong> shows the classes (actually,
+ the classifier roles) in the collaboration. <strong></strong></p>
+<p align="center"> <img height="382" title="Figure 4. JDBC: Static View" alt="Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. " src="./resources/jdbc1.gif" width="571" /></p>
+<p align="center"> <strong>Figure 4. JDBC: Static view </strong></p>
+<p align="left"> The yellow classes are the ones that were supplied. The others,
+ in tan (myDBClass and so on),
+ were bound by the designer to create the mechanism. </p>
+<p align="left"> In a Java database class, a client will work with a <b>DBClass</b>
+ to read and write persistent data. The DBClass is responsible for accessing the JDBC database, using the <b>DriverManager</b>
+ class. Once a database <b>connection</b> is open, the DBClass can then create SQL statements that will be sent to the underlying RDBMS
+ and executed using the <b>Statement</b> class. The Statement class is what communicates with the database. The result of the SQL query
+ is returned in a <b>ResultSet</b> object.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p align="left"> The <b>DBClass</b> is responsible for making another class instance
+ persistent. It understands the OO-to-RDBMS mapping and can interface with the
+ RDBMS. The DBClass flattens the
+ object, writes it to the RDBMS, and then reads the object data from the RDBMS
+ and builds the object. Every class that is persistent has a corresponding DBClass.&nbsp;
+</p>
+<p align="left"> The <b>PersistentClassList</b> is used to return a set of persistent
+ objects as a result of a database query, for example: DBClass.read().
+</p>
+<p align="left"> A series of dynamic views follow, in Figures 5 thorough 9, to
+ show how the mechanism actually works. <strong></strong></p>
+<p align="center"> <img height="146" title="Figure 5. JDBC: Initialize" alt="Diagram of JDBC: Initialize" src="./resources/jdbc2.gif" width="285" />
+</p>
+<p align="center"> <b>Figure5. JDBC: Initialize</b> </p>
+<p>
+ Initialization must occur before any persistent class can be accessed.
+</p>
+<p> To initialize the connection to the database, the DBClass
+ must load the appropriate driver by calling the DriverManager
+ getConnection() operation with a URL, user, and password. </p>
+<p> The operation getConnection()
+ attempts to establish a connection to the given database URL. The driver manager
+ attempts to select an appropriate driver from the set of registered JDBC drivers.
+</p>
+<blockquote>
+ <p> <strong>Parameters</strong></p>
+ <blockquote>
+ <p> <b>URL</b><strong>: </strong>A database URL in the form jdbc:subprotocol:subname.
+ This URL is used to locate the actual database server and is not Web-related,
+ in this instance. </p>
+ <p> <b>user</b><strong>: </strong>The database user who is making the connection.</p>
+ <p> <b>pass</b><strong>:</strong> The user's password </p>
+ </blockquote>
+ <p> <strong>Returns</strong></p>
+ <blockquote>
+ <p> A connection to the URL.</p>
+ </blockquote>
+</blockquote>
+<p align="center"> <img height="253" title="Figure 6. JDBC: Create" alt="Diagram of JDBC: Crreate" src="./resources/jdbc3.gif" width="478" />
+</p>
+<p align="center"> <b>Figure 6. JDBC: Create</b> </p>
+<p align="left"> To create a new class, the persistency client asks the DBClass
+ to create the new class. The DBClass
+ creates a new instance of PersistentClass with default values. The DBClass
+ then creates a new Statement using the Connection class createStatement()
+ operation. The Statement runs,
+ and the data is added to the database.</p>
+<p align="center"> <img height="352" title="Figure 7. JDBC: Read" alt="Diagram of JDBC: Read" src="./resources/jdbc4.gif" width="600" />
+</p>
+<p align="center"> <b>Figure 7. JDBC: Read</b> </p>
+<p> To read a persistent class, the persistency client asks the DBClass
+ to read. The DBClass creates
+ a new Statement using the Connection class createStatement() operation. The Statement is executed, and the
+ data is returned in a ResultSet object. The DBClass then creates
+ a new instance of the PersistentClass and populates it with the retrieved data. The data is returned in a collection
+ object, an instance of the PersistentClassList class. </p>
+<p> <strong>Note: </strong></p>
+<p>The string passed to executeQuery()
+ is not necessarily exactly the same string as the one passed into the
+ read(). The DBClass
+ will build the SQL query to retrieve the persistent data from the database,
+ using the criteria passed into the .
+ This is because it is not useful for the client of the DBClass
+ to know the internal structure of the database to create a valid query. This
+ knowledge is encapsulated within DBClass.
+</p>
+<p align="center"> <img height="255" title="Figure 8. JDBC: Update" alt="Diagram of JDBC: Update" src="./resources/jdbc5.gif" width="473" />
+</p>
+<p align="center"> <b>Figure 8. JDBC: Update</b> </p>
+<p> To update a class, the persistency client asks the
+ DBClass to update. The DBClass
+ retrieves the data from the given PersistentClass object, and creates a new Statement
+ using the Connection class createStatement()
+ operation. Once the Statement
+ is built, the database is updated with the new data from the class. </p>
+<p> <strong>Remember: </strong>It is the job of the DBClass
+ to flatten the PersistentClass and
+ write it to the database. That is why it must be retrieved from the given PersistentClass
+ before creating the SQL Statement.
+</p>
+<p> <strong>Note: </strong></p>
+<p>In the above mechanism, the PersistentClass
+ must provide access routines for all persistent data so that
+ DBClass can access them. This provides external access to certain persistent
+ attributes that would have been private otherwise. This is a price you have
+ to pay to pull the persistence knowledge out of the class that encapsulates
+ the data.</p>
+<p align="center"> <img height="255" title="Figure 9. JDBC: Delete" alt="Diagram of JDBC: Delete" src="./resources/jdbc6.gif" width="473" />
+</p>
+<p align="center"> <b>Figure 9. JDBC: Delete</b></p>
+<p align="left"> To delete a class, the persistency client asks the DBClass to delete the PersistentClass.
+ The DBClass creates a new Statement using the Connection class createStatement()
+ operation. The Statement is
+ executed and the data is removed from the database. </p>
+<p align="left"> In the actual implementation of this design, you would make some
+ decisions about the mapping of DBClass
+ to the persistent classes, such as having one DBClass
+ per persistent class and allocating them to appropriate packages. These packages
+ will depend on<strong> </strong>the supplied java.sql file (see <a href="http://java.sun.com/products/jdbc/index.jsp">JDBC:
+ API Documentation</a>)<strong> </strong>package that contains the supporting
+ classes DriverManager, Connection, Statement,
+ and ResultSet. </p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.xmi
new file mode 100644
index 0000000..0b1b517
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.xmi
@@ -0,0 +1,144 @@
+<?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" epf:version="1.0.0" xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" name="find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA" guid="-Rcm_MlViENAvFFyIe9V3dQ" changeDate="2006-10-23T13:31:13.565-0700" version="1.0.0">
+ <mainDescription><h4>
+ Finding actors
+</h4>
+<p>
+ Find the external entities with which the system under development must interact. Candidates include groups of users
+ who will require help from the system to perform their tasks and execute the system's primary or secondary functions,
+ as well as external hardware, software, and other systems.
+</p>
+<p>
+ Define each candidate actor by naming it and writing a brief description. Includes the actor's area of responsibility
+ and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not
+ have any goals.
+</p>
+<p>
+ These questions are useful in identifying actors:
+</p>
+<ul>
+ <li>
+ Who will supply, use, or remove information from the system?
+ </li>
+ <li>
+ Who will use the system?
+ </li>
+ <li>
+ Who is interested in a certain feature or service provided by the system?
+ </li>
+ <li>
+ Who will support and maintain the system?
+ </li>
+ <li>
+ What are the system's external resources?
+ </li>
+ <li>
+ What other systems will need to interact with the system under development?
+ </li>
+</ul>
+<p>
+ Review the list of stakeholders that you captured in the Vision statement. Not all stakeholders will be actors
+ (meaning, they will not all interact directly with the system under development), but this list of stakeholders is
+ useful for identifying candidates for actors.
+</p>
+<h4>
+ Finding use cases
+</h4>
+<p>
+ The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not,
+ ask:
+</p>
+<ul>
+ <li>
+ What are the goals that the actor will attempt to accomplish with the system?
+ </li>
+ <li>
+ What are the primary tasks that the actor wants the system to perform?
+ </li>
+ <li>
+ Will the actor create, store, change, remove, or read data in the system?
+ </li>
+ <li>
+ Will the actor need to inform the system about sudden external changes?
+ </li>
+ <li>
+ Does the actor need to be informed about certain occurrences, such as unavailability of a network resource,&nbsp;in
+ the system?
+ </li>
+ <li>
+ Will the actor perform a system startup or shutdown?
+ </li>
+</ul>
+<p>
+ Understanding how&nbsp;the target&nbsp;organization works and how this information system might be incorporated into
+ existing operations gives an idea of system's surroundings. That information may reveal other use case candidates.
+</p>
+<p>
+ Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case
+ does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case.
+</p>
+<h4>
+ Outlining Use Cases
+</h4>
+<p>
+ Without going into details, write a first draft of the flow of events of the use cases identified as being of high
+ priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step
+ description is a simple ordered list of interactions between the actor and the system. For example, the description of
+ the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this:
+</p>
+<ol>
+ <li>
+ The&nbsp;customer inserts a bank card.
+ </li>
+ <li>
+ The system validates the card and prompts the person to enter a personal identification number (PIN).
+ </li>
+ <li>
+ The customer&nbsp;enters a PIN.
+ </li>
+ <li>
+ The system validates the PIN and prompts the customer to select an action.
+ </li>
+ <li>
+ The customer selects Withdraw Cash.
+ </li>
+ <li>
+ The system prompts the customer to choose which account.
+ </li>
+ <li>
+ The customer selects the checking account.
+ </li>
+ <li>
+ The system prompts for an amount.
+ </li>
+ <li>
+ The customer enters the amount to withdraw.
+ </li>
+ <li>
+ The system validates the amount (assuming sufficient funds), and then issues cash and receipt.
+ </li>
+ <li>
+ The customer takes the cash and receipt, and then retrieves the bank card.
+ </li>
+ <li>
+ The use case ends.
+ </li>
+</ol>
+<p>
+ As you create this step-by-step description of the basic flow of events, you may discover alternative and exceptional
+ flows. For example, what happens if the customer enters an invalid PIN? Record the name and a brief description of each
+ alternate flow that you identified.
+</p>
+<h4>
+ Representing relationships between actors and use cases
+</h4>
+<p>
+ The relationship between actors and use cases should be captured, or documented&nbsp; There are several ways to do
+ this. If you are using a use-case model on the project, you can create use-case diagrams to show how&nbsp;actors and
+ use cases&nbsp;relate to each other.&nbsp; Refer to&nbsp;<a class="" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>&nbsp;for more information.
+</p>
+<p>
+ If you are not using a use-case model for the project, make sure that each use case identifies the associated primary
+ and secondary actors.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/implementation.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/implementation.xmi
new file mode 100644
index 0000000..098a2a5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/implementation.xmi
@@ -0,0 +1,79 @@
+<?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" epf:version="1.0.0" xmi:id="_4wqaMMPaEdmbOvqy4O0adg" name="implementation,_0Y0dsMlgEdmt3adZL5Dmdw" guid="_4wqaMMPaEdmbOvqy4O0adg" authors="Jim Ruehlin" changeDate="2006-12-01T16:13:39.278-0800" version="1.0">
+ <mainDescription><h5>
+ Code Reuse&nbsp;
+</h5>
+<p>
+ Code reuse and code generation tools produce more robust code and are preferable to writing code by hand. Existing code
+ has often already been tested and even deployed, making it more stable and well understood than new code. Source code
+ created from a code generation tool (such as a visual modeling tool) automates dreary coding tasks such as creating
+ getters and setters.
+</p>
+<p>
+ There are many places to harvest code for reuse:
+</p>
+<ul>
+ <li>
+ Internal (corporate) code libraries.
+ </li>
+ <li>
+ 3rd party libraries.
+ </li>
+ <li>
+ Built-in language libraries.
+ </li>
+ <li>
+ Code samples from tutuorials, examples, books, etc.
+ </li>
+ <li>
+ Local code guru or knowledgable colleague
+ </li>
+ <li>
+ Existing system code
+ </li>
+ <li>
+ Open source products (be sure to follow any licensing agreements)&nbsp;
+ </li>
+</ul>
+<h5>
+ Transforming the Design into the&nbsp;Implementation
+</h5>
+<p>
+ Transforming the design into code implements the system structure in the chosen source language. It also implements the
+ system behavior defined in the functional requirements. Implementing the system behavior means writing the code that
+ allows different parts of the application (classes or components) to collaborate in realizing the behavior of the
+ system.
+</p>
+<p>
+ There are various techniques for automatically transforming design to implementation. Here are some examples:
+</p>
+<ul>
+ <li>
+ Platform-specific visual models can be used to generate an initial code framework. This framework can be further
+ elaborated with additional code not specified in the design.<br />
+ </li>
+ <li>
+ Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and
+ behavior diagrams (such as state and activity diagram) can be used to generate executable code. These prototypes
+ can be further refined as needed.<br />
+ </li>
+ <li>
+ The design may be platform independent to varying degrees. Platform specific design models or even code can be
+ generated via transformations that apply various rules to map high level abstractions platform specific elements.
+ This is the focus of the Object Management Group (OMG) Model Driven Architecture (MDA) <a href="http://www.omg.org/" target="_blank">(http://www.omg.org</a>) initiative.<br />
+ </li>
+ <li>
+ Standard patterns can be applied to generate design and code elements from related design and implementation. For
+ example, a standard transformation pattern can be applied to a data table to create java classes to access the data
+ table. Another example is using an Eclipse Modeling Framework (<a href="http://www.eclipse.org/emf/" target="_blank">http://www.eclipse.org/emf/</a>) model to generate code for storing data that matches the model and
+ to generate a user interface implementation for populating data. A pattern or transformation engine can be used to
+ create the implementation, or the implementation can be done by hand. Pattern engines are easier and more reliable,
+ but hand-written code implementing a defined pattern will have fewer errors than hand-written code implementing a
+ novel or unique design.
+ </li>
+</ul>
+<p>
+ In all cases, however, some design abstraction (classes, components, etc)&nbsp;is detailed to become the
+ implementation.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/iteration_planning.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/iteration_planning.xmi
new file mode 100644
index 0000000..4c8c376
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/iteration_planning.xmi
@@ -0,0 +1,132 @@
+<?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" epf:version="1.0.0" xmi:id="_71hDkMPgEdmbOvqy4O0adg" name="iteration_plan,_0auiMMlgEdmt3adZL5Dmdw" guid="_71hDkMPgEdmbOvqy4O0adg" changeDate="2006-11-01T11:17:34.612-0800">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
+ iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
+ define how to assess that you accomplished what you set out to accomplish.
+</p>
+<p>
+ Iteration planning is ideally done with the entire team in a meeting, typically lasting a few hours, at the beginning
+ of an iteration. This ensures that the entire team understands what needs to be done, and they become committed to the
+ success of the team. In some cases, it is preferred to have a smaller subset of people, such as the Project Manager, an
+ Architect and an Analyst to meet in advance to prep the meeting with a draft iteration plan.
+</p>
+<h3>
+ Define High-Level Objectives
+</h3>
+<p>
+ A key aspect of an iteration is to focus the team on a short term deliverable of measurable value. Document 1-5
+ high-level objectives to make sure that you don't lose focus on what to accomplish during the iteration. Typically, the
+ project plan should outline one or several objectives for each iteration, and those objectives are used as a starting
+ point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
+</p>
+<p>
+ The objectives are usually based on the following factors:
+</p>
+<ul>
+ <li>
+ <strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
+ risks.
+ </li>
+ <li>
+ <strong>The time allocated to the iteration:</strong> Iterations are usually timeboxed, so the Project Manager must
+ ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the
+ iteration.
+ </li>
+ <li>
+ <strong>The highest priority features:</strong> requirements are prioritized to ensure that the critical features
+ of the application will be developed and tested early on.
+ </li>
+</ul>
+<h3>
+ Produce an Iteration Plan
+</h3>
+<p>
+ There is an Iteration Plan per iteration that should outline who will implement which Work Item in how long a time.
+ Since iterations are time-boxed, we need to understand how big our ‘box” is by assessing how many hours of actual work
+ can be taken on. Let’s assume that you have 6 team members, and you have 15 working days in your iteration, and you on
+ average can do 5 actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work. Note
+ that the average team member only performs 4-6 hours of actual project work per day, with the rest being consumed by
+ e-mails, meetings, and other overhead activities not directly related to the project.
+</p>
+<p>
+ The team should then revisit and update priorities for all the high-priority items in the Work Items List, to make sure
+ that an important Work Item is not missed that would otherwise fall just below the list of what can be taken on in this
+ iteration.
+</p>
+<p>
+ Pick the top-priority Work Item and see if it matches the objectives of the iteration. If it does, assess whether the
+ Work Item is too big to take on within an iteration. If it is too big, break it down into smaller Work Items. Once the
+ Work Item has been decomposed, the team determines whether to take on one or several child Work Items.
+</p>
+<p>
+ <em>Example: The team would like to take on Work Item “Develop Use Case A”, but it would take roughly 300 hours to
+ develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,
+ allowing them to take on other high-priority Work Items. They divide the Work Item into 5 smaller work items
+ representing different scenarios of use case A. The team decides to take on one out of the 5 identified scenarios in
+ this iteration.</em>
+</p>
+<p>
+ When a team has decided to take on a Work Item, it will assign the work to one or several team members. Ideally, this
+ is done by team members signing up to do the work, since this makes people motivated and committed to doing the job,
+ but based on culture, you may instead have the project manager assign the work.
+</p>
+<p>
+ The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
+ want to have each work assignment to be no more than 2 days of work. If the Work Item is too big, consider breaking it
+ down into smaller Work Items.
+</p>
+<p>
+ The team sums up the actual estimate for each Work Item they have committed to, and checks if they can commit to any
+ more work.
+</p>
+<p>
+ <em>Example: Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he
+ decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:</em>
+</p>
+<ul>
+ <li>
+ <em>Detail the requirements (Jack) —5 hours</em>
+ </li>
+ <li>
+ <em>Design the scenario (Jack, Ann, and David) —5 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the dB changes (Ann)—12 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the server portion (David)—16 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the client portion (Jack)—12 hours</em>
+ </li>
+ <li>
+ <em>Total—50 hours</em>
+ </li>
+</ul>
+<p>
+ As Work Items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
+ understand what is involved, and whether other team member may be better suited to take on a subset of the task
+</p>
+<p>
+ The team now determines whether they are willing to take on another Work Item by comparing actual hours signed up for
+ to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence have another
+ 400 hours available
+</p>
+<h3>
+ Define Evaluation Criteria
+</h3>
+<p>
+ It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
+ the iteration. Obvious success criteria should be that you can test the functionality implemented, and that no or few
+ defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
+ meaningful feedback. Test objectives and test cases need to be clearly outlined.
+</p>
+<p>
+ There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
+ favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/layering.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/layering.xmi
new file mode 100644
index 0000000..868e012
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/layering.xmi
@@ -0,0 +1,218 @@
+<?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" epf:version="1.0.0" xmi:id="_lbGQwMM3EdmSIPI87WLu3g" name="layering,_0gpkAMlgEdmt3adZL5Dmdw" guid="_lbGQwMM3EdmSIPI87WLu3g" changeDate="2007-02-26T12:37:43.312+0000" version="1.0.0">
+ <mainDescription><p>
+ Layering logically partitions the subsystems into a number of sets, with certain rules regarding how relationships can
+ be formed between the layers. Layering provides a way to restrict inter-subsystem dependencies, with the result that
+ the system is more loosely coupled and, therefore, more easily maintained.
+</p>
+<p>
+ Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
+ than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
+ requirements. Removing layers is not always as easy and may introduce risks into the project.
+</p>
+<p>
+ The criteria for grouping subsystems follow a few patterns:
+</p>
+<ul>
+ <li>
+ <b>Visibility</b><strong>:</strong> Subsystems may depend only on subsystems in the same layer and the next-lower
+ layer.
+ </li>
+ <li>
+ <b>Volatility</b><strong>:</strong>
+ <ul>
+ <li>
+ <b>In the highest layers</b>, put elements that vary when user requirements change.
+ </li>
+ <li>
+ <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
+ language, operating system, database, and so forth).
+ </li>
+ <li>
+ <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
+ systems and implementation environments.
+ </li>
+ <li>
+ <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
+ model.
+ </li>
+ </ul>
+ </li>
+ <li>
+ <b>Generality</b><strong>:</strong> Abstract model elements tend to be placed lower in the model. If not
+ implementation-specific, they tend to gravitate toward the middle layers.
+ </li>
+ <li>
+ <b>Number of layers.</b> For a small system, three layers are sufficient. For a complex system, five to seven
+ layers are usually sufficient. For any degree of complexity, more than 10 layers should be viewed with suspicion
+ that increases with the number of layers. The table that follows gives you a few guidelines.
+ </li>
+</ul>
+<p align="center">
+ <strong>Guideline for number of layers according to number of classes</strong>
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="58%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th width="40%">
+ <p align="center" scope="col">
+ <b>Number of Classes</b>
+ </p>
+ </th>
+ <th width="60%">
+ <p align="center" scope="col">
+ <b>Number of Layers</b>
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 0 - 10
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ No layering needed
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 10 - 50
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 2 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 25 - 150
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 3 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 100 - 1000
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 4 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<p>
+ Failure to restrict dependencies according to Visibility criteria mentioned above can cause architectural degradation
+ and make the system difficult to extend and maintain.
+</p>
+<p>
+ Exceptions include cases where subsystems need direct access to lower-layer services. Make a decision about how to
+ handle primitive services that are needed throughout the system, such as printing, sending messages, and so forth.
+ There is little value in restricting messages to lower layers if the solution is to effectively implement call
+ pass-throughs in the intermediate layers.
+</p>
+<h4>
+ <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
+</h4>
+<p>
+ Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
+ partitioning present different issues to consider:
+</p>
+<p>
+ <b>User organization</b><strong>:</strong> Subsystems may be organized along lines that mirror the organization of
+ functionality in the business organization (partitioning occurs along departmental lines). This partitioning often
+ occurs early in the design because an existing enterprise model that is strongly partitioned according to the structure
+ of the organization. This pattern usually affects only the top few layers of application-specific services and often
+ disappears as the design evolves.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning along user-organization lines can be a good starting point for the model.
+ </p>
+ </li>
+ <li>
+ <p>
+ The structure of the user organization is not stable over a long period of time because business
+ reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
+ organization of the system should enable the system to evolve and be maintained independently of the
+ organization of the business that it supports.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Areas of competence and skills:</b> Subsystems may be organized to partition responsibilities for parts of the model
+ among different groups within the development organization. Typically, this occurs in the middle and lower layers of
+ the system, and reflects the need for specialization in skills during the development and support of an infrastructure
+ based on complex technology. Examples of such technologies include network and distribution management, database
+ management, communication management, and process control, among others. Partitioning along competence lines may also
+ occur in upper layers, where special competency in the problem domain is required to understand and support key
+ business functionality. Examples include telecommunication call management, securities trading, insurance claims
+ processing, and air traffic control, to name a few.
+</p>
+<p>
+ <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
+ so to speak, to reflect the distribution of functionality.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning to reflect distribution of functionality can help you visualize the network communication that
+ will occur as the system runs.
+ </p>
+ </li>
+ <li>
+ <p>
+ Partitioning to reflect distribution can also, however, make the system more difficult to change if the
+ deployment model changes significantly.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
+ develop or support, require additional partitioning according to security access privileges. Software that controls
+ access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
+ people with this background on the project is limited, the functionality requiring special clearance must be
+ partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
+ secrecy areas the only visible aspect of these subsystems.
+</p>
+<p>
+ <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
+ the system, should be organized into independent subsystems that are developed and delivered independently from the
+ mandatory functionality of the system.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/maintaining_automated_test_suite.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/maintaining_automated_test_suite.xmi
new file mode 100644
index 0000000..b8a19e1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/maintaining_automated_test_suite.xmi
@@ -0,0 +1,104 @@
+<?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" epf:version="1.0.0" xmi:id="_8ngBgMPdEdmbOvqy4O0adg" name="maintaining_automated_test_suite,_0kF5kMlgEdmt3adZL5Dmdw" guid="_8ngBgMPdEdmbOvqy4O0adg" changeDate="2006-09-26T11:31:15.615-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ At some point in your test effort, you may find it necessary to manage your test effort by creating test suites for
+ your test assets.&nbsp;Maintaining test suites can take many different forms. To facilitate your testing, you may want
+ to introduce some&nbsp;level of&nbsp;automation of your test suites.&nbsp;The fact that you've automated your test
+ suites does not necessarily make your testing easier however. It may actually increase the maintenance burden of your
+ suites.
+</p>
+<p>
+ This guideline introduces you to useful heuristics on how to facilitate the maintenance of your automated test suites.
+</p>
+<h4>
+ Plan your test&nbsp;suites
+</h4>
+<p>
+ Automating your testing without planning increases&nbsp;the chances that testing will be ineffective
+ and&nbsp;inefficient.&nbsp;Some level of planning should take place whether implicit or explicit.&nbsp;An essential
+ part of any test plan is the definition of a strategy for test automation.&nbsp;Use your plan to articulate to the
+ development team how you plan to maintain your test assets.&nbsp;In many cases, this is never done.&nbsp;The rest of
+ the development team may be unaware of how you intend to maintain your tests.&nbsp;It is also a good practice to get
+ the rest of the development team to understand that this maintenance can be a substantial part of the overall
+ development effort.&nbsp;Use your test tooling to capture this information and treat this plan just like you would
+ treat any other test asset in your test repository.
+</p>
+<h4>
+ Centrally locate your test assets
+</h4>
+<p>
+ To facilitate the maintenance of your automated test suites, locate your test assets in a repository that can be
+ accessed by the development team.&nbsp;Many test automation environments provide test management tools that make it
+ easier to organize and access your test assets by maintaining the test assets (test cases, test scripts, and test
+ suites) in a common repository.
+</p>
+<p>
+ In addition, some form of access control is enforced by the automation test tool.&nbsp;This eases the maintenance
+ burden by ensuring the integrity of your test suites.&nbsp;You may choose to grant stakeholders and managers read-only
+ access, whereas developers and testers at the practitioner level may have read/write access.
+</p>
+<h4>
+ Treat your test assets like any other software
+</h4>
+<p>
+ Software must be maintained.&nbsp;This also applies to the software in your test suites.&nbsp;Test cases and their
+ associated test scripts, whether recorded or programmed, should be maintained.&nbsp;And just as software has different
+ kinds of maintenance (e.g., corrective, preventative, or adaptive) so too do the assets in your automated test suites.
+ As you lifecycle your test suites, identify, if only informally,&nbsp;how&nbsp;you plan to disposition the test suite
+ corrective maintenance (e.g., syntactical errors in your scripts),&nbsp;preventative maintenance (e.g., where possible
+ to write generalized test scripts), and adaptive maintenance (e.g., how you&nbsp;can use your test tooling to re-assign
+ test&nbsp;assets within one suite to&nbsp;another suite or suites).&nbsp;This can be captured, as described in the
+ section <strong>Plan Your Test Suites</strong> above, in your test plan.
+</p>
+<h4>
+ Improve the testability of your test suites through collaboration with developers
+</h4>
+<p>
+ It's one thing to say that your test suites will need to be maintained due to changes in the application, changes in
+ the testing target, etc.&nbsp;It's quite another thing to actually determine whether a test suite needs to be
+ revamped&nbsp;and, if it does, what test assets within it need to be addressed.
+</p>
+<p>
+ One way to facilitate this is to use test suites as a way to communicate test decision to the developers.&nbsp;One way
+ to perform continuous perfective maintenance of test suites is to think of your test suites as assets that belong to
+ the development team rather than just the testers.&nbsp; You can perform a kind of perfective maintenance on test in
+ the following ways:
+</p>
+<ul>
+ <li>
+ use test suites to raise the level of abstraction
+ </li>
+ <li>
+ use test suites to provide focus for the developer
+ </li>
+ <li>
+ use test suites to articulate areas that the developers would like testers to focus on
+ </li>
+ <li>
+ make the construction and maintenance&nbsp;of test suites more efficient&nbsp;by understanding what area(s)
+ developers want to focus on
+ </li>
+ <li>
+ use test suites to clarify test targets with developers
+ </li>
+</ul>
+<h4>
+ Don't be afraid to clean up your suites
+</h4>
+<p>
+ Your test assets will evolve just as the application under test will.&nbsp;As requirements to the system change, the
+ application will change as well.&nbsp;To maintain your test suites, you should continually&nbsp;check whether test
+ assets are valid.&nbsp;If possible, validity checks should be performed after each new release of the software,
+ preferably more frequently.&nbsp;Keeping your test suites relevant is a full-time job.&nbsp;Assume that changes in the
+ software will lead to some degree of invalid tests within your test suites.&nbsp;Once these test assets have been
+ identified as invalid, get rid of them.&nbsp;This will make the maintenance burden much more tolerable.&nbsp;Some
+ automated test tooling environments make this task easier by providing ways to package outdated or invalid
+ tests.&nbsp;In some cases, you may not be absolutely sure whether you want to completely get rid of tests within your
+ test suite or even of getting rid of test suites altogether.&nbsp; To alleviate this burden, you can create packages
+ for obsolete tests or test suites and dispose of tests or test suites by putting them in packages labeled for this
+ purpose.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_and_openup_basic.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_and_openup_basic.xmi
new file mode 100644
index 0000000..b6fdfa3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_and_openup_basic.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-KCSbXYv5TALlL00zMMfgVw" name=",_v2l6gK_5EduMeuOwJ2MpeQ" guid="-KCSbXYv5TALlL00zMMfgVw">
+ <mainDescription><p>
+ What's the difference between OpenUP and OpenUP/Basic?
+</p>
+<p>
+ How does OpenUP relate to EPF?
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_architecture.xmi
new file mode 100644
index 0000000..b75d233
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_architecture.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-clUV9n59dDwg0e1VCcsB8Q" name=",_REqtUMEvEduwZvIr61GnNg" guid="-clUV9n59dDwg0e1VCcsB8Q" changeDate="2007-02-20T14:13:25.950-0800">
+ <mainDescription><p>
+ Describe how Elaboration deals with architecture (link to existing content).
+</p>
+<p>
+ The architecture artifacts are the work products that provide the most benefit in development in terms of understanding
+ and extending the system.
+</p>
+<p>
+ Explain how architecture reduces technical risk and the importance of doing so.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_iterations.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_iterations.xmi
new file mode 100644
index 0000000..eda90a9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_iterations.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-Mobjz86dw07NW5-IhtEoNA" name=",_U3VjIMEuEduwZvIr61GnNg" guid="-Mobjz86dw07NW5-IhtEoNA" changeDate="2007-02-20T14:09:51.021-0800">
+ <mainDescription>Describe the&nbsp;milestone of each phase (link to existing content). Explain that iterations are not homogeneous, but they
+all deliver stakeholder value. explain that that the focus on reducing risk and understanding the architecture in I &amp; E
+make C &amp; T more predictable.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_risk.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_risk.xmi
new file mode 100644
index 0000000..e11b673
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/openup_risk.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-_BjYXvrfe1HHL5Y_QBfh4Q" name=",_G08UgMEwEduwZvIr61GnNg" guid="-_BjYXvrfe1HHL5Y_QBfh4Q" changeDate="2007-02-20T14:22:16.653-0800">
+ <mainDescription><p>
+ Define risk (reference existing content).
+</p>
+<p>
+ Explain how addressing risk in early iterations reduces the uncertainty and unpredictabiliy in future iterations.
+ Describe the effect that identifying, tracking, and mitigating risk has on a project (better decisions, high comfort
+ level, more visibility into problems).
+</p>
+<p>
+ Reference definitions for risk and risk mitigation.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/programming_automated_tests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/programming_automated_tests.xmi
new file mode 100644
index 0000000..bbe0ae0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/programming_automated_tests.xmi
@@ -0,0 +1,73 @@
+<?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" epf:version="1.0.0" xmi:id="_vuwC4MPcEdmbOvqy4O0adg" name="programming_automated_tests,_0j5sUMlgEdmt3adZL5Dmdw" guid="_vuwC4MPcEdmbOvqy4O0adg" changeDate="2006-12-07T16:06:38.445-0500" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Although the programming of automated tests should contribute to the overall test effort, it usually does not make up
+ the entire test effort. In fact, test environments that are based on a complete automation approach end up spending
+ more time on test automation than on testing. Before you begin developing automated test scripts, consider first
+ whether it is more efficient to perform manual testing. Some aspects of an application are more efficiently tested
+ manually (for example, GUI testing versus data-drive testing). If you decide to program automated test scripts, examine
+ what aspects of your test scripting can be automated and begin designing your scripts.
+</p>
+<h3>
+ Design your automated tests
+</h3>
+<p>
+ Without some level of design of your automated tests, introducing automation into your testing effort can lead to more
+ problems than it solves. You should consider developing your automated tests according to a lifecycle with automation
+ test requirements, design, testing of the automation tests, and implementation of the automation tests. This approach
+ can be informal or formal depending on your project needs. By designing the programming of your automated tests, you
+ can avoid spending time programming the wrong tests, re-working programmed tests, deciphering different coding styles
+ in the programming of the tests, etc.
+</p>
+<h3>
+ Recorded versus programmed scripts
+</h3>
+<p>
+ Although there are clear benefits to recorded scripts (for example, ease of creation or ability for novice testers to
+ learn a scripting language), recorded scripts also present their own problems. The disadvantages of playback scripts
+ are well known. They are deceptively easy to create but very difficult to update. Problems with script reliability,
+ hard-coded data values, or changes to the application under test and the need to re-record are well-documented. On the
+ other hand, programming scripts can present difficulties of their own: they are difficult for the novice tester to
+ create, they can require substantial time and effort to develop, and they can be difficult to debug. Most test tooling
+ makes these issues less problematic by providing the tester script support functions, such as ways to establish target
+ of test lists, systematic ways to program verification point, point to datapools, build commands into the script (for
+ example, sleeper commands), comment the script, and document the script. Another major advantage, which is often
+ overlooked, of using testing tooling to mitigate these risks is the ability to add to an existing script in the form of
+ making corrections to an existing script, testing new features of a test target or application under test, or resuming
+ a recording after an interruption.
+</p>
+<h3>
+ Functional and performance test scripts
+</h3>
+<p>
+ When discussing automating test scripts, it is important to distinguish between functional and performance tests. Most
+ discussions of programming automated test scripts focus on testing the functionality of an application. This is not
+ inappropriate, since a lot of automated testing focuses on functional testing. Performance test scripting, however, has
+ its unique characteristics. Performance test automation provides you with the ability to programmatically set workloads
+ by adding user groups to test loads under group usage, setting think time behavior, running tests randomly or at set
+ rates, or setting the duration of a run. Performance test automation also allows you to create and maintain schedules
+ for your tests.
+</p>
+<h3>
+ Testing test scripts
+</h3>
+<p>
+ When testing your test scripts, keep in mind whether you are testing recorded or programmed test scripts. For recorded
+ scripts, much of the debugging of the script consists of errors that are introduced due to changes in the test target
+ or test environment. When you run a recorded test script, consider the test target of the script. Some test automation
+ tools capture this information as a part of the test script. Debugging a recorded script consists largely of
+ determining whether changes in the target have created error conditions in the script. In general, there are two main
+ categories to examine here: changes in the UI and test session sensitive data (for example, date stamped data). In most
+ cases, discrepancies between recording and playback cause errors in your recorded test scripts.
+</p>
+<p>
+ Testing programmed test scripts involves many of the same debugging techniques you would apply to debugging an
+ application. Consider both the flow control logic and the data aspects of your script. Automated testing tools provide
+ you with test script debugging IDEs as well as datapool management features that facilitate this type of testing.
+ During execution of test scripts, a test that uses a datapool can replace values in the programmed test with variable
+ test data that is stored in the datapool.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/promoting_builds.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/promoting_builds.xmi
new file mode 100644
index 0000000..6cfe19b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/promoting_builds.xmi
@@ -0,0 +1,87 @@
+<?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" epf:version="1.0.0" xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ" name="promoting_builds,_SM4YIL6dEdqti4GwqTkbsQ" guid="-zCM2ucJJxc_bQr_LoHlSaQ" changeDate="2007-02-26T13:49:04.018-0500" version="1.0.0">
+ <mainDescription><p>
+ During iterative software development the team will create numerous <a class="elementLink"
+ href="./../../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>s. A build is initiated by combining the work completed by one or more
+ developers and resolving any conflicts that are encountered. Ideally a build is then subjected to a battery of tests to
+ determine if it is of sufficient quality to move into production.
+</p>
+<p>
+ As a build progresses from development towards production it is beneficial to know two characteristics:
+</p>
+<p>
+ <strong>Build contents</strong> – identifying the elements and their versions
+</p>
+<ul>
+ <li>
+ What is in this build (completed work items)
+ </li>
+ <li>
+ What is partially in this build (work items that are partially complete)
+ </li>
+ <li>
+ What is not in this build (work items that are not reflected at all in this build)
+ </li>
+</ul>
+<p>
+ <strong>Verification Level</strong> – identifying what amount of testing that has been completed.&nbsp; For example,
+</p>
+<ul>
+ <li>
+ Unit Tested
+ </li>
+ <li>
+ Integration Tested
+ </li>
+ <li>
+ System Tested
+ </li>
+</ul>
+<p>
+ The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
+ the following steps:
+</p>
+<ul>
+ <li>
+ Changes are introduced into the system in the form of completed work items
+ </li>
+ <li>
+ A build is generated clearly identifying the&nbsp;changes
+ </li>
+ <li>
+ Testing is conducted
+ </li>
+ <li>
+ When testing is successful the changes are delivered to the next&nbsp;verification level
+ </li>
+</ul>
+<p>
+ Ultimately all required testing is complete and the a new system version is ready.
+</p>
+<p>
+ It can also be beneficial to isolate work being performed at the different stages using different <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/workspace,_0cEmAMlgEdmt3adZL5Dmdw.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>s. This ensures that the effort of testing a build is applied to the
+ correct version and also allows developers to continue working on the next build while the previous build is being
+ tested.
+</p>
+<p>
+ A promotional lifecycle such as this offers three key benefits
+</p>
+<ol>
+ <li>
+ Reduces effort because there is no reason to execute the tests in the next stages until the build passes the
+ previous stage. For example you would not commit the resources to&nbsp;System Testing&nbsp;a build until it passes
+ integration tests.
+ </li>
+ <li>
+ Helps to ensure that a build which is moved into production has been subjected to the appropriate level of testing
+ first.
+ </li>
+ <li>
+ Simplifies debugging since developers can base their work on a proven build (Integration Tested build, for example)
+ in relative isolation from destabilizing changes from other developers
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
new file mode 100644
index 0000000..a7ff527
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
@@ -0,0 +1,43 @@
+<?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" epf:version="1.0.0" xmi:id="_iCwb8MM3EdmSIPI87WLu3g" name="repres_interfaces_to_ext_systems,_0gjdYMlgEdmt3adZL5Dmdw" guid="_iCwb8MM3EdmSIPI87WLu3g" changeDate="2007-02-26T12:05:55.921+0000" version="1.0.0">
+ <mainDescription><p>
+ Interfaces with external systems should be consistently handled throughout the system, so markers need to be identified
+ in the architecture to make sure that the team develop the coherant software. The architecture need not include a
+ specific, detailed design for each system interface. It is often enough to simply identify the existence of the
+ interfacre as a significant part of the architecture and create a subsystem to encapsulate the detail, so that it can
+ be developed later.
+</p>
+<p>
+ The <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides the basis for a useful technique to
+ support this.
+</p>
+<p>
+ If the system communicates with another system, define one or more boundary classes to describe the communication
+ protocol. An external system may be anything from software to hardware units that the current system will use, such as
+ printers, terminals, alarm devices, and sensors. In each case, a boundary class that mediates the communication with
+ the external system will be identified.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ An automated teller machine (ATM) must communicate with the ATM network to ascertain whether a customer's bank
+ number and PIN are correct, and whether the customer has sufficient funds to withdrawal the requested amount. The
+ ATM network is an external system (from the perspective of the ATM); therefore, you would use a
+ <strong>boundary</strong> class to represent it in a use-case analysis.
+ </p>
+</blockquote>
+<p>
+ If the interfaces with the system are simple and well-defined, a single class may be sufficient to represent the
+ external system. Often, however, these interfaces are too complex to be represented by using a single class; they often
+ require complex collaborations of many classes. Moreover, interfaces between systems are often highly reusable across
+ applications. As a result, in many cases, a subsystem models the system interfaces more appropriately.
+</p>
+<p>
+ The use of a subsystem allows the interface to the external system to be defined and stabilized, while leaving the
+ design details of the system interface hidden as the system evolves.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/req_gathering_techniques.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/req_gathering_techniques.xmi
new file mode 100644
index 0000000..fc6ae21
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/req_gathering_techniques.xmi
@@ -0,0 +1,347 @@
+<?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" epf:version="1.0.0" xmi:id="_On0agNSAEdmLhZ9H5Plxyw" name="req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw" guid="_On0agNSAEdmLhZ9H5Plxyw" changeDate="2006-09-22T10:27:44.597-0400">
+ <mainDescription><h3>
+ Sources of Requirements
+</h3>
+<p>
+ Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one
+ that&nbsp;takes few&nbsp;resources. Examples of sources of requirements include:
+</p>
+<ul>
+ <li>
+ Customers
+ </li>
+ <li>
+ Users
+ </li>
+ <li>
+ Administrators and maintenance&nbsp;staff
+ </li>
+ <li>
+ Partners
+ </li>
+ <li>
+ Domain Experts
+ </li>
+ <li>
+ Industry Analysts
+ </li>
+ <li>
+ Information about competitors&nbsp;
+ </li>
+</ul>
+<h3>
+ Requirements Gathering Techniques
+</h3>
+<p>
+ After you have identified these sources, there are a number of techniques that may be used to gather requirements. The
+ following will describe the various techniques, followed by a brief discussion of when to use each technique.
+</p>
+<p>
+ To get the requirements down on paper, you&nbsp;can to do one or more of the following:
+</p>
+<ul>
+ <li>
+ Conduct a brainstorming session
+ </li>
+ <li>
+ Interview users
+ </li>
+ <li>
+ Send questionnaires
+ </li>
+ <li>
+ Work in the target environment
+ </li>
+ <li>
+ Study analogous systems
+ </li>
+ <li>
+ Examine suggestions and problem reports
+ </li>
+ <li>
+ Talk to support teams
+ </li>
+ <li>
+ Study improvements made by users
+ </li>
+ <li>
+ Look at unintended uses
+ </li>
+ <li>
+ Conduct workshops
+ </li>
+ <li>
+ Demonstrate prototypes to stakeholders
+ </li>
+</ul>
+<p>
+ The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put
+ in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best
+ structure you can devise, but expect to keep on correcting it throughout the process.&nbsp; Success tips: Do it now,
+ keep it small, and correct it immediately.
+</p>
+<h4>
+ Conduct a brainstorming session
+</h4>
+<p>
+ Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of
+ discussion. After that, a facilitator leads the group in organizing and prioritizing the results.&nbsp; The following
+ basic rules for brainstorming&nbsp;ensures better results:
+</p>
+<ul>
+ <li>
+ Start out by clearly stating the objective of the brainstorming session.
+ </li>
+ <li>
+ Generate as may ideas as possible.
+ </li>
+ <li>
+ Let your imagination soar.
+ </li>
+ <li>
+ Do not allow criticism or debate while you are gathering information.
+ </li>
+ <li>
+ Once information is gathered,&nbsp;reshape and combine ideas.
+ </li>
+</ul>
+<h4>
+ Interview users
+</h4>
+<p>
+ Face-to-face contact with users through individual interviewing is the primary source of requirements and an important
+ way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can
+ conduct interviews many different ways. Develop a repertoire of styles to&nbsp;fit different situations. Unless you use
+ the system yourself, you will need to make an effort to understand and experience the user's problem to describe it
+ clearly and correctly.
+</p>
+<h4>
+ Send Questionnaires
+</h4>
+<p>
+ If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering
+ the problem behind the problem. Sometimes, though,&nbsp;face-to-face meetings with stakeholders are not feasible (when
+ developing products for the consumer market, for example). In those situations, consider using questionnaires.&nbsp;
+ Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to
+ complete it and return it to you.&nbsp; Success&nbsp;tips: Keep it short and given them a deadline.&nbsp;
+</p>
+<p>
+ This technique has the advantage of providing a lot of information for statistical analysis. However, the questions
+ must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.&nbsp;
+</p>
+<h4>
+ Work in the target environment
+</h4>
+<p>
+ Experience the work of the users for yourself. Working with users helps you understand problems that have resisted
+ previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as
+ interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the
+ desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other
+ areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just
+ sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they
+ would like to have to make the work easier.
+</p>
+<h4>
+ Study analogous systems
+</h4>
+<p>
+ The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and
+ systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the
+ wheel by looking at systems already on the market, whether they are systems installed at the user's site or products
+ made by rival organizations. Even if they are trying to solve slightly different problems, they often&nbsp;provide
+ valuable clues as to what you need to do.
+</p>
+<p>
+ Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these
+ suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements
+ directly this way. If not, capture and store suggestions for future use.
+</p>
+<p>
+ You can describe to users selected features of other products. Explain that the system is designed for&nbsp;another
+ purpose&nbsp;but contains an interesting feature, and you wonder it or something similar&nbsp;would help them.
+ Sometimes these systems are described in documents, such as a contract from another organization or a report written
+ for management. Often, these documents were never intended as formal requirements, and were written merely to
+ communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
+</p>
+<p>
+ Such a process might involve the following activities:
+</p>
+<ul>
+ <li>
+ Read the document from end to end (several times) to comprehend what the customer wants and what actually has been
+ written.
+ </li>
+ <li>
+ Classify all of the types of information in the document. (user, system requirements, design elements, plans,
+ background material, irrelevant detail)
+ </li>
+ <li>
+ Mark up the original text to separate out such requirements.
+ </li>
+ <li>
+ Find a good structure for each of the different types of information such as: a scenario for the user requirements,
+ functional breakdown for the system requirements, and architecture for the design.
+ </li>
+ <li>
+ Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions
+ with the users.
+ </li>
+ <li>
+ Create traceability links between these information elements to show the designers exactly what the users want.
+ </li>
+ <li>
+ Convince the customer to accept the new information as the basis for the contract.
+ </li>
+</ul>
+<h4>
+ Examine suggestions and problem reports
+</h4>
+<p>
+ Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at
+ suggestions and problems as first described. Most organizations have a form for reporting system problems or software
+ defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can
+ identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users'
+ actual needs.
+</p>
+<h4>
+ Talk to support teams
+</h4>
+<p>
+ Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do
+ the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff
+ and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training
+ team and installation teams about what users find to be&nbsp;difficult.
+</p>
+<h4>
+ Study improvements made by users
+</h4>
+<p>
+ This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or
+ related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why
+ did you add that? Their answers help you&nbsp;get to the heart of the actual requirement. This applies also to hardware
+ and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents
+ movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product,
+ which makes it&nbsp;a valid&nbsp;requirement for the new version.
+</p>
+<h4>
+ Look at unintended uses
+</h4>
+<p>
+ People often use things for purposes for which they were not designed.&nbsp; This is&nbsp;a good way to get new ideas
+ and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the
+ office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive
+ commercial products are now widely available for home use.
+</p>
+<h4>
+ Conduct workshops
+</h4>
+<p>
+ Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of
+ requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each
+ requirement, the document becomes much more useful and cost-effective.
+</p>
+<p>
+ Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You
+ are bringing the right collection of people together, and getting them to correct and improve on their requirements
+ document.
+</p>
+<p>
+ A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If
+ you can define the product right the first time and cut three months off the requirements gathering, the savings could
+ be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
+</p>
+<p>
+ Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should
+ be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that
+ people don't go home at night or go out separately. The example&nbsp;in Figure 1&nbsp;shows the logic of a requirements
+ workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques
+ such as brainstorming.
+</p>
+<p>
+ <img height="381" alt="" src="./resources/Workshop%20Activity%20Diagram.GIF" width="542" />
+</p>
+<p>
+ <strong>Figure 1: Conducting Workshops</strong>
+</p>
+<h4>
+ Demonstrate prototypes to stakeholders
+</h4>
+<p>
+ Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can
+ provoke&nbsp;them into giving good requirements information or changing their mind about existing requirements. The
+ techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of
+ presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might
+ be able to do. More requirements are likely to emerge when users see what you are suggesting.
+</p>
+<p>
+ A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a
+ vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that
+ there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here
+ for the unwary).
+</p>
+<p>
+ This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or
+ product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and
+ right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems
+ with the prototype! This is excellent,&nbsp;because each problem leads to a new requirement.
+</p>
+<h3>
+ Which Technique to Apply?
+</h3>
+<p>
+ Which technique to apply depends on a number of factors, such as:
+</p>
+<ul>
+ <li>
+ Availability and location of stakeholders
+ </li>
+ <li>
+ Development team knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the development process and methods
+ </li>
+</ul>
+<p>
+ If the stakeholders are not co-located or readily available, for example in the case of a product being developed for
+ mass market,&nbsp;techniques such as brainstorming, interviews and workshops that require face-to-face contact with the
+ stakeholders may be difficult or impossible.
+</p>
+<p>
+ If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the
+ techniques described, or combination of them, may be applied. In this case, the domain and development experience of
+ oth the stakeholders and the development team are critical factors in selecting the appropriate technique.
+</p>
+<p>
+ Figure 2, adapted from <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>, provides a framework for determining the appropriate techniques. It
+ defines four main categories of customer or user experience and development team experience: "Fuzzy problem",
+ "Selling/Teaching", "Catch up", and "Mature".
+</p>
+<p>
+ <img height="470" alt="" src="./resources/Which%20Req%20Gathering%20Technique.gif" width="514" />
+</p>
+<p>
+ <strong>Figure 2: Selection of Techniques</strong>
+</p>
+<p>
+ There is no "right answer", but these guidelines may help you decide which method to use:
+</p>
+<ul>
+ <li>
+ Catch-up: Interviews, work in target environment
+ </li>
+ <li>
+ Fuzzy: Brainstorming, workshops
+ </li>
+ <li>
+ Mature: Questionnaires, workshops, prototypes
+ </li>
+ <li>
+ Selling/Teaching: prototypes
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/requirement_pitfalls.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/requirement_pitfalls.xmi
new file mode 100644
index 0000000..8930001
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/requirement_pitfalls.xmi
@@ -0,0 +1,250 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-Q72-dNdHnZ93aRXAB_d34A" name="requirement_pitfalls_1,_1AOsMO0JEdqHTdbLTmC5IQ" guid="-Q72-dNdHnZ93aRXAB_d34A" authors="Chris Sibbald" changeDate="2006-09-27T10:14:43.487-0700" version="0.2">
+ <mainDescription><p>
+ Explanations and examples follow for each of the following common pitfalls to avoid, in defining and writing
+ requirements (for more information, see <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>):
+</p>
+<ul>
+ <li>
+ Avoid ambiguity.
+ </li>
+ <li>
+ Don't make multiple requirements.
+ </li>
+ <li>
+ Never use let-out or escape words.
+ </li>
+ <li>
+ Don't ramble.
+ </li>
+ <li>
+ Resist designing the system.
+ </li>
+ <li>
+ Avoid mixing different kinds of requirements.
+ </li>
+ <li>
+ Do not speculate.
+ </li>
+ <li>
+ Do not use vague, undefined terms.
+ </li>
+ <li>
+ Do not express possibilities.
+ </li>
+ <li>
+ Avoid wishful thinking.
+ </li>
+</ul>
+<h4>
+ Avoid ambiguity
+</h4>
+<p>
+ Avoidance of ambiguity is one of the subtlest and most difficult issues in writing requirements. Try to write as
+ clearly and explicitly as possible. Be specific. Remember, though, that if you carry this too far, the text becomes
+ dull and unreadable, which makes it difficult for other people to review. Although this guideline emphasizes
+ structured, written expression of requirements, informal text, diagrams, conversations, and phone calls are excellent
+ ways of removing ambiguity.
+</p>
+<p>
+ Some constructions (such as the use of or and unless in requirements) allow different groups of readers to understand
+ different things from the same wording. Developers could use this technique deliberately, so as to postpone, until too
+ late, any possibility of the customer's asking for what was truly wanted. This is dangerous and could easily backfire.
+</p>
+<p>
+ The only approach that works is for developers to make requirements as clear as possible, and for all stakeholders to
+ co-operate. In the long run, project success is in everybody's interest.
+</p>
+<p>
+ Dangerous ambiguities can be caused by the word <strong>or</strong> and also by many more-subtle errors.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The same subsystem shall also be able to generate a visible or audible caution/warning signal for the attention of
+ the co-pilot or navigator.</em>
+</p>
+<p>
+ Which subsystem? Is the signal to be visible, audible, or both? Is it both caution and warning, just caution, or just
+ warning? Is it for both the co-pilot and the navigator, or just one of them? If just one of them, which one and under
+ what conditions?
+</p>
+<h4>
+ Don't make multiple requirements
+</h4>
+<p>
+ Requirements which contain conjunctions (words that join independent clauses together) are dangerous. Problems arise
+ when readers try to figure out which part applies, especially if the different clauses seem to conflict, or if the
+ individual parts apply separately. Multiple requirements also make verification more complex.
+</p>
+<p>
+ Dangerous conjunctions include: and, or, but
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or
+ input data shall be saved.</em>
+</p>
+<p>
+ Should the battery low warning lamp light up when the voltage drops and the workspace is saved? Should the battery low
+ warning lamp light up and the workspace be saved when the voltage drops?
+</p>
+<h4>
+ Never use let-out or escape words
+</h4>
+<p>
+ Requirements that include options or exceptions are dangerous. They seem to ask for something definite, but at the last
+ moment they back down and allow for other options. Problems arise when the requirements are to be tested, and someone
+ has to decide what (if anything) could prove the requirement was met.
+</p>
+<p>
+ Dangerous words that imply exceptions include: if, when, but, except, unless, although.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is
+ deployed.</em>
+</p>
+<p>
+ <em>The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has
+ suppressed the alarm.</em>
+</p>
+<p>
+ The latter sentence is a truly dangerous requirement!
+</p>
+<h4>
+ Don't ramble
+</h4>
+<p>
+ Long rambling sentences, especially when combined with arcane language, references to unreachable documents, and other
+ defects of writing, quickly lead to confusion and error.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Provided that the designated input signals from the specified devices are received in the correct order where the
+ system is able to differentiate the designators, the output signal shall comply with the required framework of section
+ 3.1.5 to indicate the desired input state.</em>
+</p>
+<h4>
+ Resist designing the system
+</h4>
+<p>
+ Requirements should specify the design envelope without unnecessary constraints on a specific design. If we supply too
+ much detail we start to design the system. Going too far is tempting for designers, especially when they come to their
+ favorite bits.
+</p>
+<p>
+ Danger signs include names of components, materials, software objects/procedures, and database fields.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof
+ hardened rubber shield.</em>
+</p>
+<p>
+ Specifying design rather than actual need increases the cost of systems by placing needless constraints on development
+ and manufacture. Often knowing why is much better than knowing what.
+</p>
+<h4>
+ Avoid mixing different kinds of requirements
+</h4>
+<p>
+ The user requirements form a complete model of what users want. They need to be organized coherently to show gaps and
+ overlaps. The same applies to system requirements, which form a complete functional model of the proposed system. A
+ quick road to confusion is to mix up requirements for users, systems, and how the system should be designed, tested, or
+ installed.
+</p>
+<p>
+ Danger signs are any references to system, design, testing, or installation.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The user shall be able to view the currently selected channel number which shall be displayed in 14pt Swiss type on
+ an LCD panel tested to Federal Regulation Standard 567-89 and mounted with shockproof rubber washers.</em>
+</p>
+<h4>
+ Do not speculate
+</h4>
+<p>
+ Requirements are part of a contract between customer and developer. There is no room for wish lists, meaning general
+ terms about things that somebody probably wants.
+</p>
+<p>
+ Danger signs include vagueness about which type of user is speaking, and generalization such as: usually, generally,
+ often, normally, typically
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Users normally require early indication of intrusion into the system.</em>
+</p>
+<h4>
+ Do not use vague, undefined terms
+</h4>
+<p>
+ Many words used informally to indicate system quality are too vague for use in requirements. Vague terms include, among
+ others: user-friendly, versatile, flexible, approximately, as possible
+</p>
+<p>
+ Requirements using these terms are unverifiable because there is no definite test to show whether the system has the
+ indicated property.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The print dialog shall be versatile and user-friendly.</em>
+</p>
+<p>
+ <em>The OK status indicator lamp shall be illuminated as soon as possible after the system self-check is
+ completed.</em>
+</p>
+<h4>
+ Do not express possibilities
+</h4>
+<p>
+ Suggestions that are not explicitly stated as requirements are invariably ignored by developers.
+</p>
+<p>
+ "Possible options" are indicated with terms such as: may, might, should, ought, could, perhaps, probably
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed
+ building.</em>
+</p>
+<h4>
+ Avoid wishful thinking
+</h4>
+<p>
+ Engineering is a real-world activity. No system or component is perfect. Wishful thinking means asking for the
+ impossible.
+</p>
+<p>
+ Wishful-thinking terms include: reliable, safe, handle all unexpected failures, please all users, run on all platforms,
+ never fail, upgradeable to all future situations
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The gearbox shall be 100% safe in normal operation.</em>
+</p>
+<p>
+ <em>The network shall handle all unexpected errors without crashing.</em>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/4plus1_2.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/4plus1_2.jpg
new file mode 100644
index 0000000..24cfc97
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/4plus1_2.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG
new file mode 100644
index 0000000..903bdea
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/PDMSample.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/PDMSample.JPG
new file mode 100644
index 0000000..5ad1683
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/PDMSample.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG
new file mode 100644
index 0000000..0270965
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG
new file mode 100644
index 0000000..6e965d1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/WBR Fig 1.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/WBR Fig 1.JPG
new file mode 100644
index 0000000..45bf93e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/WBR Fig 1.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/WBR Fig 3.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/WBR Fig 3.JPG
new file mode 100644
index 0000000..b4e8d48
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/WBR Fig 3.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/Which Req Gathering Technique.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/Which Req Gathering Technique.gif
new file mode 100644
index 0000000..10b6366
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/Which Req Gathering Technique.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/Workshop Activity Diagram.GIF b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/Workshop Activity Diagram.GIF
new file mode 100644
index 0000000..228f102
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/Workshop Activity Diagram.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ac_intsy.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ac_intsy.gif
new file mode 100644
index 0000000..b4e468f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ac_intsy.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec1.gif
new file mode 100644
index 0000000..b076e0b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec2.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec2.gif
new file mode 100644
index 0000000..b8b7cd9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec3.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec3.gif
new file mode 100644
index 0000000..bfd2a4b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/co_dmec3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/compass.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/compass.gif
new file mode 100644
index 0000000..39f306a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/compass.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/compassL.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/compassL.gif
new file mode 100644
index 0000000..4117414
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/compassL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/dm_1.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/dm_1.jpg
new file mode 100644
index 0000000..7c443c4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/dm_1.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG
new file mode 100644
index 0000000..ae585d8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/icon_introL.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/icon_introL.gif
new file mode 100644
index 0000000..1826cbd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/icon_introL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc1.gif
new file mode 100644
index 0000000..1c2beb3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc2.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc2.gif
new file mode 100644
index 0000000..717c2b2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc3.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc3.gif
new file mode 100644
index 0000000..06f3a9d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc4.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc4.gif
new file mode 100644
index 0000000..cb79539
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc4.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc5.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc5.gif
new file mode 100644
index 0000000..8559e50
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc5.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc6.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc6.gif
new file mode 100644
index 0000000..13a7b72
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/jdbc6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/login_vopc.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/login_vopc.jpg
new file mode 100644
index 0000000..0d46428
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/login_vopc.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg
new file mode 100644
index 0000000..dafa9b7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd02.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd02.gif
new file mode 100644
index 0000000..7cd32c8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd02.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd03.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd03.gif
new file mode 100644
index 0000000..f7bd16b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd03.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd05.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd05.gif
new file mode 100644
index 0000000..ccd95b4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd05.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd06.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd06.gif
new file mode 100644
index 0000000..7a78158
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd06.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd08.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd08.gif
new file mode 100644
index 0000000..a32d7b5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd08.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd09.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd09.gif
new file mode 100644
index 0000000..cab0b90
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd09.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd10.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd10.gif
new file mode 100644
index 0000000..d637473
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd10.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd11.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd11.gif
new file mode 100644
index 0000000..6e296de
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd11.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd12.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd12.gif
new file mode 100644
index 0000000..88d7fce
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd12.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd13.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd13.gif
new file mode 100644
index 0000000..9ce8e35
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd13.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd14.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd14.gif
new file mode 100644
index 0000000..db36d0c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd14.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd15.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd15.gif
new file mode 100644
index 0000000..33eb769
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd15.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd16.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd16.gif
new file mode 100644
index 0000000..8ca3f5d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd16.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd17.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd17.gif
new file mode 100644
index 0000000..76b321b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd17.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd18.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd18.gif
new file mode 100644
index 0000000..583cc54
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd18.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd19.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd19.gif
new file mode 100644
index 0000000..e7fc0b0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd19.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd20.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd20.gif
new file mode 100644
index 0000000..adc1a9a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd20.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd21.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd21.gif
new file mode 100644
index 0000000..83b2c2c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd21.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd22.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd22.gif
new file mode 100644
index 0000000..91e7c76
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_datamd22.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_ucmo6.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_ucmo6.gif
new file mode 100644
index 0000000..14a7376
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_ucmo6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_ucre3.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_ucre3.gif
new file mode 100644
index 0000000..7f4cf27
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/md_ucre3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/mic.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/mic.gif
new file mode 100644
index 0000000..0b316db
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/mic.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ucmex2.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ucmex2.gif
new file mode 100644
index 0000000..7f71f61
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ucmex2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ucrea1.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ucrea1.gif
new file mode 100644
index 0000000..78190a2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/ucrea1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wg_fish.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wg_fish.gif
new file mode 100644
index 0000000..d2103d6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wg_fish.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wg_paret.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wg_paret.gif
new file mode 100644
index 0000000..8332803
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wg_paret.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wil_overview.bmp b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wil_overview.bmp
new file mode 100644
index 0000000..920106d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/resources/wil_overview.bmp
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/self_organize_work_assignments.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/self_organize_work_assignments.xmi
new file mode 100644
index 0000000..4b8dce2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/self_organize_work_assignments.xmi
@@ -0,0 +1,100 @@
+<?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" epf:version="1.0.0" xmi:id="-e26WOHRbTVQrDssK5zijVA" name="self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA" guid="-e26WOHRbTVQrDssK5zijVA" changeDate="2007-01-05T09:07:49.299-0500" version="1.0.0">
+ <mainDescription><p>
+ A "self organizing team" has the authority to choose the work that it will perform and the responsibility to do that
+ work in the way that it chooses.&nbsp; Important aspects of a self organizing team&nbsp;are:
+</p>
+<ol>
+ <li>
+ The team selects its own work. At the beginning of an iteration the team collectively selects the <a class=""
+ href="./../../../openup_basic/guidances/termdefinitions/work_item,_jyVgcEvKEdunZcj9T5hrMQ.html"
+ guid="_jyVgcEvKEdunZcj9T5hrMQ">work item</a>s from the prioritized <a class=""
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>. Work selection is performed within given constraints, including
+ the priorities set by <a class="" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s, time (such as the length of the current <a class=""
+ href="./../../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html"
+ guid="_lam4ADkBEduxovfWMDsntw">Iteration</a>), the budget, and the skills of team members.
+ </li>
+ <li>
+ Individuals select their own work. Individuals are empowered to select their own work. Someone will choose to do
+ something because they are good at it and know that they can do the work effectively, because they want to gain
+ more experience at something and hope to improve their skill-set by working with someone with such experience, or
+ because they know that the work needs to be done and that it's their turn to do so. Although an individual fulfills
+ one or more roles on a project team that doesn't imply that the person is constrained to only doing specific types
+ of work.
+ </li>
+ <li>
+ The team determines how to perform the work. At the beginning of an iteration the team will hold an "all hands"
+ planning meeting where it determines the general strategy for doing the work and the tasks required to do so. More
+ detailed planning, if required, will be done on a just-in-time (JIT) basis by the individual(s) doing the work.
+ Note that the team is still constrained by your organization's standards, technical infrastructure, regulations,
+ and so on.
+ </li>
+ <li>
+ Everyone commits to the work. The team commits to accomplishing the work that it has agreed to do by the end of the
+ iteration. Individuals also commit to doing the work that they say they will do, although as the iteration
+ progresses various tasks may be renegotiated as required.
+ </li>
+ <li>
+ The team coordinates regularly. To ensure that the work is accomplished the team must coordinate its efforts
+ effectively. This is typically done through daily stand up meetings of the team and impromptu discussions between
+ individuals.
+ </li>
+</ol>
+<p>
+ This is a participatory approach to decision making where everyone has the opportunity to provide input and to listen
+ to the decision making process. The goal is to make decisions at the right place within the organizational structure,
+ empowering teams by giving them both the responsibility and the authority to get the job done. It improves motivation
+ amongst team members, and thereby their productivity, by giving them control over their work.
+</p>
+<h3>
+ Project Manager Responsibilities
+</h3>
+<p>
+ There is still work for the <a href="./../../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> on self organizing teams. The project manager must still:
+</p>
+<ol>
+ <li>
+ Provide leadership. Team culture and project vision must be nurtured and evolved throughout the project, and
+ direction must be provided to the team.
+ </li>
+ <li>
+ Mediate disagreements. The manager must be prepared to step in and make a decision when other team members are
+ unable to come to a decision.
+ </li>
+ <li>
+ Ensure that team members grow their skill-set. From time to time the manager may need to motivate individuals to
+ take on new tasks that are outside their comfort zone or to work with others to help those people gain new skills.
+ </li>
+ <li>
+ Ensure that the team respects their limits. Self organizing teams have the authority to make decisions within the
+ scope of their responsibility, but that doesn't mean that they get to rethink everything that they feel like. For
+ example, the development team must still conform to the technical infrastructure and to the business strategy of
+ your organization: they likely don't have the authority to change these things even though they may not fully agree
+ with them. When an issue falls outside their scope of responsibility the team must either accept it or collaborate
+ with the people with the appropriate authority.
+ </li>
+ <li>
+ Summarize the project plan. External stakeholders, such as senior management or business representatives not
+ actively involved with the team, will want to know the current status of the project and the team's current plans.
+ The project manager may be required to summarize and communicate this information to those people.
+ </li>
+</ol>
+<h3>
+ What This Isn't
+</h3>
+<p>
+ The concept of self organizing teams often sounds like anarchy or non-management to traditional IT professionals, but
+ nothing could be further from the truth. Although self organization relies on team members being responsible and mature
+ it is tempered by the guiding hand of a good project manager. It is also tempered by organizational standards,
+ infrastructure, and external regulations. "Self organizing" doesn't mean that you have complete freedom to do what you
+ want.
+</p>
+<p>
+ Self organization isn't necessarily a consensus-based approach either; sometimes individuals will disagree with a
+ decision but will choose to go along with the will of the team. Nevertheless, consensus isn't ruled out by this
+ approach but it certainly isn't required.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/staffing_project.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/staffing_project.xmi
new file mode 100644
index 0000000..808d03a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/staffing_project.xmi
@@ -0,0 +1,63 @@
+<?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" epf:version="1.0.0" xmi:id="-HYO1lwAFOxlT7ncq8EjSng" name="new_guideline,_Jq64EJjsEduad8I_c-ogIA" guid="-HYO1lwAFOxlT7ncq8EjSng" changeDate="2007-01-31T13:46:21.802-0500" version="1.0.0">
+ <mainDescription><p>
+ Good software development teams are made up of a collection of people who collaborate effectively. How the project team
+ is staffed, by either adding or removing people, will greatly impact the team's productivity.
+</p>
+<p>
+ When staffing a development project, consider the following advice:
+</p>
+<ol>
+ <li>
+ Include people who fit into the existing team culture. Good teams don't just appear magically one day, but instead
+ are grown and nurtured over time. Invite people onto the team who will add value and furthermore who will not be
+ disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
+ team and they don't seem to be able to change.
+ </li>
+ <li>
+ People should want to be on the team. People are far more productive when they're working on a project that they
+ believe in and want to see succeed.
+ </li>
+ <li>
+ Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
+ specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas,
+ including both technical and domain areas. Generalizing specialists add value to the team because they have
+ specialized skills that you need while at the same time appreciate the full range of issues that a general
+ understanding of the software development process and the business domain offers.
+ </li>
+ <li>
+ Include stakeholders. Stakeholders, including business stakeholders such as end users and technical stakeholders
+ such as operations staff, can add significant value to your team. Instead of just interviewing them to gain
+ information from them, or asking them to review your work, why not include them as active participants on the team?
+ </li>
+ <li>
+ Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
+ particularly when they have specific skills and experience which existing team members do not have. It can often be
+ more effective to bring a specialist into the team for a short period of time to help with a specific task, such as
+ installation and setup of an application server, the development of an architectural spike, or simply taking part
+ in a review.
+ </li>
+ <li>
+ Give people opportunities to evolve their skills. At the beginning of a project the team may not have the full
+ range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
+ they are filling. This is a very common risk taken on by the majority of project teams for the simple reasons that
+ you often can't find the perfect combination of people and even if you could you still want to provide people with
+ opportunities to grow as professionals.
+ </li>
+ <li>
+ Remember Brook's Law. Adding people to a late project will only make it later [<a class=""
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BRO95</a>]. The corollary is that removing people from a late project may speed
+ things up [<a class=""
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
+ </li>
+</ol>
+<p>
+ Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
+ are available (although there's nothing stopping a specialist from becoming a generalizing specialist), perhaps there
+ aren't as many opportunities for people to try new things as they would like, or perhaps the stakeholders aren't
+ available to be active members of the team. The advice above is designed to lead to as high-performing a team as
+ possible, but even partial adherence to this guideline will improve the team.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi
new file mode 100644
index 0000000..9c34e29
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi
@@ -0,0 +1,65 @@
+<?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" epf:version="1.0.0" xmi:id="-w7sImtXWkf4HDXdUWjRsUg" name="new_guideline,_fnZj0NVXEdqy9sbRhejO5Q" guid="-w7sImtXWkf4HDXdUWjRsUg" authors="Chris Sibbald" changeDate="2007-02-26T13:52:05.226-0500" changeDescription="Moved content from previous concept:change request to this guideline and updated in accordance with discussion from April 18, 2006 telecon." version="0.2">
+ <mainDescription><h3>
+ Background
+</h3>
+<p>
+ Change requests typically have a lifecycle. They are raised,&nbsp;reviewed, accepted or rejected, implemented, verified
+ and closed. These states define the status of the change request at a particular point in time and represent critical
+ information for tracking progress. Other sets of states are possible.
+</p>
+<p>
+ During review of a change request, the goal&nbsp;is to assess the&nbsp;technical, cost, and schedule impact
+ of&nbsp;implementing the change.&nbsp; The technical impact&nbsp;assessment includes&nbsp;the determination of
+ which&nbsp;work products&nbsp;are affected and an estimate of the level of effort required to change and verify all
+ affected artifacts. This information becomes the basis of the cost and schedule impact assessments and, ultimately,
+ whether the change request will be accepted or rejected.
+</p>
+<p>
+ If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
+ manner as any other work item.
+</p>
+<p>
+ The&nbsp;current process uses the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
+ using the attributes defined for that artifact.
+</p>
+<h3>
+ Submitting Change Requests
+</h3>
+<p>
+ When submitting a change request provide as much information as possible to enable a speedy review and
+ disposition.&nbsp; As a minimum, all change requests should include the following information:
+</p>
+<ul>
+ <li>
+ <strong>ID</strong> - a unique identifier for the change request to simplify tracking.&nbsp; If you are using some
+ form of change tracking tool the tool will assign a unique ID.
+ </li>
+ <li>
+ <strong>Brief Description</strong>&nbsp;- a name that summarizes the change request
+ </li>
+ <li>
+ <strong>Detailed Description</strong> - A detailed description of the change request.&nbsp; For a defect, if you
+ can provide information that will help reproduce the defect please do so.&nbsp; For an enhancement request, provide
+ a rationale for the request.
+ </li>
+ <li>
+ <strong>Affected Item</strong>&nbsp;- the affected artifact and version.
+ </li>
+ <li>
+ <strong>Severity</strong> - how severe is this issue (show stopper, nice to have, etc.).
+ </li>
+ <li>
+ <strong>Priority</strong> - how important it is this request in your opinion.
+ </li>
+</ul>
+<p>
+ Depending upon the system you are using, the names of these data elements may differ.&nbsp; However, this information
+ is required, in one form or another, to permit a speedy review and disposition of the change request.
+</p>
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/supporting_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/supporting_requirements.xmi
new file mode 100644
index 0000000..afd0639
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/supporting_requirements.xmi
@@ -0,0 +1,417 @@
+<?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" epf:version="1.0.0" xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" name="supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q" guid="-BdYFG4-dbPBGFzF9z6KGPA" changeDate="2006-12-21T12:43:46.709-0500" version="1.0.0">
+ <mainDescription><p>
+ There is a finite set of requirements to consider when it comes to gathering system-wide requirements, qualities, or
+ constraints. Many of them are unfamiliar to stakeholders; therefore, they may find it difficult to answer questions
+ related to topics such as availability, performance, scalability, or localization. You can use this guideline and the
+ associated checklist <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.html"
+ guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a>&nbsp;when speaking to stakeholders to ensure that
+ all topics are discussed. Make sure that stakeholders understand the costs of their selections and do not end up
+ wanting everything that is on the list.
+</p>
+<h3>
+ Functional
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Auditing:</strong> Is there a need to track who used the system and when they used it? State
+ requirements for providing audit trails when running the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Authentication:</strong> Will access to the system be controlled? State requirements for
+ authentication.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Licensing:</strong> Will the system or parts of the system be licensed? If open-source software has
+ been used in the system, have all open-source agreements been respected? State requirements for acquiring,
+ installing, tracking, and monitoring licenses.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Printing:</strong> Will printing capability be required? State requirements for printing.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Reporting:</strong> Is reporting capability required? State requirements for reporting.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Scheduling:</strong> Will certain system actions need to be scheduled? State requirements for
+ scheduling capability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Security:</strong> Will elements of the system or system data need to be secure? State requirements to
+ protect access to certain resources or information.
+ </p>
+ </li>
+</ul>
+<h3>
+ Usability
+</h3>
+<p>
+ Usability requirements are critical to the success of any system. Unfortunately, usability requirements are often the
+ most poorly specified requirements. Consider this common requirement: The system shall be easy to use. This doesn't
+ help much, because it cannot be verified.
+</p>
+<p>
+ While capturing usability requirements, it is a good idea to identify issues and concerns first, and then refine these
+ into verifiable requirements later (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>). According to a traditional definition,
+ usability consists of five factors:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Ease of learning:</strong> A user with a specified level of experience must be able to learn how to use
+ the system in a specified amount of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Task efficiency:</strong> A user should be able to complete a specified task in a specified time (or
+ number of mouse clicks).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Ease of remembering:</strong> A user should be able to remember how to accomplish specified tasks after
+ not using the system for a specified period of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understandability:</strong> A user must be able to understand system prompts and messages and what the
+ system does.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Subjective satisfaction:</strong> A specified percentage of the user community must express
+ satisfaction with using the system.
+ </p>
+ </li>
+</ul>
+<p>
+ You may want to use the following method to identify and specify usability requirements:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ol>
+ <li>
+ Identify the key usability issues by looking at critical tasks, user profiles, system goals, and previous
+ usability problems.
+ </li>
+ <li>
+ Choose the appropriate style to express the requirements:
+ <ul>
+ <li>
+ <strong>Performance style:</strong> Specify how fast users can learn various tasks and how fast they
+ can perform the tasks after training.
+ </li>
+ <li>
+ <strong>Defect style:</strong> Rather than measuring task times, identify usability defects and
+ specifies how frequently they may occur.
+ </li>
+ <li>
+ <strong>Guideline style:</strong> Specify the general appearance and response time of the user
+ interface by reference to an accepted and well-defined standard
+ </li>
+ </ul>
+ </li>
+ <li>
+ Write the actual requirements, including performance criteria (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>&nbsp;for more information).
+ </li>
+ </ol>
+</div>
+<h3>
+ Reliability
+</h3>
+<p>
+ Reliability includes the system's ability to continue running under stress and adverse conditions. In the case of an
+ application, reliability relates to the amount of time that the software is available and running as opposed to time
+ unavailable. Specify reliability acceptance levels, as well as how they will be measured and evaluated. Describe
+ reliability criteria in measurable terms. This is usually expressed as the allowable time between failures or the total
+ allowable failure rate. Other important reliability considerations include:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Accuracy:</strong> Specify requirements for the precision (resolution) and the accuracy (by some known
+ standard) that is required in any calculation performed or in system output.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Availability:</strong> Specify requirements for the percentage of time the system is available for use,
+ hours of use, maintenance access, and degraded-mode operations. Availability is typically specified in terms of
+ the Mean Time Between Failures (MTBF).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Recoverability:</strong> Specify requirements for recovery from failure. This is typically specified in
+ terms of the Mean Time to Repair (MTTR).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Frequency and severity of failures:</strong> Specify the maximum defect rate (typically expressed as
+ defects/KSLOC or defects/function-point) and severity of failures. Severity&nbsp;may be categorized in terms of
+ <strong>minor</strong>, <strong>significant</strong>, and <strong>critical</strong> defects. The requirements
+ must define each of these terms unambiguously. For example, a <strong>critical</strong> defect could be defined
+ as one that results in loss of data or complete inability to use certain functionality of the system.
+ </p>
+ </li>
+</ul>
+<h3>
+ Performance
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Response times:</strong> Specify the amount of time available for the system to complete specified
+ tasks and transactions (average, maximum). Use units of measurement. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ Any interface between a user and the system shall have a maximum response time of 2 seconds.
+ </li>
+ <li>
+ The product shall download the new status parameters within 5 minutes of a change.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Throughput:</strong> Specify the capacity of the system to support a given flow of information (for
+ example, transactions per second).<br />
+ </li>
+ <li>
+ <strong>Capacity:</strong> Specify on the volumes that the product must be able to deal with and the numbers of
+ data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
+ unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
+ (memory, disk, . . . ) or degradation modes (what is the acceptable mode of operation when the system has been
+ degraded in some manner) <em>Examples:</em>
+ <ul>
+ <li>
+ The product shall cater for 300 simultaneous users within the period from 9:00 AM to 11 AM.
+ </li>
+ <li>
+ Maximum loading at other periods will be 150.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Start-up:</strong> The time for the system to start up.<br />
+ </li>
+ <li>
+ <strong>Shut-down:</strong> The time for the system to shut down.
+ </li>
+</ul>
+<h3>
+ Supportability
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Adaptability:</strong> Are there any special requirements regarding adaptation of the software
+ (including upgrading)? List requirements for the ease with which the system is adapted to new environments.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Compatibility:</strong> Are there any requirements regarding this system and its compatibility with
+ previous versions of this system or legacy systems that provide the same capability?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Configurability:</strong> Will the product be configured after it has been deployed? In what way will
+ the system be configured?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Installation:</strong> State any special requirements regarding system installation
+ </p>
+ </li>
+ <li>
+ <strong>Level of Support:</strong> What is the level of support that the product requires? This is often done using
+ a Help desk. If there are to be people who provide support for the product, is that support considered part of what
+ you are providing to the customer? Are there any requirements for that support? You might also build support into
+ the product itself, in which case this is the place to write those requirements. Consider the level of support that
+ you anticipate providing and what forms it might take.<br />
+ </li>
+ <li>
+ <strong>Maintainability:</strong> Are there any special requirements regarding system maintenance? What are the
+ requirements for the intended release cycle for the product and the form that the release will take? Quantify the
+ time necessary to make specified changes to the product. There may also be special requirements for
+ maintainability, such as&nbsp;a requirement that&nbsp;the product must be able to be maintained by its end-users or
+ developers who are not your development team. This has an effect on the way that the product is developed, and
+ there may be additional requirements for documentation or training. Describe the type of maintenance and the amount
+ of effort required. <em>Examples:</em><br />
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ A new weather station must be able to be added to the system overnight.
+ </li>
+ <li>
+ The maintenance releases will be offered to end-users once a year.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Scalability:</strong> What volumes of users and data will the system support? This specifies the expected
+ increases in size that the product must be able to handle As businesses grow (or are expected to grow), the
+ software products must increase their capacities to cope with the new volumes. This may be expressed as a profile
+ over time.<br />
+ </li>
+ <li>
+ <strong>Testability:</strong> Are there any special requirements regarding the testability of the system?
+ </li>
+</ul>
+<h3>
+ Constraints (+)
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Design constraints:</strong> Are there any design decisions that have been mandated that the product
+ must adhered to?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Third-party components:</strong> Specify any mandated legacy, COTS, or open-source components to be
+ used with the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation languages:</strong> Specify requirements on the implementation languages to be used
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Platform support:</strong> Specify requirements on the platforms that the system will support
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Resource limits:</strong> Specify requirements on the use of system resources, such as memory and hard
+ disk space
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Physical Constraints:</strong> Specify requirements on the shape, size, and weight of the resulting
+ hardware to house the system
+ </p>
+ </li>
+</ul>
+<h3>
+ Interface Requirements (+)
+</h3>
+<p>
+ Describe both the user interface and interfaces with external systems.
+</p>
+<h4>
+ User interface
+</h4>
+<p>
+ Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
+ section is to state the requirements, but not to describe the user interface itself, because interface design may
+ overlap the requirements-gathering process. This is particularly true if you are using prototyping as part of your
+ requirements gathering process. As you develop prototypes, it is important to capture the requirements that relate to
+ the look and feel of the user interface. In other words, be sure that you understand your client’s intentions for the
+ product’s look and feel. Record these as requirements, rather than merely using a prototype for approval.
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Look and feel:</strong> A description of the aesthetic appearance and layout of the interface. Your
+ client may have given you particular demands, such as style, colors, degree of interaction, and so on. This
+ section captures the requirements for the interface, rather than the design for the interface. The motivation
+ is to capture the expectations, the constraints, and the client’s demands for the interface before designing
+ it. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ The product shall have the same layout as the district maps from the engineering department.
+ </li>
+ <li>
+ The product shall use the company color.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Layout and navigation requirements:</strong> Specify requirements on major screen areas and how they should
+ be grouped together.<br />
+ </li>
+ <li>
+ <strong>Consistency:</strong> Consistency in the user interface enables users to predict what will happen. This
+ section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
+ the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
+ and shapes, placements for entering / presenting data, terminology<br />
+ </li>
+ <li>
+ <strong>User personalization and customization requirements:</strong> Requirements on content that should
+ automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
+ content displayed or to personalize displayed content.
+ </li>
+</ul>
+<h4>
+ Interfaces to external systems or devices
+</h4>
+<ul>
+ <li>
+ <p>
+ <strong>Software interfaces:</strong> Are there any external systems with which this system must interface? Are
+ there any constraints on the nature of the interface between this system and any external system, such as the
+ format of data passed between these systems? Do they use any particular protocol? Describe software interfaces
+ with other components. These may be purchased components, components reused from another application, or
+ components being developed for subsystems outside of the scope of the system under consideration, but with
+ which this it must interact. For each system, consider both provided and required interfaces.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Hardware interfaces:</strong> Define any hardware interfaces that are to be supported by the software,
+ including logical structure, physical addresses, expected behavior, and so on.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Communications interfaces:</strong> Describe any communications interfaces to other systems or devices,
+ such as local area networks (LANs), remote serial devices, and so on.
+ </p>
+ </li>
+</ul>
+<h3>
+ Business Rules (+)
+</h3>
+<p>
+ Besides technical requirements, also consider the particular business domain in which the system needs to fit.
+</p>
+<p>
+ Business rules or policies that the system must conform to may constrain system functionality. Business rules are
+ referred to by system use cases and can be in the form of decision tables, computation rules, decision trees,
+ algorithms, and so forth. Describing the rules in the flows of the use cases usually clutters the use-case
+ specifications. Therefore, they are normally captured in separate artifacts or as annexes related to the use-case
+ specifications. In many cases, a business rule applies to more then one use case. Shared business rules should be
+ stored in a single repository, such as a supporting requirements document.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/test_ideas.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/test_ideas.xmi
new file mode 100644
index 0000000..6bf0b28
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/test_ideas.xmi
@@ -0,0 +1,144 @@
+<?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" epf:version="1.0.0" xmi:id="_y3rxsMM3EdmSIPI87WLu3g" name="test_ideas,_0jzlsMlgEdmt3adZL5Dmdw" guid="_y3rxsMM3EdmSIPI87WLu3g" changeDate="2006-09-29T09:37:59.292-0700" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Test ideas are used to generate tests.&nbsp;Test ideas can come from many different sources.&nbsp;In general, they can
+ be derived in different ways depending on the given development domain, the kind of application being developed, and
+ the sophistication of the testers.&nbsp;Although test ideas are derived in many different ways, there are some useful
+ categories for generating them.&nbsp;This guideline will describe some of these categories as well as some general
+ heuristics for creating good test ideas.
+</p>
+<h4>
+ Test Ideas and Functions
+</h4>
+<p>
+ Below are some test ideas to calculate the square root:
+</p>
+<ol>
+ <li>
+ A number that's barely less than zero as input
+ </li>
+ <li>
+ Zero as the input
+ </li>
+ <li>
+ Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
+ </li>
+ <li>
+ Print to a LaserJet IIIp
+ </li>
+ <li>
+ Test with database full
+ </li>
+</ol>
+<p>
+ The first&nbsp;3 test ideas validate input while the last 2 address environmental issues.&nbsp; Even though these
+ statements are very incomplete they ensure that an idea is not forgotten.
+</p>
+<h4>
+ Test Ideas and Boundaries
+</h4>
+<p>
+ Test ideas are often based on fault models.&nbsp; Consider boundaries. It's safe to assume the square root function can
+ be implemented something like this:<br />
+ double sqrt(double x) {<br />
+ &nbsp;&nbsp;&nbsp; if (x &lt; 0)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // signal error<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br />
+ It's also plausible that the &lt; will be incorrectly typed as &lt;=. People often make that kind of mistake, so it's
+ worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x&lt;=0)
+ and the correct expression (x&lt;0) will take the same branch of the if statement. Similarly, giving X the value -5
+ cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea.
+</p>
+<h4>
+ Test Idea and Methods
+</h4>
+<p>
+ Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
+ obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is
+ found.<br />
+ int Collection.find(String string, Boolean ignoreCase);
+</p>
+<p>
+ Here are some test ideas for this method, each of which could be implemented as a test.&nbsp;
+</p>
+<ol>
+ <li>
+ Match found in the first position
+ </li>
+ <li>
+ Match found in the last position
+ </li>
+ <li>
+ No match found
+ </li>
+ <li>
+ Two or more matches found in the collection
+ </li>
+ <li>
+ Case is ignored; match found, but it wouldn't match if case was obeyed
+ </li>
+ <li>
+ Case is obeyed; an exact match is found
+ </li>
+ <li>
+ Case is obeyed; a string that would have matched if case were ignored is skipped
+ </li>
+</ol>
+<p>
+ However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas
+ 2, 6, and 7:
+</p>
+<p>
+ <strong>Setup:</strong> Collection initialized to ["dawn", "Dawn"]<br />
+ <strong>Invocation:</strong> Collection.find("Dawn", false)<br />
+ <strong>Expected result:</strong> Return value is 1 (it would be 0 if "dawn" were not skipped)
+</p>
+<h4>
+ Test Idea Simplicity and Complexity
+</h4>
+<p>
+ Making test ideas nonspecific makes them easier to combine.<br />
+ Creating many several small tests that satisfy a few test ideas makes it simpler to:
+</p>
+<ul>
+ <li>
+ "Copy and Tweak" the tests to meet other test idea
+ </li>
+ <li>
+ Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if
+ the test covers 7 test ideas you will spend more time debugging the issue.&nbsp;
+ </li>
+</ul>
+<p>
+ If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote
+ the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the
+ chance the test will satisfy a test idea that you didn't know you needed.
+</p>
+<h4>
+ Complex Tests
+</h4>
+<p>
+ Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not
+ creating complex tests.
+</p>
+<ul>
+ <li>
+ Complex test are more difficult to debug because they usually cover multiple test ideas
+ </li>
+ <li>
+ Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.
+ </li>
+ <li>
+ Complex tests are more difficult to create.
+ </li>
+</ul>
+<p>
+ Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each
+ satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying
+ four.<br />
+ In practice, find a reasonable balance between complexity and simplicity.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/test_suite.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/test_suite.xmi
new file mode 100644
index 0000000..c0ce03e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/test_suite.xmi
@@ -0,0 +1,163 @@
+<?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" epf:version="1.0.0" xmi:id="_s60KoMM3EdmSIPI87WLu3g" name="test_suite,_0aDz0MlgEdmt3adZL5Dmdw" guid="_s60KoMM3EdmSIPI87WLu3g" changeDate="2006-09-29T12:48:57.425-0400" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The test suite provides a means of managing the complexity of the test implementation. Many system test efforts fail
+ because the team gets lost in the minutia of all of the detailed tests, and subsequently loses control of the test
+ effort. Similar to UML packages, test suites provide a hierarchy of encapsulating containers to help manage the test
+ implementation. They provide a means of managing the strategic aspects of the test effort by collecting tests together
+ in related groups that can be planned, managed, and assessed in a meaningful way.
+</p>
+<p>
+ The test suite represents a container for organizing arbitrary collections of related test scripts. This may be
+ realized (implemented) as one or more automated regression test suites, but the test suite can also be a work plan for
+ the implementation of a group of related manual test scripts. Note also that test suites can be nested hierarchically,
+ therefore one test suite may be enclosed within another.
+</p>
+<p>
+ Sometimes these groups of tests will relate directly to a subsystem or other system design element, but other times
+ they'll relate directly to things such as quality dimensions, core "mission critical" functions, requirements
+ compliance, standards adherence, and many others concerns that are organized based on requirements and therefore cut
+ across the internal system elements.
+</p>
+<p>
+ Consider creating test suites that arrange the available test scripts, in addition to other test suites, in many
+ different combinations: the more variations you have, the more you'll increase coverage and the potential for finding
+ errors. Give thought to a variety of test suites that will cover the breadth and depth of the target test items.
+ Remember the corresponding implication that a single test script (or test suite) may appear in many different test
+ suites.
+</p>
+<p>
+ Some test automation tools provide the ability to automatically generate or assemble test suites. There are also
+ implementation techniques that enable automated test suites to dynamically select all or part of their component test
+ scripts for each test cycle run.
+</p>
+<p>
+ Test suites can help you maintain your test assets and impose a level of organization that facilitates the entire
+ testing effort.&nbsp; Like physical objects, tests can break. It's not that they wear down, it's that something changed
+ in their environment. Perhaps they've been ported to a new operating system. Or, more likely, the code they exercise
+ has changed in a way that correctly causes the test to fail. Suppose you're working on version 2.0 of an e-banking
+ application. In version 1.0, this method was used to log in:
+</p>
+<p class="codeSample">
+ public boolean login (String username);
+</p>
+<p>
+ In version 2.0, the marketing department has realized that password protection might be a good idea. So the method is
+ changed to this:
+</p>
+<p class="codeSample">
+ public boolean login (String username, String password);
+</p>
+<p>
+ Any test that uses the first form of the login will fail. It won't even compile. In this example you could find that,
+ not many useful tests can be written that don't use login. You might be faced with hundreds or thousands of failing
+ tests.
+</p>
+<p>
+ These tests can be fixed by using a global search-and-replace tool that finds every instance of login(something) and
+ replaces it with login(something, "dummy password"). Then arrange for all the testing accounts to use that password,
+ and you're on your way.
+</p>
+<p>
+ Then, when marketing decides that passwords should not be allowed to contain spaces, you get to do it all over again.
+</p>
+<p>
+ This kind of thing is a wasteful burden, especially when, as is often the case, the test changes aren't so easily made.
+ There is a better way.
+</p>
+<p>
+ Suppose that the test scripts originally did not call the product's login method. Rather, they called a library method
+ that does whatever it takes to get the test logged in and ready to proceed. Initially, that method might look like
+ this:
+</p>
+<p class="codeSample">
+ public boolean testLogin (String username) {<br />
+ &nbsp; return product.login(username);<br />
+ }
+</p>
+<p>
+ When the version 2.0 change happens, the utility library is changed to match:
+</p>
+<p class="codeSample">
+ public Boolean testLogin (String username) {<br />
+ &nbsp; return product.login(username, "dummy password");<br />
+ }
+</p>
+<p>
+ Instead of a changing a thousand tests, you change one method.
+</p>
+<p>
+ Ideally, all the needed library methods would be available at the beginning of the testing effort. In practice, they
+ can't all be anticipated-you might not realize you need a testLogin utility method until the first time the product
+ login changes. So test utility methods are often "factored out" of existing tests as needed. It is very important that
+ you perform this ongoing test repair, even under schedule pressure. If you do not, you will waste much time dealing
+ with an ugly and un-maintainable test suite. You might well find yourself throwing it away, or being unable to write
+ the needed numbers of new tests because all your available testing time is spent maintaining old ones.
+</p>
+<p>
+ Note: the tests of the product's login method will still call it directly. If its behavior changes, some or all of
+ those tests will need to be updated. (If none of the login tests fail when its behavior changes, they're probably not
+ very good at detecting defects.)
+</p>
+<h3>
+ Abstraction helps manage complexity
+</h3>
+<p>
+ The previous example showed how tests can abstract away from the concrete application. Most likely you can do
+ considerably more abstraction. You might find that a number of tests begin with a common sequence of method calls: they
+ log in, set up some state, and navigate to the part of the application you're testing. Only then does each test do
+ something different. All this setup could-and should-be contained in a single method with an evocative name such as
+ readyAccountForWireTransfer. By doing that, you're saving considerable time when new tests of a particular type are
+ written, and you're also making the intent of each test much more understandable.
+</p>
+<p>
+ Understandable tests are important. A common problem with old test suites is that no one knows what the tests are doing
+ or why. When they break, the tendency is to fix them in the simplest possible way. That often results in tests that are
+ weaker at finding defects. They no longer test what they were originally intended to test.
+</p>
+<h3>
+ Throwing away tests
+</h3>
+<p>
+ Even with utility libraries, a test might periodically be broken by behavior changes that have nothing to do with what
+ it checks. Fixing the test doesn't stand much of a chance of finding a defect due to the change; it's something you do
+ to preserve the chance of the test finding some other defect someday. But the cost of such a series of fixes might
+ exceed the value of the tests hypothetically finding a defect. It might be better to simply throw the test away and
+ devote the effort to creating new tests with greater value.
+</p>
+<p>
+ Most people resist the notion of throwing away a test, at least until they're so overwhelmed by the maintenance burden
+ that they throw all the tests away. It is better to make the decision carefully and continuously, test by test, asking:
+</p>
+<ul>
+ <li>
+ How much work will it be to fix this test well, perhaps adding to the utility library?
+ </li>
+ <li>
+ How else might the time be used?
+ </li>
+ <li>
+ How likely is it that the test will find serious defects in the future? What's been the track record of it and
+ related tests?
+ </li>
+ <li>
+ How long will it be before the test breaks again?
+ </li>
+</ul>
+<p>
+ The answers to these questions will be rough estimates or even guesses. But asking them will yield better results than
+ simply having a policy of fixing all tests.
+</p>
+<p>
+ Another reason to throw away tests is that they are now redundant. For example, early in development, there might be a
+ multitude of simple tests of basic parse-tree construction methods (the LessOp constructor and the like). Later, during
+ the writing of the parser, there will be a number of parser tests. Since the parser uses the construction methods, the
+ parser tests will also indirectly test them. As code changes break the construction tests, it's reasonable to discard
+ some of them as being redundant. Of course, any new or changed construction behavior will need new tests. They might be
+ implemented directly (if they're hard to test thoroughly through the parser) or indirectly (if tests through the parser
+ are adequate and more maintainable).
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/types_of_developer_tests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/types_of_developer_tests.xmi
new file mode 100644
index 0000000..87d5be9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/types_of_developer_tests.xmi
@@ -0,0 +1,253 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-VGT8iHGtQSiOUGitq1qmow" name=",_eRutgC5QEduVhuZHT5jKZQ" guid="-VGT8iHGtQSiOUGitq1qmow" changeDate="2006-12-28T10:50:35.593-0800" version="1.0.0">
+ <mainDescription><p>
+ This guideline describes a number of types of tests. To perform these types of testing you need to define, and then
+ run, a series of tests against&nbsp;the source code. A developer test is a single test that needs to be performed.
+</p>
+<p>
+ It is valuable&nbsp;to augment automated tests with human readable test scripts in order to implement developer test
+ cases, scripts that include the information discussed below. A test script is the actual steps, sometimes either
+ written procedures to follow or the source code of a test. Developer test scripts are run against testing targets:
+ either one unit of source code, a more complex portion of your system (such as a component), or the entire system
+ itself to test&nbsp;some developer issue such as integration.
+</p>
+<h3>
+ Regression Testing
+</h3>
+<p>
+ Regression testing is the act of ensuring that changes to&nbsp;the code have not adversely affected existing
+ functionality. It is important to recognize that incremental development makes regression testing critical. Whenever
+ you release an application, you must ensure its previous functionality still works, and because you release
+ applications more often when taking the incremental approach, this means regression testing becomes that much more
+ important. Regression testing is the first thing you should be thinking about when testing for the following reasons:
+</p>
+<ol>
+ <li>
+ You want to be able to modify code and know that you can rerun your tests to see if you broke anything.
+ </li>
+ <li>
+ Existing users get very angry when things that previously worked don’t work anymore.
+ </li>
+</ol>
+<p>
+ Regression testing is fairly straightforward conceptually – you just need to run all of&nbsp;the previous test cases
+ against the new version of&nbsp;the code. Regression testing tools help immensely because they are designed with
+ regression testing in mind. However, there are potential challenges to regression testing:
+</p>
+<ul>
+ <li>
+ When you change your production, either to enhance it or to refactor it, you will need to rework existing test
+ cases coupled to that code.
+ </li>
+ <li>
+ If your updates affect only a component of the system, then potentially you only need to run the test cases that
+ affect this single component. Although this approach is a little risky because your changes may have had a greater
+ impact than you suspect, it does help to reduce both the time and cost of regression testing.
+ </li>
+ <li>
+ The more non-code artifacts that you decide to keep, the greater the effort to regression test your work and
+ therefore the greater the risk to your project because you are more likely to skimp on your testing efforts.
+ </li>
+</ul>
+<p>
+ Regression testing is critical to success as an agile developer. Many software developers use the xUnit family of open
+ source tools, such as <a href="http://www.junit.org/" target="_blank">JUnit</a> and <a href="http://www.vbunit.org/"
+ target="_blank">VBUnit</a>, to test their code. The advantage of these tools is that they implement a testing framework
+ with which you can regression test all of your source code. Commercial testing tools are also viable options.
+</p>
+<h3>
+ Traditional Code Testing Techniques
+</h3>
+<p>
+ Although object and procedural technologies are different, several important testing concepts from the procedural world
+ are valid regardless of the underlying technology. These traditional testing techniques are:
+</p>
+<ul>
+ <li>
+ Black-box testing
+ </li>
+ <li>
+ Clear-box testing
+ </li>
+ <li>
+ Boundary-value testing
+ </li>
+ <li>
+ Coverage/Path testing
+ </li>
+</ul>
+<h4>
+ Black-Box Testing
+</h4>
+<p>
+ Black-box testing, also called interface testing, is a technique in which you create test cases based only on the
+ expected functionality of a method, class, or application without any knowledge of its internal workings. One way to
+ define black-box testing is that given input A you should obtain expected results B.
+</p>
+<p>
+ The goal of black-box testing is to ensure the system can do what it should be able to do, but not how it does it. For
+ example, if you invoke differenceInDays(June 30 2006, July 3 2006) the expected result should be three. The creation of
+ black-box tests is often driven by the requirements for&nbsp;the system. The basic idea is&nbsp;to look at the user
+ requirement and ask what needs to be done to show that the user requirement is met.
+</p>
+<p>
+ The primary advantage of black-box testing is that it enables you to prove that your application fulfills the
+ requirements defined for it.&nbsp;&nbsp; The primary disadvantage is that it does not show that the internals
+ of&nbsp;the system work (hence the need for clear-box testing).
+</p>
+<h4>
+ Clear-Box Testing
+</h4>
+<p>
+ Clear-box testing, also called white-box testing, is based on the idea that&nbsp;the program code can drive the
+ development of test cases. The basic concept is you look at&nbsp;the code, and then create test cases that exercise it.
+ For example, assume you have access to the source code for differenceInDays(). When you look at it, you see an IF
+ statement determines whether the two dates are in the same year. If&nbsp;they are in the same year then&nbsp;a simple
+ strategy based on Julian dates is used; if not then a more complex&nbsp;strategy is used. This indicates that you need
+ at least one test that uses dates from the same year and one from different years. By looking at the code, you are able
+ to determine new test cases to exercise the different logic paths within it.
+</p>
+<p>
+ The primary advantage of this concept is that it motivates you to create tests that exercise specific lines of
+ code.&nbsp; The disadvantages are that it does not ensure that your code fulfils the actual requirements (hence the
+ need for black-box testing) and that your testing code becomes highly coupled to your application code.
+</p>
+<h4>
+ Boundary-Value Testing
+</h4>
+<p>
+ This is based on the knowledge that you need to test your code to ensure it can handle unusual and extreme situations.
+ For example, boundary-value test cases differenceInDays() would include passing it the same date, two wildly different
+ dates, one date on the last day of the year and the second on the first day of the following year, and one date on
+ February 29th of a leap year. The basic idea is you want to look for limits defined either by your business rules or by
+ common sense, and then create test cases to test attribute values in and around those values.
+</p>
+<p>
+ The primary advantage of boundary value testing is that it motivates you to confirm that your program code is able to
+ handle “unusual” or “extreme” cases.
+</p>
+<h4>
+ Coverage and Path Testing
+</h4>
+<p>
+ Two critical “traditional” concepts are coverage and path testing. Coverage testing is a technique in which you create
+ a series of test cases designed to test all the code paths in your code. In many ways, coverage testing is simply a
+ collection of clear-box test cases that together exercise every line of code in your application at least once. Path
+ testing is a superset of coverage testing that ensures not only have all lines of code been tested, but all paths of
+ logic have also been tested. The main difference occurs when you have a method with more than one set of case
+ statements or nested IF statements: to determine the number of test cases with coverage testing you would count the
+ maximum number of paths between the sets of case/nested IF statements and, with path testing, you would multiply the
+ number of logic paths.
+</p>
+<h4>
+ Unit and Integration Testing
+</h4>
+<p>
+ Unit testing is the testing of an item, such as an operation, in isolation. For example, the tests defined so far for
+ differenceInDays() are all unit tests. Integration testing, on the other hand, is the testing of a collection of items
+ to validate that they work together. In the case of the data library/class, do the various functions work together?
+ Perhaps the differenceInDays() function has a side effect that causes the dayOfWeek() function to fail if
+ differenceInDays() is called first. Integration testing looks for problems like this.
+</p>
+<h3>
+ Object-Oriented Testing Techniques
+</h3>
+<p>
+ When testing systems built using object technology it is important to understand that your source code is composed of
+ several constructs, including methods (operations), classes, and inheritance. Therefore you need testing techniques
+ that reflect the fact that you have these constructs. These techniques are:
+</p>
+<ul>
+ <li>
+ Method testing
+ </li>
+ <li>
+ Class testing
+ </li>
+ <li>
+ Class-integration testing
+ </li>
+ <li>
+ Inheritance-regression testing
+ </li>
+</ul>
+<h4>
+ Method Testing
+</h4>
+<p>
+ Method testing is the act of ensuring that your methods (operations) perform as defined. In procedural testing this
+ would have been called function/procedure testing. Issues to address via method testing include:
+</p>
+<ul>
+ <li>
+ Ensure that your getter/setter methods work as intended
+ </li>
+ <li>
+ Ensure that each method returns the proper values, including error messages and exceptions
+ </li>
+ <li>
+ Validate the parameters being passed to a method
+ </li>
+ <li>
+ Ensure that a method does what it should
+ </li>
+</ul>
+<p>
+ The advantage of method testing is that it ensures that methods work well in isolation but it does not help to find
+ unintended side effects.
+</p>
+<h4>
+ Class Testing
+</h4>
+<p>
+ The main purpose of class testing is to test classes in isolation, and it is effectively the combination of traditional
+ unit testing and integration testing. It is unit testing because you are testing the class and its instances as single
+ units in isolation, but it is also integration testing because you need to verify the methods and attributes of the
+ class work together. The one assumption you need to make while writing “class tests” is that all other classes in the
+ system work. Issues to address via class testing include:
+</p>
+<ul>
+ <li>
+ Validate that the attributes of an object are initialized properly
+ </li>
+ <li>
+ Validate the invariants of the class
+ </li>
+</ul>
+<p>
+ The primary advantages of class testing are that it validates that the operations and properties of a class work
+ together and that the class works in isolation. However, it does not guarantee that a class works well with the rest of
+ your system.
+</p>
+<h4>
+ Class-integration Testing
+</h4>
+<p>
+ Also known as component testing, this technique addresses the issue of whether the classes in your system, or a
+ component of your system, work together properly. The relationships between classes can be used to drive the
+ development of class integration test cases. Issues to address via class-integration testing include:
+</p>
+<ul>
+ <li>
+ Validate that objects do what other objects expect of them
+ </li>
+ <li>
+ Validate that return values are acted appropriately
+ </li>
+ <li>
+ Validate that exceptions/errors are processed appropriately
+ </li>
+</ul>
+<p>
+ The technique helps to validate that the various classes within a component, or a system, work together. However, it
+ can be difficult to define and develop the test cases to fully perform this level of testing.
+</p>
+<h4>
+ Inheritance-regression&nbsp;Testing
+</h4>
+This is the act of running of test cases defined for the superclasses on the instances of a subclass because errors have
+not been introduced by that new subclass. New methods are added and existing methods may be redefined by subclasses,
+methods which access and potentially change the value of the attributes defined in the superclass. It is possible that a
+subclass may change the value of the attributes in a way that was never intended in the superclass, or at least was never
+expected. The point is that you need to invoke the test suite of the superclass(es) when testing a subclass. <br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/uc_model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/uc_model.xmi
new file mode 100644
index 0000000..ecbc4c7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/uc_model.xmi
@@ -0,0 +1,291 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_AGvpcMM3EdmSIPI87WLu3g" name="uc_model,_0VAUsMlgEdmt3adZL5Dmdw" guid="_AGvpcMM3EdmSIPI87WLu3g" changeDate="2007-02-28T11:40:11.200-0800" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The key to successful iterative development is ensuring that the development team maximizes stakeholder value and
+ minimizes risk early in the lifecycle, while minimizing re-work later.&nbsp; This imposes some constraints on how we
+ develop the use-case model.
+</p>
+<p>
+ At one extreme is the classical waterfall approach, which attempts to&nbsp;detail all of the requirements prior to
+ design and implementation.&nbsp; This approach delays delivery of stakeholder value and risk reduction unnecessarily.
+</p>
+<p>
+ At the other extreme is&nbsp;beginning development prior to understanding what the system must do.&nbsp; This approach
+ results in significant, and costly, re-work later in the lifecycle.
+</p>
+<p>
+ A better approach is to detail only those requirements which will be the focus of development in the next iteration (or
+ two).&nbsp; Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract
+ understanding of the "big-picture".
+</p>
+<p>
+ The following discussion will outline the approach used to evolve the use-case model to achieve these goals.
+</p>
+<h3>
+ <a id="How the Use-Case Model Evolves" name="How the Use-Case Model Evolves">How the Use-Case Model Evolves</a>
+</h3>
+<p>
+ The recommended approach to evolving the use-case model takes a "breadth before depth" approach.&nbsp; In this
+ approach, one identifies the actors and use cases and outlines them quickly.&nbsp; Based on this knowledge, one can
+ then perform an initial assessment of risk and priorities and thus focus the effort of&nbsp;detailing&nbsp;the use
+ cases on the right areas.
+</p>
+<h4>
+ Inception
+</h4>
+<p>
+ The purpose of inception is to understand the scope of the system.&nbsp; We need to understand the main purpose of the
+ system, what is within the scope of the system, and what is external to the system.&nbsp; We should strive to list all
+ the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at
+ this time.&nbsp; Strive to&nbsp;identify by name&nbsp;~80% of the primary actors and use cases and provide a brief
+ description (one - three sentences) for each.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Identify Stakeholders
+ </h5>
+ <p>
+ Begin by listing all the external stakeholders for the system.&nbsp; These individuals will be the source of the
+ requirements.
+ </p>
+ <h5>
+ Identify Actors
+ </h5>
+ <p>
+ Name and describe the primary actors.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>.
+ </p>
+ <h5>
+ Identify Use Cases
+ </h5>
+ <p>
+ For each actor, ask "what does this actor want to accomplish with the system"?&nbsp; This will reveal the primary
+ use cases for the system.&nbsp; Name and describe each of these as you discover them.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the use case model to capture the actor and use case names and brief description.&nbsp; Capture the
+ relationship between the actors and use cases.
+ </p>
+ <h5>
+ Outline the Basic Flows
+ </h5>
+ <p>
+ For those use cases that are considered high priority by the stakeholders, or high risk by the development team,
+ capture a step-by-step description of the Basic Flow.&nbsp; Don't worry about structuring the flow at this
+ point.&nbsp; Focus on capturing the dialogue between the actor and the system and the key requirements for the
+ system.
+ </p>
+ <h5>
+ Identify Alternate Flows
+ </h5>
+ <p>
+ As you work through the Basic Flows, ask: "What can go wrong?"; "What options are available at this point?";
+ etc.&nbsp; These types of questions will reveal alternate flows.&nbsp; Capture these, giving each a name and brief
+ description.&nbsp; Fight the urge to detail these alternate flows at this time.
+ </p>
+ <h5>
+ Refactor the Use Case Model
+ </h5>
+ <p>
+ Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into
+ &lt;&lt;include&gt;&gt; use cases.&nbsp; Refactor the Use Case model accordingly.
+ </p>
+ <h5>
+ Prioritize Use Cases
+ </h5>
+ <p>
+ Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use
+ cases.&nbsp; This will be the primary input to iteration planning.
+ </p>
+</blockquote>
+<h4>
+ Elaboration
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of elaboration is to demonstrate the feasibilty of&nbsp;the solution prior to committing additional
+ resources.&nbsp; To be successful, one should demonstrate that stakeholder value can be delivered and that the risk
+ of continuing is acceptable.&nbsp; We should strive to detail and implement ~20% of the scenarios.&nbsp; These
+ scenarios should be selected to achieve good coverage of the architecture (for example, a vertical slice through
+ the architecture, touching as many&nbsp;components and interfaces as possible, is preferred to elaborating the GUI
+ only).
+ </p>
+ <h5>
+ Detail Basic Flow
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flow
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.&nbsp; Depending upon the
+ complexity of the system, you may want to introduce packages to group the use cases in a logical manner to simplify
+ communications, iteration planning, and parallel development.
+ </p>
+</blockquote>
+<h4>
+ Construction
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of construction is to incrementally deliver functionality (and value).&nbsp; Working from the iteration
+ plan, continue detailing the remaining requirements.&nbsp; Shoot for completion of ~90 - ~95% of use cases by the
+ end of construction.
+ </p>
+ <h5>
+ Detail Basic Flows
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flows
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.
+ </p>
+</blockquote>
+<h4>
+ Transition
+</h4>
+<p>
+ The purpose of transition is to make the system operational in its intended environment.&nbsp; Some requirements will
+ still be uncovered at this point, but if we have done things right they should not stress the design.&nbsp; The
+ remaining ~5% to ~10% of use cases should be detailed and implemented in this phase.
+</p>
+<h3>
+ <a id="Avoiding Functional Decomposition" name="Avoiding Functional Decomposition">Avoiding Functional
+ Decomposition</a>
+</h3>
+<p>
+ A common pitfall for those new to use-case models is to perform a&nbsp;functional decomposition of the system. This
+ results in many small "use cases", that on their own do not deliver the "observable result of value" to the
+ actor.&nbsp; To avoid this, watch for the following symptoms:
+</p>
+<ul>
+ <li>
+ <strong>Small</strong> use cases, meaning that the description of the flow of events is only one or a few
+ sentences.
+ </li>
+ <li>
+ <strong>Many</strong> use cases, meaning that the number of use cases is some multiple of a hundred, rather than a
+ multiple of ten.
+ </li>
+ <li>
+ Use-case names that are constructions such as "do this operation on this particular data" or "do this function with
+ this particular data". For example, "Enter Personal Identification Number in an ATM machine" should not be modeled
+ as a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a
+ complete flow of events that results in something of value to an actor.
+ </li>
+</ul>
+<p>
+ To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:
+</p>
+<ul>
+ <li>
+ What is the context of the system?
+ </li>
+ <li>
+ Why are you building this system?
+ </li>
+ <li>
+ What does the user want the system to do?
+ </li>
+ <li>
+ How&nbsp;do the users benefit from the system?
+ </li>
+</ul>
+<h3>
+ <a id="Structuring the Use-Case Model" name="Structuring the Use-Case Model">Structuring the Use-Case Model</a>
+</h3>
+<p>
+ There are three main reasons for structuring the use-case model:
+</p>
+<ul>
+ <li>
+ To make the use cases easier to understand.
+ </li>
+ <li>
+ To partition common behavior described within many use cases.
+ </li>
+ <li>
+ To make the use-case model easier to maintain.
+ </li>
+</ul>
+<p>
+ Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit
+ more about their behavior than a one-sentence description. You should at least have established a step-by-step outline
+ for the flow of events of the use case to make sure that your decisions are based on an accurate understanding of the
+ behavior.
+</p>
+<p>
+ There are several advanced modeling concepts available in the literature for&nbsp;structuring the use-case model,
+ however, following the principle of "keep-it-simple" only the most useful of these, namely the &lt;&lt;include&gt;&gt;
+ relationship is discussed in this process.&nbsp; This relationship permits one to factor out common behavior into a
+ separate use case that is "include" in other use cases.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>&nbsp;for more&nbsp;details.
+</p>
+<p>
+ Another aspect of&nbsp;structuring the use-case model for easier understanding is grouping the use cases into packages.
+ The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see
+ <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>.
+</p>
+<h3>
+ <a id="Use Cases Are Always Related to Actors" name="Use Cases Are Always Related to Actors">Relationship Between Use
+ Cases and Actors</a>
+</h3>
+<p>
+ Running each use case includes communication with one or more actors. A use-case instance is always started by an actor
+ asking the system to do something. This implies that every use case should have communicates-associations with actors.
+ The reason for this rule is to enforce that the system provides only the functionality that users need and nothing
+ else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the
+ requirements.
+</p>
+<p>
+ However, there are some exceptions to this rule:
+</p>
+<ul>
+ <li>
+ An&nbsp;"included" use case might not interact with an actor if the base use case does.
+ </li>
+ <li>
+ A use case may be initiated according to a schedule (for example, once a week or once a day), which means that the
+ system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated
+ by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have
+ any associations to actors. However, for clarity, you can use "time" as an actor to show how the use case is
+ initiated in your use-case diagrams. <strong>CAUTION:</strong> if you have a lot of "time" actors in your model,
+ challenge them.&nbsp; Perhaps you missed a real actor, such as an administrator responsible for scheduling reports,
+ etc.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/uc_realizations.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/uc_realizations.xmi
new file mode 100644
index 0000000..978f2d7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/uc_realizations.xmi
@@ -0,0 +1,86 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-CFYVionNDLkMw6SG6runQA" name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" changeDate="2006-09-26T15:24:33.595-0700" version="1.0.0">
+ <mainDescription><p>
+ A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
+ can take various forms. It may include, for example, a textual description (a document), class diagrams of
+ participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
+ the flow of interactions between class and subsystem instances.
+</p>
+<p>
+ The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
+ managed separately from their realizations. This is particularly important for larger projects, or families of systems
+ where the same use cases may be designed differently in different products within the product family. Consider the case
+ of a family of telephone switches which have many use cases in common, but which design and implement them differently
+ according to product positioning, performance and price.
+</p>
+<p>
+ For larger projects, separating the use case and its realization allows changes to the design of the use case without
+ affecting the baselined use case itself.
+</p>
+<p>
+ In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
+ (such as textual descriptions) that form part of the use-case realization.
+</p>
+<p>
+ UML diagrams that&nbsp;support use-case realizations can be produced in an analysis context, a&nbsp;design context, or
+ both, depending on the needs of the project. For each use case in the use-case model, there&nbsp;can be&nbsp;a use-case
+ realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
+ dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
+ inheritance, as well as a dependency.<br />
+</p>
+<p align="center">
+ <img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
+</p>
+<p>
+ A use-case realization in the&nbsp;design can be traced to a use case in the use-case model.
+</p>
+<h4>
+ Class Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there may be one or more class diagrams depicting its participating classes. A class and
+ its objects often participate in several use-case realizations. It is important&nbsp;while designing to coordinate all
+ the requirements on a class and its objects that different use-case realizations may have. The figure below shows an
+ analysis&nbsp;class diagram for the realization of the Receive Deposit Item use case. Note the use of
+ boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Concept: Entity-Control-Boundary Pattern</a>).
+</p>
+<p align="center">
+ <img height="213" alt="Class diagram for the realization of Receive Deposit Item" src="./resources/md_ucre3.gif" width="328" />
+</p>
+<p align="center">
+ <strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
+</p>
+<h4>
+ Communication and Sequence Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there&nbsp;can be&nbsp;one or more interaction diagrams depicting its participating
+ objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
+ diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
+ of messages and are better when it is important to visualize the time ordering of messages, whereas communication
+ diagrams show the communication links between objects and are better for understanding all of the effects on a given
+ object and for algorithm design.
+</p>
+<p>
+ Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
+ responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
+ contain the following:
+</p>
+<ul>
+ <li>
+ Only the functionality actually used in support of a use case scenario.
+ </li>
+ <li>
+ Functionality that can be tested through an associated test case.
+ </li>
+ <li>
+ Functionality that is more easily traceable to requirements and changes.
+ </li>
+ <li>
+ Explicitly declared class dependencies that are easier to manage.
+ </li>
+</ul>
+<p>
+ These factors help improve the overall quality of the system.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/use_case_formats.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/use_case_formats.xmi
new file mode 100644
index 0000000..a4933b8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/use_case_formats.xmi
@@ -0,0 +1,330 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" name="new_guideline,_qq0GMAXkEduj_7BEUj1JfQ" guid="-pQrBSyxJHLLodLbS4R_Zdw" changeDate="2006-08-16T07:20:15.017-0700">
+ <mainDescription><h3> Use Case Formats </h3>
+<p> Use cases differ from project to project and person to person. A use case
+ that works in one situation may be totally unsuited for another. Different projects
+ have different needs. (See <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO04]</a>
+ for more information on use case formats.) </p>
+<p>Some need rigorous documentation, including <strong>high-ceremony use cases</strong>,
+ which are formal, highly structured use cases. If the writers used a template,
+ then they filled out all or almost all of its fields for each use case. High-ceremony
+ use cases are best suited for large, extremely complex, safety-critical systems,
+ such as flight control systems, telephone switches, and so forth. They are also
+ used in development cultures that have high documentation standards. </p>
+<p>Other projects may be more agile and less formal, benefiting from <strong>low-ceremony
+ use cases</strong>, which are informal, less rigidly structured use cases. If
+ the writers used a template, then they may have left many of the fields blank.
+ Low-ceremony use cases are best suited for smaller, less complex, less safety-critical
+ systems where most of the stakeholders have a strong background in the problem
+ domain. Sometimes, simple descriptions suffice, such as use case <strong>briefs</strong>.
+</p>
+<p> As <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline:
+ Detail Use Cases and Scenarios</a> explains, it makes sense to write use cases
+ iteratively. Starting with the basic details, you can then identify the various
+ alternative and error paths that the use case might follow so that you can evaluate,
+ rearrange, or eliminate them, and then elaborate or fill in the details of the
+ courses that you intended to use. You can then write the
+ use cases in<strong> </strong> one or more of
+ the following formats, progressively, until you
+ reach the one with the level of detail required for a specific project: </p>
+<ul>
+ <li><a id="Actor-Goal-List" name="Actor-Goal_List"><strong>Actor-Goal list</strong></a>:
+ A format for the overview</li>
+ <li> <a id="Briefs" name="Briefs"><strong>Briefs: </strong></a>A format for
+ writing summary use cases</li>
+ <li> <a id="Improvisational Score" name="Improvisational Score"><strong>Improvisational
+ score: </strong></a>A format for writing less formal, low-ceremony use cases</li>
+ <li> <a id="Symphonic Score" name="Symphonic Score"><strong>Symphonic score:
+ </strong></a>A format for writing more formal, high-ceremony use cases</li>
+</ul>
+<h4>Actor-Goal list </h4>
+<p> <strong>Context: </strong>You have identified your actors and are trying to
+ identify use cases. </p>
+<p> <strong>Problem:</strong> Developing a set of use cases in an ad hoc manner
+ can lead to unnecessary work, missing features, and feature creep. Weight
+ is one of the most important factors in space flight &#8212; so important that
+ the United States space agency, NASA, will not
+ allow anything on a spacecraft that isn’t absolutely critical to the flight.
+ If something literally isn’t worth its weight, then it doesn’t go. Likewise,
+ each use case adds cost to a system; therefore, you need to be sure to include
+ only those use cases that add some kind of value to your collection. </p>
+<p> <strong>Forces:<em> </em></strong></p>
+<ul>
+ <li>
+ <p><strong>Simply listing actors or listing goals is not informative enough,
+ but actors and goals together are informative.</strong> The classical approach
+ to writing use cases is to define a list of actors, then find use cases
+ for each. A variation on this theme is to itemize what the system must accomplish.
+ Yet, neither approach is adequate by itself. You need to know both who is
+ using the system and why they are using it. Otherwise, you introduce the
+ potential of either feature creep or missed features. At the least, a set
+ of use cases should describe this association. </p>
+ </li>
+ <li>
+ <p><strong> A quick overview of the entire project structure is sufficient
+ and necessary early in the use case development cycle.</strong> Ideally,
+ this overview should be as short as reasonably possible. It must contain
+ key information as to who requires each service and why they need it. Most
+ other information is not very useful at this stage of the project, because
+ it runs the risk of quickly becoming obsolete, as well as discouraging
+ out-of-the-box (innovative) thinking. An overview
+ helps the writers work through the entire set from a high-level view, expanding
+ some use cases, eliminating others, and combining still others into a more
+ logical grouping. </p>
+ </li>
+ <li>
+ <p><strong>You need to be able to expand each to a full use case on demand.
+ </strong>A <em>seedling</em><strong> </strong>use case forms the basis for
+ a full use case later in the iterative development cycle. Each seedling
+ use case needs to convey enough information so that someone, possibly other
+ than the outline writer, can easily go back and expand it into a more informative
+ use case. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Build an Actor-Goal list,
+ which is a list of actors and their goals that
+ gives you an overview of entire project needs.<strong></strong></p>
+<ul>
+ <li>
+ <p>Start by identifying the list of actors who will use the system, and then
+ identify at least one goal for each. Actors without goals indicate that
+ you haven’t adequately defined the system. The actor is beyond the system’s
+ scope, doesn’t belong in the system, or is part of another actor. </p>
+ </li>
+ <li>
+ <p>Likewise, leftover goals can indicate that the system is too complex and
+ you're trying to accomplish too much, or that you haven’t adequately defined
+ all of the necessary actors. Carefully evaluate the leftovers to see if
+ you are just overlooking some detail, or whether they don’t belong in the
+ system. </p>
+ </li>
+ <li>
+ <p>Remove unassociated actors and goals from the list. </p>
+ </li>
+</ul>
+<p> Sometimes, this list may provide enough information to serve as use cases
+ for very small, high-communicating, low-ceremony project teams. Usually, the
+ actor goal list is the first step of identifying use cases. </p>
+<h4>
+ Briefs
+</h4>
+<p> <strong>Context: </strong>You have written an Actor-Goal list that outlines
+ your use cases. </p>
+<p> <strong>Problem: </strong>Relying solely on an overview to capture the important
+ parts of a system’s behavior is dangerous, because it provides only high-level
+ information and can easily introduce ambiguity into a system. </p>
+<p> <strong>Forces: </strong></p>
+<ul>
+ <li>
+ <p><strong>Although valuable, an Actor-Goal list does not clearly describe
+ a system.</strong> Usually, an outline doesn’t provide enough precision
+ to avoid ambiguity, which can wreak havoc on a project by leading to unnecessary
+ or erroneous development. Yet, an outline is helpful, because you still
+ want an overview that you can easily scan. Unfortunately, with the passing
+ of time or sheer volume of work, it’s too easy to forget details
+ that were obvious to you earlier.</p>
+ </li>
+ <li>
+ <p><strong>Iterative use case development requires creating placeholders for
+ expansion.</strong> To develop use cases iteratively, you start with sparse
+ use cases, reorganize them, and flesh them out as the system takes shape.
+ Ideally, these placeholders should be clear enough to: 1) unambiguously
+ describe their role in the system, and 2) allow someone to expand the use
+ case, even if they were not involved in writing them originally. </p>
+ </li>
+ <li>
+ <p><strong>Because outlines are general by nature, do not spend a lot of time,
+ energy, or money writing them. </strong>Outlines provide an inexpensive
+ method of documenting complex ideas in a manner that is easy to follow,
+ and they provide a mechanism for people outside of a project to understand
+ the high-level concepts. While it may take
+ some effort to think things through, you don’t want to waste resources describing
+ your ideas. The system is still in a state of flux at this point, and it
+ is too early to spend much time documenting its shifting details. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Write two to four sentences per use case, capturing
+ key activities and key-extension handling. </p>
+<ul>
+ <li>
+ <p> Expand the Actor-Goal list into<strong> briefs</strong> by writing a two-
+ to four-sentence use cases for each entry in the list. </p>
+ </li>
+ <li>
+ <p>Briefly describe each use case’s main&nbsp;scenario and most important
+ extensions. </p>
+ </li>
+ <li>
+ <p> Include enough information to eliminate ambiguity for at least the main&nbsp;scenario
+ of the system. </p>
+ </li>
+</ul>
+<h4> Improvisational score</h4>
+<p> <strong>Context: </strong>You are operating in well-known domains or in situations
+ where writing high-ceremony use cases would require all of your allotted development
+ time. </p>
+<p> <strong>Problem:</strong> Writing formal, high-ceremony use cases when lesser
+ detail would suffice wastes time and resources. </p>
+<p> Jazz is considered to be “musician’s music,” and jazz players are usually
+ highly skilled. Many jazz musicians prefer to improvise in small, highly skilled
+ teams, such as jazz quartets. To improvise effectively, the musicians must have
+ a thorough understanding of the conventions that form the given musical style,
+ including chord sequences, rhythmic patterns, and melodies. These conventions
+ provide a basic framework for the musicians to interact as a team, while still
+ allowing room for spontaneous creativity. </p>
+<p> Likewise, use cases do not always need to be specified in excruciating detail.
+ A far-preferable strategy is simply to define the basic structure of what the
+ developers need to implement. The use cases act as placeholders that may be
+ elaborated later or simply improvised by the developer who implements the use
+ case. </p>
+<p> <strong>Forces:</strong></p>
+<ul>
+ <li>
+ <p><strong>Briefs do not provide enough information. </strong>While useful,
+ use-case briefs describe only the more significant parts of behavior. Often,
+ developers need more information, especially when working in unfamiliar
+ domains or in the heart of the system, where the actor has many choices
+ to make and many paths to follow. Briefs do not describe all of the important
+ events that can happen, nor do they describe the details that go into making
+ choices along the way. </p>
+ </li>
+ <li>
+ <p><strong>Fully elaborated use cases can be too expensive, time consuming,
+ long to write, and boring to read. </strong>It
+ takes a lot of time and effort to write a formal, fully descriptive set
+ of use cases. Maintaining this set takes even longer. Often, a collection
+ of use cases reaches the point of diminishing returns long before it is
+ completely written, much less formalized. Readers often prefer shorter,
+ simpler use cases over long, complicated ones, because overly detailed use
+ cases can be overwhelming and, frankly speaking, quite boring. </p>
+ </li>
+ <li>
+ <p><strong>Many groups communicate well enough to
+ resolve ambiguities on the fly. </strong>While briefs may be insufficient,
+ stakeholders don’t always need everything to be spelled out for them. Developers
+ are usually capable of asking questions and filling out the necessary detail
+ from their own domain knowledge. Many people can work with a fair level
+ of ambiguity, and most organizations possess what is often referred to as
+ their “core competencies.” Mature organizations with strong domain knowledge
+ can survive, and even thrive, using more informal, less precise use cases.
+ </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Specify the use cases at
+ a low level of precision, allowing the developers to fill in the missing details
+ as necessary. The level of precision required depends on the background experiences
+ of the development team. Skip the less meaningful fields on the template, and
+ write the Main Scenario section as a simple paragraph.
+ Describe key-extension handling in the next paragraph
+ or two. Be prepared to resolve ambiguities and expand detail on the fly throughout
+ the project. </p>
+<p> When you can rely upon open and frequent communication among the developers
+ and customer, write the use case with less detail and precision. The developers
+ can fill in the gaps by asking users or by using knowledge of the domain. However,
+ the developers need a thorough understanding of the business context to be able
+ to fill out the details themselves. Even the most knowledgeable developer will
+ still need access to the customers and users to get answers to questions and
+ clarify requirements. </p>
+<p> Ideally, the project will be structured to enable effective communication
+ between the customer and the developers. Typically, this will involve having
+ a small, co-located team, with the developers having easy access to the users
+ throughout the project. The risk of misunderstanding can be resolved by frequent
+ incremental delivery if the development organization
+ has a relatively low-ceremony culture. </p>
+<p> Jazz improvisation does not always work. It can become tedious and unpleasant
+ to listen to, even for the committed connoisseur.
+ For this reason, you also need feedback from the audience to determine the success
+ of the improvisations. Multi-level or two-tier reviews are critical to success
+ (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline:
+ Effective Requirement Reviews</a>). </p>
+<p> Improvisation may not always be suitable for the organizational culture, a
+ full <strong>symphonic score</strong> may be preferable in large, high-ceremony
+ teams (see section that follows). For instance,
+ I once watched a conductor toss his baton away in disgust when a pianist improvised
+ to such an extent that the orchestra could not follow the score. If the organization
+ deems the risk of improvising to be unacceptably high, then you can specify
+ the use cases with a higher level of detail and precision. You could start with
+ a strategy of specifying low levels of detail and precision, and then adapt
+ as necessary. </p>
+<h4> Symphonic score </h4>
+<p> <strong>Context: </strong>Writing structure for high-ceremony situations,
+ such as when there are many developers or when development teams are geographically
+ dispersed. </p>
+<p> <strong>Problem: </strong>Writing low-ceremony use cases for high-ceremony
+ situations raises the risk of miscommunication to unacceptable levels. </p>
+<p> A conductor’s version of a symphonic score contains the music for the entire
+ orchestra, as well as any accompanying vocals. The parts to be performed by
+ different voices or instruments are written on a separate staff, with all of
+ the staves aligned, one above another. This score specifies each note and its
+ associated timing in precise detail, so that the orchestra can perform a symphony
+ as the composer intended. </p>
+<p> As with use cases, a score tells the musician what to play, not how to play
+ it. For most symphonies, the orchestra will not be able to meet the composer,
+ so instead, they must rely upon the director to interpret the
+ score and the composer's intentions. </p>
+<p> <strong>Forces: </strong></p>
+<ul>
+ <li>
+ <p><strong>Certain development situations and cultures require high degrees
+ of formality. </strong>Some organizations operate in a highly formal manner,
+ thus require a highly formal process. While this formality may not
+ be desirable, it is the company's way of doing business, so things need
+ to be done that way. Other organizations are highly formal because they
+ do highly complex, life-critical work, where even small failures could have
+ disastrous consequences. For instance, no one would feel comfortable flying
+ on an airliner with an off-the-shelf, one-size-fits-all flight management
+ system. </p>
+ </li>
+ <li>
+ <p><strong>The cost of repairing miscommunication
+ is high. </strong>It is easy to write vague, inadequate use cases full of
+ ambiguity. Use cases can be too brief and ambiguous, or contain domain-specific
+ details that may be beyond the understanding of many stakeholders. Either
+ way, they provide an opportunity for a misunderstanding that leads to an
+ incorrect implementation. The cost of correcting these mistakes depends
+ on when they are discovered. <em>Earlier</em> is cheaper than<em> later</em>,
+ especially when later means customers finding the problem in the delivered
+ product. To avoid miscommunication, aim to write use cases that are general
+ enough for all of the stakeholders to follow, yet precise enough for the
+ developers to use when building the system. </p>
+ </li>
+ <li>
+ <p><strong>Developers need detail for implementing steps, business rules,
+ data fields, and, especially, for handling extensions. </strong>No one has
+ developed a program that can take a set of use cases as input, and churn
+ out a completed system. Even the best-case tools seem to require human intervention
+ to flesh out details and resolve ambiguities. Similarly, developers who
+ do not understand the business context or lack domain expertise may not
+ be able to fully comprehend a product. In an ideal project, software developers
+ would have access to the domain experts to ask questions, so they could
+ fill in any areas that may have been missed (see<em> Improvisational score</em>,
+ previously). But often, they do not ask. Therefore, they misunderstand the
+ more complex or ambiguous use cases in the set. To develop a system correctly,
+ a team needs either access to domain experts or additional information that
+ describe the steps, business rules, data fields, and extension handling
+ that they are implementing. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Specify your use cases with a high level of precision,
+ explicitly filling in all of the details in the use case template, while staying
+ technology-neutral. The level of precision required depends on the background
+ experiences of the development team. </p>
+<p> Intuition may tell you that if some detail is good, then more must be better.
+ However, be careful about falling into the trap of over-specifying details.
+ It’s naive to believe that everyone who reads your use cases will be able to
+ understand them. Different people may interpret the use cases differently. Prepare
+ for this eventuality in your process, and avoid the tendency to over-specify
+ your use cases. If you try to specify a use case in too much detail, you may
+ fall into the classic analysis paralysis trap. </p>
+<p> People are often tempted to address the communication problem by trying to
+ explain the business domain within the use cases. In a similar manner, they
+ include too much technical detail. Succumbing to these temptations by explaining
+ the business domain or including technical details is always a mistake, because
+ it complicates the process and obfuscates the requirements. The reader of the
+ use cases cannot distinguish the real requirements from the boring background
+ information, so will soon get distracted and lose interest. Instead, include
+ this information in an extra section. </p>
+<p> If you are handing over the requirements to a development team whose members
+ are unfamiliar with the domain, then you will need an alternative strategy for
+ teaching them the domain knowledge. </p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/using_patterns.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/using_patterns.xmi
new file mode 100644
index 0000000..986aaff
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/using_patterns.xmi
@@ -0,0 +1,37 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-U-5cLUk-mdaO518lh5CxTQ" name="using_patterns,_0cr7cACrEdu8m4dIntu6jA" guid="-U-5cLUk-mdaO518lh5CxTQ" changeDate="2006-09-21T15:38:16.868-0700" version="1.0.0">
+ <mainDescription><p>
+ In software design, it is primarily the development method and not the pattern and its pattern language that influences
+ the process of pattern selection and use. As discussed in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/patterns,_0YJvUMlgEdmt3adZL5Dmdw.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Patterns</a>, Alexander developed the concept of generative pattern languages
+ to guide a designer’s application of individual patterns to the entire design. In software design, however, as
+ Alexander observed [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">OOP96</a>] there is little evidence of using generative pattern languages.
+</p>
+<p>
+ For iterative development methods, software patterns and pattern languages support the development method through their
+ ability to be applied incrementally, or by piecemeal growth, and by providing extensible structures. From an
+ architectural perspective, these two qualities allow software architecture to be designed and refactored incrementally,
+ thus so avoid the need for a so-called "big, up-front design."
+</p>
+<h4>
+ Piecemeal growth
+</h4>
+<p>
+ The term <strong>piecemeal growth</strong>, as it applies to patterns, originates in Alexander's work. It refers to a
+ top-down design process in which a design starts from a high-level structure that is embellished or refined through the
+ implementation of lower-level patterns. For software development, this corresponds to using hierarchies of
+ architectural and design patterns and idioms like those proposed by Buschmann et. al. [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>]. Using the idea of piecemeal growth, an architect can start with one or more
+ architectural patterns to provide an architectural vision for the design, and then progressively extend the design
+ using design patterns. For example, an interactive application may use the Model-View-Controller pattern as its
+ architectural vision, then during implementation the Command pattern may be selected to implement the Controller
+ component.
+</p>
+<h4>
+ Extensibility
+</h4>
+<p>
+ A key aspect of object oriented design patterns is their ability to support extension without causing the rewriting of
+ existing code. This feature allows a bottom up approach to the design process through code refactoring. When a problem
+ is encountered during coding such as duplicate code, the developer can weighed up various patterns and their tradeoffs
+ and select the appropriate solution in the context of the application.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/work_items_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/work_items_list.xmi
new file mode 100644
index 0000000..978108a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/work_items_list.xmi
@@ -0,0 +1,136 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-G1Oxlk6F0R09vClqy1EzOw" name="work_items_list,_7vEXEMA4EdqSgKaj2SZBmg" guid="-G1Oxlk6F0R09vClqy1EzOw" changeDate="2006-08-31T13:22:12.278-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;captures all scheduled work to be done within the
+ project, as well as proposed work that may affect the product. Some of the Work Items may be implemented in this
+ project, some of them may be implemented in a future project, and some of them may never be implemented.
+</p>
+<p>
+ Some of the work items may still be poorly defined, representing a big chunk of work requiring potentially several
+ staff months of effort. As the priority of these work items increase, they are typically decomposed into smaller work
+ items that represent specific and well-defined tasks that may take hours or days to address. In other cases, specific
+ and well-defined work items are created directly, representing for example a defect to be addressed, see Figure 1.
+</p>
+<br />
+<img height="369" alt="work item list overview" src="./resources/wil_overview.bmp" width="600" /><br />
+<br />
+<p>
+ <strong><em>Figure 1. Work Items List provides one prioritized list of scheduled and proposed work.</em></strong>
+</p>
+<p>
+ A Work Item may represent work associated with a defect, enhancement request, use case, scenario, user story,
+ supporting requirement, or anything else that captures a potential requirement or improvement to your system. A Work
+ Item may reference any type of requirement, defect, enhancement request, or other useful information guiding you in
+ what needs to be done.
+</p>
+<p>
+ A big advantage with the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;is that it enables you to prioritize only one list
+ containing all the things that may need to be addressed, whether the work item represent a work related to a
+ requirement, enhancement, or defect. The one exception is that we separately prioritize the risk list.
+</p>
+<p>
+ Nothing in the project will get done if not represented or mapped to a Work Item. This means that all requirements,
+ defects and change requests have to at some stage be mapped to a work item. Also, a developer will not take on work
+ that is not represented in a Work Item. Only Work Items needs to be prioritized. This also means that tracking Work
+ Items are a primary means of understanding status of the project.
+</p>
+<p>
+ There are two major types of Work Items:
+</p>
+<ul>
+ <li>
+ <strong>Un-scheduled Work Items:</strong> These Work Items have not yet been assigned to an iteration, and there is
+ no detailed effort estimate for the Work Item yet.
+ </li>
+ <li>
+ <strong>Scheduled Work Items:</strong> These Work Items are assigned to an iteration, and typically have an
+ additional set of attributes filled in, such as detailed effort estimates.
+ </li>
+</ul>
+<h3>
+ Un-scheduled Work Items
+</h3>
+<p>
+ Most Work Items are initially un-scheduled, meaning that it has not yet been decided whether to do them, and when to do
+ them. Unscheduled Work Items should always represent something meaningful to deliver to stakeholders, such a scenario
+ to be detailed, designed, implemented and tested. You may consider capturing the following data for such Work Items:
+</p>
+<ul>
+ <li>
+ Name
+ </li>
+ <li>
+ Description
+ </li>
+ <li>
+ Priority
+ </li>
+ <li>
+ Size estimate, such as a point estimate, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+ </li>
+ <li>
+ State, such as New, Assigned, Resolved, Verified, Closed, see Work Items States below
+ </li>
+ <li>
+ Links to other reference material, such as requirements or detailed specifications of what needs to be done
+ </li>
+</ul>
+<h3>
+ Scheduled Work Items
+</h3>
+<p>
+ Once a Work Item has been assigned to an iteration, it becomes scheduled. Note that we only assign Work Items to the
+ current or next iteration. There is no point in assigning Work Items to a specific future iteration, since we cannot
+ predict what a meaningful schedule will be more than an iteration in advance, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/iteration_planning,_0auiMMlgEdmt3adZL5Dmdw.html" guid="_0auiMMlgEdmt3adZL5Dmdw">Guideline: Iteration Planning</a>.
+</p>
+<p>
+ The following additional attributes are useful for Scheduled Work Items:
+</p>
+<ul>
+ <li>
+ Target iteration
+ </li>
+ <li>
+ Responsible team member
+ </li>
+ <li>
+ Effort estimate left, such as actual hours of work, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+ </li>
+ <li>
+ Hours worked
+ </li>
+</ul>
+<p>
+ This provides the information required to plan and manage an iteration. We can plan iterations by understanding effort
+ involved and we can do <a class="elementLinkWithType" href="./../../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> by tracking how much work is left.
+</p>
+<h3>
+ Work Items States
+</h3>
+<p>
+ We have found the following states to be useful to track Work Items:
+</p>
+<ul>
+ <li>
+ New: Work Item has been created, but not yet assigned to a team member.
+ </li>
+ <li>
+ Assigned: A team member has been identified as responsible for the Work Item.
+ </li>
+ <li>
+ Resolved: The team member responsible for the work items has implemented and tested the Work Item.
+ </li>
+ <li>
+ Verified: The Work Item has been independently tested.
+ </li>
+ <li>
+ Closed: The Work Item is no longer active.
+ </li>
+</ul>
+<p>
+ You may choose another set of states, based on your needs.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/writing_good_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/writing_good_requirements.xmi
new file mode 100644
index 0000000..6736533
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/guidelines/writing_good_requirements.xmi
@@ -0,0 +1,94 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-AJQLv2ldVv5KN9eUbdQe_g" name="new_guideline,_6jXzYNcKEdqz_d2XWoVt6Q" guid="-AJQLv2ldVv5KN9eUbdQe_g" changeDate="2006-05-01T15:33:21.329-0700" version="1.0.0">
+ <mainDescription><P>To write a good requirement,
+ you must write it<strong> </strong>as a complete sentence, with a subject
+ and a predicate (usually a verb). The subject&nbsp;is
+ an Actor, a stakeholder, the system under development, or a design entity that
+ is related to the requirement. The predicate specifies a condition, action,
+ or intended result that is done for, by, with, or to the subject.</P>
+<P>Consistent use of the verb <strong>to be </strong>solidifies
+ the link between the subject and the predicate.<strong>
+ </strong>Thus, you can analyze a requirement from
+ a grammatical point of view. </P>
+<P>Beware of lists, bullets, and words such as <strong>all</strong>, <strong>every</strong>and <strong>some</strong>. For example:<strong> </strong></P>
+<blockquote>
+ <p>The order entry clerk must<strong> </strong>be
+ able to complete 10 customer orders in less than two hours.</p>
+</blockquote>
+<P>This requirement has a subject (the order entry clerk, who<strong>
+ </strong>is an Actor), a specific and measurable
+ end state (10 customer orders completed), and a performance criterion
+ (in less than two hours).</P>
+<P>Follow these simple guidelines<strong> </strong>
+ in writing any requirement. For consistency, these examples
+ are all in the context of an aircraft. [[WAS: is used throughout.]] <a class=elementlinkwithusertext href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</P>
+<ul>
+ <li>Define one requirement at a time.
+ <blockquote>
+ <p>The pilot shall be able to control the aircraft's angle of climb with
+ one hand.</p>
+ </blockquote>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p> The pilot shall be able to feel the angle of climb from the climb control.</p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>Avoid conjunctions (and, or) that make multiple requirements. </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p>The navigator shall be able to view the aircraft's position relative to
+ the route's radio beacons. </p>
+ <p>The navigator shall be able to view the aircraft's position as
+ estimated by inertial guidance.</p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>Avoid let-out clauses or words that imply options
+ or exceptions (unless, except, if necessary, but). </li>
+ <blockquote>
+ <p>The design shall provide a rear-facing seat
+ for each cabin crew member.</p>
+ </blockquote>
+ <li>Use simple, direct sentences. </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>The pilot shall be able to see<strong> </strong>the
+ airspeed indicator.</p>
+ </blockquote>
+ <li>Use a limited (500-word) vocabulary, especially if your audience is international.
+ <blockquote>
+ <p>The airline shall be able to convert the
+ aircraft from business to holiday charter use in less than 12 hours </p>
+ </blockquote>
+ </li>
+ <blockquote>
+ <p><strong>Note: </strong>There is no need to use words such
+ as <strong> reconfigured. </strong></p>
+ </blockquote>
+ <li>Identify the type of user who needs each requirement.
+ </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>The navigator shall be able to...</p>
+ </blockquote>
+ <li>Focus on stating what result you will provide<strong>
+ </strong> for that type of user. </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>...view storm clouds by radar...</p>
+ </blockquote>
+ <li>Define verifiable criteria
+ <blockquote>
+ <p> ...at least 100 miles ahead.</p>
+ </blockquote>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/iteration_burndown.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/iteration_burndown.xmi
new file mode 100644
index 0000000..158a166
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/iteration_burndown.xmi
@@ -0,0 +1,37 @@
+<?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" epf:version="1.0.0" xmi:id="-Aw8p59vJ9rWsOV82rljQiQ" name="iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA" guid="-Aw8p59vJ9rWsOV82rljQiQ" changeDate="2006-11-03T07:59:14.929-0800" version="1.0.0">
+ <mainDescription><p>
+ The iteration burndown is&nbsp;the primary tool for understanding the status of the current iteration. It shows the
+ trend for how much work is left to do within the iteration. This is accomplished by adding up the estimated effort left
+ for each of the work items to be addressed within the iteration, and showing how the estimated effort is changing over
+ the duration of the iteration. The iteration backlog should be updated frequently, preferably on a daily basis.
+</p>
+<p>
+ Factors that impact the team’s assessment of how much work remains include:
+</p>
+<ul>
+ <li>
+ Work that has been completed, which means there is less work remaining.
+ </li>
+ <li>
+ The developer responsible for a work item changes the assessment of effort required to complete the work item. This
+ should be expected, since we typically understand what it really takes to complete a task after we have done a
+ subset of the task.&nbsp;It's common for estimates of the work remaining to increase in the beginning of the
+ iteration, especially for inexperienced teams, since they often underestimate efforts. Expect estimates to continue
+ changing as teams become more experienced, but the modifications are as frequently upward as downward.
+ </li>
+ <li>
+ Estimated effort left can increase during the iteration as a result of the team learning more about what needs to
+ be done.
+ </li>
+</ul>
+<p>
+ Daily or frequent updates to the iteration burndown allows the team to react to changes. For example, cutting scope by
+ removing work items from the iteration, reducing the ambition level associated with a work item, or finding better ways
+ of approaching work items such as having an expert team member help out with difficult work items.
+</p>
+<p>
+ See <a href="./resources/ex_iteration_burndown.xls" target="_blank">ex_iteration_burndown.xls</a> for an example
+ iteration burndown report.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/project_burndown.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/project_burndown.xmi
new file mode 100644
index 0000000..ded8e71
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/project_burndown.xmi
@@ -0,0 +1,18 @@
+<?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" epf:version="1.0.0" xmi:id="-hrDndmFd0zexB0HNYX3gww" name="project_burndown,_ePrt8Dj3EduxovfWMDsntw" guid="-hrDndmFd0zexB0HNYX3gww" changeDate="2006-09-25T17:07:38.314-0700" version="1.0.0">
+ <mainDescription><p>
+ Project burndown is usually communicated in graphical form.&nbsp;Project burndown is very useful to quickly communicate
+ the overall project progress based on actual data and to diagnose a trend for the remainder of the project.&nbsp;
+</p>
+<p>
+ The project burndown chart consists of two perspectives, the horizontal axis showing the iterations and the vertical
+ axis indicating the remaining points from the work items list. Additionally the average burndown from previous
+ iterations is calculated and a trend for the remainder of the project diagnosed and forecasted.
+</p>
+<p>
+ Project burndown management is a enabling technique that allows direct linkage of iteration goals to work items. The
+ project manager will use the project burndown information for communicating progress and trend to senior management.
+</p>
+See <a href="./resources/ex_project_burndown.xls" target="_blank">ex_project_burndown.xls</a>&nbsp;for an example of
+project burndown.<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls
new file mode 100644
index 0000000..67cb1b6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/resources/ex_project_burndown.xls b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/resources/ex_project_burndown.xls
new file mode 100644
index 0000000..e63fef8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/reports/resources/ex_project_burndown.xls
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/openup_basic_roadmap.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/openup_basic_roadmap.xmi
new file mode 100644
index 0000000..14d37ea
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/openup_basic_roadmap.xmi
@@ -0,0 +1,194 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-At_b3UIzbgdmtJsb2Ymfhg" name="new_roadmap,_vEruwN-rEdqiM_wFaqLjNg" guid="-At_b3UIzbgdmtJsb2Ymfhg" changeDate="2007-03-01T10:29:08.857-0800" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ OpenUP/Basic is for small teams, working together in the same location. The team needs to engage in plenty of daily
+ face-to-face interaction. Team members include the stakeholders, developers, architects, project manager, and testers.
+ Team members engage in significant collaboration, making their own decisions as to what needs to be worked on, what the
+ priorities are, and how best to address stakeholder needs. The organization must support the team by allowing them this
+ responsibility.
+</p>
+<p>
+ Team members collaborate extensively. The presence of stakeholders as team members is critical to successfully
+ realizing OpenUP/Basic.
+</p>
+<p>
+ Team members participate in daily stand-up meetings to communicate status and issues. Problems are addressed outside of
+ the daily meetings.
+</p>
+<p>
+ OpenUP/Basic focuses on signficantly&nbsp;reducing risk early in the lifecycle. This requires regular risk review
+ meetings and rigorous implementation of mitigation strategies.
+</p>
+<p>
+ All work is listed, tracked, and assigned through the Work Item List. Team mebers use this single repository for all
+ tasks that need to be recorded and tracked. This includes all change requests, bugs, and stakeholder requests.
+</p>
+<p>
+ Use cases are used to elicit and describe requirements. Team members should develop skills at writing good use cases.
+ Stakeholders are responsbile for reviewing and certifying the requirements are correct. Use cases are developed
+ collaboratively.
+</p>
+<p>
+ Architecturally significant requirements must be identified and stabilized in Elaboration so a robust architecture can
+ be created that is the core of the system. An architecturally significant requirement change may arise later in
+ development that must be addressed, but the risk of this happening is significantly reduced in the Elaboration
+ iteration.
+</p>
+<p>
+ Testing is performed....
+</p>
+<p>
+ OpenUP/Basic doesn't include content for deployment, change management, or environment (such as customizing this
+ process or setting up development environments). OpenUP/Basic is focused on a singe team, and these areas are generally
+ addressed at an organizational or enterprise level. Look for extensions to OpenUP that address these wider areas.<br />
+</p>
+<p>
+ OpenUP/Basic is an iterative software development process that is minimal, complete, and extensible. It is governed by
+ four core <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA">principles</a>:
+</p>
+<ul>
+ <li>
+ Balance competing priorities to maximize stakeholder value.
+ </li>
+ <li>
+ Collaborate to align interests and share understanding
+ </li>
+ <li>
+ Evolve to continuously obtain feedback and improve
+ </li>
+ <li>
+ Focus on articulating the architecture
+ </li>
+</ul>
+<p>
+ <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">Roles</a>&nbsp;perform <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> that consume and produce <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/artifact,_x7cUM9nmEdmO6L4XMImrsA.html"
+ guid="_x7cUM9nmEdmO6L4XMImrsA">artifacts</a>. OpenUP/Basic describes the minimal set of&nbsp;roles, tasks, and
+ artifacts&nbsp;involved in software development:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ">Tasks</a> (organized by disciplines)
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg">Artifacts</a> (organized by domains)&nbsp;
+ </li>
+</ul>
+<h3>
+ Software development&nbsp;lifecycle
+</h3>
+<p>
+ OpenUP/Basic is an iterative process&nbsp;distributed throughout&nbsp;four <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html"
+ guid="__7xOEC7aEdqHMdmRzC0-2g">phases</a>: Inception, Elaboration, Construction, and Transition. Each phase consists of
+ one or more iterations, where stable, working versions of the software are developed and released, with the completion
+ of each iteration representing a minor <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">milestone</a>&nbsp;for the project and contributing to the successful achievement of the
+ Phase's major milestone where phase objectives are met.
+</p>
+<p>
+ The following diagram depicts the OpenUP/Basic <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">lifecycle</a>.
+</p>
+<p align="center">
+ <img height="192" alt="Figure 1: Diagram of the OpenUP/Basic Lifecycle" src="./resources/openup-basic_lifecycle.jpg"
+ width="667" usemap="#Map" border="0" />
+</p>
+<p align="center">
+ Figure 1: The OpenUP/Basic lifecycle
+</p>
+<map id="Map" name="Map">
+ <h4>
+ How&nbsp;to get started?
+ </h4>
+ <p>
+ The fourth OpenUP core principle, "Evolve to continuously obtain feedback and improve", suggests an iterative and
+ incremental approach to adopting OpenUP/Basic.
+ </p>
+ <ul>
+ <li>
+ Start with the core principles and understand the intentions behind OpenUP.
+ </li>
+ <li>
+ Then assess your existing process, and select one or two key areas that you would like to improve.
+ </li>
+ <li>
+ Begin using OpenUP/Basic to improve these areas first.
+ </li>
+ <li>
+ In later iterations or development cycles, make incremental improvements in other areas.
+ </li>
+ <li>
+ If you have little or no experience with unified processes or other iterative processes, use OpenUP/Basic in a
+ small pilot project, perhaps with only three to four people working for only two to three months.
+ </li>
+ </ul>
+ <p>
+ While OpenUP/Basic is a ready to use as-is, you may choose to extend the process or modify the work product
+ templates to suit your specific needs. For example:
+ </p>
+ <ul>
+ <li>
+ You may require more or less precision in your work products.
+ </li>
+ <li>
+ Your organization may have specific configuration management practices or safety protocols to include in your
+ process.
+ </li>
+ <li>
+ You may simply want to put your own corporate logo on the banner.
+ </li>
+ <li>
+ You may want to incorporate lessons learned from a retrospective review into OpenUP/Basic.
+ </li>
+ </ul>
+ <p>
+ Use EPF Composer to extend and tailor OpenUP/Basic. For more information about EPF composer, visit <a
+ href="http://www.eclipse.org/epf" target="_blank">www.eclipse.org/epf</a>.
+ </p>
+ <area shape="RECT" coords="116,7,175,25" alt="link to inception phase concept"
+ href="./../../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="255,11,327,27" alt="link to elaboration phase concept"
+ href="./../../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="395,11,476,27" alt="link to construction phase concept"
+ href="./../../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="554,10,619,27" alt="link to transition phase concept"
+ href="./../../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="39,98,100,162" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/inception_phase_iteration,_xupMvxOKEduCNqgZdt_OaA.html"
+ guid="_xupMvxOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="188,99,250,168" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="332,100,397,165" alt="link to construction phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="480,98,541,167" alt="link to transition phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/transition_phase_iteration,_467NIhOKEduCNqgZdt_OaA.html"
+ guid="_467NIhOKEduCNqgZdt_OaA" />
+</map></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/resources/OpenUp2_504.JPG b/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/resources/OpenUp2_504.JPG
new file mode 100644
index 0000000..b21a8a2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/resources/OpenUp2_504.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg
new file mode 100644
index 0000000..4719cad
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/about_openup_basic.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/about_openup_basic.xmi
new file mode 100644
index 0000000..23cb0fc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/about_openup_basic.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="-WFD3nKccpkueaG15cHT-fA" name="new_supporting_material,_8tSNMPGYEdqiDINUyockoA" guid="-WFD3nKccpkueaG15cHT-fA" changeDate="2006-09-27T16:25:47.645-0700" version="1.0.0">
+ <mainDescription><h3>
+ <a id="version" name="version">Version Information</a>
+</h3>
+<p>
+ OpenUP/Basic Plug-in Version 0.9<br />
+ Based on: Base Concepts Plug-in Version: 0.9
+</p>
+<h3>
+ Legal Statement
+</h3>
+<p class="node">
+ See <a href="./resources/copyrite.htm">Intellectual Property Notices</a>.
+</p>
+<h3>
+ Browser Support
+</h3>
+<p>
+ <b>Note 1:</b> OpenUP/Basic does not currently support Netscape Navigator 6.x.
+</p>
+<p>
+ <b>Note 2:</b> Some versions of Microsoft Internet Explorer 4.x and Netscape Navigator 4.x may not be able to display
+ all pages of OpenUP/Basic.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/copyright_oup.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/copyright_oup.xmi
new file mode 100644
index 0000000..381de26
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/copyright_oup.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-PZ0CqCcJHB-nbxs8fbP7bg" name="new_supporting_material,_cTs20KzREduOqvpk_MDLfQ" guid="-PZ0CqCcJHB-nbxs8fbP7bg" changeDate="2007-01-25T16:09:53.285-0800">
+ <mainDescription><p>
+ View copyright information here:&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/supportingmaterials/openup_copyright,_UaGfECcTEduSX6N2jUafGA.html"
+ guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/delivery_process_graph.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/delivery_process_graph.xmi
new file mode 100644
index 0000000..13eac63
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/delivery_process_graph.xmi
@@ -0,0 +1,30 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-cy0DcnEk7uJJ1OOH3_E6rg" name="new_supporting_material,_Pt_fYBjoEduxUfEVCtmW4Q" guid="-cy0DcnEk7uJJ1OOH3_E6rg" changeDate="2006-07-21T11:39:59.312-0700">
+ <mainDescription><img height="192" alt="OpenUP/Basic Lifecycle" src="./resources/openup-basic_lifecycle.jpg" width="667" usemap="#Map"
+border="0" /> <map id="Map" name="Map">
+ <area shape="RECT" coords="116,7,175,25" alt="link to inception phase concept"
+ href="./../../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="255,11,327,27" alt="link to elaboration phase concept"
+ href="./../../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="395,11,476,27" alt="link to construction phase concept"
+ href="./../../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="554,10,619,27" alt="link to transition phase concept"
+ href="./../../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="39,98,100,162" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/inception_phase_iteration,_xupMvxOKEduCNqgZdt_OaA.html"
+ guid="_xupMvxOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="188,99,250,168" alt="link to elaboration phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="332,100,397,165" alt="link to construction phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="480,98,541,167" alt="link to transition phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/transition_phase_iteration,_467NIhOKEduCNqgZdt_OaA.html"
+ guid="_467NIhOKEduCNqgZdt_OaA" />
+</map></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/openup_basic_home.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/openup_basic_home.xmi
new file mode 100644
index 0000000..3669540
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/openup_basic_home.xmi
@@ -0,0 +1,150 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-XR2Rbg25yN80p1exWC4MHg" name="intro_to_openup_basic,_i-BDsNogEdqfmNgIq7q3Xw" guid="-XR2Rbg25yN80p1exWC4MHg" changeDate="2006-09-29T10:56:32.453-0700" version="1.0.0">
+ <mainDescription><table>
+ <tbody>
+ <tr>
+ <td>
+ <table width="100%" border="0">
+ <tbody>
+ <tr>
+ <td width="58%">
+ <div align="center">
+ <table width="589" align="center" border="0">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <img height="48" alt="getting started" src="./resources/GetStarted_48.gif" width="48" usemap="#Map" border="0" />
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <img height="48" alt="core principles" src="./resources/CorePrinciples_48.gif" width="48" usemap="#Map2" border="0" />
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <img height="48" alt="roles" src="./resources/Roles_48.gif" width="48" usemap="#Map3" border="0" />
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <img height="48" alt="work products" src="./resources/WorkProducts_48.gif" width="48" usemap="#Map4" border="0" />
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <img height="48" alt="disciplines" src="./resources/Disciplines_48.gif" width="48" usemap="#Map5" border="0" />
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <img height="48" alt="lifecycle" src="./resources/LifeCycle_48.gif" width="48" usemap="#Map6" border="0" />
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/customcategories/getting_started,_cp6ycBOGEduCNqgZdt_OaA.html" guid="_cp6ycBOGEduCNqgZdt_OaA">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" guid="_HEu9QBOHEduCNqgZdt_OaA">Core Principles</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html" guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html" guid="_s4Z9AMWXEdqWePvIjHInwg">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html" guid="__BZycP1UEdmek8CQTQgrOQ">Disciplines</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">Lifecycle</a>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ &nbsp;
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <p>
+ OpenUP/Basic is organized into four major areas of content, Communication&nbsp;and Collaboration,
+ Intent, Solution, and Management, also known as sub-processes.
+ </p>
+ <br />
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ <img height="350" alt="Four major areas upon which the OpenUP/Basic content is organized" src="./resources/OpenUp1_350.jpg" width="350" usemap="#Map7" border="0" /> <map id="Map7" name="Map7">
+ <area shape="RECT" alt="Stakeholder" coords="144,5,207,62" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ" />
+ <area shape="POLY" alt="Tester" coords="336,242,310,287,254,256,278,209" href="./../../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw" />
+ <area shape="RECT" alt="Developer" coords="148,282,201,347" href="./../../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmd" />
+ <area shape="POLY" alt="Architect" coords="66,199,14,232,40,283,96,249" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Project Manager" coords="11,118,68,146,99,91,50,52" href="./../../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Analyst" coords="258,99,312,66,338,114,284,145" href="./../../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw" />
+ <area shape="CIRCLE" alt="Communication and Collaboration" coords="176,176,47" href="./../../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Management" coords="85,219,70,163,115,89,169,72,169,117,124,144,120,197" href="./../../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Intent" coords="181,116,223,143,229,196,264,219,283,160,245,94,181,70" href="./../../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Solution" coords="129,211,176,235,221,210,257,231,214,271,133,272,94,232" href="./../../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" />
+ </map><br />
+ &nbsp;
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="left">
+ OpenUP/Basic is an iterative software development process with the following characteristics:
+ </p>
+ <div align="left">
+ <ul>
+ <li>
+ <strong>Minimal:</strong> Only fundamental process content is included
+ </li>
+ <li>
+ <strong>Complete:</strong> It can be manifested as an entire process to build a system
+ </li>
+ <li>
+ <strong>Extensible:</strong> It can be used as a foundation&nbsp;to add or tailor process
+ content
+ </li>
+ </ul>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ <map id="Map" name="Map">
+ <area shape="RECT" coords="0,1,47,47" alt="Getting Started" href="./../../../openup_basic/customcategories/getting_started,_cp6ycBOGEduCNqgZdt_OaA.html" />
+ </map><map id="Map2" name="Map2">
+ <area shape="RECT" coords="0,0,48,47" alt="Core principles" href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" />
+ </map><map id="Map3" name="Map3">
+ <area shape="RECT" coords="0,0,48,48" alt="Openup basic roles" href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html" />
+ </map><map id="Map4" name="Map4">
+ <area shape="RECT" coords="0,1,48,48" alt="Openup basic work product" href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html" />
+ </map><map id="Map5" name="Map5">
+ <area shape="RECT" coords="0,0,47,48" alt="Openup basic disciplines" href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html" />
+ </map><map id="Map6" name="Map6">
+ <area shape="RECT" coords="0,0,47,48" alt="Openup basic process" href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" />
+ </map>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/openup_copyright.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/openup_copyright.xmi
new file mode 100644
index 0000000..ab6b7f0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/openup_copyright.xmi
@@ -0,0 +1,12 @@
+<?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" epf:version="1.0.0" xmi:id="-RNyaB6jxqoopm9fJU8k9vg" name="new_supporting_material,_UaGfECcTEduSX6N2jUafGA" guid="-RNyaB6jxqoopm9fJU8k9vg" changeDate="2007-01-31T19:45:05.478-0500" version="1.0.0">
+ <mainDescription><p>
+ Copyright &copy; 1987, 2006 IBM Corp. All Rights Reserved.<br />
+ Copyright &copy; 2006 Telelogic AB. All Rights Reserved.<br />
+ Copyright &copy; 2006 Armstrong Process Group, Inc. All Rights Reserved.<br />
+ Copyright &copy; 2006 Number Six Software, Inc. All Rights Reserved.<br />
+</p>
+<p>
+ And others. All rights reserved
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/references.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/references.xmi
new file mode 100644
index 0000000..1df18e0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/references.xmi
@@ -0,0 +1,213 @@
+<?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" epf:version="1.0.0" xmi:id="-aCI9T-9TIe8D35yXBU6qvg" name="references,_9ToeIB83Edqsvps02rpOOg" guid="-aCI9T-9TIe8D35yXBU6qvg" changeDate="2007-03-13T15:43:56.164-0700" version="1.0.0">
+ <mainDescription><TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ADO03</a> </TD>
+<TD colSpan=2>Adolph, Bramble, Cockburn, and Pols <EM>Patterns for Effective Use Cases</EM>, Addison Wesley, 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ADO04</a> </TD>
+<TD colSpan=2>Adolph, Bramble, Cockburn, and Pols <EM>Tutorial 17: Patterns for Writing Effective Use Cases</EM>, presented at the 19th Annual Conference on Object-Oriented Programming, Systems, Languages and Applications, 2004.</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALE77</a> </TD>
+<TD colSpan=2>Alexander, C. <EM>A Pattern Language</EM>, Oxford University Press, 1977 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALE79</a> </TD>
+<TD colSpan=2>Alexander, C., <EM>A Timeless Way of Building</EM>, Oxford University Press, 1979 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALL02</a> </TD>
+<TD colSpan=2>Allamaraju, S. <EM>Architecture Paradox</EM>, <a href="http://www.sei.cmu.edu/architecture/essays.html">http://www.sei.cmu.edu/architecture/essays.html</a>. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALU03</a> </TD>
+<TD colSpan=2>
+<P>Alur, D., Crupi, J., Malks, D., <EM>Core J2EE Patterns: Best Practices and Design Strategies</EM>, Prentice Hall/Sun Press, 2001.</P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P>AMB02</P>
+<P>AMB03</P>
+<P>AMB04</P>
+<P>AMB06</P>
+<P><a name="">BOE88</a> </P></TD>
+<TD colSpan=2>
+<P>Ambler, S.W. <EM>Agile Modeling: Effective Practices for Extreme Programming and Unified Process</EM>. Wiley Publishing, 2002.</P>
+<P>Ambler, S.W. <EM>Agile Database Techniques: Effective Strategies for the Agile Software Developer</EM>.&nbsp; Wiley Publishing, 2003.</P>
+<P>Ambler, S.W. <EM>The Object Primer 3rd Edition: Agile Model Driven Development with UML 2</EM>. Cambridge University Press, 2004.</P>
+<P>Ambler, S.W. and Sadalage, P.J. <EM>Refactoring Databases: Evolutionary Database Design</EM>.&nbsp; Addison Wesley, 2006.</P>
+<P>Boehm, B., Papaccio, C. <EM>Understanding and Controlling Software Cost</EM>, IEEE Trans. on Software Engineering, Oct. 1988. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BOE95</a> </TD>
+<TD colSpan=2>Boehm, B. <EM>Anchoring the Software Process</EM>, <a href="http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf">http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P>BRO95</P></TD>
+<TD colSpan=2>
+<P>Brooks, F.P <EM>The Mythical Man Month: Essays on Software Engineering, 20th Anniversary Edition</EM>.&nbsp;Addison Wesley Professional, 1995. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BOO05</a> </TD>
+<TD colSpan=2>Booch, G., Rumbaugh, J., Jacobson, I.<EM>The Unified Modeling Language User Guide</EM>, Addison-Wesley Professional, 2005</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BUS96</a> </TD>
+<TD colSpan=2>Buschmann, F., Meunier, R., Rohnert, H.,Sommerlad, P., Stal, M., <EM>Pattern-Oriented Software Architecture -- A System of Patterns</EM>, Wiley, 1996. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P><a name="">COH05</a>&nbsp;</P>
+<P><a name="">COP95</a> </P></TD>
+<TD colSpan=2>
+<P>Cohn, M. <EM>Agile Estimation and Planning</EM>, Addison Wesley Longman, 2005 </P>Coplien, J., Schmidt, D., <EM>Pattern Languages of Program Design</EM>,Addison-Wesley Professional, 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">COP95</a> </TD>
+<TD colSpan=2>Coplien, J., Schmidt, D., <EM>Pattern Languages of Program Design</EM>,Addison-Wesley Professional, 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">CRO79</a> </TD>
+<TD colSpan=2>Crosby, Philip. <EM>Quality is Free: The Art of Making Quality Certain</EM>, McGraw-Hill, 1979. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAM95</a> </TD>
+<TD colSpan=2>Gamma, E., Helm, R., Johnson, R., Vlissides, J., <EM>Design Patterns: Elements of Reusable Object-Oriented Software</EM>, Addison-Wesley Professional; 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAB98</a> </TD>
+<TD colSpan=2>Gabriel, Richard P., <EM>Patterns of Software: Tales from the Software Community</EM>, Oxford University Press, 1998. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAR93</a> </TD>
+<TD colSpan=2>David Garlan and Mary Shaw. <EM>An Introduction to Software Architecture</EM>,&nbsp; SEI Technical Report CMU/SEI-94-TR-21.&nbsp; </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">HIC03</a> </TD>
+<TD colSpan=2>Hickey A., Davis, A. <EM>Elicitation Technique Selection: How Do the Experts Do It?</EM>, International Conference on Requirements Engineering (RE03), Los Alamitos, California: IEEE Computer Society Press, September 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">HUL05</a> </TD>
+<TD colSpan=2>Hull, E., Jackson, K. and&nbsp;Dick, J. <EM>Requirements Engineering</EM>, Second Edition. Springer, 2005. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">IEP1471</a> </TD>
+<TD colSpan=2>IEEE <EM>Recommended Practice for Architectural Description</EM>, IEEE Std P1471, 2000.</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KAZ00</a> </TD>
+<TD colSpan=2>Kazman, R., Carriere, S. J., Woods, S. G.&nbsp;<a href="http://www.sei.cmu.edu/staff/rkazman/annals-scenario.pdf">Toward a Discipline of Scenario-Based Architectural Engineering</a>,(Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) <a href="http://manta.cs.vt.edu./ase/">Annals of Software Engineering</a>, Vol. 9, 2000, 5-33. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KAZ04</a> </TD>
+<TD colSpan=2>Kazman, R., Kruchten, P., Nord, R., Tomayko, J.&nbsp;<EM>Integrating Software-Architecture-Centric Methods into the Rational Unified Process</EM>, CMU-SEI Technical Reports, 2004. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KRO03</a> </TD>
+<TD colSpan=2>Kroll, P. and&nbsp;Kruchten, P. <EM>The Rational Unified Process Made Easy</EM>, Addison Wesley, 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">KRO05 </TD>
+<TD colSpan=2>Kroll, P. and&nbsp;MacIsaac, B. <EM>Agility and Discipline Made Easy</EM>, Addison Wesley, 2005. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KRU95</a> </TD>
+<TD colSpan=2>Kruchten, Phillipe B.,&nbsp; <EM>The 4+1 View Model of Architecture</EM>, IEEE Software, vol. 12, no. 6, pp 42-50, November 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">MAR03</a>&nbsp;</TD>
+<TD colSpan=2>Marick, B., <EM>Exploration Through Example</EM>, <a href="http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1">http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1</a></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">NBG01</a> </TD>
+<TD colSpan=2>Eric J. Naiburg and Robert A. Maksimchuk. <EM>UML for Database Design</EM>, New York, NY: Addison Wesley, 2001</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">RUP06</a> </TD>
+<TD colSpan=2>IBM Rational 2006. <EM>The Rational Unified Process.</EM> </TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">A commercial methodology, also based on the Eclipse Process Framework, and advanced guidance on topics such as business modeling, portfolio management, asset-based development, real-time design, user experience, and so on. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">OOP96</a> </TD>
+<TD colSpan=2>The 1996 ACM Conference on Object-Oriented Programs, Systems, Languages and Applications (OOPSLA), <EM>The Origins of Pattern Theory, the Future of the Theory, And The Generation of a Living World.</EM></TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">See <a href="http://www.patternlanguage.com/archive/ieee/ieeetext.htm" target="">http://www.patternlanguage.com/archive/ieee/ieeetext.htm</a></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">PW92</a> </TD>
+<TD colSpan=2>Dewayne E. Perry and Alexander L. Wolf. <EM>Foundations for the Study of Software Architecture</EM>. ACM SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992.</TD></TR>
+<TR>
+<TD vAlign=top width="12%"><a name="">SCH04</a> </TD>
+<TD colSpan=2>Schwaber, K. <EM>Agile Project Management with Scrum.</EM> Microsoft Press 2004. </TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">
+<P>An excellent reference by one of the co-inventors of the Scrum project management method. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0 <table &gt;>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">SEI99</a> </TD>
+<TD colSpan=2>SEI, 1999. <EM>Software Risk Evaluation (SRE) Method Description, v2.0.</EM> <BR><a href="http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf#search=%22software%20risk%20evaluation%22">http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf#search=%22software%20risk%20evaluation%22</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.)</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">TEL06</a> </TD>
+<TD colSpan=2>Telelogic, 2006. <EM>Get It Right the First Time: Writing Better Requirements.</EM> </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">THA00</a> </TD>
+<TD colSpan=2>Thayer, Richard H.&nbsp;and Dorfman, Merlin&nbsp;<EM>Software Requirements Engineering Second Edition</EM>, IEEE Computer Society, 2000 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">UML05</a> </TD>
+<TD colSpan=2>OMG, 2005. <EM>Unified Modeling Language 2.0: Superstructure.</EM> <BR><a href="http://www.omg.org/docs/formal/05-07-04.pdf" target="">http://www.omg.org/docs/formal/05-07-04.pdf</a>&nbsp;(Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) </TD></TR></TBODY>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">WIB04</a> </TD>
+<TD colSpan=2>Wiborg-Weber, D., Vignaud, J. L. <EM>A Framework for Managing Component Based Development</EM>, Telelogic Whitepaper, 2004 <BR><a href="http://www.telelogic.com/download/index.cfm?id=4423" target="">http://www.telelogic.com/download/index.cfm?id=4423</a></TD></TR></TBODY>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">WIKP-MVC</a> </TD>
+<TD colSpan=2>Wikipedia <EM>Model-view-controller</EM> <BR><a href="http://en.wikipedia.org/wiki/Model-view-controller" target="">http://en.wikipedia.org/wiki/Model-view-controller</a> </TD></TR></TBODY></TABLE></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif
new file mode 100644
index 0000000..d1f6a31
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif
new file mode 100644
index 0000000..da5215c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif
new file mode 100644
index 0000000..36f36b4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif
new file mode 100644
index 0000000..5839c94
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif
new file mode 100644
index 0000000..f7f4665
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg
new file mode 100644
index 0000000..0bb0b38
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif
new file mode 100644
index 0000000..3fb662d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif
new file mode 100644
index 0000000..9554964
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/about.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/about.gif
new file mode 100644
index 0000000..1316610
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/about.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/copyrite.htm b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/copyrite.htm
new file mode 100644
index 0000000..51edd3a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/copyrite.htm
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>IBM(R) Rational(R) Intellectual Property Notices and Other Licensing Requirements</title>
+</head>
+
+<body>
+NOTICES AND INFORMATION <br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+About This Content
+</p>
+<p>
+May 2, 2006
+</p>
+<p>
+License
+</p>
+<p>
+The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
+</p>
+<p>
+If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributors license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
+ <br>
+</BODY>
+</HTML>
\ No newline at end of file
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/icon_introL.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/icon_introL.gif
new file mode 100644
index 0000000..1826cbd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/icon_introL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/mic.gif b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/mic.gif
new file mode 100644
index 0000000..0b316db
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/mic.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.cdr b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.cdr
new file mode 100644
index 0000000..afb1e0e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.cdr
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg
new file mode 100644
index 0000000..4719cad
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/architecture.xmi
new file mode 100644
index 0000000..09b74ee
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/architecture.xmi
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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" epf:version="1.0.0" xmi:id="-1Lm8-0FY-QIC56u5t2SC9w" name=",__JXkoCk8EduLGM8dfVsrKg" guid="-1Lm8-0FY-QIC56u5t2SC9w" changeDate="2007-02-26T12:49:32.093+0000" version="1.0.0">
+ <mainDescription><p>
+ Here are some templates for representing the architecture. Architecture can be represented in a variety of ways,
+ according to the needs of the project team. See <a class="elementLink"
+ href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture</a>&nbsp;for more information.
+</p>
+<p>
+ Feel free to use one or more of these templates or create your own.
+</p>
+<p>
+ The <a class="elementLink" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> should decide what views are useful for describing the system under
+ consideration.&nbsp;
+</p>
+<p>
+ Consider one or more&nbsp;relevant views of the architecture and document each one using the provided template for the
+ architectural view. If needed, document information that applies to more than one view using the template provided for
+ the Software Architecture Document to get an integrated representation of the architecture instead of just snapshots
+ taken from different angles.
+</p>
+<p>
+ The structuring of the documents must support the needs of the intended audience. For example, instead of a document
+ for the implementation view developers may find more useful alternative forms for the project directory structure like
+ the template provided for the project startup kit.
+</p>
+<p>
+ Keep documentation up-to-date but to an essential minimum. When the architecture is under development, decisions are
+ reconsidered frequently so constant revision of the documentation is an unnecessary expense.&nbsp; Determine points in
+ the development lifecycle when documentation should be updated.
+</p></mainDescription>
+ <attachments>resources/sw_architecture_doc_tpl.dot|resources/project_startup_kit.zip|resources/sw_architecture_view_tpl.dot|resources/software_arch_document.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/iteration_plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/iteration_plan.xmi
new file mode 100644
index 0000000..18115b6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/iteration_plan.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_Z_bUIMM2EdmSIPI87WLu3g" name="iteration_plan,_0dBoQMlgEdmt3adZL5Dmdw" guid="_Z_bUIMM2EdmSIPI87WLu3g" changeDate="2006-05-08T16:49:33.210-0700">
+ <attachments>resources/iteration_plan.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/project_plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/project_plan.xmi
new file mode 100644
index 0000000..60e29a2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/project_plan.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_XjOXcMM2EdmSIPI87WLu3g" name="project_plan,_0c7hoMlgEdmt3adZL5Dmdw" guid="_XjOXcMM2EdmSIPI87WLu3g" changeDate="2006-05-08T17:03:04.654-0700">
+ <attachments>resources/project_plan.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/iteration_plan.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/iteration_plan.dot
new file mode 100644
index 0000000..0c5aa32
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/iteration_plan.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/project_plan.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/project_plan.dot
new file mode 100644
index 0000000..7d0f02b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/project_plan.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/project_startup_kit.zip b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/project_startup_kit.zip
new file mode 100644
index 0000000..01f305a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/project_startup_kit.zip
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/risk_list.xls b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/risk_list.xls
new file mode 100644
index 0000000..e3970a2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/risk_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/software_arch_document.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/software_arch_document.dot
new file mode 100644
index 0000000..e13bc09
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/software_arch_document.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/status_assessment.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/status_assessment.dot
new file mode 100644
index 0000000..02c5cd1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/status_assessment.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/supporting_req.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/supporting_req.dot
new file mode 100644
index 0000000..9ee5649
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/supporting_req.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/supporting_req_spec.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/supporting_req_spec.dot
new file mode 100644
index 0000000..3baaa46
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/supporting_req_spec.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot
new file mode 100644
index 0000000..1839b44
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot
new file mode 100644
index 0000000..5a9581f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/test_case.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/test_case.dot
new file mode 100644
index 0000000..2395e41
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/test_case.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/uc_specification.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/uc_specification.dot
new file mode 100644
index 0000000..fdcd90c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/uc_specification.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/vision.dot b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/vision.dot
new file mode 100644
index 0000000..9628c3b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/vision.dot
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/work_items_list.xls b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/work_items_list.xls
new file mode 100644
index 0000000..9f0b462
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/resources/work_items_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/risk_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/risk_list.xmi
new file mode 100644
index 0000000..98595b5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/risk_list.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="-OugFZJszm73z0_KSwRXZPw" name="new_template,_MIUO0C8FEduzydamRseoUw" guid="-OugFZJszm73z0_KSwRXZPw">
+ <attachments>resources/risk_list.xls</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/software_arch_document.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/software_arch_document.xmi
new file mode 100644
index 0000000..fd0456d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/software_arch_document.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_fJPGkMM2EdmSIPI87WLu3g" name="software_arch_document,_0dN1gMlgEdmt3adZL5Dmdw" guid="_fJPGkMM2EdmSIPI87WLu3g" changeDate="2006-05-09T10:50:14.957-0700">
+ <attachments>resources/software_arch_document.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/status_assessment.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/status_assessment.xmi
new file mode 100644
index 0000000..f6a3347
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/status_assessment.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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" epf:version="1.0.0" xmi:id="-2uQACndDBzBhJC1sCmk5UA" name="new_template,_1awLIEp2Edup0IY9DKDPkg" guid="-2uQACndDBzBhJC1sCmk5UA">
+ <attachments>resources/status_assessment.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/supporting_requirements_spec.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/supporting_requirements_spec.xmi
new file mode 100644
index 0000000..87f73c3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/supporting_requirements_spec.xmi
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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" epf:version="1.0.0" xmi:id="-FsyxZy4tyX8k5CxT5Jww_w" name="new_template,_ItYXcNa9Edqrw4BYKyYKiA" guid="-FsyxZy4tyX8k5CxT5Jww_w" authors="Ana Paula Valente Pereira (apereira@whatever.pt) and Chris Sibbald" changeDate="2006-08-17T12:24:20.463-0400" version="0.4">
+ <mainDescription>This template provides a starting point for capturing&nbsp;supporting requirement in a consistent manner and to provide a
+useful checklist when determining the types of requirements that may apply.&nbsp; It is not expected that one would
+complete&nbsp;every section of this template in all circumstances.&nbsp; Tailor as you see fit for your particular
+circumstances.</mainDescription>
+ <attachments>resources/supporting_req_spec.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/test_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/test_case.xmi
new file mode 100644
index 0000000..8aef710
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/test_case.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_j2pQ4MM2EdmSIPI87WLu3g" name="test_case,_0dT8IMlgEdmt3adZL5Dmdw" guid="_j2pQ4MM2EdmSIPI87WLu3g" changeDate="2006-05-09T10:58:06.425-0700">
+ <attachments>resources/test_case.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/uc_specification.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/uc_specification.xmi
new file mode 100644
index 0000000..4111542
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/uc_specification.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_OaB-UMM2EdmSIPI87WLu3g" name="uc_specification,_0cpNwMlgEdmt3adZL5Dmdw" guid="_OaB-UMM2EdmSIPI87WLu3g" changeDate="2006-05-09T11:32:09.165-0700">
+ <attachments>resources/uc_specification.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/vision.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/vision.xmi
new file mode 100644
index 0000000..52893af
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/vision.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_LxX6AMM2EdmSIPI87WLu3g" name="vision,_0cW54MlgEdmt3adZL5Dmdw" guid="_LxX6AMM2EdmSIPI87WLu3g" changeDate="2006-05-09T11:32:25.328-0700">
+ <attachments>resources/vision.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/work_items_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/work_items_list.xmi
new file mode 100644
index 0000000..6f10ead
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/templates/work_items_list.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="-mPA7vone29k1OvF_1rACjg" name="work_items_list,_QwUJYDg0Edu4E8ZdmlYjtA" guid="-mPA7vone29k1OvF_1rACjg">
+ <attachments>resources/work_items_list.xls</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/actor.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/actor.xmi
new file mode 100644
index 0000000..1d279b5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/actor.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-4RQJzq_1URTZ5FGCBKnTIw" name="new_term_definition,_ZsK30EvBEdunZcj9T5hrMQ" guid="-4RQJzq_1URTZ5FGCBKnTIw">
+ <mainDescription>Someone or something, outside the system that interacts with the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/agile.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/agile.xmi
new file mode 100644
index 0000000..f322be0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/agile.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-qZE4XgeMK93LmJMKuQWGFg" name=",_3PJ38EvqEdunZcj9T5hrMQ" guid="-qZE4XgeMK93LmJMKuQWGFg">
+ <mainDescription>A set of values and principles for software development that use lean production techniques to deliver value to
+stakeholders quickly and frequently.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/analyst.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/analyst.xmi
new file mode 100644
index 0000000..f869df1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/analyst.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-1RwpgmmY974S0YkxEOFDCw" name="new_term_definition,_GEAwAEvCEdunZcj9T5hrMQ" guid="-1RwpgmmY974S0YkxEOFDCw">
+ <mainDescription>Role representing customer and end-user concerns</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architect.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architect.xmi
new file mode 100644
index 0000000..79cb5b4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architect.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-2QB1bosN011CudkwZ0cn-g" name="architect,_wI3R4EvCEdunZcj9T5hrMQ" guid="-2QB1bosN011CudkwZ0cn-g">
+ <mainDescription>Role representing someone responsible for designing the software architecture, which includes making the key technical
+decisions that constrain the overall design and implementation of the project</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architectural_mechanism.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architectural_mechanism.xmi
new file mode 100644
index 0000000..85f412d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architectural_mechanism.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-Vvwb6EupIB9kfSQ_mhjURA" name="architectural_mechanism,_VHFGkEvCEdunZcj9T5hrMQ" guid="-Vvwb6EupIB9kfSQ_mhjURA" changeDate="2006-09-24T13:46:41.881+0100">
+ <mainDescription>Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of
+structure, patterns of behavior, or both.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architectural_view.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architectural_view.xmi
new file mode 100644
index 0000000..b9d86f9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architectural_view.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-0vih7gB84YYDheaH7jeYFQ" name="new_term_definition,_n7GmQEvCEdunZcj9T5hrMQ" guid="-0vih7gB84YYDheaH7jeYFQ">
+ <mainDescription>A view of the&nbsp; architecture from a given perspective.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architecture.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architecture.xmi
new file mode 100644
index 0000000..d0b3916
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/architecture.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-YMvJ5LwexkcVWWqLdm5-nQ" name=",_siyjEEvCEdunZcj9T5hrMQ" guid="-YMvJ5LwexkcVWWqLdm5-nQ">
+ <mainDescription>Describes the blueprint for software development, frequently represented using a number of architectural views. It also
+contains the rationale, assumptions, explanations and implications of the decisions that where made in forming the
+architecture as well as the global mapping between views</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/build.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/build.xmi
new file mode 100644
index 0000000..80026c2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/build.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-Wh-byAGHoy_gGry0Jq6VaA" name=",_Z-AukEvpEdunZcj9T5hrMQ" guid="-Wh-byAGHoy_gGry0Jq6VaA">
+ <mainDescription>An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the
+final product</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/business_rule.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/business_rule.xmi
new file mode 100644
index 0000000..59b25b9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/business_rule.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-COrjB4k8Qtf6ZpPEcBNwpw" name=",_NtGL0EvDEdunZcj9T5hrMQ" guid="-COrjB4k8Qtf6ZpPEcBNwpw">
+ <mainDescription>A declaration of policy or condition that must be satisfied by the system under consideration. For more information see
+Supporting Requirements</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/code_instrumentation.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/code_instrumentation.xmi
new file mode 100644
index 0000000..a05caf1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/code_instrumentation.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-RlYzPnl6Pig2H851hHebBA" name="new_term_definition,_JiqnEJt1EdutoZjlV3a4Lg" guid="-RlYzPnl6Pig2H851hHebBA" changeDate="2007-01-03T16:56:04.699-0500">
+ <mainDescription><p>
+ "Extra" statements added to source code for the purposes of testing, debugging, tuning,&nbsp;or tracing.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/component.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/component.xmi
new file mode 100644
index 0000000..d5bc074
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/component.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-BWZsh3vKrqSOzfkBJmDTLA" name=",_d82_AEvDEdunZcj9T5hrMQ" guid="-BWZsh3vKrqSOzfkBJmDTLA">
+ <mainDescription>A nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined
+architecture. A component conforms to and provides the realization of a set of interfaces</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/configuration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/configuration.xmi
new file mode 100644
index 0000000..59fada0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/configuration.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-VPoMu7qzVX9grE4-nB3kMw" name=",__Cw30ElxEducWJcS4yanqg" guid="-VPoMu7qzVX9grE4-nB3kMw" changeDate="2006-09-21T09:07:10.404-0400">
+ <mainDescription>The performance, functional, and physical attributes of an existing or planned product, or a combination of products.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/construction.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/construction.xmi
new file mode 100644
index 0000000..25c5fcd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/construction.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-5wJmUR0WqX7lCIxsyqFsdA" name=",_0sD60EvDEdunZcj9T5hrMQ" guid="-5wJmUR0WqX7lCIxsyqFsdA">
+ <mainDescription>The third phase of the OpenUP/ Basic project lifecycle, in which the software is brought from an executable architectural
+baseline to the point at which it is ready to be transitioned to the user community.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/developer.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/developer.xmi
new file mode 100644
index 0000000..aab29a6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/developer.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-802sCZ4lJcejyRbhLmkxkw" name=",_-61a8EvOEdunZcj9T5hrMQ" guid="-802sCZ4lJcejyRbhLmkxkw" changeDate="2006-09-24T15:17:35.993+0100">
+ <mainDescription>Role representing someone&nbsp; responsible for developing a part of the system, including designing it to fit into the
+architecture, and then implementing, unit-testing, and integrating the components that are part of the solution.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/effort.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/effort.xmi
new file mode 100644
index 0000000..697e5da
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/effort.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-WIgtkwJN71D51FdcQs-TzQ" name=",_nJSDwEvuEdunZcj9T5hrMQ" guid="-WIgtkwJN71D51FdcQs-TzQ">
+ <mainDescription><p>
+ Indicates how long it will take the team member(s) assigned to the work item to do the work. Typically uses the units
+ of Actual Days or Actual Hours
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/elaboration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/elaboration.xmi
new file mode 100644
index 0000000..d092b64
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/elaboration.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-0g2jTHQla8lbP6xGB3iGlg" name=",_8DkT4EvDEdunZcj9T5hrMQ" guid="-0g2jTHQla8lbP6xGB3iGlg">
+ <mainDescription>Second of four phases in the in the OpenUP/ Basic project lifecycle, when architecturally-significant risks are addressed</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/feature.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/feature.xmi
new file mode 100644
index 0000000..36260a0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/feature.xmi
@@ -0,0 +1,7 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-qpBnpWqiD7gjT08LjTMbsQ" name="new_term_definition,_PgYREAeYEduWycDgioo5rg" guid="-qpBnpWqiD7gjT08LjTMbsQ" changeDate="2006-06-29T10:56:21.941-0700">
+ <mainDescription>An externally observable service provided by the system that directly fulfills
+a <a class="elementLink"
+href="./../../../openup_basic/guidances/termdefinitions/stakeholder_need,_WUiFcAeYEduWycDgioo5rg.html"
+guid="_WUiFcAeYEduWycDgioo5rg">Stakeholder Need</a>&nbsp;.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/furps.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/furps.xmi
new file mode 100644
index 0000000..f1b2d1c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/furps.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-vq2pL6yQuqGhql9Wo_Av4w" name=",_ZH6M0EvEEdunZcj9T5hrMQ" guid="-vq2pL6yQuqGhql9Wo_Av4w" changeDate="2006-12-21T12:45:04.101-0500" version="1.0.0">
+ <mainDescription>Functional, usability, reliability, performance, supportability + others. This acronym represents categories that can be
+used in the definition of product requirements. For more information see Supporting Requirements</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/glossary.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/glossary.xmi
new file mode 100644
index 0000000..419199e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/glossary.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-05pn_DGdNui9qqwx46iKZQ" name=",_VhhDMEvrEdunZcj9T5hrMQ" guid="-05pn_DGdNui9qqwx46iKZQ" changeDate="2006-09-24T18:40:24.193+0100">
+ <mainDescription>An artifact in OpenUP that defines the vocabulary and other important terms that are part of a project and the problem
+domain.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/inception.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/inception.xmi
new file mode 100644
index 0000000..5d1838d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/inception.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-dhgOQQ4GsV0-dNJmTmF9GA" name=",_525A8EvDEdunZcj9T5hrMQ" guid="-dhgOQQ4GsV0-dNJmTmF9GA" changeDate="2006-09-24T14:05:23.073+0100">
+ <mainDescription>First of the four phases in the OpenUP/ Basic project lifecycle, it is about understanding the project scope and objectives
+and getting enough information to confirm that the project should proceed&nbsp; or not.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/ioc_milestone.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/ioc_milestone.xmi
new file mode 100644
index 0000000..4885640
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/ioc_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-gEgZg2UkFLjGeXkJLpAP6A" name=",_O7JBYEvFEdunZcj9T5hrMQ" guid="-gEgZg2UkFLjGeXkJLpAP6A" changeDate="2006-09-24T14:41:48.635+0100">
+ <mainDescription>At the end of Construction phase is the third important project milestone.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/iteration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/iteration.xmi
new file mode 100644
index 0000000..067dfeb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/iteration.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-_G0VvVOdMoajk615LwFtxg" name=",_ZBUnMEvFEdunZcj9T5hrMQ" guid="-_G0VvVOdMoajk615LwFtxg" changeDate="2006-09-24T14:23:38.618+0100">
+ <mainDescription>Short and time-boxed division of a project. Iterations allow to demonstrate incremental value and obtain early and
+continuous feedback</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/iteration_burndown.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/iteration_burndown.xmi
new file mode 100644
index 0000000..b4bfd3d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/iteration_burndown.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-3G3HV0opAmFWGxYgsD5AhA" name=",_8b20EEvvEdunZcj9T5hrMQ" guid="-3G3HV0opAmFWGxYgsD5AhA">
+ <mainDescription>A&nbsp;primary tool for understanding the status of an iteration. It shows the trend for how much work is left to do within
+that iteration.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/lca_milestone.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/lca_milestone.xmi
new file mode 100644
index 0000000..bfb482f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/lca_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-MllWL01NL93RTB7VsY69fw" name=",_NL4DMEvFEdunZcj9T5hrMQ" guid="-MllWL01NL93RTB7VsY69fw">
+ <mainDescription>At the end of the Elaboration phase is the second important project milestone</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/lco_milestone.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/lco_milestone.xmi
new file mode 100644
index 0000000..a6665d1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/lco_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-Rl8kaRW9Bxqdvq32kVCi7w" name=",_LGRBkEvFEdunZcj9T5hrMQ" guid="-Rl8kaRW9Bxqdvq32kVCi7w">
+ <mainDescription>At the end of the Inception phase is the first major project milestone</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/milestone.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/milestone.xmi
new file mode 100644
index 0000000..e042ec7
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/milestone.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-9fXEOvMc4t7y6s5GscBD1Q" name=",_ByXNcEvqEdunZcj9T5hrMQ" guid="-9fXEOvMc4t7y6s5GscBD1Q">
+ <mainDescription><p>
+ The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready
+ to move to the next iteration or phase.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/pattern.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/pattern.xmi
new file mode 100644
index 0000000..2a3b8bb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/pattern.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-VJBtRm2brEKpRlnLWNF8_g" name=",_ctrEgEvCEdunZcj9T5hrMQ" guid="-VJBtRm2brEKpRlnLWNF8_g">
+ <mainDescription>Generalized solutions that can be implemented and applied in a problem situation (a context)</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/point.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/point.xmi
new file mode 100644
index 0000000..7307076
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/point.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-oShmMITo9RIi1AzACWI9vw" name="new_term_definition,_MvOuAEvGEdunZcj9T5hrMQ" guid="-oShmMITo9RIi1AzACWI9vw" changeDate="2006-09-24T18:59:48.289+0100">
+ <mainDescription>A relative measure of size is typically used for Agile estimation</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/pr_milestone.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/pr_milestone.xmi
new file mode 100644
index 0000000..c27251f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/pr_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-JegYQHIteCRN0iV2EKMjSA" name=",_QuywUEvFEdunZcj9T5hrMQ" guid="-JegYQHIteCRN0iV2EKMjSA">
+ <mainDescription>At the end of the Transition phase is the last major project milestone</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/project_burndown.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/project_burndown.xmi
new file mode 100644
index 0000000..9919821
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/project_burndown.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-NNByAM5YsjCu39flaOSZtQ" name=",_eX0YsEvvEdunZcj9T5hrMQ" guid="-NNByAM5YsjCu39flaOSZtQ" changeDate="2006-09-24T19:09:54.521+0100">
+ <mainDescription>A chart consisting of two perspectives, the horizontal axis showing the iterations and the vertical axis indicating the
+remaining points from the work items list.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/requirement.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/requirement.xmi
new file mode 100644
index 0000000..9816094
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/requirement.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-0sCBiohjw_wBDKk0WEeDJQ" name="new_term_definition,_feKVQLULEdqI644ssJaKYg" guid="-0sCBiohjw_wBDKk0WEeDJQ" authors="Chris Sibbald" changeDate="2006-12-22T09:19:44.500-0500" changeDescription="Added term definition for "requirement"." version="0.2">
+ <mainDescription><ol>
+ <li>
+ A capability needed by the user to solve a problem [in order to] to achieve an objective
+ </li>
+ <li>
+ A capability that must be met or possessed by a system or system component to satisfy a contract, standard,
+ specification, or other formally imposed documentation <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[THA00]</a><br />
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/risk.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/risk.xmi
new file mode 100644
index 0000000..a17fd9d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/risk.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-hOtatvr8wIjqW8UD0MSGhQ" name="risk,_ii2LUEvGEdunZcj9T5hrMQ" guid="-hOtatvr8wIjqW8UD0MSGhQ" changeDate="2006-09-29T11:58:30.374-0700" version="1.0.0">
+ <mainDescription>A condition that can potentially affect, prevent, or limit a project's success. Project risks may be seen as threats or
+opportunities</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/scope.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/scope.xmi
new file mode 100644
index 0000000..e0d64c1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/scope.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-h1poMaxtQbmg6hD5772oVw" name=",_t7JOkEvtEdunZcj9T5hrMQ" guid="-h1poMaxtQbmg6hD5772oVw" changeDate="2006-09-24T19:22:03.239+0100">
+ <mainDescription>A description of the breadth of a system's behavior, specifying the boundaries of the problem domain or system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/stakeholder_need.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/stakeholder_need.xmi
new file mode 100644
index 0000000..17e35d8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/stakeholder_need.xmi
@@ -0,0 +1,5 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-1pmL5bC27rtWB84PXAgq9Q" name="new_term_definition,_WUiFcAeYEduWycDgioo5rg" guid="-1pmL5bC27rtWB84PXAgq9Q">
+ <mainDescription>The business or operational problem (opportunity) that must be fulfilled to justify
+purchase or use of the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/supporting_requirement.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/supporting_requirement.xmi
new file mode 100644
index 0000000..900c071
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/supporting_requirement.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-ketzwgDgY82DMyfuHqu3Cw" name=",_U_olUEvDEdunZcj9T5hrMQ" guid="-ketzwgDgY82DMyfuHqu3Cw" changeDate="2006-12-21T12:32:14.441-0500" version="1.0.0">
+ <mainDescription>Supporting requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
+usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral requirements
+artifacts such as use-cases.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/test_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/test_case.xmi
new file mode 100644
index 0000000..df79e4e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/test_case.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-6oW2YOnoWq_xPpmoil91KA" name="test_case,_U4RYEEvOEdunZcj9T5hrMQ" guid="-6oW2YOnoWq_xPpmoil91KA">
+ <mainDescription><p>
+ The specification of a set of test inputs, execution conditions, and expected results, which need to be validated to
+ enable an assessment of some particular aspects of the system under test.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/tester.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/tester.xmi
new file mode 100644
index 0000000..6545a39
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/tester.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-prQBbamJ4CLPywfEbyaPaA" name=",_WB6rQEvPEdunZcj9T5hrMQ" guid="-prQBbamJ4CLPywfEbyaPaA" changeDate="2006-09-24T15:20:01.152+0100">
+ <mainDescription>Role representing someone&nbsp; responsible for the core activities of the test effort.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/transition.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/transition.xmi
new file mode 100644
index 0000000..72efd0e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/transition.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-yoFF90pq-_UV3fm-5oDenw" name=",_-5ms4EvDEdunZcj9T5hrMQ" guid="-yoFF90pq-_UV3fm-5oDenw">
+ <mainDescription>The fourth and last <span class="docEmphasis">phase</span> of the OpenUP/ Basic project lifecycle, which results in a final
+product <span class="docEmphasis">release</span>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case.xmi
new file mode 100644
index 0000000..abccf68
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-HDfMzDXoilK-f2iNreHRVg" name=",_IHRO8EvHEdunZcj9T5hrMQ" guid="-HDfMzDXoilK-f2iNreHRVg">
+ <mainDescription>Captures requirements as&nbsp;a&nbsp; sequence of actions a system performs that yields an observable result of value to
+those interacting with the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case_model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case_model.xmi
new file mode 100644
index 0000000..7a15c6b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case_model.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-UTrE64wEDJIC1FRUomEYDg" name=",_k6B3kEvmEdunZcj9T5hrMQ" guid="-UTrE64wEDJIC1FRUomEYDg">
+ <mainDescription>A&nbsp;model of the system use cases and actors and the relationships between them</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case_scenario.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case_scenario.xmi
new file mode 100644
index 0000000..bffc82f
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/use_case_scenario.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-t3jNM5ZWkYtzB8A4Chz2Vw" name=",_oXmYMEvGEdunZcj9T5hrMQ" guid="-t3jNM5ZWkYtzB8A4Chz2Vw">
+ <mainDescription>Represents specific instances of the use case that correspond to specific inputs from the Actor or to specific conditions
+in the environment. Each scenario describes alternate ways that the system provides a behavior, or it may describe failure
+or exception cases</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/velocity.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/velocity.xmi
new file mode 100644
index 0000000..4f95433
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/velocity.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-mgWkuUy3q0zzFaxE7DY1ag" name=",_Nj2hsEvuEdunZcj9T5hrMQ" guid="-mgWkuUy3q0zzFaxE7DY1ag">
+ <mainDescription>A&nbsp;key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a
+certain team and project.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/version.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/version.xmi
new file mode 100644
index 0000000..cd92f6d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/version.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-4iL0UEFR2Fg7oWkh1TymIg" name=",_eX8K8ElyEducWJcS4yanqg" guid="-4iL0UEFR2Fg7oWkh1TymIg" changeDate="2006-09-21T09:10:30.780-0400">
+ <mainDescription>A variant of some artifact; later versions of an artifact typically expand upon earlier versions.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/vision.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/vision.xmi
new file mode 100644
index 0000000..d6e86e6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/vision.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-VMnkFJpPLdEDUpbz2QDgow" name=",_J_5kgEvHEdunZcj9T5hrMQ" guid="-VMnkFJpPLdEDUpbz2QDgow" changeDate="2006-09-24T14:21:36.312+0100">
+ <mainDescription>The user's or customer's view of the product to be developed, specified at the level of key stakeholder needs and features
+of the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/work_breakdown_structure.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/work_breakdown_structure.xmi
new file mode 100644
index 0000000..ea004fc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/work_breakdown_structure.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-KQTbqDSJXR8KLBxIgGVquA" name=",_RK9nwEvtEdunZcj9T5hrMQ" guid="-KQTbqDSJXR8KLBxIgGVquA">
+ <mainDescription>Breaks the project into individual units of work, or tasks, for which cost, milestones, and activities can be allocated and
+tracked.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/work_item.xmi b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/work_item.xmi
new file mode 100644
index 0000000..98f62dc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/guidances/termdefinitions/work_item.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-1Oc9t_TLaBgW_YLugZcq7w" name="work_item,_jyVgcEvKEdunZcj9T5hrMQ" guid="-1Oc9t_TLaBgW_YLugZcq7w" changeDate="2006-09-24T19:07:26.158+0100">
+ <mainDescription>Scheduled work to be done within the project</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/plugin.xmi b/OpenUP/OpenUP_PT/library/openup_basic/plugin.xmi
new file mode 100644
index 0000000..3e32e8c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/plugin.xmi
@@ -0,0 +1,1227 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nHk9MPL5Edm6Nvont3uinw" guid="_nHk9MPL5Edm6Nvont3uinw">
+ <subManagers xmi:id="_nI06YvL5Edm6Nvont3uinw" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_nI06YvL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nJHOQPL5Edm6Nvont3uinw" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_nJHOQPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nJr2APL5Edm6Nvont3uinw" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_nJr2APL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nJx8oPL5Edm6Nvont3uinw" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_nJx8oPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nKQdwPL5Edm6Nvont3uinw" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_nKQdwPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nKu-4vL5Edm6Nvont3uinw" href="uma://_0sluQclgEdmt3adZL5Dmdw#_nKu-4vL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nK7zMvL5Edm6Nvont3uinw" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_nK7zMvL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nLga8vL5Edm6Nvont3uinw" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_nLga8vL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nMRP8PL5Edm6Nvont3uinw" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_nMRP8PL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nNCE8PL5Edm6Nvont3uinw" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_nNCE8PL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nNtaYPL5Edm6Nvont3uinw" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_nNtaYPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_h7wUUPimEdmugcVr9AdHjQ" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h7wUUPimEdmugcVr9AdHjQ"/>
+ <subManagers xmi:id="_z-Z5MOtQEdqc1LGhiSPqRg" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_z-Z5MOtQEdqc1LGhiSPqRg"/>
+ <resourceDescriptors xmi:id="_mur8EPL5Edm6Nvont3uinw" id="__rFCULv9EdmmUvZAZjqE3g" uri="disciplines/requirements.xmi"/>
+ <resourceDescriptors xmi:id="_mur8EfL5Edm6Nvont3uinw" id="_Bbq2MLv-EdmmUvZAZjqE3g" uri="disciplines/analysis_and_design.xmi"/>
+ <resourceDescriptors xmi:id="_mur8EvL5Edm6Nvont3uinw" id="_D5dHQLv-EdmmUvZAZjqE3g" uri="disciplines/implementation.xmi"/>
+ <resourceDescriptors xmi:id="_mur8E_L5Edm6Nvont3uinw" id="_FuQswLv-EdmmUvZAZjqE3g" uri="disciplines/test.xmi"/>
+ <resourceDescriptors xmi:id="_mu-P8PL5Edm6Nvont3uinw" id="_GybfgLv-EdmmUvZAZjqE3g" uri="disciplines/project_management.xmi"/>
+ <resourceDescriptors xmi:id="_mvEWkPL5Edm6Nvont3uinw" id="_H9TXMLv-EdmmUvZAZjqE3g" uri="disciplines/config_and_change_management.xmi"/>
+ <resourceDescriptors xmi:id="_mvEWkfL5Edm6Nvont3uinw" id="_Tb5J8O8NEdmKSqa_gSYthg" uri="rolesets/openup_basic_roles.xmi"/>
+ <resourceDescriptors xmi:id="_mvWqcPL5Edm6Nvont3uinw" id="_cyZ5EMfLEdmg9p6Pf0sWyw" uri="customcategories/Custom%20Categories.xmi"/>
+ <resourceDescriptors xmi:id="_mvWqcfL5Edm6Nvont3uinw" id="_gXQCkO8MEdmKSqa_gSYthg" uri="customcategories/openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_mvcxFPL5Edm6Nvont3uinw" id="_EvRkgO8NEdmKSqa_gSYthg" uri="customcategories/view_building_blocks.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3sfL5Edm6Nvont3uinw" id="_tYiSIO8NEdmKSqa_gSYthg" uri="customcategories/disciplines.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3svL5Edm6Nvont3uinw" id="_5WkxcO8NEdmKSqa_gSYthg" uri="customcategories/openup_basic_work_products.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3s_L5Edm6Nvont3uinw" id="_-jHu0O8NEdmKSqa_gSYthg" uri="customcategories/by_domain.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3tPL5Edm6Nvont3uinw" id="__uYoEO8NEdmKSqa_gSYthg" uri="customcategories/by_type.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3tfL5Edm6Nvont3uinw" id="_zHZW9KYSEdmvhNXG0Oc2uA" uri="workproducts/uc_model_intent_req_ucm.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3tvL5Edm6Nvont3uinw" id="_MqODAMM1EdmSIPI87WLu3g" uri="guidances/checklists/uc_model.xmi"/>
+ <resourceDescriptors xmi:id="_m9t2kPL5Edm6Nvont3uinw" id="_AGvpcMM3EdmSIPI87WLu3g" uri="guidances/guidelines/uc_model.xmi"/>
+ <resourceDescriptors xmi:id="_m-SeUPL5Edm6Nvont3uinw" id="_zHZW8qYSEdmvhNXG0Oc2uA" uri="workproducts/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_m-xmg_L5Edm6Nvont3uinw" id="_KEldgMM1EdmSIPI87WLu3g" uri="guidances/checklists/actor.xmi"/>
+ <resourceDescriptors xmi:id="_m-xmhPL5Edm6Nvont3uinw" id="_Nx8icKYdEdmvhNXG0Oc2uA" uri="roles/analyst.xmi"/>
+ <resourceDescriptors xmi:id="_m-xmhfL5Edm6Nvont3uinw" id="_zHTQUKYSEdmvhNXG0Oc2uA" uri="workproducts/vision.xmi"/>
+ <resourceDescriptors xmi:id="_m-3tIfL5Edm6Nvont3uinw" id="_eUfzwMMyEdmdo9HxCRR_Gw" uri="guidances/concepts/requirements.xmi"/>
+ <resourceDescriptors xmi:id="_m-3tIvL5Edm6Nvont3uinw" id="_qktWQMM0EdmSIPI87WLu3g" uri="guidances/checklists/vision.xmi"/>
+ <resourceDescriptors xmi:id="_m-3tI_L5Edm6Nvont3uinw" id="_zxB-QKYcEdmvhNXG0Oc2uA" uri="workproducts/design.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zwvL5Edm6Nvont3uinw" id="_H4gOYKYTEdmvhNXG0Oc2uA" uri="workproducts/architecture_notebook.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zw_L5Edm6Nvont3uinw" id="_YIYIYMM1EdmSIPI87WLu3g" uri="guidances/checklists/design.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zxPL5Edm6Nvont3uinw" id="_SB1n8MM1EdmSIPI87WLu3g" uri="guidances/concepts/visual_modeling.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zx_L5Edm6Nvont3uinw" id="_Qo7pYMM3EdmSIPI87WLu3g" uri="guidances/guidelines/design.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6YPL5Edm6Nvont3uinw" id="_17Ve8Nd6EdmIm-bsRSNCgw" uri="guidances/checklists/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6YfL5Edm6Nvont3uinw" id="_Y6tLEKbXEdm9d-ircVOUCA" uri="roles/architect.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6YvL5Edm6Nvont3uinw" id="_NqL7MqeqEdmKDbQuyzCoqQ" uri="roles/developer.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6Y_L5Edm6Nvont3uinw" id="_QvmkAMM1EdmSIPI87WLu3g" uri="guidances/concepts/pattern.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6ZPL5Edm6Nvont3uinw" id="_TZiasMM1EdmSIPI87WLu3g" uri="guidances/concepts/component.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6Z_L5Edm6Nvont3uinw" id="_6u9ZsKYcEdmvhNXG0Oc2uA" uri="workproducts/implementation.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBAPL5Edm6Nvont3uinw" id="_NqSB0KeqEdmKDbQuyzCoqQ" uri="workproducts/build.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBAfL5Edm6Nvont3uinw" id="_NqSB0qeqEdmKDbQuyzCoqQ" uri="workproducts/developer_test.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBAvL5Edm6Nvont3uinw" id="_4wqaMMPaEdmbOvqy4O0adg" uri="guidances/guidelines/implementation.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBA_L5Edm6Nvont3uinw" id="_Hg5UUMPbEdmbOvqy4O0adg" uri="guidances/concepts/test_first_design.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBBvL5Edm6Nvont3uinw" id="_NqYIcKeqEdmKDbQuyzCoqQ" uri="roles/tester.xmi"/>
+ <resourceDescriptors xmi:id="_m_QHoPL5Edm6Nvont3uinw" id="_NqYIdKeqEdmKDbQuyzCoqQ" uri="workproducts/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_m_QHovL5Edm6Nvont3uinw" id="_NqYIcqeqEdmKDbQuyzCoqQ" uri="workproducts/test_script.xmi"/>
+ <resourceDescriptors xmi:id="_m_QHo_L5Edm6Nvont3uinw" id="_NqePEKeqEdmKDbQuyzCoqQ" uri="workproducts/test_log.xmi"/>
+ <resourceDescriptors xmi:id="_nC4qcPL5Edm6Nvont3uinw" id="_kwHAgMPbEdmbOvqy4O0adg" uri="guidances/checklists/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_nC-xEfL5Edm6Nvont3uinw" id="_4LuPMMPcEdmbOvqy4O0adg" uri="guidances/checklists/test_script.xmi"/>
+ <resourceDescriptors xmi:id="_nDE3sPL5Edm6Nvont3uinw" id="_y-_PIMPdEdmbOvqy4O0adg" uri="guidances/concepts/types_of_test.xmi"/>
+ <resourceDescriptors xmi:id="_nDK-UvL5Edm6Nvont3uinw" id="_BcBR8KX5EdmvhNXG0Oc2uA" uri="workproducts/iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDRE8vL5Edm6Nvont3uinw" id="_71hDkMPgEdmbOvqy4O0adg" uri="guidances/guidelines/iteration_planning.xmi"/>
+ <resourceDescriptors xmi:id="_nDRE8_L5Edm6Nvont3uinw" id="_Fdq-8KX4EdmvhNXG0Oc2uA" uri="roles/project_manager.xmi"/>
+ <resourceDescriptors xmi:id="_nDXLkPL5Edm6Nvont3uinw" id="_IbVp8KX4EdmvhNXG0Oc2uA" uri="workproducts/project_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDXLkfL5Edm6Nvont3uinw" id="_K-e8IKX4EdmvhNXG0Oc2uA" uri="workproducts/status_assessment.xmi"/>
+ <resourceDescriptors xmi:id="_nDjY0PL5Edm6Nvont3uinw" id="_u6enMMM1EdmSIPI87WLu3g" uri="guidances/concepts/risk.xmi"/>
+ <resourceDescriptors xmi:id="_nDqGgPL5Edm6Nvont3uinw" id="_Dfmk8MPiEdmbOvqy4O0adg" uri="guidances/concepts/workspace.xmi"/>
+ <resourceDescriptors xmi:id="_nDqGg_L5Edm6Nvont3uinw" id="_LxX6AMM2EdmSIPI87WLu3g" uri="guidances/templates/vision.xmi"/>
+ <resourceDescriptors xmi:id="_nDqGhPL5Edm6Nvont3uinw" id="_OaB-UMM2EdmSIPI87WLu3g" uri="guidances/templates/uc_specification.xmi"/>
+ <resourceDescriptors xmi:id="_nDwNIPL5Edm6Nvont3uinw" id="_XjOXcMM2EdmSIPI87WLu3g" uri="guidances/templates/project_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDwNIfL5Edm6Nvont3uinw" id="_Z_bUIMM2EdmSIPI87WLu3g" uri="guidances/templates/iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDwNI_L5Edm6Nvont3uinw" id="_fJPGkMM2EdmSIPI87WLu3g" uri="guidances/templates/software_arch_document.xmi"/>
+ <resourceDescriptors xmi:id="_nD2TwPL5Edm6Nvont3uinw" id="_j2pQ4MM2EdmSIPI87WLu3g" uri="guidances/templates/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_nD2Tw_L5Edm6Nvont3uinw" id="_NqqcUqeqEdmKDbQuyzCoqQ" uri="roles/any_role.xmi"/>
+ <resourceDescriptors xmi:id="_nEzWAfL5Edm6Nvont3uinw" id="_Nqwi8KeqEdmKDbQuyzCoqQ" uri="tasks/detail_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_nGJZ0PL5Edm6Nvont3uinw" id="_5rJ78Lj3Edmy88CC3LfB_w" uri="tasks/define_vision.xmi"/>
+ <resourceDescriptors xmi:id="_nGJZ0vL5Edm6Nvont3uinw" id="_NrC20qeqEdmKDbQuyzCoqQ" uri="tasks/design_solution.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgcPL5Edm6Nvont3uinw" id="_qDRSULBKEdm7Eph_l9Cn9w" uri="tasks/analyze_arch_reqs.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgcfL5Edm6Nvont3uinw" id="_rUis8LBKEdm7Eph_l9Cn9w" uri="tasks/develop_arch.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgcvL5Edm6Nvont3uinw" id="_S8KCcMP2EdmWKcx6ixEiwg" uri="guidances/concepts/analysis_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgdfL5Edm6Nvont3uinw" id="_d2aMwKrMEdmqUqi7YGiSxw" uri="tasks/implement_solution.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnEPL5Edm6Nvont3uinw" id="_dWPe8KrMEdmqUqi7YGiSxw" uri="tasks/impl_developer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnEfL5Edm6Nvont3uinw" id="_W6rc0Lv7EdmmUvZAZjqE3g" uri="tasks/run_developer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnFPL5Edm6Nvont3uinw" id="_NrVKsKeqEdmKDbQuyzCoqQ" uri="tasks/create_test_cases.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnFfL5Edm6Nvont3uinw" id="_NrbRUKeqEdmKDbQuyzCoqQ" uri="tasks/implement_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGbtsPL5Edm6Nvont3uinw" id="_NrbRUqeqEdmKDbQuyzCoqQ" uri="tasks/run_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGbtsfL5Edm6Nvont3uinw" id="_uqL2gMM3EdmSIPI87WLu3g" uri="guidances/concepts/test_ideas.xmi"/>
+ <resourceDescriptors xmi:id="_nGbttPL5Edm6Nvont3uinw" id="_Wk7noKe1EdmGSrcKGOYDGg" uri="tasks/plan_iteration.xmi"/>
+ <resourceDescriptors xmi:id="_nGh0UfL5Edm6Nvont3uinw" id="_fPbdIKe2Edmzde8VFK5bxg" uri="tasks/plan_the_project.xmi"/>
+ <resourceDescriptors xmi:id="_nGh0VfL5Edm6Nvont3uinw" id="_a3uz4LBYEdm7Eph_l9Cn9w" uri="tasks/assess_results.xmi"/>
+ <resourceDescriptors xmi:id="_nGn68PL5Edm6Nvont3uinw" id="_7ygXoMM3EdmSIPI87WLu3g" uri="guidances/concepts/metrics.xmi"/>
+ <resourceDescriptors xmi:id="_nGuBkPL5Edm6Nvont3uinw" id="_Nr0S4KeqEdmKDbQuyzCoqQ" uri="tasks/request_change.xmi"/>
+ <resourceDescriptors xmi:id="_nG6O0_L5Edm6Nvont3uinw" id="_0nJNkclgEdmt3adZL5Dmdw" uri="capabilitypatterns/manage_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVcfL5Edm6Nvont3uinw" id="_0nz79MlgEdmt3adZL5Dmdw" uri="capabilitypatterns/test/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVcvL5Edm6Nvont3uinw" id="_0oSdEclgEdmt3adZL5Dmdw" uri="capabilitypatterns/inception_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVc_L5Edm6Nvont3uinw" id="_0o9ygMlgEdmt3adZL5Dmdw" uri="capabilitypatterns/manage_requirements/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVdPL5Edm6Nvont3uinw" id="_0pJ_xclgEdmt3adZL5Dmdw" uri="capabilitypatterns/ongoing_tasks/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVdfL5Edm6Nvont3uinw" id="_0pWNAslgEdmt3adZL5Dmdw" uri="capabilitypatterns/initiate_project/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHGcEfL5Edm6Nvont3uinw" id="_0qrpwMlgEdmt3adZL5Dmdw" uri="capabilitypatterns/transition_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHGcEvL5Edm6Nvont3uinw" id="_0rWYIMlgEdmt3adZL5Dmdw" uri="capabilitypatterns/elaboration_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHGcFPL5Edm6Nvont3uinw" id="_0sluQclgEdmt3adZL5Dmdw" uri="capabilitypatterns/determine_architectural_feasibility/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHMisPL5Edm6Nvont3uinw" id="_0sx7iclgEdmt3adZL5Dmdw" uri="capabilitypatterns/define_architecture/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHSpUPL5Edm6Nvont3uinw" id="_0uHYQclgEdmt3adZL5Dmdw" uri="deliveryprocesses/openup_basic_process/model.xmi"/>
+ <resourceDescriptors xmi:id="_nt4IMfL5Edm6Nvont3uinw" id="_s60KoMM3EdmSIPI87WLu3g" uri="guidances/guidelines/test_suite.xmi"/>
+ <resourceDescriptors xmi:id="_nuo9MPL5Edm6Nvont3uinw" id="_On0agNSAEdmLhZ9H5Plxyw" uri="guidances/guidelines/req_gathering_techniques.xmi"/>
+ <resourceDescriptors xmi:id="_nuo9MvL5Edm6Nvont3uinw" id="_iCwb8MM3EdmSIPI87WLu3g" uri="guidances/guidelines/repres_interfaces_to_ext_systems.xmi"/>
+ <resourceDescriptors xmi:id="_nuo9M_L5Edm6Nvont3uinw" id="_lbGQwMM3EdmSIPI87WLu3g" uri="guidances/guidelines/layering.xmi"/>
+ <resourceDescriptors xmi:id="_nu1KcPL5Edm6Nvont3uinw" id="_qS8JcMM3EdmSIPI87WLu3g" uri="guidances/guidelines/failure_analysis_rpt_creation.xmi"/>
+ <resourceDescriptors xmi:id="_nu7REPL5Edm6Nvont3uinw" id="_y3rxsMM3EdmSIPI87WLu3g" uri="guidances/guidelines/test_ideas.xmi"/>
+ <resourceDescriptors xmi:id="_nu7REfL5Edm6Nvont3uinw" id="_vuwC4MPcEdmbOvqy4O0adg" uri="guidances/guidelines/programming_automated_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nu7REvL5Edm6Nvont3uinw" id="_8ngBgMPdEdmbOvqy4O0adg" uri="guidances/guidelines/maintaining_automated_test_suite.xmi"/>
+ <resourceDescriptors xmi:id="_QATTEPV_EdmdHa9MmVPgqQ" id="_P9iS8PV_EdmdHa9MmVPgqQ" uri="tasks/find_and_outline_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_h3jw0PimEdmugcVr9AdHjQ" id="_h2-iAPimEdmugcVr9AdHjQ" uri="capabilitypatterns/develop_solution/model.xmi"/>
+ <resourceDescriptors xmi:id="_AaS4AP1VEdmek8CQTQgrOQ" id="_AYGfoP1VEdmek8CQTQgrOQ" uri="disciplinegroupings/openup_basic_disciplines.xmi"/>
+ <resourceDescriptors xmi:id="_CY764BEdEdqY7JB6N6CW2w" id="_CYRMgBEdEdqY7JB6N6CW2w" uri="guidances/guidelines/agile_estimation.xmi"/>
+ <resourceDescriptors xmi:id="_g5NaAB85Edqsvps02rpOOg" id="-aCI9T-9TIe8D35yXBU6qvg" uri="guidances/supportingmaterials/references.xmi"/>
+ <resourceDescriptors xmi:id="_t_ZKUCbSEdqh1LYUOGRh2A" id="-buxz4BVToq97bSxaqyjySg" uri="workproducts/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_8UFwQCbYEdqh1LYUOGRh2A" id="-PbfqVxB_j9KN-Jx39_pEUA" uri="tasks/manage_iteration.xmi"/>
+ <resourceDescriptors xmi:id="_89PC0Cb3Edqh1LYUOGRh2A" id="-BsXK3ZGMm-mUT0KnkdoYBg" uri="guidances/concepts/change_requests.xmi"/>
+ <resourceDescriptors xmi:id="_jtUSACu-EdqSxKAVa9kmvA" id="-Rcm_MlViENAvFFyIe9V3dQ" uri="guidances/guidelines/find_and_outline_actors_and_ucs.xmi"/>
+ <resourceDescriptors xmi:id="_7ymQsCxSEdqjsdw1QLH_6Q" id="-78ko4CuOJERKJF9ZvwMUBQ" uri="guidances/guidelines/detail_ucs_and_scenarios.xmi"/>
+ <resourceDescriptors xmi:id="_8XiwQDz6Edq03rqPoNVoKg" id="-5S6ney_fFdEHm49XznPRiA" uri="workproducttypes/assessment.xmi"/>
+ <resourceDescriptors xmi:id="_DK-L4Dz7Edq03rqPoNVoKg" id="-Nl-rJ_6aaAG2jpJyGm_wcg" uri="workproducttypes/concept.xmi"/>
+ <resourceDescriptors xmi:id="_MQnhwTz7Edq03rqPoNVoKg" id="-CKZiRxRx_TZhMbquLd4Sqw" uri="workproducttypes/infrastructure.xmi"/>
+ <resourceDescriptors xmi:id="_Sxgb4Dz7Edq03rqPoNVoKg" id="-ARfZUsgYE1XrKQlDgr9mEQ" uri="workproducttypes/model.xmi"/>
+ <resourceDescriptors xmi:id="_Wp1YUDz7Edq03rqPoNVoKg" id="-cW3aVzDjHhqkVayoItUQqw" uri="workproducttypes/model_element.xmi"/>
+ <resourceDescriptors xmi:id="_hOtFQDz7Edq03rqPoNVoKg" id="-vpMAMS8Cz-z9DQQhxbjjLA" uri="workproducttypes/plan.xmi"/>
+ <resourceDescriptors xmi:id="_mDSOkDz7Edq03rqPoNVoKg" id="-DBPx56p4GCNFpRTT8uOmiQ" uri="workproducttypes/project_data.xmi"/>
+ <resourceDescriptors xmi:id="_tJVrQDz7Edq03rqPoNVoKg" id="-sIh01vzZACgxRrG_sv7DVw" uri="workproducttypes/solution.xmi"/>
+ <resourceDescriptors xmi:id="_69Xb0Dz7Edq03rqPoNVoKg" id="-C5ih3s1Vn_9qQbjm85-GYg" uri="workproducttypes/specification.xmi"/>
+ <resourceDescriptors xmi:id="_bL9KAL3vEdqLRJZPGVbHDA" id="-_BAmniONtHWbpHQH7znR3g" uri="tasks/design_solution_vm.xmi"/>
+ <resourceDescriptors xmi:id="_x-s5sMWdEdqiT9CqkRksWQ" id="-15BvSftWbF7VdZ_W8YycBQ" uri="domains/openup_basic_wp.xmi"/>
+ <resourceDescriptors xmi:id="_aIutoMWeEdqiT9CqkRksWQ" id="-9qPK9k01PN_COE9YPXpw8Q" uri="domains/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_2zkhcMWeEdqiT9CqkRksWQ" id="-X9nP8esP9nWMvx1wmMaJAA" uri="domains/change_management.xmi"/>
+ <resourceDescriptors xmi:id="_Lp3a4cWfEdqiT9CqkRksWQ" id="-xO3vqWsd3W98UXFsyp-wGA" uri="domains/development.xmi"/>
+ <resourceDescriptors xmi:id="_WlKDwcWfEdqiT9CqkRksWQ" id="-N4r_U0LZhZ_K-8gfHON9BA" uri="domains/project_management.xmi"/>
+ <resourceDescriptors xmi:id="_kGPDIcWfEdqiT9CqkRksWQ" id="-d5O4LFNaAs4YRDxfxH3CRw" uri="domains/requirements.xmi"/>
+ <resourceDescriptors xmi:id="_tTZ9UcWfEdqiT9CqkRksWQ" id="-Mxgu9hq0upbMqZlq1xBFYw" uri="domains/test.xmi"/>
+ <resourceDescriptors xmi:id="_jHV4oNVbEdqy9sbRhejO5Q" id="-w7sImtXWkf4HDXdUWjRsUg" uri="guidances/guidelines/submitting_change_requests.xmi"/>
+ <resourceDescriptors xmi:id="_FFod4NVuEdqWcvghdb0qxA" id="-bUmvEAAtFf6B0aUCux8k9Q" uri="guidances/guidelines/assign_changes_to_iteration.xmi"/>
+ <resourceDescriptors xmi:id="_BaPxINb2Edq_LtLvi4w2yw" id="-CFYVionNDLkMw6SG6runQA" uri="guidances/guidelines/uc_realizations.xmi"/>
+ <resourceDescriptors xmi:id="_Bab-YNb2Edq_LtLvi4w2yw" id="-6ep_EyK3ZO6vRGWtAqoJ-A" uri="guidances/guidelines/design_components.xmi"/>
+ <resourceDescriptors xmi:id="_2soicNb2Edq_LtLvi4w2yw" id="-_dNuyh-0q5vpCiIiLfbj6w" uri="workproducts/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_kIZk4bUNEdqI644ssJaKYg" id="-0sCBiohjw_wBDKk0WEeDJQ" uri="guidances/termdefinitions/requirement.xmi"/>
+ <resourceDescriptors xmi:id="_BW4HgNcLEdqz_d2XWoVt6Q" id="-AJQLv2ldVv5KN9eUbdQe_g" uri="guidances/guidelines/writing_good_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_V7RtwNcNEdqz_d2XWoVt6Q" id="-pNA0DbSdSoUqnjQIiOeHcQ" uri="guidances/guidelines/effective_req_reviews.xmi"/>
+ <resourceDescriptors xmi:id="_ffK0QMvoEdqukPpotm3DYg" id="-aMD1wQVJLzzlMARfHBdOBQ" uri="guidances/concepts/core_principle_evolve.xmi"/>
+ <resourceDescriptors xmi:id="_PUrQsMvqEdqukPpotm3DYg" id="-I4IbR1GW6IFBCdq9SiMUsw" uri="guidances/concepts/core_principle_balance.xmi"/>
+ <resourceDescriptors xmi:id="_VIeQwMvpEdqukPpotm3DYg" id="-HTMJFV29MTZkKWqnIo01Gg" uri="guidances/concepts/core_principle_focus.xmi"/>
+ <resourceDescriptors xmi:id="_aV48scp8EdqC_NfSivunjA" id="-IXfkG-XfnoEo0xgux482Kw" uri="guidances/concepts/core_principle_collaborate.xmi"/>
+ <resourceDescriptors xmi:id="_jkD6kNohEdqJa75enFTwVQ" id="-XR2Rbg25yN80p1exWC4MHg" uri="guidances/supportingmaterials/openup_basic_home.xmi"/>
+ <resourceDescriptors xmi:id="_mfuHQN-vEdqiM_wFaqLjNg" id="-At_b3UIzbgdmtJsb2Ymfhg" uri="guidances/roadmaps/openup_basic_roadmap.xmi"/>
+ <resourceDescriptors xmi:id="_z-TykOtQEdqc1LGhiSPqRg" id="_y-etQOtQEdqc1LGhiSPqRg" uri="capabilitypatterns/construction_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_VyNPIOz3Edq2wJOsmRwmhg" id="-iOn7_gfX_iELWRNGJ2JKPQ" uri="workproducts/glossary.xmi"/>
+ <resourceDescriptors xmi:id="_BaLJYNbaEdqrw4BYKyYKiA" id="-FsyxZy4tyX8k5CxT5Jww_w" uri="guidances/templates/supporting_requirements_spec.xmi"/>
+ <resourceDescriptors xmi:id="_lXzjoOz6Edq2wJOsmRwmhg" id="-BQLZ5GRUNrMdU6XeZAfe9Q" uri="guidances/concepts/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_0nV8oNk1Edq2Q8qZoWbvGA" id="-T2IeqdOunweffIDgL-aM0w" uri="guidances/checklists/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_kjwkoO0HEdqHTdbLTmC5IQ" id="-2o1pXjHpSEPN_rohLce5jA" uri="guidances/checklists/good_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_WES08O0IEdqHTdbLTmC5IQ" id="-3SXuKijeVOZalgLPgWRyFA" uri="guidances/concepts/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_1kU3wO0JEdqHTdbLTmC5IQ" id="-Q72-dNdHnZ93aRXAB_d34A" uri="guidances/guidelines/requirement_pitfalls.xmi"/>
+ <resourceDescriptors xmi:id="_V1DNIO0KEdqHTdbLTmC5IQ" id="-fCBrf_5JlrmuKgyrCaKGOA" uri="guidances/concepts/requirement_attributes.xmi"/>
+ <resourceDescriptors xmi:id="_e_SvIO0KEdqHTdbLTmC5IQ" id="-TksCtMgc0b4QqzwzniGvIw" uri="guidances/concepts/traceability.xmi"/>
+ <resourceDescriptors xmi:id="_gc724PDxEdqYgerqi84oCA" id="-awaQ_2dwhGyKRoVKQ-esPQ" uri="guidances/concepts/entity_control_boundary_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_B5BhQPD0EdqYgerqi84oCA" id="-dhAMzNZNWufBnW0fPYQtBA" uri="guidances/concepts/continuous_integration.xmi"/>
+ <resourceDescriptors xmi:id="_svkl0PD0EdqYgerqi84oCA" id="-DlaqJu4sEqMPk84qhJ6IEA" uri="guidances/guidelines/continuous_integration.xmi"/>
+ <resourceDescriptors xmi:id="_2buasPD3EdqYgerqi84oCA" id="-zCM2ucJJxc_bQr_LoHlSaQ" uri="guidances/guidelines/promoting_builds.xmi"/>
+ <resourceDescriptors xmi:id="_I6hwsPGaEdqiDINUyockoA" id="-WFD3nKccpkueaG15cHT-fA" uri="guidances/supportingmaterials/about_openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_Uf9gUPvuEdqf0-top1XJIg" id="-xbAirPdH1IOKcnklk8hdqw" uri="roles/developer_vm.xmi"/>
+ <resourceDescriptors xmi:id="_dEVfgACsEdu8m4dIntu6jA" id="-HhGIkAPjHSIxnPzI3cyDnQ" uri="guidances/concepts/risk_management.xmi"/>
+ <resourceDescriptors xmi:id="_ePUlgAFoEduDPKiaP0pu-Q" id="-Yt8TXGkE1rwydXR34apsrg" uri="tasks/find_and_outline_requirements_intent_req_ucm.xmi"/>
+ <resourceDescriptors xmi:id="__WjDgAXmEduZUPWQRyV4zQ" id="-pQrBSyxJHLLodLbS4R_Zdw" uri="guidances/guidelines/use_case_formats.xmi"/>
+ <resourceDescriptors xmi:id="_VbT-cAeYEduWycDgioo5rg" id="-qpBnpWqiD7gjT08LjTMbsQ" uri="guidances/termdefinitions/feature.xmi"/>
+ <resourceDescriptors xmi:id="_d1sJwQeYEduWycDgioo5rg" id="-1pmL5bC27rtWB84PXAgq9Q" uri="guidances/termdefinitions/stakeholder_need.xmi"/>
+ <resourceDescriptors xmi:id="_-KDQoAhWEduRe8TeoBmuGg" id="-yEWkrWZ3VUcjZPhq6bvScg" uri="guidances/concepts/use_case_model.xmi"/>
+ <resourceDescriptors xmi:id="_43csUA3tEduibvKwrGxWxA" id="-YeVRerdEixh4HgHOuw2KRQ" uri="guidances/guidelines/analyze_arch_reqs.xmi"/>
+ <resourceDescriptors xmi:id="_ovE-8A4LEduibvKwrGxWxA" id="-SJrpVySJ2npYs8NwGvnHjw" uri="guidances/concepts/arch_mech.xmi"/>
+ <resourceDescriptors xmi:id="_xCNSwA4LEduibvKwrGxWxA" id="-EG22TRyJ5TDKW6U88AXfhw" uri="guidances/concepts/design_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_0XXQsA4LEduibvKwrGxWxA" id="-Rex8oOBv985RruZNrCW0rg" uri="guidances/concepts/implementation_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_4mCQkA4LEduibvKwrGxWxA" id="-CJ--jlBqXi3FzdOM_dw5_w" uri="guidances/guidelines/example_analysis_mechanisms_descr.xmi"/>
+ <resourceDescriptors xmi:id="_4mIXMA4LEduibvKwrGxWxA" id="-FqP5LgLVrlhvFC_eeYd_vA" uri="guidances/guidelines/example_architectural_mechanisms.xmi"/>
+ <resourceDescriptors xmi:id="_4mOd0A4LEduibvKwrGxWxA" id="-mAo18f36rZ1R98kpZX7HMw" uri="guidances/guidelines/example_design_mechanisms.xmi"/>
+ <resourceDescriptors xmi:id="_HsocQA4MEduibvKwrGxWxA" id="-EytH4BCNGiHF6pZrp8ISCw" uri="guidances/concepts/architecturally_significant_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_NqskoBOHEduCNqgZdt_OaA" id="-Ss8EBFGKz6PI_08BAjuUwQ" uri="customcategories/core_principles_cat.xmi"/>
+ <resourceDescriptors xmi:id="_eMOOgBONEduCNqgZdt_OaA" id="-GRJW_KNOJoEQF3r6lmBrEw" uri="guidances/concepts/inception_phase.xmi"/>
+ <resourceDescriptors xmi:id="_CyjSMBOOEduCNqgZdt_OaA" id="-F-eWIBzxEXE1jygbN3nrrQ" uri="guidances/concepts/elaboration_phase.xmi"/>
+ <resourceDescriptors xmi:id="_esJPQBOOEduCNqgZdt_OaA" id="-bbpT_BdDRrv6waNI365Qhg" uri="guidances/concepts/construction_phase.xmi"/>
+ <resourceDescriptors xmi:id="_B2T28ROPEduCNqgZdt_OaA" id="-FrUmsKsGW4bnNmb9uaNOkg" uri="guidances/concepts/transition_phase.xmi"/>
+ <resourceDescriptors xmi:id="_Z7gJgBapEduSTJywppIxVQ" id="-Of51hmgdsO_U2-pnbJ67Cg" uri="guidances/concepts/business_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_nrMMoBapEduSTJywppIxVQ" id="-t7mQSRPYITkMoYRVNz7jQg" uri="guidances/guidelines/develop_architecture.xmi"/>
+ <resourceDescriptors xmi:id="_XSM3sBjoEduxUfEVCtmW4Q" id="-cy0DcnEk7uJJ1OOH3_E6rg" uri="guidances/supportingmaterials/delivery_process_graph.xmi"/>
+ <resourceDescriptors xmi:id="_BQ2N8CF7Edu3VKXZx45D3A" id="-BdYFG4-dbPBGFzF9z6KGPA" uri="guidances/guidelines/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_pyUo0CGMEdu3VKXZx45D3A" id="-kw2vYHKDkWv2tZrDMrBPNA" uri="guidances/checklists/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_lZIzECcTEduSX6N2jUafGA" id="-RNyaB6jxqoopm9fJU8k9vg" uri="guidances/supportingmaterials/openup_copyright.xmi"/>
+ <resourceDescriptors xmi:id="_XcJIYCdCEduIsqH1Q6ZuqA" id="-4VJ_0upihz-bR7VRlm63Vw" uri="workproducts/risk_list.xmi"/>
+ <resourceDescriptors xmi:id="_o3qSICdEEduIsqH1Q6ZuqA" id="-DG8mYMnTGosWIxjPQFUoTA" uri="guidances/concepts/milestones.xmi"/>
+ <resourceDescriptors xmi:id="_9JydECk9EduLGM8dfVsrKg" id="-1Lm8-0FY-QIC56u5t2SC9w" uri="guidances/templates/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_ZXEuAClFEduLGM8dfVsrKg" id="-cnGBBA4NXmhTIjHjlHx4Mw" uri="guidances/guidelines/architectural_view.xmi"/>
+ <resourceDescriptors xmi:id="_2hWugClTEduLGM8dfVsrKg" id="-U-5cLUk-mdaO518lh5CxTQ" uri="guidances/guidelines/using_patterns.xmi"/>
+ <resourceDescriptors xmi:id="_DLM38ColEduK2emCyq5fBw" id="-X7QSjItNBz7w8603yBCv0Q" uri="guidances/guidelines/abstract_away_complexity.xmi"/>
+ <resourceDescriptors xmi:id="_XQS1oC5REduVhuZHT5jKZQ" id="-VGT8iHGtQSiOUGitq1qmow" uri="guidances/guidelines/types_of_developer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_dWGwgC8FEduzydamRseoUw" id="-OugFZJszm73z0_KSwRXZPw" uri="guidances/templates/risk_list.xmi"/>
+ <resourceDescriptors xmi:id="_TVGdwDBGEduMqpUNhaTSRA" id="-1xE2ZW3MjNAJ7jkaZNbkww" uri="guidances/guidelines/designing_visually.xmi"/>
+ <resourceDescriptors xmi:id="_i5pNMDFYEduMqpUNhaTSRA" id="-fj_9xjbrpaYNSETyCz5yJg" uri="guidances/concepts/refactoring.xmi"/>
+ <resourceDescriptors xmi:id="_JNr6YDIeEduDTv4Y1akVTA" id="-gqNN4DnROmJpgKtrdguhpg" uri="guidances/checklists/risk_list.xmi"/>
+ <resourceDescriptors xmi:id="__Fy8ATIrEduDTv4Y1akVTA" id="-945-1xTnAeJZR0Z9oYMJDA" uri="customcategories/getting_started.xmi"/>
+ <resourceDescriptors xmi:id="__GLWgTIrEduDTv4Y1akVTA" id="-kiltuUhgu5dbjVjvA3l_kg" uri="customcategories/about.xmi"/>
+ <resourceDescriptors xmi:id="__GRdIDIrEduDTv4Y1akVTA" id="-8uqXjzIOnt6LVDae6Uv_0w" uri="customcategories/openup_basic_views.xmi"/>
+ <resourceDescriptors xmi:id="__GXjwDIrEduDTv4Y1akVTA" id="-nY50CawHefla4zauYddVfw" uri="customcategories/openup_basic_deprecated.xmi"/>
+ <resourceDescriptors xmi:id="_HJ9fYDIvEduDTv4Y1akVTA" id="-vErMTo5DGQ1v_3_GNsccNw" uri="workproducts/design_vm%202.xmi"/>
+ <resourceDescriptors xmi:id="__wASEDRZEdudA-StyUUwnw" id="-SUqkkwrs1D_5YXZls-3YBg" uri="workproducts/supporting_requirements_intent_req.xmi"/>
+ <resourceDescriptors xmi:id="_nxdG4DRcEduFvfVCXiK3AA" id="-JcGDIeBIMM099mbWX5fXbA" uri="workproducts/use_case_intent_req.xmi"/>
+ <resourceDescriptors xmi:id="_7WIYYDg2Edu4E8ZdmlYjtA" id="-G1Oxlk6F0R09vClqy1EzOw" uri="guidances/guidelines/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_gTd74Dj9EduxovfWMDsntw" id="-mPA7vone29k1OvF_1rACjg" uri="guidances/templates/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_HU76YDkAEduxovfWMDsntw" id="-qunTPN3vqTIGpELwajXpLA" uri="guidances/examples/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_WrOAgDkDEduxovfWMDsntw" id="-vi8wxwxVZLY0SMPFxZjD7A" uri="guidances/concepts/iteration.xmi"/>
+ <resourceDescriptors xmi:id="_HhqNQDn8Edu_y4hBImiwwQ" id="-fDVhZTkf1TqDyExbI9DM-w" uri="workproducts/work_items_list_pm.xmi"/>
+ <resourceDescriptors xmi:id="_wpM84Dn9EduEpvsDmUyxqg" id="-b9hejTMj8E7U4g2v80xDjA" uri="workproducts/iteration_plan_pm.xmi"/>
+ <resourceDescriptors xmi:id="_UItQgDoAEdusGsHODb-STA" id="-IdlCQXdDNYGrGJU4TBwvCA" uri="guidances/examples/project_plan.xmi"/>
+ <resourceDescriptors xmi:id="_eSrjED6TEduAL-bCqar_dg" id="-HQSI39vBrjpmQL1qHYOJtA" uri="guidances/checklists/design_vm.xmi"/>
+ <resourceDescriptors xmi:id="_FG9cgEE7EdulKujnGUuxbg" id="-nDr0XNiUWBo6VS1YS6KAqA" uri="guidances/examples/iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_eRfk4EcmEdu6ianenth5PQ" id="-Aw8p59vJ9rWsOV82rljQiQ" uri="guidances/reports/iteration_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_NmdiMEf7EduISP1GQDlvVQ" id="-_mfd9ziTwQV_5LE80jJw4g" uri="tasks/detail_requirements_intent_req_ucm.xmi"/>
+ <resourceDescriptors xmi:id="_TrtRwElyEducWJcS4yanqg" id="-VPoMu7qzVX9grE4-nB3kMw" uri="guidances/termdefinitions/configuration.xmi"/>
+ <resourceDescriptors xmi:id="_jtrgkElyEducWJcS4yanqg" id="-4iL0UEFR2Fg7oWkh1TymIg" uri="guidances/termdefinitions/version.xmi"/>
+ <resourceDescriptors xmi:id="_xoyz8EmbEdu0xduwSKie-w" id="-1ZoXO1IRfkXUKej4bNv8cw" uri="customcategories/sub_processes.xmi"/>
+ <resourceDescriptors xmi:id="_3JNIgEmbEdu0xduwSKie-w" id="-NMF-a9hwKjzWNfHzzseDYQ" uri="customcategories/collab_commun_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_FMk8oEmcEdu0xduwSKie-w" id="-QRnsN2e6IQlSMaRts-wFNw" uri="customcategories/intent_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_FMrDQEmcEdu0xduwSKie-w" id="-q8ubSlQ5miYcY1JXdj1fbQ" uri="customcategories/management_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_Mjm0kEmcEdu0xduwSKie-w" id="-qwWeiX7WrSVHSluBe-J7yw" uri="customcategories/solution_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_1BKVgEptEduVV9JixWe5Rw" id="-hrDndmFd0zexB0HNYX3gww" uri="guidances/reports/project_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_Id32wEp3Edup0IY9DKDPkg" id="-2uQACndDBzBhJC1sCmk5UA" uri="guidances/templates/status_assessment.xmi"/>
+ <resourceDescriptors xmi:id="_09MY8EyFEdu-df7p0PuRvQ" id="-XMbxFU8M85cRlf3C4iwAGw" uri="guidances/guidelines/data_modeling.xmi"/>
+ <resourceDescriptors xmi:id="_DMZa8EvIEdunZcj9T5hrMQ" id="-0g2jTHQla8lbP6xGB3iGlg" uri="guidances/termdefinitions/elaboration.xmi"/>
+ <resourceDescriptors xmi:id="_5QECwEvJEdunZcj9T5hrMQ" id="-MllWL01NL93RTB7VsY69fw" uri="guidances/termdefinitions/lca_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_TsOyAEvqEdunZcj9T5hrMQ" id="-9fXEOvMc4t7y6s5GscBD1Q" uri="guidances/termdefinitions/milestone.xmi"/>
+ <resourceDescriptors xmi:id="_iZ-GsEvHEdunZcj9T5hrMQ" id="-_G0VvVOdMoajk615LwFtxg" uri="guidances/termdefinitions/iteration.xmi"/>
+ <resourceDescriptors xmi:id="_5KcVYUvpEdunZcj9T5hrMQ" id="-yoFF90pq-_UV3fm-5oDenw" uri="guidances/termdefinitions/transition.xmi"/>
+ <resourceDescriptors xmi:id="_tgigkEvJEdunZcj9T5hrMQ" id="-Rl8kaRW9Bxqdvq32kVCi7w" uri="guidances/termdefinitions/lco_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_4dN4QEvDEdunZcj9T5hrMQ" id="-5wJmUR0WqX7lCIxsyqFsdA" uri="guidances/termdefinitions/construction.xmi"/>
+ <resourceDescriptors xmi:id="_EAp3gEvKEdunZcj9T5hrMQ" id="-gEgZg2UkFLjGeXkJLpAP6A" uri="guidances/termdefinitions/ioc_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_Nh-cwEvKEdunZcj9T5hrMQ" id="-JegYQHIteCRN0iV2EKMjSA" uri="guidances/termdefinitions/pr_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_5qob4EvqEdunZcj9T5hrMQ" id="-qZE4XgeMK93LmJMKuQWGFg" uri="guidances/termdefinitions/agile.xmi"/>
+ <resourceDescriptors xmi:id="_D7dnwEvFEdunZcj9T5hrMQ" id="-dhgOQQ4GsV0-dNJmTmF9GA" uri="guidances/termdefinitions/inception.xmi"/>
+ <resourceDescriptors xmi:id="_hQyYcEvEEdunZcj9T5hrMQ" id="-vq2pL6yQuqGhql9Wo_Av4w" uri="guidances/termdefinitions/furps.xmi"/>
+ <resourceDescriptors xmi:id="_TgQIUUvmEdunZcj9T5hrMQ" id="-t3jNM5ZWkYtzB8A4Chz2Vw" uri="guidances/termdefinitions/use_case_scenario.xmi"/>
+ <resourceDescriptors xmi:id="_uzNYoUvlEdunZcj9T5hrMQ" id="-HDfMzDXoilK-f2iNreHRVg" uri="guidances/termdefinitions/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_gjU_EUvQEdunZcj9T5hrMQ" id="-ketzwgDgY82DMyfuHqu3Cw" uri="guidances/termdefinitions/supporting_requirement.xmi"/>
+ <resourceDescriptors xmi:id="_Oz_loEvHEdunZcj9T5hrMQ" id="-VMnkFJpPLdEDUpbz2QDgow" uri="guidances/termdefinitions/vision.xmi"/>
+ <resourceDescriptors xmi:id="_nzyS8UvmEdunZcj9T5hrMQ" id="-UTrE64wEDJIC1FRUomEYDg" uri="guidances/termdefinitions/use_case_model.xmi"/>
+ <resourceDescriptors xmi:id="_cuUoIEvrEdunZcj9T5hrMQ" id="-05pn_DGdNui9qqwx46iKZQ" uri="guidances/termdefinitions/glossary.xmi"/>
+ <resourceDescriptors xmi:id="_5LUmUUvBEdunZcj9T5hrMQ" id="-4RQJzq_1URTZ5FGCBKnTIw" uri="guidances/termdefinitions/actor.xmi"/>
+ <resourceDescriptors xmi:id="_R2ylEEvDEdunZcj9T5hrMQ" id="-COrjB4k8Qtf6ZpPEcBNwpw" uri="guidances/termdefinitions/business_rule.xmi"/>
+ <resourceDescriptors xmi:id="_MGOxIUvCEdunZcj9T5hrMQ" id="-1RwpgmmY974S0YkxEOFDCw" uri="guidances/termdefinitions/analyst.xmi"/>
+ <resourceDescriptors xmi:id="_KbS1UEvuEdunZcj9T5hrMQ" id="-oShmMITo9RIi1AzACWI9vw" uri="guidances/termdefinitions/point.xmi"/>
+ <resourceDescriptors xmi:id="_Kl_0AEvvEdunZcj9T5hrMQ" id="-1Oc9t_TLaBgW_YLugZcq7w" uri="guidances/termdefinitions/work_item.xmi"/>
+ <resourceDescriptors xmi:id="_VEO_YEvtEdunZcj9T5hrMQ" id="-KQTbqDSJXR8KLBxIgGVquA" uri="guidances/termdefinitions/work_breakdown_structure.xmi"/>
+ <resourceDescriptors xmi:id="_qjj5oEvrEdunZcj9T5hrMQ" id="-hOtatvr8wIjqW8UD0MSGhQ" uri="guidances/termdefinitions/risk.xmi"/>
+ <resourceDescriptors xmi:id="_gdtuMUvvEdunZcj9T5hrMQ" id="-NNByAM5YsjCu39flaOSZtQ" uri="guidances/termdefinitions/project_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_RJ6pcUvuEdunZcj9T5hrMQ" id="-mgWkuUy3q0zzFaxE7DY1ag" uri="guidances/termdefinitions/velocity.xmi"/>
+ <resourceDescriptors xmi:id="_98ybUUvvEdunZcj9T5hrMQ" id="-3G3HV0opAmFWGxYgsD5AhA" uri="guidances/termdefinitions/iteration_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_RPuOIEv8EdunZcj9T5hrMQ" id="-h1poMaxtQbmg6hD5772oVw" uri="guidances/termdefinitions/scope.xmi"/>
+ <resourceDescriptors xmi:id="_wVAzgEvuEdunZcj9T5hrMQ" id="-WIgtkwJN71D51FdcQs-TzQ" uri="guidances/termdefinitions/effort.xmi"/>
+ <resourceDescriptors xmi:id="_zbijkEvCEdunZcj9T5hrMQ" id="-2QB1bosN011CudkwZ0cn-g" uri="guidances/termdefinitions/architect.xmi"/>
+ <resourceDescriptors xmi:id="_J9kvoUvPEdunZcj9T5hrMQ" id="-802sCZ4lJcejyRbhLmkxkw" uri="guidances/termdefinitions/developer.xmi"/>
+ <resourceDescriptors xmi:id="_n2PogUvPEdunZcj9T5hrMQ" id="-6oW2YOnoWq_xPpmoil91KA" uri="guidances/termdefinitions/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_beLg0UvpEdunZcj9T5hrMQ" id="-Wh-byAGHoy_gGry0Jq6VaA" uri="guidances/termdefinitions/build.xmi"/>
+ <resourceDescriptors xmi:id="_WK10YUvoEdunZcj9T5hrMQ" id="-VJBtRm2brEKpRlnLWNF8_g" uri="guidances/termdefinitions/pattern.xmi"/>
+ <resourceDescriptors xmi:id="_a7dNEUvPEdunZcj9T5hrMQ" id="-prQBbamJ4CLPywfEbyaPaA" uri="guidances/termdefinitions/tester.xmi"/>
+ <resourceDescriptors xmi:id="_kGVesUvDEdunZcj9T5hrMQ" id="-BWZsh3vKrqSOzfkBJmDTLA" uri="guidances/termdefinitions/component.xmi"/>
+ <resourceDescriptors xmi:id="_HKvSQUvoEdunZcj9T5hrMQ" id="-YMvJ5LwexkcVWWqLdm5-nQ" uri="guidances/termdefinitions/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_aenL8UvCEdunZcj9T5hrMQ" id="-Vvwb6EupIB9kfSQ_mhjURA" uri="guidances/termdefinitions/architectural_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_q-5HYUvCEdunZcj9T5hrMQ" id="-0vih7gB84YYDheaH7jeYFQ" uri="guidances/termdefinitions/architectural_view.xmi"/>
+ <resourceDescriptors xmi:id="_hwX4sE_8Edu-kbBL8pBzSQ" id="-9gUpkUYqONF3x8UWwAO_zw" uri="guidances/concepts/failure_analysis_rpt_creation%202.xmi"/>
+ <resourceDescriptors xmi:id="_jrhTMJjsEduad8I_c-ogIA" id="-HYO1lwAFOxlT7ncq8EjSng" uri="guidances/guidelines/staffing_project.xmi"/>
+ <resourceDescriptors xmi:id="_2IlrcJjsEduad8I_c-ogIA" id="-e26WOHRbTVQrDssK5zijVA" uri="guidances/guidelines/self_organize_work_assignments.xmi"/>
+ <resourceDescriptors xmi:id="_FnGbYJqvEdukqcRKZBQN9w" id="-Ff1JwbrGt1laexkOB6ZM1Q" uri="guidances/concepts/developer_testing.xmi"/>
+ <resourceDescriptors xmi:id="_NYFZcJt1EdutoZjlV3a4Lg" id="-RlYzPnl6Pig2H851hHebBA" uri="guidances/termdefinitions/code_instrumentation.xmi"/>
+ <resourceDescriptors xmi:id="_WFzxwKrPEdu6T6WyNqBzqQ" id="-zfl87vJBFdinDB02ArLXOQ" uri="guidances/concepts/component_vm.xmi"/>
+ <resourceDescriptors xmi:id="_lQP7EKzREduOqvpk_MDLfQ" id="-PZ0CqCcJHB-nbxs8fbP7bg" uri="guidances/supportingmaterials/copyright_oup.xmi"/>
+ <resourceDescriptors xmi:id="_ixQNMK__EduMeuOwJ2MpeQ" id="-KCSbXYv5TALlL00zMMfgVw" uri="guidances/guidelines/openup_and_openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_IQhrEbAAEduMeuOwJ2MpeQ" id="-l-ZsqrXu2nmVE1giLpI6iw" uri="guidances/guidelines/agile_and_unified.xmi"/>
+ <resourceDescriptors xmi:id="_VPIPILcJEduRNaXpzCOLXQ" id="-OcMsciNn-UtD9fTHj26LGA" uri="guidances/guidelines/abstract_away_complexity_vm.xmi"/>
+ <resourceDescriptors xmi:id="_BwXDIMDqEduTGJ8i4u8TMw" id="-aN0zy068ovKHgmkkoYqoYQ" uri="guidances/concepts/actor.xmi"/>
+ <resourceDescriptors xmi:id="_FdKesMEvEduwZvIr61GnNg" id="-Mobjz86dw07NW5-IhtEoNA" uri="guidances/guidelines/openup_iterations.xmi"/>
+ <resourceDescriptors xmi:id="_rKMEsMEvEduwZvIr61GnNg" id="-clUV9n59dDwg0e1VCcsB8Q" uri="guidances/guidelines/openup_architecture.xmi"/>
+ <resourceDescriptors xmi:id="_GU3Q0MExEduwZvIr61GnNg" id="-_BjYXvrfe1HHL5Y_QBfh4Q" uri="guidances/guidelines/openup_risk.xmi"/>
+ <resourceDescriptors xmi:id="_CPn-wMNrEdu2IdAIaWZyAw" id="-JviMIao63C7w9C8W6iPJrw" uri="guidances/examples/uc_model_evolve.xmi"/>
+ <resourceDescriptors xmi:id="_7KWL4MNvEdu2IdAIaWZyAw" id="-qq-9Brh5oa6H3lsdp-m8mQ" uri="guidances/examples/use_case_spec.xmi"/>
+ <resourceDescriptors xmi:id="_prz9sMUKEdu5GrwIlTJV7g" id="-I-2SvZtjELUYDQO0jvdxEA" uri="guidances/guidelines/analyze_arch_reqs_vm.xmi"/>
+ <resourceDescriptors xmi:id="_YI8eEMVxEduLYZUGfgZrkQ" id="-UQ_e8kozIP11Xu008RJd-A" uri="guidances/concepts/software_architecture.xmi"/>
+ <resourceDescriptors xmi:id="_Nm8sQMXwEduywMSzPTUUwA" id="-TfxeHO_AJxYCzXVva0kSzQ" uri="customcategories/introduction_to_openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_UDRPccXwEduywMSzPTUUwA" id="-I2j8LuHkworb0Y3EIlWfDQ" uri="customcategories/core_principles_category.xmi"/>
+ <resourceDescriptors xmi:id="__d1xocXxEduywMSzPTUUwA" id="-zy1Q3NXKXbiCP_zrjTxwaQ" uri="customcategories/getting_started_with_openup.xmi"/>
+ <resourceDescriptors xmi:id="_SEaRgMqPEduwrYVlQ9zp3w" id="-vlYpfwIYlF_ZCk5s4Dsqdg" uri="guidances/concepts/coding_standard.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_0TLvwMlgEdmt3adZL5Dmdw" name="openup_basic" guid="_0TLvwMlgEdmt3adZL5Dmdw" briefDescription="The OpenUP/Basic is an iterative software development process that is minimal, complete, and extensible." changeDate="2005-07-25T11:30:48.309-0700">
+ <copyrightStatement href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uuunoPsDEdmyhNQr5STrZQ"/>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2YMlgEdmt3adZL5Dmdw" name="Content" guid="_0TR2YMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2YclgEdmt3adZL5Dmdw" name="Categories" guid="_0TR2YclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2YslgEdmt3adZL5Dmdw" name="Domains" guid="_0TR2YslgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Domain" xmi:id="_s4Z9AMWXEdqWePvIjHInwg" name="openup_basic_wp" guid="_s4Z9AMWXEdqWePvIjHInwg" briefDescription="This is the list of domains in OpenUp/Basic providing organization of work products." presentationName="OpenUP/Basic Work Products">
+ <presentation xmi:id="-15BvSftWbF7VdZ_W8YycBQ" href="uma://-15BvSftWbF7VdZ_W8YycBQ#-15BvSftWbF7VdZ_W8YycBQ"/>
+ <subdomains xmi:id="_xITr8MWXEdqWePvIjHInwg" name="architecture" guid="_xITr8MWXEdqWePvIjHInwg" briefDescription="This is the list of work products related to architecture domain." presentationName="Architecture" workProducts="_0XAf0MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-9qPK9k01PN_COE9YPXpw8Q" href="uma://-9qPK9k01PN_COE9YPXpw8Q#-9qPK9k01PN_COE9YPXpw8Q"/>
+ </subdomains>
+ <subdomains xmi:id="_vUzp0MWeEdqiT9CqkRksWQ" name="change_management" guid="_vUzp0MWeEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to change management domain." presentationName="Change Management">
+ <presentation xmi:id="-X9nP8esP9nWMvx1wmMaJAA" href="uma://-X9nP8esP9nWMvx1wmMaJAA#-X9nP8esP9nWMvx1wmMaJAA"/>
+ </subdomains>
+ <subdomains xmi:id="_A9k3UMWfEdqiT9CqkRksWQ" name="development" guid="_A9k3UMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to development domain." presentationName="Development" workProducts="_ZTGAYL3uEdqLRJZPGVbHDA _0YuXEMlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw _0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-xO3vqWsd3W98UXFsyp-wGA" href="uma://-xO3vqWsd3W98UXFsyp-wGA#-xO3vqWsd3W98UXFsyp-wGA"/>
+ </subdomains>
+ <subdomains xmi:id="_QxjGYMWfEdqiT9CqkRksWQ" name="project_management" guid="_QxjGYMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to project management domain." presentationName="Project Management" workProducts="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _0bA2EMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA">
+ <presentation xmi:id="-N4r_U0LZhZ_K-8gfHON9BA" href="uma://-N4r_U0LZhZ_K-8gfHON9BA#-N4r_U0LZhZ_K-8gfHON9BA"/>
+ </subdomains>
+ <subdomains xmi:id="_allMQMWfEdqiT9CqkRksWQ" name="requirements" guid="_allMQMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to requirements domain." presentationName="Requirements" workProducts="_BVh9cL-CEdqb7N6KIeDL8Q _0WVxcMlgEdmt3adZL5Dmdw _0VGbUMlgEdmt3adZL5Dmdw _Wn7HcNcEEdqz_d2XWoVt6Q _W2SgEDR5EdutE_HNDTJk5Q">
+ <presentation xmi:id="-d5O4LFNaAs4YRDxfxH3CRw" href="uma://-d5O4LFNaAs4YRDxfxH3CRw#-d5O4LFNaAs4YRDxfxH3CRw"/>
+ </subdomains>
+ <subdomains xmi:id="_ou4CMMWfEdqiT9CqkRksWQ" name="test" guid="_ou4CMMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to test domain." presentationName="Test" workProducts="_0ZS-0MlgEdmt3adZL5Dmdw _0ZlSsMlgEdmt3adZL5Dmdw _0ZfMEMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-Mxgu9hq0upbMqZlq1xBFYw" href="uma://-Mxgu9hq0upbMqZlq1xBFYw#-Mxgu9hq0upbMqZlq1xBFYw"/>
+ </subdomains>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2Y8lgEdmt3adZL5Dmdw" name="Disciplines" guid="_0TR2Y8lgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TR2ZMlgEdmt3adZL5Dmdw" name="requirements" guid="_0TR2ZMlgEdmt3adZL5Dmdw" briefDescription="This discipline defines the minimal tasks required to elicit, analyze, specify, validate and manage the requirements for the system to be developed." presentationName="Requirements" conceptsAndPapers="_VXZ5wO0IEdqHTdbLTmC5IQ _KudM0NcJEdqz_d2XWoVt6Q _VQ268O0KEdqHTdbLTmC5IQ _0Wh-sMlgEdmt3adZL5Dmdw _eYtQQO0KEdqHTdbLTmC5IQ _2jyfUAhVEduRe8TeoBmuGg _zGqO0MDpEduTGJ8i4u8TMw" checklists="_jxn9EO0HEdqHTdbLTmC5IQ _0WoFUMlgEdmt3adZL5Dmdw _0U6OEMlgEdmt3adZL5Dmdw _Vael8CGMEdu3VKXZx45D3A _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_4BJ_YCxSEdqjsdw1QLH_6Q _E-dPIL-GEdqb7N6KIeDL8Q _eyL0wCu-EdqSxKAVa9kmvA _OnoNQNSAEdmLhZ9H5Plxyw _1AOsMO0JEdqHTdbLTmC5IQ _wr24gNcGEdqz_d2XWoVt6Q _qq0GMAXkEduj_7BEUj1JfQ _6jXzYNcKEdqz_d2XWoVt6Q _0VAUsMlgEdmt3adZL5Dmdw" tasks="_0fOAoMlgEdmt3adZL5Dmdw _0e1mIMlgEdmt3adZL5Dmdw _P9cMUPV_EdmdHa9MmVPgqQ">
+ <presentation xmi:id="__rFCULv9EdmmUvZAZjqE3g" href="uma://__rFCULv9EdmmUvZAZjqE3g#__rFCULv9EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNA8lgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TX9AMlgEdmt3adZL5Dmdw" name="analysis_and_design" guid="_0TX9AMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to create a design from requirements that can be implemented by developers." presentationName="Analysis & Design" conceptsAndPapers="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _Z53x0BapEduSTJywppIxVQ _0YP18MlgEdmt3adZL5Dmdw _w2ACwA4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw _0XY6UMlgEdmt3adZL5Dmdw _uF-QYEAhEdq_UJTvM1DM2Q" checklists="_17PYUNd6EdmIm-bsRSNCgw _0XSzsMlgEdmt3adZL5Dmdw" guidelines="_we3F4ACpEdu8m4dIntu6jA _T9nygClEEduLGM8dfVsrKg _mDf2EBapEduSTJywppIxVQ _0gpkAMlgEdmt3adZL5Dmdw _0gjdYMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA _42UD4A3tEduibvKwrGxWxA _0X3bcMlgEdmt3adZL5Dmdw _ienXEEyAEdu-df7p0PuRvQ _CFAswNbzEdqu5o2S60g5LA _1fM3AC9_EduW5uTjiIcspQ _2uan8NbyEdqu5o2S60g5LA" tasks="_0f-1oMlgEdmt3adZL5Dmdw _0gRJgMlgEdmt3adZL5Dmdw _0fshwMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_Bbq2MLv-EdmmUvZAZjqE3g" href="uma://_Bbq2MLv-EdmmUvZAZjqE3g#_Bbq2MLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TeDoMlgEdmt3adZL5Dmdw" name="implementation" guid="_0TeDoMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to implement a technical solution that conforms to the design, works within the architecture and supports the requirements." presentationName="Implementation" conceptsAndPapers="_B3xkEPD0EdqYgerqi84oCA _aFeZgJquEdukqcRKZBQN9w _0Y6kUMlgEdmt3adZL5Dmdw _Poc7IPDzEdqYgerqi84oCA _0lnRMMqOEduwrYVlQ9zp3w" guidelines="_0Y0dsMlgEdmt3adZL5Dmdw _eRutgC5QEduVhuZHT5jKZQ _i8bUEL6cEdqti4GwqTkbsQ _SM4YIL6dEdqti4GwqTkbsQ" tasks="_0iL1EMlgEdmt3adZL5Dmdw _0hyzgMlgEdmt3adZL5Dmdw _0iYCUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_D5dHQLv-EdmmUvZAZjqE3g" href="uma://_D5dHQLv-EdmmUvZAZjqE3g#_D5dHQLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TkKQMlgEdmt3adZL5Dmdw" name="test" guid="_0TkKQMlgEdmt3adZL5Dmdw" briefDescription="This discipline defines the minimal set of tasks required to plan, implement, run and evaluate the testing of a system." presentationName="Test" conceptsAndPapers="_0jnYcMlgEdmt3adZL5Dmdw _0aJ6cMlgEdmt3adZL5Dmdw _0jhR0MlgEdmt3adZL5Dmdw" checklists="_0Zxf8MlgEdmt3adZL5Dmdw _0Z9tMMlgEdmt3adZL5Dmdw" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0jzlsMlgEdmt3adZL5Dmdw _0aDz0MlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw" tasks="_0iwc0clgEdmt3adZL5Dmdw _0jVEkMlgEdmt3adZL5Dmdw _0jO98MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_FuQswLv-EdmmUvZAZjqE3g" href="uma://_FuQswLv-EdmmUvZAZjqE3g#_FuQswLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TqQ4MlgEdmt3adZL5Dmdw" name="project_management" guid="_0TqQ4MlgEdmt3adZL5Dmdw" presentationName="Project Management" tasks="_0l53cMlgEdmt3adZL5Dmdw _0lC70MlgEdmt3adZL5Dmdw _0keUEMlgEdmt3adZL5Dmdw _8S2aICbYEdqh1LYUOGRh2A">
+ <presentation xmi:id="_GybfgLv-EdmmUvZAZjqE3g" href="uma://_GybfgLv-EdmmUvZAZjqE3g#_GybfgLv-EdmmUvZAZjqE3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TwXgMlgEdmt3adZL5Dmdw" name="config_and_change_management" guid="_0TwXgMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to control changes to artifacts, ensuring a synchronized evolution of the set of Work Products composing a software system." presentationName="Configuration &amp; Change Management" conceptsAndPapers="_6jdvECb3Edqh1LYUOGRh2A _B3xkEPD0EdqYgerqi84oCA _0cEmAMlgEdmt3adZL5Dmdw" guidelines="_fnZj0NVXEdqy9sbRhejO5Q _i8bUEL6cEdqti4GwqTkbsQ _SM4YIL6dEdqti4GwqTkbsQ __yQQ4L6REdqti4GwqTkbsQ _7vEXEMA4EdqSgKaj2SZBmg" tasks="_0mwzEclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_H9TXMLv-EdmmUvZAZjqE3g" href="uma://_H9TXMLv-EdmmUvZAZjqE3g#_H9TXMLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:DisciplineGrouping" xmi:id="__BZycP1UEdmek8CQTQgrOQ" name="openup_basic_disciplines" guid="__BZycP1UEdmek8CQTQgrOQ" briefDescription="This is the list of disciplines in OpenUP/Basic providing organization of tasks." presentationName="OpenUP/Basic Disciplines" disciplines="_0TR2ZMlgEdmt3adZL5Dmdw _0TX9AMlgEdmt3adZL5Dmdw _0TeDoMlgEdmt3adZL5Dmdw _0TkKQMlgEdmt3adZL5Dmdw _0TqQ4MlgEdmt3adZL5Dmdw _0TwXgMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_AYGfoP1VEdmek8CQTQgrOQ" href="uma://_AYGfoP1VEdmek8CQTQgrOQ#_AYGfoP1VEdmek8CQTQgrOQ"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T2eIMlgEdmt3adZL5Dmdw" name="RoleSets" guid="_0T2eIMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_TZIJ0O8NEdmKSqa_gSYthg" name="openup_basic_roles" guid="_TZIJ0O8NEdmKSqa_gSYthg" briefDescription="This is the list of roles in OpenUP/Basic." presentationName="OpenUP/Basic Roles" roles="_0X9iEMlgEdmt3adZL5Dmdw _0a0o0MlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _0dsWoMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ">
+ <presentation xmi:id="_Tb5J8O8NEdmKSqa_gSYthg" href="uma://_Tb5J8O8NEdmKSqa_gSYthg#_Tb5J8O8NEdmKSqa_gSYthg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T2eIclgEdmt3adZL5Dmdw" name="WP Types" guid="_0T2eIclgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_2VBNIDz6Edq03rqPoNVoKg" name="assessment" guid="_2VBNIDz6Edq03rqPoNVoKg" briefDescription="These work products result from the analysis or evaluation of some particular aspect of the project, organization, business, or solution being developed. They are often used to determine the health of different aspects of the project or the organization." presentationName="Assessment" workProducts="_0bA2EMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-5S6ney_fFdEHm49XznPRiA" href="uma://-5S6ney_fFdEHm49XznPRiA#-5S6ney_fFdEHm49XznPRiA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_8XKVwDz6Edq03rqPoNVoKg" name="concept" guid="_8XKVwDz6Edq03rqPoNVoKg" briefDescription="These work products present an overview of key ideas or basic background information. They ensure that everyone on a project has a common understanding of these items." presentationName="Concept" workProducts="_0WVxcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-Nl-rJ_6aaAG2jpJyGm_wcg" href="uma://-Nl-rJ_6aaAG2jpJyGm_wcg#-Nl-rJ_6aaAG2jpJyGm_wcg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_EL6rgDz7Edq03rqPoNVoKg" name="infrastructure" guid="_EL6rgDz7Edq03rqPoNVoKg" briefDescription="These work products provide the required tools and technical environment to setup the required development infrastructure for a project." presentationName="Infrastructure">
+ <presentation xmi:id="-CKZiRxRx_TZhMbquLd4Sqw" href="uma://-CKZiRxRx_TZhMbquLd4Sqw#-CKZiRxRx_TZhMbquLd4Sqw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_MQbUgDz7Edq03rqPoNVoKg" name="model" guid="_MQbUgDz7Edq03rqPoNVoKg" briefDescription="These work products are a special kind of specification that are an abstract representation or simulation of a &quot;system&quot; that provides a complete description of the system from a particular perspective. Models are often used to gain a better understanding of how the system works or to document design decisions for the actual implementation. Models are often made up of several different kinds of parts, these parts are categorized as Model Elements." presentationName="Model" workProducts="_W2SgEDR5EdutE_HNDTJk5Q">
+ <presentation xmi:id="-ARfZUsgYE1XrKQlDgr9mEQ" href="uma://-ARfZUsgYE1XrKQlDgr9mEQ#-ARfZUsgYE1XrKQlDgr9mEQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_SxUOoDz7Edq03rqPoNVoKg" name="model_element" guid="_SxUOoDz7Edq03rqPoNVoKg" briefDescription="These work products are the individual parts that make-up a Model." presentationName="Model Element" workProducts="_0VGbUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-cW3aVzDjHhqkVayoItUQqw" href="uma://-cW3aVzDjHhqkVayoItUQqw#-cW3aVzDjHhqkVayoItUQqw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_ZR7b8Dz7Edq03rqPoNVoKg" name="plan" guid="_ZR7b8Dz7Edq03rqPoNVoKg" briefDescription="These work products provide a description of the means of achieving an objective. A successful project may include many different types of plans." presentationName="Plan" workProducts="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-vpMAMS8Cz-z9DQQhxbjjLA" href="uma://-vpMAMS8Cz-z9DQQhxbjjLA#-vpMAMS8Cz-z9DQQhxbjjLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_hOaxYDz7Edq03rqPoNVoKg" name="project_data" guid="_hOaxYDz7Edq03rqPoNVoKg" briefDescription="These work products identify the information that is used to manage the project. Collected information may either be kept as permanent records or used solely on an interim basis at a particular point in the project." presentationName="Project Data" workProducts="_rGNWsCbSEdqh1LYUOGRh2A _0ZlSsMlgEdmt3adZL5Dmdw _Ckay8Cc_EduIsqH1Q6ZuqA">
+ <presentation xmi:id="-DBPx56p4GCNFpRTT8uOmiQ" href="uma://-DBPx56p4GCNFpRTT8uOmiQ#-DBPx56p4GCNFpRTT8uOmiQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_mC_6sDz7Edq03rqPoNVoKg" name="solution" guid="_mC_6sDz7Edq03rqPoNVoKg" briefDescription="These work products consist of those that are part of the overall solution or product, or that contribute directly to it." presentationName="Solution" workProducts="_0YuXEMlgEdmt3adZL5Dmdw _0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw _0ZfMEMlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-sIh01vzZACgxRrG_sv7DVw" href="uma://-sIh01vzZACgxRrG_sv7DVw#-sIh01vzZACgxRrG_sv7DVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_tJJeADz7Edq03rqPoNVoKg" name="specification" guid="_tJJeADz7Edq03rqPoNVoKg" briefDescription="These work products define the interfaces between different parts of the project, especially between different domains. They define exactly what something is or what it must do. For example, the Architecture shows how system requirements are mapped into design." presentationName="Specification" workProducts="_0ZS-0MlgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q">
+ <presentation xmi:id="-C5ih3s1Vn_9qQbjm85-GYg" href="uma://-C5ih3s1Vn_9qQbjm85-GYg#-C5ih3s1Vn_9qQbjm85-GYg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T2eIslgEdmt3adZL5Dmdw" name="Tools" guid="_0T2eIslgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T8kwMlgEdmt3adZL5Dmdw" name="StandardCategories" guid="_0T8kwMlgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T8kwclgEdmt3adZL5Dmdw" name="CustomCategories" guid="_0T8kwclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T8kwslgEdmt3adZL5Dmdw" name="Hidden" guid="_0T8kwslgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_0T8kw8lgEdmt3adZL5Dmdw" name="Custom Categories" guid="_0T8kw8lgEdmt3adZL5Dmdw" categorizedElements="_NIIYMBOJEduCNqgZdt_OaA">
+ <presentation xmi:id="_cyZ5EMfLEdmg9p6Pf0sWyw" href="uma://_cyZ5EMfLEdmg9p6Pf0sWyw#_cyZ5EMfLEdmg9p6Pf0sWyw"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_cp6ycBOGEduCNqgZdt_OaA" name="getting_started" guid="_cp6ycBOGEduCNqgZdt_OaA" briefDescription="This area provides information useful for understanding how to deploy and adopt OpenUP/Basic." presentationName="Getting Started" shapeicon="openup_basic/customcategories/resources/icon_introL.gif" nodeicon="openup_basic/customcategories/resources/mic.gif" categorizedElements="_vEruwN-rEdqiM_wFaqLjNg _ClDF4BOHEduCNqgZdt_OaA _UaGfECcTEduSX6N2jUafGA"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_ClDF4BOHEduCNqgZdt_OaA" name="about" guid="_ClDF4BOHEduCNqgZdt_OaA" presentationName="About" shapeicon="openup_basic/customcategories/resources/processicon.gif" nodeicon="openup_basic/customcategories/resources/about.gif">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="#_8tSNMPGYEdqiDINUyockoA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uvje4D_fEdqDFvujd6NHiA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_HEu9QBOHEduCNqgZdt_OaA" name="core_principles_cat" guid="_HEu9QBOHEduCNqgZdt_OaA" briefDescription="Four core principles capture the general intentions behind this process and create the foundation for interpreting roles and work products and performing tasks." presentationName="Core Principles" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_ssG6MMvpEdqukPpotm3DYg _KkTIsMp7EdqC_NfSivunjA _9gocwMvoEdqukPpotm3DYg _GXiogMvoEdqukPpotm3DYg"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_NIIYMBOJEduCNqgZdt_OaA" name="openup_basic_views" guid="_NIIYMBOJEduCNqgZdt_OaA" presentationName="OpenUP/Basic Views" categorizedElements="_SEztkBOJEduCNqgZdt_OaA _2l8U4K4sEdudp4CB-AFxtw _RdM7MMXnEduywMSzPTUUwA">
+ <presentation xmi:id="-8uqXjzIOnt6LVDae6Uv_0w" href="uma://-8uqXjzIOnt6LVDae6Uv_0w#-8uqXjzIOnt6LVDae6Uv_0w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_SEztkBOJEduCNqgZdt_OaA" name="openup_basic_deprecated" guid="_SEztkBOJEduCNqgZdt_OaA" presentationName="OpenUP/Basic - deprecated">
+ <presentation xmi:id="-nY50CawHefla4zauYddVfw" href="uma://-nY50CawHefla4zauYddVfw#-nY50CawHefla4zauYddVfw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="#_i-BDsNogEdqfmNgIq7q3Xw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_cp6ycBOGEduCNqgZdt_OaA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_HEu9QBOHEduCNqgZdt_OaA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_V2BQkEmbEdu0xduwSKie-w"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:RoleSet" href="#_TZIJ0O8NEdmKSqa_gSYthg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_s4Z9AMWXEdqWePvIjHInwg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DisciplineGrouping" href="#__BZycP1UEdmek8CQTQgrOQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uyGoMlgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_V2BQkEmbEdu0xduwSKie-w" name="sub_processes" guid="_V2BQkEmbEdu0xduwSKie-w" briefDescription="OpenUP/Basic is organized into four major areas of content, also known as sub-processes." presentationName="Sub-processes" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_r8cVIEmbEdu0xduwSKie-w _57_ZMEmbEdu0xduwSKie-w _Aoz2gEmcEdu0xduwSKie-w _HEVvgEmcEdu0xduwSKie-w">
+ <presentation xmi:id="-1ZoXO1IRfkXUKej4bNv8cw" href="uma://-1ZoXO1IRfkXUKej4bNv8cw#-1ZoXO1IRfkXUKej4bNv8cw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_r8cVIEmbEdu0xduwSKie-w" name="collab_commun_subprocess" guid="_r8cVIEmbEdu0xduwSKie-w" briefDescription="This layer is the foundation for OpenUP, reflecting the collaborative nature of the process." presentationName="Communication and Collaboration" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_KkTIsMp7EdqC_NfSivunjA _TZIJ0O8NEdmKSqa_gSYthg">
+ <presentation xmi:id="-NMF-a9hwKjzWNfHzzseDYQ" href="uma://-NMF-a9hwKjzWNfHzzseDYQ#-NMF-a9hwKjzWNfHzzseDYQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_57_ZMEmbEdu0xduwSKie-w" name="intent_subprocess" guid="_57_ZMEmbEdu0xduwSKie-w" briefDescription="The intent sub-process deals with how to channel the intent of stakeholders to the rest of the development team, to ensure that validated builds with incremental capabilities reflect stakeholder intents." presentationName="Intent" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif">
+ <presentation xmi:id="-QRnsN2e6IQlSMaRts-wFNw" href="uma://-QRnsN2e6IQlSMaRts-wFNw#-QRnsN2e6IQlSMaRts-wFNw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_ssG6MMvpEdqukPpotm3DYg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TR2ZMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TwXgMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_allMQMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_vUzp0MWeEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_Aoz2gEmcEdu0xduwSKie-w" name="management_subprocess" guid="_Aoz2gEmcEdu0xduwSKie-w" briefDescription="The Management sub-process deals with management of the project, including project planning, iteration planning, day-to-day management of the work within the iteration, and iteration assessments." presentationName="Management" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif">
+ <presentation xmi:id="-q8ubSlQ5miYcY1JXdj1fbQ" href="uma://-q8ubSlQ5miYcY1JXdj1fbQ#-q8ubSlQ5miYcY1JXdj1fbQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_GXiogMvoEdqukPpotm3DYg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TqQ4MlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_QxjGYMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNA8lgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_HEVvgEmcEdu0xduwSKie-w" name="solution_subprocess" guid="_HEVvgEmcEdu0xduwSKie-w" briefDescription="The Solution sub-process describes all aspects of creating the architecture, designing, implementing, and testing the application." presentationName="Solution" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif">
+ <presentation xmi:id="-qwWeiX7WrSVHSluBe-J7yw" href="uma://-qwWeiX7WrSVHSluBe-J7yw#-qwWeiX7WrSVHSluBe-J7yw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_9gocwMvoEdqukPpotm3DYg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TX9AMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TeDoMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TkKQMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_xITr8MWXEdqWePvIjHInwg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_A9k3UMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_ou4CMMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQslgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_2l8U4K4sEdudp4CB-AFxtw" name="architectural_mechanisms" guid="_2l8U4K4sEdudp4CB-AFxtw" briefDescription="Information about how to use use architectural mechansims to create a robust architecture." presentationName="Architectural Mechanisms" categorizedElements="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA _4k_HsA4LEduibvKwrGxWxA _4k_HsQ4LEduibvKwrGxWxA _4k_Hsg4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_RdM7MMXnEduywMSzPTUUwA" name="openup_basic_treebrowser" guid="_RdM7MMXnEduywMSzPTUUwA" presentationName="OpenUP/Basic">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_BTJ_YMXwEduywMSzPTUUwA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#__cft0MXxEduywMSzPTUUwA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DisciplineGrouping" href="#__BZycP1UEdmek8CQTQgrOQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_s4Z9AMWXEdqWePvIjHInwg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:RoleSet" href="#_TZIJ0O8NEdmKSqa_gSYthg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uyGoMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_ClDF4BOHEduCNqgZdt_OaA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="#_UaGfECcTEduSX6N2jUafGA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_BTJ_YMXwEduywMSzPTUUwA" name="introduction_to_openup_basic" guid="_BTJ_YMXwEduywMSzPTUUwA" presentationName="Introduction to OpenUP/Basic" shapeicon="openup_basic/customcategories/resources/icon_introL.gif" nodeicon="openup_basic/customcategories/resources/mic.gif" categorizedElements="_v2l6gK_5EduMeuOwJ2MpeQ _Nm5vUK__EduMeuOwJ2MpeQ _qg1IAK__EduMeuOwJ2MpeQ _UCOtoMXwEduywMSzPTUUwA _ZRHNUMXwEduywMSzPTUUwA">
+ <presentation xmi:id="-TfxeHO_AJxYCzXVva0kSzQ" href="uma://-TfxeHO_AJxYCzXVva0kSzQ#-TfxeHO_AJxYCzXVva0kSzQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_UCOtoMXwEduywMSzPTUUwA" name="core_principles_category" guid="_UCOtoMXwEduywMSzPTUUwA" briefDescription="Four core principles capture the general intentions behind this process and create the foundation for interpreting roles and work products and performing tasks." presentationName="Core Principles" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_ssG6MMvpEdqukPpotm3DYg _KkTIsMp7EdqC_NfSivunjA _9gocwMvoEdqukPpotm3DYg _GXiogMvoEdqukPpotm3DYg">
+ <presentation xmi:id="-I2j8LuHkworb0Y3EIlWfDQ" href="uma://-I2j8LuHkworb0Y3EIlWfDQ#-I2j8LuHkworb0Y3EIlWfDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_ZRHNUMXwEduywMSzPTUUwA" name="fundamental_concepts" guid="_ZRHNUMXwEduywMSzPTUUwA" presentationName="OpenUP Fundamental Concepts" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_0hmKgBOMEduCNqgZdt_OaA _2plxwBOMEduCNqgZdt_OaA _48EKsBOMEduCNqgZdt_OaA __ca5UBOMEduCNqgZdt_OaA _lam4ADkBEduxovfWMDsntw _KudM0NcJEdqz_d2XWoVt6Q _0bsLgMlgEdmt3adZL5Dmdw __O7tAMVvEduLYZUGfgZrkQ"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="__cft0MXxEduywMSzPTUUwA" name="getting_started_with_openup" guid="__cft0MXxEduywMSzPTUUwA" briefDescription="This area provides information useful for understanding how to deploy and adopt OpenUP/Basic." presentationName="Getting Started" shapeicon="openup_basic/customcategories/resources/icon_introL.gif" nodeicon="openup_basic/customcategories/resources/mic.gif" categorizedElements="_vEruwN-rEdqiM_wFaqLjNg _omneEMX4EduywMSzPTUUwA _t9yXEMX4EduywMSzPTUUwA">
+ <presentation xmi:id="-zy1Q3NXKXbiCP_zrjTxwaQ" href="uma://-zy1Q3NXKXbiCP_zrjTxwaQ#-zy1Q3NXKXbiCP_zrjTxwaQ"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0UCrYMlgEdmt3adZL5Dmdw" name="CoreContent" guid="_0UCrYMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0UCrYclgEdmt3adZL5Dmdw" name="collaboration" guid="_0UCrYclgEdmt3adZL5Dmdw" briefDescription="Collaboration sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_OGGKkMpyEdqC_NfSivunjA" name="core_principles" guid="_OGGKkMpyEdqC_NfSivunjA">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_KkTIsMp7EdqC_NfSivunjA" name="core_principle_collaborate" guid="_KkTIsMp7EdqC_NfSivunjA" briefDescription="Develop collaborative practices that foster a healthy team environment. Good collaborative practices align the interests of project participants and help them develop a shared understanding of the project." presentationName="Collaborate to align interests and share understanding">
+ <presentation xmi:id="-IXfkG-XfnoEo0xgux482Kw" href="uma://-IXfkG-XfnoEo0xgux482Kw#-IXfkG-XfnoEo0xgux482Kw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_GXiogMvoEdqukPpotm3DYg" name="core_principle_evolve" guid="_GXiogMvoEdqukPpotm3DYg" briefDescription="Divide the project up into short, time-boxed iterations to demonstrate incremental value and obtain early and continuous feedback." presentationName="Evolve to continuously obtain feedback and improve">
+ <presentation xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" href="uma://-aMD1wQVJLzzlMARfHBdOBQ#-aMD1wQVJLzzlMARfHBdOBQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_9gocwMvoEdqukPpotm3DYg" name="core_principle_focus" guid="_9gocwMvoEdqukPpotm3DYg" briefDescription="Articulate essential technical decisions through a growing architecture." presentationName="Focus on articulating the architecture">
+ <presentation xmi:id="-HTMJFV29MTZkKWqnIo01Gg" href="uma://-HTMJFV29MTZkKWqnIo01Gg#-HTMJFV29MTZkKWqnIo01Gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_ssG6MMvpEdqukPpotm3DYg" name="core_principle_balance" guid="_ssG6MMvpEdqukPpotm3DYg" briefDescription="Develop a solution that maximizes stakeholder benefits and complies with constraints placed on the project." presentationName="Balance competing priorities to maximize stakeholder value">
+ <presentation xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" href="uma://-I4IbR1GW6IFBCdq9SiMUsw#-I4IbR1GW6IFBCdq9SiMUsw"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_L79ggDR5EdutE_HNDTJk5Q" name="uc_modeling" guid="_L79ggDR5EdutE_HNDTJk5Q" briefDescription="Elements specific to UC modeling.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_W2SgEDR5EdutE_HNDTJk5Q" name="uc_model" guid="_W2SgEDR5EdutE_HNDTJk5Q" presentationName="Use-Case Model"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0dsWoMlgEdmt3adZL5Dmdw" name="any_role" guid="_0dsWoMlgEdmt3adZL5Dmdw" briefDescription="Anyone on a team can fill this role of performing general tasks." presentationName="Any Role">
+ <presentation xmi:id="_NqqcUqeqEdmKDbQuyzCoqQ" href="uma://_NqqcUqeqEdmKDbQuyzCoqQ#_NqqcUqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_9ToeIB83Edqsvps02rpOOg" name="references" guid="_9ToeIB83Edqsvps02rpOOg" briefDescription="Additional references that may be useful, including books, method plug-ins, and commercial methodology products." presentationName="References">
+ <presentation xmi:id="-aCI9T-9TIe8D35yXBU6qvg" href="uma://-aCI9T-9TIe8D35yXBU6qvg#-aCI9T-9TIe8D35yXBU6qvg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_dTa6gMAYEdqX-s4mWhkyqQ" name="stakeholder" guid="_dTa6gMAYEdqX-s4mWhkyqQ" briefDescription="This role represents interest groups whose needs must be satisfied by the project. It is a role that may be played by anyone who is (or potentially will be) materially affected by the outcome of the project." presentationName="Stakeholder"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_i-BDsNogEdqfmNgIq7q3Xw" name="openup_basic_home" guid="_i-BDsNogEdqfmNgIq7q3Xw" presentationName="OpenUP/Basic" shapeicon="openup_basic/guidances/supportingmaterials/resources/icon_introL.gif" nodeicon="openup_basic/guidances/supportingmaterials/resources/mic.gif">
+ <presentation xmi:id="-XR2Rbg25yN80p1exWC4MHg" href="uma://-XR2Rbg25yN80p1exWC4MHg#-XR2Rbg25yN80p1exWC4MHg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Roadmap" xmi:id="_vEruwN-rEdqiM_wFaqLjNg" name="openup_basic_roadmap" guid="_vEruwN-rEdqiM_wFaqLjNg" briefDescription="This roadmap presents an overview of OpenUP/Basic, its purpose and lifecycle." presentationName="OpenUP/Basic Roadmap">
+ <presentation xmi:id="-At_b3UIzbgdmtJsb2Ymfhg" href="uma://-At_b3UIzbgdmtJsb2Ymfhg#-At_b3UIzbgdmtJsb2Ymfhg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_8tSNMPGYEdqiDINUyockoA" name="about_openup_basic" guid="_8tSNMPGYEdqiDINUyockoA" presentationName="About OpenUP/Basic" nodeicon="openup_basic/guidances/supportingmaterials/resources/about.gif">
+ <presentation xmi:id="-WFD3nKccpkueaG15cHT-fA" href="uma://-WFD3nKccpkueaG15cHT-fA#-WFD3nKccpkueaG15cHT-fA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_NOHy0BOGEduCNqgZdt_OaA" name="using_openup_basic" guid="_NOHy0BOGEduCNqgZdt_OaA" briefDescription="This guideline explains the various usage scenarios of this Web site." presentationName="Using OpenUP/Basic" shapeicon="openup_basic/guidances/guidelines/resources/compassL.gif" nodeicon="openup_basic/guidances/guidelines/resources/compass.gif"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0hmKgBOMEduCNqgZdt_OaA" name="inception_phase" guid="_0hmKgBOMEduCNqgZdt_OaA" briefDescription="First of the four phases in the project lifecycle, it is about understanding the project scope and objectives and getting enough information to confirm that the project should proceed - or convince you that it should not." presentationName="Inception Phase">
+ <presentation xmi:id="-GRJW_KNOJoEQF3r6lmBrEw" href="uma://-GRJW_KNOJoEQF3r6lmBrEw#-GRJW_KNOJoEQF3r6lmBrEw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2plxwBOMEduCNqgZdt_OaA" name="elaboration_phase" guid="_2plxwBOMEduCNqgZdt_OaA" briefDescription="Second of four phases in the project lifecycle, when architecturally significant risks are addressed." presentationName="Elaboration Phase">
+ <presentation xmi:id="-F-eWIBzxEXE1jygbN3nrrQ" href="uma://-F-eWIBzxEXE1jygbN3nrrQ#-F-eWIBzxEXE1jygbN3nrrQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_48EKsBOMEduCNqgZdt_OaA" name="construction_phase" guid="_48EKsBOMEduCNqgZdt_OaA" briefDescription="Third of the four phases in the project lifecycle, Construction focuses on design, implementation, and testing of functionalities to develop a complete system." presentationName="Construction Phase">
+ <presentation xmi:id="-bbpT_BdDRrv6waNI365Qhg" href="uma://-bbpT_BdDRrv6waNI365Qhg#-bbpT_BdDRrv6waNI365Qhg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="__ca5UBOMEduCNqgZdt_OaA" name="transition_phase" guid="__ca5UBOMEduCNqgZdt_OaA" briefDescription="Fourth and final phase in the project lifecycle." presentationName="Transition Phase">
+ <presentation xmi:id="-FrUmsKsGW4bnNmb9uaNOkg" href="uma://-FrUmsKsGW4bnNmb9uaNOkg#-FrUmsKsGW4bnNmb9uaNOkg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_Pt_fYBjoEduxUfEVCtmW4Q" name="delivery_process_graph" guid="_Pt_fYBjoEduxUfEVCtmW4Q" presentationName="Delivery Process Graph">
+ <presentation xmi:id="-cy0DcnEk7uJJ1OOH3_E6rg" href="uma://-cy0DcnEk7uJJ1OOH3_E6rg#-cy0DcnEk7uJJ1OOH3_E6rg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_UaGfECcTEduSX6N2jUafGA" name="openup_copyright" guid="_UaGfECcTEduSX6N2jUafGA" briefDescription="OpenUP Copyright Information" presentationName="OpenUP Copyright" shapeicon="openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif" nodeicon="openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif">
+ <presentation xmi:id="-RNyaB6jxqoopm9fJU8k9vg" href="uma://-RNyaB6jxqoopm9fJU8k9vg#-RNyaB6jxqoopm9fJU8k9vg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0VxJsMlgEdmt3adZL5Dmdw" name="analyst" guid="_0VxJsMlgEdmt3adZL5Dmdw" briefDescription="The person in this role represents customer and end-user concerns by gathering input from stakeholders to understand the problem to be solved and by capturing and setting priorities for requirements." presentationName="Analyst" responsibleFor="_0WVxcMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q _W2SgEDR5EdutE_HNDTJk5Q">
+ <presentation xmi:id="_Nx8icKYdEdmvhNXG0Oc2uA" href="uma://_Nx8icKYdEdmvhNXG0Oc2uA#_Nx8icKYdEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_BVh9cL-CEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_BVh9cL-CEdqb7N6KIeDL8Q" briefDescription="This artifact captures system-wide requirements not captured in scenarios or use cases, including requirements on quality attributes and global functional requirements." presentationName="Supporting Requirements" conceptsAndPapers="_VXZ5wO0IEdqHTdbLTmC5IQ">
+ <presentation xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" href="uma://-_dNuyh-0q5vpCiIiLfbj6w#-_dNuyh-0q5vpCiIiLfbj6w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0VGbUMlgEdmt3adZL5Dmdw" name="use_case" guid="_0VGbUMlgEdmt3adZL5Dmdw" briefDescription="This artifact captures the sequence of actions a system performs that yields an observable result of value to those interacting with the system." presentationName="Use Case" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q">
+ <presentation xmi:id="_zHZW8qYSEdmvhNXG0Oc2uA" href="uma://_zHZW8qYSEdmvhNXG0Oc2uA#_zHZW8qYSEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0WVxcMlgEdmt3adZL5Dmdw" name="vision" guid="_0WVxcMlgEdmt3adZL5Dmdw" briefDescription="This artifact contains the definition of the stakeholders' view of the product to be developed, specified in terms of the stakeholders' key needs and features. It contains an outline of the envisioned core requirements for the system." presentationName="Vision" checklists="_0WoFUMlgEdmt3adZL5Dmdw _jxn9EO0HEdqHTdbLTmC5IQ">
+ <presentation xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" href="uma://_zHTQUKYSEdmvhNXG0Oc2uA#_zHTQUKYSEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_rGNWsCbSEdqh1LYUOGRh2A" name="work_items_list" guid="_rGNWsCbSEdqh1LYUOGRh2A" briefDescription="This artifact contains a list of all scheduled work to be done within the project, as well as proposed work that may affect the product in this or future projects. Each Work Item may contain references to information relevant to carry out the work described within the work item." presentationName="Work Items List" guidelines="_7vEXEMA4EdqSgKaj2SZBmg" templates="_QwUJYDg0Edu4E8ZdmlYjtA">
+ <presentation xmi:id="-buxz4BVToq97bSxaqyjySg" href="uma://-buxz4BVToq97bSxaqyjySg#-buxz4BVToq97bSxaqyjySg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0aQBEslgEdmt3adZL5Dmdw" name="iteration_plan" guid="_0aQBEslgEdmt3adZL5Dmdw" briefDescription="A fine-grained plan describing the objectives, work assignments, and evaluation criteria for the iteration." presentationName="Iteration Plan" conceptsAndPapers="_lam4ADkBEduxovfWMDsntw" templates="_0dBoQMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_BcBR8KX5EdmvhNXG0Oc2uA" href="uma://_BcBR8KX5EdmvhNXG0Oc2uA#_BcBR8KX5EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_7vEXEMA4EdqSgKaj2SZBmg" name="work_items_list" guid="_7vEXEMA4EdqSgKaj2SZBmg" briefDescription="This guideline explains the lifecycle of work items, and how the Work Items List is used." presentationName="Work Items List">
+ <presentation xmi:id="-G1Oxlk6F0R09vClqy1EzOw" href="uma://-G1Oxlk6F0R09vClqy1EzOw#-G1Oxlk6F0R09vClqy1EzOw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Wn7HcNcEEdqz_d2XWoVt6Q" name="glossary" guid="_Wn7HcNcEEdqz_d2XWoVt6Q" briefDescription="This artifact defines important terms used by the project. These terms are the basis for effective collaboration with the stakeholders and other team members." presentationName="Glossary">
+ <presentation xmi:id="-iOn7_gfX_iELWRNGJ2JKPQ" href="uma://-iOn7_gfX_iELWRNGJ2JKPQ#-iOn7_gfX_iELWRNGJ2JKPQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VXZ5wO0IEdqHTdbLTmC5IQ" name="supporting_requirements" guid="_VXZ5wO0IEdqHTdbLTmC5IQ" briefDescription="This concept describes the supporting requirements" presentationName="Supporting Requirements">
+ <presentation xmi:id="-3SXuKijeVOZalgLPgWRyFA" href="uma://-3SXuKijeVOZalgLPgWRyFA#-3SXuKijeVOZalgLPgWRyFA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_KudM0NcJEdqz_d2XWoVt6Q" name="use_case" guid="_KudM0NcJEdqz_d2XWoVt6Q" briefDescription="A use case describes what the system must do to provide value to the stakeholders." presentationName="Use Case" conceptsAndPapers="_zGqO0MDpEduTGJ8i4u8TMw">
+ <presentation xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" href="uma://-BQLZ5GRUNrMdU6XeZAfe9Q#-BQLZ5GRUNrMdU6XeZAfe9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_jxn9EO0HEdqHTdbLTmC5IQ" name="good_requirements" guid="_jxn9EO0HEdqHTdbLTmC5IQ" briefDescription="This checklist provides guidance on assessing the quality of requirements." presentationName="Qualities of Good Requirements">
+ <presentation xmi:id="-2o1pXjHpSEPN_rohLce5jA" href="uma://-2o1pXjHpSEPN_rohLce5jA#-2o1pXjHpSEPN_rohLce5jA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0WoFUMlgEdmt3adZL5Dmdw" name="vision" guid="_0WoFUMlgEdmt3adZL5Dmdw" briefDescription="This check list provides questions to verify that the Vision is described in a consistent and complete manner." presentationName="Vision">
+ <presentation xmi:id="_qktWQMM0EdmSIPI87WLu3g" href="uma://_qktWQMM0EdmSIPI87WLu3g#_qktWQMM0EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0VrDEMlgEdmt3adZL5Dmdw" name="actor" guid="_0VrDEMlgEdmt3adZL5Dmdw" briefDescription="This check list provides questions to help ensure that all actors, and only valid actors, have been identified and described correctly." presentationName="Actor">
+ <presentation xmi:id="_KEldgMM1EdmSIPI87WLu3g" href="uma://_KEldgMM1EdmSIPI87WLu3g#_KEldgMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0ZM4MclgEdmt3adZL5Dmdw" name="tester" guid="_0ZM4MclgEdmt3adZL5Dmdw" briefDescription="This role is responsible for the core activities of the test effort. Those activities include identifying, defining, implementing, and conducting the necessary tests, as well as logging the outcomes of the testing and analyzing the results." presentationName="Tester" responsibleFor="_0ZS-0MlgEdmt3adZL5Dmdw _0ZlSsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NqYIcKeqEdmKDbQuyzCoqQ" href="uma://_NqYIcKeqEdmKDbQuyzCoqQ#_NqYIcKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0ZS-0MlgEdmt3adZL5Dmdw" name="test_case" guid="_0ZS-0MlgEdmt3adZL5Dmdw" briefDescription="This artifact is the specification of a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a scenario." presentationName="Test Case" conceptsAndPapers="_0aJ6cMlgEdmt3adZL5Dmdw" checklists="_0Zxf8MlgEdmt3adZL5Dmdw" templates="_0dT8IMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NqYIdKeqEdmKDbQuyzCoqQ" href="uma://_NqYIdKeqEdmKDbQuyzCoqQ#_NqYIdKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0ZlSsMlgEdmt3adZL5Dmdw" name="test_log" guid="_0ZlSsMlgEdmt3adZL5Dmdw" briefDescription="This artifact collects raw output captured during a unique execution of one or more tests for a single test cycle run." presentationName="Test Log">
+ <presentation xmi:id="_NqePEKeqEdmKDbQuyzCoqQ" href="uma://_NqePEKeqEdmKDbQuyzCoqQ#_NqePEKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0Zxf8MlgEdmt3adZL5Dmdw" name="test_case" guid="_0Zxf8MlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that test cases are created in a consistent and complete manner." presentationName="Test Case">
+ <presentation xmi:id="_kwHAgMPbEdmbOvqy4O0adg" href="uma://_kwHAgMPbEdmbOvqy4O0adg#_kwHAgMPbEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0YDosMlgEdmt3adZL5Dmdw" name="developer" guid="_0YDosMlgEdmt3adZL5Dmdw" briefDescription="This role is responsible for developing a part of the system, including designing it to fit into the architecture, possibly prototyping the user-interface, and then implementing, unit-testing, and integrating the components that are part of the solution." presentationName="Developer">
+ <presentation xmi:id="_NqL7MqeqEdmKDbQuyzCoqQ" href="uma://_NqL7MqeqEdmKDbQuyzCoqQ#_NqL7MqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0X9iEMlgEdmt3adZL5Dmdw" name="architect" guid="_0X9iEMlgEdmt3adZL5Dmdw" briefDescription="This role is responsible for defining the software architecture, which includes making the key technical decisions that constrain the overall design and implementation of the project." presentationName="Architect" conceptsAndPapers="_9gocwMvoEdqukPpotm3DYg">
+ <presentation xmi:id="_Y6tLEKbXEdm9d-ircVOUCA" href="uma://_Y6tLEKbXEdm9d-ircVOUCA#_Y6tLEKbXEdm9d-ircVOUCA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0a0o0MlgEdmt3adZL5Dmdw" name="project_manager" guid="_0a0o0MlgEdmt3adZL5Dmdw" briefDescription="Leads the planning of the project, coordinates interactions with the stakeholders, and keeps the project team focused on meeting the project objectives." presentationName="Project Manager" responsibleFor="_0aQBEslgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_Fdq-8KX4EdmvhNXG0Oc2uA" href="uma://_Fdq-8KX4EdmvhNXG0Oc2uA#_Fdq-8KX4EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_lam4ADkBEduxovfWMDsntw" name="iteration" guid="_lam4ADkBEduxovfWMDsntw" briefDescription="An iteration is a set period of time within a project in which you produce a stable, executable version of the product, together with any other supporting documentation, install scripts, or similar, necessary to use this release. Also referred to as a cycle or a timebox." presentationName="Iteration">
+ <presentation xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" href="uma://-vi8wxwxVZLY0SMPFxZjD7A#-vi8wxwxVZLY0SMPFxZjD7A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0bsLgMlgEdmt3adZL5Dmdw" name="risk" guid="_0bsLgMlgEdmt3adZL5Dmdw" briefDescription="A risk is whatever may stand in the way to success, and is currently unknown or uncertain. Usually, a risk is qualified by the probability of occurrence and the impact in the project, if it occurs." presentationName="Risk">
+ <presentation xmi:id="_u6enMMM1EdmSIPI87WLu3g" href="uma://_u6enMMM1EdmSIPI87WLu3g#_u6enMMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3PJ38EvqEdunZcj9T5hrMQ" name="agile" guid="_3PJ38EvqEdunZcj9T5hrMQ" presentationName="agile">
+ <presentation xmi:id="-qZE4XgeMK93LmJMKuQWGFg" href="uma://-qZE4XgeMK93LmJMKuQWGFg#-qZE4XgeMK93LmJMKuQWGFg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_0sD60EvDEdunZcj9T5hrMQ" name="construction" guid="_0sD60EvDEdunZcj9T5hrMQ" presentationName="Construction">
+ <presentation xmi:id="-5wJmUR0WqX7lCIxsyqFsdA" href="uma://-5wJmUR0WqX7lCIxsyqFsdA#-5wJmUR0WqX7lCIxsyqFsdA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_8DkT4EvDEdunZcj9T5hrMQ" name="elaboration" guid="_8DkT4EvDEdunZcj9T5hrMQ" presentationName="Elaboration">
+ <presentation xmi:id="-0g2jTHQla8lbP6xGB3iGlg" href="uma://-0g2jTHQla8lbP6xGB3iGlg#-0g2jTHQla8lbP6xGB3iGlg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_525A8EvDEdunZcj9T5hrMQ" name="inception" guid="_525A8EvDEdunZcj9T5hrMQ" presentationName="Inception">
+ <presentation xmi:id="-dhgOQQ4GsV0-dNJmTmF9GA" href="uma://-dhgOQQ4GsV0-dNJmTmF9GA#-dhgOQQ4GsV0-dNJmTmF9GA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_O7JBYEvFEdunZcj9T5hrMQ" name="ioc_milestone" guid="_O7JBYEvFEdunZcj9T5hrMQ" presentationName="Initial Operational Capability Milestone.">
+ <presentation xmi:id="-gEgZg2UkFLjGeXkJLpAP6A" href="uma://-gEgZg2UkFLjGeXkJLpAP6A#-gEgZg2UkFLjGeXkJLpAP6A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZBUnMEvFEdunZcj9T5hrMQ" name="iteration" guid="_ZBUnMEvFEdunZcj9T5hrMQ" presentationName="iteration">
+ <presentation xmi:id="-_G0VvVOdMoajk615LwFtxg" href="uma://-_G0VvVOdMoajk615LwFtxg#-_G0VvVOdMoajk615LwFtxg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_NL4DMEvFEdunZcj9T5hrMQ" name="lca_milestone" guid="_NL4DMEvFEdunZcj9T5hrMQ" presentationName="Lifecycle Architecture Milestone">
+ <presentation xmi:id="-MllWL01NL93RTB7VsY69fw" href="uma://-MllWL01NL93RTB7VsY69fw#-MllWL01NL93RTB7VsY69fw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_LGRBkEvFEdunZcj9T5hrMQ" name="lco_milestone" guid="_LGRBkEvFEdunZcj9T5hrMQ" presentationName="Lifecycle Objectives Milestone">
+ <presentation xmi:id="-Rl8kaRW9Bxqdvq32kVCi7w" href="uma://-Rl8kaRW9Bxqdvq32kVCi7w#-Rl8kaRW9Bxqdvq32kVCi7w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ByXNcEvqEdunZcj9T5hrMQ" name="milestone" guid="_ByXNcEvqEdunZcj9T5hrMQ" presentationName="milestone">
+ <presentation xmi:id="-9fXEOvMc4t7y6s5GscBD1Q" href="uma://-9fXEOvMc4t7y6s5GscBD1Q#-9fXEOvMc4t7y6s5GscBD1Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_QuywUEvFEdunZcj9T5hrMQ" name="pr_milestone" guid="_QuywUEvFEdunZcj9T5hrMQ" presentationName="Product Release Milestone">
+ <presentation xmi:id="-JegYQHIteCRN0iV2EKMjSA" href="uma://-JegYQHIteCRN0iV2EKMjSA#-JegYQHIteCRN0iV2EKMjSA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_-5ms4EvDEdunZcj9T5hrMQ" name="transition" guid="_-5ms4EvDEdunZcj9T5hrMQ" presentationName="Transition">
+ <presentation xmi:id="-yoFF90pq-_UV3fm-5oDenw" href="uma://-yoFF90pq-_UV3fm-5oDenw#-yoFF90pq-_UV3fm-5oDenw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_cTs20KzREduOqvpk_MDLfQ" name="copyright_oup" guid="_cTs20KzREduOqvpk_MDLfQ" variabilityType="contributes">
+ <presentation xmi:id="-PZ0CqCcJHB-nbxs8fbP7bg" href="uma://-PZ0CqCcJHB-nbxs8fbP7bg#-PZ0CqCcJHB-nbxs8fbP7bg"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uuunoPsDEdmyhNQr5STrZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_v2l6gK_5EduMeuOwJ2MpeQ" name="openup_and_openup_basic" guid="_v2l6gK_5EduMeuOwJ2MpeQ" briefDescription="OpenUP is a family of open source process plug-ins. OpenUP/Basic is the core process in OpenUP and is geared towards a small, co-located team." presentationName="OpenUP and OpenUP/Basic" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif">
+ <presentation xmi:id="-KCSbXYv5TALlL00zMMfgVw" href="uma://-KCSbXYv5TALlL00zMMfgVw#-KCSbXYv5TALlL00zMMfgVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_Nm5vUK__EduMeuOwJ2MpeQ" name="minimal_complete_extensible" guid="_Nm5vUK__EduMeuOwJ2MpeQ" briefDescription="OpenUP/Basic is minimal, complete, and extensible. It's the minimum amount of process for a small team, it can be used as-is, and it can be extended and customized for specific purposes." presentationName="Minimal, Complete, and Extensible" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_qg1IAK__EduMeuOwJ2MpeQ" name="agile_and_unified" guid="_qg1IAK__EduMeuOwJ2MpeQ" briefDescription="OpenUP/Basic is a Unified process that incorporates proven agile techniques. The result is a robust, effective, and lightweight process structure." presentationName="Agile and Unified" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif">
+ <presentation xmi:id="-l-ZsqrXu2nmVE1giLpI6iw" href="uma://-l-ZsqrXu2nmVE1giLpI6iw#-l-ZsqrXu2nmVE1giLpI6iw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_zGqO0MDpEduTGJ8i4u8TMw" name="actor" guid="_zGqO0MDpEduTGJ8i4u8TMw" briefDescription="An Actor is a role that a person or external system plays when interacting with a system. Instances of an Actor can be an individual or an external system." presentationName="Actor" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q">
+ <presentation xmi:id="-aN0zy068ovKHgmkkoYqoYQ" href="uma://-aN0zy068ovKHgmkkoYqoYQ#-aN0zy068ovKHgmkkoYqoYQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_U3VjIMEuEduwZvIr61GnNg" name="openup_iterations" guid="_U3VjIMEuEduwZvIr61GnNg" briefDescription="The set of iterations in a phase address specific milestones that objectively track a project's progress. Each phase has its own milestone that reflects the emphasis of the phase." presentationName="The Benefit of OpenUP/Basic Iterations" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif" conceptsAndPapers="_48EKsBOMEduCNqgZdt_OaA _2plxwBOMEduCNqgZdt_OaA _0hmKgBOMEduCNqgZdt_OaA __ca5UBOMEduCNqgZdt_OaA _GXiogMvoEdqukPpotm3DYg _lam4ADkBEduxovfWMDsntw">
+ <presentation xmi:id="-Mobjz86dw07NW5-IhtEoNA" href="uma://-Mobjz86dw07NW5-IhtEoNA#-Mobjz86dw07NW5-IhtEoNA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_REqtUMEvEduwZvIr61GnNg" name="openup_architecture" guid="_REqtUMEvEduwZvIr61GnNg" briefDescription="The early iterations of OpenUP/Basic focus on addressing the requirements that will produce an executable architecture. Buiding and validating the architecture first significantly reduces the technical risk in a project." presentationName="The Importance of Architecture in OpenUP/Basic" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif" conceptsAndPapers="_9gocwMvoEdqukPpotm3DYg _2plxwBOMEduCNqgZdt_OaA _0bsLgMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-clUV9n59dDwg0e1VCcsB8Q" href="uma://-clUV9n59dDwg0e1VCcsB8Q#-clUV9n59dDwg0e1VCcsB8Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_G08UgMEwEduwZvIr61GnNg" name="openup_risk" guid="_G08UgMEwEduwZvIr61GnNg" briefDescription="Risk is a reflection of uncertainty in a project. Reducing uncertainty increases the predictability and possible of success." presentationName="OpenUP/Basic constantly identifies and removes risk from a project" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-_BjYXvrfe1HHL5Y_QBfh4Q" href="uma://-_BjYXvrfe1HHL5Y_QBfh4Q#-_BjYXvrfe1HHL5Y_QBfh4Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_omneEMX4EduywMSzPTUUwA" name="resources_for_modifying_methods" guid="_omneEMX4EduywMSzPTUUwA" presentationName="Resources for Modifying Methods"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_t9yXEMX4EduywMSzPTUUwA" name="resources_for_contributing_to_openup" guid="_t9yXEMX4EduywMSzPTUUwA" presentationName="Resources for Contributing to OpenUP"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0cQzQMlgEdmt3adZL5Dmdw" name="templates" guid="_0cQzQMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0cW54MlgEdmt3adZL5Dmdw" name="vision" guid="_0cW54MlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing the Vision document." presentationName="Vision">
+ <presentation xmi:id="_LxX6AMM2EdmSIPI87WLu3g" href="uma://_LxX6AMM2EdmSIPI87WLu3g#_LxX6AMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0cpNwMlgEdmt3adZL5Dmdw" name="uc_specification" guid="_0cpNwMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing a use case specification." presentationName="Use-Case Specification">
+ <presentation xmi:id="_OaB-UMM2EdmSIPI87WLu3g" href="uma://_OaB-UMM2EdmSIPI87WLu3g#_OaB-UMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0c7hoMlgEdmt3adZL5Dmdw" name="project_plan" guid="_0c7hoMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template for representing the project plan." presentationName="Project Plan">
+ <presentation xmi:id="_XjOXcMM2EdmSIPI87WLu3g" href="uma://_XjOXcMM2EdmSIPI87WLu3g#_XjOXcMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0dBoQMlgEdmt3adZL5Dmdw" name="iteration_plan" guid="_0dBoQMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for an iteration plan." presentationName="Iteration Plan">
+ <presentation xmi:id="_Z_bUIMM2EdmSIPI87WLu3g" href="uma://_Z_bUIMM2EdmSIPI87WLu3g#_Z_bUIMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0dN1gMlgEdmt3adZL5Dmdw" name="software_arch_document" guid="_0dN1gMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing architecture." presentationName="Software Architecture Document">
+ <presentation xmi:id="_fJPGkMM2EdmSIPI87WLu3g" href="uma://_fJPGkMM2EdmSIPI87WLu3g#_fJPGkMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0dT8IMlgEdmt3adZL5Dmdw" name="test_case" guid="_0dT8IMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing test cases." presentationName="Test Case">
+ <presentation xmi:id="_j2pQ4MM2EdmSIPI87WLu3g" href="uma://_j2pQ4MM2EdmSIPI87WLu3g#_j2pQ4MM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_ItYXcNa9Edqrw4BYKyYKiA" name="supporting_requirements_spec" guid="_ItYXcNa9Edqrw4BYKyYKiA" briefDescription="This is the template suggested for specifying requirements and constraints in accordance with the FURPS+ classification." presentationName="Supporting Requirements Specification">
+ <presentation xmi:id="-FsyxZy4tyX8k5CxT5Jww_w" href="uma://-FsyxZy4tyX8k5CxT5Jww_w#-FsyxZy4tyX8k5CxT5Jww_w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="__JXkoCk8EduLGM8dfVsrKg" name="architecture" guid="__JXkoCk8EduLGM8dfVsrKg" briefDescription="Templates for representing the architecture work product." presentationName="Architecture">
+ <presentation xmi:id="-1Lm8-0FY-QIC56u5t2SC9w" href="uma://-1Lm8-0FY-QIC56u5t2SC9w#-1Lm8-0FY-QIC56u5t2SC9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_MIUO0C8FEduzydamRseoUw" name="risk_list" guid="_MIUO0C8FEduzydamRseoUw" briefDescription="A list or table containing risk attributes. As it is usual to rank risks by priority, spreadsheets may be an alternative to capture risks" presentationName="Risk List">
+ <presentation xmi:id="-OugFZJszm73z0_KSwRXZPw" href="uma://-OugFZJszm73z0_KSwRXZPw#-OugFZJszm73z0_KSwRXZPw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_QwUJYDg0Edu4E8ZdmlYjtA" name="work_items_list" guid="_QwUJYDg0Edu4E8ZdmlYjtA" briefDescription="This is a spreadsheet suggested for representing a work items list. Alternative templates would be usage of a specific tool or database with similar information." presentationName="Work Items List">
+ <presentation xmi:id="-mPA7vone29k1OvF_1rACjg" href="uma://-mPA7vone29k1OvF_1rACjg#-mPA7vone29k1OvF_1rACjg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_1awLIEp2Edup0IY9DKDPkg" name="status_assessment" guid="_1awLIEp2Edup0IY9DKDPkg" briefDescription="This is the informal template suggested for capturing and communicating the results of iteration assessments." presentationName="Status Assessment">
+ <presentation xmi:id="-2uQACndDBzBhJC1sCmk5UA" href="uma://-2uQACndDBzBhJC1sCmk5UA#-2uQACndDBzBhJC1sCmk5UA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_3E1NwDPBEduyTOpiJx8z_g" name="intent" guid="_3E1NwDPBEduyTOpiJx8z_g" briefDescription="Intent sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0b4YwMlgEdmt3adZL5Dmdw" name="change_management" guid="_0b4YwMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0cEmAMlgEdmt3adZL5Dmdw" name="workspace" guid="_0cEmAMlgEdmt3adZL5Dmdw" briefDescription="Workspace refers to storage areas where developers can implement and test code in accordance with the project's adopted standards in relative isolation from other developers." presentationName="Workspace">
+ <presentation xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" href="uma://_Dfmk8MPiEdmbOvqy4O0adg#_Dfmk8MPiEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0mwzEclgEdmt3adZL5Dmdw" name="request_change" guid="_0mwzEclgEdmt3adZL5Dmdw" briefDescription="Capture and record change requests." presentationName="Request Change" conceptsAndPapers="_6jdvECb3Edqh1LYUOGRh2A" guidelines="_fnZj0NVXEdqy9sbRhejO5Q" performedBy="_0dsWoMlgEdmt3adZL5Dmdw" output="_rGNWsCbSEdqh1LYUOGRh2A" optionalInput="_rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_Nr0S4KeqEdmKDbQuyzCoqQ" href="uma://_Nr0S4KeqEdmKDbQuyzCoqQ#_Nr0S4KeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_6jdvECb3Edqh1LYUOGRh2A" name="change_requests" guid="_6jdvECb3Edqh1LYUOGRh2A" briefDescription="A change request is a general term for any request to change a work product." presentationName="Change Requests" guidelines="_7vEXEMA4EdqSgKaj2SZBmg">
+ <presentation xmi:id="-BsXK3ZGMm-mUT0KnkdoYBg" href="uma://-BsXK3ZGMm-mUT0KnkdoYBg#-BsXK3ZGMm-mUT0KnkdoYBg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_fnZj0NVXEdqy9sbRhejO5Q" name="submitting_change_requests" guid="_fnZj0NVXEdqy9sbRhejO5Q" briefDescription="This guideline describes the type of information that is typically captured on a change request. This information is used to prioritize and scope the work required to implement the change and to monitor progress." presentationName="Submitting Change Requests">
+ <presentation xmi:id="-w7sImtXWkf4HDXdUWjRsUg" href="uma://-w7sImtXWkf4HDXdUWjRsUg#-w7sImtXWkf4HDXdUWjRsUg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="__Cw30ElxEducWJcS4yanqg" name="configuration" guid="__Cw30ElxEducWJcS4yanqg" presentationName="configuration">
+ <presentation xmi:id="-VPoMu7qzVX9grE4-nB3kMw" href="uma://-VPoMu7qzVX9grE4-nB3kMw#-VPoMu7qzVX9grE4-nB3kMw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_eX8K8ElyEducWJcS4yanqg" name="version" guid="_eX8K8ElyEducWJcS4yanqg" presentationName="version">
+ <presentation xmi:id="-4iL0UEFR2Fg7oWkh1TymIg" href="uma://-4iL0UEFR2Fg7oWkh1TymIg#-4iL0UEFR2Fg7oWkh1TymIg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0UCrYslgEdmt3adZL5Dmdw" name="requirements" guid="_0UCrYslgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_FtSMYAFjEduDPKiaP0pu-Q" name="uc_modeling" guid="_FtSMYAFjEduDPKiaP0pu-Q" briefDescription="This package contains elements specific to Use-Case Modeling technique.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0UCrZclgEdmt3adZL5Dmdw" name="uc_model_intent_req_ucm" guid="_0UCrZclgEdmt3adZL5Dmdw" briefDescription="This artifact captures a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers." variabilityType="contributes" variabilityBasedOnElement="_W2SgEDR5EdutE_HNDTJk5Q" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg _zGqO0MDpEduTGJ8i4u8TMw _KudM0NcJEdqz_d2XWoVt6Q" checklists="_0U6OEMlgEdmt3adZL5Dmdw _0VrDEMlgEdmt3adZL5Dmdw _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_0VAUsMlgEdmt3adZL5Dmdw" examples="_t4QdAMNqEdu2IdAIaWZyAw">
+ <presentation xmi:id="_zHZW9KYSEdmvhNXG0Oc2uA" href="uma://_zHZW9KYSEdmvhNXG0Oc2uA#_zHZW9KYSEdmvhNXG0Oc2uA"/>
+ <containedArtifacts xmi:id="_SBnZ4AFlEduDPKiaP0pu-Q" name="use_case_intent_req_ucm" guid="_SBnZ4AFlEduDPKiaP0pu-Q" variabilityType="contributes" variabilityBasedOnElement="_0VGbUMlgEdmt3adZL5Dmdw" examples="_JLOiIMNvEdu2IdAIaWZyAw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_txpV0AFmEduDPKiaP0pu-Q" name="find_and_outline_requirements_intent_req_ucm" guid="_txpV0AFmEduDPKiaP0pu-Q" orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1150923424568"> <gUIDs>_ckG-cCY-EdqNHcQ-rAojXw</gUIDs> <gUIDs>_GAr3IOz3Edq2wJOsmRwmhg</gUIDs> <gUIDs>_fDbgkCY-EdqNHcQ-rAojXw</gUIDs> <gUIDs>_XRKgkAFoEduDPKiaP0pu-Q</gUIDs> <gUIDs>_0WhHsN-eEdqiM_wFaqLjNg</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " variabilityType="contributes" variabilityBasedOnElement="_P9cMUPV_EdmdHa9MmVPgqQ" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg" checklists="_0U6OEMlgEdmt3adZL5Dmdw" guidelines="_0VAUsMlgEdmt3adZL5Dmdw" output="_0UCrZclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-Yt8TXGkE1rwydXR34apsrg" href="uma://-Yt8TXGkE1rwydXR34apsrg#-Yt8TXGkE1rwydXR34apsrg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_7_3vEAFmEduDPKiaP0pu-Q" name="detail_requirements_intent_req_ucm" guid="_7_3vEAFmEduDPKiaP0pu-Q" orderingGuide="<?xml version="1.0" encoding="ASCII"?> <org.eclipse.epf.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1158683054424"> <gUIDs>_vWeHMCxSEdqjsdw1QLH_6Q</gUIDs> <gUIDs>_B47VwCxTEdqjsdw1QLH_6Q</gUIDs> <gUIDs>_2389cOz2Edq2wJOsmRwmhg</gUIDs> <gUIDs>_w2JYgEf6EduISP1GQDlvVQ</gUIDs> <gUIDs>_BYbboN-bEdqiM_wFaqLjNg</gUIDs> </orderInfos> </org.eclipse.epf.uma.edit.tng.util.model:OrderInfoCollection> " variabilityType="contributes" variabilityBasedOnElement="_0e1mIMlgEdmt3adZL5Dmdw" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg" mandatoryInput="_0UCrZclgEdmt3adZL5Dmdw" output="_0UCrZclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-_mfd9ziTwQV_5LE80jJw4g" href="uma://-_mfd9ziTwQV_5LE80jJw4g#-_mfd9ziTwQV_5LE80jJw4g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0U6OEMlgEdmt3adZL5Dmdw" name="uc_model" guid="_0U6OEMlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that the Use-Case Model is described in a consistent and complete manner." presentationName="Use-Case Model">
+ <presentation xmi:id="_MqODAMM1EdmSIPI87WLu3g" href="uma://_MqODAMM1EdmSIPI87WLu3g#_MqODAMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0VAUsMlgEdmt3adZL5Dmdw" name="uc_model" guid="_0VAUsMlgEdmt3adZL5Dmdw" briefDescription="This guideline describes how to develop and evolve the use-case model to capture the functional requirements for the system under development." presentationName="Use-Case Model" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg" guidelines="_eyL0wCu-EdqSxKAVa9kmvA _4BJ_YCxSEdqjsdw1QLH_6Q">
+ <presentation xmi:id="_AGvpcMM3EdmSIPI87WLu3g" href="uma://_AGvpcMM3EdmSIPI87WLu3g#_AGvpcMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2jyfUAhVEduRe8TeoBmuGg" name="use_case_model" guid="_2jyfUAhVEduRe8TeoBmuGg" briefDescription="This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team." presentationName="Use-Case Model">
+ <presentation xmi:id="-yEWkrWZ3VUcjZPhq6bvScg" href="uma://-yEWkrWZ3VUcjZPhq6bvScg#-yEWkrWZ3VUcjZPhq6bvScg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_MO9vkDPKEdudA-StyUUwnw" name="analyst_intent_req_ucm" guid="_MO9vkDPKEdudA-StyUUwnw" variabilityType="contributes" variabilityBasedOnElement="_0VxJsMlgEdmt3adZL5Dmdw" responsibleFor="_0UCrZclgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0Wh-sMlgEdmt3adZL5Dmdw" name="requirements" guid="_0Wh-sMlgEdmt3adZL5Dmdw" briefDescription="This page provides an informal definition of a requirement and explains how the concept is related to the process." presentationName="Requirements">
+ <presentation xmi:id="_eUfzwMMyEdmdo9HxCRR_Gw" href="uma://_eUfzwMMyEdmdo9HxCRR_Gw#_eUfzwMMyEdmdo9HxCRR_Gw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0fOAoMlgEdmt3adZL5Dmdw" name="define_vision" guid="_0fOAoMlgEdmt3adZL5Dmdw" briefDescription="Define the vision for the future system. Describe the problem and features based on Stakeholder requests." orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1115151259496"> <gUIDs>_sa5F4LwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_tvzDULwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_vGg-oLwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_z7ZC4LwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_u0DWcKhXEdmsY5hhGsDstg</gUIDs> <gUIDs>_yl_-EKhXEdmsY5hhGsDstg</gUIDs> <gUIDs>_zQUfoKuHEdmhFZtkg1nakg</gUIDs> <gUIDs>_1LVn0LwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_2VixILwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_yq-j4LwPEdm6DujQZORGLQ</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " presentationName="Define Vision" conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw" checklists="_0WoFUMlgEdmt3adZL5Dmdw" guidelines="_OnoNQNSAEdmLhZ9H5Plxyw _E-dPIL-GEdqb7N6KIeDL8Q" performedBy="_0VxJsMlgEdmt3adZL5Dmdw" output="_0WVxcMlgEdmt3adZL5Dmdw _Wn7HcNcEEdqz_d2XWoVt6Q _rGNWsCbSEdqh1LYUOGRh2A" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0a0o0MlgEdmt3adZL5Dmdw _0X9iEMlgEdmt3adZL5Dmdw" optionalInput="_0WVxcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_5rJ78Lj3Edmy88CC3LfB_w" href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_5rJ78Lj3Edmy88CC3LfB_w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_P9cMUPV_EdmdHa9MmVPgqQ" name="find_and_outline_requirements" guid="_P9cMUPV_EdmdHa9MmVPgqQ" briefDescription="This task describes how to capture the requirements for the system." presentationName="Find and Outline Requirements" conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw _KudM0NcJEdqz_d2XWoVt6Q _VXZ5wO0IEdqHTdbLTmC5IQ _zGqO0MDpEduTGJ8i4u8TMw" checklists="_jxn9EO0HEdqHTdbLTmC5IQ _Vael8CGMEdu3VKXZx45D3A _0VrDEMlgEdmt3adZL5Dmdw _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_OnoNQNSAEdmLhZ9H5Plxyw _eyL0wCu-EdqSxKAVa9kmvA _wr24gNcGEdqz_d2XWoVt6Q _E-dPIL-GEdqb7N6KIeDL8Q _1AOsMO0JEdqHTdbLTmC5IQ _6jXzYNcKEdqz_d2XWoVt6Q" performedBy="_0VxJsMlgEdmt3adZL5Dmdw" mandatoryInput="_Wn7HcNcEEdqz_d2XWoVt6Q _0WVxcMlgEdmt3adZL5Dmdw" output="_rGNWsCbSEdqh1LYUOGRh2A _BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q _0VGbUMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0X9iEMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_P9iS8PV_EdmdHa9MmVPgqQ" href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_P9iS8PV_EdmdHa9MmVPgqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_OnoNQNSAEdmLhZ9H5Plxyw" name="req_gathering_techniques" guid="_OnoNQNSAEdmLhZ9H5Plxyw" briefDescription="This guideline describes various techniques for gathering requirements." presentationName="Requirements Gathering Techniques">
+ <presentation xmi:id="_On0agNSAEdmLhZ9H5Plxyw" href="uma://_On0agNSAEdmLhZ9H5Plxyw#_On0agNSAEdmLhZ9H5Plxyw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0e1mIMlgEdmt3adZL5Dmdw" name="detail_requirements" guid="_0e1mIMlgEdmt3adZL5Dmdw" briefDescription="This task describes how to detail one or more requirements for the system." orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1113334493908"> <gUIDs>_yqm4kKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_zg2kEKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_1GGDkKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_35vP4KuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_5mtIAKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_7g3HkKuJEdmhFZtkg1nakg</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " presentationName="Detail Requirements" conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw _KudM0NcJEdqz_d2XWoVt6Q _VXZ5wO0IEdqHTdbLTmC5IQ _VQ268O0KEdqHTdbLTmC5IQ _eYtQQO0KEdqHTdbLTmC5IQ" checklists="_jxn9EO0HEdqHTdbLTmC5IQ _Vael8CGMEdu3VKXZx45D3A _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_4BJ_YCxSEdqjsdw1QLH_6Q _E-dPIL-GEdqb7N6KIeDL8Q _1AOsMO0JEdqHTdbLTmC5IQ _6jXzYNcKEdqz_d2XWoVt6Q _qq0GMAXkEduj_7BEUj1JfQ" performedBy="_0VxJsMlgEdmt3adZL5Dmdw" mandatoryInput="_BVh9cL-CEdqb7N6KIeDL8Q _0WVxcMlgEdmt3adZL5Dmdw _Wn7HcNcEEdqz_d2XWoVt6Q _0VGbUMlgEdmt3adZL5Dmdw" output="_BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q _0VGbUMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0X9iEMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_Nqwi8KeqEdmKDbQuyzCoqQ" href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_Nqwi8KeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_eyL0wCu-EdqSxKAVa9kmvA" name="find_and_outline_actors_and_ucs" guid="_eyL0wCu-EdqSxKAVa9kmvA" briefDescription="This guideline describes how to find and outline actors and use cases." presentationName="Find and Outline Actors and Use Cases" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q _zGqO0MDpEduTGJ8i4u8TMw _2jyfUAhVEduRe8TeoBmuGg">
+ <presentation xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" href="uma://-Rcm_MlViENAvFFyIe9V3dQ#-Rcm_MlViENAvFFyIe9V3dQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4BJ_YCxSEdqjsdw1QLH_6Q" name="detail_ucs_and_scenarios" guid="_4BJ_YCxSEdqjsdw1QLH_6Q" briefDescription="This guideline provides help on detailing use cases and scenarios." presentationName="Detail Use Cases and Scenarios" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q _VXZ5wO0IEdqHTdbLTmC5IQ" guidelines="_qq0GMAXkEduj_7BEUj1JfQ">
+ <presentation xmi:id="-78ko4CuOJERKJF9ZvwMUBQ" href="uma://-78ko4CuOJERKJF9ZvwMUBQ#-78ko4CuOJERKJF9ZvwMUBQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_E-dPIL-GEdqb7N6KIeDL8Q" name="effective_req_reviews" guid="_E-dPIL-GEdqb7N6KIeDL8Q" briefDescription="This guideline discusses how to conduct reviews with relevant stakeholders to ensure agreement, assess quality, and identify changes required." presentationName="Effective Requirement Reviews">
+ <presentation xmi:id="-pNA0DbSdSoUqnjQIiOeHcQ" href="uma://-pNA0DbSdSoUqnjQIiOeHcQ#-pNA0DbSdSoUqnjQIiOeHcQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_wr24gNcGEdqz_d2XWoVt6Q" name="supporting_requirements" guid="_wr24gNcGEdqz_d2XWoVt6Q" briefDescription="This guideline explains how to develop and use the supporting requirements specification." presentationName="Supporting Requirements">
+ <presentation xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" href="uma://-BdYFG4-dbPBGFzF9z6KGPA#-BdYFG4-dbPBGFzF9z6KGPA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_feKVQLULEdqI644ssJaKYg" name="requirement" guid="_feKVQLULEdqI644ssJaKYg" presentationName="Requirements">
+ <presentation xmi:id="-0sCBiohjw_wBDKk0WEeDJQ" href="uma://-0sCBiohjw_wBDKk0WEeDJQ#-0sCBiohjw_wBDKk0WEeDJQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_6jXzYNcKEdqz_d2XWoVt6Q" name="writing_good_requirements" guid="_6jXzYNcKEdqz_d2XWoVt6Q" briefDescription="This guideline describes ways of writing good requirements." presentationName="Writing Good Requirements">
+ <presentation xmi:id="-AJQLv2ldVv5KN9eUbdQe_g" href="uma://-AJQLv2ldVv5KN9eUbdQe_g#-AJQLv2ldVv5KN9eUbdQe_g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0kNwINk1Edq2Q8qZoWbvGA" name="use_case" guid="_0kNwINk1Edq2Q8qZoWbvGA" briefDescription="This checklist provides questions to verify that use cases are described in a consistent and complete manner." presentationName="Use Case" variabilityType="replaces" checklists="_jxn9EO0HEdqHTdbLTmC5IQ">
+ <presentation xmi:id="-T2IeqdOunweffIDgL-aM0w" href="uma://-T2IeqdOunweffIDgL-aM0w#-T2IeqdOunweffIDgL-aM0w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_1AOsMO0JEdqHTdbLTmC5IQ" name="requirement_pitfalls" guid="_1AOsMO0JEdqHTdbLTmC5IQ" briefDescription="This guideline describes common pitfalls to avoid in defining and writing requirements. In some cases these are the inverse of the guidelines for writing good requirements, however, by showing examples of what NOT to do makes the explanation of what TO DO clearer." presentationName="Requirement Pitfalls">
+ <presentation xmi:id="-Q72-dNdHnZ93aRXAB_d34A" href="uma://-Q72-dNdHnZ93aRXAB_d34A#-Q72-dNdHnZ93aRXAB_d34A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VQ268O0KEdqHTdbLTmC5IQ" name="requirement_attributes" guid="_VQ268O0KEdqHTdbLTmC5IQ" briefDescription="Requirements attributes capture additional information, such as risk, planned iteration, source of requirement, about each requirement. This additional information is used to manage the project." presentationName="Requirement Attributes">
+ <presentation xmi:id="-fCBrf_5JlrmuKgyrCaKGOA" href="uma://-fCBrf_5JlrmuKgyrCaKGOA#-fCBrf_5JlrmuKgyrCaKGOA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_eYtQQO0KEdqHTdbLTmC5IQ" name="traceability" guid="_eYtQQO0KEdqHTdbLTmC5IQ" briefDescription="Traceability is a term used to describe the establishment and maintenance of relationships between artifacts, such as a requirement and a design class or a requirement and a test case, so that you can track the completeness of work &lt;strong&gt; &lt;/strong&gt;and assess the impact of changes." presentationName="Traceability">
+ <presentation xmi:id="-TksCtMgc0b4QqzwzniGvIw" href="uma://-TksCtMgc0b4QqzwzniGvIw#-TksCtMgc0b4QqzwzniGvIw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_qq0GMAXkEduj_7BEUj1JfQ" name="use_case_formats" guid="_qq0GMAXkEduj_7BEUj1JfQ" briefDescription="This guideline describes different use case formats and associated levels of detail that you may want to use, depending upon the nature of the project." presentationName="Use Case Formats">
+ <presentation xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" href="uma://-pQrBSyxJHLLodLbS4R_Zdw#-pQrBSyxJHLLodLbS4R_Zdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_PgYREAeYEduWycDgioo5rg" name="feature" guid="_PgYREAeYEduWycDgioo5rg" presentationName="Feature">
+ <presentation xmi:id="-qpBnpWqiD7gjT08LjTMbsQ" href="uma://-qpBnpWqiD7gjT08LjTMbsQ#-qpBnpWqiD7gjT08LjTMbsQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_WUiFcAeYEduWycDgioo5rg" name="stakeholder_need" guid="_WUiFcAeYEduWycDgioo5rg" presentationName="Stakeholder Need">
+ <presentation xmi:id="-1pmL5bC27rtWB84PXAgq9Q" href="uma://-1pmL5bC27rtWB84PXAgq9Q#-1pmL5bC27rtWB84PXAgq9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_Vael8CGMEdu3VKXZx45D3A" name="supporting_requirements" guid="_Vael8CGMEdu3VKXZx45D3A" briefDescription="This check list is used to verify that all types of supporting requirements are considered." presentationName="Supporting Requirements">
+ <presentation xmi:id="-kw2vYHKDkWv2tZrDMrBPNA" href="uma://-kw2vYHKDkWv2tZrDMrBPNA#-kw2vYHKDkWv2tZrDMrBPNA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_oclg0DRXEdudA-StyUUwnw" name="supporting_requirements_intent_req" guid="_oclg0DRXEdudA-StyUUwnw" variabilityType="contributes" variabilityBasedOnElement="_BVh9cL-CEdqb7N6KIeDL8Q" checklists="_Vael8CGMEdu3VKXZx45D3A _jxn9EO0HEdqHTdbLTmC5IQ" guidelines="_wr24gNcGEdqz_d2XWoVt6Q" templates="_ItYXcNa9Edqrw4BYKyYKiA">
+ <presentation xmi:id="-SUqkkwrs1D_5YXZls-3YBg" href="uma://-SUqkkwrs1D_5YXZls-3YBg#-SUqkkwrs1D_5YXZls-3YBg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_qis78DRbEduFvfVCXiK3AA" name="use_case_intent_req" guid="_qis78DRbEduFvfVCXiK3AA" variabilityType="contributes" variabilityBasedOnElement="_0VGbUMlgEdmt3adZL5Dmdw" checklists="_0kNwINk1Edq2Q8qZoWbvGA" templates="_0cpNwMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-JcGDIeBIMM099mbWX5fXbA" href="uma://-JcGDIeBIMM099mbWX5fXbA#-JcGDIeBIMM099mbWX5fXbA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_6OAFQDRdEduFvfVCXiK3AA" name="vision_intent_req" guid="_6OAFQDRdEduFvfVCXiK3AA" variabilityType="contributes" variabilityBasedOnElement="_0WVxcMlgEdmt3adZL5Dmdw" templates="_0cW54MlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_t4QdAMNqEdu2IdAIaWZyAw" name="uc_model_evolve" guid="_t4QdAMNqEdu2IdAIaWZyAw" briefDescription="This example illustrates how the use-case model evolves over time when using a &quot;breadth before depth&quot; approach to maximize value and minimize risk early in the lifecycle and to minimize re-work later." presentationName="Evolution of the Use-Case Model">
+ <presentation xmi:id="-JviMIao63C7w9C8W6iPJrw" href="uma://-JviMIao63C7w9C8W6iPJrw#-JviMIao63C7w9C8W6iPJrw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_JLOiIMNvEdu2IdAIaWZyAw" name="use_case_spec" guid="_JLOiIMNvEdu2IdAIaWZyAw" briefDescription="This is an example of a completed use-case specification for the Withdraw Cash use case for an Automated Teller Machine." presentationName="Use-Case Specification" examples="_t4QdAMNqEdu2IdAIaWZyAw">
+ <presentation xmi:id="-qq-9Brh5oa6H3lsdp-m8mQ" href="uma://-qq-9Brh5oa6H3lsdp-m8mQ#-qq-9Brh5oa6H3lsdp-m8mQ"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_IIPZQDRjEduU7vV49F9N0A" name="test" guid="_IIPZQDRjEduU7vV49F9N0A" briefDescription="Portion of testing discipline that relates to Intent.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0iwc0clgEdmt3adZL5Dmdw" name="create_test_cases" guid="_0iwc0clgEdmt3adZL5Dmdw" briefDescription="Develop the test cases and test data for the requirements to be tested." presentationName="Create Test Cases" conceptsAndPapers="_0jnYcMlgEdmt3adZL5Dmdw" performedBy="_0ZM4MclgEdmt3adZL5Dmdw" mandatoryInput="_0VGbUMlgEdmt3adZL5Dmdw" output="_0ZS-0MlgEdmt3adZL5Dmdw" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0YDosMlgEdmt3adZL5Dmdw" optionalInput="_0ZS-0MlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q">
+ <presentation xmi:id="_NrVKsKeqEdmKDbQuyzCoqQ" href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_NrVKsKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0jnYcMlgEdmt3adZL5Dmdw" name="test_ideas" guid="_0jnYcMlgEdmt3adZL5Dmdw" briefDescription="A list of test ideas sorted in decreasing order of importance and associated with specific testing strategies used to create executable tests." presentationName="Test Ideas">
+ <presentation xmi:id="_uqL2gMM3EdmSIPI87WLu3g" href="uma://_uqL2gMM3EdmSIPI87WLu3g#_uqL2gMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0aJ6cMlgEdmt3adZL5Dmdw" name="types_of_test" guid="_0aJ6cMlgEdmt3adZL5Dmdw" briefDescription="Testing is applied to different types of targets, in different stages or levels of work effort. This Concept introduces various types of test." presentationName="Types of Test">
+ <presentation xmi:id="_y-_PIMPdEdmbOvqy4O0adg" href="uma://_y-_PIMPdEdmbOvqy4O0adg#_y-_PIMPdEdmbOvqy4O0adg"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZsK30EvBEdunZcj9T5hrMQ" name="actor" guid="_ZsK30EvBEdunZcj9T5hrMQ" presentationName="actor">
+ <presentation xmi:id="-4RQJzq_1URTZ5FGCBKnTIw" href="uma://-4RQJzq_1URTZ5FGCBKnTIw#-4RQJzq_1URTZ5FGCBKnTIw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_GEAwAEvCEdunZcj9T5hrMQ" name="analyst" guid="_GEAwAEvCEdunZcj9T5hrMQ" presentationName="analyst">
+ <presentation xmi:id="-1RwpgmmY974S0YkxEOFDCw" href="uma://-1RwpgmmY974S0YkxEOFDCw#-1RwpgmmY974S0YkxEOFDCw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_NtGL0EvDEdunZcj9T5hrMQ" name="business_rule" guid="_NtGL0EvDEdunZcj9T5hrMQ" presentationName="business rule">
+ <presentation xmi:id="-COrjB4k8Qtf6ZpPEcBNwpw" href="uma://-COrjB4k8Qtf6ZpPEcBNwpw#-COrjB4k8Qtf6ZpPEcBNwpw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZH6M0EvEEdunZcj9T5hrMQ" name="furps" guid="_ZH6M0EvEEdunZcj9T5hrMQ" presentationName="FURPS+">
+ <presentation xmi:id="-vq2pL6yQuqGhql9Wo_Av4w" href="uma://-vq2pL6yQuqGhql9Wo_Av4w#-vq2pL6yQuqGhql9Wo_Av4w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_VhhDMEvrEdunZcj9T5hrMQ" name="glossary" guid="_VhhDMEvrEdunZcj9T5hrMQ" presentationName="glossary">
+ <presentation xmi:id="-05pn_DGdNui9qqwx46iKZQ" href="uma://-05pn_DGdNui9qqwx46iKZQ#-05pn_DGdNui9qqwx46iKZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_U_olUEvDEdunZcj9T5hrMQ" name="supporting_requirement" guid="_U_olUEvDEdunZcj9T5hrMQ" presentationName="Supporting Requirements">
+ <presentation xmi:id="-ketzwgDgY82DMyfuHqu3Cw" href="uma://-ketzwgDgY82DMyfuHqu3Cw#-ketzwgDgY82DMyfuHqu3Cw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_IHRO8EvHEdunZcj9T5hrMQ" name="use_case" guid="_IHRO8EvHEdunZcj9T5hrMQ" presentationName="use case">
+ <presentation xmi:id="-HDfMzDXoilK-f2iNreHRVg" href="uma://-HDfMzDXoilK-f2iNreHRVg#-HDfMzDXoilK-f2iNreHRVg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_k6B3kEvmEdunZcj9T5hrMQ" name="use_case_model" guid="_k6B3kEvmEdunZcj9T5hrMQ" presentationName="use-case model">
+ <presentation xmi:id="-UTrE64wEDJIC1FRUomEYDg" href="uma://-UTrE64wEDJIC1FRUomEYDg#-UTrE64wEDJIC1FRUomEYDg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_oXmYMEvGEdunZcj9T5hrMQ" name="use_case_scenario" guid="_oXmYMEvGEdunZcj9T5hrMQ" presentationName="use-case scenario">
+ <presentation xmi:id="-t3jNM5ZWkYtzB8A4Chz2Vw" href="uma://-t3jNM5ZWkYtzB8A4Chz2Vw#-t3jNM5ZWkYtzB8A4Chz2Vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_J_5kgEvHEdunZcj9T5hrMQ" name="vision" guid="_J_5kgEvHEdunZcj9T5hrMQ" presentationName="vision">
+ <presentation xmi:id="-VMnkFJpPLdEDUpbz2QDgow" href="uma://-VMnkFJpPLdEDUpbz2QDgow#-VMnkFJpPLdEDUpbz2QDgow"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_kB42IDRiEduU7vV49F9N0A" name="solution" guid="_kB42IDRiEduU7vV49F9N0A" briefDescription="Solution sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0WuL8MlgEdmt3adZL5Dmdw" name="architecture" guid="_0WuL8MlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0WuL8clgEdmt3adZL5Dmdw" name="visual_modeling" guid="_0WuL8clgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0XY6UMlgEdmt3adZL5Dmdw" name="visual_modeling" guid="_0XY6UMlgEdmt3adZL5Dmdw" briefDescription="This concept introduces the use of semantically rich graphical and textual design notations to capture software designs." presentationName="Visual Modeling" guidelines="_we3F4ACpEdu8m4dIntu6jA">
+ <presentation xmi:id="_SB1n8MM1EdmSIPI87WLu3g" href="uma://_SB1n8MM1EdmSIPI87WLu3g#_SB1n8MM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_lRV2QEvkEduCAaECSrUMPQ" name="architecture_vm" guid="_lRV2QEvkEduCAaECSrUMPQ" variabilityType="contributes" variabilityBasedOnElement="_0XAf0MlgEdmt3adZL5Dmdw" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_HZGFsKrPEdu6T6WyNqBzqQ" name="component_vm" guid="_HZGFsKrPEdu6T6WyNqBzqQ" variabilityType="contributes" variabilityBasedOnElement="_0YP18MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-zfl87vJBFdinDB02ArLXOQ" href="uma://-zfl87vJBFdinDB02ArLXOQ#-zfl87vJBFdinDB02ArLXOQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_34jWsLcIEduRNaXpzCOLXQ" name="abstract_away_complexity_vm" guid="_34jWsLcIEduRNaXpzCOLXQ" variabilityType="contributes" variabilityBasedOnElement="_we3F4ACpEdu8m4dIntu6jA" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-OcMsciNn-UtD9fTHj26LGA" href="uma://-OcMsciNn-UtD9fTHj26LGA#-OcMsciNn-UtD9fTHj26LGA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_SYDjUMUKEdu5GrwIlTJV7g" name="analyze_arch_reqs_vm" guid="_SYDjUMUKEdu5GrwIlTJV7g" variabilityType="contributes" variabilityBasedOnElement="_42UD4A3tEduibvKwrGxWxA" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-I-2SvZtjELUYDQO0jvdxEA" href="uma://-I-2SvZtjELUYDQO0jvdxEA#-I-2SvZtjELUYDQO0jvdxEA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_douywISSEdu8NaFPL8nS_w" name="uc_modeling" guid="_douywISSEdu8NaFPL8nS_w">
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_YdaogAI9Edu5WetVoS7Gvw" name="analyze_arch_reqs_ucm" guid="_YdaogAI9Edu5WetVoS7Gvw" variabilityType="contributes" variabilityBasedOnElement="_0f-1oMlgEdmt3adZL5Dmdw" mandatoryInput="_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_h15dULCxEdujaOuld2kPdg" name="deprecated" guid="_h15dULCxEdujaOuld2kPdg" briefDescription="This is a temporary content package to hold old copies of elements while they are refactored for release 1.0 It should be deleted before final release. This package should not be published.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0cr7cACrEdu8m4dIntu6jA" name="using_patterns" guid="_0cr7cACrEdu8m4dIntu6jA" briefDescription="This guidance discusses the practical application of patterns in a project." presentationName="Using Patterns">
+ <presentation xmi:id="-U-5cLUk-mdaO518lh5CxTQ" href="uma://-U-5cLUk-mdaO518lh5CxTQ#-U-5cLUk-mdaO518lh5CxTQ"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0YJvUMlgEdmt3adZL5Dmdw" name="pattern" guid="_0YJvUMlgEdmt3adZL5Dmdw" briefDescription="A generalized solution that can be implemented and applied in a problem situation (a context) and thereby eliminate one or more of the inherent problems." presentationName="Pattern">
+ <presentation xmi:id="_QvmkAMM1EdmSIPI87WLu3g" href="uma://_QvmkAMM1EdmSIPI87WLu3g#_QvmkAMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0YP18MlgEdmt3adZL5Dmdw" name="component" guid="_0YP18MlgEdmt3adZL5Dmdw" briefDescription="An encapsulated part of a system that is, ideally, a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of well-defined architecture." presentationName="Component">
+ <presentation xmi:id="_TZiasMM1EdmSIPI87WLu3g" href="uma://_TZiasMM1EdmSIPI87WLu3g#_TZiasMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0f-1oMlgEdmt3adZL5Dmdw" name="analyze_arch_reqs" guid="_0f-1oMlgEdmt3adZL5Dmdw" briefDescription="Analyze the architecturally significant requirements and define a candidate architecture for the system. Define the architectural patterns, key mechanisms, and where applicable, modeling conventions for the system." presentationName="Analyze the Architectural Requirements" conceptsAndPapers="_HrZGIA4MEduibvKwrGxWxA _mzxI0A4LEduibvKwrGxWxA __O7tAMVvEduLYZUGfgZrkQ" guidelines="_42UD4A3tEduibvKwrGxWxA _0gpkAMlgEdmt3adZL5Dmdw" performedBy="_0X9iEMlgEdmt3adZL5Dmdw" mandatoryInput="_Wn7HcNcEEdqz_d2XWoVt6Q _0WVxcMlgEdmt3adZL5Dmdw" output="_0XAf0MlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0a0o0MlgEdmt3adZL5Dmdw" optionalInput="_0WuL8slgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw _0VGbUMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q">
+ <presentation xmi:id="_qDRSULBKEdm7Eph_l9Cn9w" href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_qDRSULBKEdm7Eph_l9Cn9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0gRJgMlgEdmt3adZL5Dmdw" name="develop_arch" guid="_0gRJgMlgEdmt3adZL5Dmdw" briefDescription="Make concrete decisions about the architecture to provide guidance and direction to the development work for the iteration." presentationName="Develop the Architecture" conceptsAndPapers="_Z53x0BapEduSTJywppIxVQ _w2ACwA4LEduibvKwrGxWxA _mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA __O7tAMVvEduLYZUGfgZrkQ" guidelines="_mDf2EBapEduSTJywppIxVQ" performedBy="_0X9iEMlgEdmt3adZL5Dmdw" mandatoryInput="_0WuL8slgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _0VGbUMlgEdmt3adZL5Dmdw _0WVxcMlgEdmt3adZL5Dmdw _0YuXEMlgEdmt3adZL5Dmdw" output="_0WuL8slgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0a0o0MlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_rUis8LBKEdm7Eph_l9Cn9w" href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_rUis8LBKEdm7Eph_l9Cn9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0XAf0MlgEdmt3adZL5Dmdw" name="architecture_notebook" guid="_0XAf0MlgEdmt3adZL5Dmdw" briefDescription="The Architecture Notebook describes the blueprint for software development. It contains the rationale, assumptions, explanations and implications of the decisions that were made in forming the architecture." presentationName="Architecture Notebook" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw _0YP18MlgEdmt3adZL5Dmdw __O7tAMVvEduLYZUGfgZrkQ" checklists="_17PYUNd6EdmIm-bsRSNCgw" guidelines="_T9nygClEEduLGM8dfVsrKg _0gpkAMlgEdmt3adZL5Dmdw _0gjdYMlgEdmt3adZL5Dmdw _we3F4ACpEdu8m4dIntu6jA" templates="__JXkoCk8EduLGM8dfVsrKg">
+ <presentation xmi:id="_H4gOYKYTEdmvhNXG0Oc2uA" href="uma://_H4gOYKYTEdmvhNXG0Oc2uA#_H4gOYKYTEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0gvqoMlgEdmt3adZL5Dmdw" name="analysis_mechanism" guid="_0gvqoMlgEdmt3adZL5Dmdw" briefDescription="An Analysis Mechanism is a conceptual representation of an Architectural Mechanism." presentationName="Analysis Mechanism" conceptsAndPapers="_HrZGIA4MEduibvKwrGxWxA _mzxI0A4LEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA" guidelines="_4k_HsA4LEduibvKwrGxWxA _4k_HsQ4LEduibvKwrGxWxA">
+ <presentation xmi:id="_S8KCcMP2EdmWKcx6ixEiwg" href="uma://_S8KCcMP2EdmWKcx6ixEiwg#_S8KCcMP2EdmWKcx6ixEiwg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_17PYUNd6EdmIm-bsRSNCgw" name="architecture" guid="_17PYUNd6EdmIm-bsRSNCgw" briefDescription="This checklist provides questions to help in evaluating whether architectural decisions have been captured appropriately." presentationName="Architecture" conceptsAndPapers="_mzxI0A4LEduibvKwrGxWxA">
+ <presentation xmi:id="_17Ve8Nd6EdmIm-bsRSNCgw" href="uma://_17Ve8Nd6EdmIm-bsRSNCgw#_17Ve8Nd6EdmIm-bsRSNCgw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0gpkAMlgEdmt3adZL5Dmdw" name="layering" guid="_0gpkAMlgEdmt3adZL5Dmdw" briefDescription="Guidance on the possible ways for partitioning the system." presentationName="Layering" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw" guidelines="_0cr7cACrEdu8m4dIntu6jA">
+ <presentation xmi:id="_lbGQwMM3EdmSIPI87WLu3g" href="uma://_lbGQwMM3EdmSIPI87WLu3g#_lbGQwMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0gjdYMlgEdmt3adZL5Dmdw" name="repres_interfaces_to_ext_systems" guid="_0gjdYMlgEdmt3adZL5Dmdw" briefDescription="This guideline introduces system level interfaces." presentationName="Representing Interfaces to External Systems" conceptsAndPapers="_uF-QYEAhEdq_UJTvM1DM2Q">
+ <presentation xmi:id="_iCwb8MM3EdmSIPI87WLu3g" href="uma://_iCwb8MM3EdmSIPI87WLu3g#_iCwb8MM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_42UD4A3tEduibvKwrGxWxA" name="analyze_arch_reqs" guid="_42UD4A3tEduibvKwrGxWxA" briefDescription="This guideline provides additional information to support the analysis of architecturally significant requirements and the creation of an outline architecture." presentationName="Analyze the Architectural Requirements" guidelines="_0gpkAMlgEdmt3adZL5Dmdw _T9nygClEEduLGM8dfVsrKg">
+ <presentation xmi:id="-YeVRerdEixh4HgHOuw2KRQ" href="uma://-YeVRerdEixh4HgHOuw2KRQ#-YeVRerdEixh4HgHOuw2KRQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_mzxI0A4LEduibvKwrGxWxA" name="arch_mech" guid="_mzxI0A4LEduibvKwrGxWxA" briefDescription="Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity." presentationName="Architectural Mechanism" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw _0gvqoMlgEdmt3adZL5Dmdw _HrZGIA4MEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA" guidelines="_4k_HsA4LEduibvKwrGxWxA _4k_HsQ4LEduibvKwrGxWxA _4k_Hsg4LEduibvKwrGxWxA">
+ <presentation xmi:id="-SJrpVySJ2npYs8NwGvnHjw" href="uma://-SJrpVySJ2npYs8NwGvnHjw#-SJrpVySJ2npYs8NwGvnHjw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_w2ACwA4LEduibvKwrGxWxA" name="design_mechanism" guid="_w2ACwA4LEduibvKwrGxWxA" briefDescription="A Design Mechanism is a concrete representation of an Architectural Mechanism." presentationName="Design Mechanism" conceptsAndPapers="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw" guidelines="_4k_Hsg4LEduibvKwrGxWxA _0cr7cACrEdu8m4dIntu6jA">
+ <presentation xmi:id="-EG22TRyJ5TDKW6U88AXfhw" href="uma://-EG22TRyJ5TDKW6U88AXfhw#-EG22TRyJ5TDKW6U88AXfhw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0LcUkA4LEduibvKwrGxWxA" name="implementation_mechanism" guid="_0LcUkA4LEduibvKwrGxWxA" briefDescription="A representation of an Architecture Mechanism that uses a specific programming language or product." presentationName="Implementation Mechanism" conceptsAndPapers="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA" guidelines="_4k_Hsg4LEduibvKwrGxWxA">
+ <presentation xmi:id="-Rex8oOBv985RruZNrCW0rg" href="uma://-Rex8oOBv985RruZNrCW0rg#-Rex8oOBv985RruZNrCW0rg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4k_HsA4LEduibvKwrGxWxA" name="example_analysis_mechanisms_descr" guid="_4k_HsA4LEduibvKwrGxWxA" briefDescription="Examples showing how to describe Analysis Mechanisms" presentationName="Example Analysis Mechanism Descriptions">
+ <presentation xmi:id="-CJ--jlBqXi3FzdOM_dw5_w" href="uma://-CJ--jlBqXi3FzdOM_dw5_w#-CJ--jlBqXi3FzdOM_dw5_w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4k_HsQ4LEduibvKwrGxWxA" name="example_architectural_mechanisms" guid="_4k_HsQ4LEduibvKwrGxWxA" briefDescription="Commonly encountered architectural mechanisms" presentationName="Example Architectural Mechanisms">
+ <presentation xmi:id="-FqP5LgLVrlhvFC_eeYd_vA" href="uma://-FqP5LgLVrlhvFC_eeYd_vA#-FqP5LgLVrlhvFC_eeYd_vA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4k_Hsg4LEduibvKwrGxWxA" name="example_design_mechanisms" guid="_4k_Hsg4LEduibvKwrGxWxA" briefDescription="Examples that show how to describe design mechanisms" presentationName="Example: Design Mechanisms">
+ <presentation xmi:id="-mAo18f36rZ1R98kpZX7HMw" href="uma://-mAo18f36rZ1R98kpZX7HMw#-mAo18f36rZ1R98kpZX7HMw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_HrZGIA4MEduibvKwrGxWxA" name="architecturally_significant_requirements" guid="_HrZGIA4MEduibvKwrGxWxA" briefDescription="Some requirements have a profound impact on the architecture of the solution and require special attention." presentationName="Architecturally Significant Requirements">
+ <presentation xmi:id="-EytH4BCNGiHF6pZrp8ISCw" href="uma://-EytH4BCNGiHF6pZrp8ISCw#-EytH4BCNGiHF6pZrp8ISCw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Z53x0BapEduSTJywppIxVQ" name="business_pattern" guid="_Z53x0BapEduSTJywppIxVQ" briefDescription="A re-usable portion of design that can be applied to multiple domain-specific activities." presentationName="Business Pattern" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw" guidelines="_0cr7cACrEdu8m4dIntu6jA">
+ <presentation xmi:id="-Of51hmgdsO_U2-pnbJ67Cg" href="uma://-Of51hmgdsO_U2-pnbJ67Cg#-Of51hmgdsO_U2-pnbJ67Cg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_mDf2EBapEduSTJywppIxVQ" name="develop_architecture" guid="_mDf2EBapEduSTJywppIxVQ" briefDescription="This guideline provides additional information to support the ongoing refinement and development of the architecture." presentationName="Develop the Architecture" conceptsAndPapers="_Z53x0BapEduSTJywppIxVQ" guidelines="_T9nygClEEduLGM8dfVsrKg">
+ <presentation xmi:id="-t7mQSRPYITkMoYRVNz7jQg" href="uma://-t7mQSRPYITkMoYRVNz7jQg#-t7mQSRPYITkMoYRVNz7jQg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_T9nygClEEduLGM8dfVsrKg" name="architectural_view" guid="_T9nygClEEduLGM8dfVsrKg" briefDescription="Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of the system." presentationName="Architectural View" guidelines="_0X3bcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-cnGBBA4NXmhTIjHjlHx4Mw" href="uma://-cnGBBA4NXmhTIjHjlHx4Mw#-cnGBBA4NXmhTIjHjlHx4Mw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_cH6f0DR7EduwLdLujGQAIQ" name="architect_sln" guid="_cH6f0DR7EduwLdLujGQAIQ" variabilityType="contributes" variabilityBasedOnElement="_0X9iEMlgEdmt3adZL5Dmdw" conceptsAndPapers="__O7tAMVvEduLYZUGfgZrkQ" responsibleFor="_0XAf0MlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_we3F4ACpEdu8m4dIntu6jA" name="abstract_away_complexity" guid="_we3F4ACpEdu8m4dIntu6jA" presentationName="Abstract Away Complexity" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw _0YP18MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-X7QSjItNBz7w8603yBCv0Q" href="uma://-X7QSjItNBz7w8603yBCv0Q#-X7QSjItNBz7w8603yBCv0Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="__O7tAMVvEduLYZUGfgZrkQ" name="software_architecture" guid="__O7tAMVvEduLYZUGfgZrkQ" briefDescription="The software architecture represents the structure or structures of the system, which consists of software components, the externally visible properties of those components, and the relationships among them." presentationName="Software Architecture">
+ <presentation xmi:id="-UQ_e8kozIP11Xu008RJd-A" href="uma://-UQ_e8kozIP11Xu008RJd-A#-UQ_e8kozIP11Xu008RJd-A"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0YcDMMlgEdmt3adZL5Dmdw" name="development" guid="_0YcDMMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_PGDx8PisEdmjyaJMRcPDWA" name="visual_modeling" guid="_PGDx8PisEdmjyaJMRcPDWA">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_ZTGAYL3uEdqLRJZPGVbHDA" name="design_vm" guid="_ZTGAYL3uEdqLRJZPGVbHDA" variabilityType="contributes" variabilityBasedOnElement="_0WuL8slgEdmt3adZL5Dmdw" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_T8WvwL3vEdqLRJZPGVbHDA" name="design_solution_vm" guid="_T8WvwL3vEdqLRJZPGVbHDA" briefDescription="Render the design visually to aid in solving the problem and communicating the solution." orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1146255243164"> <gUIDs>_4Z7WYKuKEdmhFZtkg1nakg</gUIDs> <gUIDs>_YiTAIL3vEdqLRJZPGVbHDA</gUIDs> <gUIDs>_--6tYKuKEdmhFZtkg1nakg</gUIDs> <gUIDs>_RBAyANbzEdqu5o2S60g5LA</gUIDs> <gUIDs>_A_LU8KuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_ObN0cNbzEdqu5o2S60g5LA</gUIDs> <gUIDs>_ENwJwKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_Gyf-cKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_JrHKUKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_KNZYAKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_OGYbwKuLEdmhFZtkg1nakg</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " variabilityType="contributes" variabilityBasedOnElement="_0fshwMlgEdmt3adZL5Dmdw" guidelines="_2uan8NbyEdqu5o2S60g5LA _CFAswNbzEdqu5o2S60g5LA _1fM3AC9_EduW5uTjiIcspQ _ienXEEyAEdu-df7p0PuRvQ">
+ <presentation xmi:id="-_BAmniONtHWbpHQH7znR3g" href="uma://-_BAmniONtHWbpHQH7znR3g#-_BAmniONtHWbpHQH7znR3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_2uan8NbyEdqu5o2S60g5LA" name="uc_realizations" guid="_2uan8NbyEdqu5o2S60g5LA" briefDescription="A use-case realization represents how a use case will be implemented in terms of collaborating objects. This guideline describes its purpose and UML notation." presentationName="Use-Cases Realizations" conceptsAndPapers="_uF-QYEAhEdq_UJTvM1DM2Q">
+ <presentation xmi:id="-CFYVionNDLkMw6SG6runQA" href="uma://-CFYVionNDLkMw6SG6runQA#-CFYVionNDLkMw6SG6runQA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_CFAswNbzEdqu5o2S60g5LA" name="design_components" guid="_CFAswNbzEdqu5o2S60g5LA" briefDescription="This guideline describes how to visually represent design components." presentationName="Design Components Representation">
+ <presentation xmi:id="-6ep_EyK3ZO6vRGWtAqoJ-A" href="uma://-6ep_EyK3ZO6vRGWtAqoJ-A#-6ep_EyK3ZO6vRGWtAqoJ-A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_sypCEPvjEdqf0-top1XJIg" name="developer_vm" guid="_sypCEPvjEdqf0-top1XJIg" variabilityType="contributes" variabilityBasedOnElement="_BCtiMDR9EduwLdLujGQAIQ">
+ <presentation xmi:id="-xbAirPdH1IOKcnklk8hdqw" href="uma://-xbAirPdH1IOKcnklk8hdqw#-xbAirPdH1IOKcnklk8hdqw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_1fM3AC9_EduW5uTjiIcspQ" name="designing_visually" guid="_1fM3AC9_EduW5uTjiIcspQ" briefDescription="This guideline provides information on how to apply visual modeling to designing a system." presentationName="Designing Visually">
+ <presentation xmi:id="-1xE2ZW3MjNAJ7jkaZNbkww" href="uma://-1xE2ZW3MjNAJ7jkaZNbkww#-1xE2ZW3MjNAJ7jkaZNbkww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_nnSXcD6SEduAL-bCqar_dg" name="design_vm" guid="_nnSXcD6SEduAL-bCqar_dg" variabilityType="contributes" variabilityBasedOnElement="_0XSzsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-HQSI39vBrjpmQL1qHYOJtA" href="uma://-HQSI39vBrjpmQL1qHYOJtA#-HQSI39vBrjpmQL1qHYOJtA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_ienXEEyAEdu-df7p0PuRvQ" name="data_modeling" guid="_ienXEEyAEdu-df7p0PuRvQ" briefDescription="A physical data model (PDM) captures the design of a persistent data store such as a relational database or data file. Data modeling is the act of creating such a model." presentationName="Physical Data Modeling">
+ <presentation xmi:id="-XMbxFU8M85cRlf3C4iwAGw" href="uma://-XMbxFU8M85cRlf3C4iwAGw#-XMbxFU8M85cRlf3C4iwAGw"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YoQcMlgEdmt3adZL5Dmdw" name="implementation" guid="_0YoQcMlgEdmt3adZL5Dmdw" briefDescription="Software code files, data files, and supporting files such as online help files that represent the raw parts of a system that can be built." presentationName="Implementation" guidelines="_0Y0dsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_6u9ZsKYcEdmvhNXG0Oc2uA" href="uma://_6u9ZsKYcEdmvhNXG0Oc2uA#_6u9ZsKYcEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YuXEMlgEdmt3adZL5Dmdw" name="build" guid="_0YuXEMlgEdmt3adZL5Dmdw" briefDescription="An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product." presentationName="Build" conceptsAndPapers="_B3xkEPD0EdqYgerqi84oCA" guidelines="_SM4YIL6dEdqti4GwqTkbsQ _i8bUEL6cEdqti4GwqTkbsQ">
+ <presentation xmi:id="_NqSB0KeqEdmKDbQuyzCoqQ" href="uma://_NqSB0KeqEdmKDbQuyzCoqQ#_NqSB0KeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YuXEclgEdmt3adZL5Dmdw" name="developer_test" guid="_0YuXEclgEdmt3adZL5Dmdw" briefDescription="The instructions that validate individual software components perform as specified." presentationName="Developer Test" conceptsAndPapers="_0Y6kUMlgEdmt3adZL5Dmdw" guidelines="_eRutgC5QEduVhuZHT5jKZQ">
+ <presentation xmi:id="_NqSB0qeqEdmKDbQuyzCoqQ" href="uma://_NqSB0qeqEdmKDbQuyzCoqQ#_NqSB0qeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0Y0dsMlgEdmt3adZL5Dmdw" name="implementation" guid="_0Y0dsMlgEdmt3adZL5Dmdw" briefDescription="This guideline describes the different types of elements in an implementation." presentationName="Implementation">
+ <presentation xmi:id="_4wqaMMPaEdmbOvqy4O0adg" href="uma://_4wqaMMPaEdmbOvqy4O0adg#_4wqaMMPaEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0Y6kUMlgEdmt3adZL5Dmdw" name="test_first_design" guid="_0Y6kUMlgEdmt3adZL5Dmdw" briefDescription="This concept explains how to bring test design chronologically in-line with software design." presentationName="Test-first Design">
+ <presentation xmi:id="_Hg5UUMPbEdmbOvqy4O0adg" href="uma://_Hg5UUMPbEdmbOvqy4O0adg#_Hg5UUMPbEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0hyzgMlgEdmt3adZL5Dmdw" name="implement_solution" guid="_0hyzgMlgEdmt3adZL5Dmdw" briefDescription="Implement source code to provide new functionality or fix defects." presentationName="Implement the Solution" conceptsAndPapers="_0Y6kUMlgEdmt3adZL5Dmdw _B3xkEPD0EdqYgerqi84oCA _Poc7IPDzEdqYgerqi84oCA" guidelines="_0Y0dsMlgEdmt3adZL5Dmdw _SM4YIL6dEdqti4GwqTkbsQ" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_0WuL8slgEdmt3adZL5Dmdw" output="_0YoQcMlgEdmt3adZL5Dmdw _0YuXEMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _0VGbUMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0YoQcMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _0VGbUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_d2aMwKrMEdmqUqi7YGiSxw" href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_d2aMwKrMEdmqUqi7YGiSxw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0iL1EMlgEdmt3adZL5Dmdw" name="impl_developer_tests" guid="_0iL1EMlgEdmt3adZL5Dmdw" briefDescription="Implement one or more tests that enable the validation of the individual software components through execution." presentationName="Implement Developer Tests" conceptsAndPapers="_0Y6kUMlgEdmt3adZL5Dmdw _aFeZgJquEdukqcRKZBQN9w" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_0YoQcMlgEdmt3adZL5Dmdw" output="_0YuXEclgEdmt3adZL5Dmdw" additionallyPerformedBy="_0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0WuL8slgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_dWPe8KrMEdmqUqi7YGiSxw" href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_dWPe8KrMEdmqUqi7YGiSxw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0iYCUMlgEdmt3adZL5Dmdw" name="run_developer_tests" guid="_0iYCUMlgEdmt3adZL5Dmdw" briefDescription="Run tests of the individual software components to verify that their internal structures work as specified." presentationName="Run Developer Tests" conceptsAndPapers="_aFeZgJquEdukqcRKZBQN9w" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw" output="_0ZlSsMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_W6rc0Lv7EdmmUvZAZjqE3g" href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_W6rc0Lv7EdmmUvZAZjqE3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0WuL8slgEdmt3adZL5Dmdw" name="design" guid="_0WuL8slgEdmt3adZL5Dmdw" briefDescription="This artifact describes the realization of required system functionality in terms of components and serves as an abstraction of the source code." presentationName="Design" checklists="_0XSzsMlgEdmt3adZL5Dmdw" guidelines="_0X3bcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" href="uma://_zxB-QKYcEdmvhNXG0Oc2uA#_zxB-QKYcEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0fshwMlgEdmt3adZL5Dmdw" name="design_solution" guid="_0fshwMlgEdmt3adZL5Dmdw" briefDescription="Identify the elements and devise the interactions, behavior, relations, and data necessary to realize some functionality." presentationName="Design the Solution" conceptsAndPapers="_uF-QYEAhEdq_UJTvM1DM2Q _mzxI0A4LEduibvKwrGxWxA" guidelines="_0X3bcMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_BVh9cL-CEdqb7N6KIeDL8Q _0XAf0MlgEdmt3adZL5Dmdw _0VGbUMlgEdmt3adZL5Dmdw" output="_0WuL8slgEdmt3adZL5Dmdw" additionallyPerformedBy="_0X9iEMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0WuL8slgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NrC20qeqEdmKDbQuyzCoqQ" href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_NrC20qeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0XSzsMlgEdmt3adZL5Dmdw" name="design" guid="_0XSzsMlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that the design is created in a consistent and complete manner." presentationName="Design">
+ <presentation xmi:id="_YIYIYMM1EdmSIPI87WLu3g" href="uma://_YIYIYMM1EdmSIPI87WLu3g#_YIYIYMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0X3bcMlgEdmt3adZL5Dmdw" name="design" guid="_0X3bcMlgEdmt3adZL5Dmdw" briefDescription="This guideline gives additional information on how to design a portion of the system." presentationName="Design">
+ <presentation xmi:id="_Qo7pYMM3EdmSIPI87WLu3g" href="uma://_Qo7pYMM3EdmSIPI87WLu3g#_Qo7pYMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_i8bUEL6cEdqti4GwqTkbsQ" name="continuous_integration" guid="_i8bUEL6cEdqti4GwqTkbsQ" briefDescription="This guideline describes how to apply continuous integration to improve the integration of units into the code base." presentationName="Continuous Integration" conceptsAndPapers="_B3xkEPD0EdqYgerqi84oCA">
+ <presentation xmi:id="-DlaqJu4sEqMPk84qhJ6IEA" href="uma://-DlaqJu4sEqMPk84qhJ6IEA#-DlaqJu4sEqMPk84qhJ6IEA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_SM4YIL6dEdqti4GwqTkbsQ" name="promoting_builds" guid="_SM4YIL6dEdqti4GwqTkbsQ" briefDescription="This guideline describes how to migrate a build up through a set of tiers from a private development area to a release area." presentationName="Promoting Builds" conceptsAndPapers="_0cEmAMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ" href="uma://-zCM2ucJJxc_bQr_LoHlSaQ#-zCM2ucJJxc_bQr_LoHlSaQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_uF-QYEAhEdq_UJTvM1DM2Q" name="entity_control_boundary_pattern" guid="_uF-QYEAhEdq_UJTvM1DM2Q" briefDescription="This concept introduces a pattern that provides a starting point for the distribution of responsibilities to a set of interacting design elements based on three key perspectives in a collaboration." presentationName="Entity-Control-Boundary Pattern">
+ <presentation xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" href="uma://-awaQ_2dwhGyKRoVKQ-esPQ#-awaQ_2dwhGyKRoVKQ-esPQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Poc7IPDzEdqYgerqi84oCA" name="refactoring" guid="_Poc7IPDzEdqYgerqi84oCA" briefDescription="This concept explains ways of improving the design of existing code in a way that does not alter its external behavior." presentationName="Refactoring">
+ <presentation xmi:id="-fj_9xjbrpaYNSETyCz5yJg" href="uma://-fj_9xjbrpaYNSETyCz5yJg#-fj_9xjbrpaYNSETyCz5yJg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_B3xkEPD0EdqYgerqi84oCA" name="continuous_integration" guid="_B3xkEPD0EdqYgerqi84oCA" briefDescription="This concept introduces the idea of creating regular (at least daily) integrations in order to reduce integration risks, find bugs earlier, and drive a collaborative work environment." presentationName="Continuous Integration" variabilityType="replaces">
+ <presentation xmi:id="-dhAMzNZNWufBnW0fPYQtBA" href="uma://-dhAMzNZNWufBnW0fPYQtBA#-dhAMzNZNWufBnW0fPYQtBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_eRutgC5QEduVhuZHT5jKZQ" name="types_of_developer_tests" guid="_eRutgC5QEduVhuZHT5jKZQ" briefDescription="This guideline describes various types of developer tests." presentationName="Types of Developer Tests">
+ <presentation xmi:id="-VGT8iHGtQSiOUGitq1qmow" href="uma://-VGT8iHGtQSiOUGitq1qmow#-VGT8iHGtQSiOUGitq1qmow"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_BCtiMDR9EduwLdLujGQAIQ" name="developer_sln" guid="_BCtiMDR9EduwLdLujGQAIQ" variabilityType="contributes" variabilityBasedOnElement="_0YDosMlgEdmt3adZL5Dmdw" responsibleFor="_0YuXEMlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw _0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_aFeZgJquEdukqcRKZBQN9w" name="developer_testing" guid="_aFeZgJquEdukqcRKZBQN9w" briefDescription="Developers regression test their code on a continuous basis to ensure that it works as expected." presentationName="Developer Testing">
+ <presentation xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q" href="uma://-Ff1JwbrGt1laexkOB6ZM1Q#-Ff1JwbrGt1laexkOB6ZM1Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_JiqnEJt1EdutoZjlV3a4Lg" name="code_instrumentation" guid="_JiqnEJt1EdutoZjlV3a4Lg" presentationName="Code Instrumentation">
+ <presentation xmi:id="-RlYzPnl6Pig2H851hHebBA" href="uma://-RlYzPnl6Pig2H851hHebBA#-RlYzPnl6Pig2H851hHebBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0lnRMMqOEduwrYVlQ9zp3w" name="coding_standard" guid="_0lnRMMqOEduwrYVlQ9zp3w" briefDescription="A standard describing various coding conventions used for consistent, quality, understandable implementation." presentationName="Coding Standard">
+ <presentation xmi:id="-vlYpfwIYlF_ZCk5s4Dsqdg" href="uma://-vlYpfwIYlF_ZCk5s4Dsqdg#-vlYpfwIYlF_ZCk5s4Dsqdg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0ZM4MMlgEdmt3adZL5Dmdw" name="test" guid="_0ZM4MMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0ZfMEMlgEdmt3adZL5Dmdw" name="test_script" guid="_0ZfMEMlgEdmt3adZL5Dmdw" briefDescription="This artifact contains the step-by-step instructions that realize a test, enabling its execution. These may take the form of either documented textual instructions that are executed manually or computer readable instructions that enable automated test execution." presentationName="Test Script" checklists="_0Z9tMMlgEdmt3adZL5Dmdw" guidelines="_0aDz0MlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NqYIcqeqEdmKDbQuyzCoqQ" href="uma://_NqYIcqeqEdmKDbQuyzCoqQ#_NqYIcqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0Z9tMMlgEdmt3adZL5Dmdw" name="test_script" guid="_0Z9tMMlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that tests are created in a consistent and complete manner." presentationName="Test Script">
+ <presentation xmi:id="_4LuPMMPcEdmbOvqy4O0adg" href="uma://_4LuPMMPcEdmbOvqy4O0adg#_4LuPMMPcEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0aDz0MlgEdmt3adZL5Dmdw" name="test_suite" guid="_0aDz0MlgEdmt3adZL5Dmdw" briefDescription="This guideline discusses how to maintain automated test suites." presentationName="Test Suite">
+ <presentation xmi:id="_s60KoMM3EdmSIPI87WLu3g" href="uma://_s60KoMM3EdmSIPI87WLu3g#_s60KoMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0jO98MlgEdmt3adZL5Dmdw" name="implement_tests" guid="_0jO98MlgEdmt3adZL5Dmdw" briefDescription="Implement one or more test artifacts to enable the validation of the software product through actually running the system. Combine tests to facilitate appropriate breadth and depth of test coverage." presentationName="Implement Tests" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw _0jzlsMlgEdmt3adZL5Dmdw" performedBy="_0ZM4MclgEdmt3adZL5Dmdw" mandatoryInput="_0ZS-0MlgEdmt3adZL5Dmdw" output="_0ZfMEMlgEdmt3adZL5Dmdw" optionalInput="_0ZfMEMlgEdmt3adZL5Dmdw _0YuXEMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NrbRUKeqEdmKDbQuyzCoqQ" href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_NrbRUKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0jVEkMlgEdmt3adZL5Dmdw" name="run_tests" guid="_0jVEkMlgEdmt3adZL5Dmdw" briefDescription="Run the appropriate collections of tests required to evaluate product quality. Capture test results that facilitate ongoing assessment of the product." presentationName="Run Tests" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw" performedBy="_0ZM4MclgEdmt3adZL5Dmdw" mandatoryInput="_0YuXEMlgEdmt3adZL5Dmdw _0ZfMEMlgEdmt3adZL5Dmdw" output="_0ZlSsMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_NrbRUqeqEdmKDbQuyzCoqQ" href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_NrbRUqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0jhR0MlgEdmt3adZL5Dmdw" name="failure_analysis_rpt_creation" guid="_0jhR0MlgEdmt3adZL5Dmdw" briefDescription="This concept addresses how to conduct failure analysis based on the execution of tests. The result of this analysis can take the form of a failure analysis report." presentationName="Failure Analysis and Report Creation">
+ <presentation xmi:id="-9gUpkUYqONF3x8UWwAO_zw" href="uma://-9gUpkUYqONF3x8UWwAO_zw#-9gUpkUYqONF3x8UWwAO_zw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0kF5kMlgEdmt3adZL5Dmdw" name="maintaining_automated_test_suite" guid="_0kF5kMlgEdmt3adZL5Dmdw" briefDescription="This guideline explains ways to maintain automated test suites - collection of tests performed together for breadth and depth coverage." presentationName="Maintaining Automated Test Suite">
+ <presentation xmi:id="_8ngBgMPdEdmbOvqy4O0adg" href="uma://_8ngBgMPdEdmbOvqy4O0adg#_8ngBgMPdEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0j5sUMlgEdmt3adZL5Dmdw" name="programming_automated_tests" guid="_0j5sUMlgEdmt3adZL5Dmdw" briefDescription="This guideline discusses ways of structuring, recording, entering data, executing and handling errors in automated tests." presentationName="Programming Automated Tests">
+ <presentation xmi:id="_vuwC4MPcEdmbOvqy4O0adg" href="uma://_vuwC4MPcEdmbOvqy4O0adg#_vuwC4MPcEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0jzlsMlgEdmt3adZL5Dmdw" name="test_ideas" guid="_0jzlsMlgEdmt3adZL5Dmdw" briefDescription="This guideline identifies common faults and mistakes done when developing software. It shows how to create test ideas from method calls, and from boolean and relational expressions." presentationName="Test Ideas">
+ <presentation xmi:id="_y3rxsMM3EdmSIPI87WLu3g" href="uma://_y3rxsMM3EdmSIPI87WLu3g#_y3rxsMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_yDyI8DR1EdutE_HNDTJk5Q" name="tester_tst" guid="_yDyI8DR1EdutE_HNDTJk5Q" variabilityType="contributes" variabilityBasedOnElement="_0ZM4MclgEdmt3adZL5Dmdw" responsibleFor="_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_wI3R4EvCEdunZcj9T5hrMQ" name="architect" guid="_wI3R4EvCEdunZcj9T5hrMQ" presentationName="architect">
+ <presentation xmi:id="-2QB1bosN011CudkwZ0cn-g" href="uma://-2QB1bosN011CudkwZ0cn-g#-2QB1bosN011CudkwZ0cn-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_VHFGkEvCEdunZcj9T5hrMQ" name="architectural_mechanism" guid="_VHFGkEvCEdunZcj9T5hrMQ" presentationName="architectural mechanisms">
+ <presentation xmi:id="-Vvwb6EupIB9kfSQ_mhjURA" href="uma://-Vvwb6EupIB9kfSQ_mhjURA#-Vvwb6EupIB9kfSQ_mhjURA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_n7GmQEvCEdunZcj9T5hrMQ" name="architectural_view" guid="_n7GmQEvCEdunZcj9T5hrMQ" presentationName="architectural view">
+ <presentation xmi:id="-0vih7gB84YYDheaH7jeYFQ" href="uma://-0vih7gB84YYDheaH7jeYFQ#-0vih7gB84YYDheaH7jeYFQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_siyjEEvCEdunZcj9T5hrMQ" name="architecture" guid="_siyjEEvCEdunZcj9T5hrMQ" presentationName="architecture">
+ <presentation xmi:id="-YMvJ5LwexkcVWWqLdm5-nQ" href="uma://-YMvJ5LwexkcVWWqLdm5-nQ#-YMvJ5LwexkcVWWqLdm5-nQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Z-AukEvpEdunZcj9T5hrMQ" name="build" guid="_Z-AukEvpEdunZcj9T5hrMQ" presentationName="build">
+ <presentation xmi:id="-Wh-byAGHoy_gGry0Jq6VaA" href="uma://-Wh-byAGHoy_gGry0Jq6VaA#-Wh-byAGHoy_gGry0Jq6VaA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_d82_AEvDEdunZcj9T5hrMQ" name="component" guid="_d82_AEvDEdunZcj9T5hrMQ" presentationName="component">
+ <presentation xmi:id="-BWZsh3vKrqSOzfkBJmDTLA" href="uma://-BWZsh3vKrqSOzfkBJmDTLA#-BWZsh3vKrqSOzfkBJmDTLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_-61a8EvOEdunZcj9T5hrMQ" name="developer" guid="_-61a8EvOEdunZcj9T5hrMQ" presentationName="developer">
+ <presentation xmi:id="-802sCZ4lJcejyRbhLmkxkw" href="uma://-802sCZ4lJcejyRbhLmkxkw#-802sCZ4lJcejyRbhLmkxkw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ctrEgEvCEdunZcj9T5hrMQ" name="pattern" guid="_ctrEgEvCEdunZcj9T5hrMQ" presentationName="pattern">
+ <presentation xmi:id="-VJBtRm2brEKpRlnLWNF8_g" href="uma://-VJBtRm2brEKpRlnLWNF8_g#-VJBtRm2brEKpRlnLWNF8_g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_U4RYEEvOEdunZcj9T5hrMQ" name="test_case" guid="_U4RYEEvOEdunZcj9T5hrMQ" presentationName="test case">
+ <presentation xmi:id="-6oW2YOnoWq_xPpmoil91KA" href="uma://-6oW2YOnoWq_xPpmoil91KA#-6oW2YOnoWq_xPpmoil91KA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_WB6rQEvPEdunZcj9T5hrMQ" name="tester" guid="_WB6rQEvPEdunZcj9T5hrMQ" presentationName="tester">
+ <presentation xmi:id="-prQBbamJ4CLPywfEbyaPaA" href="uma://-prQBbamJ4CLPywfEbyaPaA#-prQBbamJ4CLPywfEbyaPaA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_5la48DR2EdutE_HNDTJk5Q" name="management" guid="_5la48DR2EdutE_HNDTJk5Q" briefDescription="Management sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0aQBEMlgEdmt3adZL5Dmdw" name="project_management" guid="_0aQBEMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0a6vcMlgEdmt3adZL5Dmdw" name="project_plan" guid="_0a6vcMlgEdmt3adZL5Dmdw" briefDescription="This artifact gathers all information required to manage the project. Its main part consists of a coarse-grained plan, containing project phases and milestones." presentationName="Project Plan" examples="_Nzv5kDoAEdusGsHODb-STA" reports="_ePrt8Dj3EduxovfWMDsntw" templates="_0c7hoMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_IbVp8KX4EdmvhNXG0Oc2uA" href="uma://_IbVp8KX4EdmvhNXG0Oc2uA#_IbVp8KX4EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0bA2EMlgEdmt3adZL5Dmdw" name="status_assessment" guid="_0bA2EMlgEdmt3adZL5Dmdw" briefDescription="Capture and communicate results and actions from assessments. This is typically done at the end of each iteration." presentationName="Status Assessment" templates="_1awLIEp2Edup0IY9DKDPkg">
+ <presentation xmi:id="_K-e8IKX4EdmvhNXG0Oc2uA" href="uma://_K-e8IKX4EdmvhNXG0Oc2uA#_K-e8IKX4EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0lC70MlgEdmt3adZL5Dmdw" name="plan_the_project" guid="_0lC70MlgEdmt3adZL5Dmdw" briefDescription="Define a coarse-grained plan for the project." presentationName="Plan Project" conceptsAndPapers="_HNxbwMBJEdqSgKaj2SZBmg _VNxL4ACsEdu8m4dIntu6jA _lam4ADkBEduxovfWMDsntw" guidelines="_CGHskBEdEdqY7JB6N6CW2w _Jq64EJjsEduad8I_c-ogIA _rmBEkJjsEduad8I_c-ogIA" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0WVxcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" output="_0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA" additionallyPerformedBy="_0X9iEMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0YDosMlgEdmt3adZL5Dmdw" optionalInput="_0a6vcMlgEdmt3adZL5Dmdw _Ckay8Cc_EduIsqH1Q6ZuqA _0bA2EMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_fPbdIKe2Edmzde8VFK5bxg" href="uma://_fPbdIKe2Edmzde8VFK5bxg#_fPbdIKe2Edmzde8VFK5bxg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0l53cMlgEdmt3adZL5Dmdw" name="assess_results" guid="_0l53cMlgEdmt3adZL5Dmdw" briefDescription="Determine success or failure of the iteration. Apply the lessons learned to modify the project or improve the process." presentationName="Assess Results" conceptsAndPapers="_HNxbwMBJEdqSgKaj2SZBmg" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" output="_0bA2EMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _0a6vcMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0dsWoMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0X9iEMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0bA2EMlgEdmt3adZL5Dmdw _0WVxcMlgEdmt3adZL5Dmdw _0ZlSsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_a3uz4LBYEdm7Eph_l9Cn9w" href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_a3uz4LBYEdm7Eph_l9Cn9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0mYYkMlgEdmt3adZL5Dmdw" name="metrics" guid="_0mYYkMlgEdmt3adZL5Dmdw" briefDescription="A metric is the interpretation of a measurable attribute(s) of an entity." presentationName="Metrics">
+ <presentation xmi:id="_7ygXoMM3EdmSIPI87WLu3g" href="uma://_7ygXoMM3EdmSIPI87WLu3g#_7ygXoMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_CGHskBEdEdqY7JB6N6CW2w" name="agile_estimation" guid="_CGHskBEdEdqY7JB6N6CW2w" briefDescription="This guideline explains three key concepts, and their interrelationships, for doing agile estimation; estimation of size, velocity, and estimation of effort." presentationName="Agile Estimation">
+ <presentation xmi:id="_CYRMgBEdEdqY7JB6N6CW2w" href="uma://_CYRMgBEdEdqY7JB6N6CW2w#_CYRMgBEdEdqY7JB6N6CW2w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_8S2aICbYEdqh1LYUOGRh2A" name="manage_iteration" guid="_8S2aICbYEdqh1LYUOGRh2A" briefDescription="Assess project status and identify any blocking issues and/or opportunities. Identify and manage exceptions, problems and risks. Communicate project status." presentationName="Manage Iteration" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw _VNxL4ACsEdu8m4dIntu6jA _0mYYkMlgEdmt3adZL5Dmdw" guidelines="__yQQ4L6REdqti4GwqTkbsQ _rmBEkJjsEduad8I_c-ogIA" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA" output="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _0X9iEMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0dsWoMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ">
+ <presentation xmi:id="-PbfqVxB_j9KN-Jx39_pEUA" href="uma://-PbfqVxB_j9KN-Jx39_pEUA#-PbfqVxB_j9KN-Jx39_pEUA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0keUEMlgEdmt3adZL5Dmdw" name="plan_iteration" guid="_0keUEMlgEdmt3adZL5Dmdw" briefDescription="Plan the scope and responsibilities for a single iteration." presentationName="Plan Iteration" conceptsAndPapers="_lam4ADkBEduxovfWMDsntw" guidelines="_0auiMMlgEdmt3adZL5Dmdw _CGHskBEdEdqY7JB6N6CW2w __yQQ4L6REdqti4GwqTkbsQ _7vEXEMA4EdqSgKaj2SZBmg _rmBEkJjsEduad8I_c-ogIA" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" output="_0aQBEslgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" additionallyPerformedBy="_0X9iEMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ" optionalInput="_0XAf0MlgEdmt3adZL5Dmdw _0WVxcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_Wk7noKe1EdmGSrcKGOYDGg" href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_Wk7noKe1EdmGSrcKGOYDGg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0auiMMlgEdmt3adZL5Dmdw" name="iteration_planning" guid="_0auiMMlgEdmt3adZL5Dmdw" briefDescription="The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the iteration and produce a sufficiently detailed plan outlining who needs to do what." presentationName="Iteration Planning">
+ <presentation xmi:id="_71hDkMPgEdmbOvqy4O0adg" href="uma://_71hDkMPgEdmbOvqy4O0adg#_71hDkMPgEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_HNxbwMBJEdqSgKaj2SZBmg" name="milestones" guid="_HNxbwMBJEdqSgKaj2SZBmg" briefDescription="The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready to move to the next iteration or phase." presentationName="Milestones">
+ <presentation xmi:id="-DG8mYMnTGosWIxjPQFUoTA" href="uma://-DG8mYMnTGosWIxjPQFUoTA#-DG8mYMnTGosWIxjPQFUoTA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="__yQQ4L6REdqti4GwqTkbsQ" name="assign_changes_to_iteration" guid="__yQQ4L6REdqti4GwqTkbsQ" briefDescription="This guideline promotes the best practice of isolating team members from disruptive changes during the current iteration. Change requests are reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration." presentationName="Assign Changes to an Iteration">
+ <presentation xmi:id="-bUmvEAAtFf6B0aUCux8k9Q" href="uma://-bUmvEAAtFf6B0aUCux8k9Q#-bUmvEAAtFf6B0aUCux8k9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VNxL4ACsEdu8m4dIntu6jA" name="risk_management" guid="_VNxL4ACsEdu8m4dIntu6jA" briefDescription="This is a fundamental practice that project managers should consider in their projects. Identifying and minimizing risks early in the project lifecycle is key factor for project success." presentationName="Risk Management" conceptsAndPapers="_GXiogMvoEdqukPpotm3DYg">
+ <presentation xmi:id="-HhGIkAPjHSIxnPzI3cyDnQ" href="uma://-HhGIkAPjHSIxnPzI3cyDnQ#-HhGIkAPjHSIxnPzI3cyDnQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Ckay8Cc_EduIsqH1Q6ZuqA" name="risk_list" guid="_Ckay8Cc_EduIsqH1Q6ZuqA" briefDescription="This artifact is a sorted list of known and open risks to the project, sorted in order of importance and associated with specific mitigation or contingency actions." presentationName="Risk List" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw _VNxL4ACsEdu8m4dIntu6jA" checklists="_7BZa0DIdEduDTv4Y1akVTA" templates="_MIUO0C8FEduzydamRseoUw">
+ <presentation xmi:id="-4VJ_0upihz-bR7VRlm63Vw" href="uma://-4VJ_0upihz-bR7VRlm63Vw#-4VJ_0upihz-bR7VRlm63Vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_7BZa0DIdEduDTv4Y1akVTA" name="risk_list" guid="_7BZa0DIdEduDTv4Y1akVTA" briefDescription="This checklist provides guidance on assessing that all possible risks have been considered in a project." presentationName="Risk List">
+ <presentation xmi:id="-gqNN4DnROmJpgKtrdguhpg" href="uma://-gqNN4DnROmJpgKtrdguhpg#-gqNN4DnROmJpgKtrdguhpg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_dkAtkDR_EdursMWmT1aZyw" name="project_manager_pm" guid="_dkAtkDR_EdursMWmT1aZyw" variabilityType="contributes" variabilityBasedOnElement="_0a0o0MlgEdmt3adZL5Dmdw" responsibleFor="_0a6vcMlgEdmt3adZL5Dmdw _Ckay8Cc_EduIsqH1Q6ZuqA _0bA2EMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_nHomIDgzEdu4E8ZdmlYjtA" name="work_items_list" guid="_nHomIDgzEdu4E8ZdmlYjtA" briefDescription="This is an example of a partial Work Items List for a small team who just started to work on iteration 3." presentationName="Work Items List">
+ <presentation xmi:id="-qunTPN3vqTIGpELwajXpLA" href="uma://-qunTPN3vqTIGpELwajXpLA#-qunTPN3vqTIGpELwajXpLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_uAzgkDg3Edu4E8ZdmlYjtA" name="iteration_burndown" guid="_uAzgkDg3Edu4E8ZdmlYjtA" briefDescription="The iteration burndown shows the trend for how much work is left to do within that iteration." presentationName="Iteration Burndown">
+ <presentation xmi:id="-Aw8p59vJ9rWsOV82rljQiQ" href="uma://-Aw8p59vJ9rWsOV82rljQiQ#-Aw8p59vJ9rWsOV82rljQiQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_ePrt8Dj3EduxovfWMDsntw" name="project_burndown" guid="_ePrt8Dj3EduxovfWMDsntw" briefDescription="An effective way of communicating project progress." presentationName="Project Burndown">
+ <presentation xmi:id="-hrDndmFd0zexB0HNYX3gww" href="uma://-hrDndmFd0zexB0HNYX3gww#-hrDndmFd0zexB0HNYX3gww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_sNoQ0Dn6Edu_y4hBImiwwQ" name="work_items_list_pm" guid="_sNoQ0Dn6Edu_y4hBImiwwQ" variabilityType="contributes" variabilityBasedOnElement="_rGNWsCbSEdqh1LYUOGRh2A" guidelines="_CGHskBEdEdqY7JB6N6CW2w" examples="_nHomIDgzEdu4E8ZdmlYjtA" reports="_ePrt8Dj3EduxovfWMDsntw _uAzgkDg3Edu4E8ZdmlYjtA">
+ <presentation xmi:id="-fDVhZTkf1TqDyExbI9DM-w" href="uma://-fDVhZTkf1TqDyExbI9DM-w#-fDVhZTkf1TqDyExbI9DM-w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_xWdL0Dn6Edu_y4hBImiwwQ" name="iteration_plan_pm" guid="_xWdL0Dn6Edu_y4hBImiwwQ" variabilityType="contributes" variabilityBasedOnElement="_0aQBEslgEdmt3adZL5Dmdw" guidelines="_0auiMMlgEdmt3adZL5Dmdw" examples="_TuNhIEE4EdulKujnGUuxbg" reports="_uAzgkDg3Edu4E8ZdmlYjtA">
+ <presentation xmi:id="-b9hejTMj8E7U4g2v80xDjA" href="uma://-b9hejTMj8E7U4g2v80xDjA#-b9hejTMj8E7U4g2v80xDjA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_Nzv5kDoAEdusGsHODb-STA" name="project_plan" guid="_Nzv5kDoAEdusGsHODb-STA" briefDescription="This is an example of a project plan." presentationName="Project Plan">
+ <presentation xmi:id="-IdlCQXdDNYGrGJU4TBwvCA" href="uma://-IdlCQXdDNYGrGJU4TBwvCA#-IdlCQXdDNYGrGJU4TBwvCA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_TuNhIEE4EdulKujnGUuxbg" name="iteration_plan" guid="_TuNhIEE4EdulKujnGUuxbg" briefDescription="This is an example of an iteration plan for iteration 5 for a small team. In this example, the team has chosen not to list work items in the iteration plan. Instead, the team will search the work items list for work items assigned to iteration 5. This is the preferred solution when work items are managed in a tool that provides basic search capabilities." presentationName="Iteration Plan">
+ <presentation xmi:id="-nDr0XNiUWBo6VS1YS6KAqA" href="uma://-nDr0XNiUWBo6VS1YS6KAqA#-nDr0XNiUWBo6VS1YS6KAqA"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_nJSDwEvuEdunZcj9T5hrMQ" name="effort" guid="_nJSDwEvuEdunZcj9T5hrMQ" presentationName="effort">
+ <presentation xmi:id="-WIgtkwJN71D51FdcQs-TzQ" href="uma://-WIgtkwJN71D51FdcQs-TzQ#-WIgtkwJN71D51FdcQs-TzQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_8b20EEvvEdunZcj9T5hrMQ" name="iteration_burndown" guid="_8b20EEvvEdunZcj9T5hrMQ" presentationName="iteration burndown">
+ <presentation xmi:id="-3G3HV0opAmFWGxYgsD5AhA" href="uma://-3G3HV0opAmFWGxYgsD5AhA#-3G3HV0opAmFWGxYgsD5AhA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_MvOuAEvGEdunZcj9T5hrMQ" name="point" guid="_MvOuAEvGEdunZcj9T5hrMQ" presentationName="point">
+ <presentation xmi:id="-oShmMITo9RIi1AzACWI9vw" href="uma://-oShmMITo9RIi1AzACWI9vw#-oShmMITo9RIi1AzACWI9vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_eX0YsEvvEdunZcj9T5hrMQ" name="project_burndown" guid="_eX0YsEvvEdunZcj9T5hrMQ" presentationName="project burndown">
+ <presentation xmi:id="-NNByAM5YsjCu39flaOSZtQ" href="uma://-NNByAM5YsjCu39flaOSZtQ#-NNByAM5YsjCu39flaOSZtQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ii2LUEvGEdunZcj9T5hrMQ" name="risk" guid="_ii2LUEvGEdunZcj9T5hrMQ" presentationName="risk">
+ <presentation xmi:id="-hOtatvr8wIjqW8UD0MSGhQ" href="uma://-hOtatvr8wIjqW8UD0MSGhQ#-hOtatvr8wIjqW8UD0MSGhQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_t7JOkEvtEdunZcj9T5hrMQ" name="scope" guid="_t7JOkEvtEdunZcj9T5hrMQ" presentationName="scope">
+ <presentation xmi:id="-h1poMaxtQbmg6hD5772oVw" href="uma://-h1poMaxtQbmg6hD5772oVw#-h1poMaxtQbmg6hD5772oVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Nj2hsEvuEdunZcj9T5hrMQ" name="velocity" guid="_Nj2hsEvuEdunZcj9T5hrMQ" presentationName="velocity">
+ <presentation xmi:id="-mgWkuUy3q0zzFaxE7DY1ag" href="uma://-mgWkuUy3q0zzFaxE7DY1ag#-mgWkuUy3q0zzFaxE7DY1ag"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_RK9nwEvtEdunZcj9T5hrMQ" name="work_breakdown_structure" guid="_RK9nwEvtEdunZcj9T5hrMQ" presentationName="work breakdown structure" guidelines="_rmBEkJjsEduad8I_c-ogIA">
+ <presentation xmi:id="-KQTbqDSJXR8KLBxIgGVquA" href="uma://-KQTbqDSJXR8KLBxIgGVquA#-KQTbqDSJXR8KLBxIgGVquA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_jyVgcEvKEdunZcj9T5hrMQ" name="work_item" guid="_jyVgcEvKEdunZcj9T5hrMQ" presentationName="work item" guidelines="_rmBEkJjsEduad8I_c-ogIA">
+ <presentation xmi:id="-1Oc9t_TLaBgW_YLugZcq7w" href="uma://-1Oc9t_TLaBgW_YLugZcq7w#-1Oc9t_TLaBgW_YLugZcq7w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_Jq64EJjsEduad8I_c-ogIA" name="staffing_project" guid="_Jq64EJjsEduad8I_c-ogIA" briefDescription="Advice for how to staff a software development project." presentationName="Staffing a Project">
+ <presentation xmi:id="-HYO1lwAFOxlT7ncq8EjSng" href="uma://-HYO1lwAFOxlT7ncq8EjSng#-HYO1lwAFOxlT7ncq8EjSng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_rmBEkJjsEduad8I_c-ogIA" name="self_organize_work_assignments" guid="_rmBEkJjsEduad8I_c-ogIA" briefDescription="Agile software development teams organize the work that needs to be done together as a team." presentationName="Self Organize Work Assignments">
+ <presentation xmi:id="-e26WOHRbTVQrDssK5zijVA" href="uma://-e26WOHRbTVQrDssK5zijVA#-e26WOHRbTVQrDssK5zijVA"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0nJNkMlgEdmt3adZL5Dmdw" name="CapabilityPatterns" guid="_0nJNkMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_bxcS4B_REdq3EKSIdbj-MA" name="Phase Iteration Templates" guid="_bxcS4B_REdq3EKSIdbj-MA">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0rWYIMlgEdmt3adZL5Dmdw" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIMlgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0oSdEclgEdmt3adZL5Dmdw" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdEclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0qrpwMlgEdmt3adZL5Dmdw" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwMlgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_y-etQOtQEdqc1LGhiSPqRg" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-etQOtQEdqc1LGhiSPqRg"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mpl9kDbmEduMn613sF6-Uw" name="Sub-processes" guid="_mpl9kDbmEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_JEyxADboEduMn613sF6-Uw" name="Management" guid="_JEyxADboEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0pWNAslgEdmt3adZL5Dmdw" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNAslgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0nJNkclgEdmt3adZL5Dmdw" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkclgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_TFSlkDboEduMn613sF6-Uw" name="Intent" guid="_TFSlkDboEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0pJ_xclgEdmt3adZL5Dmdw" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0o9ygMlgEdmt3adZL5Dmdw" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygMlgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_XzhPQDboEduMn613sF6-Uw" name="Solution" guid="_XzhPQDboEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0sx7iclgEdmt3adZL5Dmdw" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7iclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0sluQclgEdmt3adZL5Dmdw" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_h2-iAPimEdmugcVr9AdHjQ" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAPimEdmugcVr9AdHjQ"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0nz79MlgEdmt3adZL5Dmdw" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79MlgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ </childPackages>
+ </childPackages>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0uHYQMlgEdmt3adZL5Dmdw" name="DeliveryProcesses" guid="_0uHYQMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0uHYQclgEdmt3adZL5Dmdw" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uHYQclgEdmt3adZL5Dmdw"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0u-T4MlgEdmt3adZL5Dmdw" name="ProcessContributions" guid="_0u-T4MlgEdmt3adZL5Dmdw"/>
+ <bases href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCUhAO8KEdmKSqa_gSYthg"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/resources/banner.gif b/OpenUP/OpenUP_PT/library/openup_basic/resources/banner.gif
new file mode 100644
index 0000000..83300e8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/resources/banner.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/analyst.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/analyst.xmi
new file mode 100644
index 0000000..7ae122e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/analyst.xmi
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_Nx8icKYdEdmvhNXG0Oc2uA" name="analyst,_0VxJsMlgEdmt3adZL5Dmdw" guid="_Nx8icKYdEdmvhNXG0Oc2uA" changeDate="2007-01-05T09:44:25.904-0500" version="1.0.0">
+ <skills><p>
+ An analyst needs the following knowledge, skills, and abilities:
+</p>
+<ul>
+ <li>
+ Expertise in identifying and understanding problems and opportunities
+ </li>
+ <li>
+ Ability&nbsp;to articulate the needs that are associated with the key problem to be solved or opportunity to be
+ realized
+ </li>
+ <li>
+ Ability to collaborate effectively with the extended team through collaborative working sessions, workshops, JAD
+ sessions and other techniques.
+ </li>
+ <li>
+ Good communication skills, verbally and in writing
+ </li>
+ <li>
+ Knowledge of the business and technology domains or the ability to quickly absorb and understand such information
+ </li>
+</ul>
+<br /></skills>
+ <assignmentApproaches><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ On small, agile teams this role is often shared among several team members that also perform other roles.&nbsp; See
+ <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self Organize Work Assignments</a>&nbsp;and <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/staffing_project,_Jq64EJjsEduad8I_c-ogIA.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;for more information on this approach.
+ </li>
+ <li>
+ One (or more)&nbsp;team member(s) performs this role exclusively. This commonly adopted approach is suitable for
+ complex requirements that are difficult to gather.
+ </li>
+ <li>
+ One staff (or more) team member(s) performs both this role and the <a class="elementLink"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>
+ role. This is a good option for smaller or resource<font color="#ff0000">-</font>constrained test teams.
+ </li>
+</ul></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/any_role.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/any_role.xmi
new file mode 100644
index 0000000..4a4e58e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/any_role.xmi
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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="_NqqcUqeqEdmKDbQuyzCoqQ" name="any_role,_0dsWoMlgEdmt3adZL5Dmdw" guid="_NqqcUqeqEdmKDbQuyzCoqQ" changeDate="2006-09-11T11:34:17.153-0700">
+ <mainDescription><p>
+ This role allows anyone on a team to perform general tasks:
+</p>
+<ul>
+ <li>
+ Access artifacts in the configuration control system for development and maintenance
+ </li>
+ <li>
+ Submit change requests for the project
+ </li>
+ <li>
+ Participate in assessments and reviews
+ </li>
+ <li>
+ Volunteer to work on a particular iteration
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/architect.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/architect.xmi
new file mode 100644
index 0000000..b5bc66d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/architect.xmi
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_Y6tLEKbXEdm9d-ircVOUCA" name="architect,_0X9iEMlgEdmt3adZL5Dmdw" guid="_Y6tLEKbXEdm9d-ircVOUCA" changeDate="2007-03-02T10:46:47.447-0800" version="1.0.0">
+ <mainDescription><p>
+ This role leads or coordinates the technical design of the system and has overall responsibility for facilitating the
+ major technical decisions expressed as software architecture. This typically includes identifying and documenting the
+ architecturally significant aspects of the system as views that describe requirements, design, implementation, and
+ deployment.
+</p>
+<p>
+ This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various
+ stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and
+ followed.
+</p>
+<p>
+ This role is closely involved in organizing the team around the architecture by working closely with the&nbsp;<a
+ class="elementLink" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a>&nbsp;in staffing and planning the project.
+</p></mainDescription>
+ <keyConsiderations>This role&nbsp;places emphasis on the core principle <a class="elementLink"
+href="./../../openup_basic/guidances/concepts/core_principle_focus,_9gocwMvoEdqukPpotm3DYg.html"
+guid="_9gocwMvoEdqukPpotm3DYg">Focus on articulating the architecture</a>.</keyConsiderations>
+ <skills><p>
+ Architects must be well-rounded people with maturity, vision, and a depth of experience that allows for grasping issues
+ quickly and making educated, critical judgments in the absence of complete information. Specifically, the person must
+ possess this combination of qualifications:
+</p>
+<ul>
+ <li>
+ <b>Experience</b> <strong>in both problem and software engineering domains</strong>, with evidence of a thorough
+ understanding of the requirements to solve the problem and active participation in software development. If there
+ is a team, this experience can be represented by different team members, but at least one person must be able to
+ provide the overall vision for the project.
+ </li>
+ <li>
+ <b>Leadership ability</b> to motivate and maintain momentum for the technical effort across the various teams and
+ to make critical decisions under pressure, plus make those decisions stick. To be effective, this role must have
+ the authority to make technical decisions.
+ </li>
+ <li>
+ <b>Excellent communication</b> <strong>skills</strong> to earn trust, persuade, motivate, and mentor. This role
+ cannot lead by decree, but only by the consent of the rest of the project team. To be effective, this&nbsp;person
+ must earn the respect of the team members, the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a>, the customer, and the user community, as well as the management
+ team.
+ </li>
+ <li>
+ <b>Goal-oriented and proactive</b> <strong>orientation</strong> with a relentless focus on results.&nbsp;This
+ person is the technical driving force behind the project, not a visionary or dreamer. The career of a successful
+ architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can
+ focus on doing what needs to be done will be successful.
+ </li>
+</ul>
+<p>
+ From an expertise standpoint, this role also needs to show both design and implementation abilities. However, from the
+ design perspective, the effective architect typically exhibits these traits:
+</p>
+<ul>
+ <li>
+ Tends to be a generalist, rather than a specialist, who knows many technologies at a high level rather than a few
+ technologies at the detail level
+ </li>
+ <li>
+ Makes the broader technical decisions, thereby demonstrating broad knowledge and experience, as well as
+ communication and leadership skills
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ This person in this role should be engaged in the project from start to finish.
+</p>
+<p>
+ For smaller projects, a single person may act as both Architect and <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a>. However, it is better to have these roles performed by different people to ensure that the pressures one
+ role doesn't cause neglect of the other role.&nbsp;The Architect and Project Manager&nbsp;must work together closely.
+</p></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/developer.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/developer.xmi
new file mode 100644
index 0000000..b269533
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/developer.xmi
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_NqL7MqeqEdmKDbQuyzCoqQ" name="developer,_0YDosMlgEdmt3adZL5Dmdw" guid="_NqL7MqeqEdmKDbQuyzCoqQ" changeDate="2007-01-14T17:32:58.561-0500" version="1.0.0">
+ <skills><p>
+ This role needs the following knowledge, skills, and abilities:
+</p>
+<ul>
+ <li>
+ Define and create technical solutions in the project's technology
+ </li>
+ <li>
+ Understand and&nbsp;conform to the&nbsp;architecture
+ </li>
+ <li>
+ Identify and build developer tests that cover required behavior of the technical components
+ </li>
+ <li>
+ Communicate the design in a way that other team members understand
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ On small, agile teams this role is often shared among several team members that also perform other roles.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self Organize Work Assignments</a>&nbsp;and <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/staffing_project,_Jq64EJjsEduad8I_c-ogIA.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;for more information on this approach.
+</p>
+<p>
+ Even in the smallest team, multiple individuals should be working together to create the technical solution.
+</p>
+<p>
+ A person performing this role can have specialized skills in a particular technical area, but should also have a broad
+ understanding of all the technologies involved to be able to work with other technical team members.
+</p></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/developer_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/developer_vm.xmi
new file mode 100644
index 0000000..a7e0c5c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/developer_vm.xmi
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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="-xbAirPdH1IOKcnklk8hdqw" name="new_role,_sypCEPvjEdqf0-top1XJIg" guid="-xbAirPdH1IOKcnklk8hdqw" changeDate="2006-09-11T11:34:39.535-0700">
+ <skills><p>
+ In addition, to create a visual model of the system, this role needs the ability to&nbsp;render the design in the
+ Unified Modeling Language (UML).
+</p></skills>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/project_manager.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/project_manager.xmi
new file mode 100644
index 0000000..998218c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/project_manager.xmi
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_Fdq-8KX4EdmvhNXG0Oc2uA" name="project_manager,_0a0o0MlgEdmt3adZL5Dmdw" guid="_Fdq-8KX4EdmvhNXG0Oc2uA" changeDate="2006-11-01T17:03:02.026-0800" version="1.0.0">
+ <mainDescription><p>
+ This role:
+</p>
+<ul>
+ <li>
+ Applies management knowledge, skills, tools and techniques to a broad range of tasks in order to deliver&nbsp;the
+ desired&nbsp;result for a particular project in a timely fashion.
+ </li>
+ <li>
+ Is accountable for the outcome of the project and the acceptance of the product by the customer.
+ </li>
+ <li>
+ Responsible for the evaluation of project's risks, and controling these risks through mitigation strategies.&nbsp;
+ </li>
+</ul></mainDescription>
+ <skills><p>
+ A person performing this role needs the following skills:
+</p>
+<ul>
+ <li>
+ Good in presentation, facilitation, communication, and negotiation.
+ </li>
+ <li>
+ Leadership and team building capabilities.
+ </li>
+ <li>
+ Thorough experience in the software development lifecycle to teach, guide and support other team members.
+ </li>
+ <li>
+ Proficient in conflict resolution and problem solving techniques.
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ This role is often played by a single person. This role is difficult to share with others, but might not consume all of
+ a person’s availability.
+</p>
+<br />
+<br /></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/roles/tester.xmi b/OpenUP/OpenUP_PT/library/openup_basic/roles/tester.xmi
new file mode 100644
index 0000000..8af4c86
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/roles/tester.xmi
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_NqYIcKeqEdmKDbQuyzCoqQ" name="tester,_0ZM4MclgEdmt3adZL5Dmdw" guid="_NqYIcKeqEdmKDbQuyzCoqQ" changeDate="2006-09-26T13:51:28.608-0700" version="1.0.0">
+ <mainDescription><p>
+ This role is primarily responsible for the following&nbsp;tasks:
+</p>
+<ul>
+ <li>
+ Identify the tests&nbsp;that need to&nbsp;be performed
+ </li>
+ <li>
+ Identify the most appropriate implementation approach for a given test
+ </li>
+ <li>
+ Implement individual tests
+ </li>
+ <li>
+ Set up and execute the tests
+ </li>
+ <li>
+ Log outcomes and verify that the tests have been run
+ </li>
+ <li>
+ Analyze and recover from execution errors
+ </li>
+ <li>
+ Communicate test results to the team
+ </li>
+</ul></mainDescription>
+ <skills><p>
+ A person&nbsp;filling the&nbsp;this role should have the following skills:
+</p>
+<ul>
+ <li>
+ Knowledge of testing approaches and techniques
+ </li>
+ <li>
+ Diagnostic and problem-solving skills
+ </li>
+ <li>
+ Knowledge of the system or application being tested (desirable)
+ </li>
+ <li>
+ Knowledge of networking and system architecture (desirable)
+ </li>
+</ul>
+<p>
+ Where automated testing is required, consider requiring these additional qualifications:
+</p>
+<ul>
+ <li>
+ Training in the appropriate use of test automation tools
+ </li>
+ <li>
+ Experience using test automation tools
+ </li>
+ <li>
+ Programming skills
+ </li>
+ <li>
+ Debugging and diagnostic skills
+ </li>
+</ul>
+<p>
+ <strong>Note:</strong> Specific skill requirements vary depending on the type of testing that you are conducting. For
+ example, the skills needed to successfully use system load testing automation tools are different from those needed for
+ the automation of system functional testing.
+</p></skills>
+ <assignmentApproaches><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ Assign one or more testing staff members to perform this role. This is a fairly standard approach and is
+ particularly suitable for small teams, as well as for teams of any size where the team is made up of an experienced
+ group of testers of relatively equal skill levels.
+ </li>
+ <li>
+ Assign one or more testing staff members to perform only this role.&nbsp;This works well in large teams. It is also
+ useful to separate responsibilities when some of the testing staff has more test automation experience than other
+ team members.
+ </li>
+ <li>
+ Assign one or more team members that is already playing another role in the project to be responsible for the
+ testing of some part of the system’s capabilities.&nbsp;The team member will have to have the appropriate test
+ skills
+ </li>
+</ul></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/rolesets/openup_basic_roles.xmi b/OpenUP/OpenUP_PT/library/openup_basic/rolesets/openup_basic_roles.xmi
new file mode 100644
index 0000000..4bd2350
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/rolesets/openup_basic_roles.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="_Tb5J8O8NEdmKSqa_gSYthg" name="openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg" guid="_Tb5J8O8NEdmKSqa_gSYthg" changeDate="2007-02-27T13:09:15.904-0800" version="1.0.0">
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">roles</a>. You can see the roles that have been included, and visit each role page to
+ see its definition and relationships to other elements.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/analyze_arch_reqs.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/analyze_arch_reqs.xmi
new file mode 100644
index 0000000..55fbc36
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/analyze_arch_reqs.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_qDRSULBKEdm7Eph_l9Cn9w" name="analyze_architecture,_0f-1oMlgEdmt3adZL5Dmdw" guid="_qDRSULBKEdm7Eph_l9Cn9w" changeDate="2007-03-03T21:37:35.140+0000" version="1.0.0">
+ <mainDescription><p>
+ This task focuses on defining a candidate&nbsp;architecture&nbsp;that will guide&nbsp;the development, testing, and
+ operation of the system. It relies on gathering experience gained in similar systems or problem domains to constrain
+ and focus the architecture so that effort is not wasted in re-inventing architecture.
+</p>
+<p>
+ Capture architectural decisions in the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. Make sure that this is communicated across the team.
+</p></mainDescription>
+ <keyConsiderations><p>
+ This task&nbsp;is most beneficial when developing new and unprecedented systems. In systems where there is already a
+ well-defined architecture, this task might be omitted, or performed quickly as a&nbsp;review of the existing
+ architecture.
+</p>
+<p>
+ It is critical that this task is performed collaboratively with active involvement of other team members and project
+ stakeholders so that consensus and common understanding is reached. It is particularly vital for the architect to
+ involve the developer(s) throughout this task. The architecture effort&nbsp;is about providing leadership and
+ coordination of the technical work rather than putting in a solo performance.
+</p></keyConsiderations>
+ <sections xmi:id="_3nMQQA3rEduibvKwrGxWxA" name="Identify architectural goals" guid="_3nMQQA3rEduibvKwrGxWxA">
+ <sectionDescription><p>
+ Describe the goals of the architecture by examining the product <a class="elementLink"
+ href="./../../openup_basic/guidances/checklists/vision,_0WoFUMlgEdmt3adZL5Dmdw.html"
+ guid="_0WoFUMlgEdmt3adZL5Dmdw">Vision</a>&nbsp;and requirements, including architecturally significant requirements.
+ Also, talk to the project <a class="elementLink"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> and <a class="elementLink"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a>.
+ These goals will guide your&nbsp;approach to important architectural and design decisions.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_9o6Z4CSCEdqDjNgZyGMf5w" name="Identify architectural constraints" guid="_9o6Z4CSCEdqDjNgZyGMf5w">
+ <sectionDescription><p>
+ Understand&nbsp;any constraints (or opportunities) on the solution&nbsp;that are inherent in the existing environment
+ or organization. If available, examine the <a class="elementLink"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>&nbsp;for any constraints that have already been
+ identified.&nbsp;Discuss any critical time and resource constraints with the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a>, as these&nbsp;will also need to be taken into account when arriving at your decisions. Discuss potential
+ constraints with the tester such as hooks for tests, and to identify architectural areas that may be difficult to test.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_B899cMP2EdmWKcx6ixEiwg" name="Survey, assess, and select available assets" guid="_B899cMP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Establish the availability of any existing software assets as suitable candidates for re-use. Make sure you consult
+ with others who have knowledge of existing assets, particularly the&nbsp;<a class="elementLink"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html"
+ guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a>(s) and other&nbsp;people outside the project team (such as production
+ support teams) in order to form a balanced view of the suitability of existing assets for re-use. Identifying reusable
+ assets could be done as a team brainstorming session.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_FVrlsMP2EdmWKcx6ixEiwg" name="Define approach for structuring the system" guid="_FVrlsMP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Decide how to structure&nbsp;the software, both in logical and physical terms. As a minimum, decide on:
+</p>
+<ul>
+ <li>
+ How to partition the software when managing development
+ </li>
+ <li>
+ How the software will be composed at run time.
+ </li>
+</ul>
+<p>
+ For each software partition, briefly describe
+</p>
+<ul>
+ <li>
+ Their name and purpose.
+ </li>
+ <li>
+ Their relationships to other partitions.
+ </li>
+</ul>
+<p>
+ These decisions will form the basis for structuring the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;and the <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_tmvWwE5cEducxZ_XZXh-vw" name="Define approach for deploying the system" guid="_tmvWwE5cEducxZ_XZXh-vw">
+ <sectionDescription>Outline how the software will deploy over the nodes on the network. Work with stakeholders such as as network support and
+deployment&nbsp;teams to ensure that the proposed approach is a good fit for the wider technical environment.</sectionDescription>
+ </sections>
+ <sections xmi:id="_I32E4MP2EdmWKcx6ixEiwg" name="Identify key abstractions" guid="_I32E4MP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Identify the key abstractions that the system needs to handle. You can usually find these by looking for nouns that the
+ requirements emphasize or repeat, because they help identify what is important to the business. The <a
+ class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html"
+ guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> is particularly useful for this. Work with the analyst and stakeholder
+ here, as they will have knowledge and materials that are relevant to this step. Work with the developer to identify key
+ abstractions internal to the system.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_KBAsYMP2EdmWKcx6ixEiwg" name="Identify architectural mechanisms" guid="_KBAsYMP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Catalog the architectural mechanisms that are necessary to fulfil the requirements. At this stage, it only
+ necessary&nbsp;to capture&nbsp;a relatively small amount of detail for each mechanism. Discuss the requirements
+ (especially&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) that are being addressed by each&nbsp;mechanisms with the
+ analysts and stakeholders to make sure that the requirements are&nbsp;unambiguous and well understood.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xTdYACGAEdqk6N_Ot_YEvA" name="Capture architectural decisions" guid="_xTdYACGAEdqk6N_Ot_YEvA">
+ <sectionDescription><p>
+ Capture&nbsp;important decisions&nbsp;about the architecture for future reference. Consider using the templates
+ provided for the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>.
+</p></sectionDescription>
+ </sections>
+ <purpose>To provide sufficient guidance and direction for the team to be able to perform analysis and design&nbsp;in consistent and
+coherent ways.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/assess_results.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/assess_results.xmi
new file mode 100644
index 0000000..113f1eb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/assess_results.xmi
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_a3uz4LBYEdm7Eph_l9Cn9w" name="assess_results,_0l53cMlgEdmt3adZL5Dmdw" guid="_a3uz4LBYEdm7Eph_l9Cn9w" changeDate="2006-09-22T12:12:39.478-0700" version="1.0.0">
+ <sections xmi:id="_PABe4MQIEdmaiYJe8-Eaqg" name="Gather stakeholder feedback" guid="_PABe4MQIEdmaiYJe8-Eaqg">
+ <sectionDescription><p>
+ The team should demonstrate the product to customer, end-users, and other <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>s&nbsp;to collect their feedback, or better yet, have end users to use the product themselves. This
+ should be done throughout the iteration, or at least in a separate session towards the end of the iteration. Record
+ requested changes to the product in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;for later prioritization. Factor&nbsp;the feedback
+ into the&nbsp;overall iteration assessment.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_o28GgMMsEdmdo9HxCRR_Gw" name="Assess results" guid="_o28GgMMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ Towards the end of the iteration, the team should jointly assess whether the objectives and evaluation criteria
+ established in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a>&nbsp;were met, and whether the team adhered to the
+ iteration plan and completed all the planned work items. Below&nbsp;are some sample questions that the team can ask
+ themselves as a part of the assessment:
+</p>
+<ul>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
+ release meet performance and capacity goals?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Were risks reduced or eliminated? Can we identify new risks?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Were all planned work items addressed? What was the teams velocity relative to plan?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Did the end users provide favorable feedback on what we built in this iteration?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Are changes to the project plan required?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ What portion of the current release will be baselined? What portion will need to be reworked?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ Have there been external changes such as changes in the marketplace, in the user community, or in the
+ requirements?
+ </div>
+ </li>
+</ul>
+<p dir="ltr">
+ The assessments should be based on objective measures to the greatest extent possible. For example, to assess that a
+ given requirement is developed, the team should ensure that the corresponding test cases were successfully run against
+ it, rather than considering it done when the implementation is done.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_iL7cQEpqEdup0IY9DKDPkg" name="Perform a retrospective" guid="_iL7cQEpqEdup0IY9DKDPkg">
+ <sectionDescription><p>
+ Review the approach taken to development and team collaboration, the effectiveness of the development environment, the
+ suitability of the working environment, and other factors and discuss what things went well, what could have gone
+ better, and how things could be changed to deliver better results. Capture actions to be taken to improve the
+ development approach for next iteration in the <a class="elementLink" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_YdoAAM1DEdmLoKw_mVTvhQ" name="Refine project scope and duration" guid="_YdoAAM1DEdmLoKw_mVTvhQ">
+ <sectionDescription><p>
+ Depending on the results of the&nbsp;assessment and the stakeholders' feedback, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a>&nbsp;could need to revise the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>&nbsp;to adapt to those changes. If a change affects defined
+ project milestones, the project manager should consult with the stakeholders before committing to the changes.
+</p>
+<p>
+ Necessary changes can also encompass the need to acquire new resources, to absorb an unplanned effort increase, or to
+ implement a specific change request.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_wp2CIMMsEdmdo9HxCRR_Gw" name="Close-out phase" guid="_wp2CIMMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ This step is optional and must be performed only when the assessment period coincide with the end of a phase.
+</p>
+<p>
+ The end of&nbsp;a phase represents a point of synchronization of technical and management expectations and closure for
+ a project. In iterative development, it coincides&nbsp;with the end of an iteration. However, phase ends mark a point
+ when it is possible to consider re-scoping and even re-contracting a project. For example, the inception phase is
+ exploratory and may be appropriately performed under a time-and-materials contract or a cost-plus type of contract. The
+ elaboration phase could be done as a fixed-price contract or a cost-plus contract, depending on the extent to which the
+ development is unusual. By the construction and transition phases, enough is known about the system that fixed-price
+ contracts are more appealing to the acquirer and vendor.
+</p>
+<p>
+ The phase end is marked by a major milestone and a corresponding milestone review. The degree of formality of
+ these&nbsp;reviews depends on the project. The important thing is to take advantage&nbsp;of this milestone review to
+ achieve agreement among all stakeholders on the current state of the project. For more information, refer to <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Concept: Milestones</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_1YHH8DLqEdueZPye-FaNgA" name="Close-out project" guid="_1YHH8DLqEdueZPye-FaNgA">
+ <sectionDescription><p>
+ This step is optional and must be performed only when the assessment period coincide with the end of the project.
+</p>
+<p>
+ Involve the team and stakeholders in&nbsp;a final assessment for project acceptance which, if successful, marks the
+ point when the customer accepts ownership of the software product. Gather and record the lessons learned to be used in
+ future projects. Complete the close-out of the project by disposing of the remaining assets and reassigning the
+ remaining staff.
+</p></sectionDescription>
+ </sections>
+ <purpose>Capture and communicate whether the project is on track, requires corrective actions, and whether there are opportunities
+for improvement.<br /></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/create_test_cases.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/create_test_cases.xmi
new file mode 100644
index 0000000..59c2631
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/create_test_cases.xmi
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrVKsKeqEdmKDbQuyzCoqQ" name="create_test_cases,_0iwc0clgEdmt3adZL5Dmdw" guid="_NrVKsKeqEdmKDbQuyzCoqQ" changeDate="2007-02-07T15:38:57.234-0800" version="1.0.0">
+ <sections xmi:id="_IJFSsKuSEdmhFZtkg1nakg" name="Review the requirements to be tested" guid="_IJFSsKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Work with&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html"
+ guid="_0VxJsMlgEdmt3adZL5Dmdw">Role: Analyst</a> and <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Role:
+ Developer</a>&nbsp;to identify which use-case scenarios need new or additional test cases. Review the <a
+ class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a>&nbsp;to ensure you understand the scope of development for
+ the current iteration.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_aDe_ILGcEdubqf8m_Zrvvg" name="Identify relevant Test Cases" guid="_aDe_ILGcEdubqf8m_Zrvvg">
+ <sectionDescription><p>
+ Identify paths through the use-case scenario as unique test conditions.&nbsp; Consider alternative or exception paths
+ from both a positive and negative perspective.&nbsp;&nbsp;Review the test ideas list for patterns of test cases that
+ apply to the use-case scenario.
+</p>
+<p>
+ Discuss the requirement with the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role:
+ Stakeholder</a> to identify other conditions of satisfaction for the requirement.
+</p>
+<p>
+ List the test cases with a unique name that identifies the condition they evaluate or their expected result.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_LpbM8KuSEdmhFZtkg1nakg" name="Outline the Test Cases" guid="_LpbM8KuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ For each test case, write a brief description with an expected result.&nbsp; Ensure that a casual reader can clearly
+ understand the difference between test cases.&nbsp; Note the logical pre-conditions and post-conditions that apply to
+ each test case. Optionally, outline steps for the test case.
+</p>
+<p>
+ Verify that test cases meet the <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/checklists/test_case,_0Zxf8MlgEdmt3adZL5Dmdw.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>&nbsp;guidelines.
+</p>
+<p>
+ For more information on the test case, see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/templates/test_case,_0dT8IMlgEdmt3adZL5Dmdw.html"
+ guid="_0dT8IMlgEdmt3adZL5Dmdw">Template: Test Case</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_NK18YKuSEdmhFZtkg1nakg" name="Identify test data needs" guid="_NK18YKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Review each test case and note where data input or output might be required. Identify the type, quantity, and
+ uniqueness of the required data, and add these observations to the test case. Focus on articulating the data needed and
+ not on creating specific data.
+</p>
+<p>
+ For more information on test data selection, see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/checklists/test_case,_0Zxf8MlgEdmt3adZL5Dmdw.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Ok_mMKuSEdmhFZtkg1nakg" name="Share and evaluate the Test Cases" guid="_Ok_mMKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Walk through the test cases with the&nbsp;<a class="elementLinkWithType"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Role:
+ Analyst</a>&nbsp;and&nbsp;<a class="elementLinkWithType"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Role:
+ Developer</a>&nbsp;responsible for the related&nbsp;use-case scenario.&nbsp;&nbsp;Ideally, the <a
+ class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>&nbsp;also participates.
+</p>
+<p>
+ Ask the participants to agree that if <em>these test cases pass</em>, they will consider these requirements
+ implemented.&nbsp; Elicit additional test ideas from the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Role: Analyst</a>
+ and the <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a> to ensure you understand the expected behavior of the use-case
+ scenario.
+</p>
+<p>
+ During the walkthrough, ensure that:
+</p>
+<ul>
+ <li>
+ The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>&nbsp;and <a class="elementLinkWithType"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>&nbsp;planned for the current iteration have
+ test cases.
+ </li>
+ <li>
+ All the participants agree with the expected results of the test cases.
+ </li>
+ <li>
+ There are no&nbsp;<em>other</em> conditions of satisfaction for the requirement being tested, which indicates
+ either a missing test case or a missing requirement.
+ </li>
+</ul>
+<p>
+ Optionally, capture new patterns of test cases&nbsp;in&nbsp;the test ideas list (see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/concepts/test_ideas_list,_0jnYcMlgEdmt3adZL5Dmdw.html"
+ guid="_0jnYcMlgEdmt3adZL5Dmdw">Concept: Test Ideas List</a>).
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ To achieve a shared understanding of the specific conditions that the solution must meet.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/define_vision.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/define_vision.xmi
new file mode 100644
index 0000000..d86d19e
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/define_vision.xmi
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_5rJ78Lj3Edmy88CC3LfB_w" name="define_vision,_0fOAoMlgEdmt3adZL5Dmdw" guid="_5rJ78Lj3Edmy88CC3LfB_w" changeDate="2007-02-28T06:02:00.035-0800" version="1.0.0">
+ <sections xmi:id="_tvzDULwPEdm6DujQZORGLQ" name="Identify Stakeholders" guid="_tvzDULwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Identify the decision-makers, customers, potential users, partners, domain experts, industry analysts and other
+ interested parties (see <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role:
+ Stakeholder</a>). Develop profiles of potential (or actual) users of the system that map to the roles of human actors
+ of the system that you are developing. Document the initial information on key users and their environment in the <a
+ class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_sa5F4LwPEdm6DujQZORGLQ" name="Gain agreement on the problem to be solved" guid="_sa5F4LwPEdm6DujQZORGLQ">
+ <sectionDescription>Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the stakeholders
+what they see as the problem. Then search for root causes, or the “problem behind the problem.”
+Use&nbsp;techniques&nbsp;like the ones&nbsp;described in&nbsp;<a class="elementlinkwithtype"
+href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html"
+guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>. Formulate the problem statement, and then
+fill in the corresponding section from <a class="elementlinkwithtype"
+href="./../../openup_basic/guidances/templates/vision,_0cW54MlgEdmt3adZL5Dmdw.html"
+guid="_0cW54MlgEdmt3adZL5Dmdw">Template: Vision</a>. The purpose of this is to help you distinguish solutions and answers
+from problems and questions.<br />
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_rliOAOz2Edq2wJOsmRwmhg" name="Capture a common vocabulary" guid="_rliOAOz2Edq2wJOsmRwmhg">
+ <sectionDescription>Every project has its own specialized terminology that everyone on the team must understand well to communicate effectively
+with stakeholders. Work with stakeholders to&nbsp;create a glossary that defines acronyms, abbreviations, and&nbsp;relevant
+business and technical terms. Work with stakeholder to continually expand and refine the&nbsp;glossary throughout the
+project life cycle.</sectionDescription>
+ </sections>
+ <sections xmi:id="_vGg-oLwPEdm6DujQZORGLQ" name="Gather stakeholder requests" guid="_vGg-oLwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Use the most appropriate method to gather information, such as the ones in <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html"
+ guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>. Each one is applicable in a particular
+ situation or to a certain type of stakeholder.
+</p>
+<p>
+ If you can meet stakeholders in person, then you can conduct an interview or a brainstorming session. This face to face
+ collaboration is extremely valuable and reduces the chances of the project team misunderstanding the needs of the
+ stakeholders.
+</p>
+<p>
+ Some requirements may already be documented in an existing Work Item List. This can often be used as a solid starting
+ position from which a full set of requirements can be created.
+</p>
+<p>
+ Any requirements gathered during this step should be captured in the Work Item List.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_z7ZC4LwPEdm6DujQZORGLQ" name="Define the system boundaries" guid="_z7ZC4LwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Find and define the line that divides the solution and the real world that surrounds the solution. Identify interfaces,
+ as well as input and output information exchanged with users, machines, or systems.
+</p>
+<p>
+ A Use Case Model is one technique that can prove useful in defining the system boundaries.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_1LVn0LwPEdm6DujQZORGLQ" name="Identify constraints on the system" guid="_1LVn0LwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Consider the various sources of constraints that can impact the design or the project itself:
+</p>
+<ul>
+ <li>
+ Political
+ </li>
+ <li>
+ Economic (budget, licensing)
+ </li>
+ <li>
+ Environmental (regulatory constraints, legal, standards)
+ </li>
+ <li>
+ Technical (platforms, technology)
+ </li>
+ <li>
+ Feasibility (schedule, resources allocation, outsourcing)
+ </li>
+ <li>
+ System (solutions compatibility, support of operating systems and environments).
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_2VixILwPEdm6DujQZORGLQ" name="Define features of the system" guid="_2VixILwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Work with stakeholders to capture&nbsp;a list&nbsp;of&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a> that stakeholders want in the system, briefly describing them and giving <a
+ class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/requirement_attributes,_VQ268O0KEdqHTdbLTmC5IQ.html"
+ guid="_VQ268O0KEdqHTdbLTmC5IQ">attributes</a> to help define their general status and priority in the project.
+</p>
+<p>
+ Update the <a class="elementLinkWithType"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;to capture the features identified&nbsp;and their
+ attributes.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_AhjmAL-GEdqb7N6KIeDL8Q" name="Achieve concurrence" guid="_AhjmAL-GEdqb7N6KIeDL8Q">
+ <sectionDescription>Conduct a review&nbsp;of the project vision with relevant Stakeholders and the development team to ensure agreement, assess
+quality, and identify required changes. See&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a> for more information.</sectionDescription>
+ </sections>
+ <purpose>The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to
+express and document their problems, needs, and potential features for the system to be, so the project team can better
+understand what has to be done.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/design_solution.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/design_solution.xmi
new file mode 100644
index 0000000..2a44af0
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/design_solution.xmi
@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrC20qeqEdmKDbQuyzCoqQ" name="design_solution,_0fshwMlgEdmt3adZL5Dmdw" guid="_NrC20qeqEdmKDbQuyzCoqQ" changeDate="2006-09-09T05:58:28.732-0700" version="1.0.0">
+ <mainDescription><p>
+ This task is about designing part of the system, not the whole system.&nbsp; It should be applied based upon some small
+ subset of requirements.&nbsp; The requirements driving the design could be scenario-based functional requirements,
+ non-functional requirements, or a combination.
+</p>
+<p>
+ This task can be applied in some specific context such as the database access elements required for some
+ scenario.&nbsp; In this case the task might be applied&nbsp;again later&nbsp;to deal with a different context on the
+ same requirements.&nbsp; Keep in mind that to actually build some functionality of value&nbsp;to the users, all
+ contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
+ will have to have been designed and implemented all its context such as user interface, business rules, database
+ access, etc.
+</p>
+<p>
+ If this task is being performed on an architecturally significant element the results of this design should be
+ referenced by the architecture.
+</p></mainDescription>
+ <keyConsiderations><P>Each step in this task can cause all previous steps to be revisited in light of new information and decisions.&nbsp; For example, while determining how elements collaborate&nbsp;you might find a gap in the requirements that causes you to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer could&nbsp;note that a reusable element being used doesn't work as expected and that could cause you to identify new elements to take its place.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
+<P>Consider the architecture while performing this task.&nbsp; All design work must be done while regarding the architecture within which the design exists.&nbsp; Furthermore, certain design elements will be deemed architecturally significant; those elements will require updates to the architecture. </P>
+<P>This task will be applied numerous times.&nbsp; Design is best performed in small chunks.</P>
+<P>Even when starting the design for a particular project it&nbsp;is expected that there will be existing frameworks and reusable elements.&nbsp; Every step of this task must give attention to the existing design and existing implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate while designing this portion of the solution. </P>
+<P>Apply patterns throughout this task.&nbsp; Patterns represent proven designs and their usage promotes quality and consistency across the design. </P></keyConsiderations>
+ <sections xmi:id="_4Z7WYKuKEdmhFZtkg1nakg" name="Understand requirement details" guid="_4Z7WYKuKEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Examine the relevant <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>&nbsp;to understand the scope of the design task and the
+ expectations on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
+ information.
+</p>
+<p>
+ If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might
+ not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the
+ requirements under consideration.
+</p>
+<p>
+ If the requirements are&nbsp;determined to be&nbsp;incomplete or incorrect, work with the analyst to get the
+ requirements improved and possibly submit a change request against the requirements.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Ci7aYFixEdusJoWkvSRO9Q" name="Understand the architecture" guid="_Ci7aYFixEdusJoWkvSRO9Q">
+ <sectionDescription><p>
+ Understand how the architecture applies to this part of the design, and how this design work fits with the rest of the
+ system. Incorporate any applicable interfaces, key abstractions, mechanisms and patterns into the design work. Discuss
+ possible refinements to the architecture and new areas of potential re-use with the architect.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_--6tYKuKEdmhFZtkg1nakg" name="Identify design elements" guid="_--6tYKuKEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Identify the elements that collaborate together to provide the required behavior.&nbsp; This can start with the key
+ abstractions identified in the architecture, domain analysis, and classical analysis&nbsp;of the requirements (noun
+ filtering) to derive the&nbsp;elements that would be required to fulfill them.
+</p>
+<p>
+ Identify elements in all perspectives being considered when performing this task.&nbsp; This could include identifying
+ user interface elements,&nbsp;control elements, data elements,&nbsp;and elements relating to interfacing to other
+ systems or devices.
+</p>
+<p>
+ Existing elements of the design should be examined to see if they should participate in the collaboration.&nbsp; It is
+ a mistake to create all new elements in each&nbsp;execution of this task.
+</p>
+<p>
+ This list of candidates must be expanded to include special-purpose participants that handle&nbsp;particular roles in
+ providing the required behavior such as transaction processing or adherence to some security specification.&nbsp; The
+ <a class="elementLink" href="./../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides a good start for identifying elements.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_A_LU8KuLEdmhFZtkg1nakg" name="Determine how elements collaborate to realize the scenario" guid="_A_LU8KuLEdmhFZtkg1nakg">
+ <sectionDescription>Walk through the scenario distributing responsibilities to the participating elements. These responsibilities can be simple
+statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc. This
+step is about ensuring that a quality model is being created that is robust enough to support the requirements.&nbsp;
+<p>
+ Identify the required relationships between the&nbsp;elements based on the walkthrough of the scenario examining how
+ the elements initiate each other's behavior. An element that requests behavior from another element is represented as a
+ relationship between those elements. As with the responsibilities, these relationships can just be defined at this
+ step.
+</p>
+<p>
+ Look to the architecture and previous design work to create a consistent collaboration. Use the Architect to explain
+ the details and motivations of the architecture. Look to reuse existing behavior and relations or to apply similar
+ structure to simplify the design of the overall system.
+</p>
+<p>
+ Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the
+ existing elements.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_ENwJwKuLEdmhFZtkg1nakg" name="Refine design decisions" guid="_ENwJwKuLEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
+ architecture.&nbsp; In this step the design can take into consideration the actual implementation language and other
+ technical decisions.&nbsp; Revisit the identification of the elements and the collaborations&nbsp;that realize the
+ scenarios if necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss
+ testability issues, such as&nbsp;design elements that are difficult to test or critical performance areas,&nbsp;with
+ the Tester and Architect.
+</p>
+<p>
+ In particular make decisions in regard to the considerations below:
+</p>
+<ul>
+ <li>
+ Specific details of relationships between the elements such as multiplicity and navigability
+ </li>
+ <li>
+ Operation detail such as parameters and return values
+ </li>
+ <li>
+ Existence and detail of data attributes necessary
+ </li>
+ <li>
+ Usage of inheritance and interfaces to improve the design
+ </li>
+</ul>
+<p>
+ Incorporate <a class="elementLink" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s from the architecture. Apply consistent structure of the elements
+ and organization of the behavior as in other areas of the design and use patterns identified in the architecture.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_KNZYAKuLEdmhFZtkg1nakg" name="Design internals (for large or complex elements)" guid="_KNZYAKuLEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Design large or complex elements or some complex internal behavior in more detail. &nbsp;
+</p>
+<p>
+ This might just involve devising an algorithm that&nbsp;could be performed to produce the desired behavior. Add
+ additional operations, attributes, and relationships to support the expectations of an element. Discuss testability
+ issues, such as&nbsp;design elements that are difficult to test or critical performance areas,&nbsp;with the Tester and
+ Architect.
+</p>
+<p>
+ The state of the&nbsp;element managed over the course of its lifetime&nbsp;can be designed to ensure proper behavior in
+ various usages.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_9LeFME42EdudDeUNeAxPCQ" name="Design the database schema" guid="_9LeFME42EdudDeUNeAxPCQ">
+ <sectionDescription><p>
+ If the system has persistent data, the design will need to address&nbsp;the database (or file) schema.&nbsp; For a
+ relational database schema, identify the following:
+</p>
+<ul>
+ <li>
+ The structure of tables and views
+ </li>
+ <li>
+ Relationships between&nbsp;tables
+ </li>
+ <li>
+ Triggers which enforce referential integrity
+ </li>
+ <li>
+ Constraints on columns
+ </li>
+ <li>
+ Default values for columns
+ </li>
+ <li>
+ Stored procedures and functions
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_mUVt8BfnEduD353bkQ4frw" name="Evaluate the design" guid="_mUVt8BfnEduD353bkQ4frw">
+ <sectionDescription><p>
+ Evaluate the object design for coupling, cohesion, and other quality design measurements.
+</p>
+<p>
+ Evaluate the database/file design for performance, referential integrity, and normalization.
+</p>
+<p>
+ Consider the design from various angles to ensure that it is a high-quality, communicable design.&nbsp; Work with other
+ technical team members; an independent party can provide a fresh perspective.&nbsp;Use the Tester and Architect to
+ provide perspectives on&nbsp;design quality and adherence to the architecture.&nbsp;However, when identifying potential
+ reviewers keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even
+ more value by actively participating in the design effort itself.
+</p>
+<p>
+ If design flaws are identified, improve the design.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_OGYbwKuLEdmhFZtkg1nakg" name="Communicate the design" guid="_OGYbwKuLEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Communicate&nbsp;the design to&nbsp;those who need to understand it. Though this is described here toward the end of
+ the task, communication should be going on throughout the steps. Working collaboratively is always better than
+ reviewing the work after it is complete.
+</p>
+<p>
+ Here are some ways to communicate&nbsp;the design:
+</p>
+<ul>
+ <li>
+ Formal models&nbsp;specified in UML .
+ </li>
+ <li>
+ Informal diagrams that render static structure and capture&nbsp;dynamic behavior.
+ </li>
+ <li>
+ Annotated code that communicates information about the static structure supplemented with textual descriptions of
+ dynamic behavior across code modules&nbsp;.
+ </li>
+ <li>
+ Physical data models to describe the database schema.
+ </li>
+</ul>
+<p>
+ Here are some examples of individuals&nbsp;who will need to understand the design:
+</p>
+<ul>
+ <li>
+ Developers&nbsp;who will implement a solution based on the design.
+ </li>
+ <li>
+ An&nbsp;architect who can review the design to ensure that it conforms to the architecture or who might examine the
+ design for opportunities to improve the architecture.
+ </li>
+ <li>
+ Other designers who can examine the design for applicability to other parts of the system.
+ </li>
+ <li>
+ Developers or other designers who will be working on other parts of the system that will&nbsp;depend on the
+ elements designed in this task.
+ </li>
+ <li>
+ Other reviewers&nbsp;who will review the design for quality and adherence to standards.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <purpose><p>
+ The purpose of&nbsp;this&nbsp;task&nbsp;is to describe the&nbsp;elements of the system so that they support the
+ required behavior, are of high quality, and fit within the architecture.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/design_solution_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/design_solution_vm.xmi
new file mode 100644
index 0000000..839d1cc
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/design_solution_vm.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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="-_BAmniONtHWbpHQH7znR3g" name=",_T8WvwL3vEdqLRJZPGVbHDA" guid="-_BAmniONtHWbpHQH7znR3g"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/detail_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/detail_requirements.xmi
new file mode 100644
index 0000000..2cf5df4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/detail_requirements.xmi
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_Nqwi8KeqEdmKDbQuyzCoqQ" name="detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw" guid="_Nqwi8KeqEdmKDbQuyzCoqQ" changeDate="2006-09-29T15:31:25.226-0700" version="1.0.0">
+ <sections xmi:id="_vWeHMCxSEdqjsdw1QLH_6Q" name="Detail Use Cases and Scenarios" guid="_vWeHMCxSEdqjsdw1QLH_6Q">
+ <sectionDescription><p>
+ Some <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s and Scenarios may need to be described in more detail to validate our
+ understanding of the requirement and to permit software development to begin. This does not imply that all&nbsp;use
+ cases and scenarios&nbsp;will be detailed prior to commencing implementation.&nbsp;&nbsp;Work with stakeholders to
+ detail only those that are prioritized for implementation in the next iteration or two (see <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>), or those that are deemed architecturally significant
+ (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>.)
+</p>
+<p>
+ The level of detail captured will vary depending upon the needs of the project and the complexity of the use
+ case.&nbsp; For a discussion of the different levels of detail that may be applicable see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
+</p>
+<p>
+ Capture the use case&nbsp;details in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>.&nbsp; For additional information on detailing use cases and scenarios, see&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.&nbsp; For assistance in assessing the
+ quality of your use cases see <a class="elementLinkWithType" href="./../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html" guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_B47VwCxTEdqjsdw1QLH_6Q" name="Detail supporting requirements" guid="_B47VwCxTEdqjsdw1QLH_6Q">
+ <sectionDescription><p>
+ Some&nbsp;<a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a> may need to be clarified or described in more detail, new
+ requirements&nbsp;may have been discovered as we detailed the use cases and scenarios, and new requirements may have
+ been submitted as <a class="elementLink" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a>.&nbsp;Work with stakeholders to capture, refine and validate those
+ requirements that will have an impact on near term work (see <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>) or are deemed architecturally significant (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>).
+</p>
+<p>
+ Capture these requirements in&nbsp;the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>.&nbsp; For additional guidance on detailing
+ supporting requirements see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q.html" guid="_wr24gNcGEdqz_d2XWoVt6Q">Guideline: Supporting Requirements</a>.&nbsp; For assistance in assessing the quality of
+ your supporting requirements see <a class="elementLinkWithType" href="./../../openup_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.html" guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_2389cOz2Edq2wJOsmRwmhg" name="Detail glossary terms" guid="_2389cOz2Edq2wJOsmRwmhg">
+ <sectionDescription>Review the use case&nbsp;flow of events. If information is exchanged, be specific about what is passed back and
+forth.&nbsp; Work with stakeholders to ensure that you define newly discovered domain terms, or ambiguous
+terms&nbsp;properly in the <a class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a>.
+If your understanding of the domain has improved,&nbsp;refine existing glossary terms.</sectionDescription>
+ </sections>
+ <sections xmi:id="_BYbboN-bEdqiM_wFaqLjNg" name="Achieve concurrence" guid="_BYbboN-bEdqiM_wFaqLjNg">
+ <sectionDescription>Conduct a review&nbsp;of the&nbsp;requirements (<a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>)&nbsp;with relevant&nbsp;<a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> and the development team to ensure consistency with the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>, assess quality, and identify required changes. See&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <purpose><p>
+ The purpose of this task is to describe one or more requirements&nbsp;in sufficient detail to validate understanding of
+ the requirement, to ensure concurrence with stakeholders expectations, and to permit software development&nbsp;to
+ begin.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/detail_requirements_intent_req_ucm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/detail_requirements_intent_req_ucm.xmi
new file mode 100644
index 0000000..0ecdb48
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/detail_requirements_intent_req_ucm.xmi
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-_mfd9ziTwQV_5LE80jJw4g" name="detail_requirements_ucm,_7_3vEAFmEduDPKiaP0pu-Q" guid="-_mfd9ziTwQV_5LE80jJw4g" version="1.0.0">
+ <sections xmi:id="_w2JYgEf6EduISP1GQDlvVQ" name="Update Use-Case Model" guid="_w2JYgEf6EduISP1GQDlvVQ">
+ <sectionDescription>Based on your work update the <a class="elementLink"
+href="./../../openup_basic/workproducts/uc_model,_W2SgEDR5EdutE_HNDTJk5Q.html" guid="_W2SgEDR5EdutE_HNDTJk5Q">Use-Case
+Model</a>.&nbsp; Add, remove or update&nbsp;<a class="elementLinkWithUserText"
+href="./../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a>
+and <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s as required.&nbsp; For more information on creating and structuring your use
+case model see <a class="elementLinkWithType"
+href="./../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html"
+guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>.&nbsp; For assistance in assessing the quality of your use
+case model see <a class="elementLinkWithType"
+href="./../../openup_basic/guidances/checklists/uc_model,_0U6OEMlgEdmt3adZL5Dmdw.html"
+guid="_0U6OEMlgEdmt3adZL5Dmdw">Checklist: Use-Case Model</a>.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/develop_arch.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/develop_arch.xmi
new file mode 100644
index 0000000..8ee19e1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/develop_arch.xmi
@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_rUis8LBKEdm7Eph_l9Cn9w" name="refine_architecture,_0gRJgMlgEdmt3adZL5Dmdw" guid="_rUis8LBKEdm7Eph_l9Cn9w" changeDate="2007-03-03T21:40:43.468+0000" version="1.0.0">
+ <mainDescription><p>
+ This task&nbsp;builds on&nbsp;the work&nbsp;performed during <a class="elementLink"
+ href="./../../openup_basic/tasks/analyze_arch_reqs,_0f-1oMlgEdmt3adZL5Dmdw.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Analyze
+ the Architectural Requirements</a>&nbsp;to produce a concrete approach for the main development work to follow.
+</p>
+<p>
+ The objective is to resolve the overarching issues which affect the design and development activity for the current
+ iteration. These are:
+</p>
+<ul>
+ <li>
+ To specify&nbsp;common mechanisms or patterns to be used.
+ </li>
+ <li>
+ To&nbsp;specify what use will be made of existing software assets and how they will integrate with the overall
+ solution.
+ </li>
+ <li>
+ To&nbsp;specify what new software needs to be developed.
+ </li>
+ <li>
+ To ensure that the appropriate hardware and software resources are&nbsp;specified to support the development and
+ testing of the solution.
+ </li>
+ <li>
+ To ensure that the architecture is useful to and used by the project team.
+ </li>
+</ul>
+<p>
+ The technical decisions&nbsp;taken as part of this task&nbsp;are concrete and unambiguous. Capture architectural
+ decisions in the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. Make sure that this is communicated across the team.
+</p>
+<p>
+ This task is applied iteratively; iterations after the first will need to take account of the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;and <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>&nbsp;products that have been developed so far.
+</p></mainDescription>
+ <keyConsiderations><p>
+ The architect should perform this task&nbsp;through collaboration with the whole&nbsp;team to promote consensus and a
+ common understanding of the overall solution. The architect should be working to coordinate and guide the technical
+ activities of the team, rather than seeking to do all the work alone.&nbsp;The architect should place emphasis&nbsp;on
+ involving&nbsp;the developer(s) throughout this task.
+</p></keyConsiderations>
+ <sections xmi:id="_P28vkMP3EdmWKcx6ixEiwg" name="Identify architectural priorities" guid="_P28vkMP3EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Determine&nbsp;the&nbsp;priorities for this iteration of&nbsp;architecture work.&nbsp;Balance the objectives for the
+ current iteration against the overall project objectives, ensuring that the architecture can support current and future
+ needs.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_0qoQ8CikEduQBKSg5n118w" name="Refine architectural mechanisms" guid="_0qoQ8CikEduQBKSg5n118w">
+ <sectionDescription><p>
+ Refine&nbsp;each architectural mechanism into a <a class="elementLink"
+ href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a> by looking at the requirements in the context of the current
+ iteration. Include each architecturally significant&nbsp;scenario in scope. Look for commonality across scenarios and
+ propose common components and patterns for their solution. Work with the developers and analysts&nbsp;to gain consensus
+ on&nbsp;the architecture mechanisms.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_QtKuoCilEduQBKSg5n118w" name="Identify business patterns" guid="_QtKuoCilEduQBKSg5n118w">
+ <sectionDescription><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ The architecture of the system can often be best&nbsp;communicated by showing how it handles important areas business
+ behaviour.
+</p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ See <a class="elementLink" href="./../../openup_basic/guidances/concepts/business_pattern,_Z53x0BapEduSTJywppIxVQ.html"
+ guid="_Z53x0BapEduSTJywppIxVQ">Business Pattern</a>. Work with the stakeholders to assure the business patterns are
+ based on&nbsp;sound knowledge.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Vdln8MP3EdmWKcx6ixEiwg" name="Identify reuse opportunities" guid="_Vdln8MP3EdmWKcx6ixEiwg">
+ <sectionDescription><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Leverage reuse of existing components by evaluating their interfaces and the behavior that they provide. Reuse
+ components when their interfaces are similar or match the interfaces of components you would need to develop from
+ scratch. If not similar, modify the newly identified interfaces so you improve the fit with existing components
+ interfaces.
+</p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Work with developers to gain consensus on the suitability of using existing components.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_G_k1kBaqEduSTJywppIxVQ" name="Identify architecturally significant design elements" guid="_G_k1kBaqEduSTJywppIxVQ">
+ <sectionDescription><p align="left">
+ Refine the key abstractions to decide on the important design elements (such as classes and&nbsp;subsystems)&nbsp;that
+ make up the architecture, and provide at least a name and brief description for each. Add them to the <a
+ class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Gain consensus with the developers on architecturally significant design
+ choices.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xIIVkMUbEdu5GrwIlTJV7g" name="Map the software to the hardware" guid="_xIIVkMUbEdu5GrwIlTJV7g">
+ <sectionDescription>Map the architecturally significant design elements to the target deployment environment. Work with hardware and network
+specialists to ensure that the hardware is sufficient to meet the needs of the system; and that any new hardware is
+available in time.</sectionDescription>
+ </sections>
+ <sections xmi:id="_LsyLkBaqEduSTJywppIxVQ" name="Define development architecture and test architecture" guid="_LsyLkBaqEduSTJywppIxVQ">
+ <sectionDescription><p>
+ Ensure that the development and test architectures are defined.&nbsp;Note any architecturally significant differences
+ between these environments and work with the team to devise strategies to mitigate any risks these may introduce.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Zlw-QMP3EdmWKcx6ixEiwg" name="Validate the architecture" guid="_Zlw-QMP3EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Verify that the architecture decisions are appropriate for their purpose.&nbsp;
+</p>
+<p>
+ Development work should be performed to&nbsp;produce a&nbsp;<a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>
+ that shows that the software architecture is viable. This should provide the definitive basis for validating the
+ suitability&nbsp;of the architecture.&nbsp;As the software&nbsp;should be developed iteratively, more than one
+ increment of the build may be required to prove the architecture.&nbsp;During the early stages of the project (up to
+ the end of <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA">Elaboration</a>), it may be&nbsp;acceptable for the software to have a incomplete or
+ prototypical feel, as it&nbsp;will be&nbsp;primarily concerned with baselining the architecture to provide a stable
+ foundation for the&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA">Construction</a> phase.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_aRCI0MP3EdmWKcx6ixEiwg" name="Communicate decisions" guid="_aRCI0MP3EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Ensure that those who need to act upon the architectural work&nbsp;understand&nbsp;it and are able to work with
+ it.&nbsp;Make sure that the description of the architecture clearly conveys not only the solution but also the
+ motivation and objectives related to the&nbsp;decisions that have been made in shaping the architecture. This will make
+ it easier for others to understand the architecture and to adapt it over time.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ Provide a skeletal design to enable more&nbsp;comprehensive design activities to be performed coherently by the team.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/find_and_outline_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/find_and_outline_requirements.xmi
new file mode 100644
index 0000000..79bd9e3
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/find_and_outline_requirements.xmi
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_P9iS8PV_EdmdHa9MmVPgqQ" name="find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ" guid="_P9iS8PV_EdmdHa9MmVPgqQ" changeDate="2006-09-29T15:32:02.476-0700" version="1.0.0">
+ <keyConsiderations>Close collaboration with stakeholders on this task is critical for the success of project.</keyConsiderations>
+ <sections xmi:id="_ckG-cCY-EdqNHcQ-rAojXw" name="Gather information" guid="_ckG-cCY-EdqNHcQ-rAojXw">
+ <sectionDescription><p>
+ Be prepared by gathering and reviewing information related to the problem domain, problem statement, business
+ environment and key stakeholders.&nbsp; Most of this information should be available in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>.&nbsp;&nbsp;You can use various techniques to make gathering
+ requirements easier. Face-to-face meetings with stakeholders is the most effective way to understand stakeholder needs
+ and to gather and validate requirements, but you&nbsp;must prepare in order for&nbsp;these meetings to run efficiently.
+ See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html" guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>&nbsp;for more information.&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_GAr3IOz3Edq2wJOsmRwmhg" name="Identify and capture domain terms" guid="_GAr3IOz3Edq2wJOsmRwmhg">
+ <sectionDescription>Work closely with stakeholder to make sure that ambiguous or domain-specific terms are clearly defined in the&nbsp;<a class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> and that you use these terms consistently.</sectionDescription>
+ </sections>
+ <sections xmi:id="_fDbgkCY-EdqNHcQ-rAojXw" name="Capture requirements" guid="_fDbgkCY-EdqNHcQ-rAojXw">
+ <sectionDescription>Identify the types of requirements relevant to your system (see <a class="elementlinkwithtype" href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>).
+<p>
+ Work with stakeholders to identify and capture&nbsp;the actors and Use Cases. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for more information.
+</p>
+<p>
+ Work with stakeholders to identify and capture&nbsp;the other types of requirements relevant&nbsp;to your system. See
+ <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q.html" guid="_wr24gNcGEdqz_d2XWoVt6Q">Guideline: Supporting Requirements</a>&nbsp;for more information.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_0WhHsN-eEdqiM_wFaqLjNg" name="Achieve concurrence" guid="_0WhHsN-eEdqiM_wFaqLjNg">
+ <sectionDescription>Conduct a review&nbsp;of the&nbsp;requirements with relevant <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>
+and the development team to ensure consistency with the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>,
+assess quality, and identify any required changes. See&nbsp;&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Mgb9IC4DEduBP8F-6-95NQ" name="Update the Work Items List" guid="_Mgb9IC4DEduBP8F-6-95NQ">
+ <sectionDescription>Capture references to the requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>, so that you can prioritize the work.</sectionDescription>
+ </sections>
+ <purpose>The purpose of this task is to understand Stakeholder requirements and communicate these to the development team.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.xmi
new file mode 100644
index 0000000..dc638ce
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.xmi
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-Yt8TXGkE1rwydXR34apsrg" name=",_txpV0AFmEduDPKiaP0pu-Q" guid="-Yt8TXGkE1rwydXR34apsrg" version="1.0.0">
+ <sections xmi:id="_XRKgkAFoEduDPKiaP0pu-Q" name="Capture Use Case and Actors in a Use-Case Model" guid="_XRKgkAFoEduDPKiaP0pu-Q">
+ <sectionDescription><p>
+ While capturing requirements, it may be useful to identify and capture the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use
+ Case</a>s and&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a>&nbsp;in a <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/uc_model_intent_req_ucm,_0UCrZclgEdmt3adZL5Dmdw.html"
+ guid="_0UCrZclgEdmt3adZL5Dmdw">Use-Case Model</a>. That can help people better understand the proposed system
+ functionality and its&nbsp;surroundings. See <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for more details.
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/impl_developer_tests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/impl_developer_tests.xmi
new file mode 100644
index 0000000..c35f0fe
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/impl_developer_tests.xmi
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_dWPe8KrMEdmqUqi7YGiSxw" name="impl_developer_tests,_0iL1EMlgEdmt3adZL5Dmdw" guid="_dWPe8KrMEdmqUqi7YGiSxw" changeDate="2007-01-15T17:54:27.434-0500" version="1.0.0">
+ <mainDescription><p>
+ Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
+ rather than being directly based on the system requirements.
+</p>
+<p>
+ It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
+ course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
+ etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
+ additional behavior.
+</p></mainDescription>
+ <keyConsiderations><ol>
+ <li>
+ Automate tests via a unit regression testing tool (for example, xUnit) so that tests may be run by developers
+ whenever they make changes to the code.
+ </li>
+ <li>
+ Test to the risk of the component. For example, the more critical a component is, the more important it is to test
+ it thoroughly.
+ </li>
+ <li>
+ Pair with the <a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html"
+ guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> in all steps of this task to gain insight on testing and quality
+ considerations.
+ </li>
+</ol></keyConsiderations>
+ <sections xmi:id="_2LYo8KuPEdmhFZtkg1nakg" name="Refine scope and identify the test(s)" guid="_2LYo8KuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Select the increment of work to be tested and identify developer test(s) to verify that the <a class="elementLink"
+ href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html"
+ guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> being developed behaves correctly. One source for the expected
+ behavior for a software component is the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>.&nbsp;
+</p>
+<p>
+ In identifying the&nbsp;tests or in any other part of this task, consider collaborating with a <a class="elementLink"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> who
+ should be well-versed in the issues of testing.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_g8npoC5UEduVhuZHT5jKZQ" name="Write the test setup" guid="_g8npoC5UEduVhuZHT5jKZQ">
+ <sectionDescription>To successfully run a test the system must be in a known state so that the correct behavior can be defined. Implement the
+setup logic that must be performed as part of the <a class="elementLink"
+href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
+guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>.</sectionDescription>
+ </sections>
+ <sections xmi:id="_g1eDUC5VEduVhuZHT5jKZQ" name="Define the expected results" guid="_g1eDUC5VEduVhuZHT5jKZQ">
+ <sectionDescription><p>
+ Define the expected results of each test so that it can be verified.
+</p>
+<p>
+ After a test runs, you need to be able to compare the results of running the test against what was expected to happen.
+ The test is successful when the actual results match the expected results.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_5WtVcKuPEdmhFZtkg1nakg" name="Write the test logic" guid="_5WtVcKuPEdmhFZtkg1nakg">
+ <sectionDescription>Write the steps that perform the actual test(s).</sectionDescription>
+ </sections>
+ <sections xmi:id="_j30aAC5VEduVhuZHT5jKZQ" name="Define the test response" guid="_j30aAC5VEduVhuZHT5jKZQ">
+ <sectionDescription>Define the information the test(s) must produce to successfully indicate success or failure. Consider if a response of True
+or False is sufficient, or if a detailed message should be logged as well.</sectionDescription>
+ </sections>
+ <sections xmi:id="_ku06gC5VEduVhuZHT5jKZQ" name="Write clean-up code" guid="_ku06gC5VEduVhuZHT5jKZQ">
+ <sectionDescription>Identify, and then implement, the steps to be followed in order to restore the environment to the original state for each
+test. The goal is to ensure that there are no side effects from running the tests.</sectionDescription>
+ </sections>
+ <sections xmi:id="_6wZFMKuPEdmhFZtkg1nakg" name="Test the test" guid="_6wZFMKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Verify that each developer test works correctly. To do this:
+</p>
+<ul>
+ <li>
+ Run the test(s), observe their behavior, and fix any defects in the tests.
+ </li>
+ <li>
+ Ensure that the expected results are defined properly and that they're being checked correctly.
+ </li>
+ <li>
+ Check the clean-up logic for each test.
+ </li>
+ <li>
+ Ensure that each developer test works within your test suite framework.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <purpose>Prepare to validate a software component (e.g. an operation, a class, a stored procedure) through unit testing. The result
+is one or more new developer tests.</purpose>
+ <alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
+developer testing in identifying bugs and finding their location in the code.</alternatives>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/implement_solution.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/implement_solution.xmi
new file mode 100644
index 0000000..6e10293
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/implement_solution.xmi
@@ -0,0 +1,159 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_d2aMwKrMEdmqUqi7YGiSxw" name="implement_solution,_0hyzgMlgEdmt3adZL5Dmdw" guid="_d2aMwKrMEdmqUqi7YGiSxw" authors="Jim Ruehlin" changeDate="2006-09-27T18:31:00.562-0700" version="1.0">
+ <mainDescription><p>
+ Usually, this task is focused on a specific element, such as a class or component, but it does not need to be.
+</p>
+<p>
+ You implement a portion of the design during each iteration by performing this task. You can perform the task any
+ number of times during an iteration.
+</p>
+<p>
+ Modify the implementation incrementally. Make additions and changes to the implementation for an issue, run the unit
+ and regression tests, and then complete the issue before moving on to other issues.
+</p>
+<p>
+ See the associated guidelines for information on how to perform the steps described in this task.
+</p></mainDescription>
+ <keyConsiderations><p>
+ This task is complete once the build has successfully completed. The implementation should then be immediately tested.
+</p></keyConsiderations>
+ <sections xmi:id="_2sxisE2iEduU655MA_3VXg" name="Determine a strategy" guid="_2sxisE2iEduU655MA_3VXg">
+ <sectionDescription><p>
+ You need to determine a strategy, based on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;of the work item being worked on, for how you're going to implement it.
+ Your fundamental options are:
+</p>
+<ol>
+ <li>
+ Apply existing, reusable assets.
+ </li>
+ <li>
+ Model the design in detail and generate the source code (by model transformation).
+ </li>
+ <li>
+ Write the source code.
+ </li>
+ <li>
+ Any combination thereof.
+ </li>
+</ol></sectionDescription>
+ </sections>
+ <sections xmi:id="_iMMWoKuPEdmhFZtkg1nakg" name="Identify opportunities for reuse" guid="_iMMWoKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Complete the implementation by reusing code at every opportunity.
+</p>
+<p>
+ Identify existing code or other implementation elements that you can reuse in the portion of the <a class="elementLink" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a>&nbsp;that you are creating or changing. A comprehensive understanding
+ of the overall design is helpful, because it is best to leverage reuse opportunities when you have a thorough
+ understanding of the proposed solution.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_pjehkNb7Edq_LtLvi4w2yw" name="Transform design into implementation" guid="_pjehkNb7Edq_LtLvi4w2yw">
+ <sectionDescription><p>
+ If you are using sophisticated modeling tools, you should be able to generate a portion of the required source code
+ from the model.&nbsp;Note that programming is often required to complete the implementation after the design
+ model&nbsp;has been transformed into code.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_mFQ58KuPEdmhFZtkg1nakg" name="Write source code" guid="_mFQ58KuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ You should strive to reuse and/or generate code wherever possible, but you will still need to do some
+ programming.&nbsp;To do so, consider the following:
+</p>
+<ul>
+ <li>
+ Examine the&nbsp;requirements. Because some requirements information does not translate directly into your design
+ you should examine the requirement(s) (potentially including both the <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) to ensure that they are fully realized in the
+ implementation.
+ </li>
+ <li>
+ Refactor your code to improve its design.&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>&nbsp;is a technique where you improve the quality of your code via
+ small changes.
+ </li>
+ <li>
+ Tuning the results of the existing implementation by improving performance, the user interface, security, and other
+ nonfunctional areas.
+ </li>
+ <li>
+ Adding missing details, such as completing the logic of operations or adding supporting classes and data structures
+ </li>
+ <li>
+ Handling boundary conditions.
+ </li>
+ <li>
+ Dealing with unusual circumstances or error states.
+ </li>
+ <li>
+ Restricting behavior (preventing users from executing illegal flows, scenarios, or combinations of options).
+ </li>
+ <li>
+ Adding critical sections for multi-threaded or re-entrant code.<br />
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_-0yzwDH4EduMqpUNhaTSRA" name="Create a build" guid="_-0yzwDH4EduMqpUNhaTSRA">
+ <sectionDescription><p>
+ Create a new <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>. This might involve simply running an existing build script and/or updating an
+ existing build script.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_ni25UKuPEdmhFZtkg1nakg" name="Evaluate the implementation" guid="_ni25UKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Verify that the implementation is fit for its purpose.&nbsp;Examine the code for its suitability to perform its
+ intended function. This is a quality assurance step that you perform in addition to testing, and it is described in
+ other tasks. Consider these strategies:
+</p>
+<ul>
+ <li>
+ Pair programming.&nbsp;By pairing to implement the code in the first place, you effectively evaluate the code as
+ its being written.
+ </li>
+ <li>
+ Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a
+ reminder reference.
+ </li>
+ <li>
+ Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or
+ set the compiler to the most detailed warning level.
+ </li>
+ <li>
+ Use tools that can visualize the code. Code visualization, such as the&nbsp;UML visualizations in the Eclipse IDE,
+ help developers identify issues such as excessive coupling or&nbsp;circular dependencies.
+ </li>
+ <li>
+ Perform informal, targeted code inspections. Ask colleagues to review&nbsp;small critical sections of code and code
+ with significant churn. Avoid reviewing large sections of code.
+ </li>
+ <li>
+ Use the Tester to assure the implementation is testable and understandable to testing resources.
+ </li>
+</ul>
+<p>
+ Improve the implementation based on the results of these evaluations.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_q5XiIKuPEdmhFZtkg1nakg" name="Communicate significant decisions" guid="_q5XiIKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Communicate the impact of unexpected changes to the design and requirements.
+</p>
+<p>
+ The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact
+ of issues discovered during implementation must be incorporated into future decisions. If appropriate, update use cases
+ and supporting requirements to reflect ambiguities that you identified and resolved in the implementation so they can
+ be tested and you can manage the <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>&nbsp;expectations appropriately. Similarly, update the design to reflect
+ new constraints and issues uncovered during implementation to be sure that the new information is communicated to other
+ developers.
+</p>
+<p>
+ Usually, there is no need for a change request if the required change is small and the same person is designing and
+ implementing the class. That individual can make the design change directly. If the required change has a broad impact,
+ such as a change in a public operation, it may be necessary to communicate that change to the other team members
+ through a change request.<br />
+ <br />
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to
+ fix one or more defects. The result is typically new or modified source code, which is generally referred to <em>the
+ implementation</em>.<br />
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/implement_tests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/implement_tests.xmi
new file mode 100644
index 0000000..485bb7c
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/implement_tests.xmi
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrbRUKeqEdmKDbQuyzCoqQ" name="implement_tests,_0jO98MlgEdmt3adZL5Dmdw" guid="_NrbRUKeqEdmKDbQuyzCoqQ" changeDate="2006-09-20T19:51:14.814-0400" version="1.0.0">
+ <sections xmi:id="_S8JzsKuSEdmhFZtkg1nakg" name="Select appropriate implementation technique" guid="_S8JzsKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Select one or several of the following test implementation&nbsp;techniques:
+</p>
+<ul>
+ <li>
+ manual test scripts
+ </li>
+ <li>
+ programmed test scripts
+ </li>
+ <li>
+ recorded test scripts
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_VN5M0KuSEdmhFZtkg1nakg" name="Implement the test" guid="_VN5M0KuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Using your test-ideas list and test cases as inputs, set up your specifications, spreadsheet, or&nbsp;automated
+ tool&nbsp;to record scripts needed to conduct the test.&nbsp;If you are recording explicit steps for your test,
+ navigate through the system under test identifying steps, groups of related steps, verification points, and control
+ points.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_WvBoYKuSEdmhFZtkg1nakg" name="Establish external data sets" guid="_WvBoYKuSEdmhFZtkg1nakg">
+ <sectionDescription>Create containers for your test data sets. Separate the production data from generated data. Associate your data sets with
+a given build of the system under test.&nbsp;If data sets are associated with a particular part of the system under test,
+mark them accordingly.</sectionDescription>
+ </sections>
+ <sections xmi:id="_X0dmcKuSEdmhFZtkg1nakg" name="Verify Test implementation" guid="_X0dmcKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Run the test script to verify that it implements the tests correctly. For manual testing,&nbsp;conduct a walkthrough of
+ the test script. For automated tests, verify that&nbsp;the test implementation will involve some degree of the
+ configuration of the testing tool.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Y-ABYKuSEdmhFZtkg1nakg" name="Organize tests into test suites" guid="_Y-ABYKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Collect tests into related groups. The grouping you use depends on your test environment. For example, you can organize
+ test cases, test scripts, and test data hierarchically to facilitate navigation within a test, as well as within the
+ suite. Another form of test suite organization is based on system functionality and uses the quality attributes of
+ usability, reliability, and performance as categories for groups.&nbsp;You may choose to follow an iteration-based test
+ suite organization, instead.&nbsp;Since the system under test is undergoing its own evolution, create your test suites
+ to facilitate regression testing, as well as system configuration identification.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ To implement one or more tests that can be executed to validate a system.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/manage_iteration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/manage_iteration.xmi
new file mode 100644
index 0000000..a3ca836
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/manage_iteration.xmi
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-PbfqVxB_j9KN-Jx39_pEUA" name="manage_iteration,_8S2aICbYEdqh1LYUOGRh2A" guid="-PbfqVxB_j9KN-Jx39_pEUA" changeDate="2006-08-31T06:45:37.803-0700" version="1.0.0">
+ <sections xmi:id="_OE65ICuxEdqTIKp3l5PtzQ" name="Capture status" guid="_OE65ICuxEdqTIKp3l5PtzQ">
+ <sectionDescription><p>
+ The project manager needs to continuously monitor the project to ensure its appropriate progress, and to enable the
+ team to react as soon as possible to any change. Many alternative means may be used to track the status:
+</p>
+<ul>
+ <li>
+ Quick, daily meetings with the entire project team, also called "scrum meetings” are useful to understand what team
+ members have accomplished since the&nbsp;last meeting, and what they plan to accomplish before the next meeting. It
+ also allows the team to identify any blocking issues. See <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[SCH04]</a>&nbsp;for guidance on scrum meetings.
+ </li>
+ <li>
+ Basic metrics, ideally automatically generated from the tools at hand, or manually assembled. The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>&nbsp;should outline which metrics the project should use.
+ Examples of such metrics include <a class="elementLinkWithType" href="./../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a>&nbsp;and <a class="elementLinkWithType" href="./../../openup_basic/guidances/reports/project_burndown,_ePrt8Dj3EduxovfWMDsntw.html" guid="_ePrt8Dj3EduxovfWMDsntw">Report: Project Burndown</a>&nbsp;charts, which are reports on the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. See also <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html" guid="_0mYYkMlgEdmt3adZL5Dmdw">Concept: Metrics</a>&nbsp;for more information.
+ </li>
+</ul>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_ztF0UCuxEdqTIKp3l5PtzQ" name="Communicate status" guid="_ztF0UCuxEdqTIKp3l5PtzQ">
+ <sectionDescription><p>
+ Communicating project status is as important as gathering it. Communication is usually done at two levels: the task
+ level and project level.
+</p>
+<ul>
+ <li>
+ <strong>Task Level – Communicated within the project team:</strong> status can be communicated through quick, daily
+ meetings. This allows you to combine the status capturing with the status communications.
+ </li>
+ <li>
+ <strong>Project Level – Communicated to the stakeholders and the project team:</strong> status is usually
+ communicated through core metrics rather than detailed information. This can be done through meetings, e-mail, or
+ Web publishing.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_oIZdkCbZEdqh1LYUOGRh2A" name="Handle exceptions and problems" guid="_oIZdkCbZEdqh1LYUOGRh2A">
+ <sectionDescription><p>
+ One of the project manager's key responsibilities is to know about the project team's problems and issues. The manager
+ needs to focus on problems that are blocking progress. A quick, daily meeting is usually a good way to monitor those
+ problems and issues.
+</p>
+<p>
+ Identify the cause and impact of problems and exceptions as they arise. Identify possible solutions for problems that
+ have an immediate impact on the short-term goals and objectives and identify who needs to be involved in implementing
+ the solution. Then, define the corrective actions and implement them.&nbsp;<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xiFJwCbZEdqh1LYUOGRh2A" name="Identify and manage risks" guid="_xiFJwCbZEdqh1LYUOGRh2A">
+ <sectionDescription><p>
+ Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. The
+ risk list should be revisited weekly, or as a minimum once per iteration, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;and <a class="elementLinkWithType" href="./../../openup_basic/workproducts/risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Artifact: Risk List</a>&nbsp;for more details. The entire team should be involved in
+ identifying and mitigating risk.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Br6VECuxEdqTIKp3l5PtzQ" name="Reprioritize work as needed" guid="_Br6VECuxEdqTIKp3l5PtzQ">
+ <sectionDescription>When a team is falling significantly behind, or critical problems occur, it may be necessary to reprioritize tasks to
+ensure that the team delivers a useful product increment by the end of the iteration, while maximizing stakeholder value.
+In these rare cases, the project manager should work with the team and stakeholders on revising the iteration plan and, as
+necessary, reduce the emphasis on less critical tasks.</sectionDescription>
+ </sections>
+ <purpose><p>
+ Identify blocking issues and/or opportunities early to take action and keep the project on track.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/plan_iteration.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/plan_iteration.xmi
new file mode 100644
index 0000000..48a9cc5
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/plan_iteration.xmi
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_Wk7noKe1EdmGSrcKGOYDGg" name="plan_iteration,_0keUEMlgEdmt3adZL5Dmdw" guid="_Wk7noKe1EdmGSrcKGOYDGg" changeDate="2006-09-07T19:29:53.219-0400">
+ <sections xmi:id="_CtKCMMBHEdqSgKaj2SZBmg" name="Define the iteration objectives" guid="_CtKCMMBHEdqSgKaj2SZBmg">
+ <sectionDescription><p>
+ At the beginning of an iteration, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a>&nbsp;works with the team to define 1-5 objectives. These objectives should be a refinement of the
+ iteration objectives found in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>, and should provide high-level direction to what should be
+ targeted for the iteration. The objectives should be driven based on <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>&nbsp;priorities, and&nbsp;will be revised as the iteration plan is finalized. The objectives are
+ usually defined as high-level capabilities or scenarios that need to be implemented and tested during the
+ iteration.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_307v0MMsEdmdo9HxCRR_Gw" name="Produce detailed plan" guid="_307v0MMsEdmdo9HxCRR_Gw">
+ <sectionDescription>The <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a> works with the rest of the team, and especially the project
+stakeholders,&nbsp;to identify the high-priority work items from the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to be addressed within the iteration. The high-level
+objectives provide guidance on what work items should be considered. The team should break down work items so they fit
+within the iteration as necessary. Actual effort to complete each Work Item should be estimated. When a team has decided to
+take on a Work Item, it will assign the work to one or several team members. Ideally, this is done by team members signing
+up to do the work, since this makes people motivated and committed to doing the job, but based on culture, you may instead
+have the project manager assign the work.</sectionDescription>
+ </sections>
+ <sections xmi:id="_7Hqr4MMsEdmdo9HxCRR_Gw" name="Define evaluation criteria" guid="_7Hqr4MMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ Each iteration should include testing as a part of the evaluation, and the test objectives and test cases needs to be
+ detailed. Other evaluation criteria may include successful demonstrations to key stakeholders, or favorable usage by a
+ small group of target users.<br />
+</p></sectionDescription>
+ </sections>
+ <purpose><p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ Develop a fine-grained plan for a single iteration, identifying the goals and evaluation criteria of an iteration
+ (usually the next one).
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/plan_the_project.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/plan_the_project.xmi
new file mode 100644
index 0000000..77f0332
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/plan_the_project.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_fPbdIKe2Edmzde8VFK5bxg" name="plan_the_project,_0lC70MlgEdmt3adZL5Dmdw" guid="_fPbdIKe2Edmzde8VFK5bxg" changeDate="2006-09-27T13:20:13.359-0700" version="1.0.0">
+ <sections xmi:id="_lrYj0MBAEdqSgKaj2SZBmg" name="Evaluate risks" guid="_lrYj0MBAEdqSgKaj2SZBmg">
+ <sectionDescription><p>
+ The project manager evaluates project risks with the team and updates the <a class="elementLink" href="./../../openup_basic/workproducts/risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Risk List</a>. The risk list will aid the team in prioritization of what to do in which iteration. Higher-ranked risks are
+ addressed in the earlier iterations.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_k1bY4MMsEdmdo9HxCRR_Gw" name="Determine project size and scope" guid="_k1bY4MMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ Analyze the size and the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>&nbsp;of the project, and whether it is realistic to deliver what is asked for
+ within the constraints of the project.
+</p>
+<p>
+ If the project is feature-driven, meaning that release criteria is defined as a set of features captured in the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, the team assesses the size of these work items, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. They then look at how many people they would need to
+ complete these work items, which gives them a ballpark understanding of project duration, staffing profile, and scope.
+</p>
+<p>
+ If the project instead is date-driven, the team assesses how much work can roughly be done in the time-frame given and
+ using the available team, captured as a candidate list of work items.
+</p>
+<p>
+ The end result of the two approaches is the same; a rough understanding of the size of the capabilities to be
+ delivered, the size of the team, and expected time of completion.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_OfFTEABjEdqHlpDr8LcRqg" name="Define length, number, and objectives of iterations" guid="_OfFTEABjEdqHlpDr8LcRqg">
+ <sectionDescription><p>
+ Determine iteration length, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>, or use 4 weeks as default iteration length. Use iteration length
+ to assess target velocity, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. Based on the target velocity and overall size of the
+ project, calculate the number of iterations required.
+</p>
+<p>
+ Determine 1-3 high-level objectives for each iteration. The goal is to create a high-level plan outlining how you can
+ build the resulting application in the given set of iterations. The plan will change as you learn more, so time-box
+ this analysis to a few hours or less. Use the Work Items List to outline what features to implement in what iteration,
+ putting top priority work items first. This can be done rapidly by leveraging expected velocity and size estimate of
+ work items.
+</p>
+<p>
+ Produce a brief summary of your analysis in your plan by documenting 1-3 objectives for each iteration. Do not commit
+ individual work items to the plan, since this will force too much re-planning. For some projects, you may have to wait
+ until after the first iteration until you can provide a meaningful plan at this level of detail.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_qcOtIE5dEdu3aqt7VHtzgw" name="Define phase milestones and refine iteration objectives" guid="_qcOtIE5dEdu3aqt7VHtzgw">
+ <sectionDescription><p>
+ Phases provide a focus for a team on meeting key management objectives, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>. For example the Elaboration phase should answer the question “Do
+ we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?”
+</p>
+<p>
+ With this in mind, the project manager determines the start and end dates of the phases and aligns the content of the
+ iterations with the perspective of the phase. Therefore the objectives of the iterations assigned to a phase, need to
+ map to the goals of its phase. The milestones, which guard the transition from one phase to another, will provide
+ checkpoints if these goals are satisfied.&nbsp; Revisit the plan to see if you should change the focus of iterations to
+ allow more rapid completion of&nbsp;certain phases.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_F2dQYABjEdqHlpDr8LcRqg" name="Map roles to team members" guid="_F2dQYABjEdqHlpDr8LcRqg">
+ <sectionDescription><p>
+ The project manager assigns project members (people) to roles according to a table like this:<br />
+ <br />
+</p>
+<table style="WIDTH: 227px; HEIGHT: 116px" cellspacing="2" cellpadding="2" width="227" border="2">
+ <tbody>
+ <tr>
+ <td>
+ <strong>Team Member&nbsp;</strong>
+ </td>
+ <td>
+ <strong>Analyst</strong>
+ </td>
+ <td>
+ <strong>Developer</strong>&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td>
+ John
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ <td>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Judy&nbsp;&nbsp;
+ </td>
+ <td>
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Jim&nbsp;
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<p>
+ The project manager needs to make sure that the roles are staffed according to skills and interests and that every role
+ is covered.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_toVK0E5fEdu3aqt7VHtzgw" name="Tune and get concurrence on the plan" guid="_toVK0E5fEdu3aqt7VHtzgw">
+ <sectionDescription>Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of the
+project and make adjustments as necessary.</sectionDescription>
+ </sections>
+ <purpose>To describe a roadmap that provides direction to the team and continually adapt it based on feedback and changes in the
+environment.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/request_change.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/request_change.xmi
new file mode 100644
index 0000000..84d1c16
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/request_change.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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="_Nr0S4KeqEdmKDbQuyzCoqQ" name="submit_change_request,_0mwzEclgEdmt3adZL5Dmdw" guid="_Nr0S4KeqEdmKDbQuyzCoqQ" changeDate="2005-07-07T14:57:19.105-0700">
+ <sections xmi:id="_qEkewKuoEdmEGLSmmpF1Sg" name="Gather change request information" guid="_qEkewKuoEdmEGLSmmpF1Sg">
+ <sectionDescription><p> Gather the information required to describe the change request. This should
+ include a description of the requested change, the reason for the change (defect
+ or enhancement), the&nbsp;artifact&nbsp;affected,
+ including&nbsp;the version, and&nbsp;the priority
+ of the change. If possible,&nbsp;provide an estimate of the effort required
+ to implement the change. </p></sectionDescription>
+ </sections>
+ <sections xmi:id="_r2aP0KuoEdmEGLSmmpF1Sg" name="Update the Work Item List" guid="_r2aP0KuoEdmEGLSmmpF1Sg">
+ <sectionDescription>Update the <a class="elementLinkWithType" href="./../../basic_unified_process/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
+Work Items List</a>&nbsp;to&nbsp;document the information
+that you gathered in the previous step.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/run_developer_tests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/run_developer_tests.xmi
new file mode 100644
index 0000000..d7547e8
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/run_developer_tests.xmi
@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_W6rc0Lv7EdmmUvZAZjqE3g" name="run_developer_tests,_0iYCUMlgEdmt3adZL5Dmdw" guid="_W6rc0Lv7EdmmUvZAZjqE3g" changeDate="2006-09-29T12:31:32.200-0400" version="1.0.0">
+ <keyConsiderations><p>
+ It is common to require that code pass all Developer tests before it can be delivered in an integrated build (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/promoting_builds,_SM4YIL6dEdqti4GwqTkbsQ.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Builds</a>).
+</p>
+<p>
+ Pair with the Tester during all steps of this task to gain insight on testing and quality considerations.
+</p></keyConsiderations>
+ <sections xmi:id="_MSnQsMP4EdmWKcx6ixEiwg" name="Run Developer Tests" guid="_MSnQsMP4EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Run the <a class="elementLink" href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>s. The procedure will vary, depending on whether the test is manual or
+ automated and whether additional test components are necessary,&nbsp;such as&nbsp;drivers or stubs.
+</p>
+<p>
+ To run the tests, you need to make sure that you have initialized the test environment with all necessary elements,
+ such as software, hardware, tools, data, and so on.
+</p>
+<p>
+ Automated tests will often update a <a class="elementLink"
+ href="./../../openup_basic/workproducts/test_log,_0ZlSsMlgEdmt3adZL5Dmdw.html" guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test
+ Log</a>&nbsp;which you can evaluate to determine where your tests went wrong.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_NkRF0MP4EdmWKcx6ixEiwg" name="Evaluate test execution" guid="_NkRF0MP4EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Evaluate the test execution by analyzing the test run.&nbsp;
+</p>
+<p>
+ Testing will&nbsp;complete either&nbsp;normally or abnormally.&nbsp; For correctly implemented tests, a normal
+ completion represents a passed test, though it could warrant additional examination of the test log to ensure&nbsp;the
+ test&nbsp;ran as expected.&nbsp; Abnormal termination could be premature termination or just a test that does not
+ complete as intended.
+</p>
+<p>
+ Review the test log to understand any reported failures, warnings, or unexpected results. The cause of the problem(s)
+ might be that the implementation element being tested is faulty, a problem with the developer tests, or a problem with
+ the environment.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_SXPFkMP4EdmWKcx6ixEiwg" name="Respond to test results" guid="_SXPFkMP4EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Determine the appropriate corrective action to recover from a "failed" developer test run. If the implementation
+ element under test is faulty, fix the problem if possible and rerun the tests. If the problem is serious and cannot be
+ immediately addressed, perform the task <a class="elementLink"
+ href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request
+ Change</a> to report the defect. If the developer test is faulty fix the test and rerun the tests. If there was a
+ problem with the environment,resolve it and then rerun&nbsp;the tests.
+</p>
+<p>
+ When the developer tests pass, communicate the results. If the passing of these tests represent completion of a
+ requirement, this could involve updating the status of something on the <a class="elementLink"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
+</p></sectionDescription>
+ </sections>
+ <purpose>To verify that the implementation works as specified.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/tasks/run_tests.xmi b/OpenUP/OpenUP_PT/library/openup_basic/tasks/run_tests.xmi
new file mode 100644
index 0000000..4e4a802
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/tasks/run_tests.xmi
@@ -0,0 +1,165 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrbRUqeqEdmKDbQuyzCoqQ" name="run_tests,_0jVEkMlgEdmt3adZL5Dmdw" guid="_NrbRUqeqEdmKDbQuyzCoqQ" changeDate="2006-12-07T16:24:24.839-0500" version="1.0.0">
+ <mainDescription>Run the system test, which addresses functional and system integration tests and, potentially, user acceptance tests.</mainDescription>
+ <keyConsiderations><ul>
+ <li>
+ Run the test regularly. Ideally, that means whenever the code changes but, minimally, once a day.
+ </li>
+ <li>
+ It should be possible for anyone on the test team to run the test at any time.
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_fR4aQKuSEdmhFZtkg1nakg" name="Schedule test execution" guid="_fR4aQKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Run&nbsp;the system tests as often as possible. Ideally, run&nbsp;the tests whenever new code is checked into&nbsp;the
+ version control tool.
+</p>
+<p>
+ For larger systems, this will be too expensive.&nbsp;The tests may take several hours to run; therefore, you'll need to
+ schedule tests less frequently. If possible, however, run the tests several times a day. As a minimum,
+ run&nbsp;automated tests each night.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_gV408KuSEdmhFZtkg1nakg" name="Run the test" guid="_gV408KuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Run the test at the scheduled time based on the instructions in the <a class="elementLink" href="./../../openup_basic/workproducts/test_script,_0ZfMEMlgEdmt3adZL5Dmdw.html" guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test Script</a>. It is best that the script&nbsp;be automated.
+</p>
+<p>
+ Good practices:
+</p>
+<ol>
+ <li>
+ Run the test in a separate test environment.
+ </li>
+ <li>
+ Ensure that you run the test against the latest clean build.
+ </li>
+ <li>
+ The first step of the test should be to set up the test environment (ensure that the network is available, that the
+ test database is available and reset to a known state, and so on).
+ </li>
+</ol></sectionDescription>
+ </sections>
+ <sections xmi:id="_hfVJQKuSEdmhFZtkg1nakg" name="Close test run" guid="_hfVJQKuSEdmhFZtkg1nakg">
+ <sectionDescription>Close the actual run as the last step of running the test.&nbsp;To do this:
+<ol>
+ <li>
+ Close the test logs. The&nbsp;test log files should be closed and placed in the appropriate folder or directory.
+ </li>
+ <li>
+ Announce results. Send a notice to everyone involved in the project informing them of the result of the test run
+ and where they can find the test logs.
+ </li>
+</ol></sectionDescription>
+ </sections>
+ <sections xmi:id="_sQaC4DO2EduqsLmIADMQ9g" name="Examine the test log" guid="_sQaC4DO2EduqsLmIADMQ9g">
+ <sectionDescription><p>
+ Collect and compile information from test execution logs so you can:
+</p>
+<ul>
+ <li>
+ Capture the high-impact and risk issues discovered in running the tests.
+ </li>
+ <li>
+ Identify errors in test creation, data inputs, or integrating applications and any architectural anomalies.
+ </li>
+ <li>
+ Isolate the target of the test to determine failure points.
+ </li>
+ <li>
+ Diagnose failure symptoms and characteristics.
+ </li>
+ <li>
+ Assess and identify possible solutions.
+ </li>
+</ul>
+<p>
+ After completing these steps, verify that you have enough details to determine the impact of the results. In addition,
+ make sure that enough information exists to assist individuals who are performing dependent tasks.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_0XzAwDO2EduqsLmIADMQ9g" name="Identify failures and propose solutions" guid="_0XzAwDO2EduqsLmIADMQ9g">
+ <sectionDescription><p>
+ Identify whether or not the test has failed and propose a solution based on the type of test and category of
+ failure.&nbsp; The approach to testing will determine the identified failures and candidates for solutions.
+</p>
+<p>
+ Tests that are programmer supporting are used to help prepare and ensure confidence in the code.&nbsp;When identifying
+ failures and proposing solutions for programmer supporting tests:
+</p>
+<ul>
+ <li>
+ Failures will be identified at an object or element level.
+ </li>
+ <li>
+ Solutions will be to help clarify the problem.
+ </li>
+</ul>
+<p>
+ Test that are business supporting are used to uncover prior mistakes and omissions.
+</p>
+<ul>
+ <li>
+ Failures will identify omissions in requirements.
+ </li>
+ <li>
+ Solutions will help to clarify expectations of the system.
+ </li>
+</ul>
+<p>
+ After you have this information and the steps proposed to resolve the failures, you can effectively categorize the type
+ of failure and the appropriate type of solution.
+</p>
+<p>
+ See <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[MAR03]</a> for more information.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_3t6oADO2EduqsLmIADMQ9g" name="Communicate test results" guid="_3t6oADO2EduqsLmIADMQ9g">
+ <sectionDescription><p>
+ Communicate the test results to the team. For failed tests this might involve adding bugs to the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
+</p>
+<p>
+ Communicating test results can affect the perception of the effectiveness of the tests. When communicating test
+ results, it is important that you:
+</p>
+<ul>
+ <li>
+ Know the audience, so that appropriate information is communicated appropriately
+ </li>
+ <li>
+ Run tests or scenarios that are likely to uncover the high-impact and risk issues or represent actual use of the
+ system
+ </li>
+</ul>
+<p>
+ When preparing test result reports, answer the following questions:
+</p>
+<ul>
+ <li>
+ How many test cases exist, and what are their states (pass, fail, blocked, and so on)?
+ </li>
+ <li>
+ How many bug reports have been filed, and what are their states (open, assigned, ready for testing, closed,
+ deferred)?
+ </li>
+ <li>
+ What trends and patterns do you see in test case and bug report states, especially opened and closed bug reports
+ and passed and failed test cases?
+ </li>
+ <li>
+ For test cases that were blocked or skipped, why are they in this state?
+ </li>
+ <li>
+ Considering all test cases not yet run (and perhaps not even created yet), what key risks and areas of
+ functionality remain untested?
+ </li>
+ <li>
+ For failed test cases, what are the associated bug reports?
+ </li>
+ <li>
+ For bug reports ready for confirmation testing, when can your team perform the test?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <purpose>To execute tests and evaluate the test results.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/architecture_notebook.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/architecture_notebook.xmi
new file mode 100644
index 0000000..e4cdfeb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/architecture_notebook.xmi
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_H4gOYKYTEdmvhNXG0Oc2uA" name="architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw" guid="_H4gOYKYTEdmvhNXG0Oc2uA" changeDate="2007-03-03T10:34:06.078+0000" version="1.0.0">
+ <mainDescription><p>
+ This artifact&nbsp;is a communication vehicle that tells Developers what pieces to build, as well as how those pieces
+ behave and interact with each other. It determines the project structure so that managers can plan the project. It also
+ gives whoever must maintain and change the architecture later their first glimpse of the system; and an understanding
+ of the motivation behind the important technical decisions.
+</p>
+<p>
+ This artifact focuses on specific aspects of the design, concentrating on structure, essential elements, key scenarios
+ and those aspects that have a lasting impact on system qualities such as performance, reliability, adaptability and
+ cost. It defines the set of mechanisms, patterns and styles that will guide the rest of the design, assuring its
+ integrity.
+</p>
+<p>
+ Architectural elements make excellent units of implementation, unit testing, integration, configuration management
+ and&nbsp;documentation. The organisation of the architecture can also help the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a> decide on the organisation of the team.
+</p></mainDescription>
+ <purpose><p>
+ To describe the essential part of the design of the system so the integrity and understandability of the system is
+ assured.
+</p></purpose>
+ <representationOptions><p>
+ The he architecture can be represented in many forms and from many viewpoints, depending on the needs of the project
+ and the preferences of the project team. The architecture can be expressed as a simple metaphor or as a comparison to a
+ predefined architectural style or set of styles. It may be a precise set of models or documents that describe the
+ various aspects of the system's key elements. Expressing it as skeletal build is another option - although this build
+ may need to be baselined and preserved to ensure that the essence of the system can be understood as the system grows.
+</p>
+<p>
+ It is frequently a design artifact that must be represented in a readable and accessible way. It can reference models
+ that describe <a class="elementLink"
+ href="./../../openup_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html"
+ guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>s for communicating the architecture. A view is a representation
+ of a system from the perspective of a related set of concerns.&nbsp;To choose the appropriate set of
+ views,&nbsp;identify the Stakeholders who depend on software architecture documentation and the information that they
+ need.
+</p>
+<p>
+ It need not be a formal document. The essence of the architecture can often be communicated through a series of simple
+ diagrams on a whiteboard; or as a list of decisions. Choose the medium that best meets the needs of the project.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/build.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/build.xmi
new file mode 100644
index 0000000..d6e11e4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/build.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqSB0KeqEdmKDbQuyzCoqQ" name="build,_0YuXEMlgEdmt3adZL5Dmdw" guid="_NqSB0KeqEdmKDbQuyzCoqQ" changeDate="2007-01-30T15:24:06.639-0500">
+ <mainDescription><p>
+ This working version of the system is the result of putting the implementation of the system through a build process
+ (typically an automated build script) that creates an executable version of the system, or one that runs.&nbsp; This
+ executable version of the system will typically have a number of supporting files that are also considered part of this
+ composite artifact.
+</p></mainDescription>
+ <keyConsiderations><p>
+ In an iterative lifecycle, each build must evolve from the previous iteration's build, adding more functionality and
+ improving quality.
+</p>
+<p>
+ The purpose of early builds that minimize or eliminate a risk or verify architectural decisions is to achieve
+ consistently stable builds in later iterations.
+</p></keyConsiderations>
+ <purpose>Deliver incremental value to the user and customer, and provide a testable artifact for verification.</purpose>
+ <reasonsForNotNeeding><p>
+ There will always need to be an&nbsp;operational version of the system.
+</p></reasonsForNotNeeding>
+ <representationOptions><p>
+ This work product is&nbsp;almost always a composite product made up of numerous parts required to make the executable
+ system. Therefore a build is more than just executable files; it additionally includes such things as configuration
+ files, help files, and data repositories that will be put together resulting in the product that will be run by the
+ users. The specifics of those parts will vary by technology in use.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/design.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/design.xmi
new file mode 100644
index 0000000..01bbce6
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/design.xmi
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" name="design,_0WuL8slgEdmt3adZL5Dmdw" guid="_zxB-QKYcEdmvhNXG0Oc2uA" changeDate="2007-03-03T07:48:41.814-0500" version="1.0.0">
+ <mainDescription><p>
+ This product can describe multiple static and dynamic views of the system for examination. Although various views may
+ focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit
+ together without contradiction.
+</p>
+<p>
+ It describes the elements that will make up the implemented system. It communicates abstractions of particular portions
+ of the implementation and can describe an&nbsp;encapsulated subsystem, a high-level analysis of the system, a view of
+ the system in only one context, or other perspectives that explain a solution to a specific problem that needs to be
+ communicated.
+</p></mainDescription>
+ <purpose><p>
+ Describe the&nbsp;elements of the system&nbsp;so&nbsp;they can be examined and understood in ways not&nbsp;possible by
+ reading the source code.
+</p></purpose>
+ <impactOfNotHaving><p>
+ Implementation will proceed with fine-grained, inconsistent tactical decisions that lead to poor-quality software.
+</p></impactOfNotHaving>
+ <reasonsForNotNeeding>Some representation of the design will always be necessary. In circumstances where a project involves applying
+well-understood, existing strategies for architecture and design, it is possible that you will not need a <em>new</em>
+design. In those cases, you can simply refer to some existing design.</reasonsForNotNeeding>
+ <representationOptions><p>
+ It is important that the author of this work product be able to analyze key decisions about the structure and behavior
+ of the system and communicate them to other collaborators. It is also important that these decisions can be
+ communicated at various levels of abstraction and granularity. Some aspects of the design can be represented by source
+ code, possibly with some extra annotations. But more abstract representations of the design will be at a higher-level
+ than source code.
+</p>
+<p>
+ The more abstract representation could use various representation options. UML could be used either strictly or
+ informally; it is a preferred notation based on its rich semantics and broad usage in the industry. Other techniques
+ could be used to communicate the design. Or the design could use a mix of techniques as applicable.
+</p>
+<p>
+ Whether you record these representations on a white board or use a formal tool is not governed by this process. But any
+ representation, whether characterized as formal or informal, should unambiguously communicate the technical decisions
+ embodied by the design.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/design_vm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/design_vm.xmi
new file mode 100644
index 0000000..b3d89bd
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/design_vm.xmi
@@ -0,0 +1,5 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="-vErMTo5DGQ1v_3_GNsccNw" name="design_vm,_ZTGAYL3uEdqLRJZPGVbHDA" guid="-vErMTo5DGQ1v_3_GNsccNw" changeDate="2006-07-30T08:17:30.553-0400">
+ <representationOptions>Whether&nbsp;maintained as a complete, semantically-rich&nbsp;model of the design in some tool or represented informally
+for the sake of investigation and communication, the design should be rendered visually.</representationOptions>
+</com.ibm.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/developer_test.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/developer_test.xmi
new file mode 100644
index 0000000..9a516e9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/developer_test.xmi
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqSB0qeqEdmKDbQuyzCoqQ" name="developer_test,_0YuXEclgEdmt3adZL5Dmdw" guid="_NqSB0qeqEdmKDbQuyzCoqQ" changeDate="2006-12-21T12:11:53.042-0500" version="1.0.0">
+ <mainDescription><p> This artifact covers all of
+ the steps that are required to validate
+ a software component. It specifies test entries,
+ execution conditions, and expected results. These details
+ are identified for the purpose of evaluating a
+ particular aspect of a scenario. </p>
+<p> The tests should be self-documenting in a way that
+ makes it clear upon completion of the test whether the component has
+ run correctly. </p></mainDescription>
+ <purpose>Evaluate that a software component performs as specified.</purpose>
+ <impactOfNotHaving>Not having developer tests can inhibit iterative development, because
+there is no assurance that modified components are still working correctly
+when you modify components iteration by iteration.</impactOfNotHaving>
+ <reasonsForNotNeeding>If the tests can be embedded into the actual production code, you might not need a separate work product. Nonetheless, some
+level of support for developer testing is always necessary.</reasonsForNotNeeding>
+ <briefOutline><p>
+ There is no predefined template for this&nbsp;work product and a testing tool will&nbsp;affect how the work product is
+ handled, but here are some key issues that should be addressed:
+</p>
+<ul>
+ <li>
+ Setup
+ </li>
+ <li>
+ Inputs
+ </li>
+ <li>
+ Script
+ </li>
+ <li>
+ Expected Results
+ </li>
+ <li>
+ Evaluation Criteria
+ </li>
+ <li>
+ Clean-Up
+ </li>
+</ul></briefOutline>
+ <representationOptions><p align="left">
+ The following are recommendation and options for representing this work product.
+</p>
+<h4>
+ Recommendation: Automated Code Unit
+</h4>
+<p>
+ The most appropriate technique for running these tests is using code that tests the components fully and that you can
+ run regularly as you update the system during development.
+</p>
+<p>
+ When code is the&nbsp;sole form of the tests, you must take care to ensure that the code is self-documenting, including
+ specifications of what conditions you are testing and what setup or clean-up is required for the test to run properly.
+</p>
+<h4>
+ Option: Manual Instructions
+</h4>
+<p>
+ In some cases, manual instructions can suffice. For example, when testing a user interface, a Developer could walk
+ through a script, explaining the component. In this case, it can still be valuable to create a test harness that goes
+ straight to the user interface. That way, the Developer can follow the script without having to walk through a
+ complicated set of instructions to get to a particular screen or page.
+</p>
+<h4>
+ Option: Embedded Code
+</h4>
+<p>
+ Certain technologies (such as Java&trade; 5 Test Annotation) enable you to embed tests in the implementation. In those cases,
+ there will be a logical work product, but it will be assimilated into the code that you are testing. Here, too, take
+ into consideration that you must ensure that the code is self-documenting.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/glossary.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/glossary.xmi
new file mode 100644
index 0000000..5cb0aa1
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/glossary.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-iOn7_gfX_iELWRNGJ2JKPQ" name="glossary,_Wn7HcNcEEdqz_d2XWoVt6Q" guid="-iOn7_gfX_iELWRNGJ2JKPQ" changeDate="2006-12-21T14:23:00.396-0500" version="1.0.0">
+ <mainDescription><p>
+ The Glossary helps you avoid miscommunication by providing two essential resources:
+</p>
+<ul>
+ <li>
+ A central location to look for terms and abbreviations that are new to development team members
+ </li>
+ <li>
+ Definitions of terms that are used in specific ways within the domain
+ </li>
+</ul>
+<p>
+ Definitions for the Glossary terms come from several sources, such as requirements documents, specifications, and
+ discussions with Stakeholders and domain experts.
+</p></mainDescription>
+ <keyConsiderations><p>
+ In some projects that do not involve business or domain modeling, the Glossary is the primary artifact for capturing
+ information about the project's business domain.
+</p>
+<p>
+ Although listed as an output from, and an input to tasks associated with the requirements discipline, this artifact can
+ be updated at any time, by any role, as new terms are identified.
+</p></keyConsiderations>
+ <purpose>The goal is for the Glossary to provide a common
+vocabulary agreed upon by all Stakeholders. It can
+help people from different functional groups reach a mutual
+understanding of the&nbsp;system.
+<!--StartFragment -->
+The goal is not to record all possible terms, but only those
+that are unclear, ambiguous, or require elaboration.</purpose>
+ <impactOfNotHaving>Misunderstandings about the meanings of data items account for many failed projects.
+Some of them become obvious only in the late stages of system testing and can
+be extremely expensive to correct.</impactOfNotHaving>
+ <representationOptions><p>
+ The Glossary is a simple alphabetized listing of domain terms and their definitions.&nbsp; It can be captured in a
+ spreadheet,&nbsp;document, or&nbsp;published on a Wiki site to simplify access and maintenance.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/implementation.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/implementation.xmi
new file mode 100644
index 0000000..8f69f62
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/implementation.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_6u9ZsKYcEdmvhNXG0Oc2uA" name="implementation,_0YoQcMlgEdmt3adZL5Dmdw" guid="_6u9ZsKYcEdmvhNXG0Oc2uA" authors="Jim Ruehlin" changeDate="2007-03-02T10:47:39.492-0800" version="1.0.0">
+ <mainDescription><p>
+ This artifact&nbsp;is the collection of one or more of&nbsp;these elements:
+</p>
+<ul>
+ <li>
+ Source code files
+ </li>
+ <li>
+ Data files&nbsp;
+ </li>
+ <li>
+ Build scripts
+ </li>
+ <li>
+ Other files that are transformed into the executable system
+ </li>
+</ul></mainDescription>
+ <purpose><p>
+ To represent the physical parts that make up the system to be built, organized in a way that is understandable and
+ manageable.
+</p></purpose>
+ <representationOptions><p>
+ Implementation files represented as files in the local file system. File folders (directories), represented as
+ packages, group the files into logical units.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/iteration_plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/iteration_plan.xmi
new file mode 100644
index 0000000..ae48460
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/iteration_plan.xmi
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_BcBR8KX5EdmvhNXG0Oc2uA" name="iteration_plan,_0aQBEslgEdmt3adZL5Dmdw" guid="_BcBR8KX5EdmvhNXG0Oc2uA" changeDate="2006-09-01T13:47:45.470-0700">
+ <mainDescription><p>
+ The main objectives of the iteration plan is to provide the team with one central place for information regarding
+ iteration objectives, detailed plan with task assignments, and evaluation results. This artifcat also helps the team to
+ monitor the progress of the iteration.
+</p>
+<p>
+ The task assignments for an iteration is a subset of all tasks on the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>, therefore the iteration plan ideally references those
+ work items.
+</p></mainDescription>
+ <purpose><p>
+ Communicate the objectives, task assignment, and evaluation criteria for a given iteration.
+</p></purpose>
+ <representationOptions><p>
+ The level of detail/formality of the plan must be adapted to what you need to successfully meet these objectives.The
+ plan could, for example, be captured
+</p>
+<ul>
+ <li>
+ on a whiteboard listing the objectives, task assignments and evaluation criteria,
+ </li>
+ <li>
+ a 1-page document listing the objectives and evaluation criteria of the iteration, as well as referencing the
+ Work Items List for assignments for that iteration,
+ </li>
+ <li>
+ a more complex document, supported by a Gantt or Pert chart in a project planning tool.
+ </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/iteration_plan_pm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/iteration_plan_pm.xmi
new file mode 100644
index 0000000..bebecf9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/iteration_plan_pm.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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="-b9hejTMj8E7U4g2v80xDjA" name="pm_iteration_plan,_xWdL0Dn6Edu_y4hBImiwwQ" guid="-b9hejTMj8E7U4g2v80xDjA" changeDate="2006-09-01T14:06:34.954-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/project_plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/project_plan.xmi
new file mode 100644
index 0000000..ff08177
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/project_plan.xmi
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_IbVp8KX4EdmvhNXG0Oc2uA" name="project_plan,_0a6vcMlgEdmt3adZL5Dmdw" guid="_IbVp8KX4EdmvhNXG0Oc2uA" changeDate="2006-10-30T15:33:37.069-0800" version="1.0.0">
+ <mainDescription><P><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p>This artifact&nbsp;defines the parameters for project progress tracking and specifies the high-level objectives of the iterations and their milestones. Additionally,&nbsp;it describes how the project is organized and which roles are assigned to whom.</o:p></SPAN></P>
+<P><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><o:p>The project manager is responsible for developing the project plan, working very closely with the rest of the team. The project plan allows stakeholders and other team members to understand the big picture and, roughly, when to expect what level of functionality.</o:p></SPAN><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><o:p><BR></P></o:p></SPAN></mainDescription>
+ <purpose><p>
+ The purpose of this artifact is&nbsp;to provide a central document where any project team member can find the
+ information on how the project will be managed.&nbsp;
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/md_acto2.gif b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/md_acto2.gif
new file mode 100644
index 0000000..29ede3a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/md_acto2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/md_acto3.gif b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/md_acto3.gif
new file mode 100644
index 0000000..43fbf21
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/md_acto3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/supporting_reguirements2.gif b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/supporting_reguirements2.gif
new file mode 100644
index 0000000..cf4c368
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/resources/supporting_reguirements2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/risk_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/risk_list.xmi
new file mode 100644
index 0000000..2f3b864
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/risk_list.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-4VJ_0upihz-bR7VRlm63Vw" name="risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA" guid="-4VJ_0upihz-bR7VRlm63Vw" changeDate="2006-10-30T16:42:53.506-0800">
+ <mainDescription>This list identifies, in decreasing order of priority, the events that could lead to a significant negative outcome. It
+serves as a focal point for project activities and is the basis around which iterations are organized. <!--EndFragment--></mainDescription>
+ <keyConsiderations><p>
+ This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider
+ whether they are really serious risks. Tracking more than 20 risks is an onerous task.
+</p></keyConsiderations>
+ <purpose>To&nbsp;capture the perceived risks to the success of the project.</purpose>
+ <representationOptions><h4>
+ Option: list of risks captured in the project plan
+</h4>
+<p>
+ In this approach you put the overall risk list in the project plan. The iteration plan will contain only the tasks you
+ will be doing during the iteration to mitigate the risks. This will ensure that the iteration plan contains only
+ iteration information. The project plan has to be revisited constantly as you update risks.
+</p>
+<h4>
+ Option: list of risks captured in&nbsp;the iteration plan
+</h4>
+<p>
+ In this approach you enter the overall risk list in the current iteration plan. This approach ensures that you look at
+ the risk list at each iteration, as it is part of your iteration plan. The only drawback is that your iteration plan
+ will contain information that is not relevant to the current iteration. All the risks you have not&nbsp;mitigated
+ during the iteration&nbsp;have to be&nbsp;transferred to the next iteration plan.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/status_assessment.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/status_assessment.xmi
new file mode 100644
index 0000000..a3323ec
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/status_assessment.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_K-e8IKX4EdmvhNXG0Oc2uA" name="status_assessment,_0bA2EMlgEdmt3adZL5Dmdw" guid="_K-e8IKX4EdmvhNXG0Oc2uA" changeDate="2006-11-01T15:32:14.824-0800" version="1.0.0">
+ <purpose><p>
+ Capture and communicate whether the project is on track, requires corrective actions, and whether there are
+ opportunities for improvement.
+</p></purpose>
+ <impactOfNotHaving>The team may not understand whether they are on track or not, and whether established iteration objectives and evaluation
+criteria are met. The team may not be able to improve the way they develop software.</impactOfNotHaving>
+ <representationOptions><p>
+ The format of the status assessment varies from one&nbsp;project to another. It can be the minutes of an assessment
+ meeting, an update to a web site, or just an email. The important thing&nbsp;is to effectively communicate&nbsp;to all
+ involved parties whether iteration objectives and evaluation criteria were addressed, and what improvements are
+ needed&nbsp;to the way the team is working.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/supporting_requirements.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/supporting_requirements.xmi
new file mode 100644
index 0000000..40df95d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/supporting_requirements.xmi
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" name="supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" changeDate="2006-12-21T12:42:23.035-0500">
+ <mainDescription><p>
+ Supporting Requirements and Use Cases, together, define the system requirements. Use Cases describe the behavioral
+ requirements for the system, and Supporting Requirements describe system-wide requirements that are not captured in Use
+ Case Specifications. Making this distinction simplifies maintenance.
+</p>
+<p>
+ Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,
+ Performance, Supportability + Constraints). For more information on this classification, see <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html"
+ guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.
+</p>
+<p>
+ The figure that follows illustrates the relationship among the Supporting Requirements, Use Case Specifications, and
+ Actors.
+</p>
+<p>
+ &nbsp;<img height="400" alt="" src="./resources/supporting_reguirements2.gif" width="600" />
+</p></mainDescription>
+ <impactOfNotHaving><p> The goal of&nbsp;this&nbsp;work product is&nbsp;to make sure that all types
+ of requirements are covered, which reduces the risk of not considering some
+ important facet of the system.&nbsp;FURPS+ requirements are system-wide, and
+ they&nbsp;influence the Architectural Mechanisms that you will create, thus
+ guiding development of the system's foundation.
+ These requirements are frequently the major cost item,
+ because they determine architectural choices.<strong>
+ </strong></p>
+<p> Furthermore, if you do not capture system-wide requirements in a central location,
+ but repeat them throughout the Use Cases, the result will
+ be more maintenance and more chance for error. </p></impactOfNotHaving>
+ <representationOptions><p> This work product does not imply using only one
+ document to capture all requirement types. To manage the communication of the
+ information, it makes more sense to separate the information into separate documents
+ or to use the Work Items List.<strong> </strong></p>
+<p align="left"> The following are recommendation and options for representing
+ the Supporting Requirements:</p>
+<h4> Option: Use the Work Items List</h4>
+<p> Consider capturing Supporting Requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
+ Work Items List</a>, which you can use for prioritizing and managing requirements.
+ If Stakeholders are comfortable with it, or with accessing a report automatically
+ generated from it, then you do not need a separate document. </p>
+<h4>
+ Option: Include as Part of the Vision Document
+</h4>
+<p> Consider including some types of Supporting Requirements in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact:
+ Vision</a>. To keep the Vision stable, follow this option for the requirements
+ types that need less refinement, such as Product Qualities, Documentation, or
+ Compliance. </p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/supporting_requirements_intent_req.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/supporting_requirements_intent_req.xmi
new file mode 100644
index 0000000..3c18369
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/supporting_requirements_intent_req.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-SUqkkwrs1D_5YXZls-3YBg" name=",_oclg0DRXEdudA-StyUUwnw" guid="-SUqkkwrs1D_5YXZls-3YBg" changeDate="2006-09-14T09:34:35.021-0400">
+ <representationOptions><h4>
+ Recommendation: Use the Supporting Requirements Specification Template
+</h4>
+<p>
+ <a class="elementLinkWithType" href="./../../openup_basic/guidances/templates/supporting_requirements_spec,_ItYXcNa9Edqrw4BYKyYKiA.html" guid="_ItYXcNa9Edqrw4BYKyYKiA">Template: Supporting Requirements Specification</a>&nbsp;provides a tool to capture,
+ structure, and organize the supporting requirements.
+</p>
+<p>
+ Even in a small project, a requirements management tool, a database, or a spreadsheet, are recommended for prioritizing
+ and managing requirements. If Stakeholders are comfortable with accessing requirements directly from that tool or with
+ accessing a report automatically generated from the tool, you will not need a separate document.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_case.xmi
new file mode 100644
index 0000000..69061ed
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_case.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqYIdKeqEdmKDbQuyzCoqQ" name="test_case,_0ZS-0MlgEdmt3adZL5Dmdw" guid="_NqYIdKeqEdmKDbQuyzCoqQ" changeDate="2006-09-20T16:57:14.165-0700">
+ <mainDescription><p>
+ A test case specifies the conditions which need to be validated to enable an assessment of some particular aspects of
+ the system under test.&nbsp; A test case is more formal than a test idea and usually takes the form of a
+ specification.&nbsp;In less formal environments, test cases can be created by identifying a unique ID, name, associated
+ test data, and expected results.&nbsp;For an example of this type of test case, see&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/templates/test_case,_0dT8IMlgEdmt3adZL5Dmdw.html" guid="_0dT8IMlgEdmt3adZL5Dmdw">Template: Test Case</a>.
+</p>
+<p>
+ Test cases may be derived from&nbsp;many&nbsp;sources but will usually include a subset of both the requirements (such
+ as use cases, performance characteristics, reliability concerns) and other types of quality attributes.&nbsp; For more
+ information on types of tests and their relationship to quality test attributes, see&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/types_of_test,_0aJ6cMlgEdmt3adZL5Dmdw.html" guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Types of Test</a>.
+</p></mainDescription>
+ <purpose><p>
+ The purpose of this artifact is to:
+</p>
+<ul>
+ <li>
+ provide a way to capture test inputs, conditions, and expected results for a system
+ </li>
+ <li>
+ systematically identify aspects of the software to test
+ </li>
+ <li>
+ specify whether an expected result has been reached based on verification of a system requirement, set of
+ requirements, or scenario
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_log.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_log.xmi
new file mode 100644
index 0000000..217ba29
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_log.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqePEKeqEdmKDbQuyzCoqQ" name="test_log,_0ZlSsMlgEdmt3adZL5Dmdw" guid="_NqePEKeqEdmKDbQuyzCoqQ" changeDate="2006-09-29T19:02:01.621-0400">
+ <mainDescription>This artifact&nbsp;provides a detailed, typically time-based record that serves both as verification that a set of tests
+were executed, and provides information relating to the success of those tests.&nbsp; The focus is typically on the
+provision of an accurate audit trail, enabling post-execution diagnosis of failures to be undertaken.&nbsp; This raw data
+will subsequently be analyzed to help determine the results of some aspect of the test effort.</mainDescription>
+ <purpose><ul>
+ <li>
+ To provide verification that a set of tests was executed
+ </li>
+ <li>
+ To provide information relating to the success of those tests
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_script.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_script.xmi
new file mode 100644
index 0000000..a7221c9
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/test_script.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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="_NqYIcqeqEdmKDbQuyzCoqQ" name="test_script,_0ZfMEMlgEdmt3adZL5Dmdw" guid="_NqYIcqeqEdmKDbQuyzCoqQ" changeDate="2005-07-19T16:12:17.077-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/uc_model_intent_req_ucm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/uc_model_intent_req_ucm.xmi
new file mode 100644
index 0000000..b504c01
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/uc_model_intent_req_ucm.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_zHZW9KYSEdmvhNXG0Oc2uA" name="uc_model,_0UCrZclgEdmt3adZL5Dmdw" guid="_zHZW9KYSEdmvhNXG0Oc2uA" changeDate="2006-12-21T09:42:02.273-0800" version="1.0.0">
+ <purpose><p>
+ This artifact presents an overview of the system's intended behavior.&nbsp; It&nbsp;is the basis for agreement
+ between&nbsp;stakeholders and the project team regarding the intended functionality for the system. It also helps to
+ guide the various tasks in the software development lifecycle.
+</p></purpose>
+ <representationOptions><p>
+ Tailor this artifact to support the project team's needs.
+</p>
+<p>
+ Representation options include: reports and diagrams from UML modeling tools, graphical representations created using
+ drawing tools, drawings on whiteboards. Most of the information in the use-case model is captured in the use-case
+ specifications.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/use_case.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/use_case.xmi
new file mode 100644
index 0000000..8d86eb2
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/use_case.xmi
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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="_zHZW8qYSEdmvhNXG0Oc2uA" name="use_case,_0VGbUMlgEdmt3adZL5Dmdw" guid="_zHZW8qYSEdmvhNXG0Oc2uA" changeDate="2006-09-13T14:58:40.026-0700">
+ <purpose><p> The primary purpose of the Use Case is to capture the required system behavior
+ from the perspective of the end user, to achieve one or more goals. Different
+ users benefit in different ways, of course: </p>
+<ul>
+ <li> <strong>Customers</strong> use them to describe, or at least to approve,
+ the description of the system's behavior. </li>
+ <li><strong> Potential users</strong> use them to understand the system's behavior.
+ </li>
+ <li><strong> Architects </strong>use them to identify architecturally significant
+ functionality. </li>
+ <li><strong> Developers </strong>use them<strong> </strong> to understand the
+ required system behavior so they can identify classes from the Use Cases'
+ flow of events. </li>
+ <li><strong> Testers</strong> use them as a basis for identifying a subset of
+ the required Test Cases. </li>
+ <li> <strong>M</strong><b>anagers</b> use them<b> </b> to plan and assess the
+ work for each iteration. </li>
+ <li><strong> Technical writers </strong>use them
+ to understand the sequence of system behavior
+ that they need to describe in the documentation. </li>
+</ul></purpose>
+ <representationOptions><p> Decide the extent to which you will elaborate on Use
+ Cases: </p>
+<ul>
+
+ <li> Describe only major flows? </li>
+
+ <li> Describe only the most important Use Cases? </li>
+
+ <li>Fully describe preconditions and post-conditions? </li>
+
+ <li> Describe scenarios first, and then raise the level of abstraction by describing
+ Use Case flows? </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/use_case_intent_req.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/use_case_intent_req.xmi
new file mode 100644
index 0000000..5664855
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/use_case_intent_req.xmi
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-JcGDIeBIMM099mbWX5fXbA" name=",_qis78DRbEduFvfVCXiK3AA" guid="-JcGDIeBIMM099mbWX5fXbA" changeDate="2006-09-14T09:30:41.163-0400">
+ <representationOptions><p>
+ Some projects apply Use Cases informally to help discover requirements, documenting and maintaining these requirements
+ in another form such as user stories. How you tailor Use Cases may depend on project size, team experience, your tool
+ set, the customer relationship, and so forth. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance related to documenting
+ Use Cases.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/vision.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/vision.xmi
new file mode 100644
index 0000000..4981962
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/vision.xmi
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" name="vision,_0WVxcMlgEdmt3adZL5Dmdw" guid="_zHTQUKYSEdmvhNXG0Oc2uA" changeDate="2007-02-28T08:55:39.149-0500" version="1.0.0">
+ <mainDescription><p>
+ This artifact&nbsp;provides a complete vision for the software system under development and supports the contract
+ between the customer and the development organization. Every project needs a source for capturing all Stakeholders'
+ expectations.
+</p>
+<p>
+ This artifact&nbsp;is written from the customers' perspective, focusing on the essential features of the system and
+ acceptable levels of quality. The artifact should include a description of what <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a>&nbsp;will be included, as well as those considered but not included.
+</p></mainDescription>
+ <purpose><p> This artifact&nbsp;provides a high-level, sometimes contractual, basis for
+ the more detailed technical requirements that are visible to the Stakeholders.
+ It captures the essence of the system by describing high-level
+ requirements and design constraints that give the reader an overview of the
+ system from a behavioral requirements perspective. It serves
+ as input for the project-approval process,
+ communicates the fundamental "what and why" for the project, and provides
+ a plan against which all future decisions should be validated. </p></purpose>
+ <impactOfNotHaving>If this artifact is not used, there is a high risk that Stakeholders and the development
+team will have different expectations.&nbsp;This could lead to cancellation of
+the project.</impactOfNotHaving>
+ <representationOptions>Tailor this artifact as necessary for your project's needs. It is generally good
+practice to keep this artifact brief so you can release
+it to Stakeholders as soon as possible, and to make it easy for Stakeholders to
+read and understand. You can
+accomplish this by including only the most important Stakeholder requests
+and features and avoiding details of requirements.
+You can describe details in the other requirement
+artifacts.</representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/work_items_list.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/work_items_list.xmi
new file mode 100644
index 0000000..ee1880b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/work_items_list.xmi
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-buxz4BVToq97bSxaqyjySg" name="work_items_list,_rGNWsCbSEdqh1LYUOGRh2A" guid="-buxz4BVToq97bSxaqyjySg" changeDate="2006-10-30T14:42:59.632-0800" version="1.0.0">
+ <mainDescription><p>
+ This artifact provides a focal point for the entire team:
+</p>
+<ul>
+ <li>
+ It provides one list containing all requests for additional capabilities or enhancement for that application. Note
+ that some of these requests may never be implemented, or be implemented in later projects
+ </li>
+ <li>
+ It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list
+ is prioritized separately.
+ </li>
+ <li>
+ It provides one place to go to for the development team to understand what needs to be done, get references to
+ material required to carry out the work, and one place to go to report progress made.
+ </li>
+</ul>
+<p>
+ Work items can be very large in scope, especially when capturing requests for enhancements, such as “Support Financial
+ Planning” for a personal finance application. Work Items are analyzed and broken down into smaller Work Items so they
+ can assigned to an iteration, such as a use case scenario for&nbsp;“Calculate Net Worth”. Further breakdown may be
+ required to identify suitable tasks to be assigned to developers, such as “Develop UI for Calculate Net Worth”. This
+ means that Work Items often have parent / child relationships.
+</p></mainDescription>
+ <purpose>To collect all requests for work that will potentially be taken on within the project, so work can be prioritized, effort
+estimated and progress tracked.</purpose>
+ <representationOptions><h3>
+ As a spreadsheet or database
+</h3>
+<p>
+ The Work Items List can be captured as a separate artifact, represented by a spreadsheet or database table, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/examples/work_items_list,_nHomIDgzEdu4E8ZdmlYjtA.html" guid="_nHomIDgzEdu4E8ZdmlYjtA">Example: Work Items List</a>.
+</p>
+<h3>
+ In specific tools
+</h3>
+<p>
+ Project Management, Requirements Management and Change Request tools are an option to capture the list of work to be
+ done.
+</p>
+<h3>
+ Subset As part of the Iteration Plan
+</h3>
+<p>
+ The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a> typically references Work Items that are assigned to that
+ iteration. If the team is capturing the Iteration Plan on a Whiteboard for example, the team may choose to reference
+ high-level work items in the Work Items List that are assigned to the iteration, and maintain low-level child work
+ items used to track day-to-day work only within an iteration plan.<br />
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducts/work_items_list_pm.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/work_items_list_pm.xmi
new file mode 100644
index 0000000..3da4895
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducts/work_items_list_pm.xmi
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-fDVhZTkf1TqDyExbI9DM-w" name=",_sNoQ0Dn6Edu_y4hBImiwwQ" guid="-fDVhZTkf1TqDyExbI9DM-w" changeDate="2006-09-07T14:41:14.873-0700">
+ <mainDescription><p>
+ Work Items should contain estimates, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/work_items_list,_7vEXEMA4EdqSgKaj2SZBmg.html" guid="_7vEXEMA4EdqSgKaj2SZBmg">Guideline: Work Items List</a>&nbsp;and <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/assessment.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/assessment.xmi
new file mode 100644
index 0000000..6f919c4
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/assessment.xmi
@@ -0,0 +1,2 @@
+<?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="-5S6ney_fFdEHm49XznPRiA" name="new_work_product_kind,_2VBNIDz6Edq03rqPoNVoKg" guid="-5S6ney_fFdEHm49XznPRiA" changeDate="2005-10-14T14:38:35.242-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/concept.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/concept.xmi
new file mode 100644
index 0000000..7c5f29a
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/concept.xmi
@@ -0,0 +1,2 @@
+<?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="-Nl-rJ_6aaAG2jpJyGm_wcg" name="new_work_product_kind,_8XKVwDz6Edq03rqPoNVoKg" guid="-Nl-rJ_6aaAG2jpJyGm_wcg" changeDate="2005-10-14T14:39:12.267-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/infrastructure.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/infrastructure.xmi
new file mode 100644
index 0000000..bee3a61
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/infrastructure.xmi
@@ -0,0 +1,2 @@
+<?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="-CKZiRxRx_TZhMbquLd4Sqw" name="new_work_product_kind,_EL6rgDz7Edq03rqPoNVoKg" guid="-CKZiRxRx_TZhMbquLd4Sqw" changeDate="2005-10-14T14:40:04.914-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/model.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/model.xmi
new file mode 100644
index 0000000..ab36227
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/model.xmi
@@ -0,0 +1,2 @@
+<?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="-ARfZUsgYE1XrKQlDgr9mEQ" name="new_work_product_kind,_MQbUgDz7Edq03rqPoNVoKg" guid="-ARfZUsgYE1XrKQlDgr9mEQ" changeDate="2005-10-14T14:40:58.794-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/model_element.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/model_element.xmi
new file mode 100644
index 0000000..802d674
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/model_element.xmi
@@ -0,0 +1,2 @@
+<?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="-cW3aVzDjHhqkVayoItUQqw" name="new_work_product_kind,_SxUOoDz7Edq03rqPoNVoKg" guid="-cW3aVzDjHhqkVayoItUQqw" changeDate="2005-10-14T14:41:44.932-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/plan.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/plan.xmi
new file mode 100644
index 0000000..588a52d
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/plan.xmi
@@ -0,0 +1,2 @@
+<?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="-vpMAMS8Cz-z9DQQhxbjjLA" name="new_work_product_kind,_ZR7b8Dz7Edq03rqPoNVoKg" guid="-vpMAMS8Cz-z9DQQhxbjjLA" changeDate="2005-10-14T14:42:22.998-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/project_data.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/project_data.xmi
new file mode 100644
index 0000000..a2d2d53
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/project_data.xmi
@@ -0,0 +1,2 @@
+<?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="-DBPx56p4GCNFpRTT8uOmiQ" name="new_work_product_kind,_hOaxYDz7Edq03rqPoNVoKg" guid="-DBPx56p4GCNFpRTT8uOmiQ" changeDate="2005-10-14T14:43:18.871-0700"/>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/solution.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/solution.xmi
new file mode 100644
index 0000000..538491b
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/solution.xmi
@@ -0,0 +1,9 @@
+<?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="-sIh01vzZACgxRrG_sv7DVw" name="new_work_product_kind,_mC_6sDz7Edq03rqPoNVoKg" guid="-sIh01vzZACgxRrG_sv7DVw" changeDate="2005-10-14T14:43:49.126-0700">
+ <mainDescription><p>
+ <font face="Arial" size="2">Many work products contribute to the overall solution or product.&nbsp; Tests and test data
+ is needed to validate the solution.&nbsp; User support materials of all sorts are needed in the final product.&nbsp;
+ Source code and other implementation elements are required to build the final product.&nbsp; These work products,
+ including those that ship with the product, are categorized as Solution.</font>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/specification.xmi b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/specification.xmi
new file mode 100644
index 0000000..b488dcb
--- /dev/null
+++ b/OpenUP/OpenUP_PT/library/openup_basic/workproducttypes/specification.xmi
@@ -0,0 +1,2 @@
+<?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="-C5ih3s1Vn_9qQbjm85-GYg" name="new_work_product_kind,_tJJeADz7Edq03rqPoNVoKg" guid="-C5ih3s1Vn_9qQbjm85-GYg" changeDate="2005-10-14T14:44:42.765-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/base_concepts_view_building_blocks.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/base_concepts_view_building_blocks.html
new file mode 100644
index 0000000..b117dbc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/base_concepts_view_building_blocks.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\base_concepts_view_building_blocks.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: base_concepts_view_building_blocks.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7-x6YBTLEdqrUt4zetC1gg CRC: 2537412959 -->Base Concepts View Building Blocks<!-- END:presentationName,_7-x6YBTLEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_7-x6YBTLEdqrUt4zetC1gg CRC: 987941067 -->This is a package of custom categories that can be used to compose views. It should never be used as a view itself.<!-- END:briefDescription,_7-x6YBTLEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/categories.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/categories.html
new file mode 100644
index 0000000..a95af37
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/categories.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\categories.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: categories.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yqwU0BTMEdqrUt4zetC1gg CRC: 1146872353 -->Categories and Views<!-- END:presentationName,_yqwU0BTMEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_yqwU0BTMEdqrUt4zetC1gg CRC: 2053083986 -->Categories provide different ways to logically organize Method Content elements.<!-- END:briefDescription,_yqwU0BTMEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yrIvUBTMEdqrUt4zetC1gg CRC: 1514625001 --><p>
+ Categories provide different ways to logically organize Content Elements. In addition to Standard Categories that have
+ been predefined for most Content Element types in UMA, <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/concepts/custom_category,_xuO10BUGEdqrUt4zetC1gg.html"
+ guid="_xuO10BUGEdqrUt4zetC1gg">Custom Categories</a> can be used to either of the following:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Categorize content based on the user's criteria.
+ </li>
+ <li>
+ Define tree-structures of nested categories allowing the user to systematically navigate and browse Method
+ Content as well as Processes based on these categories. When Custom Categories are used in this way they
+ are also referred to as <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/concepts/view,_uMKSsBUFEdqrUt4zetC1gg.html"
+ guid="_uMKSsBUFEdqrUt4zetC1gg">Views</a>.
+ </li>
+ </ul>
+</div><!-- END:mainDescription,_yrIvUBTMEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/cc_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/cc_list.html
new file mode 100644
index 0000000..41fb57b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/cc_list.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\cc_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: cc_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_5_90EO8KEdmKSqa_gSYthg CRC: 976131797 -->Component Category List<!-- END:presentationName,_5_90EO8KEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_5_90EO8KEdmKSqa_gSYthg CRC: 987941067 -->This is a package of custom categories that can be used to compose views. It should never be used as a view itself.<!-- END:briefDescription,_5_90EO8KEdmKSqa_gSYthg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/guidance.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/guidance.html
new file mode 100644
index 0000000..d2811a0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/guidance.html
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\guidance.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: guidance.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_RdIv8AIhEdqEutyfYo0quQ CRC: 163102705 -->Guidance<!-- END:presentationName,_RdIv8AIhEdqEutyfYo0quQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/guidance_2.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/guidance_2.html
new file mode 100644
index 0000000..b0fb144
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/guidance_2.html
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\guidance 2.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: guidance 2.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_xy2SAAIsEdqEutyfYo0quQ CRC: 163102705 -->Guidance<!-- END:presentationName,_xy2SAAIsEdqEutyfYo0quQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_xy2SAAIsEdqEutyfYo0quQ CRC: 232674913 -->Guidance is an abstract concept that generalizes all forms of content whose primary purpose is to provide additional explanations and illustrations to elements such as Roles, Tasks, Work Products, Activities, or Processes.<!-- END:briefDescription,_xy2SAAIsEdqEutyfYo0quQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_xy2SAQIsEdqEutyfYo0quQ CRC: 3836557520 --><p>
+ UMA defines a number of pre-defined concrete Guidance Types.
+</p>
+<p>
+ Associations and multiplicities have been predefined on the level of detail as depicted to ensure that Guidance is only
+ related to appropriate Content Elements. For example, UMA defines that Templates can only be associated with Work
+ Products. Guidance association rules are specified with the following UML diagram:
+</p>
+<p align="center">
+ <img height="571" alt="UML diagram showing Guidance relationships"
+ src="./../guidances/concepts/resources/guidance_uml.gif" width="586" />
+</p><!-- END:mainDescription,_xy2SAQIsEdqEutyfYo0quQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_architecture_fundamentals.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_architecture_fundamentals.html
new file mode 100644
index 0000000..d02923f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_architecture_fundamentals.html
@@ -0,0 +1,225 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\method_architecture_fundamentals.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_architecture_fundamentals.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uDU1oASEEdq61bDkWg1SXw CRC: 276954084 -->Method Architecture Fundamentals<!-- END:presentationName,_uDU1oASEEdq61bDkWg1SXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_uDU1oASEEdq61bDkWg1SXw CRC: 57942295 -->Introduces fundamental UMA principles, concepts, abstractions.<!-- END:briefDescription,_uDU1oASEEdq61bDkWg1SXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_uDU1oQSEEdq61bDkWg1SXw CRC: 2090078945 --><h3>
+ What is UMA?
+</h3>
+<p>
+ The Unified Method Architecture (UMA) is a process engineering meta-model that defines schema and terminology for
+ representing methods consisting of method content and processes. Also see <a class="elementLinkWithType" href="./../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html" guid="_94_eoO8LEdmKSqa_gSYthg">Concept: Key Capabilities of the Unified Method Architecture (UMA)</a> for more
+ details.
+</p>
+<h3>
+ Fundamental principle within UMA
+</h3>
+<p>
+ UMA is based on the following fundamental separations of concern:
+</p>
+<ul>
+ <li>
+ The separation of core method content versus the application of method content in processes
+ </li>
+ <li>
+ The definition of an optional extensibility mechanism in the method for large scale management of method and
+ process repositories
+ </li>
+ <li>
+ Packaging and configuration of method content, processes, and plugins in method libraries
+ </li>
+ <li>
+ A separation of recommended method and guidance description fields
+ </li>
+ <li>
+ A separation of semantic elements from their notation in process diagrams
+ </li>
+</ul>
+<h3>
+ The Basic Elements of UMA
+</h3>
+<p>
+ The most fundamental principle of the Unified Method Architecture (UMA) is the separation of reusable core method
+ content from its application in processes and almost all of UMA's elements are categorized along this separations.
+</p>
+<p>
+ The Unified Method Architecture separates reusable core method content from its application in processes. Method
+ content describes what is to be produced, the necessary skills required and the step-by-step explanation describing how
+ specific development goals are achieved, independently of the placement of these items within a development
+ lifecycle. Processes take these method elements and relate them into semi-ordered sequences that are customized
+ to specific types of projects. For example, a software development project that develops an application from scratch
+ performs development tasks such as "Develop Vision" or "Use Case Design" similar to a project that extends an existing
+ software system. However, the two projects will perform the Tasks at different points in time with a different
+ emphasis, i.e. they will perform the steps of these tasks at different point of time and perhaps apply individual
+ variations and additions.
+</p>
+<p>
+ The figure below shows the difference between method content and process by representing them as two different
+ dimensions:
+</p>
+<ul>
+ <li>
+ Method content describing how development work is being performed is categorized by disciplines. Each
+ discipline is comprised of tasks (not visible in the figure) that provide step-by-step descriptions of how specific
+ development goals are achieved.
+ </li>
+ <li>
+ For a process, tasks have been referenced by the process from the method content and placed into breakdown
+ structures and workflows ready for instantiation by allocating resources to perform the work and having real work
+ products as the inputs and outputs of the tasks.<br />
+ </li>
+</ul>
+<p align="center">
+ <img alt="Diagram illustrating the separation of Method and Process content within the UMA Meta-Model" src="../guidances/concepts/resources/uma_hump.jpg" border="0" />
+</p>
+<p class="picturetext" align="center">
+ Method Content definition versus<br />
+ the application of Method Content in a Process.
+</p>
+<p>
+ UMA's key concepts reflect this separation of method content from process as shown in the figure below. It show
+ that a Method (also refered to as a Method Framework) comprises on method content described with concepts such Work
+ Products, Roles, Task and Categories as well as Processes described with Activities, Capability Patterns, or Delivery
+ Processes.
+</p>
+<p align="center">
+ <img alt="Diagram illustrating that the intersection between Method and Process content is guidance" src="../guidances/concepts/resources/uma_m_vs_p.gif" />
+</p>
+<p align="center">
+ Overview of how the key UMA concepts are positioned based on whether they represent method content or process
+</p>
+<p class="picturetext" align="left">
+ Key <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/method_concepts,_WfL28BTMEdqrUt4zetC1gg.html" guid="_WfL28BTMEdqrUt4zetC1gg">Method Content Elements</a> are:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html" guid="4.804531471620803E-306">Work Product</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/role,1.1609745730665898E-304.html" guid="1.1609745730665898E-304">Role</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html" guid="7.624729048911575E-305">Task</a>
+ </div>
+ </li>
+ </ul>
+</div>
+<p class="picturetext" align="left">
+ Key <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/process_concepts,_AtM0gBTQEdqrUt4zetC1gg.html" guid="_AtM0gBTQEdqrUt4zetC1gg">Process Elements</a> are:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html" guid="3.132140065969088E-305">Activity</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html" guid="1.7072348895114264E-305">Capability Pattern</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html" guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>
+ </div>
+ </li>
+ </ul>
+</div>
+<p class="picturetext" align="left">
+ <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/guidance,_xy2SAAIsEdqEutyfYo0quQ.html" guid="_xy2SAAIsEdqEutyfYo0quQ">Guidance</a> comes in many types:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/checklist,_2vVuUBT9EdqrUt4zetC1gg.html" guid="_2vVuUBT9EdqrUt4zetC1gg">Checklist</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/concept,_8wobABUAEdqrUt4zetC1gg.html" guid="_8wobABUAEdqrUt4zetC1gg">Concept</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/example,_dCG-UBUBEdqrUt4zetC1gg.html" guid="_dCG-UBUBEdqrUt4zetC1gg">Example</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/guideline,_IAwkEBUEEdqrUt4zetC1gg.html" guid="_IAwkEBUEEdqrUt4zetC1gg">Guideline</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/practice,_szl6EBUBEdqrUt4zetC1gg.html" guid="_szl6EBUBEdqrUt4zetC1gg">Practice</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/report,_x2sAgBUBEdqrUt4zetC1gg.html" guid="_x2sAgBUBEdqrUt4zetC1gg">Report</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/reusable_asset,_20bs4BUBEdqrUt4zetC1gg.html" guid="_20bs4BUBEdqrUt4zetC1gg">Reusable Asset</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/roadmap,_JCQbIBnXEdqYreeU3jqaDQ.html" guid="_JCQbIBnXEdqYreeU3jqaDQ">Roadmap</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/supporting_material,_80XPABUBEdqrUt4zetC1gg.html" guid="_80XPABUBEdqrUt4zetC1gg">Supporting Material</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/template,_G_UnIBUCEdqrUt4zetC1gg.html" guid="_G_UnIBUCEdqrUt4zetC1gg">Template</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/term_definition,_Z45fwBUDEdqrUt4zetC1gg.html" guid="_Z45fwBUDEdqrUt4zetC1gg">Term Definition</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/tool_mentor,1.0762105093945226E-304.html" guid="1.0762105093945226E-304">Tool Mentor</a>
+ </div>
+ </li>
+ </ul>
+</div><!-- END:mainDescription,_uDU1oQSEEdq61bDkWg1SXw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_concepts.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_concepts.html
new file mode 100644
index 0000000..bdfc6da
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_concepts.html
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\method_concepts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_concepts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_WfL28BTMEdqrUt4zetC1gg CRC: 2285988436 -->Method Content Concepts<!-- END:presentationName,_WfL28BTMEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_WfL28BTMEdqrUt4zetC1gg CRC: 3455798170 -->UMA's fundamental Method Content abstractions are Work Products, Roles, Tasks, and Guidance.<!-- END:briefDescription,_WfL28BTMEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_WfkRcBTMEdqrUt4zetC1gg CRC: 3642075555 --><p>
+ Method Content is fundamentally described by defining Tasks described with Steps that have Work Products as input and
+ output and which are performed by Roles. Roles also define important responsibility relationships to work
+ products.
+</p>
+<p>
+ The fundamental Method Content abstractions are:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">Work Product</a>, which includes <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/artifact,_fdRfkBUJEdqrUt4zetC1gg.html"
+ guid="_fdRfkBUJEdqrUt4zetC1gg">Artifact</a>, <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/deliverable,_lBgkMBUJEdqrUt4zetC1gg.html"
+ guid="_lBgkMBUJEdqrUt4zetC1gg">Deliverable</a> and <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/outcome,_pROF4BUJEdqrUt4zetC1gg.html"
+ guid="_pROF4BUJEdqrUt4zetC1gg">Outcome</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/role,1.1609745730665898E-304.html"
+ guid="1.1609745730665898E-304">Role</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">Task</a>
+ </li>
+</ul>
+<br align="center" />
+<br /><!-- END:mainDescription,_WfkRcBTMEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_package.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_package.html
new file mode 100644
index 0000000..94d55c2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/method_package.html
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\method_package.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_package.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_R5Vk4BtpEdqSLrJ4Ij2LVA CRC: 2916300450 -->Method Package<!-- END:presentationName,_R5Vk4BtpEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_R5Vk4BtpEdqSLrJ4Ij2LVA CRC: 3633193982 -->This packaging structure defines how Method Elements can be physically organized into package hierarchies.<!-- END:briefDescription,_R5Vk4BtpEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-G5kN9IUns9GPxohNmAeeyw CRC: 161053803 --><p>
+ Method Packages physically organize Method Elements into package hierarchies. All Method Elements are located in
+ exactly one Method Package.
+</p>
+<p>
+ There are two type of Method Package:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/content_package,_49a10BUFEdqrUt4zetC1gg.html"
+ guid="_49a10BUFEdqrUt4zetC1gg">Content Package</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/process_package,_MT6U8BneEdqYreeU3jqaDQ.html"
+ guid="_MT6U8BneEdqYreeU3jqaDQ">Process Package</a>
+ </li>
+</ul><!-- END:mainDescription,-G5kN9IUns9GPxohNmAeeyw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/navigating_the_process.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/navigating_the_process.html
new file mode 100644
index 0000000..752faf1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/navigating_the_process.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\navigating_the_process.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: navigating_the_process.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3uTl0ASHEdq61bDkWg1SXw CRC: 2213766166 -->Navigating the Method Web Site<!-- END:presentationName,_3uTl0ASHEdq61bDkWg1SXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_3uTl0ASHEdq61bDkWg1SXw CRC: 455340542 -->This guidance explains how to navigate a typical method Web site.<!-- END:briefDescription,_3uTl0ASHEdq61bDkWg1SXw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/organizational_concepts.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/organizational_concepts.html
new file mode 100644
index 0000000..bcf4f97
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/organizational_concepts.html
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\organizational_concepts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: organizational_concepts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Tp3S0BTQEdqrUt4zetC1gg CRC: 3621034470 -->Organizational Concepts<!-- END:presentationName,_Tp3S0BTQEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Tp3S0BTQEdqrUt4zetC1gg CRC: 368680087 -->This section lists several key concepts define in UMA for packaging and extending methods.<!-- END:briefDescription,_Tp3S0BTQEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_TqJmsBTQEdqrUt4zetC1gg CRC: 3437382596 --><p>
+ This section describes concepts that are only used to organize method content and processes in an authoring
+ environment.None of these UMA abstractions are subject to publication. They include:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/method_library,_m8lGkBUFEdqrUt4zetC1gg.html"
+ guid="_m8lGkBUFEdqrUt4zetC1gg">Method Library</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+ guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugin</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+ guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>
+ </li>
+ <li>
+ Method Package, which includes <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/content_package,_49a10BUFEdqrUt4zetC1gg.html"
+ guid="_49a10BUFEdqrUt4zetC1gg">Content Package</a>, and <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/process_package,_MT6U8BneEdqYreeU3jqaDQ.html"
+ guid="_MT6U8BneEdqYreeU3jqaDQ">Process Package</a>
+ </li>
+</ul>
+<p>
+ These abstractions as well as their relationships are presented with the the following UML 2.0 class diagram:
+</p>
+<p align="center">
+ <img alt="UML Diagram describing the modeling or organizational abstractions"
+ src="../../base_concepts/guidances/concepts/resources/packaging_uml.gif" />
+</p><!-- END:mainDescription,_TqJmsBTQEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/process_concepts.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/process_concepts.html
new file mode 100644
index 0000000..5876ca4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/customcategories/process_concepts.html
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\customcategories\process_concepts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: process_concepts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_AtM0gBTQEdqrUt4zetC1gg CRC: 1193320241 -->Process Concepts<!-- END:presentationName,_AtM0gBTQEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_AtM0gBTQEdqrUt4zetC1gg CRC: 3531558913 -->UMA defines concepts for defining processes. This section lists the most important ones.<!-- END:briefDescription,_AtM0gBTQEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_AtZBwBTQEdqrUt4zetC1gg CRC: 2743185262 --><p>
+ A Development Process defines the structured work definitions that need to be performed to develop a system, e.g. by
+ performing a project that follows the process. Such structured work definitions delineate the work to be
+ performed along a timeline or lifecycle and organize it in so called breakdown structures and/or activity diagrams. A
+ process takes reusable core method elements such as Tasks and Work Products and relates them into semi-ordered
+ sequences that are then customized to specific types of projects.
+</p>
+<p>
+ Fundamental concepts used in UMA to define processes include:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html"
+ guid="3.132140065969088E-305">Activity</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/process_contribution,_NYASQBtqEdqSLrJ4Ij2LVA.html"
+ guid="_NYASQBtqEdqSLrJ4Ij2LVA">Process Contribution</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/descriptor,_5V9HEBUEEdqrUt4zetC1gg.html"
+ guid="_5V9HEBUEEdqrUt4zetC1gg">Descriptor</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/composite_role,_P9gp0BtHEdqSLrJ4Ij2LVA.html"
+ guid="_P9gp0BtHEdqSLrJ4Ij2LVA">Composite Role</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/team_profile,_dRKRMBtHEdqSLrJ4Ij2LVA.html"
+ guid="_dRKRMBtHEdqSLrJ4Ij2LVA">Team Profile</a>
+ </li>
+</ul><!-- END:mainDescription,_AtZBwBTQEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/activity.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/activity.html
new file mode 100644
index 0000000..21d1031
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/activity.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\activity.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: activity.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.132140065969088E-305 CRC: 1426221836 -->Activity<!-- END:presentationName,3.132140065969088E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,3.132140065969088E-305 CRC: 3400579481 -->An Activity supports the nesting and logical grouping of related process elements also referred to as Breakdown Elements (e.g. other Activities or Task Descriptors). The concepts Phase, Iteration, Delivery Process, and Capability Pattern are defined as special Activities.<!-- END:briefDescription,3.132140065969088E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zaqEMNnmEdmO6L4XMImrsA CRC: 911979929 --><p>
+ Activities are the fundamental concept for defining processes. Activities define the breakdown as well as flow of
+ work. In other words, Activities can be nested into each other defining a breakdown structure of work or they can
+ define predecessor relationships to other Activities defining a flow presented in Activity diagrams. Activities
+ can also contain references to Task, Roles, and Work Products called <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/descriptor,_5V9HEBUEEdqrUt4zetC1gg.html"
+ guid="_5V9HEBUEEdqrUt4zetC1gg">Descriptor</a>. Activities as well as Descriptors relate to timelines by allowing
+ their instances to define start and/or end dates. Further, they specify information relevant to the instantiation
+ of work in project such as if an Activity shall be performed several times and if so if they can be performed in
+ parallel (hasMultipleOccurrences attribute) or one after other (isRepeatable attribute). Activities and Task
+ Descriptors can also be event driven or describing ongoing work that does not have a fixed start and end time.
+</p>
+<p>
+ UMA defines several special Activities that allow expressing processes with terms many users are familiar
+ with. For example, Phase or Iteration are just special Activities for which specific attribute values have been
+ set with predefined values. A process such as a <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a> or <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a> is also nothing else than just a special Activity that
+ contains additional documentation on why and how to use the process. Hence, because Activities could be nested into
+ each other, so can processes.
+</p><!-- END:mainDescription,_zaqEMNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/artifact.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/artifact.html
new file mode 100644
index 0000000..00f3642
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/artifact.html
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\artifact.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: artifact.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_fdRfkBUJEdqrUt4zetC1gg CRC: 2979201658 -->Artifact<!-- END:presentationName,_fdRfkBUJEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_fdRfkBUJEdqrUt4zetC1gg CRC: 3577006256 -->Artifact is a Work Product that provides a description and definition for tangible, non-trivial work products.<!-- END:briefDescription,_fdRfkBUJEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_fdds0BUJEdqrUt4zetC1gg CRC: 656401007 --><p>
+ Artifacts are tangible well-defined Work Products consumed, produced, or modified by Tasks. Artifacts may be
+ composed of other Artifacts. For example, a model Artifact can be composed of model elements, which are also Artifacts.
+ They may serve as a basis for defining Reusable Assets. Roles use Artifacts to perform Tasks and produce
+ Artifacts in the course of performing Tasks.
+</p>
+<p>
+ Artifacts are the responsibility of a single Role, making responsibility easy to identify and understand, and promoting
+ the idea that every piece of information produced in the method requires the appropriate set of skills. Even though one
+ Role might "own" a specific type of Artifact, other Roles can still use the Artifacts, and perhaps even update them if
+ the Role has been given permission to do so.
+</p>
+<p>
+ <b>Artifacts are generally <i>not</i> documents</b>. Many methods have an excessive focus on documents, and in
+ particular on <i>paper documentation</i>. The most efficient and pragmatic approach to managing project Artifacts is to
+ maintain them <i>within</i> the appropriate tool used to create and manage them. When necessary, one may generate
+ documents (snapshots) from these tools, on a just-in-time basis.
+</p>
+<p>
+ Examples Artifacts:
+</p>
+<ul>
+ <li>
+ A use case specification stored in a word processor tool
+ </li>
+ <li>
+ A design model stored in a visual modeling tool.
+ </li>
+ <li>
+ A project plan stored in a project planning tool.
+ </li>
+ <li>
+ A defect stored in a change requests tools
+ </li>
+ <li>
+ A project requirements database in a requirements management tool.
+ </li>
+</ul>
+<p>
+ Note also that formats such as on <b>whiteboards</b> or <b>flip charts</b> can be used to capture pictorial information
+ such as UML diagrams, tabular information such as short lists of status information or even textual information such as
+ short vision statements. These formats work well for smaller, collocated teams where all team members have ready access
+ to these resources.
+</p>
+<p>
+ However, there are still Artifacts which either have to be or are best suited to being plain text documents, as in the
+ case of external input to the project, or in some cases where it is simply the best means of presenting descriptive
+ information. Where possible, teams should consider using collaborative <b>Work Group</b> tools, such as WikiWiki webs
+ or Groove to capture textual documentation electronically, thus simplifying ongoing content and version management.
+ This is especially of importance where historic records must be maintained for purposes such as fulfilling audit
+ requirements. For any nontrivial development effort, especially where large development teams are involved, Work
+ Products <strong>are</strong> <strong>most likely to be subject to version control and configuration
+ management.</strong> This is sometimes only achieved by versioning the container Work Product, when it is not possible
+ to do it for the elementary, contained Work Products. For example, in software development, you may control the
+ versions of a whole design model, or design package, and not the individual classes they contain.
+</p><!-- END:mainDescription,_fdds0BUJEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/capability_pattern.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/capability_pattern.html
new file mode 100644
index 0000000..57d370a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/capability_pattern.html
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\capability_pattern.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: capability_pattern.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.7072348895114264E-305 CRC: 2925390144 -->Capability Pattern<!-- END:presentationName,1.7072348895114264E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,1.7072348895114264E-305 CRC: 2643350980 -->A Capability Pattern is a special Process that describes a reusable cluster of Activities in common process areas that produces a result of observable value.<!-- END:briefDescription,1.7072348895114264E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zag6RdnmEdmO6L4XMImrsA CRC: 3921446002 --><a id="XE_WORKFLOW__KEY_CONCEPTS" name="XE_workflow__key_concepts"></a>
+<p>
+ Capabilities Patterns express and communicate process knowledge for a key area of interest such as a Discipline
+ or a practice and can be directly used by process practitioners to guide their work. They are also used as
+ building blocks to assemble <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Processes</a> or larger Capability Patterns ensuring optimal reuse and
+ application of the key practices they express.
+</p>
+<p>
+ Examples for Capability Pattern could be 'use case-based requirements management', 'use case analysis', or 'unit
+ testing'. Typically but not necessarily, Capability Patterns have the scope of one Discipline providing a breakdown of
+ reusable complex Activities, relationships to the Roles which perform Tasks within these Activities, as well as to the
+ Work Products that are used and produced. Generally, a Capability Pattern does not relate to any specific phase
+ or iteration of a development lifecycle, and should not imply any. In other words, a pattern should be designed
+ in a way that it is applicable anywhere in a Delivery Process. This enables its Activities to be flexibly
+ assigned to whatever phases there are in the Delivery Process to which it is being applied. An exception to this
+ would be capability patterns that are intended to provide a template for quickly creating an iteration or portion of an
+ iteration for a particular phase in a Delivery Process.<br />
+ <br />
+ Key applications or areas of reuse for Capability Patterns are:
+</p>
+<ul>
+ <li>
+ To serve as building blocks for assembling Delivery Processes or larger Capability Patterns. Normally
+ developing a Delivery Process is not done from scratch but by systematically applying and binding patterns.
+ </li>
+ <li>
+ To support direct execution in a development project that does not work following a well-defined process, but works
+ based on loosely connected process fragments of practices in a flexible manner (for example, Agile Development).
+ </li>
+ <li>
+ To support process education by describing knowledge for a key area such as practices on how to perform the work
+ for a Discipline (for example, Requirements Management), for a specific development technique (aspect-oriented
+ development), or a specific technical area (for example, relational database design), which is used for education
+ and teaching.<br />
+ </li>
+</ul>
+<p>
+ The workflow of a Capability Pattern is usually represented using the UML Activity Diagram notation.
+</p>
+<p align="center">
+ <img alt="Sample activity diagram representing the workflow of a Capability Pattern" src="resources/wf_req.gif" />
+</p>
+<p>
+ <font size="1">Sample activity diagram representing the workflow of a Capability Pattern</font>.<br />
+</p>
+<br />
+<br /><!-- END:mainDescription,_zag6RdnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/checklist.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/checklist.html
new file mode 100644
index 0000000..4f5aaf8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/checklist.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\checklist.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: checklist.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2vVuUBT9EdqrUt4zetC1gg CRC: 3734564748 -->Checklist<!-- END:presentationName,_2vVuUBT9EdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_2vVuUBT9EdqrUt4zetC1gg CRC: 812407051 -->A Checklist identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as walkthroughs or inspections.<!-- END:briefDescription,_2vVuUBT9EdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_2wY3MBT9EdqrUt4zetC1gg CRC: 2358859780 --><p>
+ In UMA, a Content Element has at most one Checklist. Checklists, are useful in a number of contexts: they help you
+ decide what to do, they help doing it, they help assess the quality of the work, and they help understand how a
+ particular Work Product relates to the rest of the process.<!--EndFragment-->
+</p>
+<p>
+ Work products typically have an associated Checklist which present information on how to develop, evaluate and
+ use them .
+</p><!-- END:mainDescription,_2wY3MBT9EdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/composite_role.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/composite_role.html
new file mode 100644
index 0000000..64a3362
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/composite_role.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\composite_role.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: composite_role.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_P9gp0BtHEdqSLrJ4Ij2LVA CRC: 4237901683 -->Composite Role<!-- END:presentationName,_P9gp0BtHEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_P9gp0BtHEdqSLrJ4Ij2LVA CRC: 1553505890 -->A Composite Role is a special Role Descriptor that relates to more than one Role. It represents a grouping of Roles with the main purpose of reducing the number of Roles defined in Method Content for a Process.<!-- END:briefDescription,_P9gp0BtHEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-FD4UbInbyzlaGxB9oPHdcg CRC: 2643451568 --><p>
+ A Composite Role is a grouping of Roles that can be used in an Activity or Process to reduce the number of Roles. A
+ Composite Role is thus for the Tasks and Work Products defined for the Roles it refers to. A typical use of this
+ construct occurs within a Process designed for a small team in which multiple standard Roles from the Method Content
+ are assigned to a single resource. By using a Composite Role the Process suggests a typical clustering of Roles to
+ Resources.<br />
+</p>
+<p>
+ A simple example is a Composite Role named <em><strong>Developer</strong></em> that groups together the
+ <em><strong>Implementer</strong></em> and <em><strong>Tester</strong></em> Roles. Now, every time one of the Roles
+ Implementer or Tester would normally be used within the breakdown structure, Developer is used instead. Hence, if a
+ Task Descriptor is added to the Process, that has Implementer or Tester as the primary performer, this Role would be
+ automatically be substituted by the Composite Role instance Developer that links back to either Tester or
+ Implementer (or both if both were listed as the Task performers).
+</p><!-- END:mainDescription,-FD4UbInbyzlaGxB9oPHdcg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/configuration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/configuration.html
new file mode 100644
index 0000000..5ab076d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/configuration.html
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\configuration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: configuration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d698IBUFEdqrUt4zetC1gg CRC: 623536939 -->Method Configuration<!-- END:presentationName,_d698IBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_d698IBUFEdqrUt4zetC1gg CRC: 2337220486 -->A Method Configuration specifies the selection of a logical subset of a Method Library.<!-- END:briefDescription,_d698IBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_d7QQABUFEdqrUt4zetC1gg CRC: 3668149071 --><p>
+ A Method Configuration is a collection of selected <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+ guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugins</a>, <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/customcategories/method_package,_R5Vk4BtpEdqSLrJ4Ij2LVA.html"
+ guid="_R5Vk4BtpEdqSLrJ4Ij2LVA">Method Packages</a> and Processes (see <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Concept: Capability Pattern</a>, <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Concept: Delivery Process</a>). A Configuration can be exported into its own stand-alone
+ library when it includes the full transitive closure of all elements it depends on. A Method Configuration defines a
+ logical subset of a <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/method_library,_m8lGkBUFEdqrUt4zetC1gg.html"
+ guid="_m8lGkBUFEdqrUt4zetC1gg">Method Library</a>.
+</p>
+<h3>
+ Applications
+</h3>
+<p>
+ A Configuration is often built around one or more Delivery Processes. A Delivery Process can be valid for different
+ Method Configurations, but each Configuration may include or exclude particular content for specific situations. For
+ example, a Delivery Process can be defined to include content for developing schemas for different types of database
+ management systems, such as content for RDBMS and OODBMS. When using such a Delivery Process, users may want to select
+ just the type of DBMS used within their project, and hence exclude all content pertaining to other types of DBMS. They
+ achieve this by selecting a Configuration which excludes the respective content or by creating a new one if none such
+ already exists.<br />
+</p><!-- END:mainDescription,_d7QQABUFEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/content_package.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/content_package.html
new file mode 100644
index 0000000..f64dd1d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/content_package.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\content_package.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content_package.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_49a10BUFEdqrUt4zetC1gg CRC: 862468632 -->Content Package<!-- END:presentationName,_49a10BUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_49a10BUFEdqrUt4zetC1gg CRC: 4197752791 -->A Content Package is a special Method Package that contains Content Elements exclusively. Examples for Content Element are Artifacts, Tasks, Roles, and so on.<!-- END:briefDescription,_49a10BUFEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/custom_category.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/custom_category.html
new file mode 100644
index 0000000..9c73084
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/custom_category.html
@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\custom_category.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: custom_category.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_xuO10BUGEdqrUt4zetC1gg CRC: 3174542953 -->Custom Category<!-- END:presentationName,_xuO10BUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_xuO10BUGEdqrUt4zetC1gg CRC: 2795397800 -->Custom categories are used to categorize content based on the user's criteria. One important use is for constructing Views.<!-- END:briefDescription,_xuO10BUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_xuhJsBUGEdqrUt4zetC1gg CRC: 588826917 --><p>
+ A Custom Category is a category introduced by a method author to structure any number of Method Content Elements of any
+ type based on user-defined criteria. Custom categories can be used to categorize content based on the user's criteria
+ as well as to define whole tree-structures of nested categories allowing the user to systematically navigate and browse
+ Method Content and Processes based on these categories. This application of Custom Categories is also called <a
+ class="elementLink" href="./../../../base_concepts/guidances/concepts/view,_uMKSsBUFEdqrUt4zetC1gg.html"
+ guid="_uMKSsBUFEdqrUt4zetC1gg">View</a>.
+</p>
+<h3>
+ Examples
+</h3>
+<p>
+ One could create a Custom Category to logically organize content relevant for the user development organization's
+ departments: A "Testing" category would group together all Roles, Work Products, Tasks, Capability Patterns and
+ Guidance relevant to testing.
+</p>
+<p>
+ Another example would be categories that express licensing levels of the content: These categories would separate
+ freely distributable Method Content from Method Content that represents intellectual property and requires a purchased
+ license for use.
+</p><!-- END:mainDescription,_xuhJsBUGEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/deliverable.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/deliverable.html
new file mode 100644
index 0000000..e092970
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/deliverable.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\deliverable.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: deliverable.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_lBgkMBUJEdqrUt4zetC1gg CRC: 669068182 -->Deliverable<!-- END:presentationName,_lBgkMBUJEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_lBgkMBUJEdqrUt4zetC1gg CRC: 2508035364 -->A Deliverable is a Work Product that provides a description and definition for packaging other Work Products, and may be delivered to an internal or external party.<!-- END:briefDescription,_lBgkMBUJEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_lBy4EBUJEdqrUt4zetC1gg CRC: 3995406675 --><p>
+ A deliverable is a Work Product that provides a description and definition for packaging other Work Products, and may
+ be delivered to an internal or external party. Therefore, a Deliverable aggregates other Work Products.
+</p>
+<p>
+ A Deliverable is used to pre-define typical or recommended content in the form or work products that would be packaged
+ for delivery. The actual content and packaging of the Deliverable may need to be modified for individual projects
+ based on these recommendations. Deliverables are used to represent an output from a process that has value,
+ material or otherwise, to a client, customer or other stakeholder.
+</p><!-- END:mainDescription,_lBy4EBUJEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/delivery_process.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/delivery_process.html
new file mode 100644
index 0000000..928e1bc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/delivery_process.html
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\delivery_process.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: delivery_process.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_EhgqwO8MEdmKSqa_gSYthg CRC: 569468565 -->Delivery Process<!-- END:presentationName,_EhgqwO8MEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_EhgqwO8MEdmKSqa_gSYthg CRC: 2532782997 -->A Delivery Process is a special Process describing a complete and integrated approach for performing a specific type of project.<!-- END:briefDescription,_EhgqwO8MEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_EijzoO8MEdmKSqa_gSYthg CRC: 951789511 --><p>
+ A Delivery Process is a special <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific
+ project type. <!--StartFragment-->It provides a complete lifecycle model that has been detailed by sequencing Method
+ Content in breakdown structures. It describes a complete project lifecycle end-to-end and is used as a reference for
+ running projects with similar characteristics.
+</p>
+<p>
+ A process engineer can define alternative Delivery Processes for software development projects that differ in the
+ scale of the engagement and staffing necessary, the type of the software application to be developed, the development
+ methods and technologies to be used, etc. Although, the Delivery Process aims to cover a whole project it keeps certain
+ decision that are too project specific open. For example, the breakdown structure defines which Breakdown
+ Elements have multiple occurrences or are repeatable via its specific attributes, but does not say how many occurrences
+ and how many repeats/iterations it will have. These decisions have to be done by a project manager when planning
+ a concrete project, project phase, or project iterations.<!--EndFragment-->
+</p>
+<h3>
+ <a id="Software Engineering Process" name="Software Engineering Process">Example</a>
+</h3>
+<p>
+ In software engineering, the goal is to build a software product or to enhance an existing one. The Delivery Process
+ for software could be an iterative process, where the product is built incrementally over time, or it could be a
+ traditional waterfall Delivery Process in which all requirements are specified up front, followed by design,
+ implementation, and test phases.
+</p><!-- END:mainDescription,_EijzoO8MEdmKSqa_gSYthg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/descriptor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/descriptor.html
new file mode 100644
index 0000000..5784407
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/descriptor.html
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\descriptor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: descriptor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_5V9HEBUEEdqrUt4zetC1gg CRC: 1288664530 -->Descriptor<!-- END:presentationName,_5V9HEBUEEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_5V9HEBUEEdqrUt4zetC1gg CRC: 645784896 -->A Descriptor is a Process Element that represents the use or application of a Method Content element in the Process. The Descriptor provides the ability to override or add to what is defined in the original Method Content Element. Descriptors include Role, Task, and Work Product Descriptors.<!-- END:briefDescription,_5V9HEBUEEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_5WJUUBUEEdqrUt4zetC1gg CRC: 1570848620 --><p>
+ A Descriptor represent an occurrence of one concrete Content Element (such as Task, Role, Work Product) in an Activity.
+ Descriptors provides a proxy-like representation for these Content Elements within breakdown structures. In addition to
+ just referencing Content Elements it allows overriding the Content Elements' structural relationships by defining its
+ own sets of associations.
+</p>
+<p>
+ Descriptors are a key concept for realizing the separation of Processes from Method Content. A Descriptor can be
+ characterized as a reference object for one particular Content Element, which has its own relationships and properties.
+ When a Descriptor is created, it has the same relationships as the referenced Content Element. However, users can
+ modify these relationships for the particular process situation for which the Descriptor has been created. The
+ Descriptor concept allows defining new relationships and specific process related properties. Descriptors are not
+ Content Elements and do not contain their own full descriptions. They refer or trace back to the Content Elements they
+ are based on instead.
+</p>
+<h3>
+ Example
+</h3>
+<p align="center">
+ <img alt="Example of Method Content referenced by Descriptor" src="resources/descriptors_uml.gif" />
+</p>
+<p align="center">
+ Example of Method Content referenced by Descriptors
+</p>
+<p>
+ <br />
+ The above illustration depicts an example using the UML 2.0 profile representation for UMA in which Descriptors
+ have been created for a Task, its performing Roles, as well as its input/output Work Products. The situation implied by
+ this example is that the Task "Prioritize Use Cases" is to be performed differently in a project's Inception phase than
+ in its Elaboration phase. (that is, with different emphasis on different Steps, utilizing different inputs, etc.). In
+ particular, we can observe the following:
+</p>
+<ul>
+ <li>
+ The Task in Inception has an additional assisting Role (Customer.Project Manager) and does not provide a
+ relationship to the Risk List Work Product that had been defined as an optional input in the Method Content (that
+ is, Steps of the Task that work with the Risk List will be omitted in this phase).
+ </li>
+ <li>
+ Two different types of Use Case Model Work Products are distinguished here: a Use Case Model as it is normally
+ being used during Inception, which describes use cases only briefly, versus use cases that have been detailed as it
+ is the case during the Elaboration phase.
+ </li>
+</ul><!-- END:mainDescription,_5WJUUBUEEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/discipline.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/discipline.html
new file mode 100644
index 0000000..6358dbe
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/discipline.html
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\discipline.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: discipline.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.409251897849429E-305 CRC: 988016111 -->Discipline<!-- END:presentationName,3.409251897849429E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,3.409251897849429E-305 CRC: 1420814483 -->A Discipline is a categorization of Tasks based upon similarity of concerns and cooperation of work effort.<!-- END:briefDescription,3.409251897849429E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zag6Q9nmEdmO6L4XMImrsA CRC: 3041155420 --><a id="XE_DISCIPLINE__KEY_CONCEPTS" name="XE_discipline__key_concepts"></a>
+<p>
+ A Discipline is a collection of Tasks that are related to a major "area of concern" within the overall project. The
+ grouping of Tasks into Disciplines is mainly an aid to understanding the project from a traditional waterfall
+ perspective. Although it is more common to perform Tasks concurrently across several Disciplines (for example, certain
+ requirements Tasks are performed in close coordination with analysis and design Tasks), separating these Tasks into
+ distinct Disciplines is simply an effective way to organize content, which makes comprehension easier.
+</p>
+<p>
+ Another reason that several Tasks are all categorized by the same Discipline is that they all represent a part in
+ achieving a higher goal or performing work that is all related to each other. Every Discipline defines standard
+ ways of doing the work it categorizes. Such standard ways are expressed by so-called reference workflows
+ described with <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>s defining how the Tasks categorized by the Discipline 'work
+ together' in the most generic way. These reference workflows are often used for educating and teaching
+ practitioners.
+</p>
+<p>
+ Like other workflows, a Discipline's reference workflow is a semi-ordered sequence of activities presented as either a
+ breakdown structure or an activity diagram performed to achieve a particular result. The "semi-ordered" nature of
+ Discipline workflows emphasizes that the Discipline workflows cannot present the real nuances of scheduling "real
+ work", for they cannot depict the optionality of activities or iterative nature of real projects. Yet they still have
+ value as a way for us to understand the process by breaking it into smaller areas of concern.
+</p>
+<h4>
+ Example: The role of Disciplines in Software Engineering
+</h4>
+<p>
+ In Software Development, each Discipline has associated with it one or more 'models', which are in turn composed of
+ associated Work Products. Some fundamental disciplines identified in Software are:
+</p>
+<ul>
+ <li>
+ Business Modeling
+ </li>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Analysis and Design
+ </li>
+ <li>
+ Implementation
+ </li>
+ <li>
+ Test
+ </li>
+ <li>
+ Deployment
+ </li>
+ <li>
+ Configuration and Change Management
+ </li>
+ <li>
+ Project Management
+ </li>
+ <li>
+ Environment
+ </li>
+</ul><!-- END:mainDescription,_zag6Q9nmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/domain.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/domain.html
new file mode 100644
index 0000000..a56a7b3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/domain.html
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\domain.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: domain.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Dh4TEBUGEdqrUt4zetC1gg CRC: 2684689213 -->Domain<!-- END:presentationName,_Dh4TEBUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Dh4TEBUGEdqrUt4zetC1gg CRC: 358851948 -->Domain is a Standard Category that is a logical grouping of work products which have an affinity to each other based on resources, timing, or relationship.<!-- END:briefDescription,_Dh4TEBUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_DiKm8BUGEdqrUt4zetC1gg CRC: 713879051 --><p>
+ A Domain is a refineable hierarchy designed to classify related Work Products. In other words, Domains are organized
+ into trees where individual Work Products appear as the leaves. Conceptually, each Domain is a grouping of related Work
+ Products that tend to be used for a similar purpose.
+</p>
+<p>
+ A single Work Product can be categorized in only one Domain.
+</p><!-- END:mainDescription,_DiKm8BUGEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/example.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/example.html
new file mode 100644
index 0000000..8e7cf3e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/example.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\example.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: example.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_dCG-UBUBEdqrUt4zetC1gg CRC: 2706481667 -->Example<!-- END:presentationName,_dCG-UBUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_dCG-UBUBEdqrUt4zetC1gg CRC: 3651411836 -->This Guidance Type represents a typical, partially completed, sample instance of one or more Content Elements. Examples are most commonly provided for Work Products.<!-- END:briefDescription,_dCG-UBUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_dCTLkBUBEdqrUt4zetC1gg CRC: 2047048393 --><p>
+ An Example represents a typical, partially completed, sample instance of one or more Content Elements. Examples are
+ most commonly provided for Work Products. A Work Product Example is a good supplement to its prescriptive and
+ descriptive process Guidance.
+</p>
+<p>
+ Examples should be associated with specific Work Products to give their producer a view of how it should look like when
+ it is done.
+</p><!-- END:mainDescription,_dCTLkBUBEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/guideline.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/guideline.html
new file mode 100644
index 0000000..33e786a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/guideline.html
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\guideline.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: guideline.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_IAwkEBUEEdqrUt4zetC1gg CRC: 2491626041 -->Guideline<!-- END:presentationName,_IAwkEBUEEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_IAwkEBUEEdqrUt4zetC1gg CRC: 3408043865 -->This Guidance type provides additional detail on how to handle a particular Content Element. Guidelines most commonly apply to Tasks and Work Products.<!-- END:briefDescription,_IAwkEBUEEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_IBPFMBUEEdqrUt4zetC1gg CRC: 3318565613 --><p>
+ A Guideline usually focuses on how to perform a particular Task or grouping of Tasks (for example, grouped together as
+ activities) or provides additional detail, rules, and recommendations on Work Products and their properties. Guidelines
+ can include details about a variety of topics including:
+</p>
+<ul>
+ <li>
+ Practices and different approaches for doing work,
+ </li>
+ <li>
+ How to handle particular kinds of Content Elements,
+ </li>
+ <li>
+ Information on different subtypes and variants of Content Elements and how they evolve throughout a lifecycle,
+ </li>
+ <li>
+ Discussions on skills the performing Roles should acquire,
+ </li>
+ <li>
+ Measurements of progress and maturity, etc.
+ </li>
+</ul>
+<p>
+ Work products typically have associated guidelines which present information on how to develop, evaluate and use the
+ Work Products . Guidelines contain much of the substance of a method and provide assistance in a number of contexts:
+ they help you decide what to do, they help doing it, they help assess the quality of the work, and they help understand
+ how a particular Work Product relates to the rest of the process.
+</p><!-- END:mainDescription,_IBPFMBUEEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/introduction_to_uma.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/introduction_to_uma.html
new file mode 100644
index 0000000..edfc49c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/introduction_to_uma.html
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\introduction_to_uma.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: introduction_to_uma.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_94_eoO8LEdmKSqa_gSYthg CRC: 604804523 -->Key Capabilities of the Unified Method Architecture (UMA)<!-- END:presentationName,_94_eoO8LEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_94_eoO8LEdmKSqa_gSYthg CRC: 3104723937 -->The Unified Method Architecture (UMA) is a process engineering meta-model that defines schema and terminology for representing methods consisting of method content and processes.<!-- END:briefDescription,_94_eoO8LEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_972lYO8LEdmKSqa_gSYthg CRC: 2401130676 --><p>
+ The Unified Method Architecture (UMA) meta-model has been developed as 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. 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 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 Patterns and Delivery
+ Processes as well as specific reuse relationships between these type of processes. 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 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><!-- END:mainDescription,_972lYO8LEdmKSqa_gSYthg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/method_library.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/method_library.html
new file mode 100644
index 0000000..47a123f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/method_library.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\method_library.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_library.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_m8lGkBUFEdqrUt4zetC1gg CRC: 3527133579 -->Method Library<!-- END:presentationName,_m8lGkBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_m8lGkBUFEdqrUt4zetC1gg CRC: 4000022341 -->A Method Library is a physical container for Method Plug-ins and Method Configuration definitions. All Method Elements are stored in a Method Library.<!-- END:briefDescription,_m8lGkBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_m83acBUFEdqrUt4zetC1gg CRC: 2054508262 -->Method Libraries represent physical storage of all Content and Process Elements as well as <a class="elementLink"
+href="./../../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>s. A Method Library defines a closed universe for all elements in
+it, since library elements cannot refer to other libraries. All user-defined extensions to method content
+and processes have to be done with <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugins</a> within the same physical library.<!-- END:mainDescription,_m83acBUFEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/method_plugin.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/method_plugin.html
new file mode 100644
index 0000000..63f4148
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/method_plugin.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\method_plugin.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_plugin.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0KeEMBUFEdqrUt4zetC1gg CRC: 2385089299 -->Method Plugin<!-- END:presentationName,_0KeEMBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0KeEMBUFEdqrUt4zetC1gg CRC: 2594956519 -->A Method Plugin represents a physical container for Method Packages. It defines a largest granularity level for the modularization and organization of method content and processes.<!-- END:briefDescription,_0KeEMBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_0LCr8BUFEdqrUt4zetC1gg CRC: 1742179216 --><p>
+ Method Plugin conceptually represents a unit for configuration, modularization, extension, packaging, and deployment of
+ method content and processes. A Process Engineer shall design Plugins and allocate content to these Plugins
+ with requirements for extensibility, modularity, reuse, and maintainability in mind.
+</p>
+<p>
+ Plug-ins can directly contribute new content, replace existing content, or to cross-reference to any Content Element or
+ Process within another Plug-in that it extends. Similar to UML 2.0's 'package merge' mechanism transformation
+ interpretations, interpreting these Method Plug-in mechanisms results into new extended Method Content and
+ Processes. For example, a might contain additional steps for Tasks, new Work Products extensions to existing
+ Roles to be responsible for the new Work Products, additional relationships of existing Content Elements to new
+ specific Guidance elements (such as Guidelines, White Papers, Checklists), additional Activities for a Delivery
+ Process, new Capability Patterns, etc. A Method Plug-in defines these extension using Variability Element
+ relationships and interpretation of these leads to new Method Content and Processes.
+</p><!-- END:mainDescription,_0LCr8BUFEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/outcome.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/outcome.html
new file mode 100644
index 0000000..3417ec4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/outcome.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\outcome.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: outcome.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_pROF4BUJEdqrUt4zetC1gg CRC: 4278277214 -->Outcome<!-- END:presentationName,_pROF4BUJEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_pROF4BUJEdqrUt4zetC1gg CRC: 1730412848 -->An Outcome describes intangible Work Products that are a result or state.<!-- END:briefDescription,_pROF4BUJEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_pRmgYBUJEdqrUt4zetC1gg CRC: 374288753 --><p>
+ An Outcome describes intangible Work Products that are a result or state, such as an installed server or optimized
+ network. As the occurrence of an Outcome is often informally documented (for example, through minutes or memos),
+ Outcomes may also be used to describe Work Products that are not formally defined. A key differentiator for
+ Outcomes against Artifacts is that Outcomes are not candidates for harvesting as reusable assets. Outcomes can
+ not have associated templates or examples and are not possible to reuse as assets on other projects.
+</p><!-- END:mainDescription,_pRmgYBUJEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/phase.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/phase.html
new file mode 100644
index 0000000..88938ad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/phase.html
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\phase.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: phase.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__7xOEC7aEdqHMdmRzC0-2g CRC: 1887238607 -->Phase<!-- END:presentationName,__7xOEC7aEdqHMdmRzC0-2g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__7xOEC7aEdqHMdmRzC0-2g CRC: 924176065 -->This guidance introduces the concept of a phase and its purpose within a project.<!-- END:briefDescription,__7xOEC7aEdqHMdmRzC0-2g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-bhzuf6RMHP3d-AHkoKDg7g CRC: 848605003 --><h3>
+ What is a Phase?
+</h3>
+<p>
+ While the entire purpose of a project is to produce a product, the specific goals of the team will vary substantially
+ throughout the project. In the beginning, there usually is considerable latitude in the requirements for the product.
+ It may not be clear whether the project is feasible or even if it is likely to be profitable. At that time, it is
+ critical to bring an answer to these questions, and of little to no value to start developing the product in
+ earnest. Towards the end of the project, the product itself is usually complete, and issues of quality, delivery,
+ and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work
+ products will have new content.
+</p>
+<p>
+ To coordinate the team’s efforts in a manner that takes these fundamental observations into account, the project
+ lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, its own iteration style
+ and customized <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">tasks</a> and <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">work products</a> to address the unique needs of the project at that point in time.
+</p>
+<p>
+ We recommend dividing the project lifecycle into four phases: Inception, Elaboration, Construction and
+ Transition.
+</p>
+<h3>
+ Iteration and Phases
+</h3>
+<p>
+ Each phase is divided into iterations. An iteration is a complete development loop resulting in a build (internal or
+ external) of an executable system, usually a subset of the final product under development, which grows incrementally
+ from iteration to iteration to become the final product.<br />
+</p><!-- END:mainDescription,-bhzuf6RMHP3d-AHkoKDg7g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/practice.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/practice.html
new file mode 100644
index 0000000..dd44870
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/practice.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\practice.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: practice.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_szl6EBUBEdqrUt4zetC1gg CRC: 2258261528 -->Practice<!-- END:presentationName,_szl6EBUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_szl6EBUBEdqrUt4zetC1gg CRC: 1134261397 -->This Guidance Type presents a proven way or strategy of doing work to achieve a goal that has a positive impact on Work Product or process quality.<!-- END:briefDescription,_szl6EBUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_s0dcwBUBEdqrUt4zetC1gg CRC: 1560063936 --><p>
+ Practices are orthogonal to methods and processes. They often summarize aspects that impact many different parts of a
+ method or specific processes.
+</p>
+In Software Engineering, examples for practices include:
+<ul>
+ <li>
+ Manage Risks,
+ </li>
+ <li>
+ Continuously verify quality,
+ </li>
+ <li>
+ Architecture-centric and component-based development, etc.
+ </li>
+</ul><!-- END:mainDescription,_s0dcwBUBEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/process_contribution.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/process_contribution.html
new file mode 100644
index 0000000..40bb5c2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/process_contribution.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\process_contribution.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: process_contribution.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NYASQBtqEdqSLrJ4Ij2LVA CRC: 532834662 -->Process Contribution<!-- END:presentationName,_NYASQBtqEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_NYASQBtqEdqSLrJ4Ij2LVA CRC: 3279084604 -->A Process Contribution is a special Process that externally defines additions and changes to an existing Process without directly modifying it.<!-- END:briefDescription,_NYASQBtqEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-x11qt8TVnuIKeMC69UP1TQ CRC: 1071435359 --><p>
+ A Process Contribution is a special Process that externally defines additions and changes to an existing Process
+ without directly modifying the existing Process. It achieves this by describing these additions and changes in a
+ separate Process structure. This structures' elements relate to the other Process's elements using "Contributes" and
+ "Replace" specializations. Process Contributions are normally packaged with Method Plug-ins that extend existing Method
+ Plug-in with new capabilities.
+</p>
+<p>
+ A Process Contribution is a kind of "process plug-in" that plugs additional breakdown structures into an existing
+ Process and therefore updates it afterwards with new or changed capabilities. For example, the J2EE Plug-in plugs into
+ the technology independent main Plug-in. It may update the generic Delivery Processes defined in that Plug-in with J2EE
+ specific Activities. A respective ".NET Plug-in" could define similar updates relevant for that technology platform. A
+ process practitioner could then apply the chosen Plug-in, thereby generating a technology specific Process, but keeping
+ maintenance of his/her Processes minimal, because technology specific parts are kept separate and will be applied on
+ demand only.
+</p><!-- END:mainDescription,-x11qt8TVnuIKeMC69UP1TQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/process_package.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/process_package.html
new file mode 100644
index 0000000..32f30a8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/process_package.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\process_package.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: process_package.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MT6U8BneEdqYreeU3jqaDQ CRC: 2753051006 -->Process Package<!-- END:presentationName,_MT6U8BneEdqYreeU3jqaDQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_MT6U8BneEdqYreeU3jqaDQ CRC: 1527626007 -->A Process Package is a special Method Package that contains Processes such as Capability Patterns or Delivery Processes only.<!-- END:briefDescription,_MT6U8BneEdqYreeU3jqaDQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/release.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/release.html
new file mode 100644
index 0000000..568faaa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/release.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\release.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: release.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_L5BIkC7uEdqHMdmRzC0-2g CRC: 1375353473 -->Release<!-- END:presentationName,_L5BIkC7uEdqHMdmRzC0-2g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_L5BIkC7uEdqHMdmRzC0-2g CRC: 2858251031 -->A Release is the delivery of a functional system meeting predefined objectives.<!-- END:briefDescription,_L5BIkC7uEdqHMdmRzC0-2g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dsgUC_uXte9wj6nt8DLHtw CRC: 756011317 --><p>
+ A release can be internal or external. An internal release is used only by the development organization, as part of a
+ milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to users. A
+ release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured
+ only from an engineering perspective. Releases act as a forcing function that drives the development team to get
+ closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome.
+</p>
+<p>
+ <a class="elementLinkWithType" href="./../../../base_concepts/guidances/concepts/iteration,3.379871268737602E-305.html"
+ guid="3.379871268737602E-305">Concept: Iteration</a>s and releases allow a better usage over time of the various
+ specialties in the team: designers, testers, writers, and so forth. Regular releases let you break down the integration
+ and test issues and spread them across the development cycle. These issues have often been the downfall of large
+ projects because all problems were discovered at once during the single massive integration step, which occurred very
+ late in the cycle, and where a single problem halts the whole team.
+</p>
+<p>
+ With each Release, many <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">Concept: Work Product</a>s are updated. It is said that this is a bit like "growing"
+ software. Instead of developing Work Products one after another, in a pipeline fashion, they are evolving across the
+ cycle, although at different rates.
+</p>
+<!--EndFragment--><!--EndFragment--><!--EndFragment--><!--EndFragment--><!-- END:mainDescription,-dsgUC_uXte9wj6nt8DLHtw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/report.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/report.html
new file mode 100644
index 0000000..459f0f1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/report.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\report.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: report.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_x2sAgBUBEdqrUt4zetC1gg CRC: 3280171698 -->Report<!-- END:presentationName,_x2sAgBUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_x2sAgBUBEdqrUt4zetC1gg CRC: 462740751 -->This Guidance Type is a predefined template of a result that is generated on the basis of other Work Products as an output from some form of tool automation.<!-- END:briefDescription,_x2sAgBUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_x2-UYBUBEdqrUt4zetC1gg CRC: 920961677 --><p>
+ An example for a report would be a use case model survey, which is generated by extracting diagram information from a
+ graphical model and textual information from documents and combines these two types of information into a report.
+</p>
+<p>
+ Unlike regular Work Products, reports are not subject to version control. However they may be baselined to provide a
+ historic audit trail of the report over time. In some cases, the development tools enable the report to be reproduced
+ at any time by rerunning the report against the Work product's History.
+</p><!-- END:mainDescription,_x2-UYBUBEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/descriptors_uml.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/descriptors_uml.gif
new file mode 100644
index 0000000..29dd96e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/descriptors_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/guidance_uml.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/guidance_uml.gif
new file mode 100644
index 0000000..21d2b32
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/guidance_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/overview.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/overview.gif
new file mode 100644
index 0000000..b898efd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/overview.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/wf_req.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/wf_req.gif
new file mode 100644
index 0000000..d48bef3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/resources/wf_req.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/reusable_asset.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/reusable_asset.html
new file mode 100644
index 0000000..08c14ea
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/reusable_asset.html
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\reusable_asset.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: reusable_asset.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_20bs4BUBEdqrUt4zetC1gg CRC: 3484502533 -->Reusable Asset<!-- END:presentationName,_20bs4BUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_20bs4BUBEdqrUt4zetC1gg CRC: 1808512967 -->This Guidance Type describes an asset that can be reused in a different context.<!-- END:briefDescription,_20bs4BUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_21rDABUBEdqrUt4zetC1gg CRC: 3653897479 --><p>
+ A Reusable Asset typically includes source code, templates, patterns, but may also include architectural
+ frameworks, domain models, and so on. A Reusable Asset has usage rules which are the instructions describing how
+ the asset should be used.
+</p><!-- END:mainDescription,_21rDABUBEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/roadmap.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/roadmap.html
new file mode 100644
index 0000000..f322c39
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/roadmap.html
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\roadmap.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: roadmap.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_JCQbIBnXEdqYreeU3jqaDQ CRC: 2893993839 -->Roadmap<!-- END:presentationName,_JCQbIBnXEdqYreeU3jqaDQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_JCQbIBnXEdqYreeU3jqaDQ CRC: 3135825525 -->This Guidance Type summarizes a Process, often from a particular perspective.<!-- END:briefDescription,_JCQbIBnXEdqYreeU3jqaDQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_JCivABnXEdqYreeU3jqaDQ CRC: 3165539577 --><p>
+ An instance of a Roadmap represents important documentation for the Activity or Process it is related to. Often a
+ complex Activity such as a Process can be much easier understood by providing a walkthrough with a linear thread of a
+ typical instantiation of this Activity.
+</p>
+<p>
+ In addition to making the process practitioner understand how work in the process is being performed, a Roadmap
+ provides additional information about how Activities and Tasks relate to each other over time. Roadmaps are also used
+ to show how specific aspects are distributed over a whole process providing a kind of filter on the Process for this
+ information.
+</p><!-- END:mainDescription,_JCivABnXEdqYreeU3jqaDQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/role.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/role.html
new file mode 100644
index 0000000..033448a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/role.html
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\role.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: role.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.1609745730665898E-304 CRC: 4149945684 -->Role<!-- END:presentationName,1.1609745730665898E-304 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,1.1609745730665898E-304 CRC: 4077930178 -->A Role defines a set of related skills, competencies, and responsibilities.<!-- END:briefDescription,1.1609745730665898E-304 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zaqEMtnmEdmO6L4XMImrsA CRC: 3663258544 --><a id="Top" name="Top"></a><a id="XE_key_concepts__role" name="XE_key_concepts__role"></a><a id="XE_role__key_concepts"
+name="XE_role__key_concepts"></a>
+<p>
+ A Role is a Method Content element that defines a set of related skills, competencies, and responsibilities. Roles are
+ used by Tasks to specify who performs them as well as define a set of Work Products they are responsible for.
+</p>
+<p class="node" align="left">
+ Roles are typically realized by an individual, or a set of individuals, working together as a team. A project team
+ member typically fulfills many different roles. Note that <b>Roles are not individuals nor are they necessarily
+ equivalent to job titles;</b> instead, they describe how individuals should behave in the project and the
+ responsibilities of an individual. Individual members of the organization will wear different hats, or perform
+ different Roles. The mapping from individual to Role is performed by the project manager when planning and staffing the
+ project.
+</p>
+<p class="node" align="left">
+ While most roles are realized by people within the organization, people outside of the development organization play an
+ important role: for example, that of the stakeholder of the project or product being developed.
+</p><!-- END:mainDescription,_zaqEMtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/role_set.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/role_set.html
new file mode 100644
index 0000000..0e91d6e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/role_set.html
@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\role_set.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: role_set.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_u3t7sBUGEdqrUt4zetC1gg CRC: 2685482450 -->Role Set<!-- END:presentationName,_u3t7sBUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_u3t7sBUGEdqrUt4zetC1gg CRC: 418956553 -->This Standard Category organizes Roles into categories.<!-- END:briefDescription,_u3t7sBUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_u4APkBUGEdqrUt4zetC1gg CRC: 3029262936 --><p>
+ Role Sets are used to group Roles together that have certain commonalities.
+</p>
+<p>
+ For example, in Software Engineering, the "Analysts" Role Set could group the
+</p>
+<ul>
+ <li>
+ Business Process Analyst
+ </li>
+ <li>
+ System Analyst
+ </li>
+ <li>
+ Requirements Specifier
+ </li>
+</ul>
+<p>
+ All of these Roles work with similar techniques and have overlapping skills, but are required to be
+ distinct by the software engineering method.
+</p><!-- END:mainDescription,_u4APkBUGEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/supporting_material.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/supporting_material.html
new file mode 100644
index 0000000..3f07d4b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/supporting_material.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\supporting_material.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_material.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_80XPABUBEdqrUt4zetC1gg CRC: 819415298 -->Supporting Material<!-- END:presentationName,_80XPABUBEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_80XPABUBEdqrUt4zetC1gg CRC: 992742956 -->This Guidance Type is a catch-all for other types of Guidance not specifically defined elsewhere.<!-- END:briefDescription,_80XPABUBEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/task.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/task.html
new file mode 100644
index 0000000..593226f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/task.html
@@ -0,0 +1,156 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\task.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: task.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,7.624729048911575E-305 CRC: 4065096731 -->Task<!-- END:presentationName,7.624729048911575E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,7.624729048911575E-305 CRC: 4175284857 -->A Task describes a unit of work assigned to a Role that provides a meaningful result.<!-- END:briefDescription,7.624729048911575E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zaqENNnmEdmO6L4XMImrsA CRC: 891996363 --><a id="XE_ACTIVITY__KEY_CONCEPTS" name="XE_activity__key_concepts"></a>
+<h3>
+ Definition
+</h3>
+<p>
+ A Task describes a unit of work. Every Task is performed by specific Roles. The granularity of a Task is generally a
+ few hours to a few days. It usually affects one or only a small number of Work Products. Tasks are not necessarily used
+ as a basis for planning and tracking progress - they are often too fine-grained for that purpose; Activity
+ groupings of Tasks are often the better units for planning and tracking.
+</p>
+<p>
+ A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models,
+ classes, or plans. Within a Task, each performing Role achieves a well defined goal. A Task provides complete
+ step-by-step explanations of doing all the work required to achieve this goal. This description is complete,
+ independent of when in a process lifecycle the work would actually be done. Therefore, it does not describe when you do
+ what work at what point of time, but describes all the work that gets done throughout the development lifecycle that
+ contributes to the achievement of the Tasks' goal.
+</p>
+<p>
+ When a Task is being applied in a Process, a reference object defined as Task Descriptor provides information, which
+ includes what elements of the Task will actually be performed at that point in time. This assumes that a Task will
+ usually be performed in the Process over and over again, but each time with a slightly different emphasis on different
+ steps or aspects of the Task description as well as perhaps different or additional performing roles or different
+ input/output (also refer to <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html"
+ guid="_94_eoO8LEdmKSqa_gSYthg">Key Capabilities of the Unified Method Architecture (UMA)</a> for the difference between
+ Method Content and Process).
+</p>
+<h3>
+ Steps
+</h3>
+<p>
+ Tasks can be broken down into sections of Steps. A Step describes a meaningful and consistent part of the overall work
+ described for a Task. Steps fall into three main categories:
+</p>
+<ul>
+ <li>
+ <b>Thinking</b> Steps: where the individual performing the Role understands the nature of the Task, gathers and
+ examines the input Work Products, and formulates the result.
+ </li>
+ <li>
+ <b>Performing</b> Steps: where the individual performing the Role creates or updates some Work Products.
+ </li>
+ <li>
+ <b>Reviewing</b> Steps: where the individual performing the Role inspects the results against some criteria.
+ </li>
+</ul>
+<p>
+ Not all Steps are necessarily performed each time a Task is invoked, so they can be expressed in the form of alternate
+ flows (similar to Use Cases).
+</p>
+<h3>
+ Examples
+</h3>
+<h4>
+ A Typical Task
+</h4>
+<p>
+ A typical Task to "Develop Use-Case Model" would describe all the work that needs to be done to develop a complete
+ use-case model. This would consist of the following:
+</p>
+<ul>
+ <li>
+ The identification and naming of use cases and actors
+ </li>
+ <li>
+ The writing of a brief description
+ </li>
+ <li>
+ The modeling of use cases and their relationships in diagrams
+ </li>
+ <li>
+ The detailed description of a basic flow
+ </li>
+ <li>
+ The detailed description of alternative flows
+ </li>
+ <li>
+ Performing of walkthroughs, workshops and reviews, etc.
+ </li>
+</ul>
+<p>
+ All of these parts contribute to the development goal of developing the use case model, but the parts will be performed
+ at different points in time in a Process. Identification, naming, and brief descriptions would be performed
+ <strong>early</strong> in a typical development process versus the writing of detailed alternative flows which would be
+ performed much <strong>later</strong>. All these parts or Steps within the same Task define the "method" of developing
+ a use-case model. Applying such a method in a lifecycle is defining which Steps are done when going from one iteration
+ to the next.
+</p>
+<h4>
+ A Task and its Steps
+</h4>
+<p class="example">
+ A typical Task to "Find Use Cases and Actors" would be decomposed into the following Steps:
+</p>
+<blockquote>
+ <blockquote>
+ <ol>
+ <li>
+ Find actors
+ </li>
+ <li>
+ Find use cases
+ </li>
+ <li>
+ Describe how actors interact with use cases
+ </li>
+ <li>
+ Package use cases and actors
+ </li>
+ <li>
+ Present the use-case model in use-case diagrams
+ </li>
+ <li>
+ Develop a survey of the use-case model
+ </li>
+ <li>
+ Evaluate your results
+ </li>
+ </ol>
+ </blockquote>
+</blockquote>
+<p class="example">
+ The finding part [Steps 1 to 3] requires some thinking; the performing part [Steps 4 to 6] involves capturing the
+ result in the use-case model; the reviewing part [Step 7] is where the individual performing the Role evaluates the
+ result to assess completeness, robustness, intelligibility, or other qualities.
+</p><!-- END:mainDescription,_zaqENNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/team_profile.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/team_profile.html
new file mode 100644
index 0000000..889e87b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/team_profile.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\team_profile.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: team_profile.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_dRKRMBtHEdqSLrJ4Ij2LVA CRC: 3704797792 -->Team Profile<!-- END:presentationName,_dRKRMBtHEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_dRKRMBtHEdqSLrJ4Ij2LVA CRC: 2995988243 -->A Team Profile is a Breakdown Element that groups Role Descriptors or Composite Roles, thus defining a nested hierarchy of teams and team members.<!-- END:briefDescription,_dRKRMBtHEdqSLrJ4Ij2LVA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-J7jcN9p3FRyhuwV5Hq42Kw CRC: 3853389569 --><p>
+ Work assignments and Work Product responsibilities can be different from Activity to Activity in a development project.
+ Different phases require different staffing profiles, that is, different skills and resources doing different types of
+ work. Therefore, a Process needs to define these profiles in a flexible manner. Whereas Core Method Content defines
+ standard responsibilities and assignments, a Process expressed in breakdown structures needs to be able to refine and
+ redefine these throughout its definition.
+</p>
+<p>
+ Role Descriptors, Composite Roles, as well as Team Profiles provide the data structure necessary to achieve this
+ flexibility and to provide Process users with the capability to define different teams and Role relationships for
+ every Activity (including Activities on any nesting level as well as Iterations or Phases). Hence, in addition to the
+ work breakdown and Work Product breakdown structures, Team Profiles are used to define a third type of breakdown
+ structure: The Team Breakdown Structure. It is created as an Activity specific hierarchy of Team Profiles comprising of
+ Role Descriptors and Composite Roles. These structures can be presented as Org-Charts.<br />
+</p><!-- END:mainDescription,-J7jcN9p3FRyhuwV5Hq42Kw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/template.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/template.html
new file mode 100644
index 0000000..965670e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/template.html
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\template.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: template.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_G_UnIBUCEdqrUt4zetC1gg CRC: 1846967765 -->Template<!-- END:presentationName,_G_UnIBUCEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_G_UnIBUCEdqrUt4zetC1gg CRC: 589369218 -->This Guidance Type specifies the structure of a Work Product by providing a pre-defined table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions how the sections and packages are supposed to be used and completed.<!-- END:briefDescription,_G_UnIBUCEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_G_m7ABUCEdqrUt4zetC1gg CRC: 477927574 --><p>
+ Templates are "models," or prototypes, of Work Products. Within a Work Product description, there usually are one or
+ more templates that can be used to create the corresponding Work Product. Templates are linked to the tool that is to
+ be used to create the Work Product. Prior to project start, organizations may want to customize the templates by adding
+ the company logo, some project identification, or information specific to the type of project.
+</p>
+<h3>
+ Example:
+</h3>
+<ul>
+ <li>
+ Word processor tools templates can be used for Work Products that are documents, and for some reports.
+ </li>
+ <li>
+ Automated report generation tools templates extract information from tools such as visual modeling tools,
+ requirements management tools or testing tools.
+ </li>
+ <li>
+ HTML tool templates for the various elements of the process.
+ </li>
+ <li>
+ Project planning tool template for the project plan.
+ </li>
+</ul><!-- END:mainDescription,_G_m7ABUCEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/term_definition.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/term_definition.html
new file mode 100644
index 0000000..6b7a446
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/term_definition.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\term_definition.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: term_definition.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Z45fwBUDEdqrUt4zetC1gg CRC: 4117105778 -->Term Definition<!-- END:presentationName,_Z45fwBUDEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Z45fwBUDEdqrUt4zetC1gg CRC: 3136344225 -->This Guidance Type defines concepts that are used to build up the Glossary.<!-- END:briefDescription,_Z45fwBUDEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/tool.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/tool.html
new file mode 100644
index 0000000..370c18b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/tool.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\tool.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: tool.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_66Jy0BUGEdqrUt4zetC1gg CRC: 2160169455 -->Tool<!-- END:presentationName,_66Jy0BUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_66Jy0BUGEdqrUt4zetC1gg CRC: 3472844507 -->This Standard Category is a container for Tool Mentors. It can also provide general descriptions of the tool and its general capabilities.<!-- END:briefDescription,_66Jy0BUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_66cGsBUGEdqrUt4zetC1gg CRC: 1601361679 --><p>
+ <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/tool_mentor,1.0762105093945226E-304.html"
+ guid="1.0762105093945226E-304">Tool Mentors</a> are a guidance type that define how work described with <a
+ class="elementLinkWithUserText" href="./../../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">Tasks</a> or <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html"
+ guid="3.132140065969088E-305">Activities</a> is to be performed using a specific tool. Every Tool Mentor
+ shall therefore be categorized by exactly one Tool category.
+</p><!-- END:mainDescription,_66cGsBUGEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/tool_mentor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/tool_mentor.html
new file mode 100644
index 0000000..b1be00a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/tool_mentor.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\tool_mentor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: tool_mentor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.0762105093945226E-304 CRC: 2119451873 -->Tool Mentor<!-- END:presentationName,1.0762105093945226E-304 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,1.0762105093945226E-304 CRC: 633089439 -->This Guidance Type shows how to use a specific tool to create part of a Work Product either in the context of or independently from a Task or Activity.<!-- END:briefDescription,1.0762105093945226E-304 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zaz1MtnmEdmO6L4XMImrsA CRC: 2198125264 --><a id="Top" name="Top"></a><a id="XE_key_concepts__tool_mentor" name="XE_key_concepts__tool_mentor"></a><a
+id="XE_TOOL_MENTOR__KEY_CONCEPTS" name="XE_tool_mentor__key_concepts"></a>
+<p>
+ Tasks, Steps, and associated guidelines provide general guidance to the practitioner. To go one step further, Tool
+ Mentors are an additional means of providing guidance by showing how to achieve certain goals with a specific software
+ tool. Tool mentors link Tasks with tools such as visual modeling tools, requirements management tools, configuration
+ management tools, change requests/tracking tools and automated testing tools. Tool Mentors almost completely
+ encapsulate the dependencies of the content on the tool set, keeping the tasks free from tool details. An organization
+ can extend the concept of Tool Mentor to provide guidance for other tools.
+</p><!-- END:mainDescription,_zaz1MtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/view.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/view.html
new file mode 100644
index 0000000..865917e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/view.html
@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\view.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: view.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uMKSsBUFEdqrUt4zetC1gg CRC: 1590625456 -->View<!-- END:presentationName,_uMKSsBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_uMKSsBUFEdqrUt4zetC1gg CRC: 628957223 -->Views are structured content collections designed to drive publication and facilitate browsing. They are specified using Custom Categories.<!-- END:briefDescription,_uMKSsBUFEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_uMcmkBUFEdqrUt4zetC1gg CRC: 1803217125 --><p>
+ Views are tabs that appear at the top of the tree browser within a published site. They identify pre-arranged
+ structured collections of content designed to facilitate its browsing by process users and practitioners.
+</p>
+<p>
+ A View is specified by defining a nested structure of <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/custom_category,_xuO10BUGEdqrUt4zetC1gg.html"
+ guid="_xuO10BUGEdqrUt4zetC1gg">Custom Categories</a> containing references to the Content Elements one desires to
+ publish within the view. Structurally, Views represent a selection of Custom Categories for one specific <a
+ class="elementLink" href="./../../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+ guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>. In other words, every configuration defines its views by
+ referring to a set of Custom Categories.
+</p><!-- END:mainDescription,_uMcmkBUFEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/white_paper.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/white_paper.html
new file mode 100644
index 0000000..f12870a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/white_paper.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\white_paper.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: white_paper.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_id9REBUDEdqrUt4zetC1gg CRC: 3073592097 -->White Paper<!-- END:presentationName,_id9REBUDEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_id9REBUDEdqrUt4zetC1gg CRC: 778408482 -->This Guidance Type is an externally published paper that is incorporated as an attachment.<!-- END:briefDescription,_id9REBUDEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_iePk8BUDEdqrUt4zetC1gg CRC: 2397178889 --><p>
+ A whitepaper is a Guidance Type for externally published papers that can be read and understood in
+ isolation of other Content Elements and Guidance.
+</p><!-- END:mainDescription,_iePk8BUDEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/work_product.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/work_product.html
new file mode 100644
index 0000000..c281a6d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/work_product.html
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\work_product.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_product.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,4.804531471620803E-306 CRC: 2759712215 -->Work Product<!-- END:presentationName,4.804531471620803E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,4.804531471620803E-306 CRC: 2561412867 -->A Work Product is something meaningful resulting from a process: Roles use Work Products to perform Tasks and produce Work Products in the course of performing Tasks.<!-- END:briefDescription,4.804531471620803E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zaz1MNnmEdmO6L4XMImrsA CRC: 2852956286 --><a id="XE_ARTIFACT__KEY_CONCEPTS" name="XE_artifact__key_concepts"></a>
+<h3>
+ Work Product
+</h3>
+<p>
+ A Work Product is a general abstraction that represents something resulting from the process. Work Products
+ include:
+</p>
+<ul>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/artifact,_fdRfkBUJEdqrUt4zetC1gg.html"
+ guid="_fdRfkBUJEdqrUt4zetC1gg">Artifact</a>
+ </li>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/deliverable,_lBgkMBUJEdqrUt4zetC1gg.html"
+ guid="_lBgkMBUJEdqrUt4zetC1gg">Deliverable</a>
+ </li>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/outcome,_pROF4BUJEdqrUt4zetC1gg.html"
+ guid="_pROF4BUJEdqrUt4zetC1gg">Outcome</a>
+ </li>
+</ul>
+<p>
+ Tasks have input and output Work Products. Roles use Work Products to perform Tasks, and produce other Work Products in
+ the course of performing Tasks. Work Products are the responsibility of a single Role, making responsibility easy to
+ identify and understand, and promoting the idea that every piece of information produced in the process requires the
+ appropriate set of skills. Even though one Role may "own" the Work Product, other Roles will use the Work Product,
+ perhaps even updating it if the Role has been given permission to do so.
+</p>
+<p align="center">
+ <map id="FPMap1" name="FPMap1">
+ </map><img height="569"
+ alt="Popular Work Products in Software Development, and the approximate dependency relationships between them."
+ src="resources/overview.gif" width="536" usemap="#FPMap1" border="0" />
+</p>
+<p class="picturetext" align="center">
+ Popular Work Products in Software Development, and the approximate dependency relationships between them.
+</p>
+<p>
+ Note that "<b>Work Product</b> " is the term used to describe what other processes denote using terms such as
+ <b>Artifact</b>, <b>work unit</b>, and so on. In UMA, <b>Deliverables</b> are only considered to be the subset of all
+ Work Products that will end up being delivered into the hands of the customers and users, usually as part of a formal
+ or contractually agreed hand-over.
+</p><!-- END:mainDescription,_zaz1MNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/work_product_kind.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/work_product_kind.html
new file mode 100644
index 0000000..826efaf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/concepts/work_product_kind.html
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\concepts\work_product_kind.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_product_kind.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VRhkoBUGEdqrUt4zetC1gg CRC: 3304608769 -->Work Product Kind<!-- END:presentationName,_VRhkoBUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_VRhkoBUGEdqrUt4zetC1gg CRC: 1586556155 -->This Standard Category represents a grouping of related Work Products which, in contrast to Domain, is more presentation oriented.<!-- END:briefDescription,_VRhkoBUGEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_VRz4gBUGEdqrUt4zetC1gg CRC: 2663766160 --><p>
+ Work Products may take various shapes or forms, such as:
+</p>
+<ul>
+ <li>
+ A <b>model</b>, such as the Use-Case Model or the Design Model, which contains other Artifacts.
+ </li>
+ <li>
+ A <b>model element</b>; that is, an element within a model, such as a Design Class, a Use-Case or a Design
+ Subsystem.
+ </li>
+ <li>
+ <strong>Project data</strong> that might be kept in databases or other types of tabular information repositories
+ such as spreadsheets.
+ </li>
+ <li>
+ Source code and executable programs that contribute to the product or <strong>Solution.</strong>
+ </li>
+ <li>
+ Various types of documents, for example a <strong>specification</strong> document<strong>,</strong> such as
+ Requirements Specification, or a <strong>plan</strong> document, such as the Software Requirements Plan.
+ </li>
+</ul>
+<p>
+ They can therefore be categorized accordingly. An example is "<strong>Specification</strong>", which categorizes
+ requirements specifications that define a system with a well-defined system boundary, such as use case or functional
+ requirements specification. Unlike in Domains, a single Work Product can be categorized in multiple Work Product Kinds.
+</p><!-- END:mainDescription,_VRz4gBUGEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/about_base_concepts.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/about_base_concepts.html
new file mode 100644
index 0000000..6be8e9a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/about_base_concepts.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\supportingmaterials\about_base_concepts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: about_base_concepts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uvje4D_fEdqDFvujd6NHiA CRC: 2750340941 -->About Base Concepts<!-- END:presentationName,_uvje4D_fEdqDFvujd6NHiA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-V2B7_NtU_O7-45ldkX0Rrw CRC: 3792280299 --><h3>
+ <a id="version" name="version">Version Information</a>
+</h3>
+<p>
+ Version 0.9
+</p>
+<h3>
+ Content
+</h3>
+<p>
+ This plug-in is a formal introduction to the Unified Method Architecture (UMA).
+</p>
+<p>
+ It positions UMA in terms of its goals and its novel aspects and defines all fundamental abstractions central to
+ UMA.
+</p>
+<p>
+ It is not dependent upon any other plug-ins.
+</p>
+<h3>
+ Legal Statement
+</h3>
+<p class="node">
+ See <a href="resources/copyrite.htm">Intellectual Property Notices</a>.
+</p><!-- END:mainDescription,-V2B7_NtU_O7-45ldkX0Rrw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/copyright.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/copyright.html
new file mode 100644
index 0000000..5089167
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/copyright.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\supportingmaterials\copyright.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: copyright.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uuunoPsDEdmyhNQr5STrZQ CRC: 3127940944 -->Copyright<!-- END:presentationName,_uuunoPsDEdmyhNQr5STrZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_u_Zg4PsDEdmyhNQr5STrZQ CRC: 1190137423 --><p>
+ This program and the accompanying materials are made available under the<br />
+ <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a> which
+ accompanies this distribution.
+</p><!-- END:mainDescription,_u_Zg4PsDEdmyhNQr5STrZQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/keyword_index.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/keyword_index.html
new file mode 100644
index 0000000..45a147b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/keyword_index.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\supportingmaterials\keyword_index.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: keyword_index.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,2.0088322577945588E-305 CRC: 3864103749 -->Keyword Index<!-- END:presentationName,2.0088322577945588E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,2.0088322577945588E-305 CRC: 3242373814 -->The keyword index provides the ability to look-up topics based on keywords or topics.<!-- END:briefDescription,2.0088322577945588E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zZxTYNnmEdmO6L4XMImrsA CRC: 3248536962 --><p class="banner" align="left">
+ The keyword index provides the ability to look-up topics in the method website based on keywords or topics. At the time
+ the pages are created, keywords are identified which allows the keyword index to be built. The top frame of the keyword
+ index window allows topics beginning with a letter or number to be displayed. The lower frame displays a list of topics
+ and their related links. Clicking on a link causes the related page to be displayed in the main frame of the published
+ site browser window.
+</p>
+<p class="banner" align="left">
+ <br />
+</p><!-- END:mainDescription,_zZxTYNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/resources/copyrite.htm b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/resources/copyrite.htm
new file mode 100644
index 0000000..51edd3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/resources/copyrite.htm
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>IBM(R) Rational(R) Intellectual Property Notices and Other Licensing Requirements</title>
+</head>
+
+<body>
+NOTICES AND INFORMATION <br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+About This Content
+</p>
+<p>
+May 2, 2006
+</p>
+<p>
+License
+</p>
+<p>
+The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
+</p>
+<p>
+If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributors license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
+ <br>
+</BODY>
+</HTML>
\ No newline at end of file
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/search_engine.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/search_engine.html
new file mode 100644
index 0000000..8bc73b8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/search_engine.html
@@ -0,0 +1,173 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\supportingmaterials\search_engine.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: search_engine.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.1789140222665413E-305 CRC: 2679675795 -->Search Engine<!-- END:presentationName,3.1789140222665413E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,3.1789140222665413E-305 CRC: 2975096802 -->The search engine allows you to search for pages in the published Web Site.<!-- END:briefDescription,3.1789140222665413E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zZxTYtnmEdmO6L4XMImrsA CRC: 3469570655 --><p>
+ <a id="using" name="using"><strong>Note</strong>: The Search Engine, implemented as applets, requires JRE 1.4.2 or
+ higher (you can download a JRE from</a> <a href="http://java.sun.com/j2se"
+ target="_blank">http://java.sun.com/j2se</a><a id="using" name="using">).</a>
+</p>
+<h3>
+ Tips on Using the Search Engine
+</h3>
+<p>
+ The search engine allows you to search for pages in the published Web site in a number of ways. For example,
+ you can:
+</p>
+<ul>
+ <li>
+ Search for pages that contain <b>all</b> of the words that you have typed.
+ </li>
+ <li>
+ Search for pages that contain <b>any</b> of the words that you have typed.
+ </li>
+ <li>
+ Search for pages that contain the <b>exact phrase</b> that you have typed.
+ </li>
+ <li>
+ Search for pages that contain <b>none of the words</b> that you have typed.
+ </li>
+</ul>
+<p>
+ To enter a search query, type the words to be searched for in your choice of the <b>All the words</b>, <b>Any word</b>,
+ <b>Exact phrase</b>, and <b>Without the words</b> fields, and then press <tt>ENTER</tt> or click the <b>Search Now</b>
+ button. When the search is complete, each matching page will be listed in the <b>Results</b> field, showing the page
+ title and a short summary of the content. Click a title to open the page in your published siteWeb browser window.
+</p>
+<p>
+ For example, to search for pages that contain all of the words "Rational", "Unified", and "Process", and either or both
+ of the words "adopt" and "vision", type the words <tt>Rational Unified Process</tt> in the <b>All the words</b> field,
+ and <tt>adopt vision</tt> in the <b>Any word</b> field.
+</p>
+<p>
+ You can select how many results per page that you want by using the <b>Show</b> list. If the results are more than what
+ you selected to see per page, click the <b>next</b> and <b>previous</b> buttons to page through the results.
+</p>
+<p>
+ You can also indicate whether you want the query to be applied against the published web-site or developerWorks. To
+ choose between the published web-site and developerWorks, click the <b>In section</b> list, and then select the desired
+ section.
+</p>
+<h3>
+ <a id="finding" name="finding">Finding a Word on a Page</a>
+</h3>
+<p>
+ Once a page is displayed by the search engine, use the Web browser's search tool to find a specific word on that page.
+ Press <tt>CTRL+F</tt> to start the Web browser's search tool.
+</p>
+<h3>
+ <a id="entering" name="entering">Entering a Search Query</a>
+</h3>
+<p>
+ A search query consists of one or more specified words. Boolean operators cannot be used. Instead of Boolean operators,
+ use the <b>All the words</b>, <b>Any word</b>, <b>Exact phrase</b>, or <b>Without the word</b> fields that are
+ provided. The search process is not case-sensitive, which means that <font size="3"><tt>Hello, HELLO, and
+ hElLo</tt></font> are all considered the same. The wildcard symbol is not supported: <font size="3"><tt>*</tt></font>.
+</p>
+<p>
+ When more than one field is used, the query is evaluated with precedence from top to bottom. For example, the query:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="4" bordercolordark="#808080" cellpadding="4" width="350" bordercolorlight="#808080" border="0">
+ <tbody>
+ <tr>
+ <th align="left" width="40%">
+ All the words:
+ </th>
+ <td width="60%">
+ project management
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Any word</b>:
+ </th>
+ <td width="60%">
+ adopt vision
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Exact phrase</b>:
+ </th>
+ <td width="60%">
+ Rational Unified Process
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Without the words</b>:
+ </th>
+ <td width="60%">
+ implementation
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+ <br />
+</div>
+<p>
+ This can be expressed as the following: (project AND management) AND (adopt OR vision) AND (Rational Unified Process)
+ NOT (implementation). In other words, the matching pages must contain both of the words "project" and "management", the
+ word "adopt" or "vision", along with the phrase "Rational Unified Process". Matching pages must not contain the word
+ "implementation".
+</p>
+<h3>
+ <a id="special_considerations" name="special_considerations">Special Considerations</a>
+</h3>
+<ul>
+ <li>
+ The search engine automatically excludes common words such as "where", "when", and "the" from search queries,
+ because these words are excluded during the creation of the index files on which the search operates. Excluding
+ these words improves performance of the search without impacting the precision of the results.
+ </li>
+ <li>
+ In order for a query using the <b>Without the words</b> field to make sense, there must be text in at least one of
+ the other search fields. In other words, unless you first specify that you want the search to find pages that
+ <b>do</b> contain certain words or a specific phrase, the search engine cannot find pages that <b>do not</b>
+ contain certain words.
+ </li>
+ <li>
+ Wildcard searches using the wildcard character are not supported.
+ </li>
+ <li>
+ Boolean operators are not supported. See the section titled <a href="#entering">Entering a Search Query</a> for
+ instructions on how to perform searches that are equivalent to using Boolean operators.
+ </li>
+ <li>
+ You may obtain unsatisfactory search results for queries that attempt to search for single digit numbers in their
+ numeric format, especially the numbers 0 though 9. Instead of searching for the numeric value, either omit the
+ number from the search or use the full textual spelling of the number, for example "zero", "six", "nine", "ten" and
+ so forth.
+ </li>
+</ul>
+<br />
+<br /><!-- END:mainDescription,_zZxTYtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.html
new file mode 100644
index 0000000..2bc6650
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.html
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\supportingmaterials\whats_new_base_concepts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: whats_new_base_concepts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qxY8MEALEdqTMtYjAib0og CRC: 3531885378 -->What's New in Base Concepts<!-- END:presentationName,_qxY8MEALEdqTMtYjAib0og -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-eyFTMGu83WSs-yJedYCY3g CRC: 2426839690 --><p>
+ For a description of this plug-in's contents, refer to <a class="elementLink"
+ href="./../../../base_concepts/guidances/supportingmaterials/about_base_concepts,_uvje4D_fEdqDFvujd6NHiA.html"
+ guid="_uvje4D_fEdqDFvujd6NHiA">About Base Concepts</a>.
+</p>
+<p>
+ The new features and changes from version to version are described below.
+</p>
+<ul>
+ <li>
+ <a href="#2.0">From 2.0 to 2.0.1</a>
+ </li>
+ <li>
+ <a href="#1.0">1.0</a>
+ </li>
+</ul>
+<h2>
+ <a id="1.0" name="1.0">1.0</a>
+</h2>
+<p>
+ This is the initial release of this plug-in.
+</p><!-- END:mainDescription,-eyFTMGu83WSs-yJedYCY3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/activity.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/activity.html
new file mode 100644
index 0000000..0f8687b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/activity.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\activity.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: activity.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yoVhMB_IEdq6CKKKq4D7YA CRC: 2893285722 -->activity<!-- END:presentationName,_yoVhMB_IEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-67u6-WRUmTOB9IdLgQg6aw CRC: 403472678 --><p>
+ An activity is something that one or more roles do.
+</p>
+<p>
+ In the <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html"
+ guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> , an activity is a <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html"
+ guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a> which supports the nesting and logical grouping of related
+ process elements such as <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/descriptor,_7rS6AB_JEdq6CKKKq4D7YA.html"
+ guid="_7rS6AB_JEdq6CKKKq4D7YA">descriptor</a> and sub-activities, thus forming <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html"
+ guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.
+</p><!-- END:mainDescription,-67u6-WRUmTOB9IdLgQg6aw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/activity_detail_diagram.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/activity_detail_diagram.html
new file mode 100644
index 0000000..a17ce82
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/activity_detail_diagram.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\activity_detail_diagram.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: activity_detail_diagram.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ycE8HNnmEdmO6L4XMImrsA CRC: 188632536 -->activity detail diagram<!-- END:presentationName,_ycE8HNnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_ycE8HdnmEdmO6L4XMImrsA CRC: 1026550594 -->Diagram depicting all the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s within the scope of an <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/activity,_yoVhMB_IEdq6CKKKq4D7YA.html" guid="_yoVhMB_IEdq6CKKKq4D7YA">activity</a>. This diagram also depicts input/output relationships between <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s, activities, and <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s; as well as responsibility relationships between <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html" guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and tasks. Activity detail diagrams are used to provide a complete summary of an
+activity and thus improve their comprehensibility.<!-- END:mainDescription,_ycE8HdnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/artifact.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/artifact.html
new file mode 100644
index 0000000..da70917
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/artifact.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\artifact.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: artifact.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_x7cUM9nmEdmO6L4XMImrsA CRC: 1222991916 -->artifact<!-- END:presentationName,_x7cUM9nmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_x7cUNNnmEdmO6L4XMImrsA CRC: 2721304075 -->A formal <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> that:
+<div style="MARGIN-LEFT: 2em">
+ 1) is produced, modified, or used by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>,<br />
+ 2) defines an area of responsibility<br />
+ 3) is subject to version control.
+</div>
+<p>
+ An artifact can have multiple forms including a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/model,_yNefY9nmEdmO6L4XMImrsA.html" guid="_yNefY9nmEdmO6L4XMImrsA">model</a></i>, a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/model_element,_yNnpVdnmEdmO6L4XMImrsA.html" guid="_yNnpVdnmEdmO6L4XMImrsA">model element</a></i>, or a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/document,_yG6kY9nmEdmO6L4XMImrsA.html" guid="_yG6kY9nmEdmO6L4XMImrsA">document</a></i>.
+</p><!-- END:mainDescription,_x7cUNNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/breakdown_element.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/breakdown_element.html
new file mode 100644
index 0000000..851717c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/breakdown_element.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\breakdown_element.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: breakdown_element.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cvdpEB_LEdq6CKKKq4D7YA CRC: 4072096395 -->breakdown element<!-- END:presentationName,_cvdpEB_LEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-7pbyO29v0VnsosWHabeZDQ CRC: 1302381119 -->Any element modeled in <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html"
+guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> that is part of <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> structure.<!--EndFragment--><!-- END:mainDescription,-7pbyO29v0VnsosWHabeZDQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/breakdown_structure.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/breakdown_structure.html
new file mode 100644
index 0000000..e0973dc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/breakdown_structure.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\breakdown_structure.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: breakdown_structure.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_95LCoB_QEdq6CKKKq4D7YA CRC: 2918388840 -->breakdown structure<!-- END:presentationName,_95LCoB_QEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dpUlq7kJXlJBUjvh7lHW7Q CRC: 2013316364 --><p>
+ A <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> construct that specifies a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> as the hierarchical composition of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s.
+</p><!-- END:mainDescription,-dpUlq7kJXlJBUjvh7lHW7Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/capability_pattern.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/capability_pattern.html
new file mode 100644
index 0000000..c0ac6d8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/capability_pattern.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\capability_pattern.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: capability_pattern.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2RUJACO4EdqaNq6Ptg8uyA CRC: 1017538796 -->capability pattern<!-- END:presentationName,_2RUJACO4EdqaNq6Ptg8uyA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-AY7-wWpxUmZp4c-odX8e7g CRC: 922498712 --><p>
+ <!--StartFragment-->A special <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that describes a reusable cluster of <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/activity,_yoVhMB_IEdq6CKKKq4D7YA.html"
+ guid="_yoVhMB_IEdq6CKKKq4D7YA">activity</a>. Capability patterns express and communicate process knowledge for a key
+ area of interest such as a <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/discipline,_yGUuidnmEdmO6L4XMImrsA.html"
+ guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a> and can be directly used by practitioners to guide their work.
+ <!--EndFragment-->
+</p><!-- END:mainDescription,-AY7-wWpxUmZp4c-odX8e7g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/checklist.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/checklist.html
new file mode 100644
index 0000000..0c0d40b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/checklist.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\checklist.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: checklist.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7vpJsMaCEduMlb2cQZNTYw CRC: 1550413103 -->checklist<!-- END:presentationName,_7vpJsMaCEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-d9uOWrjeHbE_1Xu2RIs-0A CRC: 329272867 -->Identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as
+walkthroughs or inspections.<!-- END:mainDescription,-d9uOWrjeHbE_1Xu2RIs-0A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/composite_role.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/composite_role.html
new file mode 100644
index 0000000..2e48b26
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/composite_role.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\composite_role.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: composite_role.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PzL7EMaEEduMlb2cQZNTYw CRC: 2446321813 -->composite role<!-- END:presentationName,_PzL7EMaEEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KNw2PnSSEEogCvg4sj1ebg CRC: 2296377650 -->A special role descriptor that relates to more than one <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a>. It represents a grouping of roles with the main purpose of reducing the number of
+roles defined in method content for a process.<!-- END:mainDescription,-KNw2PnSSEEogCvg4sj1ebg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/concept.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/concept.html
new file mode 100644
index 0000000..49ca748
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/concept.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\concept.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: concept.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wMchYMaEEduMlb2cQZNTYw CRC: 3880411216 -->concept<!-- END:presentationName,_wMchYMaEEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-5bvXXNVzF7mZf0R7Oez5_g CRC: 764129247 -->Outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general
+topics than <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guideline,_uK8HMMaFEduMlb2cQZNTYw.html"
+guid="_uK8HMMaFEduMlb2cQZNTYw">guidelines</a> and span across several work products, tasks, or activities.<!-- END:mainDescription,-5bvXXNVzF7mZf0R7Oez5_g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/content_element.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/content_element.html
new file mode 100644
index 0000000..4527301
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/content_element.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\content_element.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content_element.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_N8x34B_LEdq6CKKKq4D7YA CRC: 3946316982 -->content element<!-- END:presentationName,_N8x34B_LEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-We7G-7OM2QspR_i1ErwtLA CRC: 3060344775 -->Any element modeled in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> that is part of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/method_content,_Ts2joB_MEdq6CKKKq4D7YA.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">Method Content</a>. Content elements providestep-by-step explanations,describing how very
+specific development goals are achieved independent of the placement of these steps within a development lifecycle. They
+are instantiated and adapted to the specific situation within <a class="ELEMENTLINK" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> structures.<!-- END:mainDescription,-We7G-7OM2QspR_i1ErwtLA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/content_package.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/content_package.html
new file mode 100644
index 0000000..dee7c40
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/content_package.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\content_package.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content_package.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SAWgwMaFEduMlb2cQZNTYw CRC: 1947221274 -->content package<!-- END:presentationName,_SAWgwMaFEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-t4Xac9J5DWCA6r1b9L40Mw CRC: 1150575708 -->A special method package that contains <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a> exclusively. Examples for content element are <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/artifact,_x7cUM9nmEdmO6L4XMImrsA.html"
+guid="_x7cUM9nmEdmO6L4XMImrsA">artifacts</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a>, and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>.<!-- END:mainDescription,-t4Xac9J5DWCA6r1b9L40Mw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/custom_category.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/custom_category.html
new file mode 100644
index 0000000..99e9cca
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/custom_category.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\custom_category.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: custom_category.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eqw94MaFEduMlb2cQZNTYw CRC: 3431264929 -->custom category<!-- END:presentationName,_eqw94MaFEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-G9dXZH2IkpWGi4NZK-2vEw CRC: 4184885870 -->Used to categorize content based on the user's criteria. One important use is for constructing <a
+class="elementLinkWithUserText" href="./../../../base_concepts/guidances/termdefinitions/view,_GH6WUMaJEduMlb2cQZNTYw.html"
+guid="_GH6WUMaJEduMlb2cQZNTYw">views</a>.<!-- END:mainDescription,-G9dXZH2IkpWGi4NZK-2vEw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/customer.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/customer.html
new file mode 100644
index 0000000..77aaae3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/customer.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\customer.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: customer.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yE05s9nmEdmO6L4XMImrsA CRC: 2168032777 -->customer<!-- END:presentationName,_yE05s9nmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yE05tNnmEdmO6L4XMImrsA CRC: 154767812 -->A person or organization, internal or external to the producing organization, who takes financial responsibility for the
+system. In a large system this may or may not be the user. The customer is the ultimate recipient of the developed product.
+See also: <i><a class="elementLink" href="rup/guidances/termdefinitions/stakeholder,_yWHeDNnmEdmO6L4XMImrsA.html"
+guid="_yWHeDNnmEdmO6L4XMImrsA">stakeholder</a>.</i><!-- END:mainDescription,_yE05tNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/deliverable.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/deliverable.html
new file mode 100644
index 0000000..6ae7ae9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/deliverable.html
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\deliverable.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: deliverable.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yFbWoNnmEdmO6L4XMImrsA CRC: 2709365825 -->deliverable<!-- END:presentationName,_yFbWoNnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yFbWodnmEdmO6L4XMImrsA CRC: 2275953116 -->An output from a <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that has a value, material or otherwise, to a <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/customer,_yE05s9nmEdmO6L4XMImrsA.html"
+guid="_yE05s9nmEdmO6L4XMImrsA">customer</a></i> or other <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/stakeholder,_yWHeDNnmEdmO6L4XMImrsA.html"
+guid="_yWHeDNnmEdmO6L4XMImrsA">stakeholder</a></i> .<!-- END:mainDescription,_yFbWodnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/delivery_process.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/delivery_process.html
new file mode 100644
index 0000000..624c85b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/delivery_process.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\delivery_process.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: delivery_process.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZufeMCO3EdqaNq6Ptg8uyA CRC: 4185072756 -->delivery process<!-- END:presentationName,_ZufeMCO3EdqaNq6Ptg8uyA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-IsV3QdyMdwFlqznd4UAYhw CRC: 1584197512 -->A delivery process is a special <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific project
+type. <!--StartFragment-->It provides a complete lifecycle model that has been detailed by sequencing <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/method_content,_Ts2joB_MEdq6CKKKq4D7YA.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a> in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.<!-- END:mainDescription,-IsV3QdyMdwFlqznd4UAYhw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/descriptor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/descriptor.html
new file mode 100644
index 0000000..f888fed
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/descriptor.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\descriptor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: descriptor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7rS6AB_JEdq6CKKKq4D7YA CRC: 59930114 -->descriptor<!-- END:presentationName,_7rS6AB_JEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-TI6lqoTE1op3-SnmGa2S9Q CRC: 3315221631 -->In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a description is an abstract generalization for special <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s that reference one concrete <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>. Descriptors are the key concept for realizing the separation of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> from Method Content. A descriptor can be characterized as a reference
+object for one particular content element. In addition, a descriptor has its own relationships and properties whose
+purpose is to modify the semantics of the content element it refers to.<!-- END:mainDescription,-TI6lqoTE1op3-SnmGa2S9Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/discipline.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/discipline.html
new file mode 100644
index 0000000..2ea7372
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/discipline.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\discipline.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: discipline.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yGUuidnmEdmO6L4XMImrsA CRC: 1975447103 -->discipline<!-- END:presentationName,_yGUuidnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yGUuitnmEdmO6L4XMImrsA CRC: 85698938 -->A collection of related <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s that define a major 'area of concern'. In software engineering,
+Disciplines include: <em>Requirements, Analysis & Design, Implementation,Test,</em> and <em>Project
+Management</em>.<!-- END:mainDescription,_yGUuitnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/document.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/document.html
new file mode 100644
index 0000000..a8484bd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/document.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\document.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: document.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yG6kY9nmEdmO6L4XMImrsA CRC: 3630795382 -->document<!-- END:presentationName,_yG6kY9nmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yG6kZNnmEdmO6L4XMImrsA CRC: 2323263822 -->A document is a collection of information intended to be represented on paper, or in a medium using a paper metaphor. The
+paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The
+information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets,
+schedules, Gantt charts, web-pages, and overhead slide presentations.<!-- END:mainDescription,_yG6kZNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/domain.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/domain.html
new file mode 100644
index 0000000..41e5e5a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/domain.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\domain.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: domain.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yHEVYdnmEdmO6L4XMImrsA CRC: 2812878347 -->domain<!-- END:presentationName,_yHEVYdnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yHEVYtnmEdmO6L4XMImrsA CRC: 448763059 --><p>
+ (1)An area of knowledge or activity characterized by a family of related values.
+</p>
+<p>
+ (2) A specific problem category that is characterized by a body of knowledge, activities, and behaviors.
+</p>
+<p>
+ (3)A refineable hierarchy that groups related <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s.
+</p><!-- END:mainDescription,_yHEVYtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/example.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/example.html
new file mode 100644
index 0000000..698df3e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/example.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\example.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: example.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_nE6fsMaFEduMlb2cQZNTYw CRC: 1861000095 -->example<!-- END:presentationName,_nE6fsMaFEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-WGi50KpVG9oQbP82Xvk1UA CRC: 3831204560 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that represents a typical, partially completed, sample instance of one or more
+<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a>. Examples are most commonly provided for <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.<!-- END:mainDescription,-WGi50KpVG9oQbP82Xvk1UA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/guidance.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/guidance.html
new file mode 100644
index 0000000..0ea2c05
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/guidance.html
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\guidance.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: guidance.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_83ttAB_NEdq6CKKKq4D7YA CRC: 4040088999 -->guidance<!-- END:presentationName,_83ttAB_NEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-CTatxBir28UK-VwWwDij-g CRC: 4168073972 --><p>
+ Guidance describes proven advice for accomplishing a goal.
+</p>
+<p>
+ In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, guidance generalizes all forms of content whose primary purpose is to provide
+ explanations about other UMA elements. Guidance being itself a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>, it is possible to associate guidance to other guidance.
+</p><!-- END:mainDescription,-CTatxBir28UK-VwWwDij-g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/guideline.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/guideline.html
new file mode 100644
index 0000000..5ca55e3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/guideline.html
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\guideline.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: guideline.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uK8HMMaFEduMlb2cQZNTYw CRC: 376615066 -->guideline<!-- END:presentationName,_uK8HMMaFEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-EEF1Y386HZ1XRsyHmGLE3g CRC: 767592396 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that provides additional detail on how to handle a particular <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>. Guidelines most commonly apply to <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.<!-- END:mainDescription,-EEF1Y386HZ1XRsyHmGLE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/input.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/input.html
new file mode 100644
index 0000000..61c0275
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/input.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\input.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: input.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yK8IyNnmEdmO6L4XMImrsA CRC: 3626513111 -->input<!-- END:presentationName,_yK8IyNnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yK8IydnmEdmO6L4XMImrsA CRC: 2497577179 -->In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>,
+input is a type of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> used by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a> See: <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/static_work_product,_yWaY9tnmEdmO6L4XMImrsA.html" guid="_yWaY9tnmEdmO6L4XMImrsA">static work product</a>.<!-- END:mainDescription,_yK8IydnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_configuration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_configuration.html
new file mode 100644
index 0000000..c589d37
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_configuration.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\method_configuration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_configuration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__V7pAMaEEduMlb2cQZNTYw CRC: 2359849173 -->method configuration<!-- END:presentationName,__V7pAMaEEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-kzN6-iqn9zDtfnJc7IWkIg CRC: 2438661475 -->A method configuration specifies the selection of a logical subset of a <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_library,_1xELEMaFEduMlb2cQZNTYw.html"
+guid="_1xELEMaFEduMlb2cQZNTYw">method library</a>, in terms of <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_plugin,_D4TLgMaGEduMlb2cQZNTYw.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_package,_SAWgwMaFEduMlb2cQZNTYw.html"
+guid="_SAWgwMaFEduMlb2cQZNTYw">content packages</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process_package,_MN1doMaHEduMlb2cQZNTYw.html"
+guid="_MN1doMaHEduMlb2cQZNTYw">process packages</a>.<!-- END:mainDescription,-kzN6-iqn9zDtfnJc7IWkIg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_content.html
new file mode 100644
index 0000000..6736dc5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_content.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\method_content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Ts2joB_MEdq6CKKKq4D7YA CRC: 2410094810 -->method content<!-- END:presentationName,_Ts2joB_MEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-akU0PqDaad4Ns5MQhVBJ7Q CRC: 1889191730 --><p>
+ <!--StartFragment-->Describes generic <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> methodological concepts and <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> which provide step-by-step explanations, describing how specific goals
+ are achieved independently of the placement of these steps within a process lifecycle. <!--EndFragment-->UMA separates
+ method content from its application in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.
+</p><!-- END:mainDescription,-akU0PqDaad4Ns5MQhVBJ7Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_library.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_library.html
new file mode 100644
index 0000000..d4c7b75
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_library.html
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\method_library.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_library.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_1xELEMaFEduMlb2cQZNTYw CRC: 3504507087 -->method library<!-- END:presentationName,_1xELEMaFEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-m6mx-VR4CReQNhrf4b8ykQ CRC: 373967127 -->A physical container for <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_plugin,_D4TLgMaGEduMlb2cQZNTYw.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/configuration,__V7pAMaEEduMlb2cQZNTYw.html"
+guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a> definitions. All <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">method elements</a> are stored in a method library.<!-- END:mainDescription,-m6mx-VR4CReQNhrf4b8ykQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_plugin.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_plugin.html
new file mode 100644
index 0000000..fd4e947
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/method_plugin.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\method_plugin.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: method_plugin.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_D4TLgMaGEduMlb2cQZNTYw CRC: 3325245696 -->method plug-in<!-- END:presentationName,_D4TLgMaGEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-q0ixH8duU7qb8agEywAFHQ CRC: 4280224960 -->Represents a physical container for method packages. It defines a largest granularity level for the modularization and
+organization of <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_package,_SAWgwMaFEduMlb2cQZNTYw.html"
+guid="_SAWgwMaFEduMlb2cQZNTYw">method content</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">processes</a>.<!-- END:mainDescription,-q0ixH8duU7qb8agEywAFHQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/model.html
new file mode 100644
index 0000000..0e793aa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/model.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yNefY9nmEdmO6L4XMImrsA CRC: 3616895705 -->model<!-- END:presentationName,_yNefY9nmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yNefZNnmEdmO6L4XMImrsA CRC: 1231671528 --><p>
+ A model is an abstraction of a more complicated thing.
+</p>
+<br />
+<br />
+<br /><!-- END:mainDescription,_yNefZNnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/model_element.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/model_element.html
new file mode 100644
index 0000000..5465dfb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/model_element.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\model_element.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model_element.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yNnpVdnmEdmO6L4XMImrsA CRC: 1420014836 -->model element<!-- END:presentationName,_yNnpVdnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yNnpVtnmEdmO6L4XMImrsA CRC: 140990039 -->An element that is an abstraction drawn from the system being modeled. Contrast: <i><a class="elementLink"
+href="./../../../base_concepts/guidances/termdefinitions/view_element,_ybefKdnmEdmO6L4XMImrsA.html"
+guid="_ybefKdnmEdmO6L4XMImrsA">view element</a></i>.<!-- END:mainDescription,_yNnpVtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/outcome.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/outcome.html
new file mode 100644
index 0000000..3b1c05d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/outcome.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\outcome.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: outcome.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_LNAAcB_iEdqAHrsQ7-jSbw CRC: 817655234 -->outcome<!-- END:presentationName,_LNAAcB_iEdqAHrsQ7-jSbw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-SQyJsrOEI73uLZzjRVmSBA CRC: 2599251671 --><p>
+ <!--StartFragment-->Primarily describes intangible <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s that are a result or state. An outcome can also be used to represent
+ an informal work product.<!--EndFragment-->
+</p><!-- END:mainDescription,-SQyJsrOEI73uLZzjRVmSBA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/output.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/output.html
new file mode 100644
index 0000000..d9f7d15
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/output.html
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\output.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: output.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yPaZGdnmEdmO6L4XMImrsA CRC: 3437106334 -->output<!-- END:presentationName,_yPaZGdnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yPaZGtnmEdmO6L4XMImrsA CRC: 1689751088 -->(1) Any <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">Work Product</a> that is the result of a <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>. See: <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/deliverable,_yFbWoNnmEdmO6L4XMImrsA.html"
+guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a></i>.<!-- END:mainDescription,_yPaZGtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/phase.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/phase.html
new file mode 100644
index 0000000..ef6671e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/phase.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\phase.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: phase.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_K9eecMaGEduMlb2cQZNTYw CRC: 2982008523 -->phase<!-- END:presentationName,_K9eecMaGEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-88Vj7cM5EcVnfesDYaAkww CRC: 1786547878 -->The time between two major project <span class="docEmphasis">milestones</span>, during which a well-defined set of
+objectives is met, and decisions are made to move or not to move into the next phase.<!-- END:mainDescription,-88Vj7cM5EcVnfesDYaAkww -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/practice.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/practice.html
new file mode 100644
index 0000000..8a360a3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/practice.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\practice.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: practice.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wxYvkMaGEduMlb2cQZNTYw CRC: 2146186318 -->practice<!-- END:presentationName,_wxYvkMaGEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-kxtQBsUei9KRl8Z6tOSQ-g CRC: 2127191858 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that presents a proven way or strategy of doing work to achieve a goal that has
+a positive impact on work product or process quality.<!-- END:mainDescription,-kxtQBsUei9KRl8Z6tOSQ-g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process.html
new file mode 100644
index 0000000..1be81b8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\process.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: process.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yQ5m2NnmEdmO6L4XMImrsA CRC: 2250053782 -->process<!-- END:presentationName,_yQ5m2NnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yQ5m2dnmEdmO6L4XMImrsA CRC: 107715225 --><p>
+ (1) A general structure for particular types of development projects. Processes take <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>s and relate them into semi-ordered sequences that are customized to
+ specific types of projects. Thus, a process is a set of partially ordered work descriptions intended to reach a
+ higher development goal, such as the release of a specific software <!--StartFragment-->These work descriptions
+ are organized into a hierarchical breakdown-structure A process focuses on the lifecycle and the sequencing of
+ work in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.<br />
+</p>
+<p>
+ (2) The part of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> that models processes.
+</p>
+<!--EndFragment--><!-- END:mainDescription,_yQ5m2dnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process_contribution.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process_contribution.html
new file mode 100644
index 0000000..9e66990
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process_contribution.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\process_contribution.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: process_contribution.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3iqPEMaGEduMlb2cQZNTYw CRC: 487580309 -->process contribution<!-- END:presentationName,_3iqPEMaGEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-fkIJikbdLETPdu0ALqo7fw CRC: 625971190 -->A special <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that externally defines additions and changes to an existing process without
+directly modifying it.<!-- END:mainDescription,-fkIJikbdLETPdu0ALqo7fw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process_package.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process_package.html
new file mode 100644
index 0000000..3d874a9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/process_package.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\process_package.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: process_package.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MN1doMaHEduMlb2cQZNTYw CRC: 3814735484 -->process package<!-- END:presentationName,_MN1doMaHEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-GBZOfgyCAdK00NMpe1N5_Q CRC: 2075031658 -->A method package that contains processes such as <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/capability_pattern,_2RUJACO4EdqaNq6Ptg8uyA.html"
+guid="_2RUJACO4EdqaNq6Ptg8uyA">capability patterns</a> or <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/delivery_process,_ZufeMCO3EdqaNq6Ptg8uyA.html"
+guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery processes</a> only.<!-- END:mainDescription,-GBZOfgyCAdK00NMpe1N5_Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/release.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/release.html
new file mode 100644
index 0000000..4468197
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/release.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\release.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: release.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Ua93IMaHEduMlb2cQZNTYw CRC: 2655453981 -->release<!-- END:presentationName,_Ua93IMaHEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-hFYlBf3iN29RqVmHB9C4ug CRC: 1773148921 -->The delivery of a functional system meeting predefined objectives.<!-- END:mainDescription,-hFYlBf3iN29RqVmHB9C4ug -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/report.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/report.html
new file mode 100644
index 0000000..f09b549
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/report.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\report.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: report.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_bDCXUMaHEduMlb2cQZNTYw CRC: 3291445124 -->report<!-- END:presentationName,_bDCXUMaHEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-lEbg0SKqsikKdCRXPVvRmw CRC: 3000527358 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that is a predefined template of a result generated on the basis of other
+work products. An output from some form of tool automation.<!-- END:mainDescription,-lEbg0SKqsikKdCRXPVvRmw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/reusable_asset.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/reusable_asset.html
new file mode 100644
index 0000000..92e9ccb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/reusable_asset.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\reusable_asset.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: reusable_asset.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_kSKZUMaHEduMlb2cQZNTYw CRC: 3272875481 -->reusable asset<!-- END:presentationName,_kSKZUMaHEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-H9RSfWhEhOJscNkDKGPcBA CRC: 4146634165 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that describes an asset - such as source code, templates, patterns,
+architectural frameworks, domain models, and so on - that can be reused in a different context.<!-- END:mainDescription,-H9RSfWhEhOJscNkDKGPcBA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/roadmap.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/roadmap.html
new file mode 100644
index 0000000..fa84fbd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/roadmap.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\roadmap.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: roadmap.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_19dWYMaHEduMlb2cQZNTYw CRC: 1673785075 -->roadmap<!-- END:presentationName,_19dWYMaHEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-gCtPvpHU3vmCQKQ1ymqBvw CRC: 2465691571 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that summarizes a process, often from a particular perspective, such as by
+providing a walkthrough with a linear thread of a typical instantiation of activities.<!-- END:mainDescription,-gCtPvpHU3vmCQKQ1ymqBvw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/role.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/role.html
new file mode 100644
index 0000000..0b72a23
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/role.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\role.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: role.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yUefQNnmEdmO6L4XMImrsA CRC: 1466534506 -->role<!-- END:presentationName,_yUefQNnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yUefQdnmEdmO6L4XMImrsA CRC: 3458327862 -->A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team.<!-- END:mainDescription,_yUefQdnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/role_set.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/role_set.html
new file mode 100644
index 0000000..b0d26c1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/role_set.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\role_set.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: role_set.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Fs8HAMaIEduMlb2cQZNTYw CRC: 1630146916 -->role set<!-- END:presentationName,_Fs8HAMaIEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-gOXu6EqfZHMmtekNk8IDqA CRC: 4075530283 -->Used to group <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a> with certain commonalities together.<!-- END:mainDescription,-gOXu6EqfZHMmtekNk8IDqA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/stakeholder.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/stakeholder.html
new file mode 100644
index 0000000..6d0e713
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/stakeholder.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\stakeholder.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: stakeholder.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yWHeDNnmEdmO6L4XMImrsA CRC: 2342003626 -->stakeholder<!-- END:presentationName,_yWHeDNnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yWHeDdnmEdmO6L4XMImrsA CRC: 2893993356 -->An individual who is who is materially affected by the outcome of the <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> (i.e. the <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/deliverable,_yFbWoNnmEdmO6L4XMImrsA.html"
+guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s the process produces).<!-- END:mainDescription,_yWHeDdnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/static_work_product.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/static_work_product.html
new file mode 100644
index 0000000..e4171d5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/static_work_product.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\static_work_product.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: static_work_product.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yWaY9tnmEdmO6L4XMImrsA CRC: 1139704890 -->static work product<!-- END:presentationName,_yWaY9tnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yWaY99nmEdmO6L4XMImrsA CRC: 661538979 -->A <a class="elementLink" href="base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> that is used, but not changed, by a <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.<!-- END:mainDescription,_yWaY99nmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/step.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/step.html
new file mode 100644
index 0000000..b286249
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/step.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\step.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: step.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BqZloB_eEdqAHrsQ7-jSbw CRC: 1136262716 -->step<!-- END:presentationName,_BqZloB_eEdqAHrsQ7-jSbw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KfXoeGTRnQImE1byTBtryQ CRC: 1530201814 -->In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a step is <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a> used to organize <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s into parts or subunits of work.<!-- END:mainDescription,-KfXoeGTRnQImE1byTBtryQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/supporting_material.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/supporting_material.html
new file mode 100644
index 0000000..ea6c59c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/supporting_material.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\supporting_material.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_material.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SwvUgMaIEduMlb2cQZNTYw CRC: 4012203328 -->supporting material<!-- END:presentationName,_SwvUgMaIEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_-iQ4eQyiQVM7YhXcb90-g CRC: 1592995932 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that is a catch-all for other types of guidance not specifically defined
+elsewhere.<!-- END:mainDescription,-_-iQ4eQyiQVM7YhXcb90-g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/task.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/task.html
new file mode 100644
index 0000000..ceef628
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/task.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\task.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: task.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_x459ktnmEdmO6L4XMImrsA CRC: 1384045349 -->task<!-- END:presentationName,_x459ktnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_x459k9nmEdmO6L4XMImrsA CRC: 1122401699 -->A unit of work a <i><a class="elementLink"
+href="./../../../rup/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a></i> may be asked to perform.<!-- END:mainDescription,_x459k9nmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/team_profile.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/team_profile.html
new file mode 100644
index 0000000..e10170f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/team_profile.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\team_profile.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: team_profile.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_rZOGIMaIEduMlb2cQZNTYw CRC: 190732292 -->team profile<!-- END:presentationName,_rZOGIMaIEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-0cxbeJahkc1eqGKztRpcPw CRC: 685119455 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html"
+guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a> that groups role descriptors or composite roles, thus defining a
+nested hierarchy of teams and team members.<!-- END:mainDescription,-0cxbeJahkc1eqGKztRpcPw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/template.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/template.html
new file mode 100644
index 0000000..451596e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/template.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\template.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: template.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_1MLN8MaIEduMlb2cQZNTYw CRC: 2539659139 -->template<!-- END:presentationName,_1MLN8MaIEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,--SOXfR7BTPs3CqtNP8R6Rw CRC: 3598315404 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that specifies the structure of a work product by providing a pre-defined
+table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions on how the sections
+and packages are supposed to be used and completed.<!-- END:mainDescription,--SOXfR7BTPs3CqtNP8R6Rw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/term_definition.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/term_definition.html
new file mode 100644
index 0000000..b95dbdf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/term_definition.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\term_definition.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: term_definition.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_6SluIMaIEduMlb2cQZNTYw CRC: 855519548 -->term definition<!-- END:presentationName,_6SluIMaIEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-4JztP2JNqE36rtSC0UoYDw CRC: 547478105 -->A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that defines concepts that are used to build up the glossary.<!-- END:mainDescription,-4JztP2JNqE36rtSC0UoYDw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/tool.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/tool.html
new file mode 100644
index 0000000..0449680
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/tool.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\tool.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: tool.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BangwMaJEduMlb2cQZNTYw CRC: 552812241 -->tool<!-- END:presentationName,_BangwMaJEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-XnXEM7GkN21zwj7pKPmu3A CRC: 1050136926 -->A standard category used as a container for <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/tool_mentor,_yYy-mdnmEdmO6L4XMImrsA.html"
+guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentors</a>. It can also provide general descriptions of the tool and its general
+capabilities.<!-- END:mainDescription,-XnXEM7GkN21zwj7pKPmu3A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/tool_mentor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/tool_mentor.html
new file mode 100644
index 0000000..31e0fce
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/tool_mentor.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\tool_mentor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: tool_mentor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_yYy-mdnmEdmO6L4XMImrsA CRC: 4284796416 -->tool mentor<!-- END:presentationName,_yYy-mdnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_yYy-mtnmEdmO6L4XMImrsA CRC: 1934275532 -->A tool mentor is a type of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that explains how to perform specific <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a> or <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/step,_BqZloB_eEdqAHrsQ7-jSbw.html" guid="_BqZloB_eEdqAHrsQ7-jSbw">step</a>s using a specific software tool.<!-- END:mainDescription,_yYy-mtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/uma.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/uma.html
new file mode 100644
index 0000000..b08f510
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/uma.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\uma.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uma.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cj6jkB_PEdq6CKKKq4D7YA CRC: 3510269191 -->UMA<!-- END:presentationName,_cj6jkB_PEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-QBSZ9hFRr8q6kvRyq1cESQ CRC: 2336317392 -->Stands for Unified Method Architecture. UMA is a state-of-the-art architecture for the conceiving, specifying,
+and storing of method and process metadata.<!-- END:mainDescription,-QBSZ9hFRr8q6kvRyq1cESQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/view.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/view.html
new file mode 100644
index 0000000..ea694a6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/view.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\view.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: view.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_GH6WUMaJEduMlb2cQZNTYw CRC: 4278037390 -->view<!-- END:presentationName,_GH6WUMaJEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dLRBfqnBlgy_0_H13LmV3A CRC: 3132479724 -->Structured content collections designed to drive publication and facilitate browsing. They are specified using <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/custom_category,_eqw94MaFEduMlb2cQZNTYw.html"
+guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a>.<!-- END:mainDescription,-dLRBfqnBlgy_0_H13LmV3A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/view_element.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/view_element.html
new file mode 100644
index 0000000..18b1bad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/view_element.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\view_element.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: view_element.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ybefKdnmEdmO6L4XMImrsA CRC: 493734143 -->view element<!-- END:presentationName,_ybefKdnmEdmO6L4XMImrsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_ybefKtnmEdmO6L4XMImrsA CRC: 703367977 -->A view element is a textual and/or graphical projection of a collection of <i><a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/model_element,_yNnpVdnmEdmO6L4XMImrsA.html"
+guid="_yNnpVdnmEdmO6L4XMImrsA">model elements</a></i>.<!-- END:mainDescription,_ybefKtnmEdmO6L4XMImrsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/white_paper.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/white_paper.html
new file mode 100644
index 0000000..324cd56
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/white_paper.html
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\white_paper.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: white_paper.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Kc1IIMaJEduMlb2cQZNTYw CRC: 4033801202 -->white paper<!-- END:presentationName,_Kc1IIMaJEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-QLPRVsXtlVpWZiWmQPSsnw CRC: 179990342 --><p>
+ A <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+ guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> type for externally published papers that can be read and
+ understood in isolation of other <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+ guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a> and guidance.
+</p><!-- END:mainDescription,-QLPRVsXtlVpWZiWmQPSsnw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/work_product.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/work_product.html
new file mode 100644
index 0000000..acf9c2a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/work_product.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\work_product.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_product.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_H4JXwB_SEdq6CKKKq4D7YA CRC: 1945190323 -->work product<!-- END:presentationName,_H4JXwB_SEdq6CKKKq4D7YA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dcYwPivhczonAxeyXweyIQ CRC: 955248813 -->In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a
+work product is a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a> that represents anything used, produced, or modified by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>.<!-- END:mainDescription,-dcYwPivhczonAxeyXweyIQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/work_product_kind.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/work_product_kind.html
new file mode 100644
index 0000000..0776d03
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/guidances/termdefinitions/work_product_kind.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\guidances\termdefinitions\work_product_kind.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_product_kind.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_QWhfYMaJEduMlb2cQZNTYw CRC: 1381503549 -->work product kind<!-- END:presentationName,_QWhfYMaJEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-on4oCT1DzfksdshYPKAqGg CRC: 2468686504 -->Standard category that represents a grouping of related work products which, in contrast to <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/domain,_yHEVYdnmEdmO6L4XMImrsA.html"
+guid="_yHEVYdnmEdmO6L4XMImrsA">domain</a>, is more presentation oriented (like <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/model,_yNefY9nmEdmO6L4XMImrsA.html"
+guid="_yNefY9nmEdmO6L4XMImrsA">models</a>, specifications, plans, and so on).<!-- END:mainDescription,-on4oCT1DzfksdshYPKAqGg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/plugin.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/plugin.html
new file mode 100644
index 0000000..a757ee7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/base_concepts/plugin.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\base_concepts\plugin.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plugin.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_WCUhAO8KEdmKSqa_gSYthg CRC: 912586014 -->This plug-in contains basic concepts necessary to use the method composition tooling. This plug-in should be in ALL configurations.<!-- END:briefDescription,_WCUhAO8KEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_eNnSAO8LEdmKSqa_gSYthg CRC: 1719950592 -->General Guidance<!-- END:name,_eNnSAO8LEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_eNnSAO8LEdmKSqa_gSYthg CRC: 4054263982 -->This Content package concepts and other general guidance related to UMA and related tooling.<!-- END:briefDescription,_eNnSAO8LEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_AejKAMadEduMlb2cQZNTYw CRC: 2106012609 -->to_a_method_authoring_plugin<!-- END:name,_AejKAMadEduMlb2cQZNTYw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8wobABUAEdqrUt4zetC1gg CRC: 687299020 -->Concept<!-- END:presentationName,_8wobABUAEdqrUt4zetC1gg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_8wobABUAEdqrUt4zetC1gg CRC: 3076836210 -->A Concept outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general topics than Guidelines and span across several Work Products, Tasks, or activities.<!-- END:briefDescription,_8wobABUAEdqrUt4zetC1gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/configurations/OpenUPBasic.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/configurations/OpenUPBasic.html
new file mode 100644
index 0000000..d1863b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/configurations/OpenUPBasic.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\configurations\OpenUPBasic.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: OpenUPBasic.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0u-T4clgEdmt3adZL5Dmdw CRC: 3776105618 -->OpenUPBasic<!-- END:name,_0u-T4clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0u-T4clgEdmt3adZL5Dmdw CRC: 959646937 -->This configuration includes plug-ins a packages needed for the OpenUP/Basic process.<!-- END:briefDescription,_0u-T4clgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/construction_phase_iteration/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/construction_phase_iteration/content.html
new file mode 100644
index 0000000..746efb2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/construction_phase_iteration/content.html
@@ -0,0 +1,267 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\construction_phase_iteration\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_y-3IrutQEdqc1LGhiSPqRg CRC: 1846029888 -->Construction Phase Iteration<!-- END:presentationName,_y-3IrutQEdqc1LGhiSPqRg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_y-3IrutQEdqc1LGhiSPqRg CRC: 1899401464 -->This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Construction phase. Each activity and its goals is described.<!-- END:briefDescription,_y-3IrutQEdqc1LGhiSPqRg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-239OBD2wagT2qp8fuPWcHQ CRC: 2393740895 --><h3>
+ Introduction
+</h3>
+Iterations in Construction phase have a work breakdown structure (WBS) similar to iterations in the Elaboration phase, with
+activities happening in parallel. There is a different emphasis on how activities address the phase objectives,
+though.
+<p>
+ The <a href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> is expected to be stable when this phase starts, allowing the remaining
+ requirements to be implemented on top of it. Another advantage of validating the architecture and eliminating as many
+ risks as possible during Elaboration is to provide more predictability in Construction, which allows the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project manager</a> to focus on team efficiency and cost reduction.
+</p>
+<p>
+ Functionality is continuously implemented, tested, and integrated, resulting in <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
+ that are more and more complete and stable. A beta or prerelease may be deployed to a sampling of the intended audience
+ at the end of Construction. Delivery of the actual release is the main focus of the next phase.
+</p>
+<p>
+ The activities performed in a typical iteration during Construction phase are described after the following
+ introductions to each activity.
+</p>
+<h4>
+ Manage iteration
+</h4>
+<p>
+ This activity is performed throughout the project lifecycle. The goal of this activity is to identify risks and issues
+ early enough to mitigate them, to establish the goals for the iteration, and to support the development team in
+ reaching these goals.
+</p>
+<p>
+ Similarly to other phases, the project manager (supported by the team) launches the iteration, allocates work, tracks
+ status, and handles issues and risks. Although the high-priority and architecturally significant risks were mitigated
+ during Elaboration, new risks may appear during Construction, such as not having the right amount of resources to
+ obtain the desired degree of parallel development.
+</p>
+<p>
+ The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements)
+ takes place. project manager, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>, and the remaining team members agree on what is supposed to be
+ developed during that iteration.
+</p>
+<p>
+ At the end of the iteration, the team performs an iteration assessment. The goal is to conduct a retrospective review
+ of the iteration that is ending. As part of this assessment, the objectives for the Construction phase are expected to
+ be demonstrated by the beta-quality release of the software, thus supporting the possibility of transitioning the
+ software to its end users.
+</p>
+<h4>
+ Manage requirements
+</h4>
+<p>
+ This activity is repeated throughout the lifecycle. The goal of this activity is to understand and prioritize
+ stakeholder needs and associated requirements for the system, as well as to capture these in a form that will support
+ effective communication and collaboration between the stakeholders and the development team.
+</p>
+<p>
+ During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated
+ (through a working architecture) during Elaboration.
+</p>
+<p>
+ During the Construction phase, requirements management demands less time from the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>.
+ There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
+</p>
+<p>
+ <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test cases</a> describe which requirements are being tested in that iteration.
+</p>
+<h4>
+ Develop solution
+</h4>
+<p>
+ This activity is repeated multiple times, in parallel, for each development task planned for that iteration. The main
+ goal of this activity is an executable system that provides the incremental quality and functionality for the specified
+ requirements, within the specified context.
+</p>
+<p>
+ The architecture was proposed and a baseline established at the end of Elaboration. Critical requirements were
+ expected to be implemented, tested, and integrated as part of the baseline architecture. As the remaining requirements
+ are implemented during Construction, the Architect identifies commonalities among solutions being developed by the
+ various developers and leverages reuse where possible. Some degree of refactoring of the architecture may be needed to
+ accommodate putting common pieces together.
+</p>
+<p>
+ A pattern similar to the Elaboration phase happens during Construction when it comes to breaking down requirements into
+ development tasks and assigning each requirement within a context to a developer. Requirements at this stage are mostly
+ of medium-to-low level of risk, but usually they represent the largest slice from the total amount of requirements to
+ be implemented in a project. Thus, it is expected that this activity is repeated, or instantiated, multiple times (once
+ per requirement within context), thus allowing parallel development. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ.html" guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous integration</a> allows functionality to be added to the code base constantly,
+ which helps the achievement of more and more complete <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
+ of the software.
+</p>
+<h4>
+ Validate build
+</h4>
+<p>
+ This activity is repeated throughout the project lifecycle. The main goal of this activity is to validate the current
+ increment of the system against the requirements allocated to it.
+</p>
+<p>
+ Similarly to Elaboration, this activity happens in parallel with the <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/develop_solution,_h2-iAfimEdmugcVr9AdHjQ.html" guid="_h2-iAfimEdmugcVr9AdHjQ">develop solution</a> activity. The intent is to validate that a stable beta release is
+ achieved and that users can perform acceptance tests.
+</p>
+<h4>
+ Ongoing tasks
+</h4>
+<p>
+ Similarly to any other phase, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any role</a> on
+ the team can submit <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">change requests</a>. The software being developed is achieving beta quality by this
+ point; therefore, defects of high priority are generally addressed during Construction iterations and
+ Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next
+ release of the product.
+</p><!-- END:mainDescription,-239OBD2wagT2qp8fuPWcHQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_y-k0bOtQEdqc1LGhiSPqRg CRC: 1824416172 -->Plan and Manage Iteration<!-- END:presentationName,_y-k0bOtQEdqc1LGhiSPqRg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eE5nEUbpEduLBN1xMBngqw CRC: 2084512818 -->Manage Requirements<!-- END:presentationName,_eE5nEUbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_eE5nEUbpEduLBN1xMBngqw CRC: 2015390557 -->Detail a set of requirements (one or more use cases, scenarios, or supporting requirements).<!-- END:briefDescription,_eE5nEUbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWFjoU9HEdudU75l2xOQTw CRC: 2237470038 -->Develop Solution (for requirement) (within context)<!-- END:presentationName,_MWFjoU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_MWFjoU9HEdudU75l2xOQTw CRC: 1575460021 -->Design, implement, test and integrate the solution for a requirement within a given context.<!-- END:briefDescription,_MWFjoU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-q-X9OHGNRjU5gIyWVibSGQ CRC: 4065423054 --><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern as a way to perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked based on the goals to be achieved using the designed,
+ unit-tested, and integrated source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development may focus on a layer (such as the user interface, business logic,
+ or database access), on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to write and run unit tests against the implementation to make sure the implementation
+ works as designed, both as a unit and integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running developer tests should
+ happen, because they can happen in parallel. You may choose to create and run developer tests before the actual
+ code is created or the reverse sequence.
+</p><!-- END:mainDescription,-q-X9OHGNRjU5gIyWVibSGQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-q-X9OHGNRjU5gIyWVibSGQ CRC: 2872432095 --><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul><!-- END:purpose,-q-X9OHGNRjU5gIyWVibSGQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageNotes<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageNotes,-q-X9OHGNRjU5gIyWVibSGQ CRC: 1279855432 --><p>
+ This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
+ requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
+ be assigned to a developer, and it should be renamed to include the actual requirement name. Optionally, the word
+ <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
+</p>
+<blockquote>
+ <p align="left">
+ Develop <font face="Courier New, Courier, mono">requirement_name</font> (within <font face="Courier New, Courier, mono">context_name</font> context)
+ </p>
+</blockquote>
+<p>
+ If a context is specified, there will be one instance of this pattern for each requirement for each
+ context.
+</p>
+<blockquote>
+ <p>
+ <strong>Example</strong>
+ </p>
+ <ol>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">user interface</font> context)
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">business logic and DB access</font> context)
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 2</font>
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">supplemental requirement 1</font>
+ </li>
+ </ol>
+</blockquote>
+<p>
+ Note that there are four instances of this pattern in the preceding example:
+</p>
+<ul>
+ <li>
+ The first two are related to the same requirement (scenario 1) but within two different contexts
+ </li>
+ <li>
+ The last two are related to different requirements, with no context specified.
+ </li>
+</ul><!-- END:usageNotes,-q-X9OHGNRjU5gIyWVibSGQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_y-3IretQEdqc1LGhiSPqRg CRC: 79270194 -->Validate Build<!-- END:presentationName,_y-3IretQEdqc1LGhiSPqRg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/construction_phase_iteration/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/construction_phase_iteration/model.html
new file mode 100644
index 0000000..08c729f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/construction_phase_iteration/model.html
@@ -0,0 +1,200 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\construction_phase_iteration\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eFeO0EbpEduLBN1xMBngqw CRC: 2417366288 -->Analyst<!-- END:presentationName,_eFeO0EbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eGoFY0bpEduLBN1xMBngqw CRC: 699774998 -->Work Items List<!-- END:presentationName,_eGoFY0bpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eGoFZEbpEduLBN1xMBngqw CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_eGoFZEbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eFeO0UbpEduLBN1xMBngqw CRC: 3319967926 -->Use Case<!-- END:presentationName,_eFeO0UbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eG0SoEbpEduLBN1xMBngqw CRC: 1240688917 -->Glossary<!-- END:presentationName,_eG0SoEbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eFeO00bpEduLBN1xMBngqw CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_eFeO00bpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eFeO0kbpEduLBN1xMBngqw CRC: 2312412063 -->Vision<!-- END:presentationName,_eFeO0kbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eGoFYkbpEduLBN1xMBngqw CRC: 4169312566 -->Find and Outline Requirements<!-- END:presentationName,_eGoFYkbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eGuMB0bpEduLBN1xMBngqw CRC: 218410109 -->Stakeholder<!-- END:presentationName,_eGuMB0bpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eGuMBUbpEduLBN1xMBngqw CRC: 3482111992 -->Detail Requirements<!-- END:presentationName,_eGuMBUbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eHAf4EbpEduLBN1xMBngqw CRC: 857280619 -->Create Test Cases<!-- END:presentationName,_eHAf4EbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eHAf4kbpEduLBN1xMBngqw CRC: 607185224 -->Test Case<!-- END:presentationName,_eHAf4kbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eHAf4UbpEduLBN1xMBngqw CRC: 4227617651 -->Tester<!-- END:presentationName,_eHAf4UbpEduLBN1xMBngqw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWFjo09HEdudU75l2xOQTw CRC: 3876194617 -->Developer<!-- END:presentationName,_MWFjo09HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWFjpE9HEdudU75l2xOQTw CRC: 3403898630 -->Design<!-- END:presentationName,_MWFjpE9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWFjpk9HEdudU75l2xOQTw CRC: 2474353591 -->Developer Test<!-- END:presentationName,_MWFjpk9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWFjpU9HEdudU75l2xOQTw CRC: 263885700 -->Implementation<!-- END:presentationName,_MWFjpU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWFjp09HEdudU75l2xOQTw CRC: 2086788575 -->Build<!-- END:presentationName,_MWFjp09HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqQU9HEdudU75l2xOQTw CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_MWLqQU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqSE9HEdudU75l2xOQTw CRC: 3319967926 -->Use Case<!-- END:presentationName,_MWLqSE9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqRk9HEdudU75l2xOQTw CRC: 69542014 -->Test Log<!-- END:presentationName,_MWLqRk9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqSU9HEdudU75l2xOQTw CRC: 514934396 -->Develop the Architecture<!-- END:presentationName,_MWLqSU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-uRRkE_fEduE1dJ2XtzzkQ CRC: 2417366288 -->Analyst<!-- END:presentationName,_-uRRkE_fEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-uRRkU_fEduE1dJ2XtzzkQ CRC: 218410109 -->Stakeholder<!-- END:presentationName,_-uRRkU_fEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-uRRkk_fEduE1dJ2XtzzkQ CRC: 4227617651 -->Tester<!-- END:presentationName,_-uRRkk_fEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqTU9HEdudU75l2xOQTw CRC: 273197623 -->Test Script<!-- END:presentationName,_MWLqTU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqQk9HEdudU75l2xOQTw CRC: 1822983426 -->Architecture<!-- END:presentationName,_MWLqQk9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqR09HEdudU75l2xOQTw CRC: 3099060277 -->Architect<!-- END:presentationName,_MWLqR09HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqQE9HEdudU75l2xOQTw CRC: 4165556380 -->Design the Solution<!-- END:presentationName,_MWLqQE9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqRE9HEdudU75l2xOQTw CRC: 4143109244 -->Implement the Solution<!-- END:presentationName,_MWLqRE9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqQ09HEdudU75l2xOQTw CRC: 3713996132 -->Implement Developer Tests<!-- END:presentationName,_MWLqQ09HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MWLqRU9HEdudU75l2xOQTw CRC: 1641130134 -->Run Developer Tests<!-- END:presentationName,_MWLqRU9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_y_PjTOtQEdqc1LGhiSPqRg CRC: 642658025 -->Ongoing Tasks<!-- END:presentationName,_y_PjTOtQEdqc1LGhiSPqRg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_y-etQOtQEdqc1LGhiSPqRg CRC: 72170475 -->construction_phase_iteration<!-- END:name,_y-etQOtQEdqc1LGhiSPqRg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_MWLqf09HEdudU75l2xOQTw CRC: 2542690616 -->[major change]<!-- END:value,_MWLqf09HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_MWLqgk9HEdudU75l2xOQTw CRC: 1886462839 -->[small change]<!-- END:value,_MWLqgk9HEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_MWLqjU9HEdudU75l2xOQTw CRC: 2349738384 -->[trivial change]<!-- END:value,_MWLqjU9HEdudU75l2xOQTw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/define_architecture/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/define_architecture/content.html
new file mode 100644
index 0000000..2bcd06e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/define_architecture/content.html
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\define_architecture\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0sx7islgEdmt3adZL5Dmdw CRC: 3292275428 -->Define the Architecture<!-- END:presentationName,_0sx7islgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0sx7islgEdmt3adZL5Dmdw CRC: 1119296514 -->This activity completes the architecture for an iteration.<!-- END:briefDescription,_0sx7islgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb_DvL5Edm6Nvont3uinw CRC: 612684877 --><p>
+ This activity is repeated in each iteration in the Elaboration phase. The main goal of this activity is to
+ propose an <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> that addresses the requirements with high architectural risks, thus
+ providing a solid, yet resilient, foundation on which to build the system functionality.
+</p>
+<p>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> analyzes the architectural constraints, identifies available assets to
+ build the system, defines how the system will be structured, and identifies the initial abstractions and mechanisms
+ that must be provided by the architecture.
+</p>
+<p>
+ Throughout all of the iterations, the architect:
+</p>
+<ul>
+ <li>
+ Identifies commonalities between different requirements to leverage reuse
+ </li>
+ <li>
+ Defines strategies for achieving requirements related to quality
+ </li>
+ <li>
+ Captures and communicates architectural decisions
+ </li>
+</ul><!-- END:mainDescription,_mtb_DvL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: howtoStaff<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:howtoStaff,_mtb_DvL5Edm6Nvont3uinw CRC: 1412193720 --><p>
+ These activities are best carried out by a small team staffed by cross-functional team members. Issues that are
+ typically architecturally significant include usability, performance, scaling, process and thread synchronization, and
+ distribution. The team should also include members with domain experience who can identify key abstractions. The team
+ should also have experience with model organization and layering. The team will need to be able to pull all these
+ disparate threads into a cohesive, coherent (albeit preliminary) architecture.
+</p>
+<p>
+ Because the focus of the architecture effort is shifting toward implementation issues, greater attention needs to be
+ paid to specific technology issues. This will force the architecture team to shift members or expand to include people
+ with distribution and deployment expertise (if those issues are architecturally significant). In order to understand
+ the potential impact of the structure on the implementation model on the ease of integration, expertise in the software
+ build management process is useful to have.
+</p>
+<p>
+ At the same time, it is essential that the architecture team not be composed of a large extended team. A strategy for
+ countering this trend is to retain a relatively small core team with a satellite group of extended team members that
+ are brought in as "consultants" on key issues<b>.</b> This structure also works well for smaller projects where
+ specific expertise may be borrowed or contracted from other organizations; they can be brought in as specific issues
+ need to be addressed.
+</p><!-- END:howtoStaff,_mtb_DvL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageNotes<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageNotes,_mtb_DvL5Edm6Nvont3uinw CRC: 25063113 --><p>
+ The work is best done in several sessions, perhaps performed over a few days (or weeks and months for very large
+ systems). The initial focus will be on the identifying <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Concept: Design Mechanism</a>s and specifiying the important design
+ elements. Care should also be taken to incorporate existing design elements to ensure that new design do not
+ duplicate existing functionality.
+</p>
+<p>
+ As the design emerges, concurrency and distribution issues are introduced. As these issues are considered, changes to
+ design elements may be required to split behavior across processes, threads or nodes.
+</p>
+<p>
+ As the individual models are refined to incorporate the architectural decisions, the results are documented in the
+ Architecture description. The resulting architecture is reviewed.
+</p><!-- END:usageNotes,_mtb_DvL5Edm6Nvont3uinw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/define_architecture/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/define_architecture/model.html
new file mode 100644
index 0000000..b5fccd2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/define_architecture/model.html
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\define_architecture\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d5-nQFY4EdqI9sTOt2pjHw CRC: 3099060277 -->Architect<!-- END:presentationName,_d5-nQFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d6Q7IVY4EdqI9sTOt2pjHw CRC: 1822983426 -->Architecture<!-- END:presentationName,_d6Q7IVY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uknUwb-EEdqb7N6KIeDL8Q CRC: 3403898630 -->Design<!-- END:presentationName,_uknUwb-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ukbHgL-EEdqb7N6KIeDL8Q CRC: 1105243094 -->Analyze the Architectural Requirements<!-- END:presentationName,_ukbHgL-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ezOKIE9DEdudU75l2xOQTw CRC: 2417366288 -->Analyst<!-- END:presentationName,_ezOKIE9DEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_r1Xe0DeqEduCsbgJNeFsSw CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_r1Xe0DeqEduCsbgJNeFsSw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VZk0ZBeDEduXJrZWmtC8tg CRC: 2312412063 -->Vision<!-- END:presentationName,_VZk0ZBeDEduXJrZWmtC8tg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VZk0YxeDEduXJrZWmtC8tg CRC: 1240688917 -->Glossary<!-- END:presentationName,_VZk0YxeDEduXJrZWmtC8tg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uknUwL-EEdqb7N6KIeDL8Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_uknUwL-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ezOKIU9DEdudU75l2xOQTw CRC: 218410109 -->Stakeholder<!-- END:presentationName,_ezOKIU9DEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HTBBME_dEduE1dJ2XtzzkQ CRC: 4227617651 -->Tester<!-- END:presentationName,_HTBBME_dEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HTBBMU_dEduE1dJ2XtzzkQ CRC: 3876194617 -->Developer<!-- END:presentationName,_HTBBMU_dEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_m_gdUMWrEduoutjwLchi0g CRC: 2086788575 -->Build<!-- END:presentationName,_m_gdUMWrEduoutjwLchi0g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_r1QxIDeqEduCsbgJNeFsSw CRC: 1580379618 -->Project Manager<!-- END:presentationName,_r1QxIDeqEduCsbgJNeFsSw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ezOKIk9DEdudU75l2xOQTw CRC: 3319967926 -->Use Case<!-- END:presentationName,_ezOKIk9DEdudU75l2xOQTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_vAmGIL-EEdqb7N6KIeDL8Q CRC: 514934396 -->Develop the Architecture<!-- END:presentationName,_vAmGIL-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0sx7iclgEdmt3adZL5Dmdw CRC: 3987952218 -->define_architecture<!-- END:name,_0sx7iclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.html
new file mode 100644
index 0000000..3e82946
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\determine_architectural_feasibility\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0sluQslgEdmt3adZL5Dmdw CRC: 3175277106 -->Determine Architectural Feasibility<!-- END:presentationName,_0sluQslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0sluQslgEdmt3adZL5Dmdw CRC: 3629141526 -->Confirm that the project is feasible by constructing an architectural proof-of-concept.<!-- END:briefDescription,_0sluQslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: howtoStaff<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:howtoStaff,_mtb_DfL5Edm6Nvont3uinw CRC: 840508960 --><p>
+ As with <a class="elementLinkWithType" href="./../../openup_basic/capabilitypatterns/define_architecture,_0rcewclgEdmt3adZL5Dmdw.html" guid="_0rcewclgEdmt3adZL5Dmdw">Activity: Define the Architecture</a>, this activity is best carried out by a small team
+ staffed by cross-functional team members. Issues that are typically architecturally significant include performance,
+ scaling, process and thread synchronization, and distribution. The team should also include members with domain
+ experience who can identify key abstractions. The team should also have experience with model organization and
+ layering. From these inputs, the team will need to be able to synthesize a model, or even a prototype, of a solution.
+</p><!-- END:howtoStaff,_mtb_DfL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageNotes<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageNotes,_mtb_DfL5Edm6Nvont3uinw CRC: 1377766981 --><p>
+ The major effort occurs early in the Inception phase; thereafter, the system should be assessed at every iteration
+ to ensure that the design is still on track with the architecture (see <a class="elementLinkWithType" href="./../../openup_basic/capabilitypatterns/manage_iteration,_0nJNkslgEdmt3adZL5Dmdw.html" guid="_0nJNkslgEdmt3adZL5Dmdw">Capability Pattern: Plan and Manage Iteration</a>).
+</p><!-- END:usageNotes,_mtb_DfL5Edm6Nvont3uinw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.html
new file mode 100644
index 0000000..3ad3132
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.html
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\determine_architectural_feasibility\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qQROgFY4EdqI9sTOt2pjHw CRC: 3099060277 -->Architect<!-- END:presentationName,_qQROgFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qQppAFY4EdqI9sTOt2pjHw CRC: 1822983426 -->Architecture<!-- END:presentationName,_qQppAFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qQjiYFY4EdqI9sTOt2pjHw CRC: 3403898630 -->Design<!-- END:presentationName,_qQjiYFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qoEDcFY4EdqI9sTOt2pjHw CRC: 3876194617 -->Developer<!-- END:presentationName,_qoEDcFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NXkrwsWpEduoutjwLchi0g CRC: 2086788575 -->Build<!-- END:presentationName,_NXkrwsWpEduoutjwLchi0g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_lqOzsL-EEdqb7N6KIeDL8Q CRC: 1105243094 -->Analyze the Architectural Requirements<!-- END:presentationName,_lqOzsL-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PJJ3AE_dEduE1dJ2XtzzkQ CRC: 2417366288 -->Analyst<!-- END:presentationName,_PJJ3AE_dEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HTpzcDSLEdursMWmT1aZyw CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_HTpzcDSLEdursMWmT1aZyw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_g2XAwheDEduXJrZWmtC8tg CRC: 1240688917 -->Glossary<!-- END:presentationName,_g2XAwheDEduXJrZWmtC8tg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mKmV0L-EEdqb7N6KIeDL8Q CRC: 2312412063 -->Vision<!-- END:presentationName,_mKmV0L-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_lqbA8L-EEdqb7N6KIeDL8Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_lqbA8L-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PJJ3AU_dEduE1dJ2XtzzkQ CRC: 218410109 -->Stakeholder<!-- END:presentationName,_PJJ3AU_dEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PJJ3Ak_dEduE1dJ2XtzzkQ CRC: 4227617651 -->Tester<!-- END:presentationName,_PJJ3Ak_dEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PJJ3A0_dEduE1dJ2XtzzkQ CRC: 1580379618 -->Project Manager<!-- END:presentationName,_PJJ3A0_dEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NXkrwcWpEduoutjwLchi0g CRC: 3319967926 -->Use Case<!-- END:presentationName,_NXkrwcWpEduoutjwLchi0g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NXkrwMWpEduoutjwLchi0g CRC: 514934396 -->Develop the Architecture<!-- END:presentationName,_NXkrwMWpEduoutjwLchi0g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0sluQclgEdmt3adZL5Dmdw CRC: 778923866 -->determine_architectural_feasibility<!-- END:name,_0sluQclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/develop_solution/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/develop_solution/content.html
new file mode 100644
index 0000000..7df8782
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/develop_solution/content.html
@@ -0,0 +1,124 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\develop_solution\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_h2-iAfimEdmugcVr9AdHjQ CRC: 2237470038 -->Develop Solution (for requirement) (within context)<!-- END:presentationName,_h2-iAfimEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_h2-iAfimEdmugcVr9AdHjQ CRC: 1575460021 -->Design, implement, test and integrate the solution for a requirement within a given context.<!-- END:briefDescription,_h2-iAfimEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_h6zSEPimEdmugcVr9AdHjQ CRC: 788556680 --><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern as a way to perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked based on the goals to be achieved using the designed,
+ unit-tested, and integrated source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development may focus on a layer (such as the user interface, business logic,
+ or database access), on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to write and run unit tests against the implementation to make sure the implementation
+ works as designed, both as a unit and integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running developer tests should
+ happen, because they can happen in parallel. You may choose to create developer tests and run them before the actual
+ code is created or the reverse sequence.
+</p><!-- END:mainDescription,_h6zSEPimEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_h6zSEPimEdmugcVr9AdHjQ CRC: 2872432095 --><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul><!-- END:purpose,_h6zSEPimEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageNotes<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageNotes,_h6zSEPimEdmugcVr9AdHjQ CRC: 3966273720 --><p>
+ This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
+ requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
+ be assigned to a developer, and it should be renamed to include the actual requirement name. Optionally, the word
+ <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
+</p>
+<blockquote>
+ <p align="left">
+ Develop requirement_name (within context_name context)
+ </p>
+</blockquote>
+<p>
+ If a context is specified, there will be one instance of this pattern for each requirement for each
+ context.
+</p>
+<blockquote>
+ <p>
+ <strong>Example</strong>
+ </p>
+ <ol>
+ <li>
+ Develop scenario 1 (within user interface context)
+ </li>
+ <li>
+ Develop scenario 1 (within business logic and DB access context)
+ </li>
+ <li>
+ Develop scenario 2
+ </li>
+ <li>
+ Develop supplemental requirement 1
+ </li>
+ </ol>
+</blockquote>
+<p>
+ Note that there are four instances of this pattern in the preceding example:
+</p>
+<ul>
+ <li>
+ The first two are related to the same requirement (scenario 1) but within two different contexts
+ </li>
+ <li>
+ The last two are related to different requirements, with no context specified.
+ </li>
+</ul><!-- END:usageNotes,_h6zSEPimEdmugcVr9AdHjQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/develop_solution/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/develop_solution/model.html
new file mode 100644
index 0000000..81626a4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/develop_solution/model.html
@@ -0,0 +1,140 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\develop_solution\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9kUSEFY4EdqI9sTOt2pjHw CRC: 3876194617 -->Developer<!-- END:presentationName,_9kUSEFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9k_AcFY4EdqI9sTOt2pjHw CRC: 3403898630 -->Design<!-- END:presentationName,_9k_AcFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-Y3UcFY4EdqI9sTOt2pjHw CRC: 2474353591 -->Developer Test<!-- END:presentationName,_-Y3UcFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-YrHMFY4EdqI9sTOt2pjHw CRC: 263885700 -->Implementation<!-- END:presentationName,_-YrHMFY4EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_AdllQFY5EdqI9sTOt2pjHw CRC: 2086788575 -->Build<!-- END:presentationName,_AdllQFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cMHeAL-FEdqb7N6KIeDL8Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_cMHeAL-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_QN4E4ALlEduHjPEP_YPH-g CRC: 3319967926 -->Use Case<!-- END:presentationName,_QN4E4ALlEduHjPEP_YPH-g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d4k_0L-FEdqb7N6KIeDL8Q CRC: 69542014 -->Test Log<!-- END:presentationName,_d4k_0L-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cL1KIL-FEdqb7N6KIeDL8Q CRC: 4165556380 -->Design the Solution<!-- END:presentationName,_cL1KIL-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_rQ9xIMjkEdqIm8AJUZUQYg CRC: 3099060277 -->Architect<!-- END:presentationName,_rQ9xIMjkEdqIm8AJUZUQYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cMHeAb-FEdqb7N6KIeDL8Q CRC: 1822983426 -->Architecture<!-- END:presentationName,_cMHeAb-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_KAnAYE9PEdumneEH4I4Yqg CRC: 2417366288 -->Analyst<!-- END:presentationName,_KAnAYE9PEdumneEH4I4Yqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BmbHQE_cEduE1dJ2XtzzkQ CRC: 218410109 -->Stakeholder<!-- END:presentationName,_BmbHQE_cEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BmbHQU_cEduE1dJ2XtzzkQ CRC: 4227617651 -->Tester<!-- END:presentationName,_BmbHQU_cEduE1dJ2XtzzkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_RfwvEDOvEduqsLmIADMQ9g CRC: 273197623 -->Test Script<!-- END:presentationName,_RfwvEDOvEduqsLmIADMQ9g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_dAoEIL-FEdqb7N6KIeDL8Q CRC: 4143109244 -->Implement the Solution<!-- END:presentationName,_dAoEIL-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cnzUcL-FEdqb7N6KIeDL8Q CRC: 3713996132 -->Implement Developer Tests<!-- END:presentationName,_cnzUcL-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d4GesL-FEdqb7N6KIeDL8Q CRC: 1641130134 -->Run Developer Tests<!-- END:presentationName,_d4GesL-FEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_h2-iAPimEdmugcVr9AdHjQ CRC: 1053056633 -->develop_solution<!-- END:name,_h2-iAPimEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_mXzzEURlEduP07d3x5Xi-g CRC: 1820824646 -->[typical change]<!-- END:value,_mXzzEURlEduP07d3x5Xi-g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_JJvg8URmEduP07d3x5Xi-g CRC: 2349738384 -->[trivial change]<!-- END:value,_JJvg8URmEduP07d3x5Xi-g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_jrCQAcmJEduwrYVlQ9zp3w CRC: 3656888913 -->[fail]<!-- END:value,_jrCQAcmJEduwrYVlQ9zp3w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_mAr4wcmJEduwrYVlQ9zp3w CRC: 3938252875 -->[pass]<!-- END:value,_mAr4wcmJEduwrYVlQ9zp3w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_tM7dAcmJEduwrYVlQ9zp3w CRC: 3896367828 -->[more work to do]<!-- END:value,_tM7dAcmJEduwrYVlQ9zp3w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_yzpN4cmJEduwrYVlQ9zp3w CRC: 215907085 -->[requirement realized]<!-- END:value,_yzpN4cmJEduwrYVlQ9zp3w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.html
new file mode 100644
index 0000000..5fa9f67
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.html
@@ -0,0 +1,177 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\elaboration_phase_iteration\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0sTaYMlgEdmt3adZL5Dmdw CRC: 826551294 -->Elaboration Phase Iteration<!-- END:presentationName,_0sTaYMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0sTaYMlgEdmt3adZL5Dmdw CRC: 1719725133 -->This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Elaboration phase. Each activity and related goals are described.<!-- END:briefDescription,_0sTaYMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb_BPL5Edm6Nvont3uinw CRC: 1505044932 --><h3> Introduction </h3>
+<p> Most activities during a typical iteration in Elaboration phase happen in
+ parallel. Essentially, the main objectives for Elaboration are related to better
+ understanding the requirements, creating and establishing
+ a baseline for the architecture for the system, and mitigating top-priority
+ risks. </p>
+<p> The activities performed in a typical iteration during the
+ Elaboration phase are described below. </p>
+<h4> Manage iteration </h4>
+<p> This activity is performed throughout the project lifecycle.
+ The goal of this activity is to identify risks and issues early enough
+ that they can be mitigated, to establish the goals for the iteration,
+ and to support the development team in reaching these goals. </p>
+<p> The <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> and the team launche the iteration, allocating work items to team
+ members (some project teams will prefer to have members volunteer to perform
+ work). The project manager collaborates with the team to break down the work
+ items into development tasks to perform in that iteration. This provides a more
+ accurate estimate of time to spend on what can be realistically achieved. </p>
+<p> As the iteration runs, the project manager performs
+ monitoring and control of the project by regularly checking the
+ status of work completed, the work to do
+ next, and issues blocking the progress<strong>.
+ </strong>In some projects, this checking occurs
+ in daily meetings, which allows for a more precise understanding
+ of how the work in an iteration is progressing. As
+ needed, the team makes corrections to achieve what was planned. The overall
+ idea is that risks and issues are identified and managed throughout the iteration.
+ And everyone knows the project status.</p>
+<p>The prioritization of work for a given iteration takes place. Project manager, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>,
+ and the remaining team members agree on what is supposed to be developed during
+ that iteration.</p>
+<p>As in any other iteration assessment, demonstration of implemented functionality
+ planned for that iteration is the key success criterion. During iteration assessments
+ in Elaboration, though, keep the phase objectives in mind. As Elaboration iterations
+ are performed, an executable architecture evolves, and you establish a baseline
+ at the end of the phase. In addition, requirements are better understood and
+ detailed. Essential risks, including the architectural ones, have been mitigated.
+ These results help the project manager produce more accurate estimates
+ for the project schedule and cost.</p>
+<h4> Manage requirements </h4>
+<p> This activity is repeated throughout the project lifecycle.
+ The goal of this activity is to understand and prioritize stakeholder needs
+ and associated requirements for the system, and also to
+ capture these in a form that supports effective communication and collaboration
+ between the stakeholders and development team. </p>
+<p> During the Elaboration phase,
+ requirements can still be captured and outlined as customer needs arise. The
+ prioritization of requirements determines when
+ new requirements are going to be implemented. High-risk, architecturally significant
+ requirements are detailed to the extent necessary to be
+ able to use that information as input to architecture and development
+ activities in the current iteration, plus in planning
+ for the next iteration.</p>
+<p><a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test
+ cases</a> describe which requirements are being tested in that iteration.
+</p>
+<p> <strong>Note: <br />
+ <br/>
+ </strong>The emphasis on finding, outlining and detailing requirements varies
+ from phase to phase. Iterations in Inception and early Elaboration tend to focus
+ more on identifying and outlining requirements in general and on
+ detailing high-priority and architecturally
+ significant requirements. During iterations in late Elaboration and early Construction,
+ the remaining requirements are usually outlined and detailed. </p>
+<h4> Define the architecture </h4>
+<p> This activity is repeated in each iteration in the
+ Elaboration phase. The main goal of this activity is to propose an
+ <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a>
+ that addresses the requirements with high architectural risks, thus providing
+ a solid, yet resilient, foundation on which to build the system functionality.</p>
+<p> The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a>
+ analyzes the architectural constraints, identifies available assets to build
+ the system, defines how the system will be structured, and identifies the initial
+ abstractions and mechanisms that must be provided by the architecture. </p>
+<p> Throughout all of the iterations, the architect: </p>
+<ul>
+
+ <li> Identifies commonalities between different requirements to leverage reuse
+ </li>
+ <li> Defines strategies for achieving requirements related
+ to quality</li>
+ <li> Captures and communicates architectural decisions </li>
+</ul>
+<h4> Develop solution for requirement within context</h4>
+<p> This activity is instantiated multiple times, in parallel, for each development
+ task planned for that iteration. The main goal of this activity is an executable
+ system that provides the incremental quality and functionality for the specified
+ requirements within the specified context. </p>
+<p> As the requirements planned for the iteration are broken down into development
+ tasks, these are assigned by the project managers to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>
+ (some project teams prefer to have team members sign up for development tasks
+ themselves). </p>
+<p> The solution to be developed is for a particular requirement within a context,
+ which reflects the idea of breaking down requirements into development tasks.
+ As an example, a particular use-case scenario within the context of database
+ access could be assigned to a developer; whereas, the same scenario within the
+ user interface and business logic contexts could be assigned to a different
+ developer. In this example, more than one developer is working on a particular
+ piece of functionality to be delivered in a particular iteration. As they develop
+ the requirement within the context they were assigned to, they perform <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html" guid="_0YuXEclgEdmt3adZL5Dmdw">tests</a>
+ and integrate their work to create <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>.
+</p>
+<h4> Validate build </h4>
+<p> This activity is repeated throughout the project
+ lifecycle. The main goal of this activity is to validate the current increment
+ of the system against the requirements allocated to it. </p>
+<p> The intent is to validate that the high-priority requirements implemented
+ reflect a robust architecture so that remaining requirements can be implemented
+ on top of that architecture. As developer develop the solution for the requirements
+ in a given iteration, the integrated source code is unit-tested. Then, a separate
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">tester</a>
+ conducts system-level testing in parallel with development to make sure that
+ the solution, which is continuously being integrated, matches what is specified
+ in the requirements. Then, the tester defines what techniques to use, what the
+ data input is, what <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/test_suite,_0aDz0MlgEdmt3adZL5Dmdw.html" guid="_0aDz0MlgEdmt3adZL5Dmdw">test
+ suites</a> to create. As tests are performed, defects found are reported and
+ added to the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">work
+ items list</a>, so they can be prioritized and assigned to team members. </p>
+<h4> Ongoing tasks </h4>
+<p> This activity includes tasks that happen throughout the iteration on an ongoing
+ basis but are not necessarily part of a plan. For example, at any time, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any
+ role</a> in the project team can issue a <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">change
+ request</a>, either because there are requests for enhancements, or defects
+ are found. These change requests are part of the work items list and are prioritized
+ and assigned to team members. Anyone can be assigned to make changes that develop
+ enhancements or fix defects. </p>
+<h4> </h4><!-- END:mainDescription,_mtb_BPL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0rWYIslgEdmt3adZL5Dmdw CRC: 1824416172 -->Plan and Manage Iteration<!-- END:presentationName,_0rWYIslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0ruyoclgEdmt3adZL5Dmdw CRC: 2084512818 -->Manage Requirements<!-- END:presentationName,_0ruyoclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0rcewclgEdmt3adZL5Dmdw CRC: 3292275428 -->Define the Architecture<!-- END:presentationName,_0rcewclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0rilYclgEdmt3adZL5Dmdw CRC: 79270194 -->Validate Build<!-- END:presentationName,_0rilYclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.html
new file mode 100644
index 0000000..9a913da
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\elaboration_phase_iteration\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_WrXvwPinEdmugcVr9AdHjQ CRC: 2237470038 -->Develop Solution (for requirement) (within context)<!-- END:presentationName,_WrXvwPinEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_TAVx0CliEdqjQsaFX0CJTw CRC: 642658025 -->Ongoing Tasks<!-- END:presentationName,_TAVx0CliEdqjQsaFX0CJTw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0rWYIMlgEdmt3adZL5Dmdw CRC: 3512191839 -->elaboration_phase_iteration<!-- END:name,_0rWYIMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/inception_phase_iteration/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/inception_phase_iteration/content.html
new file mode 100644
index 0000000..aad0bf0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/inception_phase_iteration/content.html
@@ -0,0 +1,159 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\inception_phase_iteration\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0o3r4slgEdmt3adZL5Dmdw CRC: 1693890671 -->Inception Phase Iteration<!-- END:presentationName,_0o3r4slgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0o3r4slgEdmt3adZL5Dmdw CRC: 3157703874 -->This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Inception phase. Each activity and related goals are described.<!-- END:briefDescription,_0o3r4slgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb-6_L5Edm6Nvont3uinw CRC: 1159950529 --><h3>
+ Introduction
+</h3>
+<p>
+ The project starts with the assumption that the business case has been created, the <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> has been identified, the team (at least for the first iteration) has been defined, the development
+ environment (including tools and infrastructure) is in place, and the process to be followed is the <a
+ class="elementlinkwithusertext"
+ href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">delivery process</a> suggested by OpenUP/Basic. The number and length of each Inception
+ iteration will vary, depending upon the needs of the project.
+</p>
+<p>
+ In the next sections we describe the activities performed in a typical iteration during Inception phase.
+</p>
+<h4>
+ Initiate project
+</h4>
+<p>
+ This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity
+ is to establish the vision for the project and the project plan at a high level of granularity.
+</p>
+<p>
+ The people in the roles involved at this time collaborate to perform this activity:
+</p>
+<ul>
+ <li>
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html"
+ guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholder</a> roles work together to define the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> for the project, capturing the customer needs and features for the system
+ under development. Needs and features are captured to the extent required to reach agreement about the scope of the
+ project.
+ </li>
+ <li>
+ Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level <a
+ class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html"
+ guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases and time-boxed iterations for each phase. This
+ plan and the allocation of staff to the project evolve throughout the phases to reflect the project pace, as
+ necessary.
+ </li>
+</ul>
+<h4>
+ Manage iteration
+</h4>
+<p>
+ This activity is about the ongoing work performed by the project manager and the development team to initiate and
+ conduct a given iteration. It consists of status reporting, handling of exceptions and problems, identifying risks, and
+ reprioritizing work, as needed.
+</p>
+<p>
+ At the end of the iteration, the project manager conducts a <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html"
+ guid="_0bA2EMlgEdmt3adZL5Dmdw">status assessment</a> with the development team and stakeholders.
+</p>
+<p>
+ If the iteration end coincides with the phase end, meeting the objectives for that phase should be used as success
+ criteria for leaving the iteration. The iteration assessment should verify that the objectives for
+ the Iteration phase have been achieved, including agreement on the key functionalities and at least one
+ possible solution for the system under development, as well as a reasonable understanding of cost, schedule and risks
+ associated with the project.
+</p>
+<p>
+ Based on demonstration of key functionalities and architectural feasibility during the assessment, it becomes clear
+ that either the project can proceed at the given pace or that a reprioritization of work needs to happen. As a
+ consequence, the project manager may need to refine the project scope and duration.
+</p>
+<h4>
+ Manage requirements
+</h4>
+<p>
+ This activity is first performed in the first iteration, and repeated throughout the lifecycle. The goal of this
+ activity is to understand and prioritize stakeholder needs, and associated requirements for the system, and capture
+ these in a form that will support effective communications and collaboration between the stakeholders and development
+ team.
+</p>
+<p>
+ As the project is initiated, the <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>
+ gathers <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html"
+ guid="_0Wh-sMlgEdmt3adZL5Dmdw">requirements</a> from stakeholders and captures associated work items for
+ development in the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">work items list</a> to facilitate prioritization and planning. As needed,
+ requirements are outlined and detailed in <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">use-case</a> specifications and <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">supporting requirements</a> to the extent needed to provide information for the <a
+ class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> to create a prototype of the architecture and for the project manager to
+ scope and plan the next iteration.
+</p>
+<h4>
+ Determine architectural feasibility
+</h4>
+<p>
+ This activity is initiated in the Inception phase and completed in the Elaboration phase. The goal of this activity is
+ to establish an architecture for the system that provides the high-level design that maximizes stakeholder
+ benefit, while respecting the constraints placed on the system and the development team.
+</p>
+<p>
+ Based on requirements being captured and detailed in parallel with this activity, the architect analyzes the
+ architectural constraints and leverages the available assets and technology to propose an architectural
+ proof-of-concept. This early architectural prototype is used both to demonstrate the feasibility of the project, by
+ using the selected candidate architecture, and to mitigate one or more architecturally significant <a
+ class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html"
+ guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a>.
+</p><!-- END:mainDescription,_mtb-6_L5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0oSdE8lgEdmt3adZL5Dmdw CRC: 2715165358 -->Initiate Project<!-- END:presentationName,_0oSdE8lgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0okw8clgEdmt3adZL5Dmdw CRC: 2084512818 -->Manage Requirements<!-- END:presentationName,_0okw8clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0oreoclgEdmt3adZL5Dmdw CRC: 3175277106 -->Determine Architectural Feasibility<!-- END:presentationName,_0oreoclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/inception_phase_iteration/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/inception_phase_iteration/model.html
new file mode 100644
index 0000000..4db70c5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/inception_phase_iteration/model.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\inception_phase_iteration\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_jLaKwP77Edm1zMZYtD3GjA CRC: 1824416172 -->Plan and Manage Iteration<!-- END:presentationName,_jLaKwP77Edm1zMZYtD3GjA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0oSdEclgEdmt3adZL5Dmdw CRC: 2283946168 -->inception_phase_iteration<!-- END:name,_0oSdEclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/initiate_project/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/initiate_project/content.html
new file mode 100644
index 0000000..fd5f4f7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/initiate_project/content.html
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\initiate_project\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0pWNA8lgEdmt3adZL5Dmdw CRC: 2715165358 -->Initiate Project<!-- END:presentationName,_0pWNA8lgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0pWNA8lgEdmt3adZL5Dmdw CRC: 1253611267 -->This capability pattern bundles tasks required to define the vision and create a project plan.<!-- END:briefDescription,_0pWNA8lgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb-9fL5Edm6Nvont3uinw CRC: 2376051462 --><p>
+ This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity
+ is to establish the vision for the project and the project plan at a high level of granularity.
+</p>
+<p>
+ The people in the roles involved at this time collaborate to perform this activity:
+</p>
+<ul>
+ <li>
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholder</a> roles work together to define the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> for the project, capturing the customer needs and features for the system
+ under development. Needs and features are captured to the extent required to reach agreement about the scope of the
+ project.
+ </li>
+ <li>
+ Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases and time-boxed iterations for each phase. This
+ plan and the allocation of staff to the project evolve throughout the phases and defines the pace of the
+ project.
+ </li>
+</ul><!-- END:mainDescription,_mtb-9fL5Edm6Nvont3uinw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/initiate_project/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/initiate_project/model.html
new file mode 100644
index 0000000..bc1098c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/initiate_project/model.html
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\initiate_project\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VNpT0FY5EdqI9sTOt2pjHw CRC: 2417366288 -->Analyst<!-- END:presentationName,_VNpT0FY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VNvacFY5EdqI9sTOt2pjHw CRC: 2312412063 -->Vision<!-- END:presentationName,_VNvacFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PFnTkOB7EdqnKu908IEluw CRC: 1240688917 -->Glossary<!-- END:presentationName,_PFnTkOB7EdqnKu908IEluw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_79bQ4DoCEdu0yYZ2bsCXog CRC: 2887983663 -->Define Vision<!-- END:presentationName,_79bQ4DoCEdu0yYZ2bsCXog -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_J8-00MAZEdqX-s4mWhkyqQ CRC: 218410109 -->Stakeholder<!-- END:presentationName,_J8-00MAZEdqX-s4mWhkyqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_XKDWIFY5EdqI9sTOt2pjHw CRC: 3237280059 -->Plan the Project<!-- END:presentationName,_XKDWIFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_S8dNQMBFEdqSgKaj2SZBmg CRC: 3099060277 -->Architect<!-- END:presentationName,_S8dNQMBFEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_S8dNQsBFEdqSgKaj2SZBmg CRC: 4227617651 -->Tester<!-- END:presentationName,_S8dNQsBFEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4Y1wML3JEdqfrv3k16plXw CRC: 699774998 -->Work Items List<!-- END:presentationName,_4Y1wML3JEdqfrv3k16plXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_XKbwoFY5EdqI9sTOt2pjHw CRC: 659198141 -->Project Plan<!-- END:presentationName,_XKbwoFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_hhnXEDeqEduCsbgJNeFsSw CRC: 3469038815 -->Risk List<!-- END:presentationName,_hhnXEDeqEduCsbgJNeFsSw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_XKVqAFY5EdqI9sTOt2pjHw CRC: 1580379618 -->Project Manager<!-- END:presentationName,_XKVqAFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0pWNAslgEdmt3adZL5Dmdw CRC: 203744115 -->initiate_project<!-- END:name,_0pWNAslgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_iteration/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_iteration/content.html
new file mode 100644
index 0000000..0aa4f53
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_iteration/content.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\manage_iteration\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0nJNkslgEdmt3adZL5Dmdw CRC: 1824416172 -->Plan and Manage Iteration<!-- END:presentationName,_0nJNkslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0nJNkslgEdmt3adZL5Dmdw CRC: 4051969882 -->Initiate the iteration and assign work to team members. Monitor and communicate project status to external stakeholders. Identify and handle exceptions and problems.<!-- END:briefDescription,_0nJNkslgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_iteration/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_iteration/model.html
new file mode 100644
index 0000000..a971c0f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_iteration/model.html
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\manage_iteration\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mZDP4FY5EdqI9sTOt2pjHw CRC: 1580379618 -->Project Manager<!-- END:presentationName,_mZDP4FY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mZVjwFY5EdqI9sTOt2pjHw CRC: 3699738420 -->Iteration Plan<!-- END:presentationName,_mZVjwFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mZt-QFY5EdqI9sTOt2pjHw CRC: 659198141 -->Project Plan<!-- END:presentationName,_mZt-QFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_oNnk0FY5EdqI9sTOt2pjHw CRC: 699774998 -->Work Items List<!-- END:presentationName,_oNnk0FY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DUCuoDk-EduFTqg5hiiQIw CRC: 3469038815 -->Risk List<!-- END:presentationName,_DUCuoDk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_TPsdoUmSEduO0bs89Khm8Q CRC: 4196749033 -->Status Assessment<!-- END:presentationName,_TPsdoUmSEduO0bs89Khm8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SZICAEmSEduO0bs89Khm8Q CRC: 383256678 -->Plan Iteration<!-- END:presentationName,_SZICAEmSEduO0bs89Khm8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DT8oATk-EduFTqg5hiiQIw CRC: 3099060277 -->Architect<!-- END:presentationName,_DT8oATk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SZOIoEmSEduO0bs89Khm8Q CRC: 1822983426 -->Architecture<!-- END:presentationName,_SZOIoEmSEduO0bs89Khm8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DT8oADk-EduFTqg5hiiQIw CRC: 2417366288 -->Analyst<!-- END:presentationName,_DT8oADk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SZOIoUmSEduO0bs89Khm8Q CRC: 2312412063 -->Vision<!-- END:presentationName,_SZOIoUmSEduO0bs89Khm8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DT8oAjk-EduFTqg5hiiQIw CRC: 4227617651 -->Tester<!-- END:presentationName,_DT8oAjk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DT8oAzk-EduFTqg5hiiQIw CRC: 3876194617 -->Developer<!-- END:presentationName,_DT8oAzk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DT8oBTk-EduFTqg5hiiQIw CRC: 218410109 -->Stakeholder<!-- END:presentationName,_DT8oBTk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_oNJDsFY5EdqI9sTOt2pjHw CRC: 475284402 -->Manage Iteration<!-- END:presentationName,_oNJDsFY5EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_DT8oBDk-EduFTqg5hiiQIw CRC: 1617929191 -->Any Role<!-- END:presentationName,_DT8oBDk-EduFTqg5hiiQIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_TPsdoEmSEduO0bs89Khm8Q CRC: 2553329503 -->Assess Results<!-- END:presentationName,_TPsdoEmSEduO0bs89Khm8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0nJNkclgEdmt3adZL5Dmdw CRC: 2396546169 -->manage_iteration<!-- END:name,_0nJNkclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_requirements/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_requirements/content.html
new file mode 100644
index 0000000..066fbaa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_requirements/content.html
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\manage_requirements\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0o9ygclgEdmt3adZL5Dmdw CRC: 2084512818 -->Manage Requirements<!-- END:presentationName,_0o9ygclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0o9ygclgEdmt3adZL5Dmdw CRC: 2217099519 -->Detail a set of requirements (one or more use cases, scenarios or supporting requirements).<!-- END:briefDescription,_0o9ygclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb-8_L5Edm6Nvont3uinw CRC: 3202597504 --><p>
+ This activity describes the tasks performed to gather, specify, analyze and validate a subset of
+ system's requirements prior to implementation and verification. This does not imply that all
+ requirements are detailed prior to commencing implementation. Rather, this activity is performed throughout the
+ lifecycle with <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s and the entire development team collaborating to ensure that a clear,
+ consistent, correct, verifiable, and feasible set of requirements is available, as needed, to drive
+ implementation and verification.
+</p>
+<p>
+ During Inception, the focus is on gaining agreement on the problem to be solved, gathering stakeholder needs
+ and capturing high-level system features (see activity <a class="elementLink" href="./../../openup_basic/capabilitypatterns/initiate_project,_0pWNA8lgEdmt3adZL5Dmdw.html" guid="_0pWNA8lgEdmt3adZL5Dmdw">Initiate Project</a>).
+</p>
+<p>
+ During Elaboration, the focus shifts to defining the solution. This consists of finding those requirements that
+ have most value to stakeholders, that are particularly challenging or risky, or that are architecturally significant
+ (See <a class="elementLinkWithType" href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>). Requirements that
+ are prioritized, via the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, for implementation in the early iterations are then described
+ in sufficient detail to validate the development teams understanding of the requirements, to ensure concurrence with
+ stakeholders, and to permit software development to begin (see <a class="elementLinkWithType" href="./../../openup_basic/tasks/detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw.html" guid="_0e1mIMlgEdmt3adZL5Dmdw">Task: Detail Requirements</a>). For each of these requirements, associated test cases are defined to ensure that the
+ requirements are verifiable and to provide the guidance needed for verification and validation (see <a class="elementLinkWithType" href="./../../openup_basic/tasks/create_test_case,_0iwc0clgEdmt3adZL5Dmdw.html" guid="_0iwc0clgEdmt3adZL5Dmdw">Task: Create Test Cases</a>).
+</p>
+<p>
+ During Construction, the focus shifts to refining the system definition<em>.</em> This consists of detailing the
+ remaining requirements and associated test cases as needed to drive implementation and verification, and managing
+ requirements change (see activity <a class="elementLink" href="./../../openup_basic/capabilitypatterns/ongoing_tasks,_0pJ_xslgEdmt3adZL5Dmdw.html" guid="_0pJ_xslgEdmt3adZL5Dmdw">Ongoing Tasks</a>).
+</p><!-- END:mainDescription,_mtb-8_L5Edm6Nvont3uinw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_requirements/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_requirements/model.html
new file mode 100644
index 0000000..135dcc6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/manage_requirements/model.html
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\manage_requirements\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wGSUwFY6EdqI9sTOt2pjHw CRC: 2417366288 -->Analyst<!-- END:presentationName,_wGSUwFY6EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Y5DAML-EEdqb7N6KIeDL8Q CRC: 699774998 -->Work Items List<!-- END:presentationName,_Y5DAML-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Y5DAMb-EEdqb7N6KIeDL8Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_Y5DAMb-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_86w-oOB4EdqnKu908IEluw CRC: 1240688917 -->Glossary<!-- END:presentationName,_86w-oOB4EdqnKu908IEluw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wGeiAFY6EdqI9sTOt2pjHw CRC: 3319967926 -->Use Case<!-- END:presentationName,_wGeiAFY6EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wG28gFY6EdqI9sTOt2pjHw CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_wG28gFY6EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wGw14FY6EdqI9sTOt2pjHw CRC: 2312412063 -->Vision<!-- END:presentationName,_wGw14FY6EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Y42y8L-EEdqb7N6KIeDL8Q CRC: 4169312566 -->Find and Outline Requirements<!-- END:presentationName,_Y42y8L-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2tHGoMAYEdqX-s4mWhkyqQ CRC: 218410109 -->Stakeholder<!-- END:presentationName,_2tHGoMAYEdqX-s4mWhkyqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_F6WiEMEQEduTGJ8i4u8TMw CRC: 3099060277 -->Architect<!-- END:presentationName,_F6WiEMEQEduTGJ8i4u8TMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_F6WiEcEQEduTGJ8i4u8TMw CRC: 3876194617 -->Developer<!-- END:presentationName,_F6WiEcEQEduTGJ8i4u8TMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_kF8tYDbsEduMn613sF6-Uw CRC: 4227617651 -->Tester<!-- END:presentationName,_kF8tYDbsEduMn613sF6-Uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_kF8tYTbsEduMn613sF6-Uw CRC: 607185224 -->Test Case<!-- END:presentationName,_kF8tYTbsEduMn613sF6-Uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZRfVYL-EEdqb7N6KIeDL8Q CRC: 3482111992 -->Detail Requirements<!-- END:presentationName,_ZRfVYL-EEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_kFwgIDbsEduMn613sF6-Uw CRC: 857280619 -->Create Test Cases<!-- END:presentationName,_kFwgIDbsEduMn613sF6-Uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0o9ygMlgEdmt3adZL5Dmdw CRC: 3742244975 -->manage_requirements<!-- END:name,_0o9ygMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/ongoing_tasks/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/ongoing_tasks/content.html
new file mode 100644
index 0000000..15b850f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/ongoing_tasks/content.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\ongoing_tasks\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0pJ_xslgEdmt3adZL5Dmdw CRC: 642658025 -->Ongoing Tasks<!-- END:presentationName,_0pJ_xslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0pJ_xslgEdmt3adZL5Dmdw CRC: 2000351389 -->Perform ongoing tasks that are not necessarily part of project schedule.<!-- END:briefDescription,_0pJ_xslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb-9PL5Edm6Nvont3uinw CRC: 3784853085 --><p>
+ This activity includes a single task, <a class="elementLink" href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request Change</a>. This task may occur anytime during the lifecycle in response to an observed defect, a desired
+ enhancement, or a change request. It is not planned, which means it does not appear as a scheduled activity
+ on the project plan, iteration plan or work items list. Nevertheless, it is a critical activity that must be performed
+ to ensure project success in an environment that is not static.
+</p>
+<p>
+ <a class="elementLink" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">Any Role</a> may perform this task, however the most common sources of <a class="elementLink" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> are <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s (enhancement requests and change requests) and <a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>s (defect reports).
+</p><!-- END:mainDescription,_mtb-9PL5Edm6Nvont3uinw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/ongoing_tasks/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/ongoing_tasks/model.html
new file mode 100644
index 0000000..0200b7f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/ongoing_tasks/model.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\ongoing_tasks\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4x060FY1EdqI9sTOt2pjHw CRC: 1617929191 -->Any Role<!-- END:presentationName,_4x060FY1EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_5M7icFY1EdqI9sTOt2pjHw CRC: 699774998 -->Work Items List<!-- END:presentationName,_5M7icFY1EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_5LsMUFY1EdqI9sTOt2pjHw CRC: 3689341175 -->Request Change<!-- END:presentationName,_5LsMUFY1EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0pJ_xclgEdmt3adZL5Dmdw CRC: 2928014604 -->ongoing_tasks<!-- END:name,_0pJ_xclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/test/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/test/content.html
new file mode 100644
index 0000000..defc2d1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/test/content.html
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\test\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0nz79clgEdmt3adZL5Dmdw CRC: 2018365746 -->Test<!-- END:presentationName,_0nz79clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0nz79clgEdmt3adZL5Dmdw CRC: 4102876272 -->Test and evaluate the requirements developed, from system perspective.<!-- END:briefDescription,_0nz79clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_mtb-6vL5Edm6Nvont3uinw CRC: 2584164379 --><p>
+
+</p><!-- END:keyConsiderations,_mtb-6vL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_mtb-6vL5Edm6Nvont3uinw CRC: 780419368 -->To create and run tests that validate that the system conforms to the intent.<!-- END:purpose,_mtb-6vL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: howtoStaff<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:howtoStaff,_mtb-6vL5Edm6Nvont3uinw CRC: 1421242642 --><p>
+ The staff performing this activity must be integrated into the team.
+</p><!-- END:howtoStaff,_mtb-6vL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageNotes<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageNotes,_mtb-6vL5Edm6Nvont3uinw CRC: 3806889568 --><p>
+ Testing must occur throughout the process and <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ throughout each iteration. It is not some final inspection to be done at the end. As requirements are de<span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ veloped and integrated into the build they should be tested as soon as possible.</span></span>
+</p><!-- END:usageNotes,_mtb-6vL5Edm6Nvont3uinw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/test/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/test/model.html
new file mode 100644
index 0000000..f27cb77
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/test/model.html
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\test\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_a6qBUFY2EdqI9sTOt2pjHw CRC: 4227617651 -->Tester<!-- END:presentationName,_a6qBUFY2EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_a_F1YFY2EdqI9sTOt2pjHw CRC: 273197623 -->Test Script<!-- END:presentationName,_a_F1YFY2EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_oSQYEL3SEdqfrv3k16plXw CRC: 69542014 -->Test Log<!-- END:presentationName,_oSQYEL3SEdqfrv3k16plXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_os33gL3SEdqfrv3k16plXw CRC: 699774998 -->Work Items List<!-- END:presentationName,_os33gL3SEdqfrv3k16plXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_a8fNUFY2EdqI9sTOt2pjHw CRC: 607185224 -->Test Case<!-- END:presentationName,_a8fNUFY2EdqI9sTOt2pjHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_nykLZL3SEdqfrv3k16plXw CRC: 467065627 -->Implement Tests<!-- END:presentationName,_nykLZL3SEdqfrv3k16plXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ny2fQL3SEdqfrv3k16plXw CRC: 2086788575 -->Build<!-- END:presentationName,_ny2fQL3SEdqfrv3k16plXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_oR39mb3SEdqfrv3k16plXw CRC: 2545677411 -->Run Tests<!-- END:presentationName,_oR39mb3SEdqfrv3k16plXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0nz79MlgEdmt3adZL5Dmdw CRC: 3632233996 -->test<!-- END:name,_0nz79MlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/transition_phase_iteration/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/transition_phase_iteration/content.html
new file mode 100644
index 0000000..3299d47
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/transition_phase_iteration/content.html
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\transition_phase_iteration\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0rQRgMlgEdmt3adZL5Dmdw CRC: 3311363436 -->Transition Phase Iteration<!-- END:presentationName,_0rQRgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0rQRgMlgEdmt3adZL5Dmdw CRC: 1589840480 -->This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Transition phase. Each activity and the related goals are described.<!-- END:briefDescription,_0rQRgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb-__L5Edm6Nvont3uinw CRC: 875220565 --><h3> Introduction </h3>
+<p> In the Transition phase,
+ most activities happen in parallel. The main objectives are to fine-tune functionality,
+ performance, and overall quality of the beta product from
+ the end of Construction phase. </p>
+<p> The activities performed in a typical iteration during
+ the Transition phase are described below. </p>
+<h4> Manage iteration </h4>
+<p> This activity is performed throughout the lifecycle. The goal of this activity
+ is to identify risks and issues early enough that they can be mitigated, to
+ establish the goals for the iteration, and to support the development team in
+ reaching these goals. </p>
+<p> Similar to other phases, this is an activity led by the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> (in collaboration with the team) to launch the iteration, to allocate
+ work, to track status, and to handle risks and issues. It’s unlikely that risks
+ of high impact will happen during the Transition, but it is recommended that
+ the project manager and team identify any potential issues while delivering
+ the product to the end users. </p>
+<p>If this is the last iteration of the project, the main goal is to achieve final
+ acceptance of the system. At the end of the iteration, results are assessed
+ against phase objectives<em>,</em> and <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders'</a>
+ concurrence on the project objectives is obtained. The team conducts a retrospective
+ review to capture lessons learned and make improvements to the process for subsequent
+ <strong> </strong>projects. The project is then closed.</p>
+<h4>Ongoing tasks </h4>
+<p> Submission of change requests during the Transition phase <strong></strong>works differently
+ than in other phases. New requirements will rarely be identified at late stages
+ of the software development lifecycle in a way they can be implemented in the
+ current release. If there are enhancement requests, though, they can be captured
+ in the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">work
+ items list</a> and allocated to a future release, when a new software development
+ lifecycle begins. In that case, requirements will be outlined and detailed accordingly.
+</p>
+<p> However, defects are typically dealt with during the Transition phase, thus
+ a stable release can be accepted by the user community. If there is general
+ agreement from stakeholders, correction of low-priority defects can be postponed
+ to subsequent evolutionary releases. </p>
+<h4> Develop solution for requirement within context</h4>
+<p> This activity is repeated multiple times, in parallel, for each development
+ task planned for that iteration. The main goal of this activity is an executable
+ system that provides the incremental quality and functionality for the specified
+ requirements within the specified context. </p>
+<p> During the Transition phase, most requirements will have been already implemented
+ and validated, which is the focus of the previous phase. Nevertheless, there
+ may be a few low-priority requirements that could be accommodated in the release
+ being developed. However, enhancement requests and defects found in previous
+ iterations may need to be allocated to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
+</p>
+<h4> Validate build </h4>
+<p> This activity is repeated throughout the lifecycle. The main goal of this
+ activity is to validate the current increment of the system against the requirements
+ allocated to it. </p>
+<p> This activity happens in parallel with development of the
+ solutions for enhancement requests and defects
+ (and possibly remaining requirements), to make sure that
+ a stable release can be presented to the user community. Users can be involved
+ in performing <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/test,_0nz79clgEdmt3adZL5Dmdw.html" guid="_0nz79clgEdmt3adZL5Dmdw">tests</a>
+ to accept the release. </p>
+<h4><!-- END:mainDescription,_mtb-__L5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0q33AclgEdmt3adZL5Dmdw CRC: 1824416172 -->Plan and Manage Iteration<!-- END:presentationName,_0q33AclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0qrpwslgEdmt3adZL5Dmdw CRC: 79270194 -->Validate Build<!-- END:presentationName,_0qrpwslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0qxwYclgEdmt3adZL5Dmdw CRC: 642658025 -->Ongoing Tasks<!-- END:presentationName,_0qxwYclgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/transition_phase_iteration/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/transition_phase_iteration/model.html
new file mode 100644
index 0000000..af20325
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/capabilitypatterns/transition_phase_iteration/model.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\capabilitypatterns\transition_phase_iteration\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0DMlYPinEdmugcVr9AdHjQ CRC: 2237470038 -->Develop Solution (for requirement) (within context)<!-- END:presentationName,_0DMlYPinEdmugcVr9AdHjQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0qrpwMlgEdmt3adZL5Dmdw CRC: 376464342 -->transition_phase_iteration<!-- END:name,_0qrpwMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/collab_commun_subprocess.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/collab_commun_subprocess.html
new file mode 100644
index 0000000..70578f6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/collab_commun_subprocess.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\collab_commun_subprocess.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: collab_commun_subprocess.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_r8cVIEmbEdu0xduwSKie-w CRC: 2338400230 -->Communication and Collaboration<!-- END:presentationName,_r8cVIEmbEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_r8cVIEmbEdu0xduwSKie-w CRC: 1379394758 -->This layer is the foundation for OpenUP, reflecting the collaborative nature of the process.<!-- END:briefDescription,_r8cVIEmbEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-NMF-a9hwKjzWNfHzzseDYQ CRC: 1432107891 --><p>
+ The communication and collaboration layer is the foundation for OpenUP, reflecting the collaborative nature of the
+ process. It contains all of the roles in OpenUP/Basic: Stakeholder, Analyst, Developer, Architect, Tester, Project
+ Manager, and Any Role. Team members taking on these roles need to collaborate to jointly capture and define the
+ intent of the stakeholders, to jointly develop the solution, and to jointly manage the project.
+</p>
+<p>
+ This foundational layer reflects and enables us to express the nature of self-organized teams, where team members must
+ broaden their perspectives of what their roles are and where their responsibilities end. As an example, the
+ Analyst cannot say “I documented the requirements, now it is up to the Developer to implement them.” The Analyst's job
+ is not primarily to document requirements; it is to communicate that the stakeholder intent is understood and reflected
+ in a validated build. Documenting requirements may help you achieve that objective, but it is only one of
+ many available tools. Other tools to use include working with developers on the design, working with testers on what
+ needs to be tested, and using the build to ensure that it does what the stakeholders need it to do.
+</p>
+<p>
+ To help the team to collaborate effectively, the foundational collaboration layer provides you with a set of <a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" guid="_HEu9QBOHEduCNqgZdt_OaA">practices</a> that have been shown to motivate effective collaboration. These practices
+ apply to work done in all sub-processes.<br />
+
+</p><!-- END:mainDescription,-NMF-a9hwKjzWNfHzzseDYQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/core_principles_category.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/core_principles_category.html
new file mode 100644
index 0000000..a19cfe9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/core_principles_category.html
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\core_principles_category.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: core_principles_category.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_UCOtoMXwEduywMSzPTUUwA CRC: 2827210875 -->Core Principles<!-- END:presentationName,_UCOtoMXwEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_UCOtoMXwEduywMSzPTUUwA CRC: 2278188338 -->Four core principles capture the general intentions behind this process and create the foundation for interpreting roles and work products and performing tasks.<!-- END:briefDescription,_UCOtoMXwEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-I2j8LuHkworb0Y3EIlWfDQ CRC: 1050575362 --><h3>
+ OpenUP Core Principles
+</h3>
+<p>
+ OpenUP is based on four mutually supporting core principles:
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Collaborate to align interests and share understanding
+</h4>
+<p>
+ Software is created by people with different interests and skills who must work together to create software
+ effectively.
+</p>
+<p>
+ Therefore, practices that foster a healthy team environment are key to success. A healthy team environment enables
+ effective collaboration that align the interests of project participants (development team, quality assurance, product
+ stakeholders, customers) and helps project participants develop a shared understanding of the project.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Balance competing priorities to maximize stakeholder value
+</h4>
+<p>
+ Systems need to be developed by balancing different, and sometimes competing, perspectives. For example, do you
+ want to minimize cost by reusing an existing capability, or by custom developing the capability to get it to do exactly
+ what you want?
+</p>
+<p>
+ Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes Stakeholder
+ benefits and is compliant with constraints placed on the project. Achieving balance is a dynamic process, because, as
+ both the stakeholders and project participants learn more about the system, their priorities and constraints change.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Focus on articulating the architecture
+</h4>
+<p>
+ Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
+ proves difficult to evolve, reuse, or integrate without substantial rework. It’s also difficult to organize the team or
+ communicate ideas without the common technical focus that the architecture provides.
+</p>
+<p>
+ Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
+ essential technical decisions through the growing architecture.<span style="mso-spacerun: yes"> </span>
+</p>
+<h4>
+ Evolve to continuously obtain feedback and improve
+</h4>
+<p>
+ It is usually not possible to know all stakeholders needs, be aware of all project risks, comprehend all project
+ technologies, or know how to effectively work with your colleagues. Even if it were possible to know all of this, some
+ of it is likely to change over the life of the project.
+</p>
+<p>
+ Therefore, divide the project into short, time-boxed iterations to demonstrate incremental value and to get early and
+ continuous feedback.<span style="mso-spacerun: yes"> </span>
+</p><!-- END:mainDescription,-I2j8LuHkworb0Y3EIlWfDQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/getting_started_with_openup.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/getting_started_with_openup.html
new file mode 100644
index 0000000..09bfac0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/getting_started_with_openup.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\getting_started_with_openup.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: getting_started_with_openup.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__cft0MXxEduywMSzPTUUwA CRC: 282220576 -->Getting Started<!-- END:presentationName,__cft0MXxEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__cft0MXxEduywMSzPTUUwA CRC: 3803324311 -->This area provides information useful for understanding how to deploy and adopt OpenUP/Basic.<!-- END:briefDescription,__cft0MXxEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-zy1Q3NXKXbiCP_zrjTxwaQ CRC: 3021782272 --><p>
+ OpenUP/Basic is a process for small, co-located teams. It can be used as-is, but if your team has significantly
+ different characteristics the process should be modified or extended to address those needs.
+</p><!-- END:keyConsiderations,-zy1Q3NXKXbiCP_zrjTxwaQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/intent_subprocess.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/intent_subprocess.html
new file mode 100644
index 0000000..892b4c0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/intent_subprocess.html
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\intent_subprocess.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: intent_subprocess.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_57_ZMEmbEdu0xduwSKie-w CRC: 3116432935 -->Intent<!-- END:presentationName,_57_ZMEmbEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_57_ZMEmbEdu0xduwSKie-w CRC: 835921488 -->The intent sub-process deals with how to channel the intent of stakeholders to the rest of the development team, to ensure that validated builds with incremental capabilities reflect stakeholder intents.<!-- END:briefDescription,_57_ZMEmbEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-QRnsN2e6IQlSMaRts-wFNw CRC: 3912114610 --><p>
+ The intent sub-process deals with how to channel the intent of stakeholders to the rest of the development team, to
+ ensure that validated builds with incremental capabilities reflect stakeholder intents. This is done by capturing and
+ communicating the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> to all team members, and by translating the vision into test cases and
+ requirements of different types to allow the team to understand what capabilities needs to be delivered to address
+ stakeholder intent.
+</p>
+<p>
+ You find the most tasks for the intent sub-process in the <strong>Requirements</strong> discipline, and the task Create
+ Test Cases in the <strong>Test</strong> discipline. The corresponding work products are found under
+ <strong>Requirements</strong> and <strong>Test</strong> domains.
+</p>
+<p>
+ The intent sub-process is built upon the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w"> </a>layer. That layer constitutes the backbone of OpenUP in order to reflect the
+ following:
+</p>
+<ul>
+ <li>
+ all roles in OpenUP are involved in intent development to ensure that as a minimum, all team members properly
+ understand stakeholders’ intent.
+ </li>
+ <li>
+ make sure that the best practices for collaborative development provided in the collaboration layer guides any work
+ related to intent.
+ </li>
+</ul>
+<p>
+ The intent sub-process is written in such a way that your organization can modify it to fit your style of development
+ and stakeholder collaboration, without necessarily impacting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">Management</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w"> </a>and <a class="elementLink" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">Solution</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w"> </a>development .
+</p><!-- END:mainDescription,-QRnsN2e6IQlSMaRts-wFNw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/introduction_to_openup_basic.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/introduction_to_openup_basic.html
new file mode 100644
index 0000000..32636a5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/introduction_to_openup_basic.html
@@ -0,0 +1,247 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\introduction_to_openup_basic.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: introduction_to_openup_basic.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BTJ_YMXwEduywMSzPTUUwA CRC: 2831147402 -->Introduction to OpenUP/Basic<!-- END:presentationName,_BTJ_YMXwEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-TfxeHO_AJxYCzXVva0kSzQ CRC: 2940019542 --><table width="589" align="center" border="0">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <a
+ href="./../../openup_basic/customcategories/getting_started_with_openup,__cft0MXxEduywMSzPTUUwA.html"
+ guid="__cft0MXxEduywMSzPTUUwA"><img height="48" alt="getting started" src="./resources/GetStarted_48.gif" width="48"
+ usemap="#Map" border="0" /></a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA"><img height="48" alt="core principles" src="./resources/CorePrinciples_48.gif"
+ width="48" usemap="#Map2" border="0" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a href="./../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg"><img height="48" alt="roles" src="./resources/Roles_48.gif" width="48"
+ usemap="#Map3" border="0" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg"><img height="48" alt="work products" src="./resources/WorkProducts_48.gif" width="48"
+ usemap="#Map4" border="0" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a
+ href="./../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ"><img height="48" alt="disciplines" src="./resources/Disciplines_48.gif" width="48"
+ usemap="#Map5" border="0" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw"><img height="48" alt="lifecycle" src="./resources/LifeCycle_48.gif" width="48"
+ usemap="#Map6" border="0" /></a>
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/customcategories/getting_started_with_openup,__cft0MXxEduywMSzPTUUwA.html"
+ guid="__cft0MXxEduywMSzPTUUwA">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA">Core Principles</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ">Disciplines</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">Lifecycle</a>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ <strong>What is OpenUP/Basic?</strong>
+</p>
+<p>
+ OpenUP/Basic is an open source software development process designed for small, co-located teams who want to take an <a
+ class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/guidelines/agile_and_unified,_qg1IAK__EduMeuOwJ2MpeQ.html"
+ guid="_qg1IAK__EduMeuOwJ2MpeQ">agile approach</a> to development. OpenUP/Basic is an iterative process that is <a
+ class="elementLink"
+ href="./../../openup_basic/guidances/guidelines/minimal_complete_extensible,_Nm5vUK__EduMeuOwJ2MpeQ.html"
+ guid="_Nm5vUK__EduMeuOwJ2MpeQ">Minimal, Complete, and Extensible</a>. It values collaboration and stakeholder
+ value over unnecessary deliverables and formality.
+</p>
+<p>
+ OpenUP/Basic is organized into four major areas of content: Communication and Collaboration, Intent, Solution, and
+ Management.
+</p>
+<p align="center">
+ <img height="350" alt="Four major areas upon which the OpenUP/Basic content is organized"
+ src="./resources/OpenUp1_350.jpg" width="350" usemap="#Map7" border="0" /> <map id="Map7" name="Map7">
+ <area shape="RECT" alt="Stakeholder" coords="144,5,207,62"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ" />
+ <area shape="POLY" alt="Tester" coords="336,242,310,287,254,256,278,209"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw" />
+ <area shape="RECT" alt="Developer" coords="148,282,201,347"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmd" />
+ <area shape="POLY" alt="Architect" coords="66,199,14,232,40,283,96,249"
+ href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Project Manager" coords="11,118,68,146,99,91,50,52"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Analyst" coords="258,99,312,66,338,114,284,145"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw" />
+ <area shape="CIRCLE" alt="Communication and Collaboration" coords="176,176,47"
+ href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Management" coords="85,219,70,163,115,89,169,72,169,117,124,144,120,197"
+ href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Intent" coords="181,116,223,143,229,196,264,219,283,160,245,94,181,70"
+ href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Solution" coords="129,211,176,235,221,210,257,231,214,271,133,272,94,232"
+ href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" />
+ </map><br />
+
+</p>
+<br />
+<br />
+<p>
+ OpenUP is characterized by four mutually supporting core principles:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA.html"
+ guid="_KkTIsMp7EdqC_NfSivunjA">Collaborate</a> to align interests and share understanding
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_balance,_ssG6MMvpEdqukPpotm3DYg.html"
+ guid="_ssG6MMvpEdqukPpotm3DYg">Balance</a> competing priorities (needs and technical costs) to maximize stakeholder
+ value
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_focus,_9gocwMvoEdqukPpotm3DYg.html"
+ guid="_9gocwMvoEdqukPpotm3DYg">Focus</a> on articulating the architecture to facilitate technical collaboration,
+ reduce risk, and minimize scrap and rework.
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_evolve,_GXiogMvoEdqukPpotm3DYg.html"
+ guid="_GXiogMvoEdqukPpotm3DYg">Evolve</a> continuously to reduce risk, demonstrate results, and gain feedback from
+ the customer<br />
+ </li>
+</ul>
+<p>
+ OpenUP/Basic is ready to use as-is; nothing needs to be added or removed. It can also be extended in large and small
+ ways to add new development content or customize the process for your specific environment.
+</p>
+<p>
+ <strong>Who should use OpenUP/Basic?</strong>
+</p>
+<p>
+ OpenUP/Basic is most useful for four primary groups of users:
+</p>
+<ul>
+ <li>
+ Software development practitioners (developers, project managers, analysts, and testers) working together as a
+ project team
+ </li>
+ <li>
+ Stakeholders
+ </li>
+ <li>
+ Software process engineers
+ </li>
+ <li>
+ Instructors
+ </li>
+</ul>
+<p>
+ Software development practitioners can find guidance on what is required of them in the roles defined by OpenUP/Basic.
+ Each role describes a set of activities and artifacts that the role is responsible for. Guidance is also given on how
+ those roles collaborate.
+</p>
+<p>
+ Stakeholders will find guidance on what they may expect from the software development team and how the software will be
+ created. OpenUP/Basic also describes the stakeholders' responsibilities and how they can best work with the development
+ team to obtain software that meets their needs.
+</p>
+<p>
+ Software process engineers can use EPF Composer to extend and modify OpenUP/Basic. Modification may be as simple as
+ altering templates for work products or as sophisticated as adding activities necessary for creating software in your
+ specific environment, such as audits for safety-critical systems. In addition to modifying method content, process
+ engineers can add, change, or remove process flows to add organization-specific capability patterns.
+</p>
+<p>
+ OpenUP/Basic is appropriate for academic organizations also. As an open source process, it can serve as the basis for
+ software engineering courses and, when combined with the EPF Composer, courses in software process engineering.<br />
+</p><!-- END:mainDescription,-TfxeHO_AJxYCzXVva0kSzQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-TfxeHO_AJxYCzXVva0kSzQ CRC: 1673081359 --><p>
+ Use OpenUP/Basic as-is when you have a small, co-located team.
+</p>
+<p>
+ Modify OpenUP/Basic for small teams with different circumstances, for instance a novel project or geographically
+ distributed team members.
+</p><!-- END:keyConsiderations,-TfxeHO_AJxYCzXVva0kSzQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/management_subprocess.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/management_subprocess.html
new file mode 100644
index 0000000..823ea38
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/management_subprocess.html
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\management_subprocess.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: management_subprocess.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Aoz2gEmcEdu0xduwSKie-w CRC: 1142134431 -->Management<!-- END:presentationName,_Aoz2gEmcEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Aoz2gEmcEdu0xduwSKie-w CRC: 1693980449 -->The Management sub-process deals with management of the project, including project planning, iteration planning, day-to-day management of the work within the iteration, and iteration assessments.<!-- END:briefDescription,_Aoz2gEmcEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-q8ubSlQ5miYcY1JXdj1fbQ CRC: 221266391 --><p>
+ It is important to note that the Management sub-process is built on the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a> layer to reflect the collaborative nature
+ of management of an OpenUP project. The manager should not plan an iteration in isolation, and then tell the team
+ members their assignments. Instead, the manager should be more of a coach, involving the entire team in the planning
+ process to ensure that:
+</p>
+<ul>
+ <li>
+ Everybody’s knowledge is reflected in the plan
+ </li>
+ <li>
+ All team members estimate their own work
+ </li>
+ <li>
+ Each team member signs up to take on a task, rather than being told exactly what to do.
+ </li>
+</ul>
+<p>
+ You will find the tasks for the Management sub-process in the <strong>Project Management</strong> discipline and the
+ corresponding work products under Project Management domain.
+</p>
+<p>
+ The Management sub-process is written in such a way that your organization can modify it to fit your style of
+ development, without necessarily affecting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">Solution</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w"> </a>and <a class="elementLink" href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" guid="_57_ZMEmbEdu0xduwSKie-w">Intent</a>.<br />
+</p><!-- END:mainDescription,-q8ubSlQ5miYcY1JXdj1fbQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/openup_basic_deprecated.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/openup_basic_deprecated.html
new file mode 100644
index 0000000..b5b37bb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/openup_basic_deprecated.html
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\openup_basic_deprecated.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_deprecated.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SEztkBOJEduCNqgZdt_OaA CRC: 1464045152 -->OpenUP/Basic - deprecated<!-- END:presentationName,_SEztkBOJEduCNqgZdt_OaA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/openup_basic_views.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/openup_basic_views.html
new file mode 100644
index 0000000..ceae834
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/openup_basic_views.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\openup_basic_views.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_views.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NIIYMBOJEduCNqgZdt_OaA CRC: 2128974345 -->OpenUP/Basic Views<!-- END:presentationName,_NIIYMBOJEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-8uqXjzIOnt6LVDae6Uv_0w CRC: 792484763 -->[to do]<!-- END:mainDescription,-8uqXjzIOnt6LVDae6Uv_0w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/CorePrinciples_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/CorePrinciples_48.gif
new file mode 100644
index 0000000..da5215c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/CorePrinciples_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/Disciplines_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/Disciplines_48.gif
new file mode 100644
index 0000000..36f36b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/Disciplines_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/GetStarted_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/GetStarted_48.gif
new file mode 100644
index 0000000..5839c94
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/GetStarted_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/LifeCycle_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/LifeCycle_48.gif
new file mode 100644
index 0000000..f7f4665
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/LifeCycle_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/OpenUp1_350.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/OpenUp1_350.jpg
new file mode 100644
index 0000000..0bb0b38
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/OpenUp1_350.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/Roles_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/Roles_48.gif
new file mode 100644
index 0000000..3fb662d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/Roles_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/WorkProducts_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/WorkProducts_48.gif
new file mode 100644
index 0000000..9554964
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/resources/WorkProducts_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/solution_subprocess.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/solution_subprocess.html
new file mode 100644
index 0000000..0d0cd73
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/solution_subprocess.html
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\solution_subprocess.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: solution_subprocess.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HEVvgEmcEdu0xduwSKie-w CRC: 1715817357 -->Solution<!-- END:presentationName,_HEVvgEmcEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_HEVvgEmcEdu0xduwSKie-w CRC: 3745716185 -->The Solution sub-process describes all aspects of creating the architecture, designing, implementing, and testing the application.<!-- END:briefDescription,_HEVvgEmcEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qwWeiX7WrSVHSluBe-J7yw CRC: 830074633 --><p>
+ The Solution sub-process, among others, guides how you perform the following actions:
+</p>
+<ul>
+ <li>
+ Determine architectural feasibility
+ </li>
+ <li>
+ Define architecture
+ </li>
+ <li>
+ Develop the architecture for, design, implement, and test a major change
+ </li>
+ <li>
+ Design, implement, and test a small change
+ </li>
+ <li>
+ Implement and test a trivial change
+ </li>
+ <li>
+ Test and validate builds of incrementally improved quality
+ </li>
+</ul>
+<p>
+ You find the tasks for this sub-process in the disciplines <strong>Analysis and Design,
+ Implementation,</strong> and <strong>Test</strong>, and the corresponding work products under the <strong>Architecture,
+ Development</strong>, and <strong>Test</strong> domains.
+</p>
+<p>
+ The Solution sub-process is built upon the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a> layer. This layer constitutes the backbone of
+ OpenUP to ensure that:
+</p>
+<ul>
+ <li>
+ All roles in OpenUP are involved in solution development
+ </li>
+ <li>
+ Validated builds are the responsibility of the entire team
+ </li>
+ <li>
+ Best practices for collaborative development guide development of the solution<strong>.</strong>
+ </li>
+</ul>
+<p>
+ The Solution sub-process is written in such a way that your organization can modify it to fit your style of
+ development, without necessarily affecting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">Management</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w"> </a>and <a class="elementLink" href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" guid="_57_ZMEmbEdu0xduwSKie-w">Intent</a>.<br />
+
+</p><!-- END:mainDescription,-qwWeiX7WrSVHSluBe-J7yw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/sub_processes.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/sub_processes.html
new file mode 100644
index 0000000..9267ddb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/customcategories/sub_processes.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\customcategories\sub_processes.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: sub_processes.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_V2BQkEmbEdu0xduwSKie-w CRC: 4159162018 -->Sub-processes<!-- END:presentationName,_V2BQkEmbEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_V2BQkEmbEdu0xduwSKie-w CRC: 850545916 -->OpenUP/Basic is organized into four major areas of content, also known as sub-processes.<!-- END:briefDescription,_V2BQkEmbEdu0xduwSKie-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-1ZoXO1IRfkXUKej4bNv8cw CRC: 530184183 --> <!-- END:mainDescription,-1ZoXO1IRfkXUKej4bNv8cw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/deliveryprocesses/openup_basic_process/content.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/deliveryprocesses/openup_basic_process/content.html
new file mode 100644
index 0000000..0defea5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/deliveryprocesses/openup_basic_process/content.html
@@ -0,0 +1,242 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\deliveryprocesses\openup_basic_process\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0uyGoMlgEdmt3adZL5Dmdw CRC: 3097586409 -->OpenUP/Basic Lifecycle<!-- END:presentationName,_0uyGoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0uyGoMlgEdmt3adZL5Dmdw CRC: 1791968630 -->This delivery process defines a software development process that supports the core principles of OpenUP. It is designed to support small co-located teams, consisting of 3 to 6 team members, working on a project that will last between 3 and 6 months.<!-- END:briefDescription,_0uyGoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_mtb-4PL5Edm6Nvont3uinw CRC: 1094704711 --><p> OpenUP/Basic is an iterative process with <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/concepts/core_principle_evolve,_GXiogMvoEdqukPpotm3DYg.html" guid="_GXiogMvoEdqukPpotm3DYg">iterations</a> distributed
+ throughout four <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html" guid="__7xOEC7aEdqHMdmRzC0-2g">phases</a>:
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html" guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>,
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html" guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>,
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html" guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>,
+ and <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html" guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>.
+</p>
+<p> Each phase may have as many iterations as needed, depending on degree of novelty
+ of the business domain, technology being used, architectural complexity, and
+ project size, to name a few factors. </p>
+<p> To offer a quick start for teams to plan their iterations, OpenUP/Basic
+ provides work breakdown structure (WBS) templates for each iteration and
+ a WBS template for an end-to-end process. </p>
+<p> Iterations may have variable lengths, depending on project characteristics.
+ One-month iterations are typically recommended, because
+ this timeframe provides: </p>
+<ul>
+ <li> A reasonable amount of time for projects to
+ deliver meaningful increments in functionality. </li>
+ <li> Early and frequent customer feedback. </li>
+ <li> Timely management of risks and issues during the course of the project.
+ </li>
+</ul>
+<p> OpenUP/Basic is intended<strong> </strong>to
+ offer process guidance to small projects: </p>
+<ul>
+ <li>
+
+ <div class="O" style="mso-margin-left-alt: 216; mso-char-wrap: 1; mso-kinsoku-overflow: 1" v:shape="_x0000_s1026">
+ 3 to 6 people on the team </div>
+ </li>
+ <li>
+
+ <div class="O" style="mso-margin-left-alt: 216; mso-char-wrap: 1; mso-kinsoku-overflow: 1" v:shape="_x0000_s1026">
+ 3 to 6 months of work</div>
+ </li>
+</ul><!-- END:mainDescription,_mtb-4PL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_mtb-4PL5Edm6Nvont3uinw CRC: 2916580415 --><p>
+ The purposes of this delivery process are to:
+</p>
+<ul>
+ <li>
+ Offer process guidance for small-scale projects
+ </li>
+ <li>
+ Allow project managers to create project plans based on the proposed work breakdown structures
+ </li>
+ <li>
+ Allow project managers to track status based on goals
+ </li>
+ <li>
+ Allow team members to understand how to perform their work to achieve project goals
+ </li>
+ <li>
+ Provide a complete, end-to-end delivery process that serves as an example for defining alternative delivery
+ processes
+ </li>
+</ul><!-- END:purpose,_mtb-4PL5Edm6Nvont3uinw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_y1uwgBOKEduCNqgZdt_OaA CRC: 3130156852 -->Lifecycle Objectives Milestone<!-- END:presentationName,_y1uwgBOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_y1uwgBOKEduCNqgZdt_OaA CRC: 3843206384 -->The end of the Inception phase is the first major project milestone, the Lifecycle Objectives Milestone.<!-- END:briefDescription,_y1uwgBOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qk_QXyoSxOb2C-boCISB5g CRC: 880742402 --><p> The Lifecycle Objectives Milestone is the first major project milestone. During
+ the iteration<a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw"> assessment</a>, the following evaluation criteria
+ should be met <a
+ class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>: </p>
+<ul>
+ <li>
+ Stakeholder concurrence on
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+
+ <li> scope definition</li>
+ <li> initial cost and schedule estimates</li>
+ <li>definitions and priorities for initial set of requirements</li>
+ <li>
+ risks identified and mitigation strategies proposed.
+ </li>
+ </ul>
+ </li>
+</ul>
+<p><br />
+ Note:<strong> </strong></p>
+<p>The project may be aborted or reconsidered if it fails to reach this milestone.<br /><!-- END:mainDescription,-qk_QXyoSxOb2C-boCISB5g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_16nd0BOKEduCNqgZdt_OaA CRC: 3153209871 -->Lifecycle Architecture Milestone<!-- END:presentationName,_16nd0BOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_16nd0BOKEduCNqgZdt_OaA CRC: 1540529658 -->At the end of the Elaboration phase is the second important project milestone, the Lifecycle Architecture Milestone.<!-- END:briefDescription,_16nd0BOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-3Ul1iAI1nkD0C5AsRtjHFA CRC: 3363265142 --><p>
+ The Lifecycle Architecture Milestone is the second major project milestone. During iteration <a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a> in Elaboration, you should keep these evaluation
+ criteria in mind <a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stability of Vision, requirements and Architecture.
+ </li>
+ <li>
+ Major risk elements addressed and resolved by testing and evaluating executable prototypes.
+ </li>
+ <li>
+ Construction iterations planned in sufficient detail and credibly estimated to allow the work to proceed.
+ </li>
+ <li>
+ Agreement of stakeholders that the current vision can be met if plans are executed to develop complete system on
+ top of current architecture.
+ </li>
+ <li>
+ Resourse expenditures versus planned expenditures are acceptable.<br />
+ </li>
+</ul><!-- END:mainDescription,-3Ul1iAI1nkD0C5AsRtjHFA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_31E_YBOKEduCNqgZdt_OaA CRC: 2247672028 -->Initial Operational Capability Milestone<!-- END:presentationName,_31E_YBOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_31E_YBOKEduCNqgZdt_OaA CRC: 2699459059 -->The end of Construction phase is the third important project milestone, the Initial Operational Capability Milestone.<!-- END:briefDescription,_31E_YBOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Q37Qy6ke_PQDK4jr1EIdcA CRC: 1696127777 --><p> The Initial Operational Capability Milestone is the third major
+ project milestone. During iteration <a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a> in Construction, keep
+ these evaluation criteria in mind <a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>: </p>
+<ul>
+
+ <li> Product release is stable and mature enough to be deployed in the user
+ community.</li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+
+ <li> The beta product is ready to be handed over to the users.</li>
+ <li> All functionality has been developed and all alpha testing (if any)
+ has been completed.</li>
+ <li> In addition to the software, a user manual has been developed, and
+ there is a description of the current release. </li>
+ </ul>
+ </li>
+ <li style="LIST-STYLE-TYPE: none"> </li>
+ <li> Actual resource expenditures compared to planned expenditures are acceptable.</li>
+</ul>
+<p> Note:<strong> </strong></p>
+<p>In case the project fails to reach this milestone, an iteration can be added
+ to Construction, thus postponing Transition. </p><!-- END:mainDescription,-Q37Qy6ke_PQDK4jr1EIdcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_5v0NwBOKEduCNqgZdt_OaA CRC: 3857641588 -->Product Release Milestone<!-- END:presentationName,_5v0NwBOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_5v0NwBOKEduCNqgZdt_OaA CRC: 1178259642 -->The end of the Transition phase is the fourth important project milestone, the Product Release Milestone, which is the result of the customer reviewing and accepting the project deliverables.<!-- END:briefDescription,_5v0NwBOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Gt2aCyZVy4q1BvcJRM2E-A CRC: 2531456715 --><p> The Product Release Milestone is the last major project milestone. During
+ iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>,
+ you decide if the objectives were met, and then close the project. These
+ are the evaluation criteria to keep in mind <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+
+ <li> Users satisfaction and product acceptance</li>
+
+ <li> Stakeholder concurrence on acceptable resource expenditures compared to
+ planned expenditures</li>
+
+ <li> Product is in production; therefore, a new development cycle for enhancements
+ or maintenance may start</li>
+</ul><!-- END:mainDescription,-Gt2aCyZVy4q1BvcJRM2E-A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/deliveryprocesses/openup_basic_process/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/deliveryprocesses/openup_basic_process/model.html
new file mode 100644
index 0000000..a63f4e4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/deliveryprocesses/openup_basic_process/model.html
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\deliveryprocesses\openup_basic_process\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_xupMvxOKEduCNqgZdt_OaA CRC: 3852517932 -->Inception Iteration [1..n]<!-- END:presentationName,_xupMvxOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0Spa4BOKEduCNqgZdt_OaA CRC: 1660801901 -->Elaboration Iteration [1..n]<!-- END:presentationName,_0Spa4BOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3CqrAROKEduCNqgZdt_OaA CRC: 1316684259 -->Construction Iteration [1..n]<!-- END:presentationName,_3CqrAROKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_467NIhOKEduCNqgZdt_OaA CRC: 2080913995 -->Transition Iteration [1..n]<!-- END:presentationName,_467NIhOKEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0uHYQclgEdmt3adZL5Dmdw CRC: 2726279353 -->openup_basic_process<!-- END:name,_0uHYQclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_eqypIRjYEduxUfEVCtmW4Q CRC: 3219518662 -->[last iteration in Inception]<!-- END:value,_eqypIRjYEduxUfEVCtmW4Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_EXh7QRjZEduxUfEVCtmW4Q CRC: 854585863 -->[last iteration in Elaboration]<!-- END:value,_EXh7QRjZEduxUfEVCtmW4Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_d66ZcRjaEduxUfEVCtmW4Q CRC: 1040514578 -->[last iteration in Construction]<!-- END:value,_d66ZcRjaEduxUfEVCtmW4Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_5bCFkRjlEduxUfEVCtmW4Q CRC: 1478399231 -->[last iteration in Transition]<!-- END:value,_5bCFkRjlEduxUfEVCtmW4Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplinegroupings/openup_basic_disciplines.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplinegroupings/openup_basic_disciplines.html
new file mode 100644
index 0000000..5ee9110
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplinegroupings/openup_basic_disciplines.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplinegroupings\openup_basic_disciplines.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_disciplines.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__BZycP1UEdmek8CQTQgrOQ CRC: 316390561 -->OpenUP/Basic Disciplines<!-- END:presentationName,__BZycP1UEdmek8CQTQgrOQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__BZycP1UEdmek8CQTQgrOQ CRC: 4010925637 -->This is the list of disciplines in OpenUP/Basic providing organization of tasks.<!-- END:briefDescription,__BZycP1UEdmek8CQTQgrOQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_AYGfoP1VEdmek8CQTQgrOQ CRC: 834486487 --><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>, organized by <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/discipline,_yGUuidnmEdmO6L4XMImrsA.html" guid="_yGUuidnmEdmO6L4XMImrsA">disciplines</a>. You can see the tasks that have been included, and visit
+ each task page to see its definition and relationships to other elements.
+</p><!-- END:mainDescription,_AYGfoP1VEdmek8CQTQgrOQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/analysis_and_design.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/analysis_and_design.html
new file mode 100644
index 0000000..5cd08ff
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/analysis_and_design.html
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplines\analysis_and_design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analysis_and_design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0TX9AMlgEdmt3adZL5Dmdw CRC: 1742220005 -->Analysis &amp; Design<!-- END:presentationName,_0TX9AMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0TX9AMlgEdmt3adZL5Dmdw CRC: 1313198828 -->This discipline explains how to create a design from requirements that can be implemented by developers.<!-- END:briefDescription,_0TX9AMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Bbq2MLv-EdmmUvZAZjqE3g CRC: 196856775 --><p>
+ The purposes of Analysis & Design are:
+</p>
+<ul>
+ <li>
+ To transform the requirements into a design of the system-to-be.
+ </li>
+ <li>
+ To evolve a robust architecture for the system.
+ </li>
+ <li>
+ To adapt the design to match the implementation environment.
+ </li>
+</ul>
+<p>
+ The Analysis & Design discipline is related to other disciplines, as follows:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline provides the primary input for Analysis and Design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/implementation,_0TeDoMlgEdmt3adZL5Dmdw.html" guid="_0TeDoMlgEdmt3adZL5Dmdw">Implementation</a> discipline implements the design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a> discipline tests system designed during Analysis and Design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project, and each iteration.
+ </li>
+</ul><!-- END:mainDescription,_Bbq2MLv-EdmmUvZAZjqE3g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_Bbq2MLv-EdmmUvZAZjqE3g CRC: 3984688378 --><p>
+ Creating and applying architectural mechanisms is essential for creating a robust architecture. See more on
+ architectural mechanisms at <a class="elementLink"
+ href="./../../openup_basic/customcategories/architectural_mechanisms,_2l8U4K4sEdudp4CB-AFxtw.html"
+ guid="_2l8U4K4sEdudp4CB-AFxtw">Architectural Mechanisms</a>.
+</p><!-- END:keyConsiderations,_Bbq2MLv-EdmmUvZAZjqE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/config_and_change_management.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/config_and_change_management.html
new file mode 100644
index 0000000..5d3c7b8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/config_and_change_management.html
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplines\config_and_change_management.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: config_and_change_management.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0TwXgMlgEdmt3adZL5Dmdw CRC: 1201765651 -->Configuration &amp;amp; Change Management<!-- END:presentationName,_0TwXgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0TwXgMlgEdmt3adZL5Dmdw CRC: 4011575760 -->This discipline explains how to control changes to artifacts, ensuring a synchronized evolution of the set of Work Products composing a software system.<!-- END:briefDescription,_0TwXgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_H9TXMLv-EdmmUvZAZjqE3g CRC: 960246975 --><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Maintain a consistent set of work products as they evolve.
+ </li>
+ <li>
+ Maintain consistent builds of the software.
+ </li>
+ <li>
+ Provide an efficient means to adapt to changes and issues and re-plan work accordingly.
+ </li>
+ <li>
+ Provide data for measuring progress.
+ </li>
+</ul>
+<p>
+ In many organizations, the term "configuration management" implies all of these things.
+</p>
+<p>
+ Within the context of this process, configuration management refers to the ability to maintain <a class="elementLink" href="./../../openup_basic/guidances/termdefinitions/version,_eX8K8ElyEducWJcS4yanqg.html" guid="_eX8K8ElyEducWJcS4yanqg">version</a>s of artifacts and consistent <a class="elementLink" href="./../../openup_basic/guidances/termdefinitions/configuration,__Cw30ElxEducWJcS4yanqg.html" guid="__Cw30ElxEducWJcS4yanqg">configuration</a>s of artifacts, addressing the first two objectives listed above.
+ Change Management refers to the process of managing changes to configuration controlled artifacts, addressing the
+ latter two objectives listed above.
+</p>
+<p>
+ Although it is important to keep up to date versions and configurations of all work product, the primary work products
+ of concern are the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Artifact: Implementation</a> and the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Artifact: Build</a>.
+</p>
+<p>
+ Changes are managed via the <a class="elementLinkWithType" href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a> and subsequent prioritization and disposition of change requests via the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.
+</p>
+<p>
+ This discipline spans the entire lifecycle. Every other discipline relies upon the configuration and change management
+ discipline to maintain a consistent, up to date, set of work products and to prioritize and track changes to those work
+ products throughout the lifecycle.
+</p>
+<p>
+ Configuration and change management is done by everyone on the development team. Because of the importance and
+ pervasiveness of this discipline, configuration and change management guidance is associated with tasks and work
+ products in all other disciplines.
+</p><!-- END:mainDescription,_H9TXMLv-EdmmUvZAZjqE3g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_H9TXMLv-EdmmUvZAZjqE3g CRC: 2542153989 --><p>
+ It is assumed that the project has some form of configuration management system, such as CVS, to maintain version and
+ configuration information and enable collaborative development of the system. Without this, all but the most trivial of
+ development will be virtually impossible.
+</p><!-- END:keyConsiderations,_H9TXMLv-EdmmUvZAZjqE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/implementation.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/implementation.html
new file mode 100644
index 0000000..79b44ce
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/implementation.html
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplines\implementation.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implementation.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0TeDoMlgEdmt3adZL5Dmdw CRC: 263885700 -->Implementation<!-- END:presentationName,_0TeDoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0TeDoMlgEdmt3adZL5Dmdw CRC: 756664860 -->This discipline explains how to implement a technical solution that conforms to the design, works within the architecture and supports the requirements.<!-- END:briefDescription,_0TeDoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_D5dHQLv-EdmmUvZAZjqE3g CRC: 794660339 --><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Incrementally build the system.
+ </li>
+ <li>
+ Verify that the technical units used to build the system work as specified.
+ </li>
+</ul>
+<p>
+ With each iteration, the tasks in this discipline will evolve an ever more capable and ever more stable <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>.
+</p>
+<p>
+ When working on the system, the <a class="elementLink" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a> will use the architecture and also be constrained by the
+ architecture.
+</p>
+<p>
+ This discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline defines what will be implemented.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis & Design</a> discipline organizes and constrains the
+ implementation.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a> discipline validates that system built meets
+ the requirements.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration & Change Management</a> discipline provides the mechanisms to
+ manage changes to the system built.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans what functionality will be implemented
+ in each iteration.
+ </li>
+</ul><!-- END:mainDescription,_D5dHQLv-EdmmUvZAZjqE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/project_management.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/project_management.html
new file mode 100644
index 0000000..0e8c242
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/project_management.html
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplines\project_management.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_management.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0TqQ4MlgEdmt3adZL5Dmdw CRC: 1814688680 -->Project Management<!-- END:presentationName,_0TqQ4MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_GybfgLv-EdmmUvZAZjqE3g CRC: 1025322275 --><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Keep the team focused on continually delivering tested software product for stakeholder evaluation
+ </li>
+ <li>
+ Help prioritize the sequence of work
+ </li>
+ <li>
+ Help create an effective working environment to maximize team productivity
+ </li>
+ <li>
+ Keep stakeholders and the team informed on project progress
+ </li>
+ <li>
+ Provide a framework to manage project risk and continually adapt to change
+ </li>
+</ul>
+<p>
+ Project management acts as a bridge between the stakeholders and the development team. It is important that project
+ management activities add value to creating a high performance work environment where
+</p>
+<ul>
+ <li>
+ Stakeholders have confidence in the team’s ability to successfully deliver value and understand the capabilities
+ and tradeoffs of the technical platform
+ </li>
+ <li>
+ Project team members understand stakeholder intentions and confirm that understanding by continually producing a
+ working software product for evaluation
+ </li>
+</ul>
+<p>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> works with <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> to create a coarse-grained <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Project Plan</a> based on the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>
+ for the project. This project plan describes the lengths and objectives of the four <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html" guid="__7xOEC7aEdqHMdmRzC0-2g">Phases</a> and the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Iterations</a> within each phase.
+</p>
+<p>
+ At the beginning of each iteration, the project manager works with stakeholders and the development team to prioritize
+ requirements, change requests, and defects in the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Item List</a> and allocate them to the upcoming iteration.
+</p>
+<p>
+ The project manager then works with the development team to create a fine-grained <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> based on the objectives in the project plan and the work items
+ assigned to the iteration. Team members volunteer to collaborate on allocated work items and provide the project
+ manager with tasks and time estimates to deliver those work items.
+</p>
+<p>
+ The team demonstrates they understand stakeholder intentions throughout each iteration by building a working software
+ product that is demonstrated to stakeholders to affirm understanding and elicit feedback. At the end of each iteration,
+ the evaluation of the final <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>
+ must include test results and should be captured in a <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a> and communicated to all stakeholders and team members.
+</p>
+<p>
+ The development team demonstrates continual progress to stakeholders by reporting closed-out work items in each
+ iteration through the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/reports/project_burndown,_ePrt8Dj3EduxovfWMDsntw.html" guid="_ePrt8Dj3EduxovfWMDsntw">Project Burndown</a>. The team can use <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Iteration Burndown</a> to demonstrate progress during an iteration.
+</p>
+<p>
+ Project management needs to consider the uncertainties facing the project (i.e. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Risks</a>) and pro-actively work with stakeholders and the team to continually adapt to
+ changes in business needs, system requirements, and technical capabilities.
+</p>
+<p>
+ Project Management is an umbrella discipline which has impact and is impacted by all other disciplines.
+</p><!-- END:mainDescription,_GybfgLv-EdmmUvZAZjqE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/requirements.html
new file mode 100644
index 0000000..9876d2d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/requirements.html
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplines\requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0TR2ZMlgEdmt3adZL5Dmdw CRC: 1754233426 -->Requirements<!-- END:presentationName,_0TR2ZMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0TR2ZMlgEdmt3adZL5Dmdw CRC: 4273847759 -->This discipline defines the minimal tasks required to elicit, analyze, specify, validate and manage the requirements for the system to be developed.<!-- END:briefDescription,_0TR2ZMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,__rFCULv9EdmmUvZAZjqE3g CRC: 2365414637 --><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Understand the problem to be solved
+ </li>
+ <li>
+ Understand stakeholder needs (what users want)
+ </li>
+ <li>
+ Define the requirements for the solution (what the system must do)
+ </li>
+ <li>
+ Define the boundaries (scope) of the system
+ </li>
+ <li>
+ Identify external interfaces for the system
+ </li>
+ <li>
+ Identify technical constraints on the solution
+ </li>
+ <li>
+ Provide the basis for planning iterations
+ </li>
+ <li>
+ Provide the initial basis for estimating cost and schedule
+ </li>
+</ul>
+<p>
+ To achieve these goals, it is important to understand the definition and scope of the problem that we are trying
+ to solve. <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> are identified and the problem to be solved is defined.
+</p>
+<p>
+ Having agreed on the problem to be solved, the <a class="elementLink" href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a> for the system are elicited, organized, analyzed, validated and
+ specified.
+</p>
+<p>
+ Throughout the lifecycle, changes to the requirements are managed.
+</p>
+<p>
+ The Requirements discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis & Design</a> discipline gets its primary input from the
+ Requirements discipline
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a> discipline validates the system against the requirements
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration & Change Management</a> discipline provides the mechanisms to
+ manage changes to the requirements
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project and assigns
+ requirements to each iteration by analyzing the prioritized requirements and assigning work.
+ </li>
+</ul><!-- END:mainDescription,__rFCULv9EdmmUvZAZjqE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/test.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/test.html
new file mode 100644
index 0000000..ee8f076
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/disciplines/test.html
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\disciplines\test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0TkKQMlgEdmt3adZL5Dmdw CRC: 2018365746 -->Test<!-- END:presentationName,_0TkKQMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0TkKQMlgEdmt3adZL5Dmdw CRC: 2572793515 -->This discipline defines the minimal set of tasks required to plan, implement, run and evaluate the testing of a system.<!-- END:briefDescription,_0TkKQMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_FuQswLv-EdmmUvZAZjqE3g CRC: 1829718713 --><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Find and document defects.
+ </li>
+ <li>
+ Validate and prove the assumptions made in design and requirement specifications through concrete demonstration.
+ </li>
+ <li>
+ Validate that the software product works as designed.
+ </li>
+ <li>
+ Validate that the requirements are implemented appropriately.
+ </li>
+</ul>
+<p>
+ A good test effort is based on the philosophy of test early and test often. In addition, it is driven by questions such
+ as:
+</p>
+<ul>
+ <li>
+ How could this software break?
+ </li>
+ <li>
+ In what possible situations could this software fail to work predictably?
+ </li>
+</ul>
+<p>
+ Testing challenges the assumptions, risks, and uncertainty inherent in the work of other disciplines, and addresses
+ those concerns using concrete demonstration and impartial evaluation.
+</p>
+<p>
+ The Test discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline captures requirements for the software product, which is
+ one of the primary inputs for identifying what tests to perform.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis and Design</a> discipline determines the appropriate design for the
+ software product, which is another important input for identifying what tests to perform.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/implementation,_0TeDoMlgEdmt3adZL5Dmdw.html" guid="_0TeDoMlgEdmt3adZL5Dmdw">Implementation</a> discipline produces builds of the software product that are
+ validated by the Test discipline. Within an iteration, multiple builds will be tested - typically one per test
+ cycle.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project and the necessary work in each
+ iteration. Described in an Iteration Plan, this artifact is an important input used when you define the correct
+ evaluation mission for the test effort.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration and Change Management</a> discipline controls changes within the
+ project. The test effort verifies that each change has been completed appropriately. Test assets are kept
+ under configuration management.<br />
+ </li>
+</ul><!-- END:mainDescription,_FuQswLv-EdmmUvZAZjqE3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/architecture.html
new file mode 100644
index 0000000..b8790f0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/architecture.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_xITr8MWXEdqWePvIjHInwg CRC: 1822983426 -->Architecture<!-- END:presentationName,_xITr8MWXEdqWePvIjHInwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_xITr8MWXEdqWePvIjHInwg CRC: 1719287587 -->This is the list of work products related to architecture domain.<!-- END:briefDescription,_xITr8MWXEdqWePvIjHInwg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/change_management.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/change_management.html
new file mode 100644
index 0000000..eb18515
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/change_management.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\change_management.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: change_management.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_vUzp0MWeEdqiT9CqkRksWQ CRC: 3549835143 -->Change Management<!-- END:presentationName,_vUzp0MWeEdqiT9CqkRksWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_vUzp0MWeEdqiT9CqkRksWQ CRC: 684838562 -->This is the list of work products related to change management domain.<!-- END:briefDescription,_vUzp0MWeEdqiT9CqkRksWQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/development.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/development.html
new file mode 100644
index 0000000..073de3f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/development.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\development.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: development.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_A9k3UMWfEdqiT9CqkRksWQ CRC: 1179299581 -->Development<!-- END:presentationName,_A9k3UMWfEdqiT9CqkRksWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_A9k3UMWfEdqiT9CqkRksWQ CRC: 1300370920 -->This is the list of work products related to development domain.<!-- END:briefDescription,_A9k3UMWfEdqiT9CqkRksWQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/openup_basic_wp.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/openup_basic_wp.html
new file mode 100644
index 0000000..8144e03
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/openup_basic_wp.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\openup_basic_wp.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_wp.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_s4Z9AMWXEdqWePvIjHInwg CRC: 4002685269 -->OpenUP/Basic Work Products<!-- END:presentationName,_s4Z9AMWXEdqWePvIjHInwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_s4Z9AMWXEdqWePvIjHInwg CRC: 71075565 -->This is the list of domains in OpenUp/Basic providing organization of work products.<!-- END:briefDescription,_s4Z9AMWXEdqWePvIjHInwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-15BvSftWbF7VdZ_W8YycBQ CRC: 1221906021 --><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>, organized by <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/domain,_yHEVYdnmEdmO6L4XMImrsA.html" guid="_yHEVYdnmEdmO6L4XMImrsA">domains</a>. You can see the work products that have been included, and visit each work
+ product page to see its definition and relationships to other elements.
+</p><!-- END:mainDescription,-15BvSftWbF7VdZ_W8YycBQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/project_management.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/project_management.html
new file mode 100644
index 0000000..ab3eda9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/project_management.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\project_management.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_management.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_QxjGYMWfEdqiT9CqkRksWQ CRC: 1814688680 -->Project Management<!-- END:presentationName,_QxjGYMWfEdqiT9CqkRksWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_QxjGYMWfEdqiT9CqkRksWQ CRC: 836366772 -->This is the list of work products related to project management domain.<!-- END:briefDescription,_QxjGYMWfEdqiT9CqkRksWQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/requirements.html
new file mode 100644
index 0000000..e1e582f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/requirements.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_allMQMWfEdqiT9CqkRksWQ CRC: 1754233426 -->Requirements<!-- END:presentationName,_allMQMWfEdqiT9CqkRksWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_allMQMWfEdqiT9CqkRksWQ CRC: 1313019291 -->This is the list of work products related to requirements domain.<!-- END:briefDescription,_allMQMWfEdqiT9CqkRksWQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/test.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/test.html
new file mode 100644
index 0000000..08d0af8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/domains/test.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\domains\test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ou4CMMWfEdqiT9CqkRksWQ CRC: 2018365746 -->Test<!-- END:presentationName,_ou4CMMWfEdqiT9CqkRksWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ou4CMMWfEdqiT9CqkRksWQ CRC: 2781512622 -->This is the list of work products related to test domain.<!-- END:briefDescription,_ou4CMMWfEdqiT9CqkRksWQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/actor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/actor.html
new file mode 100644
index 0000000..ef41ecc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/actor.html
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\actor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: actor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0VrDEMlgEdmt3adZL5Dmdw CRC: 2243197437 -->Actor<!-- END:presentationName,_0VrDEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0VrDEMlgEdmt3adZL5Dmdw CRC: 4038091662 -->This check list provides questions to help ensure that all actors, and only valid actors, have been identified and described correctly.<!-- END:briefDescription,_0VrDEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ytiigAYQEdubLa3RRn5f4A CRC: 122284030 -->Have you found all the actors<!-- END:name,_ytiigAYQEdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ytiigAYQEdubLa3RRn5f4A CRC: 2792116361 -->Have you accounted for all roles in the systems environment? See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a> for some questions that may help
+identify actors.<!-- END:sectionDescription,_ytiigAYQEdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_AcjQMAYREdubLa3RRn5f4A CRC: 2461586269 -->Is each actor involved with at least one use case<!-- END:name,_AcjQMAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_AcjQMAYREdubLa3RRn5f4A CRC: 1798952258 -->If you cannot identify a use case associated with a given actor perhaps the actor should be removed, or perhaps you are
+missing a use case.<!-- END:sectionDescription,_AcjQMAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_P3mo8AYREdubLa3RRn5f4A CRC: 2295789137 -->Can you identify at least two people, or external systems, that would play the role of a particular actor<!-- END:name,_P3mo8AYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_P3mo8AYREdubLa3RRn5f4A CRC: 719895993 -->If you cannot, check if the role that the actor represents is part of another actor. If that is the case, you should
+merge the actors.<!-- END:sectionDescription,_P3mo8AYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_b640oAYREdubLa3RRn5f4A CRC: 3960615647 -->Will a particular actor use the system in several completely different ways<!-- END:name,_b640oAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_b640oAYREdubLa3RRn5f4A CRC: 400156660 --><p>
+ If true, you should probably have more than one actor.
+</p><!-- END:sectionDescription,_b640oAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_iOHtQAYREdubLa3RRn5f4A CRC: 3397753268 -->Does the actor have several completely different purposes for using the system<!-- END:name,_iOHtQAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_iOHtQAYREdubLa3RRn5f4A CRC: 2708495317 -->If true, there may be more than one actor.<!-- END:sectionDescription,_iOHtQAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ptfB0AYREdubLa3RRn5f4A CRC: 342423156 -->Have you considered maintenance and administrative roles<!-- END:name,_ptfB0AYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ptfB0AYREdubLa3RRn5f4A CRC: 3432317479 -->It is common to focus on the daily users of the system, and forget about administrative and maintenance roles such as
+setting up user accounts, managing access rights, performing backups, etc. Ensure you have captured these actors.<!-- END:sectionDescription,_ptfB0AYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_2i_UoAYREdubLa3RRn5f4A CRC: 1391396564 -->Does each actor have a clear description of its role<!-- END:name,_2i_UoAYREdubLa3RRn5f4A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_2i_UoAYREdubLa3RRn5f4A CRC: 175831465 -->Each actor should have a short description of the role and the main goal the actor has in using the system.<!-- END:sectionDescription,_2i_UoAYREdubLa3RRn5f4A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/architecture.html
new file mode 100644
index 0000000..94e4063
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/architecture.html
@@ -0,0 +1,202 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_17PYUNd6EdmIm-bsRSNCgw CRC: 1822983426 -->Architecture<!-- END:presentationName,_17PYUNd6EdmIm-bsRSNCgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_17PYUNd6EdmIm-bsRSNCgw CRC: 2374822490 -->This checklist provides questions to help in evaluating whether architectural decisions have been captured appropriately.<!-- END:briefDescription,_17PYUNd6EdmIm-bsRSNCgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_17Ve8Nd6EdmIm-bsRSNCgw CRC: 3983648830 --><p>
+ The items in this checklist represent good practices for creating and communicating a robust architecture. It may not
+ be possible to address every item, and some items may only be able to be addressed to a limited extent. In these cases,
+ be sure that there are good reasons for only partially addressing an item, or not addressing an item at all.
+</p>
+<p>
+ Architecture can be performed every day. Use this checklist regularly to ensure the results are robust, consistent, and
+ understandable. Make the architecture good enough for the specific goals being addressed by using this checklist to
+ identify areas that have been skipped, ignored, or not sufficiently addressed.
+</p><!-- END:mainDescription,_17Ve8Nd6EdmIm-bsRSNCgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_LqpmkCALEduY2JH31Kkn-A CRC: 379218764 -->Is the overall structure of the architecture clear?<!-- END:name,_LqpmkCALEduY2JH31Kkn-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_LqpmkCALEduY2JH31Kkn-A CRC: 2763889583 --><ul>
+ <li>
+ Are the key abstractions adequately defined?
+ </li>
+ <li>
+ Have necessary <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s been identified and described?
+ </li>
+ <li>
+ Does the architecture divide the system’s responsibilities into well-defined subsystems with well-defined
+ interfaces?
+ </li>
+ <li>
+ Does the packaging approach reduce complexity and improve understanding?
+ </li>
+ <li>
+ Is subsystem and package partitioning and layering logically consistent?
+ </li>
+ <li>
+ Are packages defined to be highly cohesive within the package, while the packages themselves are loosely coupled?
+ </li>
+ <li>
+ Are all of the subsystem components for the iteration identified?
+ </li>
+ <li>
+ Do the dependencies between subsystems and packages correspond to dependency relationships between the contained
+ classes?
+ </li>
+ <li>
+ Do the classes in a subsystem support the services identified for the subsystem?
+ </li>
+ <li>
+ Are the number and types of components reasonable?
+ </li>
+</ul><!-- END:sectionDescription,_LqpmkCALEduY2JH31Kkn-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_pWBfQMm9EduiAPR4gd-qxA CRC: 3881500668 -->Have the supporting requirements been adequately addressed?<!-- END:name,_pWBfQMm9EduiAPR4gd-qxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_pWBfQMm9EduiAPR4gd-qxA CRC: 2442330806 --><ul>
+ <li>
+ Does the architecture adequately address the global Functional requirements?
+ </li>
+ <li>
+ Does the architecture adequately address the Usability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address the Reliability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address the Performance requirements?
+ </li>
+ <li>
+ Does the architecture adequately address the Supportability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address the other needs identified in the <a class="elementLink"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>?
+ </li>
+</ul><!-- END:sectionDescription,_pWBfQMm9EduiAPR4gd-qxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_PHv_kCALEduY2JH31Kkn-A CRC: 3685181068 -->Can the architecture be delivered by the team?<!-- END:name,_PHv_kCALEduY2JH31Kkn-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_PHv_kCALEduY2JH31Kkn-A CRC: 3801174670 --><ul>
+ <li>
+ Does the component architecture provide a suitable basis for organizing the development teams?
+ </li>
+ <li>
+ Does each team have the skills required to implement their allocated components?
+ </li>
+ <li>
+ Are responsibilities divided well between teams?
+ </li>
+ <li>
+ Do all team members share the same understanding of the architecture as the one presented by the architect?
+ </li>
+ <li>
+ Can team members understand enough from the architecture to successfully design and code their allocated
+ components?
+ </li>
+</ul><!-- END:sectionDescription,_PHv_kCALEduY2JH31Kkn-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_A8m2YMm7EduiAPR4gd-qxA CRC: 3482659495 -->Is architecture showing appropriate stability?<!-- END:name,_A8m2YMm7EduiAPR4gd-qxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_A8m2YMm7EduiAPR4gd-qxA CRC: 632910194 --><ul>
+ <li>
+ If in Inception, is a candidate architecture emerging?
+ </li>
+ <li>
+ If in Elaboration, is the architecture beginning to stabilize?
+ </li>
+ <li>
+ If in Construction, is the architecture generally stable?
+ </li>
+ <li>
+ If in Transition, is the architecture very stable?
+ </li>
+</ul><!-- END:sectionDescription,_A8m2YMm7EduiAPR4gd-qxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_aOKkwMm8EduiAPR4gd-qxA CRC: 2772006455 -->In general, does the architecture seem sensible?<!-- END:name,_aOKkwMm8EduiAPR4gd-qxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_aOKkwMm8EduiAPR4gd-qxA CRC: 3404567218 --><ul class="noindent">
+ <li>
+ Is the architecture at an appropriate level of detail, given the objectives?
+ </li>
+ <li>
+ Are concepts handled in the simplest way possible?
+ </li>
+ <li>
+ Can the architecture easily evolve, so that expected changes can be easily accommodated?
+ </li>
+ <li>
+ At the same time, has the architecture been overly structured to handle unlikely change at the expense of
+ simplicity and comprehensibility? (Hint: "Yes" to this question is not good).
+ </li>
+ <li>
+ Are the key assumptions and decisions that the architecture is based on documented and visible to reviewers
+ and consumers of the architecture?
+ </li>
+ <li>
+ Is the architecture description current?
+ </li>
+ <li>
+ Have the design guidelines been followed?
+ </li>
+ <li>
+ Are all technical risks either mitigated or addressed in a contingency plan?
+ </li>
+</ul><!-- END:sectionDescription,_aOKkwMm8EduiAPR4gd-qxA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/design.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/design.html
new file mode 100644
index 0000000..ef57324
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/design.html
@@ -0,0 +1,185 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0XSzsMlgEdmt3adZL5Dmdw CRC: 3403898630 -->Design<!-- END:presentationName,_0XSzsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0XSzsMlgEdmt3adZL5Dmdw CRC: 1218476290 -->This checklist provides questions to verify that the design is created in a consistent and complete manner.<!-- END:briefDescription,_0XSzsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_YIYIYMM1EdmSIPI87WLu3g CRC: 4067238563 --><p>
+ The items in this checklist represent good practices for creating and communicating a robust design. Try to address
+ every item to the greatest extent possible to create the best design. It may not be possible to address every item, and
+ some items may only be able to be addressed to a limited extent. In these cases, be sure that there are good reasons
+ for only partially addressing an item, or not addressing an item at all.
+</p>
+<p>
+ Design can be performed every day. Use this checklist regularly to assure the design is robust, consistent, and
+ understandable. Make the design good enough for the specific goals being addressed by using this checklist to identify
+ areas that have been skipped, ignored, or not sufficiently addressed.
+</p><!-- END:mainDescription,_YIYIYMM1EdmSIPI87WLu3g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_cKSvsD6SEduAL-bCqar_dg CRC: 26480598 -->General<!-- END:name,_cKSvsD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_cKSvsD6SEduAL-bCqar_dg CRC: 2506740626 --><p>
+ Do separate design elements have low coupling? Does each design element have high internal cohesion?
+</p>
+<p>
+ Does the design reflect the architectural objectives of the system?
+</p>
+<p>
+ Can the system be implemented from the information in the design? Has sufficient detail been included?
+</p>
+<p>
+ Is the design consistent? Does any part of the design contradict another part of it in such a way that puts the project
+ at risk?
+</p>
+<p>
+ Is the design able to accommodate future changes?
+</p>
+<p>
+ Is the design appropriate to the experience level of other team members and stakeholders, neither too simple nor too
+ advanced?
+</p>
+<p>
+ Is the design written in such a way, and is it structured well enough, so it can be maintained easily?
+</p>
+<p>
+ Does the design constrain the implementation only as much as is necessary?
+</p>
+<p>
+ Does the design describe all the behavior of the system for the requirements that are currently being addressed?
+</p>
+<p>
+ Can all parts of the design be traced back to the requirements? Can the requirements (for the current iteration) be
+ traced to design elements?
+</p>
+<p>
+ Is there an unambiguous place or places in the design where each behavior exists?
+</p>
+<p>
+ Are the use case flows that are currently being addressed described in the design?
+</p>
+<p>
+ Are complex flows outside the Basic Flow addressed, including exceptional cases?
+</p>
+<p>
+ Has the behavior described in the requirements that are currently being addressed been distributed to the correct
+ design elements?
+</p>
+<p>
+ Does the design provide enough information for test design? For example, are the collaborations between design elements
+ clear enough to create integration tests?
+</p>
+<p>
+ Have redundant areas of the design been removed so the Implementation does not contain redundant code?
+</p><!-- END:sectionDescription,_cKSvsD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,__4O2AD6WEduAL-bCqar_dg CRC: 526592327 -->Organization and Clarity<!-- END:name,__4O2AD6WEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,__4O2AD6WEduAL-bCqar_dg CRC: 2838722867 --><p>
+ Does the design describe the system at the appropriate level of abstraction, given the objectives? This usually means
+ the system is described at a number of different levels of abstraction and perspectives.
+</p>
+<p>
+ Does the design use common vocabulary and terms from the business and technical domains?
+</p>
+<p>
+ Does the design describe the behavior of the elements unambiguously to the extent that developer tests can be created
+ toverify the implementation?
+</p>
+<p>
+ Are the design's constructs, vocabulary, and semantics appropriate to the problem being solved? This usually means the
+ customer's vocabulary is used, and elements of the design are referenced in a consistent manner.
+</p>
+<p>
+ Is the design organized in a way that team members can easily find the information they're looking for?
+</p>
+Is the notation used to describe the design used consistently?<br />
+<p>
+ Is the design organized in a way that helps team members modify it without contending for the same part of the design?
+ That is, can mulitple people work on the design in parallel?
+</p>
+<p>
+ Are the names of elements within the design consistent and easy to interpret?
+</p>
+<p>
+ Does each design element represent a clearly defined abstraction?
+</p>
+<p>
+ Is the design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to
+ implementers?
+</p>
+<p>
+ Is the design clear enough and contain enough detail so it can be implemented?
+</p><!-- END:sectionDescription,__4O2AD6WEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_dahBcD6SEduAL-bCqar_dg CRC: 1822983426 -->Architecture<!-- END:name,_dahBcD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_dahBcD6SEduAL-bCqar_dg CRC: 2885622810 --><p>
+ Is the architecture clearly called out in the design ? Can team members and stakeholders clearly identify the portion
+ of the design that is the architecture?
+</p>
+<p>
+ Are architectural mechanisms (patterns) clearly defined in the design so they're reusable and understandable?
+</p>
+<p>
+ Are architectural mechanisms used appropriately? Are they applied in all applicable circumstances?
+</p><!-- END:sectionDescription,_dahBcD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_kWnQ4D6SEduAL-bCqar_dg CRC: 1704096685 -->Subsystems<!-- END:name,_kWnQ4D6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_kWnQ4D6SEduAL-bCqar_dg CRC: 1533110501 --><p>
+ Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the only
+ way to access the behavior of elements inside the subsystem?
+</p>
+<p>
+ Is the interface for each subsystem clearly defined in the design?
+</p>
+<p>
+ Are the subsystem dependencies documented?
+</p><!-- END:sectionDescription,_kWnQ4D6SEduAL-bCqar_dg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/design_vm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/design_vm.html
new file mode 100644
index 0000000..5c7d730
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/design_vm.html
@@ -0,0 +1,154 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\design_vm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design_vm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_sG8ZoD6SEduAL-bCqar_dg CRC: 912482530 -->Packages and Organization<!-- END:name,_sG8ZoD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_sG8ZoD6SEduAL-bCqar_dg CRC: 1465976016 --><p>
+ Is the package partitioning logical and consistent? Does it make sense to team members and stakeholders?
+</p>
+<p>
+ Do package names accurately describe the contents of the package and the role they play in the architecture? Do they
+ follow naming conventions?
+</p>
+<p>
+ Do public packages and interfaces provide a logically cohesive set of services?
+</p>
+<p>
+ Are all the contents of a package listed? Are the classes within a package cohesive?
+</p>
+<p>
+ Do package dependencies correspond to the dependencies of the contained classes?
+</p>
+<p>
+ Are there packages or classes within a package that can be separated into and independent or sub-package?<br />
+</p><!-- END:sectionDescription,_sG8ZoD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_tx6tsD6SEduAL-bCqar_dg CRC: 3492918147 -->Views<!-- END:name,_tx6tsD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_tx6tsD6SEduAL-bCqar_dg CRC: 242694062 --><p>
+ Does each diagram help the designer reason about the design, or communicate key design decisions to the team?
+</p>
+<p>
+ Are the relationships between diagrams clear when several diagrams are used to describe behavior?
+</p>
+<p>
+ Is it easy to navigate between related diagrams?
+</p>
+<p>
+ Does each diagram focus on a relevant perspective? For instance, does a set of diagrams show a single class and its
+ direct relationships, rather than using one or two diagrams to show all classes?
+</p>
+<p>
+ Is each diagram complete and minimal? Does it show everything relevant to that view and nothing more?
+</p>
+<p>
+ Are the diagrams tidy and easy to interpret, with a minimum of clutter?
+</p><!-- END:sectionDescription,_tx6tsD6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_yeFh4D6SEduAL-bCqar_dg CRC: 2945124794 -->UML<!-- END:name,_yeFh4D6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_yeFh4D6SEduAL-bCqar_dg CRC: 1196805279 --><p>
+ Does the visual model conform to UML standards so all stakeholders can understand the model over time? See the <a href="http://www.uml.org/" target="_blank">OMG UML Resource Page</a> for more information.
+</p>
+<p>
+ Does the visual model conform to project or organization specific modeling standards?
+</p>
+Is the visual model internally consistent? For instance, if an object diagram shows a relationship between objects, does a
+corresponding relationship exist between the appropriate classes?<br />
+<p>
+ Does the name of each class clearly reflect the role it plays?
+</p>
+<p>
+ Does each class offer the required behavior?
+</p>
+<p>
+ Is there at least one realization association defined for each interface? The realization may represent a 3rd
+ party implementation of the subsystem.
+</p>
+<p>
+ Are there dependency associations from each subsystem to the interfaces it uses?
+</p>
+<p>
+ Is each operation in a subsystem interface described in a sequence diagram? Or at least mapped directly to an operation
+ in a class?
+</p>
+<p>
+ Does each class represent a single well defined abstraction?
+</p>
+<p>
+ Are generalization relationships used only to inherit definitions, not behavior (implementation)? In other words, is
+ behavior shared through the use of association, aggregation and containment relationships instead of generalization?
+</p>
+<p>
+ Are parent classes in generalization relationships abstract? Are the "leaf" classes in a generalization hierarchy the
+ only concrete classes?
+</p>
+<p>
+ Are stereotypes used consistently and meaningfully?
+</p>
+<p>
+ Do statecharts exist for classes with complex or restrictive state changes?
+</p>
+<p>
+ Do relationships have descriptive role or association names (one or the other but not both), and correct
+ multiplicities?
+</p>
+<p>
+ Are relationships between classes unidirectional whenever possible?<br />
+
+</p><!-- END:sectionDescription,_yeFh4D6SEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_IsDY4D6TEduAL-bCqar_dg CRC: 274651581 -->Non-UML Visual Modeling<!-- END:name,_IsDY4D6TEduAL-bCqar_dg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_IsDY4D6TEduAL-bCqar_dg CRC: 4111086495 --><p>
+ Are the semantics of the visual modeling language clearly defined, documented, and accessible to team members? The
+ semantics should be meaninful to the users of the model.
+</p>
+<p>
+ Can the semantics of the modeling language be understood over time? Is the language documented well enough so that team
+ members can understand the model long after design decisions have taken place?
+</p>
+<p>
+ Are team members and stakeholders trained in the modeling language being used?
+</p>
+<p>
+ Does the visual model conform to the semantics of the visual modeling language? In other words, are the meanings
+ of the symbols in the diagrams consistent across the model and diagrams?
+</p><!-- END:sectionDescription,_IsDY4D6TEduAL-bCqar_dg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/good_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/good_requirements.html
new file mode 100644
index 0000000..e761171
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/good_requirements.html
@@ -0,0 +1,164 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\good_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: good_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_jxn9EO0HEdqHTdbLTmC5IQ CRC: 3010651615 -->Qualities of Good Requirements<!-- END:presentationName,_jxn9EO0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_jxn9EO0HEdqHTdbLTmC5IQ CRC: 489495434 -->This checklist provides guidance on assessing the quality of requirements.<!-- END:briefDescription,_jxn9EO0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDsu0HEdqHTdbLTmC5IQ CRC: 2680628265 -->Is the requirement correct?<!-- END:name,_jxuDsu0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDsu0HEdqHTdbLTmC5IQ CRC: 1326692982 --><p>
+ Does the requirement specify a true need, desire, or obligation?
+</p>
+<p>
+ Have you identified the "root cause" for the requirement?
+</p><!-- END:sectionDescription,_jxuDsu0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDs-0HEdqHTdbLTmC5IQ CRC: 2453166247 -->Is the requirement complete?<!-- END:name,_jxuDs-0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDs-0HEdqHTdbLTmC5IQ CRC: 923625204 --><p>
+ Is the requirement stated as a complete sentence?
+</p>
+<p>
+ Is the requirement stated entirely in one place, in a manner that does not force the reader to look at additional
+ information to understand the requirement?
+</p><!-- END:sectionDescription,_jxuDs-0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDse0HEdqHTdbLTmC5IQ CRC: 1375086789 -->Is the requirement clear?<!-- END:name,_jxuDse0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDse0HEdqHTdbLTmC5IQ CRC: 4116032612 --><p>
+ Is the requirement unambiguous and not confusing?
+</p>
+<p>
+ Does everyone agree on the meaning of the requirement?
+</p><!-- END:sectionDescription,_jxuDse0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDt-0HEdqHTdbLTmC5IQ CRC: 1860228673 -->Is the requirement consistent<!-- END:name,_jxuDt-0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDt-0HEdqHTdbLTmC5IQ CRC: 787788266 --><p>
+ Is the requirement in conflict with other requirements?
+</p>
+<p>
+ Is the terminology used consistent with other requirements and glossary terms?
+</p><!-- END:sectionDescription,_jxuDt-0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDte0HEdqHTdbLTmC5IQ CRC: 995275143 -->Is the requirement verifiable?<!-- END:name,_jxuDte0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDte0HEdqHTdbLTmC5IQ CRC: 3260001816 --><p>
+ Can we determine whether the system satisfies the requirement?
+</p>
+<p>
+ Is it possible to define a clear, unambiguous pass/fail criterion?
+</p>
+<p>
+ Is it possible to determine if the requirement has been met via inspection, analysis, demonstration or test?
+</p><!-- END:sectionDescription,_jxuDte0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDtu0HEdqHTdbLTmC5IQ CRC: 1566052626 -->Is the requirement traceable?<!-- END:name,_jxuDtu0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDtu0HEdqHTdbLTmC5IQ CRC: 2457844759 --><p>
+ Is the requirement uniquely identified so it can be unambiguously referenced?
+</p><!-- END:sectionDescription,_jxuDtu0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDtO0HEdqHTdbLTmC5IQ CRC: 1331256571 -->Is the requirement feasible?<!-- END:name,_jxuDtO0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDtO0HEdqHTdbLTmC5IQ CRC: 26269228 --><p>
+ Can the requirement be satisfied within cost and on schedule?
+</p>
+<p>
+ Is the requirement technically feasible with current technology?
+</p>
+<p>
+ Is the requirement physically achievable?
+</p><!-- END:sectionDescription,_jxuDtO0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jxuDsO0HEdqHTdbLTmC5IQ CRC: 3359799507 -->Is the requirement design independent?<!-- END:name,_jxuDsO0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jxuDsO0HEdqHTdbLTmC5IQ CRC: 2721187127 --><p>
+ Are all requirements that impose constraints on the design, limiting design options, justified?
+</p>
+<p>
+ Is the requirement stated in such that there is more than one way that it can be satisfied?
+</p><!-- END:sectionDescription,_jxuDsO0HEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_gRb_IJEvEdui_vx06Mo1eg CRC: 4047137448 -->Is the requirement atomic?<!-- END:name,_gRb_IJEvEdui_vx06Mo1eg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_gRb_IJEvEdui_vx06Mo1eg CRC: 2752865898 --><p>
+ Does the requirement statement define exactly one requirement?
+</p>
+<p>
+ Is the requirement statement free of conjunctions (and, or, but) that may indicate multiple requirements?
+</p><!-- END:sectionDescription,_gRb_IJEvEdui_vx06Mo1eg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/risk_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/risk_list.html
new file mode 100644
index 0000000..15ff8fb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/risk_list.html
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\risk_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: risk_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7BZa0DIdEduDTv4Y1akVTA CRC: 3469038815 -->Risk List<!-- END:presentationName,_7BZa0DIdEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_7BZa0DIdEduDTv4Y1akVTA CRC: 1662612355 -->This checklist provides guidance on assessing that all possible risks have been considered in a project.<!-- END:briefDescription,_7BZa0DIdEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_qO41ADIfEduDTv4Y1akVTA CRC: 2532753143 -->Have all potential risks to the project been identified<!-- END:name,_qO41ADIfEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_qO41ADIfEduDTv4Y1akVTA CRC: 2119273592 -->Have you identified anything that can be on the path to the project success? List all potential risks, giving a description
+and type (direct or indirect). See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a> for more information.<!-- END:sectionDescription,_qO41ADIfEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_5RiSkDe2EduD7J48kKN20g CRC: 228826754 -->Are risks described without ambiguity<!-- END:name,_5RiSkDe2EduD7J48kKN20g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_5RiSkDe2EduD7J48kKN20g CRC: 3123451310 -->Make sure you capture and describe risks in a clear, concise and unambiguous way. Also follow these rules when describing
+mitigation strategies for risks. This will avoid unnecessary work and - more importantly - that a risks are
+effectively identified and managed.<!-- END:sectionDescription,_5RiSkDe2EduD7J48kKN20g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_2rpQoDIfEduDTv4Y1akVTA CRC: 1192245815 -->What is the probability of happening and impact of each risk<!-- END:name,_2rpQoDIfEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_2rpQoDIfEduDTv4Y1akVTA CRC: 500471375 -->Determine the probability of the risk happening and its impact on the project. This gives you the order of magnitude
+of risks (probability x impact), allowing you to address the high magnitude risks early in the project. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a> for more information.<!-- END:sectionDescription,_2rpQoDIfEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_x-gbwDe0EduD7J48kKN20g CRC: 2488283731 -->Have the risks been properly prioritized and sorted<!-- END:name,_x-gbwDe0EduD7J48kKN20g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_x-gbwDe0EduD7J48kKN20g CRC: 2345677198 -->The risk list is a prioritized list with the highest risk at the top and the rest in descending order. They should be
+sorted according to their magnitude of risk.<!-- END:sectionDescription,_x-gbwDe0EduD7J48kKN20g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_hSFaYDe3EduD7J48kKN20g CRC: 2371225870 -->Are there interdependencies between risks<!-- END:name,_hSFaYDe3EduD7J48kKN20g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_hSFaYDe3EduD7J48kKN20g CRC: 190672623 --><p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Make sure you establish interdependencies between risks as
+ appropriate. For example, the consequence of a risk happening may raise the probability of another risk happening, or
+ raise the impact that other risk brings to the project. If risks depend on each other, you may need to
+ mitigate all interdependent risks at the same time, or revisit the risk list to update the magnitude of
+ dependent risks.</span>
+</p><!-- END:sectionDescription,_hSFaYDe3EduD7J48kKN20g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_LATHgDIeEduDTv4Y1akVTA CRC: 1550330541 -->Is there a mitigation strategy for each risk<!-- END:name,_LATHgDIeEduDTv4Y1akVTA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_LATHgDIeEduDTv4Y1akVTA CRC: 3345413596 --><p>
+ Propose a mitigation strategy for each identified risk. You can either transfer the risk, avoid it, accept it or
+ mitigate it (by minimizing the probability of happening or impact that the risk brings to the project). See
+ <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk_management,_VNxL4ACsEdu8m4dIntu6jA.html" guid="_VNxL4ACsEdu8m4dIntu6jA">Concept: Risk Management</a> for more information.
+</p><!-- END:sectionDescription,_LATHgDIeEduDTv4Y1akVTA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/supporting_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/supporting_requirements.html
new file mode 100644
index 0000000..b2233a4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/supporting_requirements.html
@@ -0,0 +1,183 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\supporting_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Vael8CGMEdu3VKXZx45D3A CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_Vael8CGMEdu3VKXZx45D3A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Vael8CGMEdu3VKXZx45D3A CRC: 378433463 -->This check list is used to verify that all types of supporting requirements are considered.<!-- END:briefDescription,_Vael8CGMEdu3VKXZx45D3A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_kTZiACGMEdu3VKXZx45D3A CRC: 1359670946 -->Have global Functional requirements that will be implemented in the next iteration been captured and validated?<!-- END:name,_kTZiACGMEdu3VKXZx45D3A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_kTZiACGMEdu3VKXZx45D3A CRC: 2556327287 --><ul>
+ <li>
+ Are functional requirements that affect multiple Use Cases identified? For example, all Use Cases may be subject to
+ access control, audit trail, general responses to abnormal situations (overflow, communication facilities, error
+ handling and recovery) and so on.
+ </li>
+ <li>
+ For each of these requirements, are they behavioral and better captured in a common Use Case?
+ </li>
+ <li>
+ For each of these functions, is it clear how input and shared data generate output and shared data?
+ </li>
+</ul><!-- END:sectionDescription,_kTZiACGMEdu3VKXZx45D3A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_-eJXoCGMEdu5QMD9IAHRNg CRC: 4293485151 -->Have Usability requirements that will be implemented in the next iteration been captured and validated?<!-- END:name,_-eJXoCGMEdu5QMD9IAHRNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_-eJXoCGMEdu5QMD9IAHRNg CRC: 2978113884 --><ul>
+ <li>
+ Have the efficiency and usability factors of user tasks been considered?
+ </li>
+ <li>
+ Are the requirements specified in a way that is verifiable, including metrics and target values?
+ </li>
+ <li>
+ Have novice as well as expert users been considered?
+ </li>
+</ul><!-- END:sectionDescription,_-eJXoCGMEdu5QMD9IAHRNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_QCbtwCGNEdubdKsr57an1g CRC: 983575557 -->Have Reliability requirements that will be implemented in the next iteration been captured and validated?<!-- END:name,_QCbtwCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_QCbtwCGNEdubdKsr57an1g CRC: 3043646363 --><ul>
+ <li>
+ Have reliability requirements been specified as measurable requirements or prioritized design goals?
+ </li>
+ <li>
+ Is error checking and recovery required?
+ </li>
+ <li>
+ Are undesired events considered and their required responses specified?
+ </li>
+ <li>
+ Are initial or special states considered (such as cold starts or abnormal termination)?
+ </li>
+</ul><!-- END:sectionDescription,_QCbtwCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_e3pOgCGNEdubdKsr57an1g CRC: 421874365 -->Have Performance requirements that will be implemented in the next iteration been captured and validated?<!-- END:name,_e3pOgCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_e3pOgCGNEdubdKsr57an1g CRC: 3650385956 --><ul>
+ <li>
+ Have the resource and performance margin requirements been stated (speed, response time, recovery time of various
+ software functions)?
+ </li>
+</ul><!-- END:sectionDescription,_e3pOgCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_l8CeUCGNEdubdKsr57an1g CRC: 2425519819 -->Have Supportability requirements that will be implemented in the next iteration been captured and validated?<!-- END:name,_l8CeUCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_l8CeUCGNEdubdKsr57an1g CRC: 3966583684 --><ul>
+ <li>
+ Are there any requirements that will enhance the supportability or maintainability of the system being built?
+ </li>
+</ul><!-- END:sectionDescription,_l8CeUCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_wIttsCGNEdubdKsr57an1g CRC: 640713444 -->Have Constraints that must be considered in the next iteration been captured and validated?<!-- END:name,_wIttsCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_wIttsCGNEdubdKsr57an1g CRC: 4164920008 --><ul>
+ <li>
+ Are there any required standards in effect, implementation language, policies for database integrity, resource
+ limits, operating environment(s), etc.?
+ </li>
+ <li>
+ Has the use of inherited design or code or pre-selected tools been specified?
+ </li>
+</ul><!-- END:sectionDescription,_wIttsCGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_5j6c0CGNEdubdKsr57an1g CRC: 3775943748 -->Have External Interfaces that must be considered in the next iteration been identified?<!-- END:name,_5j6c0CGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_5j6c0CGNEdubdKsr57an1g CRC: 2092812663 --><ul>
+ <li>
+ Is it clear how the software interacts with people, the system's hardware, other hardware, and other software?
+ </li>
+ <li>
+ Have all critical data elements that cross system boundaries been identified for those scenarios that will be
+ implemented in the next iteration?
+ </li>
+</ul><!-- END:sectionDescription,_5j6c0CGNEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_H052MCGOEdubdKsr57an1g CRC: 3870735765 -->Have Business Rules that will be implemented in the next iteration been captured and validated?<!-- END:name,_H052MCGOEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_H052MCGOEdubdKsr57an1g CRC: 1947583231 --><ul>
+ <li>
+ Are the rules relevant to the use cases identified (data validation rules, formulas, flow decisions)?
+ </li>
+</ul><!-- END:sectionDescription,_H052MCGOEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_NBM78CGOEdubdKsr57an1g CRC: 1232273822 -->Have applicable Standards and Regulatory Compliance requirements that must be considered in the next iteration been identified?<!-- END:name,_NBM78CGOEdubdKsr57an1g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_NBM78CGOEdubdKsr57an1g CRC: 1181702482 --><ul>
+ <li>
+ Have all requirements derived from existing standard and regulations been specified?
+ </li>
+</ul><!-- END:sectionDescription,_NBM78CGOEdubdKsr57an1g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/test_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/test_case.html
new file mode 100644
index 0000000..376e3cb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/test_case.html
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\test_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0Zxf8MlgEdmt3adZL5Dmdw CRC: 607185224 -->Test Case<!-- END:presentationName,_0Zxf8MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0Zxf8MlgEdmt3adZL5Dmdw CRC: 2817280581 -->This checklist provides questions to verify that test cases are created in a consistent and complete manner.<!-- END:briefDescription,_0Zxf8MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_yXujsLcOEduFFo_97woSMw CRC: 26480598 -->General<!-- END:name,_yXujsLcOEduFFo_97woSMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_yXujsLcOEduFFo_97woSMw CRC: 802699012 --><ul>
+ <li>
+ Does the Test Case identify the requirement it evaluates? This linking might be informal through a naming
+ convention or formalized through a requirements traceability matrix.
+ </li>
+ <li>
+ Does the Test Case reference the preconditions and postconditions that apply to it?
+ </li>
+</ul><!-- END:sectionDescription,_yXujsLcOEduFFo_97woSMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Hv2n0BBbEduXULqRagzBHA CRC: 4262580536 -->Name<!-- END:name,_Hv2n0BBbEduXULqRagzBHA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Hv2n0BBbEduXULqRagzBHA CRC: 1894858872 --><ul>
+ <li>
+ Is the Test Case name unique?
+ </li>
+ <li>
+ Does the name express a test condition or an expected result?
+ </li>
+ <li>
+ Is it unambiguous to a stakeholder?
+ </li>
+</ul><!-- END:sectionDescription,_Hv2n0BBbEduXULqRagzBHA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_3i-gkLcOEduFFo_97woSMw CRC: 314147162 -->Brief Description<!-- END:name,_3i-gkLcOEduFFo_97woSMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_3i-gkLcOEduFFo_97woSMw CRC: 3553871614 --><ul class="noindent">
+ <li>
+ Is the logical test condition clearly identified in the description?
+ </li>
+ <li>
+ Does the description clearly state the expected result?
+ </li>
+ <li>
+ Is the expected result stated as a concrete outcome?
+ </li>
+ <li>
+ Can a casual reader distinguish this Test Case from a similar one?
+ </li>
+</ul><!-- END:sectionDescription,_3i-gkLcOEduFFo_97woSMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_4uresLcOEduFFo_97woSMw CRC: 3458387747 -->Test Data Needs<!-- END:name,_4uresLcOEduFFo_97woSMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_4uresLcOEduFFo_97woSMw CRC: 1162659767 --><ul>
+ <li>
+ Does the Test Case note the kinds of test data required to implement a detailed Test Script?
+ </li>
+ <li>
+ Are the test data type, uniqueness, and quality sufficiently explained?
+ </li>
+</ul><!-- END:sectionDescription,_4uresLcOEduFFo_97woSMw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/test_script.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/test_script.html
new file mode 100644
index 0000000..e56583f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/test_script.html
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\test_script.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_script.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0Z9tMMlgEdmt3adZL5Dmdw CRC: 273197623 -->Test Script<!-- END:presentationName,_0Z9tMMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0Z9tMMlgEdmt3adZL5Dmdw CRC: 4204877222 -->This checklist provides questions to verify that tests are created in a consistent and complete manner.<!-- END:briefDescription,_0Z9tMMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_DiPTsE_cEduqM_QlWBlZ_g CRC: 1963975593 -->Does the test script conform to the related test case<!-- END:name,_DiPTsE_cEduqM_QlWBlZ_g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_DiPTsE_cEduqM_QlWBlZ_g CRC: 1951697416 -->Ensure that the test script conforms to the specification established in the test case if one is associated with the test
+script. The test case captures the intent of the test; the test script must conform to this intent.<!-- END:sectionDescription,_DiPTsE_cEduqM_QlWBlZ_g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_KS930Bg9EduxCP6DVVLxsA CRC: 1346387023 -->Is the test script testable<!-- END:name,_KS930Bg9EduxCP6DVVLxsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_H-q58Bg9EduxCP6DVVLxsA CRC: 4065725125 -->Is the test script reusable<!-- END:name,_H-q58Bg9EduxCP6DVVLxsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_H-q58Bg9EduxCP6DVVLxsA CRC: 1421571037 -->Ensure that your test scripts can be reused by designing your test scripts to maximize reuse. Promoting reuse takes
+different forms depending on whether you are generating, programming, or recording test scripts.<!-- END:sectionDescription,_H-q58Bg9EduxCP6DVVLxsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_5_92wE_cEduqM_QlWBlZ_g CRC: 850498300 -->Is the test script prescriptive and unambiguous<!-- END:name,_5_92wE_cEduqM_QlWBlZ_g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_5_92wE_cEduqM_QlWBlZ_g CRC: 2116895210 -->Ensure that the test script represents clear instructions on how the test must be run and how the results should be
+analyzed. While non-automated tests can be written in such a way that the tester can have leeway in how the test is
+precisely run, there is no room for creativity in how the test results are to be analyzed for success or failure.<!-- END:sectionDescription,_5_92wE_cEduqM_QlWBlZ_g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_La5wQBg9EduxCP6DVVLxsA CRC: 1149849764 -->Is the test script named consistently with your other test work products<!-- END:name,_La5wQBg9EduxCP6DVVLxsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_La5wQBg9EduxCP6DVVLxsA CRC: 1404545553 -->Ensure that the naming of your test scripts is consistent with other test-related work products. For example, if you
+are creating test classes for each of your test cases, ensure that the naming represents this relationship.
+Alternatively, if you are building test scripts inside of a library, use a consistent naming convention to reflect the
+library or libraries.<!-- END:sectionDescription,_La5wQBg9EduxCP6DVVLxsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Ng5zcBg9EduxCP6DVVLxsA CRC: 100638783 -->Does your test script provide test coverage<!-- END:name,_Ng5zcBg9EduxCP6DVVLxsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Ng5zcBg9EduxCP6DVVLxsA CRC: 2734995774 -->Ensure that your test scripts provide test coverage consistent with the system under test.<!-- END:sectionDescription,_Ng5zcBg9EduxCP6DVVLxsA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/uc_model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/uc_model.html
new file mode 100644
index 0000000..c09c8fc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/uc_model.html
@@ -0,0 +1,163 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\uc_model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uc_model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0U6OEMlgEdmt3adZL5Dmdw CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_0U6OEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0U6OEMlgEdmt3adZL5Dmdw CRC: 1098136934 -->This checklist provides questions to verify that the Use-Case Model is described in a consistent and complete manner.<!-- END:briefDescription,_0U6OEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_rLdVMAeREduWycDgioo5rg CRC: 818635897 -->Is it easy to understand what the system does by reviewing the model?<!-- END:name,_rLdVMAeREduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_rLdVMAeREduWycDgioo5rg CRC: 1592198705 --><ul>
+ <li>
+ The Use-Case Survey provides a clear, concise overview of the purpose and functionality of the system.
+ </li>
+ <li>
+ There are no long chains of include relationships, such as when an included use case includes other use
+ cases. These can obscure comprehensibility.
+ </li>
+ <li>
+ Included use cases should not make assumptions about use cases that include them.
+ </li>
+ <li>
+ If several use cases contain similar sub-flows investigate if factoring this common behavior into an
+ included use case will simplify the model.
+ </li>
+</ul><!-- END:sectionDescription,_rLdVMAeREduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,__kgR8AeREduWycDgioo5rg CRC: 3807182316 -->Have all use cases been identified?<!-- END:name,__kgR8AeREduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,__kgR8AeREduWycDgioo5rg CRC: 3615580343 --><ul>
+ <li>
+ The use cases identified collectively account for all required behavior of the system.
+ </li>
+ <li>
+ All features identified in the Vision document for this iteration have been addressed by at least one use case.
+ </li>
+ <li>
+ All non-functional requirements that must be satisfied by a specific use case have been captured in that use case
+ </li>
+ <li>
+ The use-case model contains no superfluous behavior (gold-platting).
+ </li>
+ <li>
+ Each concrete use case must be associated with at least one actor.
+ </li>
+ <li>
+ Every actor should be associated with at least on use case.
+ </li>
+</ul><!-- END:sectionDescription,__kgR8AeREduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_fknU0Jz1EduBcbjYtLtItQ CRC: 1206379082 -->Is the model consistent?<!-- END:name,_fknU0Jz1EduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_fknU0Jz1EduBcbjYtLtItQ CRC: 231219731 --><ul>
+ <li>
+ Under the same conditions, and with the same input, the system behavior should be consistent.
+ </li>
+</ul><!-- END:sectionDescription,_fknU0Jz1EduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_KowpkAeSEduWycDgioo5rg CRC: 2253122176 -->Are all relationships between use cases required?<!-- END:name,_KowpkAeSEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_KowpkAeSEduWycDgioo5rg CRC: 1512830752 --><ul>
+ <li>
+ Each included use case should make the model easier to understand, implement and maintain.
+ </li>
+ <li>
+ Each concrete use case (i.e. not an included use case) should be independent of other use cases.
+ </li>
+</ul>
+<p>
+ <br />
+</p><!-- END:sectionDescription,_KowpkAeSEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jyHeMAeTEduWycDgioo5rg CRC: 3494360501 -->Are use-case packages used appropriately?<!-- END:name,_jyHeMAeTEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jyHeMAeTEduWycDgioo5rg CRC: 1209591249 --><ul>
+ <li>
+ Cross-package dependencies have been reduced or eliminated to prevent model ownership conflicts
+ </li>
+ <li>
+ Packaging is intuitive and makes the model easier to understand and implement
+ </li>
+</ul><!-- END:sectionDescription,_jyHeMAeTEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_i-S-ADeKEdu6VLD0YaVLog CRC: 4017282728 -->Do all model elements have appropriate names?<!-- END:name,_i-S-ADeKEdu6VLD0YaVLog -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_i-S-ADeKEdu6VLD0YaVLog CRC: 388921198 --><ul>
+ <li>
+ No two use cases can have the same name.
+ </li>
+ <li>
+ Each actor has a name that effectively describes the role.
+ </li>
+</ul><!-- END:sectionDescription,_i-S-ADeKEdu6VLD0YaVLog -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_IYRUkJz2EduBcbjYtLtItQ CRC: 1975733662 -->Are individual use cases properly specified?<!-- END:name,_IYRUkJz2EduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_IYRUkJz2EduBcbjYtLtItQ CRC: 1657789414 --><ul>
+ <li>
+ Review the quality of each use case specification using the <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html"
+ guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>.
+ </li>
+</ul><!-- END:sectionDescription,_IYRUkJz2EduBcbjYtLtItQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/use_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/use_case.html
new file mode 100644
index 0000000..c6def65
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/use_case.html
@@ -0,0 +1,181 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\use_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0kNwINk1Edq2Q8qZoWbvGA CRC: 3319967926 -->Use Case<!-- END:presentationName,_0kNwINk1Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0kNwINk1Edq2Q8qZoWbvGA CRC: 272819987 -->This checklist provides questions to verify that use cases are described in a consistent and complete manner.<!-- END:briefDescription,_0kNwINk1Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_663wMNk1Edq2Q8qZoWbvGA CRC: 824882437 -->Is the use-case name meaningful and un-ambiguous?<!-- END:name,_663wMNk1Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_663wMNk1Edq2Q8qZoWbvGA CRC: 1150248584 --><p>
+ Does the use case have a unique name?
+</p>
+<p>
+ Is the name a verb + noun phrase (for example, Withdraw Cash)?
+</p>
+<p>
+ Does the name accurately summarize the main goal of the use case?
+</p>
+<p>
+ Is the name "actor independent"?
+</p><!-- END:sectionDescription,_663wMNk1Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ZTA8QJznEduBcbjYtLtItQ CRC: 2587034568 -->Does the brief description clearly describe the primary goal of the use case?<!-- END:name,_ZTA8QJznEduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ZTA8QJznEduBcbjYtLtItQ CRC: 1481017042 --><p>
+ Is it clear from the brief description what the main purpose of the use case is?
+</p>
+<p>
+ Is the "observable result of value" obvious?
+</p><!-- END:sectionDescription,_ZTA8QJznEduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_4wJRgJznEduBcbjYtLtItQ CRC: 4162917410 -->Are associated actors and information exchanged clearly defined?<!-- END:name,_4wJRgJznEduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_4wJRgJznEduBcbjYtLtItQ CRC: 1381166868 --><p>
+ Is the use case associated with one or more actors?
+</p>
+<p>
+ Is the primary, or initiating actor, defined?
+</p>
+<p>
+ Is it clear who wishes to perform the use case?
+</p>
+<p>
+ Is all information exchanged between the actor(s) and the system clearly specified?
+</p>
+<p>
+ If a "time" actor is used, are you sure you did not miss an important actor and associated use cases (such as
+ administrative or maintenance personnel that define schedule events)?
+</p><!-- END:sectionDescription,_4wJRgJznEduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Qys_INk2Edq2Q8qZoWbvGA CRC: 2655536127 -->Are the pre-conditions specified?<!-- END:name,_Qys_INk2Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Qys_INk2Edq2Q8qZoWbvGA CRC: 3266314631 --><p>
+ Does each pre-condition represent a tangible state of the system (for example, the Withdraw Cash use
+ case for an automated teller machine has a precondition that the user has an account)?
+</p><!-- END:sectionDescription,_Qys_INk2Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_q3qV0Nk2Edq2Q8qZoWbvGA CRC: 1965870233 -->Are the Basic Flow and Alternate Flows complete, correct and consistent?<!-- END:name,_q3qV0Nk2Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_q3qV0Nk2Edq2Q8qZoWbvGA CRC: 2404604333 --><p>
+ Is it clear how the use case is started?
+</p>
+<p>
+ Is the triggering event clearly described?
+</p>
+<p>
+ Does the flow have a definite ending?
+</p>
+<p>
+ Does each step in the scenario contain the same level of abstraction?
+</p>
+<p>
+ Does each step in the scenario describe something that can actually happen and that the system can reasonably detect?
+</p>
+<p>
+ Does each step make progress towards the goal?
+</p>
+<p>
+ Are there any missing steps? Is it clear how to go from one step to the next? Does the sequence of communication
+ between the actors and the use case conform to the user's expectations?
+</p>
+<p>
+ Does each step describe how the step helps the actor achieve their goal?
+</p>
+<p>
+ Is each step technology independent? Is it free of technical details, and design decisions?
+</p>
+<p>
+ Are the steps correctly numbered?
+</p>
+<p>
+ For each alternate flow is the condition(s) for initiation of the flow clearly defined?
+</p>
+<p>
+ For each alternate flow is it clear how the use case ends or where in the basic flow that the use case resumes?
+</p><!-- END:sectionDescription,_q3qV0Nk2Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_dnLXMNk2Edq2Q8qZoWbvGA CRC: 3961501011 -->Are the post-conditions specified?<!-- END:name,_dnLXMNk2Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_dnLXMNk2Edq2Q8qZoWbvGA CRC: 2449244277 --><p>
+ If "Minimal Guarantees" are present, do they always happen when the use case completes, regardless of success? (A
+ Minimal Guarantee represents a condition that will be true when the use case ends, regardless of how it
+ terminates.)
+</p>
+<p>
+ If "Success Guarantees" are present, do they always happen when the use case completes successfully? (A Success
+ Guarantee represents a condition that will be true when the use case ends successfully, regardless of which path it
+ takes.)
+</p><!-- END:sectionDescription,_dnLXMNk2Edq2Q8qZoWbvGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_vkbMAJzrEduBcbjYtLtItQ CRC: 3928009720 -->Are applicable non-functional requirements captured?<!-- END:name,_vkbMAJzrEduBcbjYtLtItQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_vkbMAJzrEduBcbjYtLtItQ CRC: 3034953606 --><p>
+ Are non-functional requirements (such as performance criteria) that are applicable to the use case captured
+ in the use case?
+</p>
+<p>
+ Are these non-functional requirements applicable to many use cases? It they are, consider capturing them in the
+ supporting requirements specification to simplify maintenance.
+</p><!-- END:sectionDescription,_vkbMAJzrEduBcbjYtLtItQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/vision.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/vision.html
new file mode 100644
index 0000000..f036a4a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/checklists/vision.html
@@ -0,0 +1,140 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\checklists\vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0WoFUMlgEdmt3adZL5Dmdw CRC: 2312412063 -->Vision<!-- END:presentationName,_0WoFUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0WoFUMlgEdmt3adZL5Dmdw CRC: 1728299177 -->This check list provides questions to verify that the Vision is described in a consistent and complete manner.<!-- END:briefDescription,_0WoFUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_VwoioAeiEduWycDgioo5rg CRC: 2259109902 -->Have you fully explored what the problem behind the problem is?<!-- END:name,_VwoioAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_VwoioAeiEduWycDgioo5rg CRC: 877478683 --><p>
+ Make sure that you have found the root cause of the Stakeholder's problem or need. Often, Stakeholders define solutions
+ rather than stating the problem that they are experiencing or the pain they are experiencing. Subsequently, they may
+ not have identified the problem correctly or the correct solution for it.
+</p>
+<p>
+ For example, "We can't support customers who want to buy online" is better than "We need an on-line purchasing system".
+</p><!-- END:sectionDescription,_VwoioAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_dBs8gAeiEduWycDgioo5rg CRC: 2601811294 -->Is the problem statement correctly formulated?<!-- END:name,_dBs8gAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_dBs8gAeiEduWycDgioo5rg CRC: 1128108814 -->Make sure that you have agreement on the problem to be solved.<!-- END:sectionDescription,_dBs8gAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_jGUxYAeiEduWycDgioo5rg CRC: 2731250518 -->Is the list of Stakeholders complete and correct?<!-- END:name,_jGUxYAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_jGUxYAeiEduWycDgioo5rg CRC: 1212021079 -->Make sure you didn't miss any Stakeholders. If you did, you probably do not yet have all of the perspectives that you need
+to consider.<!-- END:sectionDescription,_jGUxYAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_s-be8AeiEduWycDgioo5rg CRC: 1535561730 -->Does everyone agree on the definition of the system boundaries?<!-- END:name,_s-be8AeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_s-be8AeiEduWycDgioo5rg CRC: 3232013601 -->Define what is <strong>in</strong> and what is <strong>out</strong> of system boundaries. This is a critical step in
+defining the scope of work.<!-- END:sectionDescription,_s-be8AeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_z1uG4AeiEduWycDgioo5rg CRC: 3849375126 -->Have you sufficiently explored constraints to put on the system?<!-- END:name,_z1uG4AeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_z1uG4AeiEduWycDgioo5rg CRC: 1683678634 -->Don't forget about the non-functional requirements and constraints. These are often the largest cost of development.<!-- END:sectionDescription,_z1uG4AeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_7KzeEAeiEduWycDgioo5rg CRC: 3567277558 -->Have you covered all kinds of constraints, including political, economic, and environmental?<!-- END:name,_7KzeEAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_7KzeEAeiEduWycDgioo5rg CRC: 3460912494 --><p>
+ These non-technical constraints often lead to problems later.
+</p><!-- END:sectionDescription,_7KzeEAeiEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_DymaUAejEduWycDgioo5rg CRC: 2337553520 -->Have all key features of the system been identified and defined?<!-- END:name,_DymaUAejEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_DymaUAejEduWycDgioo5rg CRC: 798072249 -->Do a completeness check, comparing the features with the problem statement, to make sure that you didn't miss a critical
+feature.<!-- END:sectionDescription,_DymaUAejEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_LRX5AAejEduWycDgioo5rg CRC: 1150035597 -->Will the features solve the problems that are identified?<!-- END:name,_LRX5AAejEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_LRX5AAejEduWycDgioo5rg CRC: 216812406 -->Are all the features really necessary? Perhaps you can reduce the scope.<!-- END:sectionDescription,_LRX5AAejEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_UGRdIAejEduWycDgioo5rg CRC: 101084488 -->Are the features consistent with constraints that you've identified?<!-- END:name,_UGRdIAejEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_UGRdIAejEduWycDgioo5rg CRC: 2786915174 --><p>
+ Check that conflicting requirements do not exist. If you find conflicts, resolve them now.
+</p><!-- END:sectionDescription,_UGRdIAejEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_5y4uAAhUEduRe8TeoBmuGg CRC: 3236088669 -->Can someone who is not familiar with the project understand what you hope the project will achieve by reading the Vision document?<!-- END:name,_5y4uAAhUEduRe8TeoBmuGg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_5y4uAAhUEduRe8TeoBmuGg CRC: 4269518195 -->The purpose of the Vision document is to describe the objectives of the project in terms that non-technical people, who are
+not closely involved with the project, can understand.<!-- END:sectionDescription,_5y4uAAhUEduRe8TeoBmuGg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/actor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/actor.html
new file mode 100644
index 0000000..661f98a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/actor.html
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\actor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: actor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zGqO0MDpEduTGJ8i4u8TMw CRC: 2243197437 -->Actor<!-- END:presentationName,_zGqO0MDpEduTGJ8i4u8TMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_zGqO0MDpEduTGJ8i4u8TMw CRC: 91976382 -->An Actor is a role that a person or external system plays when interacting with a system. Instances of an Actor can be an individual or an external system.<!-- END:briefDescription,_zGqO0MDpEduTGJ8i4u8TMw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-aN0zy068ovKHgmkkoYqoYQ CRC: 2895056882 --><p>
+ To fully understand the system's purpose, you must know who the system is for, that is: Who will use the system? The
+ answer to this question is: the Actors.
+</p>
+<p>
+ An Actor is a role that a person or external system plays when interacting with the system. Instances of an
+ Actor can be an individual or an external system, however each Actor provides a
+ unique and important perspective on the system that is shared by every instance of the Actor.
+</p>
+<p>
+ This difference between an actor and an instance of an actor is illustrated below. Figure 1 shows a case in
+ which Ivar and Mark are operators of a recycling machine. When they are using the machine in this capacity, each is
+ represented by an instance of the actor called Operator that expects certain functionality of the system (Print Daily
+ Reports in this example).
+</p>
+<p>
+ <img height="322" alt="" src="./resources/md_acto2.gif" width="396" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <strong>Figure 1: Example Actor with multiple instances</strong>
+ </p>
+</blockquote>
+<p>
+ Conversely, the same user can act as several actors (that is, the same person can take on different roles). In Figure
+ 2, Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the Depot-Handling
+ System as an ordinary Depot Staff member. Each of these actors expects different functionality of the system.
+</p>
+<p>
+ <img height="139" alt="" src="./resources/md_acto3.gif" width="367" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <strong>Figure 2: Example of user playing different roles</strong><br />
+ </p>
+</blockquote>
+<p>
+ Actors help you to identify external interfaces and to determine the scope the system (what is in the system, vs. what
+ is outside the system boundary). Each Actor has associated use cases which describe what that
+ particular actor expects of the system. It will be very difficult, if not impossible, to assess the
+ completeness of the set of Use Cases without the context provided by the associated Actors. Furthermore, missing an
+ actor may result in missing important stakeholder perspectives, resulting in a solution that does not meet
+ all stakeholder needs.
+</p>
+<p>
+ Hence, identifying the Actors for the system should be done early in the lifecycle. Actors are
+ captured, including their names, brief descriptions, and relationships to use cases, in the <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/uc_model,_W2SgEDR5EdutE_HNDTJk5Q.html"
+ guid="_W2SgEDR5EdutE_HNDTJk5Q">Artifact: Use-Case Model</a>.
+</p><!-- END:mainDescription,-aN0zy068ovKHgmkkoYqoYQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/analysis_mechanism.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/analysis_mechanism.html
new file mode 100644
index 0000000..f50e460
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/analysis_mechanism.html
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\analysis_mechanism.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analysis_mechanism.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0gvqoMlgEdmt3adZL5Dmdw CRC: 2820006851 -->Analysis Mechanism<!-- END:presentationName,_0gvqoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0gvqoMlgEdmt3adZL5Dmdw CRC: 3926877643 -->An Analysis Mechanism is a conceptual representation of an Architectural Mechanism.<!-- END:briefDescription,_0gvqoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_S8KCcMP2EdmWKcx6ixEiwg CRC: 959089530 --><p>
+ An Analysis Mechanism is a conceptual representation of an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. Over time, Analysis Mechanisms are refined into <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s and, later, into <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/implementation_mechanism,_0LcUkA4LEduibvKwrGxWxA.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>s.
+</p>
+<p>
+ Analysis Mechanisms allow the developer to focus on understanding the requirements without getting distracted by
+ the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people
+ can better comprehend the problem.
+</p>
+<p>
+ Analysis Mechanisms are described in simple terms:
+</p>
+<ul>
+ <li>
+ <strong>Name:</strong> Identifies the mechanism.
+ </li>
+ <li>
+ <strong>Basic attributes:</strong> Define the requirements of the mechanism.
+ </li>
+</ul>
+<p>
+ You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as
+ you proceed.
+</p>
+<p>
+ In the top-down mode, experience guides the <a class="elementLink"
+ href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a>, who knows that certain problems are present in the domain and will
+ require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms
+ during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The
+ common aspect of all of these is that each is a general capability of a broad class of systems, and each provides
+ functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support
+ capabilities required in the basic functional requirements of the system, regardless of the platform that it is
+ deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different
+ ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may
+ also be more than one way of implementing each design mechanism.
+</p>
+<p>
+ The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the <a
+ class="elementLink" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> sees, perhaps faintly at first, a common theme emerging from a set of
+ solutions to various problems. For example: There is a need to provide a way for elements in different threads to
+ synchronize their clocks, and there is a need for a common way of allocating resources. <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>, which simplify the language of analysis, emerge from these
+ patterns.
+</p>
+<p>
+ Identifying an Analysis Mechanism means that you identify a common, perhaps implicit subproblem, and you give it a
+ name. Initially, the name might be all that exists. For example, the system will require a persistence
+ mechanism. Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
+ which do not deliver application functionality directly, but exist only to support it. Very often these support classes
+ are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
+ application-level classes.
+</p>
+<p>
+ If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be
+ instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis
+ Mechanism produced this way will be abstract, and it will require further refinement throughout design and
+ implementation work.
+</p>
+<p>
+ You can see examples of how Architectural Mechanisms can be represented in <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/example_analysis_mechanisms_descr,_4k_HsA4LEduibvKwrGxWxA.html"
+ guid="_4k_HsA4LEduibvKwrGxWxA">Example Analysis Mechanism Descriptions</a>.
+</p><!-- END:mainDescription,_S8KCcMP2EdmWKcx6ixEiwg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/arch_mech.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/arch_mech.html
new file mode 100644
index 0000000..053ae8f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/arch_mech.html
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\arch_mech.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: arch_mech.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mzxI0A4LEduibvKwrGxWxA CRC: 469363530 -->Architectural Mechanism<!-- END:presentationName,_mzxI0A4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_mzxI0A4LEduibvKwrGxWxA CRC: 2553675936 -->Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity.<!-- END:briefDescription,_mzxI0A4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-SJrpVySJ2npYs8NwGvnHjw CRC: 3554619484 --><p>
+ Architectural Mechanisms are used to satisfy architecturally significant requirements. When fully described,
+ Architectural Mechanisms show patterns of structure and behavior in the software. They form the basis
+ of common software that will be consistently applied across the product being developed. They also
+ form the basis for standardizing the way that the software works; therefore, they are an important element of the
+ overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing
+ software components can be leveraged to provide the required behaviour; or whether new software should be bought or
+ built.
+</p>
+<p>
+ The key point to take on board when discussing architecture mechanisms is that the defining them is all about making
+ choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about
+ producing detailed design or software. This is a common misunderstanding. The creation of detailed design
+ and software that shows *how* specific mechanisms are satisfied is a development task.
+</p>
+<p>
+ The value in defining architecture mechanisms is that it
+</p>
+<ol>
+ <li>
+ explicitly calls out aspects of the solution mechanics that are common across the system. This aids planning.
+ </li>
+ <li>
+ puts down markers for the developers to build those aspects of the system once and then re-use them. This reduces
+ the workload.
+ </li>
+ <li>
+ promotes the development of a consistent set of services. This makes the system easier to maintain.
+ </li>
+</ol>
+<p>
+ An Architectural Mechanism can have three states: Analysis, Design and Implementation. These
+ categories reflect the state of the architectural mechanism over time. The state changes as successive levels of
+ detail are uncovered during the refinement of architecturally significant requirements into working software. The
+ categories are summarized in the table that follows.
+</p>
+<strong>States of an Architectural Mechanism</strong>
+<table style="WIDTH: 806px; HEIGHT: 228px" cellspacing="0" cellpadding="2" width="806"
+summary="Types of Architectural Mechanism" border="1">
+ <tbody valign="top">
+ <tr>
+ <th scope="col">
+ State
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Analysis
+ </td>
+ <td>
+ A conceptual solution to a common technical problem. For example, persistence is an abstract solution
+ to the common requirement to store data. The purpose of this category is simply to identify the need for an
+ Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Design
+ </td>
+ <td>
+ A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this
+ category is to enable initial design specifications to be produced and to guide precise product or
+ technology selection.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Implementation
+ </td>
+ <td>
+ <p>
+ A further refinement of a Design Mechanism into a specific technology or product that implements
+ the required Architectural Mechanism. For example, MySQL, as a database product, implements the
+ Analysis Mechanism <strong>Persistence</strong> and Design Mechanism <strong>RDBMS.</strong>
+ </p>
+ <p>
+ This essentially represents the point at which the decision is made to re-use, buy or build specific
+ software to provide the services defined by the mechanism.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<p>
+ Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
+ mechanisms. These are synonyms and merely represent the architecture mechanisms in different states of
+ development. The transition from one state to another can often be obvious or intuitive. Therefore, it can be
+ achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The
+ following diagram illustrates the transition of Architectural Mechanisms from one state to another.
+</p>
+<p>
+ <strong>State Machine for Architectural Mechanisms</strong>
+</p>
+<p>
+ <img style="WIDTH: 876px; HEIGHT: 115px" height="113" alt="Architectural Mechanism States"
+ src="./resources/ArchMechanismsStatemachine.JPG" width="600" /> <br />
+</p>
+<br /><!-- END:mainDescription,-SJrpVySJ2npYs8NwGvnHjw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/architecturally_significant_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/architecturally_significant_requirements.html
new file mode 100644
index 0000000..9ae447c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/architecturally_significant_requirements.html
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\architecturally_significant_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architecturally_significant_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HrZGIA4MEduibvKwrGxWxA CRC: 1611319007 -->Architecturally Significant Requirements<!-- END:presentationName,_HrZGIA4MEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_HrZGIA4MEduibvKwrGxWxA CRC: 1638410698 -->Some requirements have a profound impact on the architecture of the solution and require special attention.<!-- END:briefDescription,_HrZGIA4MEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-EytH4BCNGiHF6pZrp8ISCw CRC: 979302489 --><p> Not all requirements have equal significance in the architecture. Some
+ play an important role in determining the architecture of the
+ system, but others do not. </p>
+<p> Deciding whether a specific requirement is architecturally significant is
+ often a matter of judgment. Typically, these are requirements that are
+ technically challenging, technically constraining, or central to the
+ system's purpose. </p>
+<p> These are good examples of Architecturally Significant Requirements:</p>
+
+<ul>
+ <li> The system must record every modification to customer records for audit
+ purposes.</li>
+ <li> The system must respond within 5 seconds.</li>
+ <li> The system must deploy on Microsoft Windows XP and Linux. </li>
+ <li> The system must encrypt all network traffic.</li>
+ <li> The ATM system must dispense cash on demand to validated account
+ holders with sufficient cleared funds.</li>
+</ul>
+<br /><!-- END:mainDescription,-EytH4BCNGiHF6pZrp8ISCw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/business_pattern.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/business_pattern.html
new file mode 100644
index 0000000..c392b42
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/business_pattern.html
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\business_pattern.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: business_pattern.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Z53x0BapEduSTJywppIxVQ CRC: 1400735262 -->Business Pattern<!-- END:presentationName,_Z53x0BapEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Z53x0BapEduSTJywppIxVQ CRC: 3781737701 -->A re-usable portion of design that can be applied to multiple domain-specific activities.<!-- END:briefDescription,_Z53x0BapEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Of51hmgdsO_U2-pnbJ67Cg CRC: 3135408385 --><p> Business Patterns are a form of Design Pattern (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>) and are the business-domain
+ counterpart of <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/architecture_mechanism,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>. Just as
+ similar problems in the technical domain may be solved by using Architecture
+ Mechanisms, similar problems in the business domain can be solved by using Business
+ Patterns. </p>
+<p> Business Patterns are often found in COTS products. For example, packaged
+ applications that support Enterprise Resource Planning or Customer Relationship
+ Management ship with functionality to support a variety of generic business
+ processes. Similarly, it is frequently possible to identify related or similar
+ behavior in the Use Case Scenarios and thereby derive generic designs
+ that you can use in the design of the system. These elements of generic behavior
+ can be expressed as Design Patterns and applied to the system design.
+</p>
+<br /><!-- END:mainDescription,-Of51hmgdsO_U2-pnbJ67Cg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/change_requests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/change_requests.html
new file mode 100644
index 0000000..118e577
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/change_requests.html
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\change_requests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: change_requests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_6jdvECb3Edqh1LYUOGRh2A CRC: 2329320051 -->Change Requests<!-- END:presentationName,_6jdvECb3Edqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_6jdvECb3Edqh1LYUOGRh2A CRC: 2724915672 -->A change request is a general term for any request to change a work product.<!-- END:briefDescription,_6jdvECb3Edqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-BsXK3ZGMm-mUT0KnkdoYBg CRC: 471394020 --><p>
+ A change request represents any request to change a work product. This includes items commonly called defect reports,
+ enhancement requests, requirements change request, implementation requests, and stakeholder requests.
+</p>
+<p>
+ In this process, change request are captured in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/work_items_list,_7vEXEMA4EdqSgKaj2SZBmg.html"
+ guid="_7vEXEMA4EdqSgKaj2SZBmg">Guideline: Work Items List</a> for more information on the recommended
+ attributes of change requests.
+</p><!-- END:mainDescription,-BsXK3ZGMm-mUT0KnkdoYBg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/coding_standard.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/coding_standard.html
new file mode 100644
index 0000000..7ab8327
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/coding_standard.html
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\coding_standard.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: coding_standard.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0lnRMMqOEduwrYVlQ9zp3w CRC: 2456192321 -->Coding Standard<!-- END:presentationName,_0lnRMMqOEduwrYVlQ9zp3w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0lnRMMqOEduwrYVlQ9zp3w CRC: 3336966365 -->A standard describing various coding conventions used for consistent, quality, understandable implementation.<!-- END:briefDescription,_0lnRMMqOEduwrYVlQ9zp3w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-vlYpfwIYlF_ZCk5s4Dsqdg CRC: 3278169282 --><p>
+ Using a coding standard is a software development practice that has been widely accepted in the industry. The need for
+ this practice takes on added importance in a highly collaborative environment. The team should have a standard way
+ of naming and formatting things so they can understand the code quickly and know where to look at all times.
+</p>
+<p>
+ Ideally, the coding standard should be the result of team consensus. In some cases, decisions will be arbitrary (like
+ how much to indent). Each item in the standard should support one or more goals, improved communication being one of
+ the most critical goals. Once the team agrees on a standard, all members of the teams are expected to follow it. With
+ time, the team will use and modify the standard to develop a style that is well adapted to their environment.
+</p>
+<p>
+ Benefits
+</p>
+<ul>
+ <li>
+ Improved communication: increases the ability to read each other's code.
+ </li>
+ <li>
+ Refactoring support: provides consistently shaped code.
+ </li>
+</ul><!-- END:mainDescription,-vlYpfwIYlF_ZCk5s4Dsqdg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/component.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/component.html
new file mode 100644
index 0000000..a6833fd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/component.html
@@ -0,0 +1,125 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\component.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: component.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0YP18MlgEdmt3adZL5Dmdw CRC: 3406767092 -->Component<!-- END:presentationName,_0YP18MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0YP18MlgEdmt3adZL5Dmdw CRC: 4006056148 -->An encapsulated part of a system that is, ideally, a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of well-defined architecture.<!-- END:briefDescription,_0YP18MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_TZiasMM1EdmSIPI87WLu3g CRC: 3970348652 --><p align="left">
+ The software industry and literature use the term <strong>componen</strong>t to refer to many different things. It is
+ often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote
+ specific characteristics that enable replacement and assembly in larger systems.
+</p>
+<p align="left">
+ Here. we use <em>component</em> to mean <strong>an encapsulated part of a system</strong> that is, ideally, a
+ nontrivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of
+ well-defined architecture. This includes two types of components:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Design component.</strong> A significant encapsulated part of the design that includes design
+ subsystems and, sometimes, significant design classes and design packages.
+ </p>
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Implementation component.</strong> A significant encapsulated part of the implementation, generally
+ code that implements a design component.
+ </p>
+ </div>
+ </li>
+</ul>
+<p align="left">
+ Ideally, the design reflects the implementation; therefore, you can simply refer to <em>components</em>, with each
+ component having a design and an implementation.
+</p>
+<h4 align="left">
+ Component replaceability
+</h4>
+<p align="left">
+ In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
+ interfaces that hide an underlying implementation.
+</p>
+<p align="left">
+ There are other, stronger, kinds of replaceability: .
+</p>
+<div align="left">
+ <ul>
+ <li>
+ <p>
+ <strong>Source file replaceability:</strong> If two classes are implemented in a single source code file,
+ then those classes cannot usually be separately versioned and controlled. However, if a set of files fully
+ implements a single component (and no other component), then the component source files are replaceable.
+ This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
+ source file.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Deployment replaceability:</strong> If two classes are deployed in a single executable file, then
+ each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
+ components to be replaceable during deployment, which allows new versions of the component to be deployed
+ without having to rebuild the other components. This usually means that there is one file or one set of
+ files that deploy the component, and no other component.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Run-time replaceability:</strong> If a component can be redeployed into a running system, then it
+ is referred to as <em>run-time replaceable</em>. This enables you to upgrade software without loss of
+ availability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Location transparency:</strong> Components with network-addressable interfaces are referred to as
+ having <em>location transparency</em>. This allows components to be relocated to other servers or to be
+ replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of
+ components are often referred to as <em>distributed</em> or <em>distributable</em> components.
+ </p>
+ </li>
+ </ul>
+</div>
+<h4 align="left">
+ Component instantiation
+</h4>
+<p align="left">
+ A component may or may not be directly instantiated at run time.
+</p>
+<p align="left">
+ An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
+ component itself does not appear in the implementation; it merely serves as a design that an implementation must
+ follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
+ provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
+</p>
+<p align="left">
+ A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
+ object, which means that a design component has a corresponding construct in the implementation language; therefore, it
+ can be referenced explicitly.
+</p><!-- END:mainDescription,_TZiasMM1EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/component_vm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/component_vm.html
new file mode 100644
index 0000000..2dfcadf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/component_vm.html
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\component_vm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: component_vm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-zfl87vJBFdinDB02ArLXOQ CRC: 2946335115 --><p align="left">
+ The Unified Modeling Language [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">UML05</a>] defines <em>component</em> as follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p>
+ A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment. A component defines its behavior in terms of provided and required interfaces. As such, a
+ component serves as a type, whose conformance is defined by these provided and required interfaces
+ (encompassing both their static as well as dynamic semantics). (See <strong>UML representation</strong> at the
+ end of this section for definitions from earlier versions of UML.)
+ </p>
+ <p>
+ A <em>component</em> is defined as a subtype of structured class. Therefore, a component has attributes and
+ operations, is able to participate in associations and generalizations, and has internal structure and ports.
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ A number of UML standard stereotypes exist that apply to components, including <<subsystem>> to model
+ large-scale components, and <<specification>> and <<realization>> to model components with
+ distinct specification and realization definitions, where one specification may have multiple realizations.
+</p>
+<p align="left">
+ Here, we use the term <em>component </em>in a broader way than the UML definition. Rather than defining
+ components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
+ as desirable characteristics of components. See the section on Component Replaceability.
+</p>
+<h4 align="left">
+ Modeling of components
+</h4>
+<p align="left">
+ The UML component is a modeling construct that provides the following capabilities:
+</p>
+<div align="left">
+ <ul>
+ <li>
+ Group classes to define a larger granularity part of a system
+ </li>
+ <li>
+ Separate the visible interfaces from internal implementation
+ </li>
+ <li>
+ Execute instances run-time
+ </li>
+ </ul>
+</div>
+<p align="left">
+ A component includes <strong>provided</strong> and <strong>required</strong> interfaces that form the basis for wiring
+ components together. A <strong>provided interface</strong> is one that is either implemented directly by the component
+ or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A
+ <strong>required interface</strong> is designated by a usage dependency of the component or one of its realizing
+ classes or subcomponents, or it is the type of a required port.
+</p>
+<p align="left">
+ A component has an external view (or <em>black box</em> view) through its publicly visible properties and operations
+ .Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component
+ itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls
+ explicit. The wiring between components in a system or other context can be structurally defined by using dependencies
+ between component interfaces (typically on component diagrams).
+</p>
+<p align="left">
+ Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in
+ composite structures to specify the role or instance-level collaboration between components. That is the component's
+ internal view (or <em>white-box</em> view) through its private properties and realizing classes or subcomponents. This
+ view shows how the external behavior is realized internally. The mapping between external and internal views is by
+ dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.
+</p>
+<p align="left">
+ The recommendation is to use components as the representation for design subsystems.
+</p>
+<h4 align="left">
+ UML representation
+</h4>
+<p align="left">
+ The definition of <em>component</em> with the UML has changed over time with the release of different versions. The
+ version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the
+ definitions from 1.3 to 2.0 are provided here.
+</p>
+<p align="left">
+ UML 2.0 defined <em>component</em> as the following:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p align="left">
+ ...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment.
+ </p>
+ <p align="left">
+ A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a
+ type whose conformance is defined by these provided and required interfaces (encompassing both their static as
+ well as dynamic semantics).
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ UML 1.5 defined <em>component</em> as the following:
+</p>
+<blockquote>
+ <blockquote>
+ <div align="left">
+ A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of
+ interfaces. A component is typically specified by one or more classes or subcomponents that reside on it and
+ may be implemented by one or more artifacts (e.g., binary, executable, or script files).
+ </div>
+ <div align="left">
+ <p>
+ In UML 1.3 and earlier versions of the UML, the component notation was used to represent files in the
+ implementation. Files are no longer considered components by the latest UML definitions. However, many
+ tools and UML profiles still use the component notation to represent files.
+ </p>
+ </div>
+ </blockquote>
+</blockquote><!-- END:mainDescription,-zfl87vJBFdinDB02ArLXOQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/construction_phase.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/construction_phase.html
new file mode 100644
index 0000000..bea12ca
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/construction_phase.html
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\construction_phase.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: construction_phase.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_48EKsBOMEduCNqgZdt_OaA CRC: 3170083447 -->Construction Phase<!-- END:presentationName,_48EKsBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_48EKsBOMEduCNqgZdt_OaA CRC: 2571844183 -->Third of the four phases in the project lifecycle, Construction focuses on design, implementation, and testing of functionalities to develop a complete system.<!-- END:briefDescription,_48EKsBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-bbpT_BdDRrv6waNI365Qhg CRC: 3573939171 --><p>
+ The purpose in this phase is to complete the development of the system based upon the baselined architecture.
+</p>
+<p>
+ There are objectives for the Construction phase that help us to have cost-efficient development of a complete
+ product - an operational version of your system - that can be deployed in the user community <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ Iteratively develop a complete product that is ready to transition to its user community. Describe remaining
+ requirements, fill in design details, complete the implementation and test the software. Release the first
+ operational version (beta) of the system and determine if users are ready for the application to be deployed.
+ </li>
+ <li>
+ Minimize development costs and achieve some degree of parallelism. Optimize resources and leverage development
+ parallelism between developers or teams of developers, by for example, assigning components that can be developed
+ independently of one another.
+ </li>
+</ol>
+<p>
+ The following table summarizes the Construction phase objectives and what activities address each objective:
+</p>
+<p align="center">
+ <br />
+ <strong>Construction phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Iteratively develop a complete product that is ready to transition to the user community<br />
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/manage_requirements,_eE5nEUbpEduLBN1xMBngqw.html" guid="_eE5nEUbpEduLBN1xMBngqw">Manage Requirements</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/develop_solution,_MWFjoU9HEdudU75l2xOQTw.html" guid="_MWFjoU9HEdudU75l2xOQTw">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/validate_build,_y-3IretQEdqc1LGhiSPqRg.html" guid="_y-3IretQEdqc1LGhiSPqRg">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Minimize development costs and achieve some degree of parallelism<br />
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/develop_solution,_MWFjoU9HEdudU75l2xOQTw.html" guid="_MWFjoU9HEdudU75l2xOQTw">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/validate_build,_y-3IretQEdqc1LGhiSPqRg.html" guid="_y-3IretQEdqc1LGhiSPqRg">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of
+ projects:
+</p>
+<ul>
+ <li>
+ Simple project: One iteration to build the product (to a beta release)
+ </li>
+ <li>
+ More substantial project: One iteration to expose a partial system and one to mature it to beta testing
+ </li>
+ <li>
+ Large project: Three or more iterations, given the size of the project (number of requirements to implement for a
+ beta release)
+ </li>
+</ul><!-- END:mainDescription,-bbpT_BdDRrv6waNI365Qhg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/continuous_integration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/continuous_integration.html
new file mode 100644
index 0000000..88a08b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/continuous_integration.html
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\continuous_integration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: continuous_integration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_B3xkEPD0EdqYgerqi84oCA CRC: 751312288 -->Continuous Integration<!-- END:presentationName,_B3xkEPD0EdqYgerqi84oCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_B3xkEPD0EdqYgerqi84oCA CRC: 3377508991 -->This concept introduces the idea of creating regular (at least daily) integrations in order to reduce integration risks, find bugs earlier, and drive a collaborative work environment.<!-- END:briefDescription,_B3xkEPD0EdqYgerqi84oCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dhAMzNZNWufBnW0fPYQtBA CRC: 1198681502 --><p>
+ Continuous integration is an implementation practice where team members compile and test (integrate) their work
+ frequently (at least daily). Integration errors should be detected as quickly as possible, either from compiler errors
+ or errors reported by the test suite. Ideally the integration is done automatically when an updated version of
+ source code is checked into the configuration management system.
+</p>
+<p>
+ Benefits:
+</p>
+<ol>
+ <li>
+ Improved error detection. Continuous integration enables you to detect and address errors early, often
+ minutes after they’ve been injected into the product. Note that you still need a good test suite.
+ </li>
+ <li>
+ Improved system integration. By integrating continuously throughout your project you know that you can
+ actually build it, thereby mitigating integration surprises at the end of the lifecycle.
+ </li>
+ <li>
+ Reduced technical risk. You always have an up-to-date system against which to test.
+ </li>
+ <li>
+ Reduced management risk. By continuously integrating your system you know exactly how much functionality that
+ you’ve built to date, improving your ability to predict when and if you’re actually going to be able to deliver the
+ necessary functionality.
+ </li>
+ <li>
+ Improved collaboration. Continuous integration enables team members to work together safely. They know
+ that they can make a change to their code, integrate the system, and determine very quickly whether or not their
+ change worked.<br />
+ </li>
+</ol><!-- END:mainDescription,-dhAMzNZNWufBnW0fPYQtBA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_balance.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_balance.html
new file mode 100644
index 0000000..fc95838
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_balance.html
@@ -0,0 +1,178 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\core_principle_balance.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: core_principle_balance.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ssG6MMvpEdqukPpotm3DYg CRC: 2685607669 -->Balance competing priorities to maximize stakeholder value<!-- END:presentationName,_ssG6MMvpEdqukPpotm3DYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ssG6MMvpEdqukPpotm3DYg CRC: 1519387575 -->Develop a solution that maximizes stakeholder benefits and complies with constraints placed on the project.<!-- END:briefDescription,_ssG6MMvpEdqukPpotm3DYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-I4IbR1GW6IFBCdq9SiMUsw CRC: 1335940606 --><h3 style="MARGIN: 12pt 0in 3pt">
+ Introduction
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ Systems are rarely all things to all people. Often, attempts to make them so are wasteful and result in bloated
+ systems.
+</p>
+<p>
+ Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes stakeholder
+ benefits and complies with constraints placed on the project. Achieving balance is a dynamic process because as both
+ the stakeholders and project participants learn more about the system, their priorities and constraints change.
+</p>
+<p>
+ To be successful, stakeholders and the project participants must converge on a clear understanding and agreement of
+ these three factors:
+</p>
+<ul>
+ <li>
+ Problem to be solved
+ </li>
+ <li>
+ Constraints places on the development team (cost, schedule, resources, regulations)
+ </li>
+ <li>
+ Constraints placed on the solution
+ </li>
+</ul>
+<p>
+ Collectively, these three items represent the requirements for the development of the system. The challenge for all
+ project participants is creating a solution that maximizes value delivered to the stakeholders, subject to the
+ constraints. Balance is about making the critical cost-benefit trade-offs between desired features and the subsequent
+ design decisions that define the a<span>rchitecture of the system.</span>
+</p>
+<p>
+ Discovering the balance point is challenging, elusive, and ongoing, because the balance point is dynamic. As the system
+ evolves, stakeholder needs change, new opportunities appear, risks are resolved, new risks appear, and the development
+ team discovers new realities about the system. Change happens throughout the development cycle. Therefore, stakeholders
+ and developers must be prepared to re-evaluate commitments, reset expectations, and adjust plans accordingly as the
+ system evolves.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Know your audience
+</h4>
+<p>
+ You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want.
+</p>
+<p>
+ Therefore, know your stakeholders. Better yet, work closely with them to ensure that you know their needs. Start by
+ identifying all stakeholders, and then maintain open and frequent communication and collaboration between them and the
+ development team.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Separate the problem from the solution
+</h4>
+<p>
+ Too often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve
+ problems, not how to define problems, so that's easier. However, this limits our understanding of the problem, imposes
+ artificial constraints, and makes it difficult to balance trade-offs, or to even know what the trade-offs are.
+</p>
+<p>
+ Therefore, make sure that you understand the problem before you define the solution. By clearly separating the problem
+ (what the customer needs) from the solution (what the system must do), it is easier to maintain the proper focus and
+ easier to accommodate alternate ways of solving the problem.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Create a shared understanding of the domain
+</h4>
+<p>
+ Domain experts often have limited technical expertise; developers, architects and testers often have limited domain
+ expertise; and reviewers and other stakeholders often have limited time to commit to the project and learn the problem
+ domain. As a result, people often have an inconsistent or poor understanding of the problem domain, which causes
+ communication problems and increases the likelihood of delivering poor value to the stakeholders.
+</p>
+<p>
+ Therefore, enhance and share all parties’ understandings of the domain. A concise and shared understanding of the
+ problem domain enhances communication and project effectiveness. Start by defining the problem in the Vision document.
+ As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent
+ shared use of the language of the domain.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Use scenarios and use cases to capture requirements
+</h4>
+<p>
+ Many companies still document requirements as a list of declarative statements, which are sometimes called the ”shall
+ statements.” These lists are often difficult for stakeholders to understand, because they require the end user to read
+ through and mentally translate the list into a visualization of how the requirements will interact with the system. .
+</p>
+<p>
+ Therefore, use scenarios and use cases to capture functional requirements in a form that is easy for stakeholders to
+ understand. Nonfunctional requirements, such as performance, stability, or usability requirements, are important and
+ can be documented in the Supporting Requirements, using traditional techniques.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Establish and maintain agreement on priorities
+</h4>
+<p>
+ Making poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that are
+ never used, or identifying problems late in the project that result in delays and even project failure.
+</p>
+<p>
+ Therefore, prioritize requirements for implementation by regularly working with the stakeholders during product
+ evolution. Make choices that deliver value and reduce risks, while building a system that can evolve.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Make the trade-offs to maximize value
+</h4>
+<p>
+ Cost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the
+ system to the stakeholder, while architecture establishes the cost. The cost of a benefit may influence the
+ stakeholder's perceived value of the benefit.
+</p>
+<p>
+ Therefore, work with the stakeholders and developers to prioritize requirements and develop candidate architectures to
+ implement those solutions. Use the candidate architectures to evaluate the cost of the benefits. Candidate solutions
+ are considered at a high level when determining architectural feasibility. Different architectural perspectives can
+ result in different assessment of cost versus benefit. The candidate architecture that provides the most
+ coverage at the lowest cost is selected for further development.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Manage scope
+</h4>
+<p>
+ Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change will
+ result in a bloated, deficient system and unmet stakeholder needs.
+</p>
+<p>
+ Therefore, manage change while maintaining the agreements with the stakeholders. Modern processes always manage change,
+ continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making
+ trade-offs, and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned throughout
+ the development lifecycle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Know when to stop
+</h4>
+<p>
+ Over-engineering a system not only wastes resources but also leads to an overly complex system.
+</p>
+<p>
+ Therefore, stop developing the system when the desired quality is achieved. Remember that “Quality is conformance to
+ the requirements” <a href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[CRO79]</a>. This is what gives a sense of closure to the practice. Separate the problem
+ from the solution, ensuring that the solution does, indeed, solve the problem. After the critical requirements are
+ implemented and validated, the system is ready for stakeholder acceptance.
+</p><!-- END:mainDescription,-I4IbR1GW6IFBCdq9SiMUsw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_collaborate.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_collaborate.html
new file mode 100644
index 0000000..8d1a90a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_collaborate.html
@@ -0,0 +1,168 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\core_principle_collaborate.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: core_principle_collaborate.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_KkTIsMp7EdqC_NfSivunjA CRC: 958450417 -->Collaborate to align interests and share understanding<!-- END:presentationName,_KkTIsMp7EdqC_NfSivunjA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_KkTIsMp7EdqC_NfSivunjA CRC: 2421836772 -->Develop collaborative practices that foster a healthy team environment. Good collaborative practices align the interests of project participants and help them develop a shared understanding of the project.<!-- END:briefDescription,_KkTIsMp7EdqC_NfSivunjA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-IXfkG-XfnoEo0xgux482Kw CRC: 1884659856 --><h3>
+ Introduction
+</h3>
+<p>
+ Software is created by people with different interests and skills who must work together to create software
+ effectively.
+</p>
+<p>
+ Therefore, develop practices that foster a healthy team environment. A healthy team environment enables effective
+ collaboration, which aligns the interests of project participants (development team, quality assurance, product
+ stakeholders, customers) and helps project participants develop a shared understanding of the project.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Maintain a common understanding
+</h4>
+<p>
+ Project participants require a common understanding of a project to cooperate effectively. Otherwise, disorder sets in,
+ because the team members cannot align their understanding and interests and will work with different purposes.
+</p>
+<p>
+ Be proactive communicating and sharing information with project participants and do not assume that everyone will just
+ find what they need to know or that each person has the same understanding of the project as everyone else. Use work
+ products, such as the Vision, Work Items List, and Requirements to align the understanding between the stakeholders and
+ developers. Use the architecture to focus and align the interests of the developers. At the end of each iteration, get
+ agreement on whether the iteration goals have been reached, and, if not, what actions must be taken.
+</p>
+<h4 style="MARGIN: auto 0in">
+ Foster a high-trust environment
+</h4>
+<p>
+ People who do not feel safe will not communicate their ideas, take the initiative, or admit their ignorance. In these
+ low-trust work environments, activities must be laboriously planned in detailed, carefully supervised, and extensively
+ audited. A team working in a low-trust environment may not be able to keep up with rapid change.
+</p>
+<p>
+ Therefore, take actions that foster a high-trust environment:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Manage by intent.</strong> Create an environment where teams manage themselves, and managers serve as
+ mentors to teams to help them complete their objectives.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Tear down the walls.</strong> Work to remove both the physical and mental barriers that inhibit
+ development of a common understanding among project participants.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Walk a mile (or 1.6 kilometers) in someone else's shoes.</strong> Respect and try to understand the
+ perspectives of others before criticizing their ideas or responding to their criticism.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Respond to conversations with relevance.</strong> People, especially technical workers, often respond
+ with argument or disagreement, which leads to rivalry and the establishment of a pecking order in which only a
+ few people contribute to the discussion. Develop and encourage behavior that values curiosity and relevance
+ over argument and disagreement.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Always look to yourself first for the source of communication problems.</strong> Understand that
+ everyone has a perspective that is largely invisible to the individual (although it is often obvious to
+ everyone else). Develop the habit of identifying the assumptions and prejudices within yourself that lead to
+ argument or lack of communication. Learn to overcome these in the moment of the conversation. This takes
+ practice. There are times when others may be intractable, but often the problem can be addressed by wrestling
+ with your own perspective.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand the constraints of the workplace culture.</strong> Some organizations operate in a way that
+ allows people to admit mistakes, ask questions, and experiment. Some organizations limit these expressions, but
+ they may change, with time and effort. Some organizations have no tolerance for error, and workers put
+ themselves in danger by admitting mistakes or experimenting. Understand your environment and protect yourself
+ accordingly. Understand that low-trust organizations have more problems in achieving their goals and provide a
+ less satisfying environment.
+ </p>
+ </li>
+</ul>
+<h4 style="MARGIN: auto 0in">
+ Share responsibility
+</h4>
+<p>
+ There may be disadvantages for individuals when they work alone. Communication with the team can become sporadic, and
+ then stop. People may get into trouble and not ask for help, or not realize that the team is in trouble and needs their
+ help. Their understanding of the project may become misaligned with the rest of the team. In the worse situations,
+ trust breaks down as individuals see the team working at different purposes to their interests.
+</p>
+<p>
+ Therefore, while individuals have primary responsibility for their work products, responsibility for work products is
+ shared. Nothing is someone else's responsibility. This may mean either taking up slack and working with someone who is
+ lagging for some reason or asking for help. Experienced staff should be extra-vigilant and watch over less-experienced
+ staff, encouraging them to ask for help if necessary.
+</p>
+<h4 style="MARGIN: auto 0in">
+ Learn continuously
+</h4>
+<p>
+ Not only is software development a fast-developing field where technical skills rapidly become obsolete, it is also an
+ empirical process, where software is developed in a manner that sometimes resembles trial and error. Furthermore,
+ software is developed by teams of people who must work together to achieve results.
+</p>
+<p>
+ Therefore, continuously develop both your technical and interpersonal skills. Learn from the examples of your
+ colleagues. Take the opportunity to be both a student of your colleagues, as well as a teacher to them. Always increase
+ your personal ability to overcome your own antagonism toward other team members.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Organize around the architecture
+</h4>
+<br />
+<p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ As projects grow in size, communication between team members becomes increasingly complex.<span style="mso-spacerun: yes"> </span>While all team members understand the overall system, they can focus primarily
+ on the one or more subsystems they are responsible for. Organizing around the architecture also helps with
+ communication by providing the team with a common vocabulary and shared mental model of the system<strong>.</strong>
+ Communication between team members becomes increasingly complex. Therefore, organize the team around the architecture
+ and the vocabulary and shared mental model of the system. However, be watchful that individuals and teams organized
+ this way do not form a so-called <em>silo mentality</em>, where they focus strictly on their subsystems and become
+ ignorant of the other subsystems.
+</p>
+<p>
+ An architecture that reflects the organization’s structure is not evidence that the team has successfully organized
+ around the architecture. If organizations and teams are not organized around the architecture, then the architecture
+ will naturally conform to the organization, as a result of political and cultural influences. In the end, the
+ architecture and the organization will almost always be a reflection of each other. The goal is to guide team
+ organization from the needs of the architecture as much as possible.
+</p><!-- END:mainDescription,-IXfkG-XfnoEo0xgux482Kw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_evolve.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_evolve.html
new file mode 100644
index 0000000..5693c50
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_evolve.html
@@ -0,0 +1,159 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\core_principle_evolve.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: core_principle_evolve.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_GXiogMvoEdqukPpotm3DYg CRC: 1639001128 -->Evolve to continuously obtain feedback and improve<!-- END:presentationName,_GXiogMvoEdqukPpotm3DYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_GXiogMvoEdqukPpotm3DYg CRC: 1435707280 -->Divide the project up into short, time-boxed iterations to demonstrate incremental value and obtain early and continuous feedback.<!-- END:briefDescription,_GXiogMvoEdqukPpotm3DYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-aMD1wQVJLzzlMARfHBdOBQ CRC: 3868629377 --><h3>
+ Introduction
+</h3>
+<p>
+ It is usually not possible to know all stakeholders' needs, be aware of all project risks, comprehend all project
+ technologies, or know how to work with your colleagues. Even if it were possible to know all of these things, they are
+ likely to change over the life of the project. Therefore, divide the project into short, time-boxed iterations to
+ demonstrate incremental value and to get early and continuous feedback.<span style="mso-spacerun: yes"> </span>
+</p>
+<p>
+ The intention behind this principle is to continuously get feedback and to improve both the product and the process of
+ the project team. When you provide structure and create a mindset for continuous feedback and improvement, changes are
+ accommodated more easily, feedback is captured early and often, high-priority risks are confronted early in the
+ project. By constantly identifying and attacking risks, there is more confidence in project progress and quality.
+</p>
+<p>
+ Not only does the product evolve, but the team also finds better ways to work together and get involved with
+ stakeholders.<span style="mso-spacerun: yes"> </span> The process followed by the team can be adjusted accordingly
+ to leverage lessons learned and adjust project pace and needs.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Develop your project in iterations
+</h4>
+<p>
+ Developing a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new
+ knowledge. Worse, it can delay the discovery and mitigation of risks, because development efforts are scheduled later
+ in the lifecycle.
+</p>
+<p>
+ Therefore, divide your project into a series of time-boxed iterations, and plan your project iteratively. This
+ iterative strategy enables you to incrementally deliver capabilities (such as an executable, usable subset of
+ implemented and tested requirements) that can be assessed by stakeholders at the end of each iteration. This provides
+ rapid and timely feedback loops so that issues can be addressed and improvements made at a lower cost. Also, this is
+ accomplished while you still have sufficient budget and time left to do so, and you have not gone so far ahead that
+ major rework is required. Iterative development enables teams to continuously improve software throughout the
+ development <a href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">lifecycle</a>.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Focus iterations on meeting the next management milestone
+</h4>
+<p>
+ Without a focus to bring closure to important project issues, such as stakeholder concurrence regarding scope and
+ proving the proposed architecture, a project can appear to make progress while risks and unresolved issues pile up.
+</p>
+<p>
+ Therefore, divide the project into phases (such as Inception, Elaboration, Construction, and Transition), with each
+ phase having a clearly visible management milestone. The focus of each iteration within a phase is on achieving that
+ milestone. <span style="mso-spacerun: yes"> </span>
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Manage risks
+</h4>
+<p>
+ Deferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such
+ procrastination may lead to investing in the wrong technologies, a bad design, or a set of requirements that may not
+ address stakeholder needs.
+</p>
+<p>
+ Therefore, attack <a href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a> early, or they will attack you. Continuously identify and prioritize risks,
+ and then devise strategies to mitigate them. Determine the focus of iterations based on risks. For example,
+ architecturally significant risks should be addressed early in the project, no later than the end of Elaboration phase,
+ when the architecture has been proven and baselined.
+</p>
+<p>
+ At the beginning of each iteration, the entire team should consider what risks they are facing, and update the risk
+ list. Make it each team member’s and stakeholder’s responsibility to have the courage to speak up and openly discuss
+ risks, as well as to have the courage not to criticize the people who do speak up, even though the risk may point to a
+ flaw in their area of responsibility. For each risk, articulate a plan for tracking and mitigating the risk.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Embrace and manage change
+</h4>
+<p>
+ Change is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will
+ result in a bloated, deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a
+ change is made, the more the change is likely to cost.
+</p>
+<p>
+ Therefore, both embrace and manage change. Embracing change helps you to build a system that addresses stakeholder
+ needs, and managing change allows you to reduce costs and improve predictability of those changes. Changes made early
+ in the project can usually be made with limited cost. As you progress in your project, changes can become increasingly
+ costly.
+</p>
+<p>
+ To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware
+ of the impact that those changes have on the project cost and schedule. Understand the impact of a change in the
+ current phase, and isolate team members from disruptive changes during the current iteration. Change requests are
+ reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration.
+</p>
+<p>
+ If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Measure progress objectively
+</h4>
+<p>
+ If you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding.
+ Uncertainty and change make a software project’s progress difficult to measure objectively, and people have a most
+ amazing ability to believe all is well in the face of catastrophe.
+</p>
+<p>
+ Therefore, get a clear picture of project status by objectively measuring progress. The best measure of progress is the
+ delivery of working software, which is something that you do by taking an evolutionary approach.<span style="mso-spacerun: yes"> </span>You can also define a set of objective <a href="./../../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html" guid="_0mYYkMlgEdmt3adZL5Dmdw">metrics</a> to collect during an iteration (for example, requirements that were
+ implemented and validated, number of defects issued compared with number fixed) and review them as part of the <a href="./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw"><span style="COLOR: windowtext">iteration assessment</span></a>. Do not rely on single metrics. Rather, use a combination of
+ metrics and look for trends.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Continuously re-evaluate what you do
+</h4>
+<p>
+ People make mistakes during a project. If we chose to hide those mistakes, then we risk repeating the same mistakes. In
+ addition, such repressed social dynamic issues can poison the team.
+</p>
+<p>
+ Therefore, on a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team
+ to track status and identify risks and issues. This can be done daily when the team gathers to share the status of
+ individual responsibilities and identify and address issues. At the end of iterations, <a href="./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw"><span style="COLOR: windowtext">assess the status</span></a> of what has been done and look for areas of improvement that can
+ be addressed in the next iteration. Have a retrospective review at the end of the project and capture lessons learned
+ to run future projects in a more efficient way.
+</p>
+<p>
+ If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads
+ to improved project results.
+</p><!-- END:mainDescription,-aMD1wQVJLzzlMARfHBdOBQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_focus.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_focus.html
new file mode 100644
index 0000000..ef6382b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/core_principle_focus.html
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\core_principle_focus.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: core_principle_focus.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9gocwMvoEdqukPpotm3DYg CRC: 3632508815 -->Focus on articulating the architecture<!-- END:presentationName,_9gocwMvoEdqukPpotm3DYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_9gocwMvoEdqukPpotm3DYg CRC: 3608346178 -->Articulate essential technical decisions through a growing architecture.<!-- END:briefDescription,_9gocwMvoEdqukPpotm3DYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-HTMJFV29MTZkKWqnIo01Gg CRC: 1677474928 --><h3>
+ Introduction
+</h3>
+<p>
+ Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
+ proves difficult to evolve, reuse, or integrate without substantial rework. It is also difficult to organize the team
+ or communicate ideas without the common technical focus that the architecture provides.
+</p>
+<p>
+ Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
+ essential technical decisions through the growing architecture.
+</p>
+<h3>
+ Practices
+</h3>
+<p>
+ The next sections describe the practices associated with this principle.
+</p>
+<h4>
+ Create the architecture for what you know today
+</h4>
+<p>
+ As Albert Einstein said, make everything as simple as possible but no simpler. Software projects are
+ resource-constrained, and the desire of developers to create elegant solutions may lead to a system of greater
+ complexity than the stakeholder requires. Efforts to future-proof a system in a turbulent or uncertain environment will
+ likely lead to code bloat , thus increasing overall cost with little actual benefit to show for it.
+</p>
+<p>
+ Therefore, create architectures that address the stakeholder’s real needs, and provide appropriate flexibility and
+ speed for the requirements as they are known today. Avoid the desire, no matter how well intentioned, to speculate on
+ future requirements and thereby over-engineer the architecture: if you have the skill to architect something today,
+ then clearly you must also have the skill to architect it tomorrow when you actually need to.
+</p>
+<h4>
+ Cope with complexity by raising the level of abstraction
+</h4>
+<p>
+ Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it becomes
+ difficult for the team to develop a common understanding of the system, because it is hard to see the bigger picture.
+</p>
+<p>
+ Therefore, use models to raise the level of abstraction to focus on important high-level issues, such as relationships
+ and patterns, rather than getting bogged down in details. Modeling raises the level of abstraction and allows the
+ system to be more easily understood from different perspectives.
+</p>
+<h4>
+ Let the problem drive the solution
+</h4>
+<p>
+ The architecture may become difficult to maintain and adapt to new stakeholder needs when technology, rather than the
+ problem, drives the solution.
+</p>
+<p>
+ Therefore, let the needs of the stakeholders guide the architecture, instead.
+</p>
+<h4>
+ Organize the architecture into loosely coupled, highly cohesive components
+</h4>
+<p>
+ Tight coupling between components makes a system fragile and difficult to understand. Software is expensive to create,
+ so if existing components can be reused, that may reduce effort required to create a system.
+</p>
+<p>
+ Therefore, organize the architecture of the system into components that to maximize cohesion and minimize coupling.
+ This improves comprehension, increases flexibility, and increases opportunities for re-use.
+</p>
+<h4>
+ Reuse existing assets
+</h4>
+<p>
+ It is wasteful to build what you can simply reuse, download, or even buy.
+</p>
+<p>
+ Therefore, make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those
+ assets do not exactly meet their needs or those assets are of poor quality. Be prepared to balance the savings you can
+ realize using an existing asset, even if the asset requires distorting the architecture or relaxing a constraint.
+</p>
+<h4>
+ Leverage the architecture as a collaborative tool
+</h4>
+<p>
+ Lack of a common understanding by developers about a system leads to indecision and contrary opinions among developers
+ and can quickly paralyze the project. Developers may have different mental models of the system and work at cross
+ purposes to each other.
+</p>
+<p>
+ Therefore, create and evolve the system architecture with the intention of using it to align the developer’s competing
+ mental models of the system. A good architecture facilitates collaboration by providing a common vocabulary for all
+ discussions regarding the system under development.
+</p><!-- END:mainDescription,-HTMJFV29MTZkKWqnIo01Gg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/design_mechanism.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/design_mechanism.html
new file mode 100644
index 0000000..1e0d382
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/design_mechanism.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\design_mechanism.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design_mechanism.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_w2ACwA4LEduibvKwrGxWxA CRC: 2407792499 -->Design Mechanism<!-- END:presentationName,_w2ACwA4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_w2ACwA4LEduibvKwrGxWxA CRC: 3167479449 -->A Design Mechanism is a concrete representation of an Architectural Mechanism.<!-- END:briefDescription,_w2ACwA4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-EG22TRyJ5TDKW6U88AXfhw CRC: 1756450521 --><p align="left">
+ A Design Mechanism is a concrete representation of an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. It is refined from an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a> and is further refined into an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/implementation_mechanism,_0LcUkA4LEduibvKwrGxWxA.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a> as the design becomes more detailed.
+</p>
+<p align="left">
+ Design Mechanisms can be represented as specific design patterns and frameworks in the <a class="elementLink"
+ href="./../../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. They are used to guide development (see <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Using Patterns</a>). Design Mechanisms should still be relatively independent of
+ implementation but provide enough detailed information for implementation choices to be made and software to be
+ developed with confidence.
+</p>
+<p align="left">
+ See <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/example_design_mechanisms,_4k_Hsg4LEduibvKwrGxWxA.html"
+ guid="_4k_Hsg4LEduibvKwrGxWxA">Example: Design Mechanisms</a>.
+</p><!-- END:mainDescription,-EG22TRyJ5TDKW6U88AXfhw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/developer_testing.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/developer_testing.html
new file mode 100644
index 0000000..8c6350b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/developer_testing.html
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\developer_testing.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: developer_testing.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_aFeZgJquEdukqcRKZBQN9w CRC: 302200055 -->Developer Testing<!-- END:presentationName,_aFeZgJquEdukqcRKZBQN9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_aFeZgJquEdukqcRKZBQN9w CRC: 3534768133 -->Developers regression test their code on a continuous basis to ensure that it works as expected.<!-- END:briefDescription,_aFeZgJquEdukqcRKZBQN9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Ff1JwbrGt1laexkOB6ZM1Q CRC: 2975183953 --><p>
+ Developer testing is the act of regression testing source code by developers. This is sometimes called "unit
+ regression testing" but many developer tests go beyond unit testing to address integration testing instead.
+</p>
+<h3>
+ Testing Philosophies
+</h3>
+<p>
+ Here are some important philosophies with regard to developer testing:
+</p>
+<ol>
+ <li>
+ The goal is to find defects. Successful tests find bugs, but correcting the bugs falls into other areas.
+ </li>
+ <li>
+ Test early and often. The cost of change rises exponentially the longer it takes to find and then remove a
+ defect. The implication is that you want to test as early as possible (the earliest you could possibly test is
+ first, see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw.html"
+ guid="_0Y6kUMlgEdmt3adZL5Dmdw">Concept: Test-first Design</a>).
+ </li>
+ <li>
+ Testing builds confidence. Many people fear making a change to their code because they are afraid that they will
+ break it, but with a full test suite in place if you do break something you know you will detect it and then fix
+ it.
+ </li>
+ <li>
+ One test is worth a thousand opinions. You can say that your application works, but until you show the test
+ results you might not be believed.
+ </li>
+ <li>
+ Test to the risk. The riskier something is, the more it needs to be reviewed and tested. In other words you should
+ invest significant effort testing in the algorithm for estimating radiation doses but nowhere near as much effort
+ testing the "change font size" function of the same application.
+ </li>
+ <li>
+ You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of
+ this guidance is testing code.
+ </li>
+</ol>
+<h3>
+ Qualities of a Good Developer Test
+</h3>
+These are the qualities of a good developer test:
+<ul class="noindent">
+ <li>
+ It runs fast. It has short setup, run time, and clean-up.
+ </li>
+ <li>
+ It runs in isolation. You should be able to reorder your tests.
+ </li>
+ <li>
+ It is understandable. Good tests have consistent and informative names and use data that makes them easy to read
+ and to understand.
+ </li>
+ <li>
+ It uses real data. E.g. Use copies of production data when appropriate, but remember that you'll also have to
+ create some specific "artificial" test data as well.
+ </li>
+ <li>
+ It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and
+ one only issue.
+ </li>
+</ul>
+<h3>
+ Approaches for Test Setup
+</h3>
+<p>
+ To successfully run a test, the system must be in a known state. To do this you will need objects or components
+ in memory, rows in your database, etc. that you will test against. The easiest approach is to hardcode the
+ required data and the setup code within the test itself. The primary advantage is that all the information
+ that you need about the test is in one place and that the test is potentially self-sufficient.
+</p>
+<p>
+ Another approach is to define an external data set which is loaded into memory or into the database at the
+ beginning of the test run. There are several advantages to this approach:
+</p>
+<ul>
+ <li>
+ It decouples the test data from the test.
+ </li>
+ <li>
+ More than one test can use the same data set.
+ </li>
+ <li>
+ It is easy to modify and/or multiply the test data.
+ </li>
+</ul>
+<p>
+ There are some disadvantages to this approach:
+</p>
+<ul>
+ <li>
+ Increased complexity for maintaining the external data
+ </li>
+ <li>
+ Potential coupling between test cases. When they share a common test data bed it becomes very easy to
+ write tests that depend on other tests running first, thereby coupling them together.<br />
+ </li>
+</ul>
+<h3>
+ Coding for Testability
+</h3>
+<p>
+ Add <a class="elementLink"
+ href="./../../../openup_basic/guidances/termdefinitions/code_instrumentation,_JiqnEJt1EdutoZjlV3a4Lg.html"
+ guid="_JiqnEJt1EdutoZjlV3a4Lg">Code Instrumentation</a> for testing and debugging. Pay special attention to the
+ implementation of the observation/control points, such as critical functions or objects, as these aspects
+ might need special support that has to be implemented in the component under test.
+</p>
+<h3>
+ Reviewing Tests
+</h3>
+<p>
+ If a test will be long-lived, ask a person with less inside knowledge of the component to run it and check if there is
+ enough support information. Review it with other people within the development team and other interested parties as
+ needed.
+</p><!-- END:mainDescription,-Ff1JwbrGt1laexkOB6ZM1Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/elaboration_phase.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/elaboration_phase.html
new file mode 100644
index 0000000..3d7746a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/elaboration_phase.html
@@ -0,0 +1,133 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\elaboration_phase.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: elaboration_phase.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2plxwBOMEduCNqgZdt_OaA CRC: 1952986795 -->Elaboration Phase<!-- END:presentationName,_2plxwBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_2plxwBOMEduCNqgZdt_OaA CRC: 155111990 -->Second of four phases in the project lifecycle, when architecturally significant risks are addressed.<!-- END:briefDescription,_2plxwBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-F-eWIBzxEXE1jygbN3nrrQ CRC: 2213148193 --><p>
+ The purpose of this phase is to establish the baseline of the architecture of the system and provide a stable basis for
+ the bulk of the development effort in the next phase.
+</p>
+<p>
+ There are objectives for the Elaboration phase that help you address risks associated with requirements, architecture,
+ costs, and schedule <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Get a more detailed understanding of the requirements.</strong> Having a good understanding of the
+ majority of requirements allows you to create a more detailed plan and to get buy-in from stakeholders. Be sure
+ to gain an in-depth understanding of the most critical requirements to be validated by the architecture.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design, implement, validate, and establish the baseline for the architecture.</strong> Design,
+ implement, and test a skeleton structure of the system. Although the functionality is not complete yet, most of
+ the interfaces between the building blocks are implemented and tested. This is referred to <strong>an
+ executable architecture</strong>.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Mitigate essential risks, and produce accurate schedule and cost estimates.</strong> Many technical
+ risks are addressed as a result of detailing the requirements and of designing, implementing, and testing the
+ architecture. Refine and detail the high-level project plan.
+ </p>
+ </li>
+</ul>
+<p>
+ The following table summarizes the Elaboration phase objectives and what activities address each objective:
+</p>
+<p align="center">
+ <strong>Elaboration phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Get a more detailed understanding of the requirements
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0ruyoclgEdmt3adZL5Dmdw.html" guid="_0ruyoclgEdmt3adZL5Dmdw">Manage Requirements</a> <br />
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Design, implement, validate, and baseline an architecture
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../define_architecture,_0rcewclgEdmt3adZL5Dmdw.html" guid="_0rcewclgEdmt3adZL5Dmdw">Define the Architecture</a><br />
+ <a class="elementLinkWithUserText" href="./../../../develop_requirement_within_context,_WrXvwPinEdmugcVr9AdHjQ.html" guid="_WrXvwPinEdmugcVr9AdHjQ">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0rilYclgEdmt3adZL5Dmdw.html" guid="_0rilYclgEdmt3adZL5Dmdw">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Mitigate essential risks, and produce accurate schedule and cost estimates
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a> <br />
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ The number of iterations in the Elaboration phase is dependent on, but not limited to, factors such as green-field
+ development versus maintenance cycle, unprecedented system versus well-known technology and architecture, and so on.
+</p>
+<p>
+ Typically, on the first iteration, you should design, implement, and test a small number of critical scenarios to
+ identify what type of architecture and architectural mechanisms you need, so you can mitigate the most crucial risks.
+ You also detail high-risk requirements that have to be addressed early in the project. You test enough to validate that
+ the architectural risks are mitigated.
+</p>
+<p>
+ On the following iterations, you fix whatever was not right from the previous iteration. You design, implement, and
+ test the remaining architecturally significant scenarios, ensuring that you check all major areas of the system
+ (architectural coverage), so potential hidden risks arise as early as possible. <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>
+</p>
+<p>
+ <br />
+</p><!-- END:mainDescription,-F-eWIBzxEXE1jygbN3nrrQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/entity_control_boundary_pattern.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/entity_control_boundary_pattern.html
new file mode 100644
index 0000000..53aeb25
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/entity_control_boundary_pattern.html
@@ -0,0 +1,206 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\entity_control_boundary_pattern.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: entity_control_boundary_pattern.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uF-QYEAhEdq_UJTvM1DM2Q CRC: 3808310074 -->Entity-Control-Boundary Pattern<!-- END:presentationName,_uF-QYEAhEdq_UJTvM1DM2Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_uF-QYEAhEdq_UJTvM1DM2Q CRC: 2125714211 -->This concept introduces a pattern that provides a starting point for the distribution of responsibilities to a set of interacting design elements based on three key perspectives in a collaboration.<!-- END:briefDescription,_uF-QYEAhEdq_UJTvM1DM2Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ CRC: 2361721321 --><p>
+ When identifying the elements for some scenario of system behavior, you can align each participating element with one
+ of three key perspectives: Entity, Control, or Boundary.
+</p>
+<p>
+ This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>] among other places), but the Entity Control Boundary pattern is not solely
+ appropriate for dealing with user interfaces and it gives the controller a slightly different role to play.
+</p>
+<h5>
+ ECB Pattern Example
+</h5>
+<p>
+ <img height="233" alt="" src="./resources/EBCDiagram.JPG" width="493" />
+</p>
+<h3>
+ Entity Elements
+</h3>
+<p>
+ An entity is a long-lived, passive element that is responsible for some meaningful chunk of information. This is not to
+ say that entities are "data" while other design elements are "function". Entities perform behavior organized
+ around some cohesive amount of data.
+</p>
+<p>
+ An example entity for a customer service application would be a Customer entity that manages all information about a
+ customer. A design element for this entity would include data on the customer, behavior to manage the data,
+ behavior to validate customer information and perform other business calculations such as "is this customer
+ allowed to purchase product X?"
+</p>
+<p>
+ The identification of the entities as part of this pattern can be done many times at different levels of abstraction
+ from the code, at different levels of granularity in size, and from the perspectives of different contexts. For
+ example you could do an analysis pass on a scenario of creating a marketing campaign and identify the customer element
+ with various customer data elements such as name and address plus various required behaviors such as the management of
+ the name and address data and the ability to rate the customer based on some algorithm (such an application
+ of this pattern would be abstract from code, coarse-grained, and have no specific context). Later you could do a
+ pass on the same scenario applying an architectural mechanism for database access that breaks the address out into its
+ own element, moves the responsibility for storing and retrieving customers to a new control element, and identifies
+ some specific database decisions such as the usage of primary keys in the entities (such an application of
+ this pattern would be closer to the code, finer-grained, and aligned with a database context).
+</p>
+<h3>
+ Control Elements
+</h3>
+<p>
+ A control element manages the flow of interaction of the scenario. A control element could manage the end-to-end
+ behavior of a scenario or it could manage the interactions between a subset of the elements. Behavior and
+ business rules relating to the information relevant to the scenario should be assigned to the entities; the control
+ elements are just responsible for the flow of the scenario.
+</p>
+<p>
+ An example control element for a customer service application would be CreateMarketingCapmpaign. This
+ design element would be responsive to certain front-end boundary elements and would collaborate with other
+ entities, control elements, and back-end boundary elements to support the creation of a marketing campaign.
+</p>
+<p>
+ As with the entity example above, there might be many passes over the identification of control elements. A first
+ pass might be an analysis pass that identifies one control element for a scenario with behavior to make sure the
+ design can support the flow of events, a subsequent pass might find controllers to manage reusable collaborations
+ of low level elements that will map to a specific code unit to be written.
+</p>
+<h3>
+ Boundary Elements
+</h3>
+<p>
+ A boundary element lies on the periphery of a system or subsystem, but within it. For any scenario being considered
+ either across the whole system or within some subsystem, some boundary elements will be "front-end" elements that
+ accept input from outside the area under design and other elements will be "back-end" managing communication to
+ supporting elements outside the system or subsystem.
+</p>
+<p>
+ Two example boundary elements for a customer service application might be a front-end MarketingCampaignForm and a
+ back-end BugdetSystem element. The MarketingCampaignForm would manage the exchange of information between a user
+ and the system and the BugdetSystem would manage the exchange of information between the system and an external system
+ that manages budgets.
+</p>
+<p>
+ An analysis pass could identify one boundary element for each external relevant to a scenario; subsequently these could
+ be broken down into multiple boundary elements or small communities made up of collaborating elements of
+ all three stereotypes.
+</p>
+<h3>
+ Walking the Scenario
+</h3>
+<p>
+ One can walk through a scenario initiated by something outside the bounds of the system or subsystem being designed and
+ distribute the responsibility to perform behavior supporting the scenario to the elements identified of each
+ type. The appropriate design element responsible for each action in the scenario will be as described in the
+ definition of each of the element types described above.
+</p>
+<p>
+ In addition to identifying the behavior necessary to perform the scenario, the initiation of this behavior from design
+ element to design element identifies the necessary relationships. There are certain
+ appropriate relations between the participating elements. An element can communicate to other elements
+ of the same kind. Control elements can communicate with each of the other two kinds, but entities and
+ boundary elements should not directly communicate.
+</p>
+<p>
+ The table below shows appropriate links between design elements.
+</p>
+<table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ <center>
+ Entity
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Boundary
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Control
+ </center>
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ Entity
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Boundary
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Control
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ By applying this pattern, a robust design can be put together that identifies the elements, behavior, and
+ relationships necessary to support a scenario.
+</p><!-- END:mainDescription,-awaQ_2dwhGyKRoVKQ-esPQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/failure_analysis_rpt_creation_2.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/failure_analysis_rpt_creation_2.html
new file mode 100644
index 0000000..35bd84e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/failure_analysis_rpt_creation_2.html
@@ -0,0 +1,102 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\failure_analysis_rpt_creation 2.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: failure_analysis_rpt_creation 2.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0jhR0MlgEdmt3adZL5Dmdw CRC: 837252612 -->Failure Analysis and Report Creation<!-- END:presentationName,_0jhR0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0jhR0MlgEdmt3adZL5Dmdw CRC: 1652321843 -->This concept addresses how to conduct failure analysis based on the execution of tests. The result of this analysis can take the form of a failure analysis report.<!-- END:briefDescription,_0jhR0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-9gUpkUYqONF3x8UWwAO_zw CRC: 3869394487 --><h3>
+ Introduction
+</h3>
+<p>
+ During testing, you will encounter failures related to the execution of your tests in different forms, such as code
+ defects, user errors, program malfunctions, and general problems. This concept discusses some ways to conduct
+ failure analysis and then to report your findings.
+</p>
+<h3>
+ Failure Analysis
+</h3>
+<p>
+ After you have run your tests, it is good practice to identify inputs for review of the results of the testing effort.
+ Some likely sources are defects that occurred during the execution of test scripts, change request metrics, and test
+ log details.
+</p>
+<p>
+ Running test scripts results in errors of different kinds such as uncovered defects, unexpected behavior, or general
+ failure of the test script to run properly. When you run test scripts, one of the most important things to do is to
+ identify causes and effects of failure. It is important to differentiate failures in the system under test from
+ those related to the tests themselves.
+</p>
+<p>
+ Change request metrics are useful in analyzing and correcting failures in the testing. Select metrics that will
+ facilitate creation of incident reports from a collection of change requests.
+</p>
+<p>
+ Change request metrics that you may find useful in your failure analysis include:
+</p>
+<ul>
+ <li>
+ test coverage
+ </li>
+ <li>
+ priority
+ </li>
+ <li>
+ impact
+ </li>
+ <li>
+ defect trends
+ </li>
+ <li>
+ density
+ </li>
+</ul>
+<p>
+ Finally, one of the most critical sources of your failure analysis is the test log. Start by gathering the test log's
+ output during the implementation and execution of the tests. Relevant logs might come from many sources; they might be
+ captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines your
+ team has developed, output from the target test items themselves, and recorded manually be the tester. Gather all of
+ the available test log sources and examine their content. Check that all the scheduled testing executed to completion,
+ and that all the needed tests have been scheduled.
+</p>
+<h3>
+ Self-Documenting Tests
+</h3>
+<p>
+ For automated tests it is a best practice for the test itself to examine the results and clearly report itself as
+ passing or failing. This provides the most efficient way to run tests such that whole suites of tests can be run with
+ each test in turn determining whether it has passed or failed without the need for human intervention. When authoring
+ self-documenting tests, take extra care to ensure that the analysis of the results considers all possibilities.
+</p>
+<h3>
+ Recording Your Findings
+</h3>
+<p>
+ Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
+ your findings in a report. There are several factors that go into deciding whether to record your failure analysis in a
+ report. Some of the key factors include: level of testing formality, complexity of the testing effort, and the need to
+ communicate the testing results to the entire development team. In less formal environments, it may be sufficient to
+ record your failure analysis in a test evaluation summary.
+</p><!-- END:mainDescription,-9gUpkUYqONF3x8UWwAO_zw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/implementation_mechanism.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/implementation_mechanism.html
new file mode 100644
index 0000000..befd7bf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/implementation_mechanism.html
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\implementation_mechanism.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implementation_mechanism.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0LcUkA4LEduibvKwrGxWxA CRC: 3888942802 -->Implementation Mechanism<!-- END:presentationName,_0LcUkA4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0LcUkA4LEduibvKwrGxWxA CRC: 1293779744 -->A representation of an Architecture Mechanism that uses a specific programming language or product.<!-- END:briefDescription,_0LcUkA4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Rex8oOBv985RruZNrCW0rg CRC: 4178447630 --><p>
+ An Implementation Mechanism is a refinement of a corresponding Design Mechanism that uses, for example, a particular
+ programming language and other implementation technology (such as a particular vendor's middleware product). An
+ Implementation Mechanism may instantiate one or more idioms or implementation patterns.
+</p>
+<p>
+ Review these points when you are considering Implementation Mechanisms:
+</p>
+<ul>
+ <li>
+ <p>
+ <b>Determine the ranges of characteristics.</b> Take the characteristics that you identified for the Design
+ Mechanisms into consideration to determine reasonable, economical, or feasible ranges of values to use in the
+ Implementation Mechanism candidate.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Consider the cost of purchased components</b>. For Implementation Mechanism candidates, consider the cost of
+ licensing, the maturity of the product, your history or relationship with the vendor, support, and so forth in
+ addition to purely technical criteria.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Conduct a search for the right components, or build the components.</b> You will often find that there is no
+ apparently suitable Implementation Mechanism for a particular Design Mechanism. This will either trigger a
+ search for the right product or make the need for in-house development apparent. You may also find that some
+ Implementation Mechanisms are not used at all.<br />
+ <br />
+ The choice of Implementation Mechanisms is based not only on a good match for the technical characteristics,
+ but also on the non-technical characteristics, such as cost. Some of the choices may be provisional. Almost all
+ have some risks attached to them. Performance, robustness, and scalability are nearly always concerns and must
+ be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype.
+ </p>
+ </li>
+</ul><!-- END:mainDescription,-Rex8oOBv985RruZNrCW0rg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/inception_phase.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/inception_phase.html
new file mode 100644
index 0000000..883f6da
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/inception_phase.html
@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\inception_phase.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: inception_phase.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0hmKgBOMEduCNqgZdt_OaA CRC: 3173308017 -->Inception Phase<!-- END:presentationName,_0hmKgBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0hmKgBOMEduCNqgZdt_OaA CRC: 1262818545 -->First of the four phases in the project lifecycle, it is about understanding the project scope and objectives and getting enough information to confirm that the project should proceed - or convince you that it should not.<!-- END:briefDescription,_0hmKgBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-GRJW_KNOJoEQF3r6lmBrEw CRC: 3964623620 --><p>
+ The purpose in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the
+ project.
+</p>
+<p>
+ There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the
+ intended solution <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Understand what to build.</strong> Determine the <a class="elementLinkWithUserText" href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>, the scope of the system, and its boundaries. Identify who is
+ interested in this system and why (see <a class="elementLinkWithUserText" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Identify key system functionality.</strong> Decide which requirements are most critical.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Determine at least one possible solution.</strong> Identify at least one candidate architecture and its
+ feasibility.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand</strong> the cost, schedule, and risks associated with the project.
+ </p>
+ </li>
+</ol>
+<p>
+ The following table summarizes the Inception phase objectives and what activities address each objective:
+</p>
+<p align="center">
+ <strong>Inception phase objectives and activities</strong>
+</p>
+<table cellspacing="1" cellpadding="0" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ <b>Phase objectives</b>
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <b>Activities that address objectives</b>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Understand what to build
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0okw8clgEdmt3adZL5Dmdw.html" guid="_0okw8clgEdmt3adZL5Dmdw">Manage Requirements</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Identify key system functionality
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../initiate_project,_0oSdE8lgEdmt3adZL5Dmdw.html" guid="_0oSdE8lgEdmt3adZL5Dmdw">Initiate Project</a><br />
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0okw8clgEdmt3adZL5Dmdw.html" guid="_0okw8clgEdmt3adZL5Dmdw">Manage Requirements</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Determine at least one possible solution
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../determine_architectural_feasibility,_0oreoclgEdmt3adZL5Dmdw.html" guid="_0oreoclgEdmt3adZL5Dmdw">Determine Architectural Feasibility</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Understand the cost, schedule, and risks associated with the project
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../initiate_project,_0oSdE8lgEdmt3adZL5Dmdw.html" guid="_0oSdE8lgEdmt3adZL5Dmdw">Initiate Project</a><br />
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ Projects may have one or more iterations in the Inception phase. Among reasons for multiple iterations in Inception,
+ you find:
+</p>
+<ul>
+ <li>
+ Project is large, and it is hard to define its scope.
+ </li>
+ <li>
+ Unprecedented system.
+ </li>
+ <li>
+ Too many stakeholders with competing needs and complex relationships.
+ </li>
+ <li>
+ Major technical risks demand the creation of a prototype or proof of concept.
+ </li>
+</ul>
+<br /><!-- END:mainDescription,-GRJW_KNOJoEQF3r6lmBrEw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/iteration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/iteration.html
new file mode 100644
index 0000000..d40599b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/iteration.html
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\iteration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_lam4ADkBEduxovfWMDsntw CRC: 1814057918 -->Iteration<!-- END:presentationName,_lam4ADkBEduxovfWMDsntw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_lam4ADkBEduxovfWMDsntw CRC: 2358982076 -->An iteration is a set period of time within a project in which you produce a stable, executable version of the product, together with any other supporting documentation, install scripts, or similar, necessary to use this release. Also referred to as a cycle or a timebox.<!-- END:briefDescription,_lam4ADkBEduxovfWMDsntw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A CRC: 2553426250 --><H3>What is an Iteration </H3>
+<P>An iteration is a set period of time within a project in which you produce a stable, executable version of the product, together with any other supporting documentation, install scripts, or similar, necessary to use this release. The executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, get feedback on how they are doing so that they can improve their understanding of what needs to be done, and how to do it, Each iteration builds upon the results of previous iteration, and will produce a product increment one step closer to the final product. Iterations are timeboxed, meaning the schedule for an iteration should be regarded as fixed, and the scope of the iteration's content actively managed to meet that schedule. </P>
+<P>At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates. </P>
+<P>Iterative development is very disciplined: the iteration length is fixed; the objectives of iterations are carefully planned; the evaluation criteria are established when each iteration is planned; and the tasks and responsibilities of participants are well defined. Additionally, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this too is done in a structured fashion. </P>
+<P>Each iteration should address the most critical risks, and implement the highest-priority Work Items. This ensures that each iteration adds maximum stakeholder value, while reducing uncertainty. Iterative development is typically combined with frequent or continuous integration: as unit-tested components become available, they are integrated, then a build is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the iteration proceeds, towards the goals set when the iteration was planned. Regular builds, such as daily or more frequent builds, let you break down the integration and test issues and spread them across the development cycle. These issues have often been the downfall of large projects because all problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team. </P>
+<H3>What Problem Do Iterations Address? </H3>
+<P>Today’s software applications are too complex to allow you to sequentially define the requirements, come up with an architecture and design, do an implementation, carry out testing, and get it all right. Whether you use waterfall or iterative development approaches, your initial requirements, architecture, design, and code will be suboptimal. With waterfall development, you typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is too costly to make them. By contrast, dividing the project into a series of time-boxed iterations allows you to deliver capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely feedback loops enabling issues to be addressed and improvements made at a lower cost while budget and time still allow, and before the project has gone so far ahead that major rework is required. </P>
+<H3>Iteration Length </H3>
+<P>Iterations are typically 4 weeks long, although some teams will work with iterations as short as a week or as long as six weeks. For factors driving iteration length, see Table X. </P>
+<P><STRONG><EM>Table X. Factors Impacting Iteration Length.</EM></STRONG><BR> <BR></P>
+<TABLE style="WIDTH: 547px; HEIGHT: 356px" cellSpacing=2 cellPadding=2 width=547 border=1>
+<TBODY>
+<TR>
+<TH scope=col>Factors leading to reduced iteration length </TH>
+<TH scope=col>Factors leading to increased iteration length </TH></TR>
+<TR>
+<TD>Small teams </TD>
+<TD>Large teams </TD></TR>
+<TR>
+<TD>Collocated teams </TD>
+<TD>Distributed teams </TD></TR>
+<TR>
+<TD>Strong configuration management system </TD>
+<TD>Poor configuration management system </TD></TR>
+<TR>
+<TD>Dedicated, full-time resources </TD>
+<TD>Matrixed or part-time resources </TD></TR>
+<TR>
+<TD>Automated testing </TD>
+<TD>Lack of automated testing </TD></TR>
+<TR>
+<TD>Integrated tool environment </TD>
+<TD>Absence of good automation and tool integration </TD></TR>
+<TR>
+<TD>Team experienced with iterative development </TD>
+<TD>Team inexperienced with iterative development </TD></TR>
+<TR>
+<TD>Fast decision making </TD>
+<TD>Policies and bureaucracy preventing fast decision making </TD></TR>
+<TR>
+<TD>Unclear requirements </TD>
+<TD>Well-understood requirements </TD></TR>
+<TR>
+<TD>Unclear or brittle architecture </TD>
+<TD>Well-defined and stable architecture </TD></TR>
+<TR>
+<TD>New and poorly understood technology </TD>
+<TD>Well-understood technology </TD></TR></TBODY></TABLE><BR><BR>
+<H3>Why Iterate? </H3>
+<P>The iterative approach has proven itself superior to the waterfall approach for a number of reasons: </P>
+<UL>
+<LI>You are more likely to build an application that addresses user needs. Early specification of requirements often leads to unused features. The Standish Group has researched thousands of application development projects and has found that more than 45 percent of features are never used, while another 19 percent are used rarely (see Figure 2.3). In other words, typically more than half of the development effort is wasted on developing nonessential capabilities. To avoid this problem, you need to involve the customer in the development project and use an iterative approach that allows you to implement and validate the capabilities deemed most essential in each iteration. This approach allows not only early validation of key capabilities but also addition of new capabilities late in the project.
+<LI>Integration is not one “big bang” at the end of a project. Leaving integration to the end results in time- and budget-consuming rework. To avoid this, an iterative approach breaks a project down into smaller iterations, each evolving executable code that is continuously integrated to enable rapid feedback and minimize later revision.
+<LI>Risks are usually discovered or addressed during early iterations. With the iterative approach, risks are more likely to be identified and addressed in early iterations. As an example, if there is a risk that a stakeholder will not be happy with the functionality you are developing, iterative development will encourage you to implement the most essential capabilities partially and demonstrate them to key stakeholders to make sure that you are on the right track.
+<LI>Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all lifecycle activities, from requirements capture and test definition to development, implementation, and testing. Consequently, they can make sure they have the tools, skills, organizational structure, and so on to work effectively.
+<LI>Management has a way of making tactical changes to the product. Management can make changes to the product along the way—to compete with other new products, for example. Iterative development allows you to evolve partial implementations of the end product quickly and use these for quick release of a reduced-scope product to counter a competitor's move.
+<LI>Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in iterations than to recognize them at the beginning. Discussions and reviews of the design in early iterations allow team members to spot potential opportunities for reuse and then develop a mature common code for these opportunities in subsequent iterations.
+<LI>Defects can be found and corrected over several iterations. This capability results in a robust architecture and a high-quality application. Flaws are detected in early iterations, rather than during a massive testing phase at the end. Performance bottlenecks are discovered while they can still be addressed instead of creating panic on the eve of delivery.
+<LI>Project personnel are better used. Many organizations match their use of a waterfall approach with a pipeline organization: the analysts send the completed requirements to designers, who send a completed design to programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of errors and misunderstandings and make people feel less responsible for the final product. An iterative process encourages widening the scope of expertise of the team members, allowing them to play many roles and thus enabling a project manager to make better use of the available staff and simultaneously remove problematic handoffs.
+<LI>Team members learn along the way. The project members have several opportunities within a development cycle to learn from their mistakes and improve their skills from one iteration to another. More training opportunities can be discovered as a result of assessing the earlier iterations.
+<LI>The development process itself is improved and refined along the way. The end of iteration assessment not only looks at the project status from a product or scheduling perspective but also analyzes what can be improved in the next iteration in both the organization and the process. One technique for doing so is to hold a retrospective. </LI></UL><BR><SPAN class=E1><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><STRONG><IMG height=307 alt="45 percent of featues implemented are never ever used" src="./resources/iteration_1.GIF" width=489></STRONG></v:shapetype></SPAN></SPAN><BR>
+<P><STRONG><EM>Figure 2.3. Most Features Implemented Are Never or Rarely Used.<BR></EM></STRONG><EM>An amazing 45 percent of features implemented are never used, while another 19 percent are used only rarely. If features never used were not implemented in the first place, development time would be cut in about half. Further, since productivity is typically measured in the form of lines of code or functionality delivered, this improvement would not register as a productivity increase using standard productivity measures.<BR></EM> </P>
+<H3>Iteration and Phases </H3>
+<P>The purpose of iterations is to produce an executable which can be assessed so you can get feedback and make course corrections. This executable brings you one step closer to the final product. Phases provide a focus for a team on meeting a certain management objective. OpenUP has four phases, each ending with answering a specific question: </P>
+<UL>
+<LI><STRONG>Inception</STRONG>—Do we agree on the problem we are trying to solve?
+<LI><STRONG>Elaboration</STRONG>—Do we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?
+<LI><STRONG>Construction</STRONG>—Do we agree that we have a system that addresses key stakeholder needs?
+<LI><STRONG>Transition</STRONG>—Do we agree that we can release the system and end the project? </LI></UL>
+<P>Within each phase, you may have one or several iterations, where the iterations aim at producing the results required to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and test some key aspects of the system so that we understand what architecture we need, what Commercial Off-The-Shelf (COTS) components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These needs will steer how we prioritize what is to be done in an Elaboration iteration. </P><!-- END:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/metrics.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/metrics.html
new file mode 100644
index 0000000..0eeb475
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/metrics.html
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\metrics.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: metrics.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0mYYkMlgEdmt3adZL5Dmdw CRC: 3979842427 -->Metrics<!-- END:presentationName,_0mYYkMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0mYYkMlgEdmt3adZL5Dmdw CRC: 1342940695 -->A metric is the interpretation of a measurable attribute(s) of an entity.<!-- END:briefDescription,_0mYYkMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_7ygXoMM3EdmSIPI87WLu3g CRC: 2542540934 --><h3>
+ What is a Metric?
+</h3>
+<p>
+ We distinguish between measure and metric. To clarify, let’s start by defining what is meant by measure and by
+ metric.
+</p>
+<ul>
+ <li>
+ <strong>Measure</strong>: a raw data item that is directly measured and that will be used to calculate a
+ metric.
+ </li>
+ <li>
+ <strong>Metric</strong>: an interpretation of a measure or a set of measures that you use to guide your
+ project.
+ </li>
+</ul>
+<p>
+ For example, recording how many test cases have passed and how many have failed are <strong>measures</strong>.
+ Interpreting what level of quality this indicates and how it reflects the team's progress within the current iteration
+ is a <strong>metric</strong>.
+</p>
+<h3>
+ Why Measure?
+</h3>
+<p>
+ Measurements will mainly help you to:
+</p>
+<ul>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Communicate effectively</strong>. Measurement supports effective communication among team members and
+ project stakeholders.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Identify and correct problems early</strong>. Measurement enables you to identify and manage potential
+ problems early in the development lifecycle.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Make informed trade-offs</strong>. Measurement helps assess objectively the impact of decisions,
+ helping managers to make trade-off decisions to best meet project goals.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Tune estimations</strong>. Recording schedule, progress, and expenditures for projects will help team
+ members to make more reliable estimations in the future.
+ </div>
+ </li>
+</ul>
+<h3 align="left">
+ Potential Challenges
+</h3>
+<p align="left">
+ There are several dangers when it comes to metrics:
+</p>
+<div style="margin-left: 2em">
+ <ul>
+ <li>
+ <div align="left">
+ They can be too costly. The benefit provided by the metric must exceed the cost of collecting
+ it. Keep your measurements simple and easy to collect.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ They’re a poor substitute for communication. The best way to determine the current status of a project
+ is to ask the people involved, not to look at a report summarizing key metrics.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ They can be misleading. No metric or collection of metrics is perfect. Furthermore, the
+ measurements upon which they are based can be manipulated by the people capturing them. Don’t rely
+ simply upon metrics to manage a project.<br />
+ </div>
+ </li>
+ </ul>
+</div><!-- END:mainDescription,_7ygXoMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/milestones.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/milestones.html
new file mode 100644
index 0000000..918cca6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/milestones.html
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\milestones.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: milestones.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HNxbwMBJEdqSgKaj2SZBmg CRC: 1470792276 -->Milestones<!-- END:presentationName,_HNxbwMBJEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_HNxbwMBJEdqSgKaj2SZBmg CRC: 1695806427 -->The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready to move to the next iteration or phase.<!-- END:briefDescription,_HNxbwMBJEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-DG8mYMnTGosWIxjPQFUoTA CRC: 174700995 --><p>
+ Milestones are the point at which an iteration or phase formally ends.
+</p>
+<p>
+ From a development perspective, each iteration provides an increment of functionality to the product. Thus, the
+ end of each iteration corresponds to a checkpoint where the project team demonstrates to stakeholders that the
+ objectives for that iteration have been met.
+</p>
+<p>
+ However, there are four major milestones that provide evaluation criteria at the end of each phase. From a management
+ perspective, the software lifecycle is decomposed over time into four sequential phases, each concluded by a major
+ milestone [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BOE95</a>].
+</p>
+<p class="banner" align="center">
+ <img height="156" alt="Click on text for more information about phases and milestones" src="./resources/co_phas1.gif" width="406" border="0" />
+</p>
+<p class="picturetext" align="center">
+ The phases and milestones of a project
+</p>
+<p>
+ Each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed to
+ determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to
+ the next phase.
+</p>
+<p>
+ At the end of the <strong>Inception</strong> phase is the first major project milestone or <strong>Lifecycle Objectives
+ Milestone</strong>. At this point, you examine the cost versus benefits of the project, and decide either to proceed
+ with the project or to cancel it.
+</p>
+<p>
+ At the end of the <strong>Elaboration</strong> phase is the second important project milestone, the <strong>Lifecycle
+ Architecture Milestone</strong>. At this point, a baseline of requirements is agreed to, you examine the detailed
+ system objectives and scope, the choice of architecture, and the resolution of the major risks.
+</p>
+<p>
+ At the end of the <strong>Construction</strong> phase is the third important project milestone, the <strong>Initial
+ Operational Capability Milestone</strong>. At this point, the product is ready to be handed over to the transition
+ team. All functionality has been developed and all alpha testing (if any) has been completed. In addition to the
+ software, a user manual has been developed, and there is a description of the current release. The product is ready for
+ beta testing.
+</p>
+<p>
+ At the end of the <strong>Transition</strong> phase is the fourth important project milestone, the <strong>Product
+ Release Milestone</strong>. At this point, you decide if the objectives were met, and if you should start another
+ development cycle. The Product Release Milestone is the result of the customer reviewing and accepting the project
+ deliverables.
+</p><!-- END:mainDescription,-DG8mYMnTGosWIxjPQFUoTA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/pattern.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/pattern.html
new file mode 100644
index 0000000..977d6e3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/pattern.html
@@ -0,0 +1,314 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\pattern.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: pattern.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0YJvUMlgEdmt3adZL5Dmdw CRC: 1812055314 -->Pattern<!-- END:presentationName,_0YJvUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0YJvUMlgEdmt3adZL5Dmdw CRC: 3819721842 -->A generalized solution that can be implemented and applied in a problem situation (a context) and thereby eliminate one or more of the inherent problems.<!-- END:briefDescription,_0YJvUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_QvmkAMM1EdmSIPI87WLu3g CRC: 3316110238 --><h4>
+ Origins
+</h4>
+<p>
+ The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
+ written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
+ books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE79</a>] have had the greatest impact on the software community and the adoption of
+ software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
+ capture of software design expertise in a form that can then be reapplied in recurring situations.
+</p>
+<h4>
+ A definition of patterns
+</h4>
+<p>
+ Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]:
+</p>
+<blockquote>
+ <p>
+ "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
+ and classes, when to apply the solution, and the consequences of applying the solution."
+ </p>
+</blockquote>
+<p>
+ This definition often serves only as a starting point, however. A richer definition, based on Alexander’s work, is
+ offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
+ among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
+ configuration that allows these forces to resolve themselves.
+</p>
+<h4>
+ Describing patterns
+</h4>
+<p>
+ It is commonplace to describe patterns using the format made popular by Erich Gamma and his three colleagues
+ [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
+ description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
+ object-oriented design patterns:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
+ abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
+ of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
+ address?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Also known as:</strong> Other names for the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
+ the problem.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
+ applicable.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Structure:</strong> A graphical representation of the classes in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Collaborations:</strong> How participants collaborate to fulfil their responsibilities.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation:</strong> Guidance on the implementation of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Sample code:</strong> Code fragments that illustrate the pattern’s implementation.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Known uses:</strong> Where to find real-world examples of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
+ </p>
+ </li>
+</ul>
+<p>
+ Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
+ modification, to address other software patterns. A more general keyword format for software patterns based on
+ Alexander’s principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
+</p>
+<h4>
+ Pattern catalogs
+</h4>
+<p>
+ To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
+ the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] uses three classifiers: granularity, functionality, and structured
+ principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
+ classifies patterns into three levels of abstraction:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
+ scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
+ pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
+ are described by design patterns. The GoF pattern is an example of a design pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
+ </p>
+ </li>
+</ul>
+<p>
+ Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
+</p>
+<ul>
+ <li>
+ Structure
+ </li>
+ <li>
+ Distributed systems
+ </li>
+ <li>
+ Interactive systems
+ </li>
+ <li>
+ Adaptable systems
+ </li>
+</ul>
+<p>
+ The following table shows the categorization of their architectural patterns.
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1"
+valign="top">
+ <caption>
+ <strong>Categories for Architectural Patterns<br />
+ </strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ <div align="center">
+ <strong>Category</strong>
+ </div>
+ </th>
+ <th scope="col">
+ <div align="center">
+ <strong>Pattern</strong>
+ </div>
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Structure
+ </td>
+ <td>
+ <p>
+ Layers<br />
+ Pipes and filters<br />
+ Blackboard
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Distributed systems
+ </td>
+ <td>
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Interactive systems
+ </td>
+ <td>
+ Model view controller<br />
+ Presentation abstraction control
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p>
+ Adaptable systems
+ </p>
+ </td>
+ <td>
+ <p>
+ Reflection<br />
+ Micro kernel
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
+</p>
+<ul>
+ <li>
+ Creational
+ </li>
+ <li>
+ Structural
+ </li>
+ <li>
+ Behavioral
+ </li>
+</ul>
+<h4>
+ Pattern languages
+</h4>
+<p>
+ In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
+ The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
+ allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
+ buildings. Alexander explains that when using a pattern language:
+</p>
+<blockquote>
+ <p>
+ We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
+ always from the ones that create structure to the ones which then embellish those structures, and then to those
+ that embellish the embellishments.
+ </p>
+</blockquote>
+<p>
+ In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
+ initial context, would always lead to good design. Alexander states:
+</p>
+<blockquote>
+ <p>
+ Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of
+ arrangement, but shows us how to construct arrangements — as many as we want — which satisfies the rules.
+ </p>
+</blockquote>
+<p>
+ In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
+ The sequential application of patterns finds application in software design processes, both waterfall and iterative,
+ that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
+ a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
+ application of patterns, rather than a generative pattern language.
+</p><!-- END:mainDescription,_QvmkAMM1EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/refactoring.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/refactoring.html
new file mode 100644
index 0000000..49d4528
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/refactoring.html
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\refactoring.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: refactoring.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Poc7IPDzEdqYgerqi84oCA CRC: 3501494639 -->Refactoring<!-- END:presentationName,_Poc7IPDzEdqYgerqi84oCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Poc7IPDzEdqYgerqi84oCA CRC: 1996825158 -->This concept explains ways of improving the design of existing code in a way that does not alter its external behavior.<!-- END:briefDescription,_Poc7IPDzEdqYgerqi84oCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-fj_9xjbrpaYNSETyCz5yJg CRC: 3479022165 --><p>
+ Refactoring is a disciplined way to restructure code when small changes are made to the code to improve its
+ design. An important aspect of a refactoring is that it improves the design while not changing the semantics
+ of the design; a refactoring neither adds nor removes functionality.
+</p>
+<p>
+ Refactoring enables you to evolve the code slowly over time, to take an iterative and incremental approach to
+ implementation.
+</p>
+<p>
+ These are the types of refactoring:
+</p>
+<ol>
+ <li>
+ Code refactoring. Often referred to simply as refactoring, this is the refactoring of programming source
+ code. Examples of code refactorings include Rename Method, Encapsulate Field, Extract Class, Introduce
+ Assertion, and Pushdown Method.
+ </li>
+ <li>
+ Database refactoring. A database refactoring is a simple change to a database schema that improves its design
+ while retaining both its behavioral and informational semantics. Examples of database refactorings include
+ Rename Column, Split Table, Move Method to Database, Replace LOB with Table, Introduce Column Constraint, and Use
+ Official Data Source.
+ </li>
+ <li>
+ User interface (UI) refactoring. A UI refactoring is a simple change to the UI which retains its
+ semantics. Examples of UI refactorings include Align Entry Fields, Apply Common Button Size, Apply Common
+ Font, Indicate Format, Reword in Active Voice, and Increase Color Contrast.
+ </li>
+</ol>
+<p>
+ These are suggested resources:
+</p>
+<ul>
+ <li>
+ <a href="http://www.refactoring.com" target="_blank" >http://www.refactoring.com</a>
+ </li>
+ <li>
+ <a href="http://www.agiledata.org/essays/databaseRefactoring.html" >http://www.agiledata.org/essays/databaseRefactoring.html</a>
+ </li>
+</ul><!-- END:mainDescription,-fj_9xjbrpaYNSETyCz5yJg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/requirement_attributes.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/requirement_attributes.html
new file mode 100644
index 0000000..7e649f0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/requirement_attributes.html
@@ -0,0 +1,93 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\requirement_attributes.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: requirement_attributes.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VQ268O0KEdqHTdbLTmC5IQ CRC: 1974774863 -->Requirement Attributes<!-- END:presentationName,_VQ268O0KEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_VQ268O0KEdqHTdbLTmC5IQ CRC: 1106719247 -->Requirements attributes capture additional information, such as risk, planned iteration, source of requirement, about each requirement. This additional information is used to manage the project.<!-- END:briefDescription,_VQ268O0KEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-fCBrf_5JlrmuKgyrCaKGOA CRC: 3881095976 --><p>
+ Attributes are a very important source of requirements information. Just as every person has attributes (age, hair
+ color, gender), each requirement has a source, a relative importance, and time it was created. Attributes do more than
+ simply clarify a requirement. If created properly, they can yield significant information about the state of
+ the system. Just as you can run a database query to find all men with brown hair over age 30, given our human example,
+ you can run queries on the status of requirements to find all high-priority requirements from the customer in the
+ last 30 days. <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</p>
+<h4>
+ Examples of attributes
+</h4>
+<p>
+ Listed below is a partial list of some common attributes and a brief description of their meaning. Some attributes are
+ best described as a number, date, Boolean (true or false) or a text field for entering free format comments. Other
+ attributes can be expressed as lists. For instance, priority type is a list of high, medium, and low; Weekday is a list
+ which includes Monday, Tuesday, and so on.
+</p>
+<p>
+ <em>Source</em> - Person, document or other origin of a given requirement. This is useful for
+ determining whom to call for questions or for grouping requirements according to the person making the demands.
+</p>
+<p>
+ <em>Priority</em> - Statement of relative importance of the requirement, either to the system (mandatory, critical,
+ optional) or to other requirements (high, medium, low). It is good to track the mandatory or high-priority
+ items as an indication of how well the system will meet the greatest needs or for compliance-related metrics.
+</p>
+<p>
+ <em>Assigned to</em> - Who in the organization is responsible for making sure the requirement is met (person's name or
+ organizational name).
+</p>
+<p>
+ <em>Comments</em> - Reviewer's or writer's comments on a requirement.
+</p>
+<p>
+ <em>Difficulty</em> - An indication of the level of effort needed or how hard it will be to implement the requirement
+ (high, medium, low).
+</p>
+<p>
+ <em>Status</em> - Degree of completeness (completed, partial, not started).
+</p>
+<p>
+ <em>Risk</em> - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium,
+ low or the integers one through ten.
+</p>
+<p>
+ <em>Due By</em> - Date the requirement must be provided.
+</p>
+<p>
+ <em>Method of verification</em> - Qualification type to be used to verify that a requirement has been met: analysis,
+ demonstration, inspection, test, and walkthrough.
+</p>
+<p>
+ <em>Level of Test</em> - Describes the verification lifecycle stage at which the requirement is determined to be met:
+ unit test, component, system or product.
+</p>
+<p>
+ <em>Subsystem Allocation</em> - Name of system or subsystem a requirement is to be assigned to (for instance, flight
+ control module, wing assembly, passenger cabin).
+</p>
+<p>
+ <em>Test Number</em> - Identification of a specific test or other method of verification.
+</p>
+<br />
+<br /><!-- END:mainDescription,-fCBrf_5JlrmuKgyrCaKGOA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/requirements.html
new file mode 100644
index 0000000..0b052b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/requirements.html
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0Wh-sMlgEdmt3adZL5Dmdw CRC: 1754233426 -->Requirements<!-- END:presentationName,_0Wh-sMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0Wh-sMlgEdmt3adZL5Dmdw CRC: 2398827048 -->This page provides an informal definition of a requirement and explains how the concept is related to the process.<!-- END:briefDescription,_0Wh-sMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_eUfzwMMyEdmdo9HxCRR_Gw CRC: 4040077616 --><p>
+ Requirements are the project team's to-do list.
+</p>
+<p align="left">
+ Requirements define what is needed and focus the project team. They are the primary method used to communicate the
+ goals of the project to everyone on the team.
+</p>
+<div class="O" v:shape="_x0000_s1026">
+ <div style="mso-line-spacing: '100 30 0'">
+ Requirements define:
+ </div>
+</div>
+<ul>
+ <li>
+ What the stakeholders need; and
+ </li>
+ <li>
+ What the system must include to satisfy the stakeholder needs.
+ </li>
+</ul>
+<p align="left">
+ Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning
+ work, verifying and validating the system (acceptance), and managing the scope of the project.
+</p>
+<p align="left">
+ Requirements may take different forms, including Use Cases and Scenarios, unstructured text, structured text, or a
+ combination, and they may be stated at different levels of granularity. At the highest level of granularity, <a
+ class="elementLink" href="./../../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">Feature</a>s define the services that the system must provide to solve the customer's
+ problem. These are captured as structured or unstructured text in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>. At the next level of granularity, Use Cases define the
+ functionality that the system must provide to deliver the required features. These are captured as Use Cases
+ (see <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>) that describe the sequence of actions performed by the
+ system to yield an observable result of value.
+</p>
+<p>
+ A system must perform according to the behavior that Use Cases specify. However, there are system requirements that do
+ not represent a specific behavior:
+</p>
+<ul>
+ <li>
+ Legal and regulatory requirements, as well as application standards
+ </li>
+ <li>
+ Quality attributes of the system to be built, including usability, reliability, performance, and supportability
+ requirements
+ </li>
+ <li>
+ Interface requirements to be able to communicate with external systems
+ </li>
+ <li>
+ Design constraints, such as those for operating systems and environments and for compatibility with other software
+ </li>
+</ul>
+<p>
+ These quality requirements are often referred to as <strong>non-functional</strong> requirements.
+</p>
+<p>
+ Quality requirements that apply to the system as a whole are captured as structured text in <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. Quality requirements that are closely
+ associated with a particular Use Case are often captured in the Use Case itself to simplify review, understanding, and
+ maintenance.
+</p><!-- END:mainDescription,_eUfzwMMyEdmdo9HxCRR_Gw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF
new file mode 100644
index 0000000..c3428b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG
new file mode 100644
index 0000000..a1b1f17
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/EBCDiagram.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/EBCDiagram.JPG
new file mode 100644
index 0000000..67970fe
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/EBCDiagram.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/co_phas1.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/co_phas1.gif
new file mode 100644
index 0000000..919e282
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/co_phas1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/im_uc.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/im_uc.gif
new file mode 100644
index 0000000..f271c09
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/im_uc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/md_acto2.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/md_acto2.gif
new file mode 100644
index 0000000..29ede3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/md_acto2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/md_acto3.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/md_acto3.gif
new file mode 100644
index 0000000..43fbf21
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/md_acto3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/testFirstDesign.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/testFirstDesign.jpg
new file mode 100644
index 0000000..6da383c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/testFirstDesign.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ucprepst.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ucprepst.gif
new file mode 100644
index 0000000..5f9e869
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ucprepst.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ucstrct.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ucstrct.gif
new file mode 100644
index 0000000..4458bcb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/ucstrct.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/visual.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/visual.gif
new file mode 100644
index 0000000..6f4674c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/resources/visual.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/risk.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/risk.html
new file mode 100644
index 0000000..88fc3e5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/risk.html
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\risk.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: risk.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0bsLgMlgEdmt3adZL5Dmdw CRC: 3644095103 -->Risk<!-- END:presentationName,_0bsLgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0bsLgMlgEdmt3adZL5Dmdw CRC: 919637554 -->A risk is whatever may stand in the way to success, and is currently unknown or uncertain. Usually, a risk is qualified by the probability of occurrence and the impact in the project, if it occurs.<!-- END:briefDescription,_0bsLgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_u6enMMM1EdmSIPI87WLu3g CRC: 17062246 --><h3>
+ What is a Risk?
+</h3>
+<p>
+ Many decisions are driven by risk mitigation in well managed projects. You are trying to mitigate or tackle the
+ most critical risks as early as possible in the project. In order to achieve this you need to get a good grip on the
+ risks the project is faced with, and have clear strategies on how to mitigate or deal with them.
+</p>
+<p>
+ In everyday life a risk is an exposure to loss or injury; a factor, thing, element, or course involving uncertain
+ danger. Similarly, in software development a risk is something that can compromise the success of a project.
+ Examples of potential sources of risk in software development are listed below (see [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>] for more details):
+</p>
+<ul>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Design
+ </li>
+ <li>
+ Development process
+ </li>
+ <li>
+ Work environment
+ </li>
+ <li>
+ Resources
+ </li>
+ <li>
+ Contract
+ </li>
+ <li>
+ Project interdependencies
+ </li>
+ <li>
+ etc.
+ </li>
+</ul>
+<p>
+ Risks can be seen as opportunities. If there are benefits associated to an opportunity, then certain degrees of risk
+ must be taken for a project to be successful [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>].
+</p>
+<h3>
+ Risk Attributes
+</h3>
+<p>
+ You can record as much information as you like or need about your risks, you will find below a list of common risk
+ attributes.
+</p>
+<ul>
+ <li>
+ <strong>Risk Description:</strong> A description of the risk detailing the impact for the project if this risk
+ becomes a problem (i.e. it becomes a reality).
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Type:</strong> Used to classify the risk as:
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <strong>Direct risk</strong>: a risk that the project has a large degree of control over.
+ </li>
+ <li>
+ <strong>Indirect risk</strong>: a risk with little or no project control.
+ </li>
+ </ul>
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Probability</strong> (of occurence): how many chances do we have that this risk will become
+ a problem or an issue, This is usually represented as a scale of values (for example: High, Medium, Low).
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Impact</strong> (level): if this risk become an problem what will be the impact on
+ the project. This is not the actual description of the impact but the level of impact. As the risk
+ probability, it is usually represented as a scale. This attribute is also sometimes called the
+ <strong>severity</strong> of the risk.
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Magnitude</strong>: To be able to rank and to define which ones need to be mitigate first, the
+ <strong>Risk Probability </strong> and <strong>Risk Impact</strong> attributes are often combined in a
+ single <strong>Risk</strong> <strong>Magnitude</strong> indicator represented as a scale similar to the
+ combined attributes.
+ </li>
+</ul><!-- END:mainDescription,_u6enMMM1EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/risk_management.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/risk_management.html
new file mode 100644
index 0000000..80bf8d8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/risk_management.html
@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\risk_management.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: risk_management.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VNxL4ACsEdu8m4dIntu6jA CRC: 2898038623 -->Risk Management<!-- END:presentationName,_VNxL4ACsEdu8m4dIntu6jA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_VNxL4ACsEdu8m4dIntu6jA CRC: 1944800072 -->This is a fundamental practice that project managers should consider in their projects. Identifying and minimizing risks early in the project lifecycle is key factor for project success.<!-- END:briefDescription,_VNxL4ACsEdu8m4dIntu6jA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-HhGIkAPjHSIxnPzI3cyDnQ CRC: 1504106051 --><h3>
+ Introduction
+</h3>
+<p>
+ Every project contains some measure of uncertainty. The role of <strong>Risk Management</strong> is to deal with this
+ uncertainty to try to understand its potential influence on the project. Project risks may be seen as threats or
+ opportunities. The former means the risk should be mitigated (see risk management strategies below) where the latter
+ means that taking a calculated risk may bring, for example, competitive advantage for a product or
+ organization [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>].
+</p>
+<p>
+ Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. A
+ common mistake is to identify risks only at the beginning of the project and then only track the status of these
+ initial risks. The risk list should be revisited weekly, or as a minimum once per iteration, to add any newly
+ discovered risk.
+</p>
+<h3>
+ Risks Prioritization
+</h3>
+<p>
+ A good approach for prioritizing risks is to have an attribute called risk magnitude, a combination of the risk
+ probability and the risk impact. Each iteration provides a chance for better understanding of stakeholder needs,
+ the team capabilities, the technology at hand, and so on. Capture, quantify and prioritize risks as they arise.
+ High magnitude risks are attacked first, thus improving the chances of project success and minimizing
+ uncertainty. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/templates/risk_list,_MIUO0C8FEduzydamRseoUw.html" guid="_MIUO0C8FEduzydamRseoUw">Template: Risk List</a> for more information.
+</p>
+<h3>
+ Risk Management Strategies
+</h3>
+<p>
+ Once you have chosen a set of risks to focus on, choose a mitigation strategy, as described below. Then, identify and
+ assign tasks to apply the strategy to the given risk. Follow up regularly on risk-mitigation actions. Try another
+ strategy if your chosen strategy does not reduce the magnitude of a risk.
+</p>
+<p>
+ Common mitigation strategies are:
+</p>
+<ul>
+ <li>
+ Risk avoidance: reorganize the project so that it cannot be affected by that risk.
+ <ul>
+ <li>
+ For example: you need to use a new framework. A risk avoidance strategy could be to drop this new framework
+ and using another one that is already understood by the team.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk transfer: reorganize the project so that someone or something else bears the risk.
+ <ul>
+ <li>
+ For example: the application you are developing needs to communicate with a legacy system. A risk transfer
+ strategy would make the legacy support team responsible of providing the APIs to access the legacy
+ system.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk mitigation: define a mitigation plan to reduce the probability or the impact of the risk.
+ <ul>
+ <li>
+ For example: you need to use a new middleware. A risk mitigation strategy could be to build a prototype
+ using this new middleware to validate that it will provide the features you need for your
+ application.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk acceptance: decide to live with the risk, and define a contingency plan.
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ For example: your integrator is the only one who knows how to integrate the different components of your
+ application. A contingency plan could be to identify a resource on another project that you could bring on
+ if your integrator is sick, leaves the company, etc.
+ </li>
+ </ul>
+ </li>
+</ul><!-- END:mainDescription,-HhGIkAPjHSIxnPzI3cyDnQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/software_architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/software_architecture.html
new file mode 100644
index 0000000..62179c6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/software_architecture.html
@@ -0,0 +1,236 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\software_architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: software_architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__O7tAMVvEduLYZUGfgZrkQ CRC: 867985127 -->Software Architecture<!-- END:presentationName,__O7tAMVvEduLYZUGfgZrkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__O7tAMVvEduLYZUGfgZrkQ CRC: 3599034556 -->The software architecture represents the structure or structures of the system, which consists of software components, the externally visible properties of those components, and the relationships among them.<!-- END:briefDescription,__O7tAMVvEduLYZUGfgZrkQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-UQ_e8kozIP11Xu008RJd-A CRC: 3617722195 --><h3>
+ Introduction
+</h3>
+<p>
+ Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially
+ with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line
+ between design and architecture-architecture is one aspect of design that concentrates on some specific features.
+</p>
+<p>
+ In An Introduction to Software Architecture, David Garlan and Mary Shaw suggest that software architecture is a level
+ of design concerned with issues: "Beyond the algorithms and data structures of the computation; designing and
+ specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization
+ and global control structure; protocols for communication, synchronization, and data access; assignment of
+ functionality to design elements; physical distribution; composition of design elements; scaling and performance; and
+ selection among design alternatives." <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[GAR93]</a>
+</p>
+<p>
+ But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the
+ highest-level concept of a system in its environment" <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[IEP1471]</a>. It also encompasses the "fit" with system integrity, with economical
+ constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into
+ consideration the system as a whole in its user environment and its development environment - an outward focus.
+</p>
+<p>
+ In OpenUP, the architecture of a software system (at a given point) is the organization or structure of the system's
+ significant components interacting through interfaces, with components composed of successively smaller components and
+ interfaces.
+</p>
+<h3>
+ Architecture Description
+</h3>
+<p>
+ To speak and reason about software architecture, you must first define an architectural representation, a way of
+ describing important aspects of an architecture. In OpenUP, this description is captured in the <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
+</p>
+<h3>
+ Architectural Views
+</h3>
+<p>
+ We have chosen to represent software architecture in multiple architectural views. Each architectural view addresses
+ some specific set of concerns, specific to stakeholders in the development process: users, designers, managers, system
+ engineers, maintainers, and so on.
+</p>
+<p>
+ The views capture the major structural design decisions by showing how the software architecture is decomposed into
+ components, and how components are connected by connectors to produce useful forms <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the Requirements, functional, and
+ supplementary, and other constraints. But these choices in turn put further constraints on the requirements and on
+ future design decisions at a lower level.
+</p>
+<h3>
+ Architectural Focus
+</h3>
+<p>
+ Although the views above could represent the whole design of a system, the architecture concerns itself only with some
+ specific aspects:
+</p>
+<ul>
+ <li>
+ The structure of the model - the organizational patterns, for example, Layering.
+ </li>
+ <li>
+ The essential elements - critical use cases, main classes, common mechanisms, and so on, as opposed to all the
+ elements present in the model.
+ </li>
+ <li>
+ A few key scenarios showing the main control flows throughout the system.
+ </li>
+ <li>
+ The services, to capture modularity, optional features, product-line aspects.
+ </li>
+</ul>
+<p>
+ In essence, architectural views are abstractions, or simplifications, of the entire design, in which important
+ characteristics are made more visible by leaving details aside. These characteristics are important when reasoning
+ about:
+</p>
+<ul>
+ <li>
+ System evolution-going to the next development cycle.
+ </li>
+ <li>
+ Reuse of the architecture, or parts of it, in the context of a product line.
+ </li>
+ <li>
+ Assessment of supplementary qualities, such as performance, availability, portability, and safety.
+ </li>
+ <li>
+ Assignment of development work to teams or subcontractors.
+ </li>
+ <li>
+ Decisions about including off-the-shelf components.
+ </li>
+ <li>
+ Insertion in a wider system.
+ </li>
+</ul>
+<h3>
+ Architectural Patterns
+</h3>
+<p>
+ Architectural patterns are ready-made forms that solve recurring architectural problems. An architectural framework or
+ an architectural infrastructure (middleware) is a set of components on which you can build a certain kind of
+ architecture. Many of the major architectural difficulties should be resolved in the framework or in the
+ infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.
+</p>
+<h4>
+ Examples of Architectural Patterns
+</h4>
+<p>
+ <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> groups architectural patterns according to the characteristics of the
+ systems in which they are most applicable, with one category dealing with more general structuring issues. The table
+ shows the categories presented in <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> and the patterns they contain.
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th id="col1" width="50%">
+ Category
+ </th>
+ <th id="col2" width="50%">
+ Pattern
+ </th>
+ </tr>
+ <tr>
+ <th id="row2" align="left" headers="col1" width="50%" rowspan="3">
+ Structure
+ </th>
+ <td headers="row2 col2" width="50%">
+ Layers
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Pipes and Filters
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Blackboard
+ </td>
+ </tr>
+ <tr>
+ <th id="row3" align="left" headers="col1" width="50%">
+ Distributed Systems
+ </th>
+ <td headers="row3 col2" width="50%">
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <th id="row4" align="left" headers="col1" width="50%" rowspan="2">
+ Interactive Systems
+ </th>
+ <td headers="row4 col2" width="50%">
+ Model-View-Controller
+ </td>
+ </tr>
+ <tr>
+ <td headers="row4 col2" width="50%">
+ Presentation-Abstraction-Control
+ </td>
+ </tr>
+ <tr>
+ <th id="row5" align="left" headers="col1" width="50%" rowspan="2">
+ Adaptable Systems
+ </th>
+ <td headers="row5 col2" width="50%">
+ Reflection
+ </td>
+ </tr>
+ <tr>
+ <td headers="row5 col2" width="50%">
+ Microkernel
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ Refer to <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> for a complete description of these patterns.
+</p>
+<h3>
+ <a id="Architectural Style" name="Architectural Style">Architectural Style</a>
+</h3>
+<p>
+ A software architecture, or only an architectural view, may have an attribute called <b>architectural style</b>, which
+ reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The
+ style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building
+ blocks.
+</p><!-- END:mainDescription,-UQ_e8kozIP11Xu008RJd-A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/supporting_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/supporting_requirements.html
new file mode 100644
index 0000000..b08c44c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/supporting_requirements.html
@@ -0,0 +1,127 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\supporting_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VXZ5wO0IEdqHTdbLTmC5IQ CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_VXZ5wO0IEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_VXZ5wO0IEdqHTdbLTmC5IQ CRC: 4180735249 -->This concept describes the supporting requirements<!-- END:briefDescription,_VXZ5wO0IEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-3SXuKijeVOZalgLPgWRyFA CRC: 2075379761 --><h3>
+ Definition
+</h3>
+<p>
+ Supporting requirements are requirements that define necessary system quality attributes such as performance,
+ usability and reliability, as well as global functional requirements that are not captured in behavioral
+ requirements artifacts such as use-cases.
+</p>
+<h3>
+ Supporting Requirements Categories
+</h3>
+<p>
+ Supporting requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability, Performance,
+ Supportability + constraints). Constraints include design, implementation, interfaces, physical constraints, and
+ business rules. A description of each of these types of requirements follows.
+</p>
+<p>
+ Supporting requirements and Use Cases, together, define the requirements of the system. These requirements support the
+ features listed in the Vision statement. Each requirement should support at least one feature, and each feature
+ should be supported by at least one to requirement.
+</p>
+<p>
+ In general, <strong>functional</strong> requirements describe behavior and are captured in Use Cases (see <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>). <strong>Non-functional</strong> requirements are captured in
+ the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. However, nonfunctional requirements that are
+ closely associated with a particular Use Case are often captured within the Use Case itself to simplify communication
+ and maintenance. Similarly, there are global, or system-wide, functional requirements that are often captured
+ among the supporting requirements for the same reasons.
+</p>
+<h4>
+ Functional requirements
+</h4>
+<p>
+ Functionality requirements include all the overarching, system wide functional requirements. These functional
+ requirements represent the main system features that are familiar within the business domain or technically oriented
+ requirements such as auditing, licensing, localization, mail, online help, printing, reporting, security, system
+ management, or workflow.
+</p>
+<h4>
+ Usability requirements
+</h4>
+<p>
+ Usability requirements include requirements based on human factors and user interface issues such as accessibility,
+ interface aesthetics, and consistency within the user interface.
+</p>
+<h4>
+ Reliability requirements
+</h4>
+<p>
+ Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or
+ recoverability of the system from shut-down failure.
+</p>
+<h4>
+ Performance requirements
+</h4>
+<p>
+ Performance requirements address concerns such as throughput of information through the system, system response time
+ and resource usage.
+</p>
+<h4>
+ Supportability requirements
+</h4>
+<p>
+ Supportability requirements include requirements such as compatibility and the abilities to test, adapt, maintain,
+ configure, install, scale, localize, and so on.
+</p>
+<h4>
+ + Constraints
+</h4>
+<p>
+ The <strong>+</strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,
+ interfaces, physical constraints, and business rules:
+</p>
+<ul>
+ <li>
+ <strong>Design constraints</strong> limit the design and state requirements on the approach that should be taken in
+ developing the system.
+ </li>
+ <li>
+ <strong>Implementation constraints</strong> put limits on coding or construction (required standards, languages,
+ tools, or platform)
+ </li>
+ <li>
+ <strong>Interface constraints</strong> are requirements to interact with external systems, describing protocols or
+ the nature of the information that is passed across that interface.
+ </li>
+ <li>
+ <strong>Physical constraints</strong> affect the hardware or packaging housing the system (shape, size, and
+ weight).
+ </li>
+ <li>
+ <strong>Business rules</strong> are policies or decisions that govern how the business operates. They may constrain
+ the steps described in the Use Case flow.
+ </li>
+</ul><!-- END:mainDescription,-3SXuKijeVOZalgLPgWRyFA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/test_first_design.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/test_first_design.html
new file mode 100644
index 0000000..26da6bb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/test_first_design.html
@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\test_first_design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_first_design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 3904523993 -->Test-first Design<!-- END:presentationName,_0Y6kUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw CRC: 438527168 -->This concept explains how to bring test design chronologically in-line with software design.<!-- END:briefDescription,_0Y6kUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg CRC: 449565311 --><h3>
+ Introduction
+</h3>
+<p>
+ With Test-First Design (TFD) you do detailed design in a just-in-time (JIT) manner via writing a single test
+ before writing just enough production code to fulfill that test. When you have new functionality to add to your
+ system, perform the following steps:
+</p>
+<ol>
+ <li>
+ <strong>Quickly add a test</strong>. You need just enough code to fail.
+ </li>
+ <li>
+ <strong>Run your tests</strong>. You will typically run the complete test suite, although for sake of
+ speed you may decide to run only a subset. The goal is to ensure that the new test does in fact
+ fail.
+ </li>
+ <li>
+ <strong>Update your production code</strong>. The goal is to add just enough functionality so that
+ your code passes the new test.
+ </li>
+ <li>
+ <strong>Run your test suite again</strong>. If they tests fail you need to update your functional code
+ and retest. Once the tests pass, start over.
+ </li>
+</ol>
+<br />
+<p>
+ <img height="600" alt="Test First Design Flow" src="./resources/testFirstDesign.jpg" width="294" />
+</p>
+<h4>
+ Why TFD?
+</h4>
+<p>
+ A significant advantage of TFD is that it enables you to take small steps when writing software, which is not only
+ safer it is also far more productive than writing code in large steps.<span style="mso-spacerun: yes"> </span> For example, assume you add some new functional code, compile, and test
+ it.<span style="mso-spacerun: yes"> </span> Chances are pretty good that your tests will be broken by defects that
+ exist in the new code.<span style="mso-spacerun: yes"> </span> It is much easier to find, and then fix, those
+ defects if you've written five new lines of code than in fifty lines. The implication is that the faster your compiler
+ and regression test suite, the more attractive it is to proceed in smaller and smaller steps.<span style="mso-spacerun: yes"> </span>
+</p>
+<p>
+ There are three other common testing strategies (in order of effectiveness).
+</p>
+<ol>
+ <li>
+ <strong>Write several tests first</strong>. This is a variant of TFD where you write more than one test
+ before writing just enough production code to fulfill those tests. The advantage is that you don't need to
+ build your system as often, potentially saving time. It has the disadvantage that you will write
+ more production code at once, increasing the difficulty of finding any new bugs that you do introduce.
+ </li>
+ <li>
+ <strong>Test after the fact</strong>. With this approach you write some production code then you write enough
+ testing code to validate it. This has the advantage that you're at least still validating the code but has
+ the disadvantage that you lose the design benefit inherent in writing the testing code first.
+ </li>
+ <li>
+ <strong>Don't test at all</strong>. This is a really bad idea.
+ </li>
+</ol>
+<br />
+<h3>
+ Good Things to Know
+</h3>
+<p>
+ 1. An underlying assumption of TDD is that you have a unit-testing framework available to you.<span style="mso-spacerun: yes"> </span> Agile software developers often use the xUnit family of open source tools, such
+ as <a href="http://www.junit.org/" ><strong>JUnit</strong></a> or <a href="http://www.vbunit.org/" ><strong>VBUnit</strong></a>, although commercial tools are
+ also viable options.<span style="mso-spacerun: yes"> </span><span style="mso-spacerun: yes"> </span>
+</p>
+<p>
+ 2. Test-Driven Design (TDD) = TFD + <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
+</p>
+<p>
+ 3. TFD/TDD is commonly used with object-oriented business code, although you can also take this approach with
+ procedural code, user-interface code, and your database code if you choose to.
+</p>
+<p>
+ 4. A more thorough discussion of TFD and TDD is presented at <a href="http://www.agiledata.org/essays/tdd.html" target="_blank" >Introduction to Test Driven Development (TDD)</a>.
+</p>
+<br /><!-- END:mainDescription,_Hg5UUMPbEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/test_ideas.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/test_ideas.html
new file mode 100644
index 0000000..ccad694
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/test_ideas.html
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\test_ideas.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_ideas.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0jnYcMlgEdmt3adZL5Dmdw CRC: 1652868117 -->Test Ideas<!-- END:presentationName,_0jnYcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0jnYcMlgEdmt3adZL5Dmdw CRC: 2895564308 -->A list of test ideas sorted in decreasing order of importance and associated with specific testing strategies used to create executable tests.<!-- END:briefDescription,_0jnYcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_uqL2gMM3EdmSIPI87WLu3g CRC: 3218395200 --><p>
+ <strong>Test Ideas List</strong> - A list of brief statements identifying tests that are potentially useful to conduct.
+</p>
+<p>
+ <strong>Test Ideas Catalog</strong> - A catalog of common faults and mistakes done when developing software.
+</p>
+<ul>
+ <li>
+ Test Ideas will describe any of the elements of an executable test.
+ </li>
+ <li>
+ Test ideas ensure the important ideas are not forgotten and are detailed later in test cases.
+ </li>
+ <li>
+ Test Ideas are to be captured at a less-specific level in an intermediate form.
+ </li>
+ <li>
+ Test ideas are more reviewable and understandable then complete tests. Making the reasoning behind the test
+ idea clearer.
+ </li>
+ <li>
+ Test ideas support more powerful test, by not constraining the tester. Making it easier to create tests that
+ validate more then just the defined requirements.
+ </li>
+ <li>
+ Test Ideas are often based on explicit and implicit fault modules, to include but not limited to Booleans,
+ boundaries and method calls. Test Ideas Lists will contain test ideas from many faults models derived for one
+ or many work products.
+ </li>
+</ul>
+<p>
+ Creating test ideas before testing for review and inspection of design work products assists in discovering design or
+ analysis errors.
+</p><!-- END:mainDescription,_uqL2gMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/traceability.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/traceability.html
new file mode 100644
index 0000000..11a793b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/traceability.html
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\traceability.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: traceability.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eYtQQO0KEdqHTdbLTmC5IQ CRC: 2307195292 -->Traceability<!-- END:presentationName,_eYtQQO0KEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_eYtQQO0KEdqHTdbLTmC5IQ CRC: 2269060618 -->Traceability is a term used to describe the establishment and maintenance of relationships between artifacts, such as a requirement and a design class or a requirement and a test case, so that you can track the completeness of work &lt;strong&gt; &lt;/strong&gt;and assess the impact of changes.<!-- END:briefDescription,_eYtQQO0KEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-TksCtMgc0b4QqzwzniGvIw CRC: 3393829164 --><p align="left"> Traceability is about understanding how high-level requirements
+ (objectives, goals, aims, aspirations, expectations, needs) are transformed
+ into low-level requirements, how they are implemented, and how they are verified.
+</p>
+<p>
+ Using traceability can provide the following benefits <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#HUL05"
+ guid="_9ToeIB83Edqsvps02rpOOg">[HUL05]</a>:
+</p>
+<ul>
+
+ <li> <strong>Greater confidence in meeting objectives </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Establishing traceability engenders greater reflection on how objectives
+ are satisfied. Traceability permits coverage analysis to ensure that
+ everything you have done everything that you agreed to do and only what you
+ agreed to do.</p>
+</blockquote>
+<ul>
+
+ <li> <strong>Ability to assess the impact of change </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p> Traceability permits various forms of impact analysis that can be used to
+ assess the impact of a proposed change on the cost, schedule, and technical
+ aspects of the project.</p>
+</blockquote>
+<ul>
+
+ <li><strong> Improved accountability </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Traceability provides great clarity about how work contributes to the
+ whole. </p>
+</blockquote>
+<ul>
+ <li><strong> Ability to track progress </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> It is notoriously difficult to measure progress when all that you are doing
+ is creating and revising artifacts. Traceability processes allow precise measures
+ of progress, such as: Is there a design artifact for each requirement? Is
+ there a test case for each requirement?. </p>
+</blockquote>
+<ul>
+
+ <li><strong> Ability to balance cost against benefit </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Relating product components to the requirements allows you to compare benefits
+ to costs. </p>
+</blockquote>
+<br dir="ltr" />
+<br /><!-- END:mainDescription,-TksCtMgc0b4QqzwzniGvIw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/transition_phase.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/transition_phase.html
new file mode 100644
index 0000000..ec74b5b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/transition_phase.html
@@ -0,0 +1,123 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\transition_phase.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: transition_phase.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__ca5UBOMEduCNqgZdt_OaA CRC: 2941352917 -->Transition Phase<!-- END:presentationName,__ca5UBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__ca5UBOMEduCNqgZdt_OaA CRC: 1701681920 -->Fourth and final phase in the project lifecycle.<!-- END:briefDescription,__ca5UBOMEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-FrUmsKsGW4bnNmb9uaNOkg CRC: 1431457588 --><p>
+ The purpose in this phase is to ensure that the software is ready for delivery to users.
+</p>
+<p>
+ There are objectives for the Transition phase that help you to fine-tune functionality, performance, and overall
+ quality of the beta product from the end of the previous phase <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Beta test to validate that user expectations are met.</strong> This typically requires some fine-tuning
+ activities, such as bug-fixing and making enhancements for performance and usability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Achieve stakeholder concurrence that deployment is complete.</strong> This may involve various levels
+ of tests for product acceptance, including formal and informal tests and beta tests.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Improve future project performance through lessons learned.</strong> Document lessons learned and
+ improve the process and tool environment for the project.
+ </p>
+ </li>
+</ol>
+<p>
+ The following table summarizes the Transition phase objectives and what activities address each objective:
+</p>
+<p align="center">
+ <strong>Transition phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300" height="62">
+ Beta test to validate that user expectations are met
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../ongoing_tasks,_0qxwYclgEdmt3adZL5Dmdw.html" guid="_0qxwYclgEdmt3adZL5Dmdw">Ongoing Tasks</a><br />
+ <a class="elementLinkWithUserText" href="./../../../develop_requirement_within_context,_0DMlYPinEdmugcVr9AdHjQ.html" guid="_0DMlYPinEdmugcVr9AdHjQ">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0qrpwslgEdmt3adZL5Dmdw.html" guid="_0qrpwslgEdmt3adZL5Dmdw">Validate Build</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Achieve stakeholder concurrence that deployment is complete
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0qrpwslgEdmt3adZL5Dmdw.html" guid="_0qrpwslgEdmt3adZL5Dmdw">Validate Build</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Improve future project performance through lessons learned
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<h4>
+ <br />
+ Key considerations<br />
+</h4>
+<p>
+ The Transition phase can include running old and new systems in parallel, migrating data, training users, and adjusting
+ business processes.
+</p>
+<p>
+ The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily
+ minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to
+ make the business transition from using the old system to using the new system.
+</p>
+<p>
+ When the Transition phase objectives are met, the project is in position to be closed. For some products, the end
+ of the current project lifecycle may coincide with the beginning of the next lifecycle, leading to the next generation
+ of the same product.
+</p><!-- END:mainDescription,-FrUmsKsGW4bnNmb9uaNOkg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/types_of_test.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/types_of_test.html
new file mode 100644
index 0000000..f8df74e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/types_of_test.html
@@ -0,0 +1,174 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\types_of_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: types_of_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0aJ6cMlgEdmt3adZL5Dmdw CRC: 3180024288 -->Types of Test<!-- END:presentationName,_0aJ6cMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0aJ6cMlgEdmt3adZL5Dmdw CRC: 2205558808 -->Testing is applied to different types of targets, in different stages or levels of work effort. This Concept introduces various types of test.<!-- END:briefDescription,_0aJ6cMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_y-_PIMPdEdmbOvqy4O0adg CRC: 2487706777 --><h3>
+ Introduction
+</h3>
+<p>
+ There is much more to testing computer software than simply evaluating the functions, interface, and response-time
+ characteristics of a target-of-test. Additional tests must focus on characteristics and attributes, such as the
+ target-of-test.
+</p>
+<ul>
+ <li>
+ integrity (resistance to failure)
+ </li>
+ <li>
+ ability to be installed and executed on different platforms
+ </li>
+ <li>
+ ability to handle many requests simultaneously
+ </li>
+</ul>
+<p>
+ To achieve this, many different types of tests are implemented and executed. Each test type has a specific
+ objective and support technique. Each technique focuses on testing one or more characteristics or attributes of
+ the target-of-test.
+</p>
+<p>
+ The following sections list the types of test based on the most obvious <strong>quality dimensions</strong> they
+ address.
+</p>
+<h3>
+ Quality Dimension: Functionality
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Function test:</strong> Tests focused on validating the target-of-test functions as intended, providing
+ the required services, methods, or use cases. This test is implemented and executed against different targets-of-test,
+ including units, integrated units, applications, and systems.
+</p>
+<p>
+ <strong>Security test:</strong> Tests focused on ensuring the target-of-test data (or systems) are accessible only
+ to those actors for which they are intended. This test is implemented and executed on various targets-of-test.
+</p>
+<p>
+ <strong>Volume test:</strong> Tests focused on verifying the target-of-test's ability to handle large amounts of
+ data, either as input and output or resident within the database. Volume testing includes test strategies such as
+ creating queries that would return the entire contents of the database, or that would have so many restrictions that no
+ data is returned, or where the data entry has the maximum amount of data for each field.
+</p>
+<h3>
+ Quality Dimension: Usability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Usability test:</strong> Tests that focus on:
+</p>
+<ul>
+ <li>
+ human factors
+ </li>
+ <li>
+ esthetics
+ </li>
+ <li>
+ consistency in the user interface
+ </li>
+ <li>
+ online and context-sensitive help
+ </li>
+ <li>
+ wizards and agents
+ </li>
+ <li>
+ user documentation
+ </li>
+ <li>
+ training materials
+ </li>
+</ul>
+<p>
+ <strong>Integrity test:</strong> Tests that focus on assessing the target-of-test's robustness (resistance to
+ failure), and technical compliance to language, syntax, and resource usage. This test is implemented and executed
+ against different targets-of-tests, including units and integrated units.
+</p>
+<p>
+ <strong>Structure test</strong>: Tests that focus on assessing the target-of-test's adherence to its design and
+ formation. Typically, this test is done for Web-enabled applications ensuring that all links are connected,
+ appropriate content is displayed, and no content is orphaned.
+</p>
+<h3>
+ Quality Dimension: Reliability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Stress test:</strong> A type of reliability test that focuses on evaluating how the system responds under
+ abnormal conditions. Stresses on the system could include extreme workloads, insufficient memory, unavailable
+ services and hardware, or limited shared resources. These tests are often performed to gain a better understanding
+ of how and in what areas the system will break, so that contingency plans and upgrade maintenance can be planned and
+ budgeted for well in advance.
+</p>
+<p>
+ <strong>Benchmark test:</strong> A type of performance test that compares the performance of a new or unknown
+ target-of-test to a known reference-workload and system.
+</p>
+<p>
+ <strong>Contention test:</strong> Tests focused on validating the target-of-test's ability to acceptably handle
+ multiple actor demands on the same resource (data records, memory, and so on).
+</p>
+<h3>
+ Quality Dimension: Performance
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Load test:</strong> A type of performance test used to validate and assess acceptability of the
+ operational limits of a system under varying workloads while the system-under-test remains constant. In some
+ variants, the workload remains constant and the configuration of the system-under-test is varied. Measurements
+ are usually taken based on the workload throughout and in-line transaction response time. The variations in
+ workload usually include emulation of average and peak workloads that occur within normal operational tolerances.
+</p>
+<p>
+ <strong>Performance profile:</strong> A test in which the target-of-test's timing profile is monitored, including
+ execution flow, data access, function and system calls to identify and address both performance bottlenecks and
+ inefficient processes.
+</p>
+<p>
+ <strong>Configuration test:</strong> Tests focused on ensuring the target-of-test functions as intended on
+ different hardware and software configurations. This test might also be implemented as a system performance test.
+</p>
+<h3>
+ Quality Dimension: Supportability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Installation test:</strong> Tests focused on ensuring the target-of-test installs as intended on
+ different hardware and software configurations, and under different conditions (such as insufficient disk space or
+ power interruptions). This test is implemented and executed against applications and systems.
+</p><!-- END:mainDescription,_y-_PIMPdEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/use_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/use_case.html
new file mode 100644
index 0000000..cf57f47
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/use_case.html
@@ -0,0 +1,854 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\use_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_KudM0NcJEdqz_d2XWoVt6Q CRC: 3319967926 -->Use Case<!-- END:presentationName,_KudM0NcJEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_KudM0NcJEdqz_d2XWoVt6Q CRC: 4148269292 -->A use case describes what the system must do to provide value to the stakeholders.<!-- END:briefDescription,_KudM0NcJEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-BQLZ5GRUNrMdU6XeZAfe9Q CRC: 1997391341 --><h3>
+ <a id="Definitions" name="Definitions">Definitions</a>
+</h3>
+<h4>
+ Use Case
+</h4>
+<p>
+ A use case instance defines a sequence of actions performed by the system that yields an observable result of value to
+ a particular actor. There are several key words in this definition:
+</p>
+<ul>
+ <li>
+ <b>"use case instance"</b> The sequence referred to in the definition is actually a specific flow of events through
+ the system, or an instance. Many flows of events are possible, and many may be very similar. To make a use-case
+ understandable, you should group similar flows of events into one use case. Therefore, identifying and describing a
+ use case really means identifying and describing a group of related flows of events.
+ </li>
+ <li>
+ <strong>"actions"</strong> An action is a computational or algorithmic procedure. It is invoked either when the
+ actor provides a signal to the system or when the system gets a time event. An action may imply signal
+ transmissions to either the invoking actor or other actors. An action is atomic, which means it is performed either
+ entirely or not at all.
+ </li>
+ <li>
+ <b>"performed by the system"</b> This means that the system provides the use case. An actor communicates with a
+ use-case instance of the system.
+ </li>
+ <li>
+ <b>"an observable result of value"</b> You can put a value on a successfully performed use case. A use case should
+ make sure that an actor can perform a task that has an identifiable value. This is very important in determining
+ the correct level or granularity for a use case. <em>Correct level</em> refers to achieving use cases that are not
+ too small.
+ </li>
+ <li>
+ <b>"a particular actor"</b> The actor is key to finding the correct use case, especially because the actor
+ helps you avoid use cases that are too large. As an example, consider a visual modeling tool. There are really two
+ actors in this application: a developer, who develops systems using the tool as support; and a system
+ administrator, who manages the tool. Each of these actors has his own demands on the system, and will therefore
+ require his own set of use cases.
+ </li>
+</ul>
+<p>
+ The functionality of a system is defined by different use cases, each of which represents a specific goal (observable
+ result of value) for a particular actor. The description of a use case defines what happens in the system when the use
+ case is performed.
+</p>
+<p class="picturecenter" align="center">
+ <img height="173" alt="Diagram described in caption." src="./resources/im_uc.gif" width="325" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="picturetext">
+ Figure 1: ATM use case example.
+ </p>
+ </blockquote>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p>
+ In an automated teller machine the client can, for instance, withdraw money from an account, transfer money to an
+ account, or check the balance of an account. These correspond to specific goals that the actor has in using the system.
+</p>
+<p>
+ Each use case has a task of its own to perform. The collected use cases constitute all the possible ways of using the
+ system. You should be able to determine the goal of a use-case task simply by observing its name.
+</p>
+<h4>
+ <a id="A Use-Case has Many Possible Instances" name="A Use-Case has Many Possible Instances">Use-Case</a>
+ Instance
+</h4>
+<p>
+ A use-case can follow an almost unlimited, but enumerable, number of paths. These paths represent the choices open to
+ the use-case in the description of its flow of events. The path chosen depends on events. Types of events include:
+</p>
+<ul>
+ <li>
+ <strong>Input from an actor </strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ For example, an actor can decide, from several options, what to do next. In the use case Recycle Items in the
+ Recycling-Machine System the Customer always has two options: insert another deposit item or get the
+ receipt for returned items.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>A check of values or types of an internal object or attribute</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ For example, the flow of events may differ if a value is greater or less than a certain value. In the use case
+ Withdraw Money in an automated teller machine system, the flow of events will differ if the Client asks for more
+ money than he has in his account. In that situation, the use-case instance follows a different path.
+ </p>
+</blockquote>
+<h4>
+ Scenario
+</h4>
+<p>
+ A scenario is a specific sequence of actions that illustrates a behavior. A scenario may be used to illustrate a
+ use-case instance and to specify test cases.
+</p>
+<h4>
+ Use-Case Realization
+</h4>
+<p>
+ A use case describes what happens in the system when an actor interacts with the system. The use case does not define
+ how the system performs its tasks, in terms of collaborating objects. This is left for the use-case realizations
+ to show.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In the telephone example, the use case would indicate (among other things) that the system issues a signal when the
+ actor lifts the receiver, and that the system then receives digits, finds the receiving party, rings his
+ telephone, connects the call, transmits speech, and so on.
+ </p>
+</blockquote>
+<p>
+ In a running system, an instance of a use case does not correspond to any particular object in the implementation
+ model (for example, an instance of a class in the code). Instead, it corresponds to a specific flow of events that is
+ invoked by an actor and performed as a sequence of events among a set of objects. In other words, instances of use
+ cases correspond to communicating instances of implemented objects. We call this the <strong>realization of the use
+ case</strong>. Often, the same objects participate in realizations of more than one use case. For example, both the use
+ cases Deposit and Withdrawal in a banking system may use a certain account object in their realization. This does not
+ mean that the two use cases communicate, but only that they use the same object in their realization.
+</p>
+<p>
+ You can think of a flow of events as consisting of several subflows that, taken together, yield the
+ total flow of events. You can reuse the description of a subflow in other flows of events for other use cases. Subflows
+ in the description of one use case's flow of events may be common to those of other use cases. In the design you should
+ have the same objects perform this common behavior for all the relevant use cases. That is, only one set of objects
+ should perform this behavior no matter which use case is running.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In an automated teller machine system, the initial subflow is the same in the flow of events of the use cases
+ Withdraw Money and Check Balance. The flow of events of both use cases start by checking the identity of the card
+ and the client's personal access code.
+ </p>
+</blockquote>
+<h3>
+ Properties of Use Cases
+</h3>
+<h4>
+ <a id="Name" name="Name">Name</a>
+</h4>
+<p>
+ Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have
+ to be several words to be understood. Note: No two use cases can have the same name.
+</p>
+<blockquote>
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ These are examples of variations of the name for the use case Recycle Items in the Recycling Machine example:
+ </p>
+ <ul>
+ <li>
+ Return Deposit Items
+ </li>
+ <li>
+ Deposit Items
+ </li>
+ </ul>
+</blockquote>
+<h4>
+ <a id="Brief Description" name="Brief Description">Brief Description</a>
+</h4>
+<p>
+ The brief description of the use case should reflect its purpose. As you write the description, refer to the actors
+ involved in the use case and the glossary. If you need to, define new concepts.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ Following are sample brief descriptions of the use cases Recycle Items and Add New Bottle Type in the
+ Recycling-Machine system.
+ </p>
+ <p class="example">
+ <b>Recycle Items</b>: The user uses this machine to automatically have all the return items (bottles, cans, and
+ crates) counted, and receives a receipt. The receipt is to be cashed at a cash register (another machine).
+ </p>
+ <p class="example">
+ <b>Add New Bottle Type</b>: The manager can add options for the user to return new kinds of bottles can be added to
+ the machine by starting it in <em>learning</em> mode and inserting 5 samples, just as when the customers
+ return items. The machine can measure the bottles and learns to identify them. The manager specifies the refund
+ value for the new bottle type.
+ </p>
+</blockquote>
+<h4>
+ Flow of Events
+</h4>
+<h5>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of
+ Events - Contents</a>
+</h5>
+<p>
+ The f<b>low of events</b> of a use case contains the most important information derived from use-case modeling work. It
+ should describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow
+ of events should represent <em>what</em> the system does, not <em>how</em> the system is design to perform the required
+ behavior.
+</p>
+<p>
+ Follow these guidelines for the contents of the flow of events:
+</p>
+<ul>
+ <li>
+ Describe how the use case starts and ends.
+ </li>
+ <li>
+ Describe what data is exchanged between the actor and the use case.
+ </li>
+ <li>
+ Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system.
+ For example, it is often good to use a limited set of web-specific terminology when it is known beforehand that the
+ application is going to be web-based. Otherwise, your run the risk that the use-case text is being perceived as too
+ abstract. Words to include in your terminology could be "navigate", "browse", "hyperlink" "page", "submit", and
+ "browser". However, it is not advisable to include references to "frames" or "web pages" in such a way that you are
+ making assumptions about the boundaries between them; this is a critical design decision.
+ </li>
+ <li>
+ Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
+ ... ".
+ </li>
+ <li>
+ Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
+ system.
+ </li>
+ <li>
+ Avoid vague terminology.
+ </li>
+ <li>
+ Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
+ test cases.
+ </li>
+</ul>
+<p>
+ If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
+ that the meaning of the terms is consistent. To manage common terms, put them in a glossary.
+</p>
+<h5>
+ <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a>
+</h5>
+<p>
+ The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><b>alternative flows of
+ events</b>. The basic flow of events should cover what "normally" happens when the use case is performed. The
+ alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and
+ also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow
+ of events, some of which will return to the basic flow of events and some of which will end the execution of the use
+ case.
+</p>
+<p align="center">
+ <img height="212" alt="Diagram described in caption." src="./resources/ucstrct.gif" width="231" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="picturetext">
+ Figure 2: Typical structure of a use case flow of events
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p class="picturetext">
+ The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
+ relation to the normal. Some alternative paths return to the basic flow of events, whereas, others end the use
+ case.
+</p>
+<p>
+ Both the basic and alternative flows should be further structured into steps or subflows. In doing this, your main goal
+ should be readability of the text (see the <em>Flow of Events - Style</em> section, which follows). A guideline is
+ that a subflow should be a segment of behavior within the use case that has a clear purpose, and is "atomic" in the
+ sense that you do either all or none of the actions described. You may need to have several levels of subflows,
+ but avoid that if you can, since it makes the text more complex and harder to understand.
+</p>
+<p>
+ The nature of this type of written text, structured into consecutive subsections, implies to the reader that there
+ is a sequence between the subflows. To avoid misunderstandings, you should always point out whether the order of the
+ subflows is fixed or not. Considerations of this kind are often related to factors such as:
+</p>
+<ul>
+ <li>
+ <strong>Business rules</strong>. For example, the user has to be authorized before the system can make certain data
+ available.
+ </li>
+ <li>
+ <strong>User-interface design.</strong> For example, the system should not enforce a certain sequence of behavior
+ that may be intuitive to some but not to other users.
+ </li>
+</ul>
+<p>
+ To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
+ detour to the basic flow of events:
+</p>
+<ul>
+ <li>
+ Where the alternative flow can be inserted in the basic flow of events.
+ </li>
+ <li>
+ The condition that needs to be fulfilled for the alternative behavior to start.
+ </li>
+ <li>
+ How and where the basic flow of events is resumed, or how the use case ends.
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
+ </p>
+ <p class="example">
+ 2.1. Bottle Stuck
+ </p>
+ <p class="example">
+ If in section 1.5, Insert Deposit Items, a bottle gets stuck in the gate, the sensors around the gate and the
+ measuring gate will detect this problem. The conveyer belt is stopped and the machine issues an alarm to call for
+ the operator. The machine will wait for the operator to indicate that the problem has been fixed. The machine then
+ continues in section 1.9 of the basic flow.
+ </p>
+</blockquote>
+<p dir="ltr">
+ In the example above, the alternative flow of events is inserted at a specific location in the basic flow of events.
+ There are also alternative flow of events that can be inserted at more than one location, some can even be inserted at
+ any location in the basic flow of events.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
+ </p>
+ <p>
+ 2.2. Front Panel is Removed
+ </p>
+ <p class="example">
+ If somebody removes the front panel to the Recycling machine, the can compression is deactivated. It will not be
+ possible to start the can compression with the front panel off. The removal will also activate an
+ alarm for operator attention. When the front panel is closed again, the machine resumes operation from
+ the point where it stopped in the basic flow of events.
+ </p>
+</blockquote>
+<p>
+ It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
+ section (using some informal "if-then-else" construct). This should be avoided. Too many alternatives will make the
+ normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
+ text more pseudo-code like and harder to read.
+</p>
+<p>
+ In general, extracting parts of the flow of events and describing these parts separately, can increase the readability
+ of the basic flow of events and improve the structure of the use case and the use-case model. You can model extracted
+ parts as the situation requires:
+</p>
+<ul>
+ <li>
+ An <strong>alternative</strong> flow of events within the base use case if it is a simple variant, option, or
+ exception to the basic flow of events.
+ </li>
+ <li>
+ As an <strong>explicit</strong> inclusion in the base use case, if it is something that you wish to encapsulate so
+ that it can be reused by other use cases.
+ </li>
+ <li>
+ As an <strong>implicit</strong> inclusion in the base use case, if the basic flow of events of the base use case is
+ complete, that is, has a defined beginning and end. The nature of the extending flow should be such that you prefer
+ to conceal it in the description of the base use case to render it less complex.
+ </li>
+ <li>
+ A <strong>subflow</strong> in the basic flow of events, possibly as another option, if none of the above
+ alternatives applies. For example, in a Maintain Employee Information use case, there may be separate subflows for
+ adding, deleting and modifying employee information.
+ </li>
+</ul>
+<h5>
+ <a id="Flow of Events - Style" name="Flow of Events - Style">Flow of Events - Style</a>
+</h5>
+<p>
+ You can describe use cases in many styles. As an example we show the basic flow of events of the use case Administer
+ Order described in three different styles, varying primarily in how formal they are.
+</p>
+<p>
+ The first style, shown in Example 1, is the recommended one, because it is easy to understand, and the order in which
+ things happen is clearly evident. The text is divided into numbered and named subsections. Numbers are there to make it
+ easy to refer to a subsection. Names of subsections will let the reader get a quick overview of the flow of events by
+ browsing through the text reading only the headers.
+</p>
+<p>
+ In Example 2, the description of the flow of events fails to clarify the order in which things happen. If you write in
+ this style, you and others might miss important things that concern the system.
+</p>
+<p>
+ Example 3 below shows a yet another style, which can be useful if you find it difficult to express the sequence of
+ events clearly. This pseudo-code style is more precise, but the text is hard to read and absorb for a non-technical
+ person, especially if you want to grasp the flow of events quickly.
+</p>
+<p>
+ Finally, Example 4 provides an example of a complete description of a use case flow of events.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 1:" name="Example 1:"><strong>Example 1:</strong></a> <strong>Recommended style for describing a use
+ case</strong>
+ </p>
+ <p>
+ In this style, the text is easy to read and the flow of events is easy to follow.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <b>1.1. Start of Use Case</b>
+ <p>
+ This use case starts when the actor Operator tells the system to create a measurement order. The
+ system will then retrieve all Network Element actors, their measurement objects and corresponding
+ measurement functions that are available to this particular Operator. Available Network Elements
+ are those that are in operation, and that the Operator has the authority to access. The
+ availability of measurement functions depends on what has been set up for a particular type of
+ measurement object.
+ </p>
+ <p>
+ <b>1.2. Configure Measurement Order</b>
+ </p>
+ <p>
+ The system allows the actor Operator to select which Network Elements to measure and then shows
+ which measurement objects are available for the selected Network Elements. The system allows the
+ Operator to select from the measurement objects, and then select which measurement functions to set
+ up for each measurement object.
+ </p>
+ <p>
+ The system allows the Operator to enter a textual comment on the measurement order.
+ </p>
+ <p>
+ The Operator tells the system to complete the measurement order. The system will respond by
+ generating a unique name for the measurement order and setting up default values for when, how
+ often, and for how long the measurement should be made. The default values are unique to each
+ Operator. The system then allows the Operator to edit these default values.
+ </p>
+ <p>
+ <b>1.3. Initialize Order</b>
+ </p>
+ <p>
+ The Operator tells the system to initialize the measurement order. The system will then record the
+ identity of the creating Operator, the date of creation, and the "Scheduled" status of the
+ measurement order.
+ </p>
+ <p>
+ <b>1.4. Use Case Ends</b>
+ </p>
+ <p>
+ The system confirms initialization of the measurement order to the Operator, and the measurement
+ order is made available for other actors to view.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<div align="center">
+ <br />
+</div>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 2:" name="Example 2:"><strong>Example 2:</strong></a> <strong>Alternative way of describing a use
+ case</strong>
+ </p>
+ <p>
+ This style is readable, but there is no clear flow of events.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ Orderers can create Orders to collect measurement data from the Network Elements.
+ <p>
+ The system will assign the Order a unique name as well as default values that indicate the length
+ and time of the measurement and also how often it is to be repeated. The Orderer will be able to
+ edit these values.
+ </p>
+ <p>
+ The Orderer must further specify which measurement function, network element and measurements
+ objects are applicable. The Orderer can also add a personal comment to the order.
+ </p>
+ <p>
+ When the necessary information had been defined, a new Order is created and initialized with the
+ defined attributes, the name of the creator, and the date of creation. The status of the order will
+ be set to "scheduled". (Possible values for the status are: Scheduled, Executing, Completed,
+ Canceled, and Erroneous.)
+ </p>
+ <p>
+ The user interface is then notified that a new Order has been created and receives a reference to
+ the new Order so that it can be displayed.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 3:" name="Example 3:"><strong>Example 3:</strong></a> <strong>Another way of describing a use
+ case</strong>
+ </p>
+ <p>
+ Here the writer has chosen a formal style using pseudocode. This style makes it hard to quickly grasp the process
+ steps, but can be useful if the flow of events is difficult to capture precisely.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="50%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+<pre>
+<font size="2"><small>'Administrate order' (User identity)
+REPEAT
+ <='Show administer order menu'
+ IF (=> 'Creating an Order' (Measurement function, network element, measurement object)) THEN
+ The system finds a unique name, default values for when and how long the measurement should be executed.
+ <= 'Show order' (Default attributes)
+ REPEAT
+ IF (=> 'Edit order' (Attribute to change, New value of attribute)) THEN
+ <= 'Update screen' (New attributes)
+ ELSIF (=> 'Save order' (Order identity, Attributes)) THEN
+ The order is created and initialized in the system with
+ the defined attributes, the name of the creator,
+ date of creation and the status 'scheduled'.
+ <= 'New order created' (The order)
+ ENDIF
+ UNTIL (=> 'Quit')
+ ENDIF
+UNTIL 'Quit administer order'</small>
+</font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<h5>
+ <a id="Example 3:" name="Example 3:">Example 4:</a> Complete description fo the flow of events
+</h5>
+<p>
+ The complete description of the flow of events of the use case Administer Order, including its alternative flows, could
+ look like the example that follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <b>1. BASIC FLOW OF EVENTS</b>
+ </p>
+ <p>
+ <b>1.1. Start use case</b>
+ </p>
+ <p>
+ This use case starts when the actor Operator tells the system to create a measurement order. The system will then
+ retrieve all Network Element actors, their measurement objects and corresponding measurement functions that are
+ available to this particular Operator. Available Network Elements are those that are in operation, and that the
+ Operator has the authority to access. The availability of measurement functions depends on what has been set up for
+ a particular type of measurement object.
+ </p>
+ <p>
+ <b>1.2. Configure measurement order</b>
+ </p>
+ <p>
+ The system allows the actor Operator to select which Network Elements to measure and then shows which measurement
+ objects are available for the selected Network Elements. The system allows the Operator to select from these
+ measurement objects, and then select which measurement functions to set up for each measurement object.
+ </p>
+ <p>
+ The system allows the Operator to enter a textual comment on the measurement order.
+ </p>
+ <p>
+ The Operator tells the system to complete the measurement order. The system will respond by generating a unique
+ name for the measurement order and setting up default values for when, how often, and for how long the measurement
+ should be made. The default values are unique to each Operator. The system then allows the Operator to edit these
+ default values.
+ </p>
+ <p>
+ <b>1.3. Initialize order</b>
+ </p>
+ <p>
+ The Operator tells the system to initialize the measurement order. The system will then record the identity of the
+ creating Operator, the date of creation, and the "Scheduled" status of the measurement order.
+ </p>
+ <p>
+ <b>1.4. End use case</b>
+ </p>
+ <p>
+ The system confirms initialization of the measurement order to the Operator, and the measurement order is made
+ available for other actors to view.
+ </p>
+ <p>
+ <b>2. ALTERNATIVE FLOW OF EVENTS</b>
+ </p>
+ <p>
+ <b>2.1. No network elements available</b>
+ </p>
+ <p>
+ If in 1.1, Start use case, it turns out that no Network Elements are available to measure for this Operator, the
+ system will inform the Operator. The use case then ends.
+ </p>
+ <p>
+ <b>2.2. No measurement functions available</b>
+ </p>
+ <p>
+ If in 1.2, Configure measurement order, no measurement functions are available for the selected Network Elements,
+ the system will inform the Operator and allow the Operator to select other Network elements.
+ </p>
+ <p>
+ <b>2.3. Cancel measurement order</b>
+ </p>
+ <p>
+ The system will allow the Operator to cancel all actions at any point during the execution of the use case. The
+ system will then return to the state it was in before the use case was started, and end the use case.
+ </p>
+</blockquote>
+<h4>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Special Requirements" name="Special Requirements">Special
+ Requirements</a>
+</h4>
+<p>
+ In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by
+ the flow of events. These are non-functional requirements that will influence the design model. See also the discussion
+ on non-functional requirements in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>. You could organize these requirements in categories such as
+ Usability, Reliability, Performance, and Substitutability, but normally there are so few of them that such grouping is
+ not particularly value-adding.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Example
+ </h5>
+ <p class="example">
+ In the Recycling-Machine System, a special requirement of the Return Deposit Items use case could be:
+ </p>
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="example">
+ The machine has to be able to recognize deposit items with a reliability of more than 95 percent.
+ </p>
+ </blockquote>
+</blockquote>
+<h4>
+ <a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
+</h4>
+<p>
+ A <strong>precondition</strong> is the state of the system and its surroundings that is required before the use case
+ can be started. Post-Conditions are the states the system can be in after the use case has ended. It can
+ be helpful to use the concepts of <b>precondition</b> and <b>post-condition</b> to clarify how the flow of
+ events starts and ends. However, only use them only if the audience for the description of the use case agrees that it
+ is helpful.
+</p>
+<p align="center">
+ <img height="278" alt="Diagram described in caption." src="./resources/ucprepst.gif" width="344" />
+</p>
+<br class="picturetext" />
+<br />
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Figure 3: Illustration of preconditions and resulting post-conditions
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p>
+ Consider the following when specifying preconditions and post-conditions:
+</p>
+<ul>
+ <li>
+ The states described by pre- or post-conditions should be states that the user can observe. "The user has logged on
+ to the system" or "The user has opened the document" are examples of observable states.
+ </li>
+ <li>
+ A precondition is a constraint on when a use case can start. It is not the event that starts the use case.
+ </li>
+ <li>
+ A precondition for a use case is not a precondition for only one subflow, although you can define preconditions and
+ post-conditions at the subflow level.
+ </li>
+ <li>
+ A post-condition for a use case should be true regardless of which alternative flows were executed; it should not
+ be true only for the main flow. If something could fail, you would cover that in the post-condition by saying "The
+ action is completed, or if something failed, the action is not performed", rather than just "The action is
+ completed".
+ </li>
+ <li>
+ When you use post-conditions together with <em>extend</em> relationships, you should take care that the extending
+ use case does not introduce a subflow that violates the post-condition in the base use case.
+ </li>
+ <li>
+ Post-conditions can be a powerful tool for describing use cases. You first define what the use case is supposed to
+ achieve, which is the post-condition. You can then describe the necessary flow of events, or how to reach this
+ condition.
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ Examples
+ </p>
+ <p class="example">
+ <strong>A precondition for the use case Cash Withdrawal in the ATM machine:</strong> The customer has a personally
+ issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
+ </p>
+ <p class="example">
+ <strong>A pos-tcondition for the use case Cash Withdrawal in the ATM machine:</strong> At the end of the use case,
+ all account and transaction logs are balanced, communication with the banking system is reinitialized and the card
+ is returned to the customer.
+ </p>
+</blockquote>
+<h4>
+ <a id="Extension Points" name="Extension Points">Extension Points</a>
+</h4>
+<p>
+ An <b>extension point</b> opens up the use case to the possibility of an extension. It has a name and a list of
+ references to one or more locations within the flow of events of the use case. An extension point may reference a
+ single location between two behavior steps within the use case. It may also reference a set of discrete locations.
+</p>
+<p>
+ Using named extension points will help you separate the specification of the behavior of the extending use case
+ from the internal details of the base use case. The base use case can be modified or rearranged, as long as the names
+ of the extension points remain the same, it will not affect the extending use case. At the same time, you are not
+ complicating the text describing the flow of events of the base use case with details of where behavior might be
+ extended into it.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In a phone system, the use case Place Call can be extended by the abstract use case Show Caller Identity. This is
+ an optional service, often referred to as "Caller ID", that may or may not have been requested by the receiving
+ party. A description of the extension point in the use case Place Call could look like the following:
+ </p>
+ <p class="example">
+ <b>Name</b>: Show Identity
+ </p>
+ <p class="example">
+ <b>Location</b>: After section 1.9 Ring Receiving Party's Telephone.
+ </p>
+</blockquote>
+<h3>
+ Specifying Use Cases
+</h3>
+<h4>
+ <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a>
+</h4>
+<p>
+ See the <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a> for guidance on finding Actors
+ and Use Cases.
+</p>
+<h4>
+ <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a>
+</h4>
+<p>
+ See the <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a> for guidance on evolving use cases.
+</p>
+<h4>
+ Level of detail necessary in use cases
+</h4>
+<p>
+ There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
+ of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
+ disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
+ the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
+ of some data from the system.
+</p>
+<p>
+ For more information on possible formats and level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
+</p>
+<h4>
+ <a id="XE_use_case__scope_of_a_use_case" name="XE_use_case__scope_of_a_use_case"></a><a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a>
+</h4>
+<p>
+ It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
+ use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
+ machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
+ exchange this receipt for money.
+</p>
+<p>
+ Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
+ There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
+ with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
+ complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
+ case of use, a use case.
+</p>
+<p>
+ Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
+ together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
+ larger systems.
+</p>
+<h3>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Use-Case Diagrams" name="Use-Case Diagrams">Use-Case Diagrams</a>
+</h3>
+<p>
+ You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual
+ cases, more than one diagram). This is useful if the use case is involved with many actors, or has relationships to
+ many other use cases. A diagram of this kind is of "local" character, since it shows the use-case model from the
+ perspective of one use case only and is not intended to explain any general facts about the whole use-case model. Refer
+ to <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.<br />
+</p><!-- END:mainDescription,-BQLZ5GRUNrMdU6XeZAfe9Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/use_case_model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/use_case_model.html
new file mode 100644
index 0000000..dd078d2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/use_case_model.html
@@ -0,0 +1,195 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\use_case_model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case_model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2jyfUAhVEduRe8TeoBmuGg CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_2jyfUAhVEduRe8TeoBmuGg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_2jyfUAhVEduRe8TeoBmuGg CRC: 3816755173 -->This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team.<!-- END:briefDescription,_2jyfUAhVEduRe8TeoBmuGg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-yEWkrWZ3VUcjZPhq6bvScg CRC: 2974070851 --><h3>
+ Explanation
+</h3>
+<p>
+ A use-case model is a model of how different types of users interact with the system to solve a problem. As such,
+ it describes the goals of the users, the interactions between the users and the system, and the required behavior of
+ the system in satisfying these goals.
+</p>
+<p>
+ A use-case model consists of a number of model elements. The most important model elements are: use cases, actors
+ and the relationships between them.
+</p>
+<p>
+ A use-case diagram is used to graphically depict a subset of the model to simplify communications. There will
+ typically be several use-case diagrams associated with a given model, each showing a subset of the model elements
+ relevant for a particular purpose. The same model element may be shown on several use-case diagrams, but each
+ instance must be consistent. If tools are used to maintain the use-case model, this consistency constraint is
+ automated so that any changes to the model element (changing the name for example) will be automatically reflected on
+ every use-case diagram that shows that element.
+</p>
+<p>
+ The use-case model may contain packages that are used to structure the model to simplify analysis, communications,
+ navigation, development, maintenance and planning.
+</p>
+<p>
+ Much of the use-case model is in fact textual, with the text captured in the <a class="elementLink"
+ href="./../../../openup_basic/guidances/templates/uc_specification,_0cpNwMlgEdmt3adZL5Dmdw.html"
+ guid="_0cpNwMlgEdmt3adZL5Dmdw">Use-Case Specification</a>s that are associated with each use-case model
+ element. These specifications describe the flow of events of the use case.
+</p>
+<p>
+ The use-case model serves as a unifying thread throughout system development. It is used as the primary specification
+ of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning,
+ as the basis of defining test cases and as the basis for user documentation
+</p>
+<h3>
+ Basic model elements
+</h3>
+<p>
+ The use-case model contains, as a minimum, the following basic model elements.
+</p>
+<h4>
+ Actor
+</h4>
+<p>
+ A model element representing each actor. Properties include the actors name and brief description. See <a
+ class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information.
+</p>
+<h4>
+ Use Case
+</h4>
+<p>
+ A model element representing each use case. Properties include the use case name and use case specification. See
+ <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for more information.
+</p>
+<h4>
+ Associations
+</h4>
+<p>
+ Associations are used to describe the relationships between actors and the use cases they participate in. This
+ relationship is commonly known as a “communicates-association”.
+</p>
+<h3>
+ Advanced model elements
+</h3>
+<p>
+ The use-case model may also contain the following advanced model elements.
+</p>
+<h4>
+ Subject
+</h4>
+<p>
+ A model element that represents the boundary of the system of interest.
+</p>
+<h4>
+ Use-Case Package
+</h4>
+<p>
+ A model element used to structure the use case model to simplify analysis, communications, navigation, and
+ planning. If there are many use cases or actors, you can use use-case packages to further structure the use-case
+ model in much the same manner you use folders or directories to structure the information on your hard-disk.
+</p>
+<p>
+ You can partition a use-case model into use-case packages for several reasons, including:
+</p>
+<ul>
+ <li>
+ To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
+ </li>
+ <li>
+ To support parallel development by dividing the problem into bite-sized pieces.
+ </li>
+ <li>
+ To simplify communication with different stakeholders by creating packages for containing use cases and actors
+ relevant to a particular stakeholder.
+ </li>
+</ul>
+<h4>
+ Generalizations
+</h4>
+<p>
+ A relationship between actors to support re-use of common properties.
+</p>
+<h4>
+ Dependencies
+</h4>
+<p>
+ A number of dependency types between use cases are defined in UML. In particular, <<extend>> and
+ <<include>>.
+</p>
+<p>
+ <<extend>> is used to include optional behavior from an extending use case in an extended use case.
+</p>
+<p>
+ <<include>> is used to include common behavior from an included use case into a base use case in order to
+ support re-use of common behavior.
+</p>
+<p>
+ The latter is the most widely used dependency and is useful for:
+</p>
+<ul>
+ <li>
+ Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of
+ the use case to simplify communications.
+ </li>
+ <li>
+ Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and
+ ensure consistency.
+ </li>
+</ul>
+<h3>
+ Example Use-Case Diagram
+</h3>
+<p>
+ Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
+</p>
+<p>
+ <img height="410" alt="Figure 1: ATM Use-Case Diagram" src="./resources/ATMUCdiagram.GIF" width="565" />
+</p>
+<p>
+ Figure 1: ATM Use-Case Diagram
+</p>
+<p>
+ This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use
+ cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three <<includes>>
+ dependencies, and the associations between the performing actors and the use cases.
+</p>
+<p>
+ The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to
+ the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use
+ cases <<include>>. The base use cases are independent of the method used for identification, and it is
+ therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter
+ whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on
+ the result of Validate Customer.
+</p>
+<p>
+ Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions
+ of each actor, descriptions of each use case, and use-case specifications for each use case. For a more complete
+ example of this use case model see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/examples/uc_model_evolve,_t4QdAMNqEdu2IdAIaWZyAw.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: Evolution of the Use-Case Model</a>.<br />
+</p><!-- END:mainDescription,-yEWkrWZ3VUcjZPhq6bvScg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/visual_modeling.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/visual_modeling.html
new file mode 100644
index 0000000..8e435f3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/visual_modeling.html
@@ -0,0 +1,173 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\visual_modeling.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: visual_modeling.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0XY6UMlgEdmt3adZL5Dmdw CRC: 689168066 -->Visual Modeling<!-- END:presentationName,_0XY6UMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0XY6UMlgEdmt3adZL5Dmdw CRC: 3679078480 -->This concept introduces the use of semantically rich graphical and textual design notations to capture software designs.<!-- END:briefDescription,_0XY6UMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_SB1n8MM1EdmSIPI87WLu3g CRC: 3857679696 --><p align="center">
+ <img height="229" alt="visual modelling" src="./resources/visual.gif" width="447" />
+</p>
+<p align="center">
+ Visual modeling raises the level of abstraction
+</p>
+<p>
+ Visual modeling is the use of semantically rich, graphical and textual design notations to capture software designs. A
+ notation, such as UML, allows the level of abstraction to be raised, while maintaining rigorous syntax and semantics.
+ In this way, it improves communication in the team as the design is formed and reviewed, allowing the reader to reason
+ about the design, and it provides an unambiguous basis for implementation.
+</p>
+<h3>
+ How visual models help
+</h3>
+<p>
+ A model is a simplified view of a system. It shows the essentials of the system from a particular perspective and hides
+ the nonessential details. Visual models help you:
+</p>
+<ul>
+ <li>
+ Increase understanding of complex systems
+ </li>
+ <li>
+ Explore and compare design alternatives at a low cost
+ </li>
+ <li>
+ Form a foundation for implementation
+ </li>
+ <li>
+ Capture requirements precisely
+ </li>
+ <li>
+ Communicate decisions unambiguously
+ </li>
+</ul>
+<h4>
+ Increase understanding of complex systems
+</h4>
+<p>
+ The importance of models increases as systems become more complex. For example, you can build a doghouse without
+ blueprints. However, as you progress to building houses and then to skyscrapers, your need for blueprints becomes
+ pronounced.
+</p>
+<p>
+ Similarly, a small application built by one person in a few days may be easily understood in its entirety. However, an
+ e-commerce system with tens of thousands of source lines of code (SLOCs) or an air traffic control system with hundreds
+ of thousands of SLOCs can no longer be easily understood by one person. Constructing models allows a developer to focus
+ on the big picture, understand how components interact, and identify fatal flaws.
+</p>
+<p>
+ Among the various types of models are these examples:
+</p>
+<ul>
+ <li>
+ Use cases to specify behavior unambiguously
+ </li>
+ <li>
+ Class diagrams and data model diagrams to capture design
+ </li>
+ <li>
+ State transition diagrams to model dynamic behavior
+ </li>
+</ul>
+<p>
+ Modeling is important because it helps the team visualize, construct, and document the structure and behavior of the
+ system without getting lost in complexity.
+</p>
+<h4>
+ Explore and compare design alternatives at a low cost
+</h4>
+<p>
+ You can create and modify simple models inexpensively to explore design alternatives. Innovative ideas can be captured
+ and reviewed by other developers before investing in costly code development. When coupled with iterative development,
+ visual modeling helps developers assess design changes and communicate these changes to the entire development team.
+</p>
+<h4>
+ Form a foundation for implementation
+</h4>
+<p>
+ Today, many projects employ object-oriented programming languages to build reusable, change-tolerant, and stable
+ systems. To get these benefits, it is even more important to use object technology in design.
+</p>
+<p>
+ The creation of visual models, whether on paper; around a whiteboard; or in a modeling tool, can help a team to gain
+ agreement on key aspects of the system before investing time in proving their ideas with code. Having a shared model of
+ the system promotes collaboration within the team, encouraging everyone to work towards the same goal.
+</p>
+<p>
+ With the support of appropriate tools, you can use a design model to generate an initial code for implementation. This
+ is referred to as <strong>forward engineering</strong> or <strong>code generation</strong>. You can also enhance design
+ models to include enough information to build the system.
+</p>
+<p>
+ <strong>Reverse engineering</strong> may also be applied to generate design models from existing implementations. You
+ can use this method to evaluate existing implementations.
+</p>
+<p>
+ <strong>Round-trip engineering</strong> combines both forward and reverse engineering techniques to ensure consistent
+ design and code. Combined with an iterative process and the right tools, round-trip engineering allows you to
+ synchronize the design and code during each iteration.
+</p>
+<h4>
+ Capture requirements precisely
+</h4>
+<p>
+ Before building a system, it's critical to capture the requirements. Specifying the requirements using a precise and
+ unambiguous model helps to ensure that all stakeholders can understand and agree on the requirements.
+</p>
+<p>
+ A model that separates the external behavior of the system from the implementation of it helps you focus on the
+ intended use of the system, without getting bogged down in implementation details.
+</p>
+<h4>
+ Communicate decisions unambiguously
+</h4>
+<p>
+ The Unified Modeling Language (UML) is a consistent notation that can be applied for system engineering, as well
+ as for business engineering. According to these excerpts from the UML specification, a standard notation:
+</p>
+<ul>
+ <li>
+ <p>
+ Serves as a language for communicating decisions that are not obvious or cannot be inferred from the code
+ itself.
+ </p>
+ </li>
+ <li>
+ <p>
+ Provides semantics that are rich enough to capture all important strategic and tactical decisions.
+ </p>
+ </li>
+ <li>
+ <p>
+ Offers a form concrete enough for humans to reason [about] and for tools to manipulate.
+ </p>
+ </li>
+</ul>
+<p>
+ UML represents the convergence of the best practice in software modeling throughout the object-technology industry. For
+ more information on the UML, see <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[UML05]</a>.
+</p><!-- END:mainDescription,_SB1n8MM1EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/workspace.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/workspace.html
new file mode 100644
index 0000000..f7fc0d2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/concepts/workspace.html
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\concepts\workspace.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: workspace.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0cEmAMlgEdmt3adZL5Dmdw CRC: 258310842 -->Workspace<!-- END:presentationName,_0cEmAMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0cEmAMlgEdmt3adZL5Dmdw CRC: 1586362847 -->Workspace refers to storage areas where developers can implement and test code in accordance with the project's adopted standards in relative isolation from other developers.<!-- END:briefDescription,_0cEmAMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Dfmk8MPiEdmbOvqy4O0adg CRC: 2689502876 --><p align="left">
+ On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
+ conflicts.
+</p>
+<p align="left">
+ A better approach is for each developer to have a reasonably private area for the development and testing of their work
+ products. This workspace should be insulated so that destabilizing or conflicting changes made by others do not
+ interfere with progress. However, it should not be isolated to the extent that the developer's work is
+ unavailable to the team.
+</p>
+<p align="left">
+ In addition, insulated workspaces can be created for each test phase, such as integration testing and system
+ testing. This approach to workspaces provides several benefits <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[WIB04]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ Developers can develop, test, and debug software changes without being affected by others team
+ members' changes until they are ready. When ready, developers can update their insulated environments to
+ test the latest changes from other developers.
+ </p>
+ </li>
+ <li>
+ <p>
+ With separate workspaces for integration and system testing, a team could use a methodology that ensures
+ changes have passed integration testing before other developers get them, thereby minimizing the time spent
+ solving integration problems. For example, if two team members check in incompatible changes without
+ realizing it, and both changes are immediately available to everyone on the team, all team members might
+ waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
+ being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
+ team.
+ </p>
+ </li>
+ <li>
+ <p>
+ By setting up an integration area to collect and build the latest changes, the team can integrate early and
+ often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
+ </p>
+ </li>
+ <li>
+ <p>
+ The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
+ contains only configurations that have passed integration testing. This lets you control the content of the
+ release while still enabling developers to continue working.
+ </p>
+ </li>
+</ul><!-- END:mainDescription,_Dfmk8MPiEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/iteration_plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/iteration_plan.html
new file mode 100644
index 0000000..73e7bc5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/iteration_plan.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\examples\iteration_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_TuNhIEE4EdulKujnGUuxbg CRC: 3699738420 -->Iteration Plan<!-- END:presentationName,_TuNhIEE4EdulKujnGUuxbg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_TuNhIEE4EdulKujnGUuxbg CRC: 3609547278 -->This is an example of an iteration plan for iteration 5 for a small team. In this example, the team has chosen not to list work items in the iteration plan. Instead, the team will search the work items list for work items assigned to iteration 5. This is the preferred solution when work items are managed in a tool that provides basic search capabilities.<!-- END:briefDescription,_TuNhIEE4EdulKujnGUuxbg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-nDr0XNiUWBo6VS1YS6KAqA CRC: 4044771621 --><a href="./resources/ex_iteration_plan.doc" target="_blank">ex_iteration_plan.doc</a><!-- END:mainDescription,-nDr0XNiUWBo6VS1YS6KAqA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/project_plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/project_plan.html
new file mode 100644
index 0000000..2a3d3e3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/project_plan.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\examples\project_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Nzv5kDoAEdusGsHODb-STA CRC: 659198141 -->Project Plan<!-- END:presentationName,_Nzv5kDoAEdusGsHODb-STA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Nzv5kDoAEdusGsHODb-STA CRC: 1143150207 -->This is an example of a project plan.<!-- END:briefDescription,_Nzv5kDoAEdusGsHODb-STA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-IdlCQXdDNYGrGJU4TBwvCA CRC: 3657948713 --><p>
+ This example is the actual project plan used for the development of OpenUP/Basic.
+</p>
+<p>
+ <a href="./resources/project_plan.doc" target="_blank">project_plan.doc</a>
+</p><!-- END:mainDescription,-IdlCQXdDNYGrGJU4TBwvCA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/ex_iteration_plan.doc b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/ex_iteration_plan.doc
new file mode 100644
index 0000000..5802f01
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/ex_iteration_plan.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/ex_work_items_list.xls b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/ex_work_items_list.xls
new file mode 100644
index 0000000..234f2a5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/ex_work_items_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/project_plan.doc b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/project_plan.doc
new file mode 100644
index 0000000..5b4a2f6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/resources/project_plan.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/uc_model_evolve.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/uc_model_evolve.html
new file mode 100644
index 0000000..77ccfa2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/uc_model_evolve.html
@@ -0,0 +1,142 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\examples\uc_model_evolve.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uc_model_evolve.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_t4QdAMNqEdu2IdAIaWZyAw CRC: 3589190891 -->Evolution of the Use-Case Model<!-- END:presentationName,_t4QdAMNqEdu2IdAIaWZyAw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_t4QdAMNqEdu2IdAIaWZyAw CRC: 3494959854 -->This example illustrates how the use-case model evolves over time when using a &quot;breadth before depth&quot; approach to maximize value and minimize risk early in the lifecycle and to minimize re-work later.<!-- END:briefDescription,_t4QdAMNqEdu2IdAIaWZyAw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-JviMIao63C7w9C8W6iPJrw CRC: 17925949 --><h3>
+ Introduction
+</h3>
+<p>
+ This example illustrates how the use-case model and associated use-case specification will evolve during the
+ lifecycle. It shows the state of the use case model at two points in the lifecycle: early inception and towards
+ the end of elaboration. The purpose is to illustrate how one would <a class="elementLink"
+ href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find and Outline Requirements</a> and <a class="elementLink"
+ href="./../../../openup_basic/tasks/detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw.html"
+ guid="_0e1mIMlgEdmt3adZL5Dmdw">Detail Requirements</a> so as to maximize stakeholder value and minimize risk early in
+ the project as well as to minimize re-work later.
+</p>
+<p>
+ The example uses an Automated Teller Machine as the example system because it is familiar to most people. This
+ familiarity simplifies understanding the principles without getting lost in domain specific terminology.
+</p>
+<h4>
+ Early Inception
+</h4>
+<p>
+ Assume you have just started on the project as the Analyst. You have identified the key stakeholders and met with
+ them to discuss their needs. During your meetings, you identified a number of key actors, use cases and
+ supporting requirements for the ATM system. You captured the use cases and actors, with names and brief
+ descriptions only, in the use-case model. An example of this work is given in the document <a
+ href="./resources/ATM%20UC%20Model%20Inception.doc" target="_blank">ATM UC Model Inception.doc</a>.
+</p>
+<p>
+ Prior to committing significant time to detailing these use cases now, you recognize that a “breadth before depth”
+ approach can save you valuable time and permit you to identify the highest value and/or highest risk items so you can
+ concentrate on those first.
+</p>
+<p>
+ You hold a brainstorming session with the stakeholders and outline the basic flow of each of the main use cases.
+ As you are working through, you may identify some additional alternative flows. Fight the urge to “dive-in” to
+ the details on these alternative flows at this point, simply list them and come back later when you have a better
+ understanding of the “big picture”.
+</p>
+<p>
+ Examples of the notes you took during this exercise are attached below. (Note the choice of font is intentional to
+ illustrate that these are notes, not formal documents).
+</p>
+<p>
+ <a href="./resources/Withdraw%20Cash%20Outline.doc" target="_blank">Withdraw Cash Outline.doc</a>
+</p>
+<p>
+ <a href="./resources/Deposit%20Funds%20Outline.doc" target="_blank">Deposit Funds Outline.doc</a>
+</p>
+<p>
+ <a href="./resources/Transfer%20Funds%20Outline.doc" target="_blank">Transfer Funds Outline.doc</a>
+</p>
+<p>
+ Reviewing your notes, you recognize that there is some behavior that is common to most of the use cases, namely the
+ steps required to validate the Bank Customer. Factoring this behavior out into an <<included>> use
+ case will simplify communications, iteration planning, and maintenance.
+</p>
+<p>
+ You update the use case model accordingly: <a href="./resources/ATM%20UC%20Model%20Elaboration.doc" target="_blank">ATM
+ UC Model Elaboration.doc</a>.
+</p>
+<h4>
+ Elaboration
+</h4>
+<p>
+ With a better understanding of the system, you can now prioritize your effort to maximize value and minimize
+ risk. You start by detailing the common behavior captured in the use case: Validate User. This use case
+ captures key architectural requirements that will exercise a significant portion of the system (communications with the
+ Bank, card reader interface, etc.). Implementing this one key scenario will go a long way to reducing risk.
+</p>
+<p>
+ An example of the Validate User Specification is given below:<br />
+ <br />
+ <a href="./resources/Use%20Case%20Spec%20-%20Validate%20User.doc" target="_blank">Use Case Spec - Validate
+ User.doc</a>
+</p>
+<p>
+ Note that there may still be some un-answered questions, but that’s OK. Capture these directly in the use-case
+ specification and get them answered (see Section 5.6 of the Validate User UC Specification, above for an example).
+</p>
+<p>
+ Continuing with another architecturally significant thread, you detail the basic flow and some key alternate flows of
+ the use case: Withdraw Cash. You know that if the team can implement this, much of the other functionality will
+ be low risk.
+</p>
+<p>
+ An example of the Withdraw Cash Specification is given below:
+</p>
+<p>
+ <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use Case Spec - Withdraw Cash.doc</a>
+</p>
+<h3>
+ Summary
+</h3>
+<p>
+ By following a breadth before depth approach to outlining and detailing use cases one can make better decisions on
+ priorities. Start by identifying actors. Then for each actor, ask “What is the main purpose this actor
+ would like to use the system?”. This will lead to the identification of the use cases. Capture the actors
+ and use cases in the use-case model along with a brief description.
+</p>
+<p>
+ Prioritize the use cases, and then draft the main scenario or basic flow. As you are working through this you may
+ identify alternate flows (what can go wrong, what options are available, etc.). Capture these, along with a brief
+ description.
+</p>
+<p>
+ Review the use-case model and reprioritize and assess risk. For the high priority (based on value to the
+ stakeholders) and/or high risk use cases detail the main scenario and the critical alternate flows.
+</p>
+<p>
+ If you follow this approach, you will increase the likelihood of delivering value early, minimizing risk, and
+ minimizing re-work.<br />
+
+</p><!-- END:mainDescription,-JviMIao63C7w9C8W6iPJrw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/use_case_spec.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/use_case_spec.html
new file mode 100644
index 0000000..ba9f676
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/use_case_spec.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\examples\use_case_spec.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case_spec.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_JLOiIMNvEdu2IdAIaWZyAw CRC: 2598744912 -->Use-Case Specification<!-- END:presentationName,_JLOiIMNvEdu2IdAIaWZyAw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_JLOiIMNvEdu2IdAIaWZyAw CRC: 1520810480 -->This is an example of a completed use-case specification for the Withdraw Cash use case for an Automated Teller Machine.<!-- END:briefDescription,_JLOiIMNvEdu2IdAIaWZyAw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qq-9Brh5oa6H3lsdp-m8mQ CRC: 985189096 --><p>
+ The attached document provides an example of a use-case specification for an Automated Teller Machine (ATM). The
+ ATM was selected as an example system since it is familiar to most people. This familiarity simplifies
+ understanding the principles without getting lost in domain specific terminology.
+</p>
+<p>
+ Example use-case specification: <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use
+ Case Spec - Withdraw Cash.doc</a>
+</p>
+<p>
+ A companion example, <a class="elementLink"
+ href="./../../../openup_basic/guidances/examples/uc_model_evolve,_t4QdAMNqEdu2IdAIaWZyAw.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Evolution of the Use-Case Model</a>, shows how the use-case model as a whole evolves
+ over time.<br />
+</p><!-- END:mainDescription,-qq-9Brh5oa6H3lsdp-m8mQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/work_items_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/work_items_list.html
new file mode 100644
index 0000000..faf3ab9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/work_items_list.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\examples\work_items_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_items_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_nHomIDgzEdu4E8ZdmlYjtA CRC: 699774998 -->Work Items List<!-- END:presentationName,_nHomIDgzEdu4E8ZdmlYjtA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_nHomIDgzEdu4E8ZdmlYjtA CRC: 1193985585 -->This is an example of a partial Work Items List for a small team who just started to work on iteration 3.<!-- END:briefDescription,_nHomIDgzEdu4E8ZdmlYjtA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qunTPN3vqTIGpELwajXpLA CRC: 2031175364 --><a href="./resources/ex_work_items_list.xls" target="_blank">ex_work_items_list.xls</a><!-- END:mainDescription,-qunTPN3vqTIGpELwajXpLA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/abstract_away_complexity.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/abstract_away_complexity.html
new file mode 100644
index 0000000..f9c1f65
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/abstract_away_complexity.html
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\abstract_away_complexity.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: abstract_away_complexity.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_we3F4ACpEdu8m4dIntu6jA CRC: 1456285935 -->Abstract Away Complexity<!-- END:presentationName,_we3F4ACpEdu8m4dIntu6jA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-X7QSjItNBz7w8603yBCv0Q CRC: 2087353359 --><p>
+ Software development is a pursuit characterized by complexity. This can take many forms, such as accommodating
+ complex requirements, technology, or team dynamics. Elevating the level of abstraction helps you manage this complexity
+ and make measurable progress, despite the inherent difficulty of the task.
+</p>
+<p>
+ Suggestions for several strategies that help abstract away complexity follow.
+</p>
+<h4>
+ Leverage patterns
+</h4>
+<p>
+ Patterns help you take advantage of proven techniques for solving common problems. You can benefit from the experience
+ of seasoned practitioners and avoid "re-inventing the wheel," as the saying goes. The use of patterns is a crucial
+ aspect of an architecture-centric approach to development, because it helps reduce the novelty and diversity of a
+ solution, thus improves quality.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/pattern,_0YJvUMlgEdmt3adZL5Dmdw.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a> for more information.
+</p>
+<h4>
+ Design the architecture with components and services
+</h4>
+<p>
+ This strategy helps manage software complexity through partitioning a system into a set of loosely coupled
+ and highly cohesive subsystems. The benefits of this approach include the ability to organize the team around a set of
+ smaller, more manageable objectives, and the ability to substitute parts of the system without disturbing the overall
+ cohesion of the system. Exposing services encourages re-use by making the functionality of the system easier to
+ comprehend. Focusing on services makes it possible to understand what the system does from a technical perspective
+ without necessarily having to understand the details of how the system works.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/component,_0YP18MlgEdmt3adZL5Dmdw.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a> for more information.
+</p>
+<h4>
+ Actively promote reuse
+</h4>
+<p>
+ Incorporating existing software into an overall architecture helps reduce cost and improve quality by reusing proven
+ working software, rather than developing from scratch. It also helps reduce the burden of maintenance by eliminating
+ duplication in the software. Although often difficult to manage, a project or enterprise can reap significant benefits
+ from a well-executed re-use strategy.
+</p><!-- END:mainDescription,-X7QSjItNBz7w8603yBCv0Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/abstract_away_complexity_vm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/abstract_away_complexity_vm.html
new file mode 100644
index 0000000..30b083f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/abstract_away_complexity_vm.html
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\abstract_away_complexity_vm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: abstract_away_complexity_vm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-OcMsciNn-UtD9fTHj26LGA CRC: 65919989 --><h4>
+ Model key perspectives
+</h4>
+<p>
+ Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
+ illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
+ software. The Unified Modeling Language (UML) provides an industry-standard approach to software modeling.
+</p>
+<p>
+ When applying this strategy, you can use various techniques:
+</p>
+<ul>
+ <li>
+ <strong>Identify the key perspectives:</strong> Focus on modeling the things that count. Few (if any) projects
+ benefit from modeling the entire design to a great level of detail. Make sure that you understand why you are
+ modeling something and who will benefit.
+ </li>
+ <li>
+ <strong>Communicate key architectural perspectives:</strong> Even if you choose to model very little of your
+ design, it is often advantageous to produce diagrams that communicate the key architectural aspects of the system.
+ Conveying the "big picture" to the rest of the team helps them understand the overall approach and develop cohesive
+ software.
+ </li>
+ <li>
+ <strong>Sketch the design:</strong> Not all models need to be detailed completely and presented in a software
+ modeling tool. It is often perfectly acceptable (if not desirable) to produce hand-drawn sketches on paper or on a
+ whiteboard when you are exploring and communicating the architecture and design with your team. You can use a
+ digital camera or an electronic whiteboard to capture these diagrams and share them. For many small projects, this
+ is often all you need. See <a href="http://www.agilemodeling.com/">http://www.agilemodeling.com/</a> for more
+ information.
+ </li>
+ <li>
+ <strong>Use a modeling tool as needed</strong>: If the team members are changing models throughout the
+ project, sharing patterns/structure, debugging design, describing behavior, etc., then static photos or paper will
+ become difficult to work with. The team may want to capture design in a software modeling tool. Other than
+ communicating the design to the team, another benefit of a such a tool is the generation of structural code
+ from the models. Many software development tools allow you to view the code as models, making it easier to
+ comprehend static and dynamic aspects of a complex code base.
+ </li>
+ <li>
+ <strong>Agree on a standard notation:</strong> In a team environment, it is important that others can understand
+ your diagrams without much explanation. Choosing a standard notation enables others to quickly comprehend your
+ diagrams without ambiguity. The Unified Modeling Language is an example of a widely understood notation.
+ </li>
+</ul><!-- END:mainDescription,-OcMsciNn-UtD9fTHj26LGA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_and_unified.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_and_unified.html
new file mode 100644
index 0000000..a087620
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_and_unified.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\agile_and_unified.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: agile_and_unified.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qg1IAK__EduMeuOwJ2MpeQ CRC: 882689237 -->Agile and Unified<!-- END:presentationName,_qg1IAK__EduMeuOwJ2MpeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_qg1IAK__EduMeuOwJ2MpeQ CRC: 4200393008 -->OpenUP/Basic is a Unified process that incorporates proven agile techniques. The result is a robust, effective, and lightweight process structure.<!-- END:briefDescription,_qg1IAK__EduMeuOwJ2MpeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-l-ZsqrXu2nmVE1giLpI6iw CRC: 3662425856 -->Describe differences between unified processes and Agile methods<br />
+Describe how OpenUP is a Unified Process that incorporates some Agile<br />
+methods that have proven effective<br />
+Describe what Agile elements are incorporated into OpenUP<!-- END:mainDescription,-l-ZsqrXu2nmVE1giLpI6iw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_estimation.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_estimation.html
new file mode 100644
index 0000000..375798b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/agile_estimation.html
@@ -0,0 +1,157 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\agile_estimation.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: agile_estimation.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_CGHskBEdEdqY7JB6N6CW2w CRC: 1236859462 -->Agile Estimation<!-- END:presentationName,_CGHskBEdEdqY7JB6N6CW2w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_CGHskBEdEdqY7JB6N6CW2w CRC: 1733553587 -->This guideline explains three key concepts, and their interrelationships, for doing agile estimation; estimation of size, velocity, and estimation of effort.<!-- END:briefDescription,_CGHskBEdEdqY7JB6N6CW2w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_CYRMgBEdEdqY7JB6N6CW2w CRC: 1918863300 --><h3>
+ Agile Estimation
+</h3>
+<p>
+ There are three main concepts you need to understand to do agile estimation:
+</p>
+<ul>
+ <li>
+ <strong>Estimation of Size</strong> gives you a high-level estimate for the work item, typically measured using a
+ neutral unit such as points
+ </li>
+ <li>
+ <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
+ </li>
+ <li>
+ <strong>Estimation of Effort</strong> translates the size (measured in points) to a detailed estimate of effort
+ typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take
+ the team member(s) assigned to the work item to do the work.
+ </li>
+</ul>
+<h4>
+ Estimation of Size
+</h4>
+<p>
+ Agile estimation of size is typically done using a relative measure called <strong>points</strong>. You decide
+ how big a point is, and based on that size, you determine how many points each work item is. To make estimation go
+ fast, you want to use only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65
+ points. To get started, look at 10 or so representative work items, give the smallest the size of one point, and then
+ go through all other work items and give them a relative point estimate based on that point. Note that points are used
+ for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of
+ lower priority, since you would then waste effort on things that are unlikely to be addressed within the current
+ iteration.
+</p>
+<p>
+ A key benefit of points is that they are neutral and relative. Let’s say that Ann is 3 times more productive than Jack.
+ If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,
+ they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours,
+ while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do
+ it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use
+ Velocity to determine how much ‘size’, or how many points, the team can take on within an iteration.
+</p>
+<p>
+ One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the
+ same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project.
+ You want to make sure that the entire team is involved in assessing size, or at least that the same people are
+ involved in all your size estimates, to ensure consistency within your project. We will see how the concept of velocity
+ will fix also this discrepancy in a point meaning different things to different project teams.
+</p>
+<p>
+ You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
+</p>
+<h4>
+ Velocity
+</h4>
+<p>
+ Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an
+ iteration for a certain team and project. As an example, a team may plan for taking on 20 points in the first
+ iteration. At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence
+ 14. For the next iteration, they may plan for fewer points, let’s say 18 points, since they think they can do a little
+ better than in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.
+</p>
+<p>
+ You should expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and
+ points are not always identical in terms of effort. Some team members are more effective than others, and some problems
+ end up being harder than others. Also, changes to the team structure, learning new skills, changes to the tool
+ environment, better teaming, or more overhead with meetings or tasks external to the project will all impact velocity.
+ In general, velocity typically increases during tha project as the team builds skills and becomes more cohesive.
+</p>
+<p>
+ Velocity compensates for differences between teams in terms of how big a point is. Let’s assume that project team Alpha
+ and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team
+ Alpha, however, assesses all work items as being worth 3 times as many points. Team Alpha assesses work item A, B, C,
+ and D to correspond to 30 points, and team Beta estimates the same work items to correspond to 10 points. Both teams
+ deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and team Beta a velocity of
+ 10. It may sound as if team Alpha is more effective, but let’s look at what happens when they plan the next iteration.
+ They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and team Beta as normal has
+ estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many points as indicated by
+ their velocity, they can both take on all of E-H. The end result is that it does not matter how big a point is, as long
+ as you are consistent within your team.
+</p>
+<p>
+ Velocity also averages out the efficiency of different team members. Let’s look at an example; Let’s assume that Ann
+ always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3
+ points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may
+ not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since
+ the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.
+ As you switch team members, or as team members become more or less efficient, your velocity will change, and you can
+ hence take on more or less points. This does however not require you to change the estimate of the size. The size is
+ still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand
+ for that iteration.
+</p>
+<h4>
+ Estimation of Effort
+</h4>
+<p>
+ As you plan an iteration, you will take on a work item, such as detail, design, implement and test a scenario, which
+ may be sized to 5 points. Typically you at this time break down this still reasonably big work item into a number of
+ smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and Testing Server portion,
+ and Implementing and Testing Client portion of the scenario. You would now do a detailed estimate of the actual effort,
+ measured in hours or days, associated with each of those 4 tasks. This estimate should be done by the person assigned
+ to do the task. In this case you may assign the following actual estimates (with person responsible within
+ parenthesis):
+</p>
+<ul>
+ <li>
+ Detailing scenario (Ann): 4 hours
+ </li>
+ <li>
+ Designing scenario (Ann and Jack): 6 hours
+ </li>
+ <li>
+ Implementing and Testing Server portion of scenario (Jack): 22 hours
+ </li>
+ <li>
+ Implementing and Testing Client portion of scenario (Ann): 12 hours
+ </li>
+ <li>
+ <strong>Total Effort Estimate for Scenario:</strong> 44 hours
+ </li>
+</ul>
+<p>
+ If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no
+ point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,
+ you have to do some level of analysis and design of the work item before you can come up with a reasonable estimate.
+ Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to
+ re-estimate the effort required to complete the task, so we have a realistic view of progress within an
+ iteration.<br />
+</p><!-- END:mainDescription,_CYRMgBEdEdqY7JB6N6CW2w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/analyze_arch_reqs.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/analyze_arch_reqs.html
new file mode 100644
index 0000000..d722afb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/analyze_arch_reqs.html
@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\analyze_arch_reqs.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analyze_arch_reqs.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_42UD4A3tEduibvKwrGxWxA CRC: 1105243094 -->Analyze the Architectural Requirements<!-- END:presentationName,_42UD4A3tEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_42UD4A3tEduibvKwrGxWxA CRC: 1722712687 -->This guideline provides additional information to support the analysis of architecturally significant requirements and the creation of an outline architecture.<!-- END:briefDescription,_42UD4A3tEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-YeVRerdEixh4HgHOuw2KRQ CRC: 3600285818 --><h4>
+ Identify architectural goals
+</h4>
+<p>
+ Architectural goals provide the motivation and rationale for decisions. These goals are often driven
+ by the software requirements, particularly in <a class="elementLink"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>, because they are not always obvious from the use
+ cases alone [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALL02</a>].
+</p>
+<p>
+ Architectural goals define how the system needs to respond to change over time. Consider these questions when writing
+ your goals:
+</p>
+<ul>
+ <li>
+ What is the expected lifespan of the system?
+ </li>
+ <li>
+ Will the system need to respond to technological changes over that time, such as new versions of middleware or
+ other products?
+ </li>
+ <li>
+ How frequently is the system expected to adapt to change?
+ </li>
+ <li>
+ What changes can we anticipate in the future, and how can we make them easier to accommodate?
+ </li>
+</ul>
+<p>
+ These considerations will have a significant effect on the structure of the system.
+</p>
+<h4>
+ Identify architectural constraints
+</h4>
+<p>
+ Ginformation about the existing environment and identify any constraints in the solution. This will ease
+ integration with the environment; and m ay reduce risk, cost and duplication of solution elements.
+</p>
+<p>
+ Architectural constraints can arise from various factors:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Network topology
+ </li>
+ <li>
+ Use of a given database vendor or an existing database
+ </li>
+ <li>
+ Web environment (server configurations, firewall, DMZs, and so forth)
+ </li>
+ <li>
+ Servers (hardware model, operating system)
+ </li>
+ <li>
+ Use of third-party software or a particular technology
+ </li>
+ <li>
+ Compliance with existing standards
+ </li>
+ </ul>
+</div>
+<p>
+ For example, if the company uses only one type of database, you will probably try to use it as much as possible to
+ leverage the existing database administration skills, rather than introducing a new one.
+</p>
+<p>
+ These architectural constraints, combined with the requirements, help you define an appropriate candidate for
+ the system architecture.
+</p>
+<h4>
+ Survey, assess, and select from available assets
+</h4>
+<p>
+ To assess and select assets to reuse on your project, you need to understand the requirements of the system's
+ environment. You also need to understand the scope and general functionality of the system that the Stakeholders
+ require. There are several types of assets to consider, including (but not limited to): reference architectures;
+ frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset repositories (internal or
+ external to your organization) and industry literature to identify assets or similar projects.
+</p>
+<p>
+ You need to assess whether available assets contribute to solving the key challenges of the current project and whether
+ they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
+ between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
+ asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
+ tradeoffs in adopting it are, in terms of cost, risk, and functionality.
+</p>
+<p>
+ Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
+</p>
+<h4>
+ Define approach for structuring the system
+</h4>
+<p>
+ Structuring your system helps you manage its complexity by using the well-known "divide and conquer" strategy. By
+ breaking the process into smaller and more manageable pieces, you make development easier.
+</p>
+<p>
+ Layering is one of the most commonly used approaches for structuring and decomposing systems. Each
+ layer groups similar classes or components, which communicate insofar as possible only with adjacent layers. See
+ <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.html"
+ guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a> for more information.
+</p>
+<p>
+ You do not define which layers contain which classes or components. Instead, you define how many layers you will need
+ and which kinds of layers you will use. For example, if you are developing a new middleware system, you probably do not
+ need a business layer. Later, during design activities, you decide which classes and components will populate
+ these layers.
+</p>
+<h4>
+ Define approach for deploying the system
+</h4>
+<p>
+ Develop a high level overview of how the software is deployed. For example, determine if the system needs to be
+ accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to
+ consider are:
+</p>
+<ul>
+ <li>
+ users at geographical locations
+ </li>
+ <li>
+ organization of business data
+ </li>
+ <li>
+ service level requirements
+ </li>
+ <li>
+ constraints (such as requirements to interface with legacy systems)
+ </li>
+</ul>
+<p>
+ Validate that the deployment overview supports users (especially those users at remote locations if this is required)
+ performing typical usage scenarios while satisfying nonfunctional requirements and constraints. Validate that
+ the nodes and connections are adequate to support the interactions between components on different nodes, and between
+ components and their stored data.
+</p>
+<h4>
+ Identify key abstractions
+</h4>
+<p>
+ Requirements and analysis tasks usually uncover key concepts that the system must be able to handle. These concepts
+ manifest in design as key abstractions. The <a class="elementLink"
+ href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> and <a class="elementLink"
+ href="./../../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html"
+ guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> work products are good sources for key abstractions. These abstractions are
+ often easily identified because they represent things that are significant to the business. For example, Customer and
+ Account are typical key abstractions in the banking business.
+</p>
+<p>
+ The abstractions that are identified at this point will also probably change and evolve during the course of the
+ project. The purpose of this step is not to identify the complete set of classes and relationships that will
+ survive throughout design. Rather, it is to identify the important concepts that the system must
+ handle. The value in calling them out arly in the project is that everyone on the team understands the importance of
+ these concepts and develops coherant software to handle them consistently.
+</p>
+<p>
+ Don't spend too much time describing abstractions in detail at this initial stage, because there is a risk that
+ spending too much time will result in identifying classes and relationships that the solution does not actually need.
+ When identifying key abstractions, it can be useful to also define any obvious relationships that exist
+ between them. These can be captured in a table or in diagrams (in a tool or whiteboard), and create a short
+ description for each abstraction. In general, it is not worth agonizing over defining a highly detailed set of
+ relationships at this early stage in design. The relationships will become more concrete and detailed later and
+ will probably modify these early assumptions.
+</p>
+<h4>
+ Identify architecture mechanisms
+</h4>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>.
+</p>
+<h4>
+ Capture architectural decisions
+</h4>
+<p>
+ It is often useful to record key architectural decisions and working assumptions on an architectural overview diagram
+ to make it easier to communicate the architecture to the project team and stakeholders. This information should be
+ part of the description of the architecture, but it can vary in format to suit the needs of the project. For
+ example, on an agile and low-ceremony project the overview diagram can be an informal picture story board or a graph
+ with icons on either a whiteboard or a drawing tool. The illustration needs to show the nature of the proposed
+ solution, convey the governing ideas, and represent the major building blocks.
+</p>
+<p>
+ Architecture decisions should be captured in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
+</p>
+<p>
+ If a more complex system is required, then the architecture can be represented as a more comprehensive set
+ of views that describe the architecture from a number of viewpoints. See <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html"
+ guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a> for more information.<br />
+</p><!-- END:mainDescription,-YeVRerdEixh4HgHOuw2KRQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.html
new file mode 100644
index 0000000..46b23af
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.html
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\analyze_arch_reqs_vm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analyze_arch_reqs_vm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-I-2SvZtjELUYDQO0jvdxEA CRC: 3143792575 --><h4>
+ Capture architectural decisions (Visual Modeling)
+</h4>
+<p>
+ You will find it useful to develop these three Unified Modeling Language (UML) diagrams at this stage:
+</p>
+<ul>
+ <li>
+ <strong>Layer map</strong> (represented as a class diagram using packages) that describes the upper-level layers of
+ the architecture
+ </li>
+ <li>
+ <strong>Draft deployment diagram</strong> that outlines the expected network topology
+ </li>
+ <li>
+ <strong>Simple class diagram</strong> that shows the key abstractions and any obvious relationships among them
+ </li>
+</ul><!-- END:mainDescription,-I-2SvZtjELUYDQO0jvdxEA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/architectural_view.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/architectural_view.html
new file mode 100644
index 0000000..ec9d383
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/architectural_view.html
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\architectural_view.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architectural_view.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_T9nygClEEduLGM8dfVsrKg CRC: 2033001342 -->Architectural View<!-- END:presentationName,_T9nygClEEduLGM8dfVsrKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_T9nygClEEduLGM8dfVsrKg CRC: 3932502239 -->Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of the system.<!-- END:briefDescription,_T9nygClEEduLGM8dfVsrKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-cnGBBA4NXmhTIjHjlHx4Mw CRC: 4068197120 --><p> As an Architect, you may want to consider the following views (not all views
+ are relevant to all systems or all the Stakeholders). This set of views is known
+ as the 4+1 Views of Software Architecture</strong> [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">KRU95</a>]..
+</p>
+<p>
+ <img height="254" alt="4+1 Views of Software Architecture" src="./resources/4plus1_2.jpg" width="405" />
+</p>
+<ul>
+ <li>
+ <p> Use-case view:</strong> Describes functionality of the system,
+ its external interfaces, and its principal users. The use-case view contains
+ the <a class="elementLink" href="./../../../openup_basic/workproducts/uc_model,_0UCrZclgEdmt3adZL5Dmdw.html" guid="_0UCrZclgEdmt3adZL5Dmdw">Use-Case
+ Model</a>. This view is mandatory when using the 4+1 Views, because all
+ elements of the architecture should be derived from requirements. </p>
+ </li>
+ <li>
+ <p> Logical view: </strong>Describes how the system is structured
+ in terms of units of implementation. The elements are packages, classes,
+ and interfaces. The relationship between elements shows dependencies, interface
+ realizations, part-whole relationships, and so forth. Note: </strong>This
+ view is mandatory when using the 4+1 Views of Software Architecture. </p>
+ </li>
+ <li>
+ <p>Implementation view: </strong>Describes how development artifacts
+ are organized in the file system. The elements are files and directories
+ (any configuration items). This includes development artifacts and deployment
+ artifacts. This view is optional when using the 4+1 Views. </p>
+ </li>
+ <li>
+ <p>Process view: </strong>Describes how the run-time system is structured
+ as a set of elements that have run-time behavior and interactions. Run-time
+ structure often bears little resemblance to the code structure. It consists
+ of rapidly changing networks of communication objects. The elements are
+ components that have run-time presence (processes, threads, Enterprise JavaBeans™
+ (EJB™), servlets, DLLs, and so on), data stores, and complex connectors,
+ such as queues. Interaction between elements varies, based on technology.
+ This view is useful for thinking </strong>about
+ run-time system quality attributes, such as performance and reliability.
+ This view is optional when using the 4+1 Views. </p>
+ </li>
+ <li>
+ <p> Deployment views: </strong>Describe how the system is mapped to
+ the hardware. This view is optional when using the 4+1 Views. </p>
+ </li>
+</ul>
+<p>In addition, you may wish to represent the following, </p>
+<ul>
+ <li>
+ <p> Data view:</strong> A specialization of the logical view. Use
+ this view if persistence is a significant aspect of the system, and the
+ translation from the design model to the data model is not done automatically
+ by the persistence mechanism. </p>
+ </li>
+</ul>
+<p><br /><!-- END:mainDescription,-cnGBBA4NXmhTIjHjlHx4Mw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/assign_changes_to_iteration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/assign_changes_to_iteration.html
new file mode 100644
index 0000000..ecaca22
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/assign_changes_to_iteration.html
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\assign_changes_to_iteration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: assign_changes_to_iteration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__yQQ4L6REdqti4GwqTkbsQ CRC: 2817405546 -->Assign Changes to an Iteration<!-- END:presentationName,__yQQ4L6REdqti4GwqTkbsQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__yQQ4L6REdqti4GwqTkbsQ CRC: 4077438359 -->This guideline promotes the best practice of isolating team members from disruptive changes during the current iteration. Change requests are reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration.<!-- END:briefDescription,__yQQ4L6REdqti4GwqTkbsQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-bUmvEAAtFf6B0aUCux8k9Q CRC: 49060291 --><p>
+ Most iterative software development processes recommend that changes not be introduced during an iteration. The main
+ idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.
+</p>
+<p>
+ To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not
+ assigned for implementation until a future iteration via the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.
+</p>
+<p>
+ Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change
+ requests.
+</p>
+<p>
+ Consider the following when choosing the future iteration where the change request will be addressed:
+</p>
+<ul>
+ <li>
+ Group similar change requests in the same iteration. For example multiple change requests focused on the same
+ functionality or that are dependent on each other.
+ </li>
+ <li>
+ Assign change requests that mitigate high risks to the earliest iteration possible.
+ </li>
+</ul><!-- END:mainDescription,-bUmvEAAtFf6B0aUCux8k9Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/continuous_integration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/continuous_integration.html
new file mode 100644
index 0000000..1707bc0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/continuous_integration.html
@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\continuous_integration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: continuous_integration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_i8bUEL6cEdqti4GwqTkbsQ CRC: 751312288 -->Continuous Integration<!-- END:presentationName,_i8bUEL6cEdqti4GwqTkbsQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_i8bUEL6cEdqti4GwqTkbsQ CRC: 1413011866 -->This guideline describes how to apply continuous integration to improve the integration of units into the code base.<!-- END:briefDescription,_i8bUEL6cEdqti4GwqTkbsQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-DlaqJu4sEqMPk84qhJ6IEA CRC: 1153667371 --><p>
+ [ Don't forget to talk about running developer tests. ]
+</p>
+<p>
+ [Content below taken from step “Accept Integrated Elements and Promote Build" in the Task “Integrate and Create
+ Build"... this Main Description needs to be cleaned up ]
+</p>
+<p>
+ Depending on the complexity and number of components to be integrated, it is often more efficient to produce the
+ target build in a number of steps, adding more components with each step, and producing a series of intermediate
+ 'mini' builds - thus, each build planned for an iteration may, in turn, have its own sequence of transient intermediate
+ builds. These are subjected to a minimal integration test to ensure that what is added is compatible with what
+ already exists in the system integration workspace. It should be easier to isolate and diagnose problems using this
+ approach.
+</p>
+<p>
+ Delivered components are accepted incrementally into the system integration workspace, having any merge
+ conflicts being resolved. It is recommended that this is done in a bottom-up approach with respect to the
+ layered structure, making sure that the versions of the components are consistent, taking imports into
+ consideration. The increment of components is compiled and linked into an intermediate build, which is then
+ provided to the tester to execute a minimal system integration test.
+</p>
+<p>
+ <font size="1"><img height="172" alt="" src="./resources/ac_intsy.gif" width="501" /></font>
+</p>
+<p>
+ This diagram shows a build produced in three increments. Some components are only needed as stubs, to make it
+ possible to compile and link the other components, and provide the essential minimal run-time behavior.
+</p><!-- END:mainDescription,-DlaqJu4sEqMPk84qhJ6IEA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/data_modeling.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/data_modeling.html
new file mode 100644
index 0000000..a98988f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/data_modeling.html
@@ -0,0 +1,199 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\data_modeling.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: data_modeling.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ienXEEyAEdu-df7p0PuRvQ CRC: 754925525 -->Physical Data Modeling<!-- END:presentationName,_ienXEEyAEdu-df7p0PuRvQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ienXEEyAEdu-df7p0PuRvQ CRC: 828844106 -->A physical data model (PDM) captures the design of a persistent data store such as a relational database or data file. Data modeling is the act of creating such a model.<!-- END:briefDescription,_ienXEEyAEdu-df7p0PuRvQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-XMbxFU8M85cRlf3C4iwAGw CRC: 2725241037 --><h3>
+ Overview
+</h3>
+Physical data models (PDMs) are used to design the structure of a persistent data store. Typically a PDM is created for a
+single data store, although sometimes a PDM will cover several related data stores (this is particularly true when the data
+storage mechanism is file based). The assumption in this guideline is that you are modeling the schema of a single
+relational database.
+<h3>
+ The Data Model in OpenUP
+</h3>
+The PDM is part of the Work Product: Design. It’s described as different views or perspectives of a portion of the design.
+<h3>
+ Data Model Types
+</h3>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Traditionally, there are three types of data models:
+</p>
+<ol>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ Conceptual. A conceptual model, also referred to as a domain model, depicts the critical business entities and
+ the relationships between them.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ Logical. A logical data model (LDM) adds detail, in particular data attributes and more entities. LDMs will
+ optionally indicate candidate keys (one or more attributes of an entity which uniquely identify it) of an
+ entity. LDMs describe how the design of the system handles the data that will be actually maintained in the
+ PDM.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ <p>
+ Physical. A PDM depicts the table structure (in the case of a relational database design), the
+ relationships between the tables, and the primary and foreign keys implemented by the tables. PDMs
+ potentially indicate views, stored procedures, and other database elements.
+ </p>
+ </div>
+ </li>
+</ol>
+<p>
+ For systems built using object and/or component-based technology, the LDM is usually not created in favor of a class
+ model.
+</p>
+<h4 style="MARGIN-RIGHT: 0px">
+ Physical Data Modeling
+</h4>
+<p>
+ The PDM consists of the detailed database table designs and their relationships. The tables in the PDM have
+ well-defined columns, as well as keys and indexes as needed. The tables might also have triggers defined as necessary
+ to support the database functionality and referential integrity of the system. In addition to the tables, stored
+ procedures have been created, documented, and associated with the database in which the stored procedure will reside.
+</p>
+<p>
+ The diagram below shows an example of some of the elements of a PDM. A UML-based notation is used, although other
+ notations such as “crow's feet” or Information Engineering (IE) are also common. This example model is a part of the
+ PDM of a fictional order entry system. It depicts three tables (Order, OrderItem, and Item), three stored procedures
+ (GetOrders, GetTotalBusiness, and TestDatabase), and a trigger on Order named deleteOrderItems. The figure also depicts
+ the columns of each table, the primary key for each table, and any foreign keys to other tables.
+</p>
+<p>
+ <strong>Example Physical Data Model</strong>
+</p>
+<p>
+ <img height="309" alt="" src="./resources/PDMSample.JPG" width="597" />
+</p>
+<p>
+ An existing database can be reverse-engineered to populate the PDM if the team has access to a tool that can transform
+ a database into a model.
+</p>
+<h3>
+ How to Model Database Schemas
+</h3>
+<p>
+ Perform the following in an iterative manner:
+</p>
+<ol>
+ <li>
+ Identify tables. A table is similar conceptually to object-orientation’s concept of a class – a table contains a
+ collection of rows of data whereas a class defines a collection of objects. A table could contain rows representing
+ people, places, things, events, or concepts. Examples of tables include Customer, Order, and OrderItem.
+ </li>
+ <li>
+ Identify columns. Each table has one or more columns. A column stores a single data attribute for each row. For
+ example, the Customer table may have columns such as First Name and Surname. A column has a single data type, such
+ as INT, DATETIME, or VARCHAR.
+ </li>
+ <li>
+ Follow accepted modeling conventions. Your organization should have standards and guidelines applicable to data
+ modeling, in particular naming conventions, that you should follow.
+ </li>
+ <li>
+ Identify relationships between tables. In the real world entities have relationships with other entities. For
+ example, customers PLACE orders, customers LIVE AT addresses, and line items ARE PART OF orders. These
+ relationships will exist between the rows of data stored in the corresponding tables.
+ </li>
+ <li>
+ Assign keys. A key is one or more columns that uniquely identify a row in a table. A primary key is the preferred
+ key for a table. For example, the Customer table may have two potential keys, CustomerID and SocialSecurityNumber.
+ You could choose to use CustomerID as the primary key, thereby making SocialSecurityNumber a secondary key. Foreign
+ keys are used to maintain relationships between rows.
+ </li>
+ <li>
+ Normalize to reduce data redundancy. Data normalization is a process in which columns within a PDM are organized to
+ increase the cohesion of tables. In other words, the goal of data normalization is to reduce and even eliminate
+ data redundancy, an important consideration for application developers because it is incredibly difficult to store
+ objects in a relational database that maintains the same information in several places.
+ </li>
+ <li>
+ De-normalize to improve performance. Normalized data schemas, when put into production, often suffer from
+ performance problems. An important part of data modeling is to de-normalize portions of the data schema, to
+ increase data redundancy by storing the same information in several places or manners, to improve database access
+ times.
+ </li>
+</ol>
+<h3>
+ Data Modeling Throughout the Lifecycle
+</h3>
+<h4>
+ Inception Phase
+</h4>
+<p>
+ During the Inception phase the goal is to identify high-level requirements for the system so that the scope may be
+ identified and project funding obtained. Little, if any, data modeling is performed at this point although some
+ conceptual modeling may occur. Detailed data models are usually not needed at this point.
+</p>
+<h4>
+ Elaboration Phase
+</h4>
+<p>
+ The goal of the Elaboration phase is to eliminate technical risk and to produce a stable (baselined) architecture for
+ the system. One of several architectural issues that is likely to arise is data architecture. To support this effort,
+ you will need to model the major database structures (tables, indexes, and primary and foreign key columns) and then
+ create the database schema from the model (ideally it would be generated from a modeling tool).
+</p>
+<p>
+ Additionally, representative data volumes may be loaded into the database to support performance testing. Based on the
+ results of performance testing, the PDM might need to be adjusted with optimization techniques, including but not
+ limited to de-normalizing, optimizing physical storage attributes, or distribution and indexing.
+</p>
+<h4>
+ Construction Phase
+</h4>
+<p>
+ During the Construction phase the goal is to build a working system that is ready to be released. During each
+ iteration the design, implementation, and tests are fleshed out to implement that iteration's requirements.
+ In other words development artifacts, including your data-oriented artifacts, evolve over time. To support data model
+ changes you may discover the need to refactor your existing database schema.
+</p>
+<h4>
+ Transition Phase
+</h4>
+<p>
+ The PDM is maintained during the Transition phase in response to approved change requests. You should keep the PDM
+ synchronized with the database as the application goes through final acceptance test and is deployed into production.
+</p>
+<h3>
+ Round-trip Engineering Considerations
+</h3>
+<p>
+ If a development team is using modern visual modeling tools that have the ability to convert classes to tables (and
+ vice versa) or has the ability to reverse and forward engineer databases, then the team needs to establish guidelines
+ for managing the transformation and engineering processes. The development team must define the points in the
+ development of the application (build-and-release cycle) at which it will be appropriate to perform the class-to-table
+ transformations and to forward-engineer the database. Once the initial database is created, the development team must
+ define guidelines for the team to manage the synchronization of the PDM and database as the design and code of the
+ system evolve throughout the project.
+</p><!-- END:mainDescription,-XMbxFU8M85cRlf3C4iwAGw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/design.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/design.html
new file mode 100644
index 0000000..dd8d705
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/design.html
@@ -0,0 +1,244 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0X3bcMlgEdmt3adZL5Dmdw CRC: 3403898630 -->Design<!-- END:presentationName,_0X3bcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0X3bcMlgEdmt3adZL5Dmdw CRC: 3671925684 -->This guideline gives additional information on how to design a portion of the system.<!-- END:briefDescription,_0X3bcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Qo7pYMM3EdmSIPI87WLu3g CRC: 1328801042 --><p>
+ The design represents the behavior and structure of the system at various levels of abstraction – most notably not
+ solely at the code level of abstraction. This will help the designer reason about the quality, structure,
+ and behavior of the design.
+</p>
+<h3>
+ Multiple Passes
+</h3>
+<p>
+ The design will be revisited many times throughout the iterative lifecycle and even within an iteration.
+</p>
+<p>
+ Each time some design activity is being performed, it will be performed with some specific goal. The goal might
+ be to identify a notional set of participants in a collaboration that can be exercised to realize the behavior required
+ (an analysis pass). The goal might be in the identification of some coarse-grained elements that are required to
+ act out some scenario (an architectural pass). Then a pass might be done within one of those components to
+ identify the elements within that will collaborate together to perform the behavior required (a more detailed design
+ pass).
+</p>
+<p>
+ Design might be performed in a particular context such as database context, user-interface context, or perhaps the
+ context of how some existing library will be applied. In these cases the design steps will be performed just to
+ make and communicate decisions regarding that context.
+</p>
+<p>
+ Avoid analysis paralysis. Avoid refining, extending, and improving the design beyond a minimal version that
+ suffices to cover the needs of the requirements within the architecture. Design should be done in small chunks,
+ proven via implementation, improved via refactoring, and integrated into the baseline to provide value to the
+ stakeholders.
+</p>
+<h3>
+ Identification of Elements
+</h3>
+<p>
+ Identify the elements based on needs of the requirements.
+</p>
+<p>
+ The identification of elements can stem from a static perspective of walking through the requirements and identifying
+ elements clearly called out, a form of domain modeling. It can pull in other elements identified as being in the
+ application domain or deemed necessary from examining the requirements for the portion of the system being
+ designed. This can also pull from key abstractions identified while defining the architecture.
+</p>
+<p>
+ The identification of elements should apply a dynamic perspective by walking through scenarios
+ of usage of the system (or subsystem) identifying elements needed to support the behavior. That behavior
+ might be a scenario of usage from an external user perspective or, while designing a subsystem, a responsibility
+ assigned to the subsystem that has complex algorithmic behavior. Consider applying the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> to identify the elements necessary to support
+ the scenario or apply other patterns identified in the architecture that specify the elements that will be used to
+ support specific aspects of the scenario.
+</p>
+<p>
+ If the system being designed is a real-time system, include elements representing events and signals that allow us to
+ describe the asynchronous triggers of behavior to which the system must respond. Events are specifications of
+ interesting occurrences in time and space that usually (if they are noteworthy) require some response from the
+ system. Signals represent asynchronous mechanisms used to communicate certain types of events within the system.
+</p>
+<p>
+ If there are existing elements from previous passes over the design or from selected frameworks or other reusable
+ elements, those should be reused whenever possible.
+</p>
+<p>
+ Having identified the elements, each should be given a meaningful name. Each element should also have a
+ description so that the team members that work together to refine the design and implement from the
+ design will understand the role the element will play.
+</p>
+<p>
+ Based on the above, this identification of elements could be applied a number of times in designing just one
+ part of the system. While there is no one correct strategy for multiple passes, they could be done at a
+ coarse-grained level and then a fine-grained level or at an analysis (abstract) level and then a design level.
+</p>
+<h3>
+ Behavior of Elements
+</h3>
+<p>
+ To identify the behavior of the elements, walk through scenarios assigning behavior to the appropriate
+ collaborating participant. If a particular usage of the system or subsystem can have multiple possible
+ outcomes or variant sequences, cover enough scenarios to ensure that the design is robust enough to support the
+ necessary possibilities.
+</p>
+<p>
+ When assigning behavior to elements, consider applying the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> or other patterns identified in the
+ architecture.
+</p>
+<p>
+ Behavior can be represented as a simple statement of responsibility or it can be a detailed operation
+ specification. Use the appropriate level of detail to communicate important design decisions while giving
+ the freedom to make appropriate implementation decisions as those tasks ensue.
+</p>
+<p>
+ Behavior must be understood as a responsibility on an element, and as an interaction between two elements in the
+ context of some broader behavior of the system or subsystem. The latter part of this will lead the developer to
+ identify relationships needed between the elements.
+</p>
+<p>
+ Avoid too much identification of behavior solely from the perspective of domain modeling. Only include
+ behavior that is really needed, behavior identified by walking through required scenarios of system usage.
+</p>
+<h3>
+ Design Element Relationships
+</h3>
+<p>
+ The relationships between the elements necessary for the behavior must be designed. This can simply be the
+ identification of the ability to traverse from one element to another or a need to manage an association
+ between the elements.
+</p>
+<p>
+ More detailed design can be performed on the relationships as appropriate. This can include optionality,
+ multiplicity, whether the relationship is a simple dependency or managed association, etc. These decisions that drive
+ implementation details are best made at the design level when it is easier to see how all the pieces fit
+ together.
+</p>
+<p>
+ As with the behavior discussion above, avoid defining too many relationships based on relationships in the application
+ domain. Only include the relationships that are really needed based on the requirements. On the other hand,
+ a combination of requirements knowledge and domain knowledge can lead to some detailed decisions on the relationships
+ such as optionality and multiplicity.
+</p>
+<h3>
+ Refine Design
+</h3>
+<p>
+ Having identified a design including a set of collaborating elements with the behavior and relationships
+ robust enough to handle the requirements under consideration, the design can be improved and transformed into an
+ implementable system through refinement.
+</p>
+<p>
+ The visibility of each operation should be selected to be as restrictive as possible. Based on walking
+ through the scenario it should be clear which operations must be available to other elements in the design and
+ which can be considered private behavior inside the element that has the operation. Minimizing the number of
+ public operations creates a more maintainable and understandable design.
+</p>
+<p>
+ With respect to parameters, the return value, and a description of how it will go about performing the behavior,
+ operations can be detailed at a lower level that drives the actual implementation or that detail might be left to
+ be handled when writing the code.
+</p>
+<p>
+ Data attributes can be identified based on information needed to support behavior or based on additional requirements
+ such as information to be presented to the user or transmitted to another system. Avoid indiscriminate domain
+ analysis; there might be a great deal of data in the domain that is not needed to support the requirements. Data
+ attributes can simply be identified or they can be designed in detail with attribute types, initial values, and
+ constraints. Decide on the visibility of the data attribute; operations to access and update the data can be added or
+ deferred to implementation.
+</p>
+<p>
+ Generalization and interfaces can be applied to simplify or otherwise improve the design. Ensure that the
+ usage of these techniques actually improves the design rather than muddling it with complexity. For example,
+ common behavior can be factored into a parent class via generalization or out to a helper class via delegation; the
+ latter solution can be more understandable and maintainable as generalization is an inflexible relationship.
+</p>
+<p>
+ The refinement of any portion of the design could include another pass through the design process. One might find
+ that what was initially identified as a single behavior on an element warrants a detailed walkthrough of the
+ collaborating elements to realize that behavior.
+</p>
+<p>
+ When updating an existing design <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ –</span> especially one that has had portions already implemented <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ –</span> apply <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> to ensure that the improved design continues to perform as expected.
+</p>
+<h4>
+ Organization of Elements (package-level)
+</h4>
+<p>
+ In a design of any notable size, the elements must be organized into packages. Assign the elements to
+ existing or new packages and ensure that the visibility relationships between the packages support
+ the navigability required between the elements. Decide whether each element should be visible to elements
+ outside its package.
+</p>
+<p>
+ When structuring the design into packages, consider <a class="elementLink" href="./../../../openup_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Layering</a> and other patterns. Though all design work must conform to
+ existing architectural decisions, the allocation of elements to packages and possible updates to package
+ visibility is an area of significant architectural concern. The developer should collaborate with the
+ architect to ensure that package-level decisions are in accordance with the rest of the architecture.
+</p>
+<p>
+ This guideline first talks about the identification and design of the elements and then about organizing
+ the elements into packages. This is not a strict order of events. There is nothing wrong with
+ identifying a package structure for the system and then populating that structure with identified elements as
+ long as the actual elements identified are allowed to influence the resulting package structure.
+</p>
+<h3>
+ Reviewing the Design
+</h3>
+<p>
+ Design is best done collaboratively as it is a problem-solving activity with a range parts and perspectives.
+ There should be a constant level of review to ensure that the decisions make sense within the area being designed and
+ in the design of the system overall. There also might be occasions where the review of some area of design is
+ reviewed by a set of interested or knowledgeable parties such as the architect who will verify that the design conforms
+ to some architectural decision or a developer who will be expected to implement the design.
+</p>
+<p>
+ The design should be examined to ensure that it follows heuristics of quality design such as loose coupling and high
+ cohesion. Responsibilities should be appropriately distributed to elements such that there are no elements
+ with too much responsibility and no elements are left without any responsibilities. The design should be able to
+ clearly communicate the design decisions while not delving into concerns best dealt with during implementation of
+ code.
+</p>
+<p>
+ Ensure the design follows any project-specific guidelines and conforms to the architecture.
+</p>
+<p>
+ Modifications to the design to improve it based on issues identified in reviewing it should apply <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> to ensure that the design and any existing implementation of the design
+ continues to fulfill its responsibilities.
+</p>
+<h3>
+ Relationship of Design to Architecture
+</h3>
+<p>
+ This guideline remarks on conforming to the architecture in various ways; it is written as though one is designing
+ within a pre-existing architecture. Though projects will often have pre-existing architectures available, a
+ particular architecture is the result of design activities. Therefore, in addition to discussing conformance to
+ some existing architecture, one must also consider the creation of the architecture and updates and improvements to the
+ architecture based on the work of design.
+</p><!-- END:mainDescription,_Qo7pYMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/design_components.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/design_components.html
new file mode 100644
index 0000000..f0b9454
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/design_components.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\design_components.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design_components.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_CFAswNbzEdqu5o2S60g5LA CRC: 484912866 -->Design Components Representation<!-- END:presentationName,_CFAswNbzEdqu5o2S60g5LA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_CFAswNbzEdqu5o2S60g5LA CRC: 880295704 -->This guideline describes how to visually represent design components.<!-- END:briefDescription,_CFAswNbzEdqu5o2S60g5LA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-6ep_EyK3ZO6vRGWtAqoJ-A CRC: 530184183 --> <!-- END:mainDescription,-6ep_EyK3ZO6vRGWtAqoJ-A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/designing_visually.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/designing_visually.html
new file mode 100644
index 0000000..abf389e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/designing_visually.html
@@ -0,0 +1,215 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\designing_visually.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: designing_visually.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_1fM3AC9_EduW5uTjiIcspQ CRC: 2602872690 -->Designing Visually<!-- END:presentationName,_1fM3AC9_EduW5uTjiIcspQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_1fM3AC9_EduW5uTjiIcspQ CRC: 1440482910 -->This guideline provides information on how to apply visual modeling to designing a system.<!-- END:briefDescription,_1fM3AC9_EduW5uTjiIcspQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-1xE2ZW3MjNAJ7jkaZNbkww CRC: 490884580 --><h3>
+ Introduction
+</h3>
+<p>
+ Using visual modeling techniques to design software can help break down complex problems into a series of smaller,
+ easier to manage tasks. Sharing pictures rather than written documents or source code also helps the understanding and
+ communication of difficult concepts. Adopting standard modeling notations such as the UML increases this capability by
+ helping to make diagrams precise and unambiguous.
+</p>
+<p>
+ The degree of formality used when producing and disseminating models should vary according to your needs. Small,
+ collaborative teams modeling around whiteboards and capturing the results on a sheet of paper or with digital cameras
+ can yield good results. This can also help the team focus on producing software with the help of models; rather than
+ becoming sidetracked into over-engineering both the models and the solution. Modeling tools provide additional value to
+ projects, especially for more complex systems. Their specifics of use are outside the scope of this guideline, however.
+</p>
+<p>
+ This guideline does not describe a formal sequential progression through prescriptive design steps. Whether some or all
+ of these techniques are needed, or how long is spent on them will vary depending on real-world issues such as the
+ complexity of the requirements; the experience of the designer; and the way the team works.
+</p>
+<p>
+ This guideline uses a simplified scenario (Login) to help keep the focus on understanding the techniques rather than
+ the specific requirements. In the real-world, it is doubtful that much time would be spent modeling a simple problem.
+ Here is the use case diagram, for reference;
+</p>
+<p>
+ <img height="142" alt="User Login Use Case Model" src="./resources/UserLoginUCM.JPG" width="472" />
+</p>
+<h3>
+ Identify elements
+</h3>
+<p>
+ Render the identified design elements as classes in a UML diagram. Apply appropriate stereotypes and optionally
+ render the class using an icon specific to the stereotype to characterize the intent of the class in the design.
+ Name and briefly describe the classes in a few sentences. Do not spend too much time working on associations, as these
+ will be developed through working on collaborations in the next step.
+</p>
+<p>
+ Classes can be drawn as a basic UML rectangle or with a specific symbol associated with a particular stereotype.
+</p>
+<p>
+ The resulting class diagram should be conceptually similar to this one:
+</p>
+<p>
+ <img height="228" alt="Identify Elements - Initial Class Model" src="./resources/IdentifyElementsBCE.JPG" width="290" />
+</p>
+<p>
+ For this example, the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> has been used to derive two classes (LoginUI and
+ LoginController). In addition, two design elements already identified in the architecture (SecuritySystemInterface and
+ User) have also been incorporated.
+</p>
+<h3>
+ Determine how elements collaborate to realize the scenario.
+</h3>
+<p>
+ When determining collaboration, two kinds of diagrams are useful.
+</p>
+<ul>
+ <li>
+ A dynamic object diagram, showing how the design elements collaborate to realize the requirements.
+ </li>
+ <li>
+ A static class diagram, showing the classes involved in realizing the requirements.
+ </li>
+</ul>
+<p>
+ Remember to also update any other impacted diagrams as appropriate, based on modifications or additions to the design.
+</p>
+<p>
+ Create a number of dynamic object diagrams that walk through how a set of objects collaborate to perform the behavior
+ of the scenarios. Even if just one scenario is being designed, this might take multiple diagrams to render it in
+ smaller, understandable chunks or from multiple contexts.
+</p>
+<p>
+ <img style="WIDTH: 776px; HEIGHT: 355px" height="355" alt="User Login Sequence Diagram" src="./resources/UserLoginSeq.JPG" width="776" />
+</p>
+<p>
+ The above sequence diagram shows the user credentials being passed through to the security system for authentication.
+ Steps in the use case scenario are transformed into messages between the participating objects. The messages in this
+ example are not yet fully formed (there are no parameters or return values), so they are prefixed with “//” to show
+ that more work is needed. A sequence diagram was used in this example, but a communication diagram could have
+ been used.
+</p>
+<p>
+ It can be useful to create one or more static class diagrams that show the classes in the design that support
+ the realization. These class diagrams are often called View of Participating Classes diagrams, they provide a
+ focused view on the overall design by only showing the classes, relationships, operations, and attributes relevant to
+ the collaboration.
+</p>
+<p>
+ <img height="469" alt="Login VOPC" src="./resources/login_vopc.jpg" width="448" />
+</p>
+<p>
+ This diagram shows the operations and relationships that were identified by drawing the sequence diagram. The
+ relationships in this example have not been refined yet, so they are just shown as simple associations. Remember
+ to examine the diagram to verify that the design can support the behavior in the sequence diagram.
+</p>
+<p>
+ Working at this level of detail in the model during the early stages of design can be helpful. It keeps the diagrams
+ relatively simple and easy to understand. It makes them easier to draw in a workshop and easier to change during
+ discussion. It is often easier to add the detail once there is agreement on the fundamentals.
+</p>
+<h3>
+ Refine design decisions
+</h3>
+<p>
+ Once the fundamentals of the design are relatively stable, you can begin to add detail to the design. Some of this can
+ be performed in code or in the model. If modeling is chosen, then refine attributes, responsibilities and
+ relationships.
+</p>
+<h4>
+ Describe responsibilities
+</h4>
+<p>
+ Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to other
+ objects. Each class will typically have several responsibilities; each responsibility will evolve into one or more
+ operations during design.
+</p>
+<p>
+ Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has
+ to support. Document a responsibility by giving it a name, and optionally a brief description (what it does).
+</p>
+<p>
+ These operations can be left as self-evident from their context, they can be given textual descriptions of the
+ algorithm required to perform the behavior, or they could spawn off another whole pass of this technique where a set of
+ classes that collaborate together to perform the internals of the operation are identified, etc.
+</p>
+<h4>
+ Describe attributes and associations
+</h4>
+<p>
+ A class may have to store simple data information, like: string, integer, and the like. For such simple type of
+ information, attributes are defined for classes. For a more complex or "behavioral” attribute, consider creating an
+ extra class and establish an association to it.
+</p>
+<p>
+ To perform their responsibilities, classes may depend on other classes to supply needed behavior. These other classes
+ might be ones already identified in this design session, they might be existing classes pulled from the architecture,
+ or the need for new classes might be conceived. Associations in a class diagram can be used to represent inter-class
+ relationships.
+</p>
+<p>
+ <img height="439" alt="Login VOPC (Refined)" src="./resources/login_vopc_refined.jpg" width="557" />
+</p>
+<p>
+ This diagram shows a number of refinements. The LoginUI class has been replaced by LoginForm. The User class has been
+ renamed UserCredentials and is created by the LoginForm class rather than LoginController. It is then used as a
+ parameter for subsequent messages rather than passing the individual attributes. The SecuritySystemInterface class has
+ been refined into two elements, ISystemSecurity, which provides a simple façade for interaction with the rests of the
+ design; and SecuritySystemProxy, which handles interaction with the external security system.
+</p>
+<h3>
+ Design internals
+</h3>
+<p>
+ The classes in the design are likely to need to be distributed amongst different packages and subsystems or components.
+</p>
+<p>
+ <img height="304" alt="User Login - Design Packages" src="./resources/dv_Packaging.JPG" width="571" />
+</p>
+<p>
+ In this example, the LoginForm, LoginController and UserCredentials elements have been placed in a package called
+ LocalSecurity. The SecuritySystemProxy is a part of a subsystem called SecuritySystemAdapter which realizes the
+ ISecuritySystem interface. The SecuritySystemAdapter wraps the legacy SecuritySystem, expressed here as a component
+ offering a validateUser interface.
+</p>
+<p>
+ Each of these packaged elements can be distributed amongst the team for further development work.
+</p>
+<h3>
+ Conclusion
+</h3>
+<p>
+ This guideline walked through the techniques in a concrete manner started with a scenario of a use case through to
+ distributing the classes identified into a set of packages. This example demonstrates a technique for designing
+ visually, but it should be considered as just one conceptual pass of design. One could as easily apply this
+ technique when defining the internals of how the SecuritySystemProxy class will collaborate with a set of classes to
+ validate the credentials.
+</p>
+<p>
+ When applying this guideline, work in small chunks and keep in mind the goal of delivering software to the users that
+ provides value. To deliver high-quality software requires consideration of how the pieces will work together to deliver
+ that value. But as soon as key decisions have been made and the decisions have been communicated to the appropriate
+ team members, the team should move on to implementing the source code to verify the design and deliver the value.
+</p><!-- END:mainDescription,-1xE2ZW3MjNAJ7jkaZNbkww -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.html
new file mode 100644
index 0000000..e288988
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.html
@@ -0,0 +1,209 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\detail_ucs_and_scenarios.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: detail_ucs_and_scenarios.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4BJ_YCxSEdqjsdw1QLH_6Q CRC: 733310024 -->Detail Use Cases and Scenarios<!-- END:presentationName,_4BJ_YCxSEdqjsdw1QLH_6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_4BJ_YCxSEdqjsdw1QLH_6Q CRC: 1052185420 -->This guideline provides help on detailing use cases and scenarios.<!-- END:briefDescription,_4BJ_YCxSEdqjsdw1QLH_6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-78ko4CuOJERKJF9ZvwMUBQ CRC: 2891050649 --><h4>
+ Most efficient way to write use cases
+</h4>
+<p>
+ Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we
+ learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in
+ others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary work
+ and rewriting.
+</p>
+<p>
+ An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an
+ effective way to write use cases. This breadth-first approach involves two aspects: writing the set of use cases and
+ writing individual use cases.
+</p>
+<p>
+ <strong>Writing sets of use cases:</strong> Use cases exist in sets, and the relationships between the various use
+ cases and Actors are important. As you learn more about the Actors, you also learn more about the system's
+ boundaries and transactions. Likewise, as you learn more about the system's transactions, you learn more about its
+ Actors. Therefore, it is more efficient to write several use cases simultaneously than to write them sequentially. This
+ way, you can identify and understand the effects of the various use cases upon each other as you write them, rather
+ than as afterthoughts that require rewriting or elimination of previous work.
+</p>
+<p>
+ <strong>Writing individual use cases.</strong> Similarly, it makes sense to write each individual use case iteratively.
+ Starting with the main scenario, you can then identify various alternative and error flows that the use case might
+ follow, then evaluate, rearrange or eliminate them, and then add the details of the surviving scenarios.
+</p>
+<p>
+ The level of detail that you capture depends on a number of factors. See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html"
+ guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a> for guidance on selecting the correct format for your
+ use cases.
+</p>
+<h4>
+ Detail the flow of events of the main scenario
+</h4>
+<p>
+ As a starting point, use the step-by-step description of the main scenario that you created during <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>. Then, gradually add details to this scenario,
+ describing <strong>what</strong> the use case does, <strong>not how</strong> to solve problems internal to the system.
+</p>
+<p>
+ A flow of events description explores:
+</p>
+<ul>
+ <li>
+ How and when the use case starts
+ </li>
+ <li>
+ When the use case interacts with the Actors, and what data they exchange
+ </li>
+ <li>
+ When the use case uses data stored in the system or stores data in the system
+ </li>
+ <li>
+ How and when the use case ends
+ </li>
+</ul>
+<p>
+ It does not describe:
+</p>
+<ul>
+ <li>
+ The GUI
+ </li>
+ <li>
+ Technical details of hardware or software
+ </li>
+ <li>
+ Design issues
+ </li>
+</ul>
+<h4>
+ Identify alternate flows
+</h4>
+<p>
+ A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to
+ specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways
+ that the system provides a behavior, or it may describe failure or exception cases.
+</p>
+<p>
+ As you detail the main scenario, identify alternate flows by asking these questions:
+</p>
+<ul>
+ <li>
+ Are there different options available, depending on input from the Actor? (for example, if the Actor enters an
+ invalid PIN number while accessing an ATM)
+ </li>
+ <li>
+ What business rules may come into play? (for instance, the Actor requests more money from the ATM than is available
+ in her account)
+ </li>
+ <li>
+ What could go wrong? (such as no network connection available when required to perform a transaction)
+ </li>
+</ul>
+<p>
+ It is best to develop these scenarios iteratively, as well. Begin by identifying them. Examine each possible scenario
+ to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios.
+ Eliminate redundant or unnecessary scenarios, and then start elaborating on the more important ones.
+</p>
+<h4>
+ Structure the use case
+</h4>
+<p>
+ It is useful to structure the use case according to scenarios. This helps both to simplify communication and
+ maintenance and to permit the use cases to be implemented iteratively.
+</p>
+<p>
+ In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios
+ themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress.
+ Unless a sub-flow involves only a minor part of the complete flow of events (which can be described in the body of the
+ text), it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Sub-flows
+ that should be in a separate section include these examples:
+</p>
+<ul>
+ <li>
+ Sub-flows that occupy a large segment of a given flow of events.
+ </li>
+ <li>
+ Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more
+ clearly.
+ </li>
+ <li>
+ Any sub-flow that can be executed at several intervals in the same flow of events.
+ </li>
+</ul>
+<p>
+ For more information, see the "Flow of Events - Structure" section in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<h4>
+ Describe special requirements
+</h4>
+<p>
+ You should also capture any requirements that are related to the use case, but are not taken into consideration in the
+ flow of events of the use case. Such requirements are likely to be nonfunctional.
+</p>
+<p>
+ Typically, nonfunctional requirements that refer to a specific use case are captured in the special requirements
+ section of the use case. For more information, see the "Special Requirements" section in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<p>
+ If there are nonfunctional requirements that apply to more than one use case, capture these in the <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. For more information on supporting requirements
+ see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html"
+ guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.<br />
+</p>
+<h4>
+ Describe preconditions and postconditions
+</h4>
+<p>
+ A <strong>precondition</strong> on a use case explains the state that the system must be in for the use case to be able
+ to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that
+ may already have taken place.
+</p>
+<p>
+ A <strong>postcondition</strong> on a use case lists possible states that the system can be in at the end of the use
+ case execution. The system must be in one of those states. A postcondition also states actions that the system performs
+ at the end of the use case, regardless of what occurred in the use case. Post-Conditions may be categorized as Minimal
+ Guarantees or Success Guarantees. A Minimal Guarantee represents a condition that will be true when the use
+ case ends, regardless of how it terminates. A Success Guarantee represents a condition that will be true when the
+ use case ends successfully, regardless of which path it took.
+</p>
+<p>
+ Neither preconditions nor postconditions should be used to create a sequence of use cases. As a general rule, there
+ should never be a case where you have to first perform one use case and then another to have a meaningful flow of
+ events. If that is the case, correct the problem by reviewing the use cases. For more information, see the
+ "Preconditions" and "Postconditions" sections in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p><!-- END:mainDescription,-78ko4CuOJERKJF9ZvwMUBQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/develop_architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/develop_architecture.html
new file mode 100644
index 0000000..cd9a0b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/develop_architecture.html
@@ -0,0 +1,221 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\develop_architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: develop_architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mDf2EBapEduSTJywppIxVQ CRC: 514934396 -->Develop the Architecture<!-- END:presentationName,_mDf2EBapEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_mDf2EBapEduSTJywppIxVQ CRC: 2076822200 -->This guideline provides additional information to support the ongoing refinement and development of the architecture.<!-- END:briefDescription,_mDf2EBapEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-t7mQSRPYITkMoYRVNz7jQg CRC: 526681293 --><h4>
+ Identify architectural priorities
+</h4>
+<p>
+ Architecture priorities can take the form of one or more <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s brought into scope by association to the scenarios
+ prioritized for the current iteration. Other drivers may also be apparent. For example, it may be necessary to move
+ certain aspects of the architecture from prototypical to production quality implementation; or explore certain aspects
+ of the architecture to inform future iterations.
+</p>
+<p>
+ The architectural priorities are often driven by the development of software that implements an <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. It is important to specify the qualities of these
+ mechasnisms precisely and this may lead you to supplement the usage scenarios with quality attributes. As more than one
+ usage scenario may plkace demands on the same mechanisms, it may be helpful to consolidate these into quality
+ scenarios.
+</p>
+<p>
+ For example, if you want a system to be secure, specify the types of threats. Quality scenarios are one way to express
+ desired qualities in collaboration with the system stakeholders [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">KAZ04</a>]. Walk through things that could happen to the system and How it would
+ respond. <strong>Use-case scenarios</strong> focus on run-time behavior where the stakeholder is the user.
+ <strong>Quality scenarios</strong> encompass other interactions with the system as well, such as system maintenance
+ staff modifying the system.
+</p>
+<p>
+ Several scenarios may be devised for each quality attribute (such as usability, reliability, performance,
+ or security). For instance, security scenarios for denial of service and unauthorized access. A good scenario
+ makes clear what the stimulus is, what causes it, and what responses are appropriate.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ During peak operation, an unauthorized intruder tries to download prohibited data through the system
+ administrator’s interface. The system detects the attempt, blocks access, and notifies the supervisor within 15
+ seconds.
+ </p>
+</blockquote>
+<p>
+ After you have collected the scenarios, you need to establish priorities for them. Use scenarios to realize
+ requirements, so that their mapping onto the architecture, their impact, and their interactions can be understood.
+</p>
+<h4>
+ Refine the architecture mechanisms
+</h4>
+<p>
+ Consider each high-priority quality scenario, and map each of these onto the architecture mechanisms. Refine the
+ mechanisms to identify the specific technology to be used to handle each mechanism in scope. For example, for
+ the Persistence mechasnism, it may be appropriate to use a relational database management system such as
+ MySQL. Consider the selection of technology in the context of the requirements and constraints.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a> for more information.
+</p>
+<h4>
+ Identify Business Patterns
+</h4>
+<p>
+ The architecture of a software system can often be characterised by a small number of essential scenarios.
+ For example, for an on-line book store describing the way the software handles the scenarios for ordering a book and
+ checking out the shopping cart are often enough to communicate the essence of the architecture. Such business patterns
+ also provide a useful blueprint for similar functionality throughout the system.
+</p>
+<h4>
+ Identify reuse opportunities
+</h4>
+<p>
+ After looking for similar behavior and returned values, then look for similarity of parameters. If their
+ interfaces are not an exact match for the component interfaces being proposed, you can modify the
+ proposed signatures to increase the degree of reuse. Some design mechanisms, such as performance or security
+ requirements, may disqualify a component from reuse even when there is a perfect match between operation
+ signatures.
+</p>
+<p align="left">
+ A common set of components may exist that provides many of the <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> that you need for the new system. These components may
+ be available either because they were developed or purchased previously for similar systems. Given their
+ suitability and compatibility within the software architecture, there may be a need to reverse-engineer these
+ components to represent them in a design model and reuse them in a project.
+</p>
+<p align="left">
+ Similar thinking applies to existing databases. Part of the information to be used by the application under
+ development may already reside in a database. You may be able to get the classes that represent the database structures
+ that hold this information by reverse-engineering the database.
+</p>
+<h4 align="left">
+ Identify architecturally significant design elements
+</h4>
+<p align="left">
+ Consider each high-priority scenario in scope. Walk through the actions that the scenario initiates and
+ highlight the areas of the architecture that participate in realizing, or implementing, the requirements.
+</p>
+<p>
+ Identifying components will help hide the complexity of the system and help you work at a higher level. Components need
+ to be internally cohesive and to provide external services through a limited interface. Component identification can
+ be based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions:
+</p>
+<ul>
+ <li>
+ What is logically or functionally related (same use case or service, for example)?
+ </li>
+ <li>
+ What entities provide services to multiple others?
+ </li>
+ <li>
+ What entities depend on each other? Strongly or weakly?
+ </li>
+ <li>
+ What entities should you be able to exchange independently from others?
+ </li>
+ <li>
+ What will run on the same processor or network node?
+ </li>
+ <li>
+ What parts are constrained by similar performance requirements?
+ </li>
+</ul>
+<p>
+ Each component includes entities from the problem domain, control classes that coordinate complex tasks within
+ components, and interfaces that handle communication with the environment. The interface for each instantiated element
+ is identified. At this point, interfaces do not need to be as detailed as a signature, but they do need to document
+ what the elements need, what they can use, and what they can depend on.
+</p>
+<p>
+ Identified patterns define the types of elements, but not a specific number. Apply the chosen patterns to define a new
+ set of elements that conform to the patterns. Functionality will be allocated to the instantiated elements.
+</p>
+<h4>
+ Define development and test architectures
+</h4>
+<p>
+ The development and test architectures may be different from the target production implementation.
+</p>
+<ul>
+ <li>
+ Additional software may need to be developed to support testing.
+ </li>
+ <li>
+ Alternative deployment configurations may need to be defined in response to constraints on development hardware.
+ </li>
+ <li>
+ Multiple environments may be required to support different categories of tests.
+ </li>
+</ul>
+<p>
+ In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall
+ architecture.
+</p>
+<h4>
+ Validate the architecture
+</h4>
+<p>
+ The surest way to validate the architecture is through software. The software developed up to the end of the
+ Elbaoration Phase is largely aiming to validate the architecture, to the point where it can be baselined, thereby
+ providing some level of stability during the Construction phase.
+</p>
+<p>
+ It can also be useful to perform simple validation by walking through the main design concepts and models, perhaps
+ around a whiteboard or through other collaborative techniques. This can help refine thinking but will not act as a
+ subsitute for building some software.
+</p>
+<h4>
+ Communicate decisions
+</h4>
+<p>
+ You can document and communicate your decisions as many ways as you wish:
+</p>
+<ul>
+ <li>
+ Publication of reference source code.
+ </li>
+ <li>
+ Publication of reference models.
+ </li>
+ <li>
+ Publication of software architecture documentation.
+ </li>
+ <li>
+ Formal presentations of the material.
+ </li>
+ <li>
+ Informal walkthroughs of the architecture
+ </li>
+</ul><!-- END:mainDescription,-t7mQSRPYITkMoYRVNz7jQg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/effective_req_reviews.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/effective_req_reviews.html
new file mode 100644
index 0000000..f62ca8b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/effective_req_reviews.html
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\effective_req_reviews.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: effective_req_reviews.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_E-dPIL-GEdqb7N6KIeDL8Q CRC: 1184040965 -->Effective Requirement Reviews<!-- END:presentationName,_E-dPIL-GEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_E-dPIL-GEdqb7N6KIeDL8Q CRC: 1060930239 -->This guideline discusses how to conduct reviews with relevant stakeholders to ensure agreement, assess quality, and identify changes required.<!-- END:briefDescription,_E-dPIL-GEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-pNA0DbSdSoUqnjQIiOeHcQ CRC: 1359170333 --><p>
+ The cost of correcting errors increases exponentially throughout the development lifecycle <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[BOE88]</a>. Therefore, it is important to discover problems early enough to solve them
+ quickly and inexpensively.
+</p>
+<p>
+ Requirements reviews are intended to discover problems with the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a> before you spend significant time and work in implementing the
+ wrong thing. This is not to say that you must have a complete set of requirements before implementation, but be sure to
+ review, internally and with stakeholders, those that are selected for implementation in the early iterations and those
+ that will have a broad impact on the system (often called <a class="elementLink" href="./../../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>) to ensure everyone's concurrence before
+ investing significant effort in implementation.
+</p>
+<h4>
+ Informal reviews
+</h4>
+<p>
+ Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a
+ prototype.
+</p>
+<p>
+ These informal reviews are excellent for getting the structure of the requirements correct and removing obvious
+ mistakes. By keeping the review team small, it is easier to make rapid progress. However, informal reviews can miss
+ important perspectives of critical stakeholders.
+</p>
+<h4>
+ Formal reviews
+</h4>
+<p>
+ Requirement reviews can be formal meetings. Start with careful preparation, so that you receive and organize comments
+ before the meeting. The meeting itself should produce decisions on all review items. After the meeting, you must pursue
+ the review actions to completion. If these actions involve a substantial amount of work or require a change to an
+ artifact that is under configuration control, consider submitting <a class="elementLink" href="./../../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> to prioritize and track the work. See <a class="elementLinkWithType" href="./../../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a> and the associated <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">Guideline: Change Requests</a> for more information on change requests.
+</p>
+<p>
+ Formal reviews are more wide-ranging and expensive. They provide for more balanced reviews from multiple
+ perspectives. However, formal reviews involve more people, which makes them more difficult to coordinate (thus
+ the need for formality) and expensive in terms of work hours.
+</p>
+<h4>
+ Two-tier reviews
+</h4>
+<p>
+ One technique to get the best of both worlds is to use staged, or "two-tier", reviews <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO03]</a>. The first tier is informal and performed by a smaller team, possibly
+ many times. The second tier is more formal and performed by the complete group, perhaps only once.
+</p>
+<p>
+ <strong>First-tier review:</strong> The authors of the requirements and the development team review the
+ requirements during the first-tier reviews to ensure that they are unambiguous, complete and
+ consistent. It is important to include testers and developers to ensure that the requirements are verifiable and
+ feasible. These reviews determine whether the requirements are ready for the larger community to
+ review. First-tier reviews may be informal, formal, or a combination of the two.
+</p>
+<p>
+ <strong>Second-tier review:</strong> Involve the larger group during the higher-tier review to get more minds working
+ on the problem and to achieve concurrence that the requirements are suitable for implementation and validation.
+ It is best to have one formal requirement review at the Lifecycle Objective (LCO) milestone and, optionally, one at the
+ Lifecycle Architecture (LCA) milestone if significant changes have occurred that introduce unacceptable risk.
+</p>
+<p>
+ At both stages, these two resources will be helpful: <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/good_requirements,_jxn9EO0HEdqHTdbLTmC5IQ.html" guid="_jxn9EO0HEdqHTdbLTmC5IQ">Checklist: Qualities of Good Requirements</a> and <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html" guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>
+</p>
+<p>
+ Tiered reviews offer several benefits:
+</p>
+<ol>
+ <li>
+ Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on
+ functionality
+ </li>
+ <li>
+ Provide a professional look to the requirements, presenting both the requirements and their authors in the best
+ possible light
+ </li>
+ <li>
+ Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or
+ diminished effectiveness from overload and stress
+ </li>
+ <li>
+ Provide the best opportunity for full, effective reviews.
+ </li>
+</ol>
+<h4>
+ Golden rules of reviewing
+</h4>
+<p>
+ Follow these golden rules of reviewing <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>:
+</p>
+<ol>
+ <li>
+ <strong>Encourage criticism:</strong> Remember that people are improving the requirements, not criticizing you.
+ Even the harshest criticism often contains a grain of truth. Adopt the attitude that every suggestion is a gift.
+ </li>
+ <li>
+ <strong>Choose your best reviewers:</strong> A few specific people make the best reviewers, time and again.
+ Cultivate them.
+ </li>
+ <li>
+ <strong>Allow adequate time:</strong> It's not over until you have agreed upon and made the corrections.<br />
+
+ </li>
+</ol><!-- END:mainDescription,-pNA0DbSdSoUqnjQIiOeHcQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.html
new file mode 100644
index 0000000..37d3f9b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.html
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\example_analysis_mechanisms_descr.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: example_analysis_mechanisms_descr.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4k_HsA4LEduibvKwrGxWxA CRC: 1738380325 -->Example Analysis Mechanism Descriptions<!-- END:presentationName,_4k_HsA4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_4k_HsA4LEduibvKwrGxWxA CRC: 2073113338 -->Examples showing how to describe Analysis Mechanisms<!-- END:briefDescription,_4k_HsA4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-CJ--jlBqXi3FzdOM_dw5_w CRC: 3244605955 --><p> The following shows how to capture information for <a class="elementLinkWithType"
+ href="file:///c|/documents%20and%20settings/rbalduino/my%20documents/tng/beacon/copyedit/structure_for_importing/openup_basic/openup_basic/guidances/concepts/analysis_mechanism,_0gvqomlgedmt3adzl5dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Concept: Analysis Mechanism</a>. </p>
+<h3> Persistence </h3>
+<p>For all classes with instances that may become persistent, you need to identify:
+
+<ul>
+ <li>
+ <p><b>Granularity</b><strong>:</strong> What is the range of size of the objects
+ to keep persistent?</p>
+ </li>
+ <li>
+ <p><b>Volume</b><strong>: </strong>How many objects (number) do you need to
+ keep persistent?</p>
+ </li>
+ <li>
+ <p><b>Duration</b><strong>:</strong> How long does the object typically need
+ to be kept?</p>
+ </li>
+ <li>
+ <p><b>Retrieval mechanism</b><strong>: </strong>How is a given object uniquely
+ identified and retrieved? </p>
+ </li>
+ <li>
+ <p><b>Update frequency</b><strong>: </strong>Are the objects more or less
+ constant? Are they permanently updated? </p>
+ </li>
+ <li>
+ <p><b>Reliability</b><strong>: </strong>Do the objects need to survive a crash
+ of the process, the processor, or the whole system? </li>
+</ul>
+<h3>Communication </h3>
+<p>For all model elements that need
+ to communicate with components or services that are running in other processes
+ or threads, you need to identify </p>
+<ul>
+ <li>
+ <p><b>Latency</b><strong>: </strong>How
+ fast must processes communicate with another? </p>
+ </li>
+ <li>
+ <p><b>Synchronicity</b><strong>:
+ </strong>Asynchronous communication. </p>
+ </li>
+ <li>
+ <p><b>Size of message</b><strong>:
+ </strong>A spectrum might be more appropriate than a single number. </p>
+ </li>
+ <li>
+ <p><strong>Protocol:</strong> Flow control, buffering,
+ and so on.</p>
+ </li>
+</ul>
+<p> Notice that there is no design-level
+ information or specification here. Instead, this is more about collating and
+ refining architecturally significant requirements. </p><!-- END:mainDescription,-CJ--jlBqXi3FzdOM_dw5_w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_architectural_mechanisms.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_architectural_mechanisms.html
new file mode 100644
index 0000000..dd338a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_architectural_mechanisms.html
@@ -0,0 +1,284 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\example_architectural_mechanisms.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: example_architectural_mechanisms.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4k_HsQ4LEduibvKwrGxWxA CRC: 1729406773 -->Example Architectural Mechanisms<!-- END:presentationName,_4k_HsQ4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_4k_HsQ4LEduibvKwrGxWxA CRC: 3921841068 -->Commonly encountered architectural mechanisms<!-- END:briefDescription,_4k_HsQ4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-FqP5LgLVrlhvFC_eeYd_vA CRC: 160945004 --><p>
+ Here are some examples of commonly encountered architectural mechanisms.<br />
+ <br />
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Example Architectural Mechanisms" border="1" valign="top">
+ <caption>
+ <strong>Example Architectural Mechanisms</strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ Architectural Mechanism
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Availability
+ </td>
+ <td>
+ The percentage of time that the system must be available for use, including planned outages.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Archiving
+ </td>
+ <td>
+ Provides a means to move data from active storage when it has reached a specific state.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Auditing
+ </td>
+ <td>
+ Provides audit trails of system execution.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Communication
+ </td>
+ <td>
+ A mechanism for handling inter-process communication.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Debugging
+ </td>
+ <td>
+ Provides elements to support application debugging.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Disaster Recovery
+ </td>
+ <td>
+ Provides facilities to recover systems, application, data and networks.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Error Management
+ </td>
+ <td>
+ Allows errors to be detected, propagated, and reported.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Event Management
+ </td>
+ <td>
+ Supports the use of asynchronous events within a system.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Graphics
+ </td>
+ <td>
+ Supports user interface services, such as 3D rendering.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Information Exchange
+ </td>
+ <td>
+ Supports information interchange accross technical and organisational boundaries, with appropriate semantic
+ and format translations.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Licensing
+ </td>
+ <td>
+ Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as
+ part of authorising corporate bodies.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Localisation / Internationalisation
+ </td>
+ <td>
+ Provides facilities for supporting multiple human languages and rendering the language preffered by the
+ user.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mail
+ </td>
+ <td>
+ Services that allow applications to send and receive electronic mail.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mega-data
+ </td>
+ <td>
+ Support for handling very large amounts of data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Memory Management
+ </td>
+ <td>
+ Services for abstracting how memory is allocated and freed.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Meta-data
+ </td>
+ <td>
+ Supports the runtime introspection of components and data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Online help
+ </td>
+ <td>
+ Provides online help capability
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Persistence
+ </td>
+ <td>
+ Services to handle the reading and writing of stored data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Printing
+ </td>
+ <td>
+ Provides facilities for interfacing with printers.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Process Management
+ </td>
+ <td>
+ Provides support for the management of processes and threads.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Reporting
+ </td>
+ <td>
+ Provides flexible reporting facilities
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Resource Management
+ </td>
+ <td>
+ Provides support for the management of expensive resources, such as database connections.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Scheduling
+ </td>
+ <td>
+ Provides the ability to execute tasks at a specified time.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Security
+ </td>
+ <td>
+ Provides services to protect access to certain resources or information.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ System Management
+ </td>
+ <td>
+ Services that facilitate management of applications in an operational environment.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Time
+ </td>
+ <td>
+ Services to synchronise time on a network, and to translate times into different time zones.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Transaction Management
+ </td>
+ <td>
+ A mechanism for handling ACID transactions.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Workflow
+ </td>
+ <td>
+ Support for the movement of documents and other items of work, typically through an organisation.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<br />
+<br />
+<br />
+
+<p>
+ <br />
+ <br />
+</p><!-- END:mainDescription,-FqP5LgLVrlhvFC_eeYd_vA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_design_mechanisms.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_design_mechanisms.html
new file mode 100644
index 0000000..2fca51a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/example_design_mechanisms.html
@@ -0,0 +1,294 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\example_design_mechanisms.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: example_design_mechanisms.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4k_Hsg4LEduibvKwrGxWxA CRC: 2840279475 -->Example: Design Mechanisms<!-- END:presentationName,_4k_Hsg4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_4k_Hsg4LEduibvKwrGxWxA CRC: 4165502524 -->Examples that show how to describe design mechanisms<!-- END:briefDescription,_4k_Hsg4LEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-mAo18f36rZ1R98kpZX7HMw CRC: 1100663635 --><h3> Design
+ Mechanism Characteristics and Mapping</h3>
+<p> Consider the analysis mechanism for <strong>persistence</strong>. </p>
+<ul>
+ <li> There might be a need for many (2,000) small objects (200 bytes each) to
+ be stored for a few seconds, with no need for them to
+ survive thereafter. </li>
+ <li> There might be a need for several <strong></strong>very large <strong></strong>
+ objects to be stored permanently on disk for several months, never updated,
+ but with sophisticated means of retrieval. </li>
+</ul>
+<p> These objects require different support
+ for persistency. The best option depends on the characteristics
+ of the design mechanism:</p>
+<ul>
+
+ <li> <b>In-memory storag</b><strong>e: </strong>For up to 1 Mb total (size x
+ volume); very fast access for read, write, update. </li>
+ <li> <b>Flash card</b><strong>:</strong> For up to 8 Mb; slow update and write
+ access; moderate read access. </li>
+ <li> <b>Binary file</b><strong>:</strong> For 100 Kb to 200 Mb; slow update;
+ slow read-and-write access. </li>
+ <li> <b>Database management system (DBMS)</b><strong>: </strong>For 100 Kb and
+ upward (essentially no upper limit); even slower update and read-and-write
+ access. </li>
+</ul>
+<p> Note that these speeds are rated as slow only as compared
+ to in-memory storage. Obviously, in some environments, caching can improve
+ apparent access times. (See Figure 1.)</p>
+<blockquote>
+
+ <p align="center"> <img height="221" title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" alt="Mapping Analyis Mechanisms to Design Mechanisms and Classes" src="./resources/co_dmec1.gif"
+ width="372" /> </p>
+</blockquote>
+<div align="center">
+ <p><strong>Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes</strong></p>
+ <h3 align="left">Mapping Design Mechanisms to Implementation Mechanisms </h3>
+ <p align="left"> The <b>persistence</b> design mechanisms can be mapped to implementation
+ mechanisms as Figure 2 shows: </p>
+ <p align="center"> <img height="216" title="Figure 2. How persistence design mechanism map to implementation mechanism" alt="How persistence design mechanism map to implementation mechanism" src="./resources/co_dmec2.gif" width="325" /></p>
+ <p align="center"><strong>Figure 2. How persistence design
+ mechanism map to implementation mechanism</strong> </p>
+ <p align="left">A possible mapping between analysis mechanisms and design mechanisms.
+ Dotted arrows mean "is specialized by," implying that the characteristics
+ of the design mechanisms are inherited from the analysis mechanisms but that
+ they will be specialized and refined. </p>
+ <p align="left"> After you have finished optimizing the mechanisms, the following
+ mappings exist (see Figure 3): </p>
+ <blockquote>
+ <p align="center"> <img height="110" title="Figure 3. Mapping structure after optimizing the mechanisms" alt="Illustration of mapping structure after optimizing the mechanisms" src="./resources/co_dmec3.gif" width="418" />
+ </p>
+ <p align="center" class="picturetext"><strong>Figure 3. Mapping structure
+ after optimizing the mechanisms </strong></p>
+ <p align="left" class="picturetext">The design decisions for a client class
+ in terms of mappings between mechanisms. The Flight
+ class needs two forms of persistency<strong>:</strong> <strong>in-memory
+ storage</strong>, implemented by a predefined
+ library routine, and <strong>a database,</strong> implemented with an off-the-shelf
+ ObjectStorage product. </p>
+ </blockquote>
+ <p align="left"> The map must be navigable in both directions to make it easy
+ to determine client classes when changing implementation mechanisms. </p>
+ <h4 align="left">Refining
+ the mapping between design and implementation mechanisms </h4>
+</div>
+<p> Initially, the mapping between design mechanisms and implementation mechanisms
+ is likely to be less than optimal, but it will get the project running, identify
+ unforeseen risks, and trigger further investigations and evaluations. As the
+ project continues and you gain more knowledge, you will need to refine the mapping.
+</p>
+<p> Proceed iteratively to refine the mapping between design and implementation
+ mechanisms. Eliminate <strong></strong>redundant
+ paths, working both top-down and bottom-up. </p>
+<p> <b>Working top-down: </b>When working top-down (from top to bottom), new and
+ refined use-case realizations will put new requirements on the necessary design
+ mechanisms through the analysis mechanisms that you need. These new requirements
+ might uncover additional characteristics of a design mechanism, forcing a split
+ between mechanisms. A compromise between the system's complexity and its performance
+ is also necessary: </p>
+<ul>
+ <li>
+ Too many different design mechanisms make the system too complex.
+ </li>
+ <li> Too few design mechanisms can create performance problems for implementation
+ mechanisms that stretch the limits of the reasonable ranges of the values
+ of their characteristics. </li>
+</ul>
+<p> <b>Working bottom-up: </b>When working bottom-up (from bottom to top) and
+ investigating the available implementation mechanisms, you might find products
+ that satisfy several design mechanisms at once, but force some adaptation or
+ repartitioning of your design mechanisms. You want to minimize the number of
+ implementation mechanisms you use, but too few of them can also lead to performance
+ problems. </p>
+<p> After you decide to use a DBMS to store class A objects, you might be tempted
+ to use it to store all objects in the system. This could be very inefficient
+ or very cumbersome. Not all objects that require persistency need to be stored
+ in the DBMS. Some objects may be persistent, but one application may access
+ them frequently, while other applications access them only infrequently. A hybrid
+ strategy, in which the object is read from the DBMS into memory and periodically
+ synchronized, may be the best approach. </p>
+<blockquote>
+ <p class="example"> <b>Example</b> </p>
+ <p class="example"> A flight can be stored both in memory for fast access and
+ in a DBMS for long-term persistency. However, this triggers a need for a mechanism
+ to synchronize both. </p>
+</blockquote>
+<p> It is not uncommon to have more than one design mechanism associated with
+ a client class as a compromise between different characteristics. </p>
+<p> Because implementation mechanisms often come in bundles in off-the-shelf components
+ (operating systems and middleware products), some optimization based on cost,
+ impedance mismatch, or uniformity of style needs to occur. Also, mechanisms
+ are often interdependent, which makes clear separation of services into design
+ mechanisms difficult. </p>
+<blockquote>
+ <p class="example"> <b>Examples</b> </p>
+ <ul>
+ <li> The notification mechanism can be based on the inter-process communication
+ mechanism. </li>
+ <li> The error reporting mechanism can be based on the persistency mechanism.
+ </li>
+ </ul>
+</blockquote>
+<p> Refinement continues over the whole Elaboration phase, and is always a compromise
+ between: </p>
+<ul>
+
+ <li> An exact fit with the requirements of the clients of the design mechanism,
+ in terms of the expected characteristics. </li>
+ <li>
+ The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
+ </li>
+</ul>
+<p> The overall goal is always to have a simple, clean set of mechanisms that
+ give conceptual integrity, simplicity, and elegance to a large system. </p>
+<h3> Describing Design Mechanisms </h3>
+<p>
+ As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
+ architectural or design patterns (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>).
+</p>
+<blockquote>
+ <p> <strong>Example: A persistence mechanism </strong></p>
+ <p> This example uses an instance of a pattern for RDBMS-based persistency drawn
+ from <strong></strong><a
+ href="http://java.sun.com/products/jdbc/index.html" target="_blank" ><u>Java™
+ Database Connectivity (JDBC)</u></a>. Although we present the design here,
+ JDBC supplies actual code for some of the classes. Therefore, it is a short
+ step from what is presented here to an implementation mechanism. </p>
+</blockquote>
+<p> Figure 4, titled <strong> JDBC: Static view,</strong> shows the classes (actually,
+ the classifier roles) in the collaboration. <strong></strong></p>
+<p align="center"> <img height="382" title="Figure 4. JDBC: Static View" alt="Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. " src="./resources/jdbc1.gif" width="571" /></p>
+<p align="center"> <strong>Figure 4. JDBC: Static view </strong></p>
+<p align="left"> The yellow classes are the ones that were supplied. The others,
+ in tan (myDBClass and so on),
+ were bound by the designer to create the mechanism. </p>
+<p align="left"> In a Java database class, a client will work with a <b>DBClass</b>
+ to read and write persistent data. The DBClass is responsible for accessing the JDBC database, using the <b>DriverManager</b>
+ class. Once a database <b>connection</b> is open, the DBClass can then create SQL statements that will be sent to the underlying RDBMS
+ and executed using the <b>Statement</b> class. The Statement class is what communicates with the database. The result of the SQL query
+ is returned in a <b>ResultSet</b> object.<span style="mso-spacerun: yes"> </span>
+</p>
+<p align="left"> The <b>DBClass</b> is responsible for making another class instance
+ persistent. It understands the OO-to-RDBMS mapping and can interface with the
+ RDBMS. The DBClass flattens the
+ object, writes it to the RDBMS, and then reads the object data from the RDBMS
+ and builds the object. Every class that is persistent has a corresponding DBClass.
+</p>
+<p align="left"> The <b>PersistentClassList</b> is used to return a set of persistent
+ objects as a result of a database query, for example: DBClass.read().
+</p>
+<p align="left"> A series of dynamic views follow, in Figures 5 thorough 9, to
+ show how the mechanism actually works. <strong></strong></p>
+<p align="center"> <img height="146" title="Figure 5. JDBC: Initialize" alt="Diagram of JDBC: Initialize" src="./resources/jdbc2.gif" width="285" />
+</p>
+<p align="center"> <b>Figure5. JDBC: Initialize</b> </p>
+<p>
+ Initialization must occur before any persistent class can be accessed.
+</p>
+<p> To initialize the connection to the database, the DBClass
+ must load the appropriate driver by calling the DriverManager
+ getConnection() operation with a URL, user, and password. </p>
+<p> The operation getConnection()
+ attempts to establish a connection to the given database URL. The driver manager
+ attempts to select an appropriate driver from the set of registered JDBC drivers.
+</p>
+<blockquote>
+ <p> <strong>Parameters</strong></p>
+ <blockquote>
+ <p> <b>URL</b><strong>: </strong>A database URL in the form jdbc:subprotocol:subname.
+ This URL is used to locate the actual database server and is not Web-related,
+ in this instance. </p>
+ <p> <b>user</b><strong>: </strong>The database user who is making the connection.</p>
+ <p> <b>pass</b><strong>:</strong> The user's password </p>
+ </blockquote>
+ <p> <strong>Returns</strong></p>
+ <blockquote>
+ <p> A connection to the URL.</p>
+ </blockquote>
+</blockquote>
+<p align="center"> <img height="253" title="Figure 6. JDBC: Create" alt="Diagram of JDBC: Crreate" src="./resources/jdbc3.gif" width="478" />
+</p>
+<p align="center"> <b>Figure 6. JDBC: Create</b> </p>
+<p align="left"> To create a new class, the persistency client asks the DBClass
+ to create the new class. The DBClass
+ creates a new instance of PersistentClass with default values. The DBClass
+ then creates a new Statement using the Connection class createStatement()
+ operation. The Statement runs,
+ and the data is added to the database.</p>
+<p align="center"> <img height="352" title="Figure 7. JDBC: Read" alt="Diagram of JDBC: Read" src="./resources/jdbc4.gif" width="600" />
+</p>
+<p align="center"> <b>Figure 7. JDBC: Read</b> </p>
+<p> To read a persistent class, the persistency client asks the DBClass
+ to read. The DBClass creates
+ a new Statement using the Connection class createStatement() operation. The Statement is executed, and the
+ data is returned in a ResultSet object. The DBClass then creates
+ a new instance of the PersistentClass and populates it with the retrieved data. The data is returned in a collection
+ object, an instance of the PersistentClassList class. </p>
+<p> <strong>Note: </strong></p>
+<p>The string passed to executeQuery()
+ is not necessarily exactly the same string as the one passed into the
+ read(). The DBClass
+ will build the SQL query to retrieve the persistent data from the database,
+ using the criteria passed into the .
+ This is because it is not useful for the client of the DBClass
+ to know the internal structure of the database to create a valid query. This
+ knowledge is encapsulated within DBClass.
+</p>
+<p align="center"> <img height="255" title="Figure 8. JDBC: Update" alt="Diagram of JDBC: Update" src="./resources/jdbc5.gif" width="473" />
+</p>
+<p align="center"> <b>Figure 8. JDBC: Update</b> </p>
+<p> To update a class, the persistency client asks the
+ DBClass to update. The DBClass
+ retrieves the data from the given PersistentClass object, and creates a new Statement
+ using the Connection class createStatement()
+ operation. Once the Statement
+ is built, the database is updated with the new data from the class. </p>
+<p> <strong>Remember: </strong>It is the job of the DBClass
+ to flatten the PersistentClass and
+ write it to the database. That is why it must be retrieved from the given PersistentClass
+ before creating the SQL Statement.
+</p>
+<p> <strong>Note: </strong></p>
+<p>In the above mechanism, the PersistentClass
+ must provide access routines for all persistent data so that
+ DBClass can access them. This provides external access to certain persistent
+ attributes that would have been private otherwise. This is a price you have
+ to pay to pull the persistence knowledge out of the class that encapsulates
+ the data.</p>
+<p align="center"> <img height="255" title="Figure 9. JDBC: Delete" alt="Diagram of JDBC: Delete" src="./resources/jdbc6.gif" width="473" />
+</p>
+<p align="center"> <b>Figure 9. JDBC: Delete</b></p>
+<p align="left"> To delete a class, the persistency client asks the DBClass to delete the PersistentClass.
+ The DBClass creates a new Statement using the Connection class createStatement()
+ operation. The Statement is
+ executed and the data is removed from the database. </p>
+<p align="left"> In the actual implementation of this design, you would make some
+ decisions about the mapping of DBClass
+ to the persistent classes, such as having one DBClass
+ per persistent class and allocating them to appropriate packages. These packages
+ will depend on<strong> </strong>the supplied java.sql file (see <a href="http://java.sun.com/products/jdbc/index.jsp">JDBC:
+ API Documentation</a>)<strong> </strong>package that contains the supporting
+ classes DriverManager, Connection, Statement,
+ and ResultSet. </p><!-- END:mainDescription,-mAo18f36rZ1R98kpZX7HMw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.html
new file mode 100644
index 0000000..57e0a76
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.html
@@ -0,0 +1,170 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\find_and_outline_actors_and_ucs.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: find_and_outline_actors_and_ucs.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eyL0wCu-EdqSxKAVa9kmvA CRC: 2737869814 -->Find and Outline Actors and Use Cases<!-- END:presentationName,_eyL0wCu-EdqSxKAVa9kmvA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_eyL0wCu-EdqSxKAVa9kmvA CRC: 1762068069 -->This guideline describes how to find and outline actors and use cases.<!-- END:briefDescription,_eyL0wCu-EdqSxKAVa9kmvA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Rcm_MlViENAvFFyIe9V3dQ CRC: 2897019858 --><h4>
+ Finding actors
+</h4>
+<p>
+ Find the external entities with which the system under development must interact. Candidates include groups of users
+ who will require help from the system to perform their tasks and execute the system's primary or secondary functions,
+ as well as external hardware, software, and other systems.
+</p>
+<p>
+ Define each candidate actor by naming it and writing a brief description. Includes the actor's area of responsibility
+ and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not
+ have any goals.
+</p>
+<p>
+ These questions are useful in identifying actors:
+</p>
+<ul>
+ <li>
+ Who will supply, use, or remove information from the system?
+ </li>
+ <li>
+ Who will use the system?
+ </li>
+ <li>
+ Who is interested in a certain feature or service provided by the system?
+ </li>
+ <li>
+ Who will support and maintain the system?
+ </li>
+ <li>
+ What are the system's external resources?
+ </li>
+ <li>
+ What other systems will need to interact with the system under development?
+ </li>
+</ul>
+<p>
+ Review the list of stakeholders that you captured in the Vision statement. Not all stakeholders will be actors
+ (meaning, they will not all interact directly with the system under development), but this list of stakeholders is
+ useful for identifying candidates for actors.
+</p>
+<h4>
+ Finding use cases
+</h4>
+<p>
+ The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not,
+ ask:
+</p>
+<ul>
+ <li>
+ What are the goals that the actor will attempt to accomplish with the system?
+ </li>
+ <li>
+ What are the primary tasks that the actor wants the system to perform?
+ </li>
+ <li>
+ Will the actor create, store, change, remove, or read data in the system?
+ </li>
+ <li>
+ Will the actor need to inform the system about sudden external changes?
+ </li>
+ <li>
+ Does the actor need to be informed about certain occurrences, such as unavailability of a network resource, in
+ the system?
+ </li>
+ <li>
+ Will the actor perform a system startup or shutdown?
+ </li>
+</ul>
+<p>
+ Understanding how the target organization works and how this information system might be incorporated into
+ existing operations gives an idea of system's surroundings. That information may reveal other use case candidates.
+</p>
+<p>
+ Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case
+ does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case.
+</p>
+<h4>
+ Outlining Use Cases
+</h4>
+<p>
+ Without going into details, write a first draft of the flow of events of the use cases identified as being of high
+ priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step
+ description is a simple ordered list of interactions between the actor and the system. For example, the description of
+ the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this:
+</p>
+<ol>
+ <li>
+ The customer inserts a bank card.
+ </li>
+ <li>
+ The system validates the card and prompts the person to enter a personal identification number (PIN).
+ </li>
+ <li>
+ The customer enters a PIN.
+ </li>
+ <li>
+ The system validates the PIN and prompts the customer to select an action.
+ </li>
+ <li>
+ The customer selects Withdraw Cash.
+ </li>
+ <li>
+ The system prompts the customer to choose which account.
+ </li>
+ <li>
+ The customer selects the checking account.
+ </li>
+ <li>
+ The system prompts for an amount.
+ </li>
+ <li>
+ The customer enters the amount to withdraw.
+ </li>
+ <li>
+ The system validates the amount (assuming sufficient funds), and then issues cash and receipt.
+ </li>
+ <li>
+ The customer takes the cash and receipt, and then retrieves the bank card.
+ </li>
+ <li>
+ The use case ends.
+ </li>
+</ol>
+<p>
+ As you create this step-by-step description of the basic flow of events, you may discover alternative and exceptional
+ flows. For example, what happens if the customer enters an invalid PIN? Record the name and a brief description of each
+ alternate flow that you identified.
+</p>
+<h4>
+ Representing relationships between actors and use cases
+</h4>
+<p>
+ The relationship between actors and use cases should be captured, or documented There are several ways to do
+ this. If you are using a use-case model on the project, you can create use-case diagrams to show how actors and
+ use cases relate to each other. Refer to <a class="" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.
+</p>
+<p>
+ If you are not using a use-case model for the project, make sure that each use case identifies the associated primary
+ and secondary actors.
+</p><!-- END:mainDescription,-Rcm_MlViENAvFFyIe9V3dQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/implementation.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/implementation.html
new file mode 100644
index 0000000..b4de252
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/implementation.html
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\implementation.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implementation.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0Y0dsMlgEdmt3adZL5Dmdw CRC: 263885700 -->Implementation<!-- END:presentationName,_0Y0dsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0Y0dsMlgEdmt3adZL5Dmdw CRC: 3043388325 -->This guideline describes the different types of elements in an implementation.<!-- END:briefDescription,_0Y0dsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_4wqaMMPaEdmbOvqy4O0adg CRC: 1813033428 --><h5>
+ Code Reuse
+</h5>
+<p>
+ Code reuse and code generation tools produce more robust code and are preferable to writing code by hand. Existing code
+ has often already been tested and even deployed, making it more stable and well understood than new code. Source code
+ created from a code generation tool (such as a visual modeling tool) automates dreary coding tasks such as creating
+ getters and setters.
+</p>
+<p>
+ There are many places to harvest code for reuse:
+</p>
+<ul>
+ <li>
+ Internal (corporate) code libraries.
+ </li>
+ <li>
+ 3rd party libraries.
+ </li>
+ <li>
+ Built-in language libraries.
+ </li>
+ <li>
+ Code samples from tutuorials, examples, books, etc.
+ </li>
+ <li>
+ Local code guru or knowledgable colleague
+ </li>
+ <li>
+ Existing system code
+ </li>
+ <li>
+ Open source products (be sure to follow any licensing agreements)
+ </li>
+</ul>
+<h5>
+ Transforming the Design into the Implementation
+</h5>
+<p>
+ Transforming the design into code implements the system structure in the chosen source language. It also implements the
+ system behavior defined in the functional requirements. Implementing the system behavior means writing the code that
+ allows different parts of the application (classes or components) to collaborate in realizing the behavior of the
+ system.
+</p>
+<p>
+ There are various techniques for automatically transforming design to implementation. Here are some examples:
+</p>
+<ul>
+ <li>
+ Platform-specific visual models can be used to generate an initial code framework. This framework can be further
+ elaborated with additional code not specified in the design.<br />
+ </li>
+ <li>
+ Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and
+ behavior diagrams (such as state and activity diagram) can be used to generate executable code. These prototypes
+ can be further refined as needed.<br />
+ </li>
+ <li>
+ The design may be platform independent to varying degrees. Platform specific design models or even code can be
+ generated via transformations that apply various rules to map high level abstractions platform specific elements.
+ This is the focus of the Object Management Group (OMG) Model Driven Architecture (MDA) <a href="http://www.omg.org/" target="_blank">(http://www.omg.org</a>) initiative.<br />
+ </li>
+ <li>
+ Standard patterns can be applied to generate design and code elements from related design and implementation. For
+ example, a standard transformation pattern can be applied to a data table to create java classes to access the data
+ table. Another example is using an Eclipse Modeling Framework (<a href="http://www.eclipse.org/emf/" target="_blank">http://www.eclipse.org/emf/</a>) model to generate code for storing data that matches the model and
+ to generate a user interface implementation for populating data. A pattern or transformation engine can be used to
+ create the implementation, or the implementation can be done by hand. Pattern engines are easier and more reliable,
+ but hand-written code implementing a defined pattern will have fewer errors than hand-written code implementing a
+ novel or unique design.
+ </li>
+</ul>
+<p>
+ In all cases, however, some design abstraction (classes, components, etc) is detailed to become the
+ implementation.
+</p><!-- END:mainDescription,_4wqaMMPaEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/iteration_planning.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/iteration_planning.html
new file mode 100644
index 0000000..180ed23
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/iteration_planning.html
@@ -0,0 +1,158 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\iteration_planning.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration_planning.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0auiMMlgEdmt3adZL5Dmdw CRC: 3350302035 -->Iteration Planning<!-- END:presentationName,_0auiMMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0auiMMlgEdmt3adZL5Dmdw CRC: 4112489180 -->The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the iteration and produce a sufficiently detailed plan outlining who needs to do what.<!-- END:briefDescription,_0auiMMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_71hDkMPgEdmbOvqy4O0adg CRC: 1440019586 --><h3>
+ Introduction
+</h3>
+<p>
+ The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
+ iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
+ define how to assess that you accomplished what you set out to accomplish.
+</p>
+<p>
+ Iteration planning is ideally done with the entire team in a meeting, typically lasting a few hours, at the beginning
+ of an iteration. This ensures that the entire team understands what needs to be done, and they become committed to the
+ success of the team. In some cases, it is preferred to have a smaller subset of people, such as the Project Manager, an
+ Architect and an Analyst to meet in advance to prep the meeting with a draft iteration plan.
+</p>
+<h3>
+ Define High-Level Objectives
+</h3>
+<p>
+ A key aspect of an iteration is to focus the team on a short term deliverable of measurable value. Document 1-5
+ high-level objectives to make sure that you don't lose focus on what to accomplish during the iteration. Typically, the
+ project plan should outline one or several objectives for each iteration, and those objectives are used as a starting
+ point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
+</p>
+<p>
+ The objectives are usually based on the following factors:
+</p>
+<ul>
+ <li>
+ <strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
+ risks.
+ </li>
+ <li>
+ <strong>The time allocated to the iteration:</strong> Iterations are usually timeboxed, so the Project Manager must
+ ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the
+ iteration.
+ </li>
+ <li>
+ <strong>The highest priority features:</strong> requirements are prioritized to ensure that the critical features
+ of the application will be developed and tested early on.
+ </li>
+</ul>
+<h3>
+ Produce an Iteration Plan
+</h3>
+<p>
+ There is an Iteration Plan per iteration that should outline who will implement which Work Item in how long a time.
+ Since iterations are time-boxed, we need to understand how big our ‘box” is by assessing how many hours of actual work
+ can be taken on. Let’s assume that you have 6 team members, and you have 15 working days in your iteration, and you on
+ average can do 5 actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work. Note
+ that the average team member only performs 4-6 hours of actual project work per day, with the rest being consumed by
+ e-mails, meetings, and other overhead activities not directly related to the project.
+</p>
+<p>
+ The team should then revisit and update priorities for all the high-priority items in the Work Items List, to make sure
+ that an important Work Item is not missed that would otherwise fall just below the list of what can be taken on in this
+ iteration.
+</p>
+<p>
+ Pick the top-priority Work Item and see if it matches the objectives of the iteration. If it does, assess whether the
+ Work Item is too big to take on within an iteration. If it is too big, break it down into smaller Work Items. Once the
+ Work Item has been decomposed, the team determines whether to take on one or several child Work Items.
+</p>
+<p>
+ <em>Example: The team would like to take on Work Item “Develop Use Case A”, but it would take roughly 300 hours to
+ develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,
+ allowing them to take on other high-priority Work Items. They divide the Work Item into 5 smaller work items
+ representing different scenarios of use case A. The team decides to take on one out of the 5 identified scenarios in
+ this iteration.</em>
+</p>
+<p>
+ When a team has decided to take on a Work Item, it will assign the work to one or several team members. Ideally, this
+ is done by team members signing up to do the work, since this makes people motivated and committed to doing the job,
+ but based on culture, you may instead have the project manager assign the work.
+</p>
+<p>
+ The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
+ want to have each work assignment to be no more than 2 days of work. If the Work Item is too big, consider breaking it
+ down into smaller Work Items.
+</p>
+<p>
+ The team sums up the actual estimate for each Work Item they have committed to, and checks if they can commit to any
+ more work.
+</p>
+<p>
+ <em>Example: Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he
+ decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:</em>
+</p>
+<ul>
+ <li>
+ <em>Detail the requirements (Jack) —5 hours</em>
+ </li>
+ <li>
+ <em>Design the scenario (Jack, Ann, and David) —5 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the dB changes (Ann)—12 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the server portion (David)—16 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the client portion (Jack)—12 hours</em>
+ </li>
+ <li>
+ <em>Total—50 hours</em>
+ </li>
+</ul>
+<p>
+ As Work Items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
+ understand what is involved, and whether other team member may be better suited to take on a subset of the task
+</p>
+<p>
+ The team now determines whether they are willing to take on another Work Item by comparing actual hours signed up for
+ to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence have another
+ 400 hours available
+</p>
+<h3>
+ Define Evaluation Criteria
+</h3>
+<p>
+ It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
+ the iteration. Obvious success criteria should be that you can test the functionality implemented, and that no or few
+ defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
+ meaningful feedback. Test objectives and test cases need to be clearly outlined.
+</p>
+<p>
+ There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
+ favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
+</p><!-- END:mainDescription,_71hDkMPgEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/layering.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/layering.html
new file mode 100644
index 0000000..36a3b5a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/layering.html
@@ -0,0 +1,244 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\layering.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: layering.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0gpkAMlgEdmt3adZL5Dmdw CRC: 3853959620 -->Layering<!-- END:presentationName,_0gpkAMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0gpkAMlgEdmt3adZL5Dmdw CRC: 3823084377 -->Guidance on the possible ways for partitioning the system.<!-- END:briefDescription,_0gpkAMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_lbGQwMM3EdmSIPI87WLu3g CRC: 2945863335 --><p>
+ Layering logically partitions the subsystems into a number of sets, with certain rules regarding how relationships can
+ be formed between the layers. Layering provides a way to restrict inter-subsystem dependencies, with the result that
+ the system is more loosely coupled and, therefore, more easily maintained.
+</p>
+<p>
+ Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
+ than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
+ requirements. Removing layers is not always as easy and may introduce risks into the project.
+</p>
+<p>
+ The criteria for grouping subsystems follow a few patterns:
+</p>
+<ul>
+ <li>
+ <b>Visibility</b><strong>:</strong> Subsystems may depend only on subsystems in the same layer and the next-lower
+ layer.
+ </li>
+ <li>
+ <b>Volatility</b><strong>:</strong>
+ <ul>
+ <li>
+ <b>In the highest layers</b>, put elements that vary when user requirements change.
+ </li>
+ <li>
+ <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
+ language, operating system, database, and so forth).
+ </li>
+ <li>
+ <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
+ systems and implementation environments.
+ </li>
+ <li>
+ <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
+ model.
+ </li>
+ </ul>
+ </li>
+ <li>
+ <b>Generality</b><strong>:</strong> Abstract model elements tend to be placed lower in the model. If not
+ implementation-specific, they tend to gravitate toward the middle layers.
+ </li>
+ <li>
+ <b>Number of layers.</b> For a small system, three layers are sufficient. For a complex system, five to seven
+ layers are usually sufficient. For any degree of complexity, more than 10 layers should be viewed with suspicion
+ that increases with the number of layers. The table that follows gives you a few guidelines.
+ </li>
+</ul>
+<p align="center">
+ <strong>Guideline for number of layers according to number of classes</strong>
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="58%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th width="40%">
+ <p align="center" scope="col">
+ <b>Number of Classes</b>
+ </p>
+ </th>
+ <th width="60%">
+ <p align="center" scope="col">
+ <b>Number of Layers</b>
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 0 - 10
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ No layering needed
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 10 - 50
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 2 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 25 - 150
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 3 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 100 - 1000
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 4 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<p>
+ Failure to restrict dependencies according to Visibility criteria mentioned above can cause architectural degradation
+ and make the system difficult to extend and maintain.
+</p>
+<p>
+ Exceptions include cases where subsystems need direct access to lower-layer services. Make a decision about how to
+ handle primitive services that are needed throughout the system, such as printing, sending messages, and so forth.
+ There is little value in restricting messages to lower layers if the solution is to effectively implement call
+ pass-throughs in the intermediate layers.
+</p>
+<h4>
+ <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
+</h4>
+<p>
+ Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
+ partitioning present different issues to consider:
+</p>
+<p>
+ <b>User organization</b><strong>:</strong> Subsystems may be organized along lines that mirror the organization of
+ functionality in the business organization (partitioning occurs along departmental lines). This partitioning often
+ occurs early in the design because an existing enterprise model that is strongly partitioned according to the structure
+ of the organization. This pattern usually affects only the top few layers of application-specific services and often
+ disappears as the design evolves.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning along user-organization lines can be a good starting point for the model.
+ </p>
+ </li>
+ <li>
+ <p>
+ The structure of the user organization is not stable over a long period of time because business
+ reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
+ organization of the system should enable the system to evolve and be maintained independently of the
+ organization of the business that it supports.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Areas of competence and skills:</b> Subsystems may be organized to partition responsibilities for parts of the model
+ among different groups within the development organization. Typically, this occurs in the middle and lower layers of
+ the system, and reflects the need for specialization in skills during the development and support of an infrastructure
+ based on complex technology. Examples of such technologies include network and distribution management, database
+ management, communication management, and process control, among others. Partitioning along competence lines may also
+ occur in upper layers, where special competency in the problem domain is required to understand and support key
+ business functionality. Examples include telecommunication call management, securities trading, insurance claims
+ processing, and air traffic control, to name a few.
+</p>
+<p>
+ <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
+ so to speak, to reflect the distribution of functionality.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning to reflect distribution of functionality can help you visualize the network communication that
+ will occur as the system runs.
+ </p>
+ </li>
+ <li>
+ <p>
+ Partitioning to reflect distribution can also, however, make the system more difficult to change if the
+ deployment model changes significantly.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
+ develop or support, require additional partitioning according to security access privileges. Software that controls
+ access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
+ people with this background on the project is limited, the functionality requiring special clearance must be
+ partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
+ secrecy areas the only visible aspect of these subsystems.
+</p>
+<p>
+ <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
+ the system, should be organized into independent subsystems that are developed and delivered independently from the
+ mandatory functionality of the system.
+</p><!-- END:mainDescription,_lbGQwMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/maintaining_automated_test_suite.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/maintaining_automated_test_suite.html
new file mode 100644
index 0000000..9b3b7b1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/maintaining_automated_test_suite.html
@@ -0,0 +1,130 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\maintaining_automated_test_suite.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: maintaining_automated_test_suite.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0kF5kMlgEdmt3adZL5Dmdw CRC: 1468414705 -->Maintaining Automated Test Suite<!-- END:presentationName,_0kF5kMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0kF5kMlgEdmt3adZL5Dmdw CRC: 2041861399 -->This guideline explains ways to maintain automated test suites - collection of tests performed together for breadth and depth coverage.<!-- END:briefDescription,_0kF5kMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_8ngBgMPdEdmbOvqy4O0adg CRC: 2032769287 --><h3>
+ Introduction
+</h3>
+<p>
+ At some point in your test effort, you may find it necessary to manage your test effort by creating test suites for
+ your test assets. Maintaining test suites can take many different forms. To facilitate your testing, you may want
+ to introduce some level of automation of your test suites. The fact that you've automated your test
+ suites does not necessarily make your testing easier however. It may actually increase the maintenance burden of your
+ suites.
+</p>
+<p>
+ This guideline introduces you to useful heuristics on how to facilitate the maintenance of your automated test suites.
+</p>
+<h4>
+ Plan your test suites
+</h4>
+<p>
+ Automating your testing without planning increases the chances that testing will be ineffective
+ and inefficient. Some level of planning should take place whether implicit or explicit. An essential
+ part of any test plan is the definition of a strategy for test automation. Use your plan to articulate to the
+ development team how you plan to maintain your test assets. In many cases, this is never done. The rest of
+ the development team may be unaware of how you intend to maintain your tests. It is also a good practice to get
+ the rest of the development team to understand that this maintenance can be a substantial part of the overall
+ development effort. Use your test tooling to capture this information and treat this plan just like you would
+ treat any other test asset in your test repository.
+</p>
+<h4>
+ Centrally locate your test assets
+</h4>
+<p>
+ To facilitate the maintenance of your automated test suites, locate your test assets in a repository that can be
+ accessed by the development team. Many test automation environments provide test management tools that make it
+ easier to organize and access your test assets by maintaining the test assets (test cases, test scripts, and test
+ suites) in a common repository.
+</p>
+<p>
+ In addition, some form of access control is enforced by the automation test tool. This eases the maintenance
+ burden by ensuring the integrity of your test suites. You may choose to grant stakeholders and managers read-only
+ access, whereas developers and testers at the practitioner level may have read/write access.
+</p>
+<h4>
+ Treat your test assets like any other software
+</h4>
+<p>
+ Software must be maintained. This also applies to the software in your test suites. Test cases and their
+ associated test scripts, whether recorded or programmed, should be maintained. And just as software has different
+ kinds of maintenance (e.g., corrective, preventative, or adaptive) so too do the assets in your automated test suites.
+ As you lifecycle your test suites, identify, if only informally, how you plan to disposition the test suite
+ corrective maintenance (e.g., syntactical errors in your scripts), preventative maintenance (e.g., where possible
+ to write generalized test scripts), and adaptive maintenance (e.g., how you can use your test tooling to re-assign
+ test assets within one suite to another suite or suites). This can be captured, as described in the
+ section <strong>Plan Your Test Suites</strong> above, in your test plan.
+</p>
+<h4>
+ Improve the testability of your test suites through collaboration with developers
+</h4>
+<p>
+ It's one thing to say that your test suites will need to be maintained due to changes in the application, changes in
+ the testing target, etc. It's quite another thing to actually determine whether a test suite needs to be
+ revamped and, if it does, what test assets within it need to be addressed.
+</p>
+<p>
+ One way to facilitate this is to use test suites as a way to communicate test decision to the developers. One way
+ to perform continuous perfective maintenance of test suites is to think of your test suites as assets that belong to
+ the development team rather than just the testers. You can perform a kind of perfective maintenance on test in
+ the following ways:
+</p>
+<ul>
+ <li>
+ use test suites to raise the level of abstraction
+ </li>
+ <li>
+ use test suites to provide focus for the developer
+ </li>
+ <li>
+ use test suites to articulate areas that the developers would like testers to focus on
+ </li>
+ <li>
+ make the construction and maintenance of test suites more efficient by understanding what area(s)
+ developers want to focus on
+ </li>
+ <li>
+ use test suites to clarify test targets with developers
+ </li>
+</ul>
+<h4>
+ Don't be afraid to clean up your suites
+</h4>
+<p>
+ Your test assets will evolve just as the application under test will. As requirements to the system change, the
+ application will change as well. To maintain your test suites, you should continually check whether test
+ assets are valid. If possible, validity checks should be performed after each new release of the software,
+ preferably more frequently. Keeping your test suites relevant is a full-time job. Assume that changes in the
+ software will lead to some degree of invalid tests within your test suites. Once these test assets have been
+ identified as invalid, get rid of them. This will make the maintenance burden much more tolerable. Some
+ automated test tooling environments make this task easier by providing ways to package outdated or invalid
+ tests. In some cases, you may not be absolutely sure whether you want to completely get rid of tests within your
+ test suite or even of getting rid of test suites altogether. To alleviate this burden, you can create packages
+ for obsolete tests or test suites and dispose of tests or test suites by putting them in packages labeled for this
+ purpose.
+</p><!-- END:mainDescription,_8ngBgMPdEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_and_openup_basic.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_and_openup_basic.html
new file mode 100644
index 0000000..02f716b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_and_openup_basic.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\openup_and_openup_basic.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_and_openup_basic.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_v2l6gK_5EduMeuOwJ2MpeQ CRC: 3059082846 -->OpenUP and OpenUP/Basic<!-- END:presentationName,_v2l6gK_5EduMeuOwJ2MpeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_v2l6gK_5EduMeuOwJ2MpeQ CRC: 2848520326 -->OpenUP is a family of open source process plug-ins. OpenUP/Basic is the core process in OpenUP and is geared towards a small, co-located team.<!-- END:briefDescription,_v2l6gK_5EduMeuOwJ2MpeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KCSbXYv5TALlL00zMMfgVw CRC: 1271532774 --><p>
+ What's the difference between OpenUP and OpenUP/Basic?
+</p>
+<p>
+ How does OpenUP relate to EPF?
+</p><!-- END:mainDescription,-KCSbXYv5TALlL00zMMfgVw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_architecture.html
new file mode 100644
index 0000000..fa64887
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_architecture.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\openup_architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_REqtUMEvEduwZvIr61GnNg CRC: 668388554 -->The Importance of Architecture in OpenUP/Basic<!-- END:presentationName,_REqtUMEvEduwZvIr61GnNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_REqtUMEvEduwZvIr61GnNg CRC: 3323858254 -->The early iterations of OpenUP/Basic focus on addressing the requirements that will produce an executable architecture. Buiding and validating the architecture first significantly reduces the technical risk in a project.<!-- END:briefDescription,_REqtUMEvEduwZvIr61GnNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-clUV9n59dDwg0e1VCcsB8Q CRC: 3439967818 --><p>
+ Describe how Elaboration deals with architecture (link to existing content).
+</p>
+<p>
+ The architecture artifacts are the work products that provide the most benefit in development in terms of understanding
+ and extending the system.
+</p>
+<p>
+ Explain how architecture reduces technical risk and the importance of doing so.
+</p><!-- END:mainDescription,-clUV9n59dDwg0e1VCcsB8Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_iterations.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_iterations.html
new file mode 100644
index 0000000..ce84c43
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_iterations.html
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\openup_iterations.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_iterations.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_U3VjIMEuEduwZvIr61GnNg CRC: 1858919771 -->The Benefit of OpenUP/Basic Iterations<!-- END:presentationName,_U3VjIMEuEduwZvIr61GnNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_U3VjIMEuEduwZvIr61GnNg CRC: 2014282375 -->The set of iterations in a phase address specific milestones that objectively track a project's progress. Each phase has its own milestone that reflects the emphasis of the phase.<!-- END:briefDescription,_U3VjIMEuEduwZvIr61GnNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Mobjz86dw07NW5-IhtEoNA CRC: 2361009456 -->Describe the milestone of each phase (link to existing content). Explain that iterations are not homogeneous, but they
+all deliver stakeholder value. explain that that the focus on reducing risk and understanding the architecture in I & E
+make C & T more predictable.<!-- END:mainDescription,-Mobjz86dw07NW5-IhtEoNA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_risk.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_risk.html
new file mode 100644
index 0000000..ca03119
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/openup_risk.html
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\openup_risk.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_risk.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_G08UgMEwEduwZvIr61GnNg CRC: 555205771 -->OpenUP/Basic constantly identifies and removes risk from a project<!-- END:presentationName,_G08UgMEwEduwZvIr61GnNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_G08UgMEwEduwZvIr61GnNg CRC: 2124238126 -->Risk is a reflection of uncertainty in a project. Reducing uncertainty increases the predictability and possible of success.<!-- END:briefDescription,_G08UgMEwEduwZvIr61GnNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_BjYXvrfe1HHL5Y_QBfh4Q CRC: 883482764 --><p>
+ Define risk (reference existing content).
+</p>
+<p>
+ Explain how addressing risk in early iterations reduces the uncertainty and unpredictabiliy in future iterations.
+ Describe the effect that identifying, tracking, and mitigating risk has on a project (better decisions, high comfort
+ level, more visibility into problems).
+</p>
+<p>
+ Reference definitions for risk and risk mitigation.
+</p><!-- END:mainDescription,-_BjYXvrfe1HHL5Y_QBfh4Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/programming_automated_tests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/programming_automated_tests.html
new file mode 100644
index 0000000..eb84e11
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/programming_automated_tests.html
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\programming_automated_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: programming_automated_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0j5sUMlgEdmt3adZL5Dmdw CRC: 834555345 -->Programming Automated Tests<!-- END:presentationName,_0j5sUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0j5sUMlgEdmt3adZL5Dmdw CRC: 3933129686 -->This guideline discusses ways of structuring, recording, entering data, executing and handling errors in automated tests.<!-- END:briefDescription,_0j5sUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_vuwC4MPcEdmbOvqy4O0adg CRC: 3545264993 --><h3>
+ Introduction
+</h3>
+<p>
+ Although the programming of automated tests should contribute to the overall test effort, it usually does not make up
+ the entire test effort. In fact, test environments that are based on a complete automation approach end up spending
+ more time on test automation than on testing. Before you begin developing automated test scripts, consider first
+ whether it is more efficient to perform manual testing. Some aspects of an application are more efficiently tested
+ manually (for example, GUI testing versus data-drive testing). If you decide to program automated test scripts, examine
+ what aspects of your test scripting can be automated and begin designing your scripts.
+</p>
+<h3>
+ Design your automated tests
+</h3>
+<p>
+ Without some level of design of your automated tests, introducing automation into your testing effort can lead to more
+ problems than it solves. You should consider developing your automated tests according to a lifecycle with automation
+ test requirements, design, testing of the automation tests, and implementation of the automation tests. This approach
+ can be informal or formal depending on your project needs. By designing the programming of your automated tests, you
+ can avoid spending time programming the wrong tests, re-working programmed tests, deciphering different coding styles
+ in the programming of the tests, etc.
+</p>
+<h3>
+ Recorded versus programmed scripts
+</h3>
+<p>
+ Although there are clear benefits to recorded scripts (for example, ease of creation or ability for novice testers to
+ learn a scripting language), recorded scripts also present their own problems. The disadvantages of playback scripts
+ are well known. They are deceptively easy to create but very difficult to update. Problems with script reliability,
+ hard-coded data values, or changes to the application under test and the need to re-record are well-documented. On the
+ other hand, programming scripts can present difficulties of their own: they are difficult for the novice tester to
+ create, they can require substantial time and effort to develop, and they can be difficult to debug. Most test tooling
+ makes these issues less problematic by providing the tester script support functions, such as ways to establish target
+ of test lists, systematic ways to program verification point, point to datapools, build commands into the script (for
+ example, sleeper commands), comment the script, and document the script. Another major advantage, which is often
+ overlooked, of using testing tooling to mitigate these risks is the ability to add to an existing script in the form of
+ making corrections to an existing script, testing new features of a test target or application under test, or resuming
+ a recording after an interruption.
+</p>
+<h3>
+ Functional and performance test scripts
+</h3>
+<p>
+ When discussing automating test scripts, it is important to distinguish between functional and performance tests. Most
+ discussions of programming automated test scripts focus on testing the functionality of an application. This is not
+ inappropriate, since a lot of automated testing focuses on functional testing. Performance test scripting, however, has
+ its unique characteristics. Performance test automation provides you with the ability to programmatically set workloads
+ by adding user groups to test loads under group usage, setting think time behavior, running tests randomly or at set
+ rates, or setting the duration of a run. Performance test automation also allows you to create and maintain schedules
+ for your tests.
+</p>
+<h3>
+ Testing test scripts
+</h3>
+<p>
+ When testing your test scripts, keep in mind whether you are testing recorded or programmed test scripts. For recorded
+ scripts, much of the debugging of the script consists of errors that are introduced due to changes in the test target
+ or test environment. When you run a recorded test script, consider the test target of the script. Some test automation
+ tools capture this information as a part of the test script. Debugging a recorded script consists largely of
+ determining whether changes in the target have created error conditions in the script. In general, there are two main
+ categories to examine here: changes in the UI and test session sensitive data (for example, date stamped data). In most
+ cases, discrepancies between recording and playback cause errors in your recorded test scripts.
+</p>
+<p>
+ Testing programmed test scripts involves many of the same debugging techniques you would apply to debugging an
+ application. Consider both the flow control logic and the data aspects of your script. Automated testing tools provide
+ you with test script debugging IDEs as well as datapool management features that facilitate this type of testing.
+ During execution of test scripts, a test that uses a datapool can replace values in the programmed test with variable
+ test data that is stored in the datapool.
+</p><!-- END:mainDescription,_vuwC4MPcEdmbOvqy4O0adg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/promoting_builds.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/promoting_builds.html
new file mode 100644
index 0000000..f56461d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/promoting_builds.html
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\promoting_builds.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: promoting_builds.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SM4YIL6dEdqti4GwqTkbsQ CRC: 495951481 -->Promoting Builds<!-- END:presentationName,_SM4YIL6dEdqti4GwqTkbsQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_SM4YIL6dEdqti4GwqTkbsQ CRC: 471641791 -->This guideline describes how to migrate a build up through a set of tiers from a private development area to a release area.<!-- END:briefDescription,_SM4YIL6dEdqti4GwqTkbsQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-zCM2ucJJxc_bQr_LoHlSaQ CRC: 3467665125 --><p>
+ During iterative software development the team will create numerous <a class="elementLink"
+ href="./../../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>s. A build is initiated by combining the work completed by one or more
+ developers and resolving any conflicts that are encountered. Ideally a build is then subjected to a battery of tests to
+ determine if it is of sufficient quality to move into production.
+</p>
+<p>
+ As a build progresses from development towards production it is beneficial to know two characteristics:
+</p>
+<p>
+ <strong>Build contents</strong> – identifying the elements and their versions
+</p>
+<ul>
+ <li>
+ What is in this build (completed work items)
+ </li>
+ <li>
+ What is partially in this build (work items that are partially complete)
+ </li>
+ <li>
+ What is not in this build (work items that are not reflected at all in this build)
+ </li>
+</ul>
+<p>
+ <strong>Verification Level</strong> – identifying what amount of testing that has been completed. For example,
+</p>
+<ul>
+ <li>
+ Unit Tested
+ </li>
+ <li>
+ Integration Tested
+ </li>
+ <li>
+ System Tested
+ </li>
+</ul>
+<p>
+ The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
+ the following steps:
+</p>
+<ul>
+ <li>
+ Changes are introduced into the system in the form of completed work items
+ </li>
+ <li>
+ A build is generated clearly identifying the changes
+ </li>
+ <li>
+ Testing is conducted
+ </li>
+ <li>
+ When testing is successful the changes are delivered to the next verification level
+ </li>
+</ul>
+<p>
+ Ultimately all required testing is complete and the a new system version is ready.
+</p>
+<p>
+ It can also be beneficial to isolate work being performed at the different stages using different <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/workspace,_0cEmAMlgEdmt3adZL5Dmdw.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>s. This ensures that the effort of testing a build is applied to the
+ correct version and also allows developers to continue working on the next build while the previous build is being
+ tested.
+</p>
+<p>
+ A promotional lifecycle such as this offers three key benefits
+</p>
+<ol>
+ <li>
+ Reduces effort because there is no reason to execute the tests in the next stages until the build passes the
+ previous stage. For example you would not commit the resources to System Testing a build until it passes
+ integration tests.
+ </li>
+ <li>
+ Helps to ensure that a build which is moved into production has been subjected to the appropriate level of testing
+ first.
+ </li>
+ <li>
+ Simplifies debugging since developers can base their work on a proven build (Integration Tested build, for example)
+ in relative isolation from destabilizing changes from other developers
+ </li>
+</ol><!-- END:mainDescription,-zCM2ucJJxc_bQr_LoHlSaQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.html
new file mode 100644
index 0000000..6c1020a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.html
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\repres_interfaces_to_ext_systems.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: repres_interfaces_to_ext_systems.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0gjdYMlgEdmt3adZL5Dmdw CRC: 196640360 -->Representing Interfaces to External Systems<!-- END:presentationName,_0gjdYMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0gjdYMlgEdmt3adZL5Dmdw CRC: 307037135 -->This guideline introduces system level interfaces.<!-- END:briefDescription,_0gjdYMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_iCwb8MM3EdmSIPI87WLu3g CRC: 2615218417 --><p>
+ Interfaces with external systems should be consistently handled throughout the system, so markers need to be identified
+ in the architecture to make sure that the team develop the coherant software. The architecture need not include a
+ specific, detailed design for each system interface. It is often enough to simply identify the existence of the
+ interfacre as a significant part of the architecture and create a subsystem to encapsulate the detail, so that it can
+ be developed later.
+</p>
+<p>
+ The <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides the basis for a useful technique to
+ support this.
+</p>
+<p>
+ If the system communicates with another system, define one or more boundary classes to describe the communication
+ protocol. An external system may be anything from software to hardware units that the current system will use, such as
+ printers, terminals, alarm devices, and sensors. In each case, a boundary class that mediates the communication with
+ the external system will be identified.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ An automated teller machine (ATM) must communicate with the ATM network to ascertain whether a customer's bank
+ number and PIN are correct, and whether the customer has sufficient funds to withdrawal the requested amount. The
+ ATM network is an external system (from the perspective of the ATM); therefore, you would use a
+ <strong>boundary</strong> class to represent it in a use-case analysis.
+ </p>
+</blockquote>
+<p>
+ If the interfaces with the system are simple and well-defined, a single class may be sufficient to represent the
+ external system. Often, however, these interfaces are too complex to be represented by using a single class; they often
+ require complex collaborations of many classes. Moreover, interfaces between systems are often highly reusable across
+ applications. As a result, in many cases, a subsystem models the system interfaces more appropriately.
+</p>
+<p>
+ The use of a subsystem allows the interface to the external system to be defined and stabilized, while leaving the
+ design details of the system interface hidden as the system evolves.<br />
+</p><!-- END:mainDescription,_iCwb8MM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/req_gathering_techniques.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/req_gathering_techniques.html
new file mode 100644
index 0000000..95a276e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/req_gathering_techniques.html
@@ -0,0 +1,373 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\req_gathering_techniques.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: req_gathering_techniques.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_OnoNQNSAEdmLhZ9H5Plxyw CRC: 1425429376 -->Requirements Gathering Techniques<!-- END:presentationName,_OnoNQNSAEdmLhZ9H5Plxyw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_OnoNQNSAEdmLhZ9H5Plxyw CRC: 856766130 -->This guideline describes various techniques for gathering requirements.<!-- END:briefDescription,_OnoNQNSAEdmLhZ9H5Plxyw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_On0agNSAEdmLhZ9H5Plxyw CRC: 2060238320 --><h3>
+ Sources of Requirements
+</h3>
+<p>
+ Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one
+ that takes few resources. Examples of sources of requirements include:
+</p>
+<ul>
+ <li>
+ Customers
+ </li>
+ <li>
+ Users
+ </li>
+ <li>
+ Administrators and maintenance staff
+ </li>
+ <li>
+ Partners
+ </li>
+ <li>
+ Domain Experts
+ </li>
+ <li>
+ Industry Analysts
+ </li>
+ <li>
+ Information about competitors
+ </li>
+</ul>
+<h3>
+ Requirements Gathering Techniques
+</h3>
+<p>
+ After you have identified these sources, there are a number of techniques that may be used to gather requirements. The
+ following will describe the various techniques, followed by a brief discussion of when to use each technique.
+</p>
+<p>
+ To get the requirements down on paper, you can to do one or more of the following:
+</p>
+<ul>
+ <li>
+ Conduct a brainstorming session
+ </li>
+ <li>
+ Interview users
+ </li>
+ <li>
+ Send questionnaires
+ </li>
+ <li>
+ Work in the target environment
+ </li>
+ <li>
+ Study analogous systems
+ </li>
+ <li>
+ Examine suggestions and problem reports
+ </li>
+ <li>
+ Talk to support teams
+ </li>
+ <li>
+ Study improvements made by users
+ </li>
+ <li>
+ Look at unintended uses
+ </li>
+ <li>
+ Conduct workshops
+ </li>
+ <li>
+ Demonstrate prototypes to stakeholders
+ </li>
+</ul>
+<p>
+ The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put
+ in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best
+ structure you can devise, but expect to keep on correcting it throughout the process. Success tips: Do it now,
+ keep it small, and correct it immediately.
+</p>
+<h4>
+ Conduct a brainstorming session
+</h4>
+<p>
+ Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of
+ discussion. After that, a facilitator leads the group in organizing and prioritizing the results. The following
+ basic rules for brainstorming ensures better results:
+</p>
+<ul>
+ <li>
+ Start out by clearly stating the objective of the brainstorming session.
+ </li>
+ <li>
+ Generate as may ideas as possible.
+ </li>
+ <li>
+ Let your imagination soar.
+ </li>
+ <li>
+ Do not allow criticism or debate while you are gathering information.
+ </li>
+ <li>
+ Once information is gathered, reshape and combine ideas.
+ </li>
+</ul>
+<h4>
+ Interview users
+</h4>
+<p>
+ Face-to-face contact with users through individual interviewing is the primary source of requirements and an important
+ way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can
+ conduct interviews many different ways. Develop a repertoire of styles to fit different situations. Unless you use
+ the system yourself, you will need to make an effort to understand and experience the user's problem to describe it
+ clearly and correctly.
+</p>
+<h4>
+ Send Questionnaires
+</h4>
+<p>
+ If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering
+ the problem behind the problem. Sometimes, though, face-to-face meetings with stakeholders are not feasible (when
+ developing products for the consumer market, for example). In those situations, consider using questionnaires.
+ Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to
+ complete it and return it to you. Success tips: Keep it short and given them a deadline.
+</p>
+<p>
+ This technique has the advantage of providing a lot of information for statistical analysis. However, the questions
+ must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.
+</p>
+<h4>
+ Work in the target environment
+</h4>
+<p>
+ Experience the work of the users for yourself. Working with users helps you understand problems that have resisted
+ previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as
+ interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the
+ desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other
+ areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just
+ sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they
+ would like to have to make the work easier.
+</p>
+<h4>
+ Study analogous systems
+</h4>
+<p>
+ The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and
+ systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the
+ wheel by looking at systems already on the market, whether they are systems installed at the user's site or products
+ made by rival organizations. Even if they are trying to solve slightly different problems, they often provide
+ valuable clues as to what you need to do.
+</p>
+<p>
+ Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these
+ suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements
+ directly this way. If not, capture and store suggestions for future use.
+</p>
+<p>
+ You can describe to users selected features of other products. Explain that the system is designed for another
+ purpose but contains an interesting feature, and you wonder it or something similar would help them.
+ Sometimes these systems are described in documents, such as a contract from another organization or a report written
+ for management. Often, these documents were never intended as formal requirements, and were written merely to
+ communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
+</p>
+<p>
+ Such a process might involve the following activities:
+</p>
+<ul>
+ <li>
+ Read the document from end to end (several times) to comprehend what the customer wants and what actually has been
+ written.
+ </li>
+ <li>
+ Classify all of the types of information in the document. (user, system requirements, design elements, plans,
+ background material, irrelevant detail)
+ </li>
+ <li>
+ Mark up the original text to separate out such requirements.
+ </li>
+ <li>
+ Find a good structure for each of the different types of information such as: a scenario for the user requirements,
+ functional breakdown for the system requirements, and architecture for the design.
+ </li>
+ <li>
+ Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions
+ with the users.
+ </li>
+ <li>
+ Create traceability links between these information elements to show the designers exactly what the users want.
+ </li>
+ <li>
+ Convince the customer to accept the new information as the basis for the contract.
+ </li>
+</ul>
+<h4>
+ Examine suggestions and problem reports
+</h4>
+<p>
+ Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at
+ suggestions and problems as first described. Most organizations have a form for reporting system problems or software
+ defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can
+ identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users'
+ actual needs.
+</p>
+<h4>
+ Talk to support teams
+</h4>
+<p>
+ Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do
+ the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff
+ and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training
+ team and installation teams about what users find to be difficult.
+</p>
+<h4>
+ Study improvements made by users
+</h4>
+<p>
+ This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or
+ related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why
+ did you add that? Their answers help you get to the heart of the actual requirement. This applies also to hardware
+ and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents
+ movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product,
+ which makes it a valid requirement for the new version.
+</p>
+<h4>
+ Look at unintended uses
+</h4>
+<p>
+ People often use things for purposes for which they were not designed. This is a good way to get new ideas
+ and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the
+ office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive
+ commercial products are now widely available for home use.
+</p>
+<h4>
+ Conduct workshops
+</h4>
+<p>
+ Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of
+ requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each
+ requirement, the document becomes much more useful and cost-effective.
+</p>
+<p>
+ Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You
+ are bringing the right collection of people together, and getting them to correct and improve on their requirements
+ document.
+</p>
+<p>
+ A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If
+ you can define the product right the first time and cut three months off the requirements gathering, the savings could
+ be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
+</p>
+<p>
+ Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should
+ be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that
+ people don't go home at night or go out separately. The example in Figure 1 shows the logic of a requirements
+ workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques
+ such as brainstorming.
+</p>
+<p>
+ <img height="381" alt="" src="./resources/Workshop%20Activity%20Diagram.GIF" width="542" />
+</p>
+<p>
+ <strong>Figure 1: Conducting Workshops</strong>
+</p>
+<h4>
+ Demonstrate prototypes to stakeholders
+</h4>
+<p>
+ Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can
+ provoke them into giving good requirements information or changing their mind about existing requirements. The
+ techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of
+ presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might
+ be able to do. More requirements are likely to emerge when users see what you are suggesting.
+</p>
+<p>
+ A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a
+ vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that
+ there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here
+ for the unwary).
+</p>
+<p>
+ This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or
+ product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and
+ right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems
+ with the prototype! This is excellent, because each problem leads to a new requirement.
+</p>
+<h3>
+ Which Technique to Apply?
+</h3>
+<p>
+ Which technique to apply depends on a number of factors, such as:
+</p>
+<ul>
+ <li>
+ Availability and location of stakeholders
+ </li>
+ <li>
+ Development team knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the development process and methods
+ </li>
+</ul>
+<p>
+ If the stakeholders are not co-located or readily available, for example in the case of a product being developed for
+ mass market, techniques such as brainstorming, interviews and workshops that require face-to-face contact with the
+ stakeholders may be difficult or impossible.
+</p>
+<p>
+ If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the
+ techniques described, or combination of them, may be applied. In this case, the domain and development experience of
+ oth the stakeholders and the development team are critical factors in selecting the appropriate technique.
+</p>
+<p>
+ Figure 2, adapted from <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>, provides a framework for determining the appropriate techniques. It
+ defines four main categories of customer or user experience and development team experience: "Fuzzy problem",
+ "Selling/Teaching", "Catch up", and "Mature".
+</p>
+<p>
+ <img height="470" alt="" src="./resources/Which%20Req%20Gathering%20Technique.gif" width="514" />
+</p>
+<p>
+ <strong>Figure 2: Selection of Techniques</strong>
+</p>
+<p>
+ There is no "right answer", but these guidelines may help you decide which method to use:
+</p>
+<ul>
+ <li>
+ Catch-up: Interviews, work in target environment
+ </li>
+ <li>
+ Fuzzy: Brainstorming, workshops
+ </li>
+ <li>
+ Mature: Questionnaires, workshops, prototypes
+ </li>
+ <li>
+ Selling/Teaching: prototypes
+ </li>
+</ul><!-- END:mainDescription,_On0agNSAEdmLhZ9H5Plxyw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/requirement_pitfalls.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/requirement_pitfalls.html
new file mode 100644
index 0000000..995c0b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/requirement_pitfalls.html
@@ -0,0 +1,276 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\requirement_pitfalls.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: requirement_pitfalls.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_1AOsMO0JEdqHTdbLTmC5IQ CRC: 949539392 -->Requirement Pitfalls<!-- END:presentationName,_1AOsMO0JEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_1AOsMO0JEdqHTdbLTmC5IQ CRC: 3236194937 -->This guideline describes common pitfalls to avoid in defining and writing requirements. In some cases these are the inverse of the guidelines for writing good requirements, however, by showing examples of what NOT to do makes the explanation of what TO DO clearer.<!-- END:briefDescription,_1AOsMO0JEdqHTdbLTmC5IQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Q72-dNdHnZ93aRXAB_d34A CRC: 1796958463 --><p>
+ Explanations and examples follow for each of the following common pitfalls to avoid, in defining and writing
+ requirements (for more information, see <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>):
+</p>
+<ul>
+ <li>
+ Avoid ambiguity.
+ </li>
+ <li>
+ Don't make multiple requirements.
+ </li>
+ <li>
+ Never use let-out or escape words.
+ </li>
+ <li>
+ Don't ramble.
+ </li>
+ <li>
+ Resist designing the system.
+ </li>
+ <li>
+ Avoid mixing different kinds of requirements.
+ </li>
+ <li>
+ Do not speculate.
+ </li>
+ <li>
+ Do not use vague, undefined terms.
+ </li>
+ <li>
+ Do not express possibilities.
+ </li>
+ <li>
+ Avoid wishful thinking.
+ </li>
+</ul>
+<h4>
+ Avoid ambiguity
+</h4>
+<p>
+ Avoidance of ambiguity is one of the subtlest and most difficult issues in writing requirements. Try to write as
+ clearly and explicitly as possible. Be specific. Remember, though, that if you carry this too far, the text becomes
+ dull and unreadable, which makes it difficult for other people to review. Although this guideline emphasizes
+ structured, written expression of requirements, informal text, diagrams, conversations, and phone calls are excellent
+ ways of removing ambiguity.
+</p>
+<p>
+ Some constructions (such as the use of or and unless in requirements) allow different groups of readers to understand
+ different things from the same wording. Developers could use this technique deliberately, so as to postpone, until too
+ late, any possibility of the customer's asking for what was truly wanted. This is dangerous and could easily backfire.
+</p>
+<p>
+ The only approach that works is for developers to make requirements as clear as possible, and for all stakeholders to
+ co-operate. In the long run, project success is in everybody's interest.
+</p>
+<p>
+ Dangerous ambiguities can be caused by the word <strong>or</strong> and also by many more-subtle errors.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The same subsystem shall also be able to generate a visible or audible caution/warning signal for the attention of
+ the co-pilot or navigator.</em>
+</p>
+<p>
+ Which subsystem? Is the signal to be visible, audible, or both? Is it both caution and warning, just caution, or just
+ warning? Is it for both the co-pilot and the navigator, or just one of them? If just one of them, which one and under
+ what conditions?
+</p>
+<h4>
+ Don't make multiple requirements
+</h4>
+<p>
+ Requirements which contain conjunctions (words that join independent clauses together) are dangerous. Problems arise
+ when readers try to figure out which part applies, especially if the different clauses seem to conflict, or if the
+ individual parts apply separately. Multiple requirements also make verification more complex.
+</p>
+<p>
+ Dangerous conjunctions include: and, or, but
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or
+ input data shall be saved.</em>
+</p>
+<p>
+ Should the battery low warning lamp light up when the voltage drops and the workspace is saved? Should the battery low
+ warning lamp light up and the workspace be saved when the voltage drops?
+</p>
+<h4>
+ Never use let-out or escape words
+</h4>
+<p>
+ Requirements that include options or exceptions are dangerous. They seem to ask for something definite, but at the last
+ moment they back down and allow for other options. Problems arise when the requirements are to be tested, and someone
+ has to decide what (if anything) could prove the requirement was met.
+</p>
+<p>
+ Dangerous words that imply exceptions include: if, when, but, except, unless, although.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is
+ deployed.</em>
+</p>
+<p>
+ <em>The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has
+ suppressed the alarm.</em>
+</p>
+<p>
+ The latter sentence is a truly dangerous requirement!
+</p>
+<h4>
+ Don't ramble
+</h4>
+<p>
+ Long rambling sentences, especially when combined with arcane language, references to unreachable documents, and other
+ defects of writing, quickly lead to confusion and error.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Provided that the designated input signals from the specified devices are received in the correct order where the
+ system is able to differentiate the designators, the output signal shall comply with the required framework of section
+ 3.1.5 to indicate the desired input state.</em>
+</p>
+<h4>
+ Resist designing the system
+</h4>
+<p>
+ Requirements should specify the design envelope without unnecessary constraints on a specific design. If we supply too
+ much detail we start to design the system. Going too far is tempting for designers, especially when they come to their
+ favorite bits.
+</p>
+<p>
+ Danger signs include names of components, materials, software objects/procedures, and database fields.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof
+ hardened rubber shield.</em>
+</p>
+<p>
+ Specifying design rather than actual need increases the cost of systems by placing needless constraints on development
+ and manufacture. Often knowing why is much better than knowing what.
+</p>
+<h4>
+ Avoid mixing different kinds of requirements
+</h4>
+<p>
+ The user requirements form a complete model of what users want. They need to be organized coherently to show gaps and
+ overlaps. The same applies to system requirements, which form a complete functional model of the proposed system. A
+ quick road to confusion is to mix up requirements for users, systems, and how the system should be designed, tested, or
+ installed.
+</p>
+<p>
+ Danger signs are any references to system, design, testing, or installation.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The user shall be able to view the currently selected channel number which shall be displayed in 14pt Swiss type on
+ an LCD panel tested to Federal Regulation Standard 567-89 and mounted with shockproof rubber washers.</em>
+</p>
+<h4>
+ Do not speculate
+</h4>
+<p>
+ Requirements are part of a contract between customer and developer. There is no room for wish lists, meaning general
+ terms about things that somebody probably wants.
+</p>
+<p>
+ Danger signs include vagueness about which type of user is speaking, and generalization such as: usually, generally,
+ often, normally, typically
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Users normally require early indication of intrusion into the system.</em>
+</p>
+<h4>
+ Do not use vague, undefined terms
+</h4>
+<p>
+ Many words used informally to indicate system quality are too vague for use in requirements. Vague terms include, among
+ others: user-friendly, versatile, flexible, approximately, as possible
+</p>
+<p>
+ Requirements using these terms are unverifiable because there is no definite test to show whether the system has the
+ indicated property.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The print dialog shall be versatile and user-friendly.</em>
+</p>
+<p>
+ <em>The OK status indicator lamp shall be illuminated as soon as possible after the system self-check is
+ completed.</em>
+</p>
+<h4>
+ Do not express possibilities
+</h4>
+<p>
+ Suggestions that are not explicitly stated as requirements are invariably ignored by developers.
+</p>
+<p>
+ "Possible options" are indicated with terms such as: may, might, should, ought, could, perhaps, probably
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed
+ building.</em>
+</p>
+<h4>
+ Avoid wishful thinking
+</h4>
+<p>
+ Engineering is a real-world activity. No system or component is perfect. Wishful thinking means asking for the
+ impossible.
+</p>
+<p>
+ Wishful-thinking terms include: reliable, safe, handle all unexpected failures, please all users, run on all platforms,
+ never fail, upgradeable to all future situations
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The gearbox shall be 100% safe in normal operation.</em>
+</p>
+<p>
+ <em>The network shall handle all unexpected errors without crashing.</em>
+</p><!-- END:mainDescription,-Q72-dNdHnZ93aRXAB_d34A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/4plus1_2.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/4plus1_2.jpg
new file mode 100644
index 0000000..24cfc97
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/4plus1_2.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG
new file mode 100644
index 0000000..903bdea
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/PDMSample.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/PDMSample.JPG
new file mode 100644
index 0000000..5ad1683
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/PDMSample.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG
new file mode 100644
index 0000000..0270965
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG
new file mode 100644
index 0000000..6e965d1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/ac_intsy.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/ac_intsy.gif
new file mode 100644
index 0000000..b4e468f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/ac_intsy.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec1.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec1.gif
new file mode 100644
index 0000000..b076e0b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec2.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec2.gif
new file mode 100644
index 0000000..b8b7cd9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec3.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec3.gif
new file mode 100644
index 0000000..bfd2a4b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/co_dmec3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG
new file mode 100644
index 0000000..ae585d8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc1.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc1.gif
new file mode 100644
index 0000000..1c2beb3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc2.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc2.gif
new file mode 100644
index 0000000..717c2b2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc3.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc3.gif
new file mode 100644
index 0000000..06f3a9d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc4.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc4.gif
new file mode 100644
index 0000000..cb79539
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc4.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc5.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc5.gif
new file mode 100644
index 0000000..8559e50
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc5.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc6.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc6.gif
new file mode 100644
index 0000000..13a7b72
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/jdbc6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/login_vopc.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/login_vopc.jpg
new file mode 100644
index 0000000..0d46428
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/login_vopc.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg
new file mode 100644
index 0000000..dafa9b7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/md_ucre3.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/md_ucre3.gif
new file mode 100644
index 0000000..7f4cf27
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/md_ucre3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/ucrea1.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/ucrea1.gif
new file mode 100644
index 0000000..78190a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/ucrea1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/wil_overview.bmp b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/wil_overview.bmp
new file mode 100644
index 0000000..920106d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/resources/wil_overview.bmp
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/self_organize_work_assignments.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/self_organize_work_assignments.html
new file mode 100644
index 0000000..d066b2b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/self_organize_work_assignments.html
@@ -0,0 +1,126 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\self_organize_work_assignments.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: self_organize_work_assignments.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_rmBEkJjsEduad8I_c-ogIA CRC: 2367156984 -->Self Organize Work Assignments<!-- END:presentationName,_rmBEkJjsEduad8I_c-ogIA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_rmBEkJjsEduad8I_c-ogIA CRC: 3586622655 -->Agile software development teams organize the work that needs to be done together as a team.<!-- END:briefDescription,_rmBEkJjsEduad8I_c-ogIA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-e26WOHRbTVQrDssK5zijVA CRC: 2151374721 --><p>
+ A "self organizing team" has the authority to choose the work that it will perform and the responsibility to do that
+ work in the way that it chooses. Important aspects of a self organizing team are:
+</p>
+<ol>
+ <li>
+ The team selects its own work. At the beginning of an iteration the team collectively selects the <a class=""
+ href="./../../../openup_basic/guidances/termdefinitions/work_item,_jyVgcEvKEdunZcj9T5hrMQ.html"
+ guid="_jyVgcEvKEdunZcj9T5hrMQ">work item</a>s from the prioritized <a class=""
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>. Work selection is performed within given constraints, including
+ the priorities set by <a class="" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s, time (such as the length of the current <a class=""
+ href="./../../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html"
+ guid="_lam4ADkBEduxovfWMDsntw">Iteration</a>), the budget, and the skills of team members.
+ </li>
+ <li>
+ Individuals select their own work. Individuals are empowered to select their own work. Someone will choose to do
+ something because they are good at it and know that they can do the work effectively, because they want to gain
+ more experience at something and hope to improve their skill-set by working with someone with such experience, or
+ because they know that the work needs to be done and that it's their turn to do so. Although an individual fulfills
+ one or more roles on a project team that doesn't imply that the person is constrained to only doing specific types
+ of work.
+ </li>
+ <li>
+ The team determines how to perform the work. At the beginning of an iteration the team will hold an "all hands"
+ planning meeting where it determines the general strategy for doing the work and the tasks required to do so. More
+ detailed planning, if required, will be done on a just-in-time (JIT) basis by the individual(s) doing the work.
+ Note that the team is still constrained by your organization's standards, technical infrastructure, regulations,
+ and so on.
+ </li>
+ <li>
+ Everyone commits to the work. The team commits to accomplishing the work that it has agreed to do by the end of the
+ iteration. Individuals also commit to doing the work that they say they will do, although as the iteration
+ progresses various tasks may be renegotiated as required.
+ </li>
+ <li>
+ The team coordinates regularly. To ensure that the work is accomplished the team must coordinate its efforts
+ effectively. This is typically done through daily stand up meetings of the team and impromptu discussions between
+ individuals.
+ </li>
+</ol>
+<p>
+ This is a participatory approach to decision making where everyone has the opportunity to provide input and to listen
+ to the decision making process. The goal is to make decisions at the right place within the organizational structure,
+ empowering teams by giving them both the responsibility and the authority to get the job done. It improves motivation
+ amongst team members, and thereby their productivity, by giving them control over their work.
+</p>
+<h3>
+ Project Manager Responsibilities
+</h3>
+<p>
+ There is still work for the <a href="./../../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> on self organizing teams. The project manager must still:
+</p>
+<ol>
+ <li>
+ Provide leadership. Team culture and project vision must be nurtured and evolved throughout the project, and
+ direction must be provided to the team.
+ </li>
+ <li>
+ Mediate disagreements. The manager must be prepared to step in and make a decision when other team members are
+ unable to come to a decision.
+ </li>
+ <li>
+ Ensure that team members grow their skill-set. From time to time the manager may need to motivate individuals to
+ take on new tasks that are outside their comfort zone or to work with others to help those people gain new skills.
+ </li>
+ <li>
+ Ensure that the team respects their limits. Self organizing teams have the authority to make decisions within the
+ scope of their responsibility, but that doesn't mean that they get to rethink everything that they feel like. For
+ example, the development team must still conform to the technical infrastructure and to the business strategy of
+ your organization: they likely don't have the authority to change these things even though they may not fully agree
+ with them. When an issue falls outside their scope of responsibility the team must either accept it or collaborate
+ with the people with the appropriate authority.
+ </li>
+ <li>
+ Summarize the project plan. External stakeholders, such as senior management or business representatives not
+ actively involved with the team, will want to know the current status of the project and the team's current plans.
+ The project manager may be required to summarize and communicate this information to those people.
+ </li>
+</ol>
+<h3>
+ What This Isn't
+</h3>
+<p>
+ The concept of self organizing teams often sounds like anarchy or non-management to traditional IT professionals, but
+ nothing could be further from the truth. Although self organization relies on team members being responsible and mature
+ it is tempered by the guiding hand of a good project manager. It is also tempered by organizational standards,
+ infrastructure, and external regulations. "Self organizing" doesn't mean that you have complete freedom to do what you
+ want.
+</p>
+<p>
+ Self organization isn't necessarily a consensus-based approach either; sometimes individuals will disagree with a
+ decision but will choose to go along with the will of the team. Nevertheless, consensus isn't ruled out by this
+ approach but it certainly isn't required.
+</p><!-- END:mainDescription,-e26WOHRbTVQrDssK5zijVA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/staffing_project.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/staffing_project.html
new file mode 100644
index 0000000..e2589b9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/staffing_project.html
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\staffing_project.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: staffing_project.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Jq64EJjsEduad8I_c-ogIA CRC: 1011265541 -->Staffing a Project<!-- END:presentationName,_Jq64EJjsEduad8I_c-ogIA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Jq64EJjsEduad8I_c-ogIA CRC: 2223451649 -->Advice for how to staff a software development project.<!-- END:briefDescription,_Jq64EJjsEduad8I_c-ogIA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-HYO1lwAFOxlT7ncq8EjSng CRC: 1232202130 --><p>
+ Good software development teams are made up of a collection of people who collaborate effectively. How the project team
+ is staffed, by either adding or removing people, will greatly impact the team's productivity.
+</p>
+<p>
+ When staffing a development project, consider the following advice:
+</p>
+<ol>
+ <li>
+ Include people who fit into the existing team culture. Good teams don't just appear magically one day, but instead
+ are grown and nurtured over time. Invite people onto the team who will add value and furthermore who will not be
+ disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
+ team and they don't seem to be able to change.
+ </li>
+ <li>
+ People should want to be on the team. People are far more productive when they're working on a project that they
+ believe in and want to see succeed.
+ </li>
+ <li>
+ Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
+ specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas,
+ including both technical and domain areas. Generalizing specialists add value to the team because they have
+ specialized skills that you need while at the same time appreciate the full range of issues that a general
+ understanding of the software development process and the business domain offers.
+ </li>
+ <li>
+ Include stakeholders. Stakeholders, including business stakeholders such as end users and technical stakeholders
+ such as operations staff, can add significant value to your team. Instead of just interviewing them to gain
+ information from them, or asking them to review your work, why not include them as active participants on the team?
+ </li>
+ <li>
+ Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
+ particularly when they have specific skills and experience which existing team members do not have. It can often be
+ more effective to bring a specialist into the team for a short period of time to help with a specific task, such as
+ installation and setup of an application server, the development of an architectural spike, or simply taking part
+ in a review.
+ </li>
+ <li>
+ Give people opportunities to evolve their skills. At the beginning of a project the team may not have the full
+ range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
+ they are filling. This is a very common risk taken on by the majority of project teams for the simple reasons that
+ you often can't find the perfect combination of people and even if you could you still want to provide people with
+ opportunities to grow as professionals.
+ </li>
+ <li>
+ Remember Brook's Law. Adding people to a late project will only make it later [<a class=""
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BRO95</a>]. The corollary is that removing people from a late project may speed
+ things up [<a class=""
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
+ </li>
+</ol>
+<p>
+ Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
+ are available (although there's nothing stopping a specialist from becoming a generalizing specialist), perhaps there
+ aren't as many opportunities for people to try new things as they would like, or perhaps the stakeholders aren't
+ available to be active members of the team. The advice above is designed to lead to as high-performing a team as
+ possible, but even partial adherence to this guideline will improve the team.
+</p><!-- END:mainDescription,-HYO1lwAFOxlT7ncq8EjSng -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/submitting_change_requests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/submitting_change_requests.html
new file mode 100644
index 0000000..9b43c59
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/submitting_change_requests.html
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\submitting_change_requests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: submitting_change_requests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_fnZj0NVXEdqy9sbRhejO5Q CRC: 2791095145 -->Submitting Change Requests<!-- END:presentationName,_fnZj0NVXEdqy9sbRhejO5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_fnZj0NVXEdqy9sbRhejO5Q CRC: 4145168387 -->This guideline describes the type of information that is typically captured on a change request. This information is used to prioritize and scope the work required to implement the change and to monitor progress.<!-- END:briefDescription,_fnZj0NVXEdqy9sbRhejO5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-w7sImtXWkf4HDXdUWjRsUg CRC: 2157374754 --><h3>
+ Background
+</h3>
+<p>
+ Change requests typically have a lifecycle. They are raised, reviewed, accepted or rejected, implemented, verified
+ and closed. These states define the status of the change request at a particular point in time and represent critical
+ information for tracking progress. Other sets of states are possible.
+</p>
+<p>
+ During review of a change request, the goal is to assess the technical, cost, and schedule impact
+ of implementing the change. The technical impact assessment includes the determination of
+ which work products are affected and an estimate of the level of effort required to change and verify all
+ affected artifacts. This information becomes the basis of the cost and schedule impact assessments and, ultimately,
+ whether the change request will be accepted or rejected.
+</p>
+<p>
+ If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
+ manner as any other work item.
+</p>
+<p>
+ The current process uses the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
+ using the attributes defined for that artifact.
+</p>
+<h3>
+ Submitting Change Requests
+</h3>
+<p>
+ When submitting a change request provide as much information as possible to enable a speedy review and
+ disposition. As a minimum, all change requests should include the following information:
+</p>
+<ul>
+ <li>
+ <strong>ID</strong> - a unique identifier for the change request to simplify tracking. If you are using some
+ form of change tracking tool the tool will assign a unique ID.
+ </li>
+ <li>
+ <strong>Brief Description</strong> - a name that summarizes the change request
+ </li>
+ <li>
+ <strong>Detailed Description</strong> - A detailed description of the change request. For a defect, if you
+ can provide information that will help reproduce the defect please do so. For an enhancement request, provide
+ a rationale for the request.
+ </li>
+ <li>
+ <strong>Affected Item</strong> - the affected artifact and version.
+ </li>
+ <li>
+ <strong>Severity</strong> - how severe is this issue (show stopper, nice to have, etc.).
+ </li>
+ <li>
+ <strong>Priority</strong> - how important it is this request in your opinion.
+ </li>
+</ul>
+<p>
+ Depending upon the system you are using, the names of these data elements may differ. However, this information
+ is required, in one form or another, to permit a speedy review and disposition of the change request.
+</p>
+<br />
+<br />
+<br /><!-- END:mainDescription,-w7sImtXWkf4HDXdUWjRsUg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/supporting_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/supporting_requirements.html
new file mode 100644
index 0000000..75ba652
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/supporting_requirements.html
@@ -0,0 +1,443 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\supporting_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wr24gNcGEdqz_d2XWoVt6Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_wr24gNcGEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_wr24gNcGEdqz_d2XWoVt6Q CRC: 3465902275 -->This guideline explains how to develop and use the supporting requirements specification.<!-- END:briefDescription,_wr24gNcGEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-BdYFG4-dbPBGFzF9z6KGPA CRC: 456521507 --><p>
+ There is a finite set of requirements to consider when it comes to gathering system-wide requirements, qualities, or
+ constraints. Many of them are unfamiliar to stakeholders; therefore, they may find it difficult to answer questions
+ related to topics such as availability, performance, scalability, or localization. You can use this guideline and the
+ associated checklist <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.html"
+ guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a> when speaking to stakeholders to ensure that
+ all topics are discussed. Make sure that stakeholders understand the costs of their selections and do not end up
+ wanting everything that is on the list.
+</p>
+<h3>
+ Functional
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Auditing:</strong> Is there a need to track who used the system and when they used it? State
+ requirements for providing audit trails when running the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Authentication:</strong> Will access to the system be controlled? State requirements for
+ authentication.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Licensing:</strong> Will the system or parts of the system be licensed? If open-source software has
+ been used in the system, have all open-source agreements been respected? State requirements for acquiring,
+ installing, tracking, and monitoring licenses.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Printing:</strong> Will printing capability be required? State requirements for printing.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Reporting:</strong> Is reporting capability required? State requirements for reporting.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Scheduling:</strong> Will certain system actions need to be scheduled? State requirements for
+ scheduling capability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Security:</strong> Will elements of the system or system data need to be secure? State requirements to
+ protect access to certain resources or information.
+ </p>
+ </li>
+</ul>
+<h3>
+ Usability
+</h3>
+<p>
+ Usability requirements are critical to the success of any system. Unfortunately, usability requirements are often the
+ most poorly specified requirements. Consider this common requirement: The system shall be easy to use. This doesn't
+ help much, because it cannot be verified.
+</p>
+<p>
+ While capturing usability requirements, it is a good idea to identify issues and concerns first, and then refine these
+ into verifiable requirements later (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>). According to a traditional definition,
+ usability consists of five factors:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Ease of learning:</strong> A user with a specified level of experience must be able to learn how to use
+ the system in a specified amount of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Task efficiency:</strong> A user should be able to complete a specified task in a specified time (or
+ number of mouse clicks).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Ease of remembering:</strong> A user should be able to remember how to accomplish specified tasks after
+ not using the system for a specified period of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understandability:</strong> A user must be able to understand system prompts and messages and what the
+ system does.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Subjective satisfaction:</strong> A specified percentage of the user community must express
+ satisfaction with using the system.
+ </p>
+ </li>
+</ul>
+<p>
+ You may want to use the following method to identify and specify usability requirements:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ol>
+ <li>
+ Identify the key usability issues by looking at critical tasks, user profiles, system goals, and previous
+ usability problems.
+ </li>
+ <li>
+ Choose the appropriate style to express the requirements:
+ <ul>
+ <li>
+ <strong>Performance style:</strong> Specify how fast users can learn various tasks and how fast they
+ can perform the tasks after training.
+ </li>
+ <li>
+ <strong>Defect style:</strong> Rather than measuring task times, identify usability defects and
+ specifies how frequently they may occur.
+ </li>
+ <li>
+ <strong>Guideline style:</strong> Specify the general appearance and response time of the user
+ interface by reference to an accepted and well-defined standard
+ </li>
+ </ul>
+ </li>
+ <li>
+ Write the actual requirements, including performance criteria (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a> for more information).
+ </li>
+ </ol>
+</div>
+<h3>
+ Reliability
+</h3>
+<p>
+ Reliability includes the system's ability to continue running under stress and adverse conditions. In the case of an
+ application, reliability relates to the amount of time that the software is available and running as opposed to time
+ unavailable. Specify reliability acceptance levels, as well as how they will be measured and evaluated. Describe
+ reliability criteria in measurable terms. This is usually expressed as the allowable time between failures or the total
+ allowable failure rate. Other important reliability considerations include:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Accuracy:</strong> Specify requirements for the precision (resolution) and the accuracy (by some known
+ standard) that is required in any calculation performed or in system output.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Availability:</strong> Specify requirements for the percentage of time the system is available for use,
+ hours of use, maintenance access, and degraded-mode operations. Availability is typically specified in terms of
+ the Mean Time Between Failures (MTBF).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Recoverability:</strong> Specify requirements for recovery from failure. This is typically specified in
+ terms of the Mean Time to Repair (MTTR).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Frequency and severity of failures:</strong> Specify the maximum defect rate (typically expressed as
+ defects/KSLOC or defects/function-point) and severity of failures. Severity may be categorized in terms of
+ <strong>minor</strong>, <strong>significant</strong>, and <strong>critical</strong> defects. The requirements
+ must define each of these terms unambiguously. For example, a <strong>critical</strong> defect could be defined
+ as one that results in loss of data or complete inability to use certain functionality of the system.
+ </p>
+ </li>
+</ul>
+<h3>
+ Performance
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Response times:</strong> Specify the amount of time available for the system to complete specified
+ tasks and transactions (average, maximum). Use units of measurement. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ Any interface between a user and the system shall have a maximum response time of 2 seconds.
+ </li>
+ <li>
+ The product shall download the new status parameters within 5 minutes of a change.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Throughput:</strong> Specify the capacity of the system to support a given flow of information (for
+ example, transactions per second).<br />
+ </li>
+ <li>
+ <strong>Capacity:</strong> Specify on the volumes that the product must be able to deal with and the numbers of
+ data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
+ unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
+ (memory, disk, . . . ) or degradation modes (what is the acceptable mode of operation when the system has been
+ degraded in some manner) <em>Examples:</em>
+ <ul>
+ <li>
+ The product shall cater for 300 simultaneous users within the period from 9:00 AM to 11 AM.
+ </li>
+ <li>
+ Maximum loading at other periods will be 150.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Start-up:</strong> The time for the system to start up.<br />
+ </li>
+ <li>
+ <strong>Shut-down:</strong> The time for the system to shut down.
+ </li>
+</ul>
+<h3>
+ Supportability
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Adaptability:</strong> Are there any special requirements regarding adaptation of the software
+ (including upgrading)? List requirements for the ease with which the system is adapted to new environments.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Compatibility:</strong> Are there any requirements regarding this system and its compatibility with
+ previous versions of this system or legacy systems that provide the same capability?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Configurability:</strong> Will the product be configured after it has been deployed? In what way will
+ the system be configured?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Installation:</strong> State any special requirements regarding system installation
+ </p>
+ </li>
+ <li>
+ <strong>Level of Support:</strong> What is the level of support that the product requires? This is often done using
+ a Help desk. If there are to be people who provide support for the product, is that support considered part of what
+ you are providing to the customer? Are there any requirements for that support? You might also build support into
+ the product itself, in which case this is the place to write those requirements. Consider the level of support that
+ you anticipate providing and what forms it might take.<br />
+ </li>
+ <li>
+ <strong>Maintainability:</strong> Are there any special requirements regarding system maintenance? What are the
+ requirements for the intended release cycle for the product and the form that the release will take? Quantify the
+ time necessary to make specified changes to the product. There may also be special requirements for
+ maintainability, such as a requirement that the product must be able to be maintained by its end-users or
+ developers who are not your development team. This has an effect on the way that the product is developed, and
+ there may be additional requirements for documentation or training. Describe the type of maintenance and the amount
+ of effort required. <em>Examples:</em><br />
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ A new weather station must be able to be added to the system overnight.
+ </li>
+ <li>
+ The maintenance releases will be offered to end-users once a year.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Scalability:</strong> What volumes of users and data will the system support? This specifies the expected
+ increases in size that the product must be able to handle As businesses grow (or are expected to grow), the
+ software products must increase their capacities to cope with the new volumes. This may be expressed as a profile
+ over time.<br />
+ </li>
+ <li>
+ <strong>Testability:</strong> Are there any special requirements regarding the testability of the system?
+ </li>
+</ul>
+<h3>
+ Constraints (+)
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Design constraints:</strong> Are there any design decisions that have been mandated that the product
+ must adhered to?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Third-party components:</strong> Specify any mandated legacy, COTS, or open-source components to be
+ used with the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation languages:</strong> Specify requirements on the implementation languages to be used
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Platform support:</strong> Specify requirements on the platforms that the system will support
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Resource limits:</strong> Specify requirements on the use of system resources, such as memory and hard
+ disk space
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Physical Constraints:</strong> Specify requirements on the shape, size, and weight of the resulting
+ hardware to house the system
+ </p>
+ </li>
+</ul>
+<h3>
+ Interface Requirements (+)
+</h3>
+<p>
+ Describe both the user interface and interfaces with external systems.
+</p>
+<h4>
+ User interface
+</h4>
+<p>
+ Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
+ section is to state the requirements, but not to describe the user interface itself, because interface design may
+ overlap the requirements-gathering process. This is particularly true if you are using prototyping as part of your
+ requirements gathering process. As you develop prototypes, it is important to capture the requirements that relate to
+ the look and feel of the user interface. In other words, be sure that you understand your client’s intentions for the
+ product’s look and feel. Record these as requirements, rather than merely using a prototype for approval.
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Look and feel:</strong> A description of the aesthetic appearance and layout of the interface. Your
+ client may have given you particular demands, such as style, colors, degree of interaction, and so on. This
+ section captures the requirements for the interface, rather than the design for the interface. The motivation
+ is to capture the expectations, the constraints, and the client’s demands for the interface before designing
+ it. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ The product shall have the same layout as the district maps from the engineering department.
+ </li>
+ <li>
+ The product shall use the company color.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Layout and navigation requirements:</strong> Specify requirements on major screen areas and how they should
+ be grouped together.<br />
+ </li>
+ <li>
+ <strong>Consistency:</strong> Consistency in the user interface enables users to predict what will happen. This
+ section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
+ the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
+ and shapes, placements for entering / presenting data, terminology<br />
+ </li>
+ <li>
+ <strong>User personalization and customization requirements:</strong> Requirements on content that should
+ automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
+ content displayed or to personalize displayed content.
+ </li>
+</ul>
+<h4>
+ Interfaces to external systems or devices
+</h4>
+<ul>
+ <li>
+ <p>
+ <strong>Software interfaces:</strong> Are there any external systems with which this system must interface? Are
+ there any constraints on the nature of the interface between this system and any external system, such as the
+ format of data passed between these systems? Do they use any particular protocol? Describe software interfaces
+ with other components. These may be purchased components, components reused from another application, or
+ components being developed for subsystems outside of the scope of the system under consideration, but with
+ which this it must interact. For each system, consider both provided and required interfaces.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Hardware interfaces:</strong> Define any hardware interfaces that are to be supported by the software,
+ including logical structure, physical addresses, expected behavior, and so on.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Communications interfaces:</strong> Describe any communications interfaces to other systems or devices,
+ such as local area networks (LANs), remote serial devices, and so on.
+ </p>
+ </li>
+</ul>
+<h3>
+ Business Rules (+)
+</h3>
+<p>
+ Besides technical requirements, also consider the particular business domain in which the system needs to fit.
+</p>
+<p>
+ Business rules or policies that the system must conform to may constrain system functionality. Business rules are
+ referred to by system use cases and can be in the form of decision tables, computation rules, decision trees,
+ algorithms, and so forth. Describing the rules in the flows of the use cases usually clutters the use-case
+ specifications. Therefore, they are normally captured in separate artifacts or as annexes related to the use-case
+ specifications. In many cases, a business rule applies to more then one use case. Shared business rules should be
+ stored in a single repository, such as a supporting requirements document.
+</p><!-- END:mainDescription,-BdYFG4-dbPBGFzF9z6KGPA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/test_ideas.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/test_ideas.html
new file mode 100644
index 0000000..b1ffb74
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/test_ideas.html
@@ -0,0 +1,170 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\test_ideas.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_ideas.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0jzlsMlgEdmt3adZL5Dmdw CRC: 1652868117 -->Test Ideas<!-- END:presentationName,_0jzlsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0jzlsMlgEdmt3adZL5Dmdw CRC: 2113250201 -->This guideline identifies common faults and mistakes done when developing software. It shows how to create test ideas from method calls, and from boolean and relational expressions.<!-- END:briefDescription,_0jzlsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_y3rxsMM3EdmSIPI87WLu3g CRC: 2458895332 --><h3>
+ Introduction
+</h3>
+<p>
+ Test ideas are used to generate tests. Test ideas can come from many different sources. In general, they can
+ be derived in different ways depending on the given development domain, the kind of application being developed, and
+ the sophistication of the testers. Although test ideas are derived in many different ways, there are some useful
+ categories for generating them. This guideline will describe some of these categories as well as some general
+ heuristics for creating good test ideas.
+</p>
+<h4>
+ Test Ideas and Functions
+</h4>
+<p>
+ Below are some test ideas to calculate the square root:
+</p>
+<ol>
+ <li>
+ A number that's barely less than zero as input
+ </li>
+ <li>
+ Zero as the input
+ </li>
+ <li>
+ Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
+ </li>
+ <li>
+ Print to a LaserJet IIIp
+ </li>
+ <li>
+ Test with database full
+ </li>
+</ol>
+<p>
+ The first 3 test ideas validate input while the last 2 address environmental issues. Even though these
+ statements are very incomplete they ensure that an idea is not forgotten.
+</p>
+<h4>
+ Test Ideas and Boundaries
+</h4>
+<p>
+ Test ideas are often based on fault models. Consider boundaries. It's safe to assume the square root function can
+ be implemented something like this:<br />
+ double sqrt(double x) {<br />
+ if (x < 0)<br />
+ // signal error<br />
+ ...<br />
+ It's also plausible that the < will be incorrectly typed as <=. People often make that kind of mistake, so it's
+ worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x<=0)
+ and the correct expression (x<0) will take the same branch of the if statement. Similarly, giving X the value -5
+ cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea.
+</p>
+<h4>
+ Test Idea and Methods
+</h4>
+<p>
+ Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
+ obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is
+ found.<br />
+ int Collection.find(String string, Boolean ignoreCase);
+</p>
+<p>
+ Here are some test ideas for this method, each of which could be implemented as a test.
+</p>
+<ol>
+ <li>
+ Match found in the first position
+ </li>
+ <li>
+ Match found in the last position
+ </li>
+ <li>
+ No match found
+ </li>
+ <li>
+ Two or more matches found in the collection
+ </li>
+ <li>
+ Case is ignored; match found, but it wouldn't match if case was obeyed
+ </li>
+ <li>
+ Case is obeyed; an exact match is found
+ </li>
+ <li>
+ Case is obeyed; a string that would have matched if case were ignored is skipped
+ </li>
+</ol>
+<p>
+ However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas
+ 2, 6, and 7:
+</p>
+<p>
+ <strong>Setup:</strong> Collection initialized to ["dawn", "Dawn"]<br />
+ <strong>Invocation:</strong> Collection.find("Dawn", false)<br />
+ <strong>Expected result:</strong> Return value is 1 (it would be 0 if "dawn" were not skipped)
+</p>
+<h4>
+ Test Idea Simplicity and Complexity
+</h4>
+<p>
+ Making test ideas nonspecific makes them easier to combine.<br />
+ Creating many several small tests that satisfy a few test ideas makes it simpler to:
+</p>
+<ul>
+ <li>
+ "Copy and Tweak" the tests to meet other test idea
+ </li>
+ <li>
+ Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if
+ the test covers 7 test ideas you will spend more time debugging the issue.
+ </li>
+</ul>
+<p>
+ If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote
+ the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the
+ chance the test will satisfy a test idea that you didn't know you needed.
+</p>
+<h4>
+ Complex Tests
+</h4>
+<p>
+ Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not
+ creating complex tests.
+</p>
+<ul>
+ <li>
+ Complex test are more difficult to debug because they usually cover multiple test ideas
+ </li>
+ <li>
+ Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.
+ </li>
+ <li>
+ Complex tests are more difficult to create.
+ </li>
+</ul>
+<p>
+ Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each
+ satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying
+ four.<br />
+ In practice, find a reasonable balance between complexity and simplicity.<br />
+</p><!-- END:mainDescription,_y3rxsMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/test_suite.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/test_suite.html
new file mode 100644
index 0000000..7100817
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/test_suite.html
@@ -0,0 +1,189 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\test_suite.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_suite.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0aDz0MlgEdmt3adZL5Dmdw CRC: 1779093997 -->Test Suite<!-- END:presentationName,_0aDz0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0aDz0MlgEdmt3adZL5Dmdw CRC: 1897955337 -->This guideline discusses how to maintain automated test suites.<!-- END:briefDescription,_0aDz0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_s60KoMM3EdmSIPI87WLu3g CRC: 1212509648 --><h3>
+ Introduction
+</h3>
+<p>
+ The test suite provides a means of managing the complexity of the test implementation. Many system test efforts fail
+ because the team gets lost in the minutia of all of the detailed tests, and subsequently loses control of the test
+ effort. Similar to UML packages, test suites provide a hierarchy of encapsulating containers to help manage the test
+ implementation. They provide a means of managing the strategic aspects of the test effort by collecting tests together
+ in related groups that can be planned, managed, and assessed in a meaningful way.
+</p>
+<p>
+ The test suite represents a container for organizing arbitrary collections of related test scripts. This may be
+ realized (implemented) as one or more automated regression test suites, but the test suite can also be a work plan for
+ the implementation of a group of related manual test scripts. Note also that test suites can be nested hierarchically,
+ therefore one test suite may be enclosed within another.
+</p>
+<p>
+ Sometimes these groups of tests will relate directly to a subsystem or other system design element, but other times
+ they'll relate directly to things such as quality dimensions, core "mission critical" functions, requirements
+ compliance, standards adherence, and many others concerns that are organized based on requirements and therefore cut
+ across the internal system elements.
+</p>
+<p>
+ Consider creating test suites that arrange the available test scripts, in addition to other test suites, in many
+ different combinations: the more variations you have, the more you'll increase coverage and the potential for finding
+ errors. Give thought to a variety of test suites that will cover the breadth and depth of the target test items.
+ Remember the corresponding implication that a single test script (or test suite) may appear in many different test
+ suites.
+</p>
+<p>
+ Some test automation tools provide the ability to automatically generate or assemble test suites. There are also
+ implementation techniques that enable automated test suites to dynamically select all or part of their component test
+ scripts for each test cycle run.
+</p>
+<p>
+ Test suites can help you maintain your test assets and impose a level of organization that facilitates the entire
+ testing effort. Like physical objects, tests can break. It's not that they wear down, it's that something changed
+ in their environment. Perhaps they've been ported to a new operating system. Or, more likely, the code they exercise
+ has changed in a way that correctly causes the test to fail. Suppose you're working on version 2.0 of an e-banking
+ application. In version 1.0, this method was used to log in:
+</p>
+<p class="codeSample">
+ public boolean login (String username);
+</p>
+<p>
+ In version 2.0, the marketing department has realized that password protection might be a good idea. So the method is
+ changed to this:
+</p>
+<p class="codeSample">
+ public boolean login (String username, String password);
+</p>
+<p>
+ Any test that uses the first form of the login will fail. It won't even compile. In this example you could find that,
+ not many useful tests can be written that don't use login. You might be faced with hundreds or thousands of failing
+ tests.
+</p>
+<p>
+ These tests can be fixed by using a global search-and-replace tool that finds every instance of login(something) and
+ replaces it with login(something, "dummy password"). Then arrange for all the testing accounts to use that password,
+ and you're on your way.
+</p>
+<p>
+ Then, when marketing decides that passwords should not be allowed to contain spaces, you get to do it all over again.
+</p>
+<p>
+ This kind of thing is a wasteful burden, especially when, as is often the case, the test changes aren't so easily made.
+ There is a better way.
+</p>
+<p>
+ Suppose that the test scripts originally did not call the product's login method. Rather, they called a library method
+ that does whatever it takes to get the test logged in and ready to proceed. Initially, that method might look like
+ this:
+</p>
+<p class="codeSample">
+ public boolean testLogin (String username) {<br />
+ return product.login(username);<br />
+ }
+</p>
+<p>
+ When the version 2.0 change happens, the utility library is changed to match:
+</p>
+<p class="codeSample">
+ public Boolean testLogin (String username) {<br />
+ return product.login(username, "dummy password");<br />
+ }
+</p>
+<p>
+ Instead of a changing a thousand tests, you change one method.
+</p>
+<p>
+ Ideally, all the needed library methods would be available at the beginning of the testing effort. In practice, they
+ can't all be anticipated-you might not realize you need a testLogin utility method until the first time the product
+ login changes. So test utility methods are often "factored out" of existing tests as needed. It is very important that
+ you perform this ongoing test repair, even under schedule pressure. If you do not, you will waste much time dealing
+ with an ugly and un-maintainable test suite. You might well find yourself throwing it away, or being unable to write
+ the needed numbers of new tests because all your available testing time is spent maintaining old ones.
+</p>
+<p>
+ Note: the tests of the product's login method will still call it directly. If its behavior changes, some or all of
+ those tests will need to be updated. (If none of the login tests fail when its behavior changes, they're probably not
+ very good at detecting defects.)
+</p>
+<h3>
+ Abstraction helps manage complexity
+</h3>
+<p>
+ The previous example showed how tests can abstract away from the concrete application. Most likely you can do
+ considerably more abstraction. You might find that a number of tests begin with a common sequence of method calls: they
+ log in, set up some state, and navigate to the part of the application you're testing. Only then does each test do
+ something different. All this setup could-and should-be contained in a single method with an evocative name such as
+ readyAccountForWireTransfer. By doing that, you're saving considerable time when new tests of a particular type are
+ written, and you're also making the intent of each test much more understandable.
+</p>
+<p>
+ Understandable tests are important. A common problem with old test suites is that no one knows what the tests are doing
+ or why. When they break, the tendency is to fix them in the simplest possible way. That often results in tests that are
+ weaker at finding defects. They no longer test what they were originally intended to test.
+</p>
+<h3>
+ Throwing away tests
+</h3>
+<p>
+ Even with utility libraries, a test might periodically be broken by behavior changes that have nothing to do with what
+ it checks. Fixing the test doesn't stand much of a chance of finding a defect due to the change; it's something you do
+ to preserve the chance of the test finding some other defect someday. But the cost of such a series of fixes might
+ exceed the value of the tests hypothetically finding a defect. It might be better to simply throw the test away and
+ devote the effort to creating new tests with greater value.
+</p>
+<p>
+ Most people resist the notion of throwing away a test, at least until they're so overwhelmed by the maintenance burden
+ that they throw all the tests away. It is better to make the decision carefully and continuously, test by test, asking:
+</p>
+<ul>
+ <li>
+ How much work will it be to fix this test well, perhaps adding to the utility library?
+ </li>
+ <li>
+ How else might the time be used?
+ </li>
+ <li>
+ How likely is it that the test will find serious defects in the future? What's been the track record of it and
+ related tests?
+ </li>
+ <li>
+ How long will it be before the test breaks again?
+ </li>
+</ul>
+<p>
+ The answers to these questions will be rough estimates or even guesses. But asking them will yield better results than
+ simply having a policy of fixing all tests.
+</p>
+<p>
+ Another reason to throw away tests is that they are now redundant. For example, early in development, there might be a
+ multitude of simple tests of basic parse-tree construction methods (the LessOp constructor and the like). Later, during
+ the writing of the parser, there will be a number of parser tests. Since the parser uses the construction methods, the
+ parser tests will also indirectly test them. As code changes break the construction tests, it's reasonable to discard
+ some of them as being redundant. Of course, any new or changed construction behavior will need new tests. They might be
+ implemented directly (if they're hard to test thoroughly through the parser) or indirectly (if tests through the parser
+ are adequate and more maintainable).
+</p><!-- END:mainDescription,_s60KoMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/types_of_developer_tests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/types_of_developer_tests.html
new file mode 100644
index 0000000..94478ae
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/types_of_developer_tests.html
@@ -0,0 +1,279 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\types_of_developer_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: types_of_developer_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eRutgC5QEduVhuZHT5jKZQ CRC: 104200557 -->Types of Developer Tests<!-- END:presentationName,_eRutgC5QEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_eRutgC5QEduVhuZHT5jKZQ CRC: 1082763834 -->This guideline describes various types of developer tests.<!-- END:briefDescription,_eRutgC5QEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-VGT8iHGtQSiOUGitq1qmow CRC: 1383036923 --><p>
+ This guideline describes a number of types of tests. To perform these types of testing you need to define, and then
+ run, a series of tests against the source code. A developer test is a single test that needs to be performed.
+</p>
+<p>
+ It is valuable to augment automated tests with human readable test scripts in order to implement developer test
+ cases, scripts that include the information discussed below. A test script is the actual steps, sometimes either
+ written procedures to follow or the source code of a test. Developer test scripts are run against testing targets:
+ either one unit of source code, a more complex portion of your system (such as a component), or the entire system
+ itself to test some developer issue such as integration.
+</p>
+<h3>
+ Regression Testing
+</h3>
+<p>
+ Regression testing is the act of ensuring that changes to the code have not adversely affected existing
+ functionality. It is important to recognize that incremental development makes regression testing critical. Whenever
+ you release an application, you must ensure its previous functionality still works, and because you release
+ applications more often when taking the incremental approach, this means regression testing becomes that much more
+ important. Regression testing is the first thing you should be thinking about when testing for the following reasons:
+</p>
+<ol>
+ <li>
+ You want to be able to modify code and know that you can rerun your tests to see if you broke anything.
+ </li>
+ <li>
+ Existing users get very angry when things that previously worked don’t work anymore.
+ </li>
+</ol>
+<p>
+ Regression testing is fairly straightforward conceptually – you just need to run all of the previous test cases
+ against the new version of the code. Regression testing tools help immensely because they are designed with
+ regression testing in mind. However, there are potential challenges to regression testing:
+</p>
+<ul>
+ <li>
+ When you change your production, either to enhance it or to refactor it, you will need to rework existing test
+ cases coupled to that code.
+ </li>
+ <li>
+ If your updates affect only a component of the system, then potentially you only need to run the test cases that
+ affect this single component. Although this approach is a little risky because your changes may have had a greater
+ impact than you suspect, it does help to reduce both the time and cost of regression testing.
+ </li>
+ <li>
+ The more non-code artifacts that you decide to keep, the greater the effort to regression test your work and
+ therefore the greater the risk to your project because you are more likely to skimp on your testing efforts.
+ </li>
+</ul>
+<p>
+ Regression testing is critical to success as an agile developer. Many software developers use the xUnit family of open
+ source tools, such as <a href="http://www.junit.org/" target="_blank">JUnit</a> and <a href="http://www.vbunit.org/"
+ target="_blank">VBUnit</a>, to test their code. The advantage of these tools is that they implement a testing framework
+ with which you can regression test all of your source code. Commercial testing tools are also viable options.
+</p>
+<h3>
+ Traditional Code Testing Techniques
+</h3>
+<p>
+ Although object and procedural technologies are different, several important testing concepts from the procedural world
+ are valid regardless of the underlying technology. These traditional testing techniques are:
+</p>
+<ul>
+ <li>
+ Black-box testing
+ </li>
+ <li>
+ Clear-box testing
+ </li>
+ <li>
+ Boundary-value testing
+ </li>
+ <li>
+ Coverage/Path testing
+ </li>
+</ul>
+<h4>
+ Black-Box Testing
+</h4>
+<p>
+ Black-box testing, also called interface testing, is a technique in which you create test cases based only on the
+ expected functionality of a method, class, or application without any knowledge of its internal workings. One way to
+ define black-box testing is that given input A you should obtain expected results B.
+</p>
+<p>
+ The goal of black-box testing is to ensure the system can do what it should be able to do, but not how it does it. For
+ example, if you invoke differenceInDays(June 30 2006, July 3 2006) the expected result should be three. The creation of
+ black-box tests is often driven by the requirements for the system. The basic idea is to look at the user
+ requirement and ask what needs to be done to show that the user requirement is met.
+</p>
+<p>
+ The primary advantage of black-box testing is that it enables you to prove that your application fulfills the
+ requirements defined for it. The primary disadvantage is that it does not show that the internals
+ of the system work (hence the need for clear-box testing).
+</p>
+<h4>
+ Clear-Box Testing
+</h4>
+<p>
+ Clear-box testing, also called white-box testing, is based on the idea that the program code can drive the
+ development of test cases. The basic concept is you look at the code, and then create test cases that exercise it.
+ For example, assume you have access to the source code for differenceInDays(). When you look at it, you see an IF
+ statement determines whether the two dates are in the same year. If they are in the same year then a simple
+ strategy based on Julian dates is used; if not then a more complex strategy is used. This indicates that you need
+ at least one test that uses dates from the same year and one from different years. By looking at the code, you are able
+ to determine new test cases to exercise the different logic paths within it.
+</p>
+<p>
+ The primary advantage of this concept is that it motivates you to create tests that exercise specific lines of
+ code. The disadvantages are that it does not ensure that your code fulfils the actual requirements (hence the
+ need for black-box testing) and that your testing code becomes highly coupled to your application code.
+</p>
+<h4>
+ Boundary-Value Testing
+</h4>
+<p>
+ This is based on the knowledge that you need to test your code to ensure it can handle unusual and extreme situations.
+ For example, boundary-value test cases differenceInDays() would include passing it the same date, two wildly different
+ dates, one date on the last day of the year and the second on the first day of the following year, and one date on
+ February 29th of a leap year. The basic idea is you want to look for limits defined either by your business rules or by
+ common sense, and then create test cases to test attribute values in and around those values.
+</p>
+<p>
+ The primary advantage of boundary value testing is that it motivates you to confirm that your program code is able to
+ handle “unusual” or “extreme” cases.
+</p>
+<h4>
+ Coverage and Path Testing
+</h4>
+<p>
+ Two critical “traditional” concepts are coverage and path testing. Coverage testing is a technique in which you create
+ a series of test cases designed to test all the code paths in your code. In many ways, coverage testing is simply a
+ collection of clear-box test cases that together exercise every line of code in your application at least once. Path
+ testing is a superset of coverage testing that ensures not only have all lines of code been tested, but all paths of
+ logic have also been tested. The main difference occurs when you have a method with more than one set of case
+ statements or nested IF statements: to determine the number of test cases with coverage testing you would count the
+ maximum number of paths between the sets of case/nested IF statements and, with path testing, you would multiply the
+ number of logic paths.
+</p>
+<h4>
+ Unit and Integration Testing
+</h4>
+<p>
+ Unit testing is the testing of an item, such as an operation, in isolation. For example, the tests defined so far for
+ differenceInDays() are all unit tests. Integration testing, on the other hand, is the testing of a collection of items
+ to validate that they work together. In the case of the data library/class, do the various functions work together?
+ Perhaps the differenceInDays() function has a side effect that causes the dayOfWeek() function to fail if
+ differenceInDays() is called first. Integration testing looks for problems like this.
+</p>
+<h3>
+ Object-Oriented Testing Techniques
+</h3>
+<p>
+ When testing systems built using object technology it is important to understand that your source code is composed of
+ several constructs, including methods (operations), classes, and inheritance. Therefore you need testing techniques
+ that reflect the fact that you have these constructs. These techniques are:
+</p>
+<ul>
+ <li>
+ Method testing
+ </li>
+ <li>
+ Class testing
+ </li>
+ <li>
+ Class-integration testing
+ </li>
+ <li>
+ Inheritance-regression testing
+ </li>
+</ul>
+<h4>
+ Method Testing
+</h4>
+<p>
+ Method testing is the act of ensuring that your methods (operations) perform as defined. In procedural testing this
+ would have been called function/procedure testing. Issues to address via method testing include:
+</p>
+<ul>
+ <li>
+ Ensure that your getter/setter methods work as intended
+ </li>
+ <li>
+ Ensure that each method returns the proper values, including error messages and exceptions
+ </li>
+ <li>
+ Validate the parameters being passed to a method
+ </li>
+ <li>
+ Ensure that a method does what it should
+ </li>
+</ul>
+<p>
+ The advantage of method testing is that it ensures that methods work well in isolation but it does not help to find
+ unintended side effects.
+</p>
+<h4>
+ Class Testing
+</h4>
+<p>
+ The main purpose of class testing is to test classes in isolation, and it is effectively the combination of traditional
+ unit testing and integration testing. It is unit testing because you are testing the class and its instances as single
+ units in isolation, but it is also integration testing because you need to verify the methods and attributes of the
+ class work together. The one assumption you need to make while writing “class tests” is that all other classes in the
+ system work. Issues to address via class testing include:
+</p>
+<ul>
+ <li>
+ Validate that the attributes of an object are initialized properly
+ </li>
+ <li>
+ Validate the invariants of the class
+ </li>
+</ul>
+<p>
+ The primary advantages of class testing are that it validates that the operations and properties of a class work
+ together and that the class works in isolation. However, it does not guarantee that a class works well with the rest of
+ your system.
+</p>
+<h4>
+ Class-integration Testing
+</h4>
+<p>
+ Also known as component testing, this technique addresses the issue of whether the classes in your system, or a
+ component of your system, work together properly. The relationships between classes can be used to drive the
+ development of class integration test cases. Issues to address via class-integration testing include:
+</p>
+<ul>
+ <li>
+ Validate that objects do what other objects expect of them
+ </li>
+ <li>
+ Validate that return values are acted appropriately
+ </li>
+ <li>
+ Validate that exceptions/errors are processed appropriately
+ </li>
+</ul>
+<p>
+ The technique helps to validate that the various classes within a component, or a system, work together. However, it
+ can be difficult to define and develop the test cases to fully perform this level of testing.
+</p>
+<h4>
+ Inheritance-regression Testing
+</h4>
+This is the act of running of test cases defined for the superclasses on the instances of a subclass because errors have
+not been introduced by that new subclass. New methods are added and existing methods may be redefined by subclasses,
+methods which access and potentially change the value of the attributes defined in the superclass. It is possible that a
+subclass may change the value of the attributes in a way that was never intended in the superclass, or at least was never
+expected. The point is that you need to invoke the test suite of the superclass(es) when testing a subclass. <br /><!-- END:mainDescription,-VGT8iHGtQSiOUGitq1qmow -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/uc_model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/uc_model.html
new file mode 100644
index 0000000..356dc88
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/uc_model.html
@@ -0,0 +1,317 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\uc_model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uc_model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0VAUsMlgEdmt3adZL5Dmdw CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_0VAUsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0VAUsMlgEdmt3adZL5Dmdw CRC: 3048609528 -->This guideline describes how to develop and evolve the use-case model to capture the functional requirements for the system under development.<!-- END:briefDescription,_0VAUsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_AGvpcMM3EdmSIPI87WLu3g CRC: 559327090 --><h3>
+ Introduction
+</h3>
+<p>
+ The key to successful iterative development is ensuring that the development team maximizes stakeholder value and
+ minimizes risk early in the lifecycle, while minimizing re-work later. This imposes some constraints on how we
+ develop the use-case model.
+</p>
+<p>
+ At one extreme is the classical waterfall approach, which attempts to detail all of the requirements prior to
+ design and implementation. This approach delays delivery of stakeholder value and risk reduction unnecessarily.
+</p>
+<p>
+ At the other extreme is beginning development prior to understanding what the system must do. This approach
+ results in significant, and costly, re-work later in the lifecycle.
+</p>
+<p>
+ A better approach is to detail only those requirements which will be the focus of development in the next iteration (or
+ two). Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract
+ understanding of the "big-picture".
+</p>
+<p>
+ The following discussion will outline the approach used to evolve the use-case model to achieve these goals.
+</p>
+<h3>
+ <a id="How the Use-Case Model Evolves" name="How the Use-Case Model Evolves">How the Use-Case Model Evolves</a>
+</h3>
+<p>
+ The recommended approach to evolving the use-case model takes a "breadth before depth" approach. In this
+ approach, one identifies the actors and use cases and outlines them quickly. Based on this knowledge, one can
+ then perform an initial assessment of risk and priorities and thus focus the effort of detailing the use
+ cases on the right areas.
+</p>
+<h4>
+ Inception
+</h4>
+<p>
+ The purpose of inception is to understand the scope of the system. We need to understand the main purpose of the
+ system, what is within the scope of the system, and what is external to the system. We should strive to list all
+ the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at
+ this time. Strive to identify by name ~80% of the primary actors and use cases and provide a brief
+ description (one - three sentences) for each.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Identify Stakeholders
+ </h5>
+ <p>
+ Begin by listing all the external stakeholders for the system. These individuals will be the source of the
+ requirements.
+ </p>
+ <h5>
+ Identify Actors
+ </h5>
+ <p>
+ Name and describe the primary actors. See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>.
+ </p>
+ <h5>
+ Identify Use Cases
+ </h5>
+ <p>
+ For each actor, ask "what does this actor want to accomplish with the system"? This will reveal the primary
+ use cases for the system. Name and describe each of these as you discover them.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the use case model to capture the actor and use case names and brief description. Capture the
+ relationship between the actors and use cases.
+ </p>
+ <h5>
+ Outline the Basic Flows
+ </h5>
+ <p>
+ For those use cases that are considered high priority by the stakeholders, or high risk by the development team,
+ capture a step-by-step description of the Basic Flow. Don't worry about structuring the flow at this
+ point. Focus on capturing the dialogue between the actor and the system and the key requirements for the
+ system.
+ </p>
+ <h5>
+ Identify Alternate Flows
+ </h5>
+ <p>
+ As you work through the Basic Flows, ask: "What can go wrong?"; "What options are available at this point?";
+ etc. These types of questions will reveal alternate flows. Capture these, giving each a name and brief
+ description. Fight the urge to detail these alternate flows at this time.
+ </p>
+ <h5>
+ Refactor the Use Case Model
+ </h5>
+ <p>
+ Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into
+ <<include>> use cases. Refactor the Use Case model accordingly.
+ </p>
+ <h5>
+ Prioritize Use Cases
+ </h5>
+ <p>
+ Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use
+ cases. This will be the primary input to iteration planning.
+ </p>
+</blockquote>
+<h4>
+ Elaboration
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of elaboration is to demonstrate the feasibilty of the solution prior to committing additional
+ resources. To be successful, one should demonstrate that stakeholder value can be delivered and that the risk
+ of continuing is acceptable. We should strive to detail and implement ~20% of the scenarios. These
+ scenarios should be selected to achieve good coverage of the architecture (for example, a vertical slice through
+ the architecture, touching as many components and interfaces as possible, is preferred to elaborating the GUI
+ only).
+ </p>
+ <h5>
+ Detail Basic Flow
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now. See <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flow
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work. Depending upon the
+ complexity of the system, you may want to introduce packages to group the use cases in a logical manner to simplify
+ communications, iteration planning, and parallel development.
+ </p>
+</blockquote>
+<h4>
+ Construction
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of construction is to incrementally deliver functionality (and value). Working from the iteration
+ plan, continue detailing the remaining requirements. Shoot for completion of ~90 - ~95% of use cases by the
+ end of construction.
+ </p>
+ <h5>
+ Detail Basic Flows
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now. See <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flows
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.
+ </p>
+</blockquote>
+<h4>
+ Transition
+</h4>
+<p>
+ The purpose of transition is to make the system operational in its intended environment. Some requirements will
+ still be uncovered at this point, but if we have done things right they should not stress the design. The
+ remaining ~5% to ~10% of use cases should be detailed and implemented in this phase.
+</p>
+<h3>
+ <a id="Avoiding Functional Decomposition" name="Avoiding Functional Decomposition">Avoiding Functional
+ Decomposition</a>
+</h3>
+<p>
+ A common pitfall for those new to use-case models is to perform a functional decomposition of the system. This
+ results in many small "use cases", that on their own do not deliver the "observable result of value" to the
+ actor. To avoid this, watch for the following symptoms:
+</p>
+<ul>
+ <li>
+ <strong>Small</strong> use cases, meaning that the description of the flow of events is only one or a few
+ sentences.
+ </li>
+ <li>
+ <strong>Many</strong> use cases, meaning that the number of use cases is some multiple of a hundred, rather than a
+ multiple of ten.
+ </li>
+ <li>
+ Use-case names that are constructions such as "do this operation on this particular data" or "do this function with
+ this particular data". For example, "Enter Personal Identification Number in an ATM machine" should not be modeled
+ as a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a
+ complete flow of events that results in something of value to an actor.
+ </li>
+</ul>
+<p>
+ To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:
+</p>
+<ul>
+ <li>
+ What is the context of the system?
+ </li>
+ <li>
+ Why are you building this system?
+ </li>
+ <li>
+ What does the user want the system to do?
+ </li>
+ <li>
+ How do the users benefit from the system?
+ </li>
+</ul>
+<h3>
+ <a id="Structuring the Use-Case Model" name="Structuring the Use-Case Model">Structuring the Use-Case Model</a>
+</h3>
+<p>
+ There are three main reasons for structuring the use-case model:
+</p>
+<ul>
+ <li>
+ To make the use cases easier to understand.
+ </li>
+ <li>
+ To partition common behavior described within many use cases.
+ </li>
+ <li>
+ To make the use-case model easier to maintain.
+ </li>
+</ul>
+<p>
+ Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit
+ more about their behavior than a one-sentence description. You should at least have established a step-by-step outline
+ for the flow of events of the use case to make sure that your decisions are based on an accurate understanding of the
+ behavior.
+</p>
+<p>
+ There are several advanced modeling concepts available in the literature for structuring the use-case model,
+ however, following the principle of "keep-it-simple" only the most useful of these, namely the <<include>>
+ relationship is discussed in this process. This relationship permits one to factor out common behavior into a
+ separate use case that is "include" in other use cases. See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a> for more details.
+</p>
+<p>
+ Another aspect of structuring the use-case model for easier understanding is grouping the use cases into packages.
+ The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see
+ <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>.
+</p>
+<h3>
+ <a id="Use Cases Are Always Related to Actors" name="Use Cases Are Always Related to Actors">Relationship Between Use
+ Cases and Actors</a>
+</h3>
+<p>
+ Running each use case includes communication with one or more actors. A use-case instance is always started by an actor
+ asking the system to do something. This implies that every use case should have communicates-associations with actors.
+ The reason for this rule is to enforce that the system provides only the functionality that users need and nothing
+ else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the
+ requirements.
+</p>
+<p>
+ However, there are some exceptions to this rule:
+</p>
+<ul>
+ <li>
+ An "included" use case might not interact with an actor if the base use case does.
+ </li>
+ <li>
+ A use case may be initiated according to a schedule (for example, once a week or once a day), which means that the
+ system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated
+ by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have
+ any associations to actors. However, for clarity, you can use "time" as an actor to show how the use case is
+ initiated in your use-case diagrams. <strong>CAUTION:</strong> if you have a lot of "time" actors in your model,
+ challenge them. Perhaps you missed a real actor, such as an administrator responsible for scheduling reports,
+ etc.
+ </li>
+</ul><!-- END:mainDescription,_AGvpcMM3EdmSIPI87WLu3g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/uc_realizations.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/uc_realizations.html
new file mode 100644
index 0000000..8149718
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/uc_realizations.html
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\uc_realizations.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uc_realizations.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2uan8NbyEdqu5o2S60g5LA CRC: 3403947559 -->Use-Cases Realizations<!-- END:presentationName,_2uan8NbyEdqu5o2S60g5LA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_2uan8NbyEdqu5o2S60g5LA CRC: 71112661 -->A use-case realization represents how a use case will be implemented in terms of collaborating objects. This guideline describes its purpose and UML notation.<!-- END:briefDescription,_2uan8NbyEdqu5o2S60g5LA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-CFYVionNDLkMw6SG6runQA CRC: 3140887471 --><p>
+ A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
+ can take various forms. It may include, for example, a textual description (a document), class diagrams of
+ participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
+ the flow of interactions between class and subsystem instances.
+</p>
+<p>
+ The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
+ managed separately from their realizations. This is particularly important for larger projects, or families of systems
+ where the same use cases may be designed differently in different products within the product family. Consider the case
+ of a family of telephone switches which have many use cases in common, but which design and implement them differently
+ according to product positioning, performance and price.
+</p>
+<p>
+ For larger projects, separating the use case and its realization allows changes to the design of the use case without
+ affecting the baselined use case itself.
+</p>
+<p>
+ In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
+ (such as textual descriptions) that form part of the use-case realization.
+</p>
+<p>
+ UML diagrams that support use-case realizations can be produced in an analysis context, a design context, or
+ both, depending on the needs of the project. For each use case in the use-case model, there can be a use-case
+ realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
+ dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
+ inheritance, as well as a dependency.<br />
+</p>
+<p align="center">
+ <img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
+</p>
+<p>
+ A use-case realization in the design can be traced to a use case in the use-case model.
+</p>
+<h4>
+ Class Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there may be one or more class diagrams depicting its participating classes. A class and
+ its objects often participate in several use-case realizations. It is important while designing to coordinate all
+ the requirements on a class and its objects that different use-case realizations may have. The figure below shows an
+ analysis class diagram for the realization of the Receive Deposit Item use case. Note the use of
+ boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Concept: Entity-Control-Boundary Pattern</a>).
+</p>
+<p align="center">
+ <img height="213" alt="Class diagram for the realization of Receive Deposit Item" src="./resources/md_ucre3.gif" width="328" />
+</p>
+<p align="center">
+ <strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
+</p>
+<h4>
+ Communication and Sequence Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there can be one or more interaction diagrams depicting its participating
+ objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
+ diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
+ of messages and are better when it is important to visualize the time ordering of messages, whereas communication
+ diagrams show the communication links between objects and are better for understanding all of the effects on a given
+ object and for algorithm design.
+</p>
+<p>
+ Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
+ responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
+ contain the following:
+</p>
+<ul>
+ <li>
+ Only the functionality actually used in support of a use case scenario.
+ </li>
+ <li>
+ Functionality that can be tested through an associated test case.
+ </li>
+ <li>
+ Functionality that is more easily traceable to requirements and changes.
+ </li>
+ <li>
+ Explicitly declared class dependencies that are easier to manage.
+ </li>
+</ul>
+<p>
+ These factors help improve the overall quality of the system.
+</p><!-- END:mainDescription,-CFYVionNDLkMw6SG6runQA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/use_case_formats.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/use_case_formats.html
new file mode 100644
index 0000000..706b06a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/use_case_formats.html
@@ -0,0 +1,356 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\use_case_formats.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case_formats.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_qq0GMAXkEduj_7BEUj1JfQ CRC: 2309794883 -->Use Case Formats<!-- END:presentationName,_qq0GMAXkEduj_7BEUj1JfQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_qq0GMAXkEduj_7BEUj1JfQ CRC: 916527591 -->This guideline describes different use case formats and associated levels of detail that you may want to use, depending upon the nature of the project.<!-- END:briefDescription,_qq0GMAXkEduj_7BEUj1JfQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-pQrBSyxJHLLodLbS4R_Zdw CRC: 1981128168 --><h3> Use Case Formats </h3>
+<p> Use cases differ from project to project and person to person. A use case
+ that works in one situation may be totally unsuited for another. Different projects
+ have different needs. (See <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO04]</a>
+ for more information on use case formats.) </p>
+<p>Some need rigorous documentation, including <strong>high-ceremony use cases</strong>,
+ which are formal, highly structured use cases. If the writers used a template,
+ then they filled out all or almost all of its fields for each use case. High-ceremony
+ use cases are best suited for large, extremely complex, safety-critical systems,
+ such as flight control systems, telephone switches, and so forth. They are also
+ used in development cultures that have high documentation standards. </p>
+<p>Other projects may be more agile and less formal, benefiting from <strong>low-ceremony
+ use cases</strong>, which are informal, less rigidly structured use cases. If
+ the writers used a template, then they may have left many of the fields blank.
+ Low-ceremony use cases are best suited for smaller, less complex, less safety-critical
+ systems where most of the stakeholders have a strong background in the problem
+ domain. Sometimes, simple descriptions suffice, such as use case <strong>briefs</strong>.
+</p>
+<p> As <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline:
+ Detail Use Cases and Scenarios</a> explains, it makes sense to write use cases
+ iteratively. Starting with the basic details, you can then identify the various
+ alternative and error paths that the use case might follow so that you can evaluate,
+ rearrange, or eliminate them, and then elaborate or fill in the details of the
+ courses that you intended to use. You can then write the
+ use cases in<strong> </strong> one or more of
+ the following formats, progressively, until you
+ reach the one with the level of detail required for a specific project: </p>
+<ul>
+ <li><a id="Actor-Goal-List" name="Actor-Goal_List"><strong>Actor-Goal list</strong></a>:
+ A format for the overview</li>
+ <li> <a id="Briefs" name="Briefs"><strong>Briefs: </strong></a>A format for
+ writing summary use cases</li>
+ <li> <a id="Improvisational Score" name="Improvisational Score"><strong>Improvisational
+ score: </strong></a>A format for writing less formal, low-ceremony use cases</li>
+ <li> <a id="Symphonic Score" name="Symphonic Score"><strong>Symphonic score:
+ </strong></a>A format for writing more formal, high-ceremony use cases</li>
+</ul>
+<h4>Actor-Goal list </h4>
+<p> <strong>Context: </strong>You have identified your actors and are trying to
+ identify use cases. </p>
+<p> <strong>Problem:</strong> Developing a set of use cases in an ad hoc manner
+ can lead to unnecessary work, missing features, and feature creep. Weight
+ is one of the most important factors in space flight — so important that
+ the United States space agency, NASA, will not
+ allow anything on a spacecraft that isn’t absolutely critical to the flight.
+ If something literally isn’t worth its weight, then it doesn’t go. Likewise,
+ each use case adds cost to a system; therefore, you need to be sure to include
+ only those use cases that add some kind of value to your collection. </p>
+<p> <strong>Forces:<em> </em></strong></p>
+<ul>
+ <li>
+ <p><strong>Simply listing actors or listing goals is not informative enough,
+ but actors and goals together are informative.</strong> The classical approach
+ to writing use cases is to define a list of actors, then find use cases
+ for each. A variation on this theme is to itemize what the system must accomplish.
+ Yet, neither approach is adequate by itself. You need to know both who is
+ using the system and why they are using it. Otherwise, you introduce the
+ potential of either feature creep or missed features. At the least, a set
+ of use cases should describe this association. </p>
+ </li>
+ <li>
+ <p><strong> A quick overview of the entire project structure is sufficient
+ and necessary early in the use case development cycle.</strong> Ideally,
+ this overview should be as short as reasonably possible. It must contain
+ key information as to who requires each service and why they need it. Most
+ other information is not very useful at this stage of the project, because
+ it runs the risk of quickly becoming obsolete, as well as discouraging
+ out-of-the-box (innovative) thinking. An overview
+ helps the writers work through the entire set from a high-level view, expanding
+ some use cases, eliminating others, and combining still others into a more
+ logical grouping. </p>
+ </li>
+ <li>
+ <p><strong>You need to be able to expand each to a full use case on demand.
+ </strong>A <em>seedling</em><strong> </strong>use case forms the basis for
+ a full use case later in the iterative development cycle. Each seedling
+ use case needs to convey enough information so that someone, possibly other
+ than the outline writer, can easily go back and expand it into a more informative
+ use case. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Build an Actor-Goal list,
+ which is a list of actors and their goals that
+ gives you an overview of entire project needs.<strong></strong></p>
+<ul>
+ <li>
+ <p>Start by identifying the list of actors who will use the system, and then
+ identify at least one goal for each. Actors without goals indicate that
+ you haven’t adequately defined the system. The actor is beyond the system’s
+ scope, doesn’t belong in the system, or is part of another actor. </p>
+ </li>
+ <li>
+ <p>Likewise, leftover goals can indicate that the system is too complex and
+ you're trying to accomplish too much, or that you haven’t adequately defined
+ all of the necessary actors. Carefully evaluate the leftovers to see if
+ you are just overlooking some detail, or whether they don’t belong in the
+ system. </p>
+ </li>
+ <li>
+ <p>Remove unassociated actors and goals from the list. </p>
+ </li>
+</ul>
+<p> Sometimes, this list may provide enough information to serve as use cases
+ for very small, high-communicating, low-ceremony project teams. Usually, the
+ actor goal list is the first step of identifying use cases. </p>
+<h4>
+ Briefs
+</h4>
+<p> <strong>Context: </strong>You have written an Actor-Goal list that outlines
+ your use cases. </p>
+<p> <strong>Problem: </strong>Relying solely on an overview to capture the important
+ parts of a system’s behavior is dangerous, because it provides only high-level
+ information and can easily introduce ambiguity into a system. </p>
+<p> <strong>Forces: </strong></p>
+<ul>
+ <li>
+ <p><strong>Although valuable, an Actor-Goal list does not clearly describe
+ a system.</strong> Usually, an outline doesn’t provide enough precision
+ to avoid ambiguity, which can wreak havoc on a project by leading to unnecessary
+ or erroneous development. Yet, an outline is helpful, because you still
+ want an overview that you can easily scan. Unfortunately, with the passing
+ of time or sheer volume of work, it’s too easy to forget details
+ that were obvious to you earlier.</p>
+ </li>
+ <li>
+ <p><strong>Iterative use case development requires creating placeholders for
+ expansion.</strong> To develop use cases iteratively, you start with sparse
+ use cases, reorganize them, and flesh them out as the system takes shape.
+ Ideally, these placeholders should be clear enough to: 1) unambiguously
+ describe their role in the system, and 2) allow someone to expand the use
+ case, even if they were not involved in writing them originally. </p>
+ </li>
+ <li>
+ <p><strong>Because outlines are general by nature, do not spend a lot of time,
+ energy, or money writing them. </strong>Outlines provide an inexpensive
+ method of documenting complex ideas in a manner that is easy to follow,
+ and they provide a mechanism for people outside of a project to understand
+ the high-level concepts. While it may take
+ some effort to think things through, you don’t want to waste resources describing
+ your ideas. The system is still in a state of flux at this point, and it
+ is too early to spend much time documenting its shifting details. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Write two to four sentences per use case, capturing
+ key activities and key-extension handling. </p>
+<ul>
+ <li>
+ <p> Expand the Actor-Goal list into<strong> briefs</strong> by writing a two-
+ to four-sentence use cases for each entry in the list. </p>
+ </li>
+ <li>
+ <p>Briefly describe each use case’s main scenario and most important
+ extensions. </p>
+ </li>
+ <li>
+ <p> Include enough information to eliminate ambiguity for at least the main scenario
+ of the system. </p>
+ </li>
+</ul>
+<h4> Improvisational score</h4>
+<p> <strong>Context: </strong>You are operating in well-known domains or in situations
+ where writing high-ceremony use cases would require all of your allotted development
+ time. </p>
+<p> <strong>Problem:</strong> Writing formal, high-ceremony use cases when lesser
+ detail would suffice wastes time and resources. </p>
+<p> Jazz is considered to be “musician’s music,” and jazz players are usually
+ highly skilled. Many jazz musicians prefer to improvise in small, highly skilled
+ teams, such as jazz quartets. To improvise effectively, the musicians must have
+ a thorough understanding of the conventions that form the given musical style,
+ including chord sequences, rhythmic patterns, and melodies. These conventions
+ provide a basic framework for the musicians to interact as a team, while still
+ allowing room for spontaneous creativity. </p>
+<p> Likewise, use cases do not always need to be specified in excruciating detail.
+ A far-preferable strategy is simply to define the basic structure of what the
+ developers need to implement. The use cases act as placeholders that may be
+ elaborated later or simply improvised by the developer who implements the use
+ case. </p>
+<p> <strong>Forces:</strong></p>
+<ul>
+ <li>
+ <p><strong>Briefs do not provide enough information. </strong>While useful,
+ use-case briefs describe only the more significant parts of behavior. Often,
+ developers need more information, especially when working in unfamiliar
+ domains or in the heart of the system, where the actor has many choices
+ to make and many paths to follow. Briefs do not describe all of the important
+ events that can happen, nor do they describe the details that go into making
+ choices along the way. </p>
+ </li>
+ <li>
+ <p><strong>Fully elaborated use cases can be too expensive, time consuming,
+ long to write, and boring to read. </strong>It
+ takes a lot of time and effort to write a formal, fully descriptive set
+ of use cases. Maintaining this set takes even longer. Often, a collection
+ of use cases reaches the point of diminishing returns long before it is
+ completely written, much less formalized. Readers often prefer shorter,
+ simpler use cases over long, complicated ones, because overly detailed use
+ cases can be overwhelming and, frankly speaking, quite boring. </p>
+ </li>
+ <li>
+ <p><strong>Many groups communicate well enough to
+ resolve ambiguities on the fly. </strong>While briefs may be insufficient,
+ stakeholders don’t always need everything to be spelled out for them. Developers
+ are usually capable of asking questions and filling out the necessary detail
+ from their own domain knowledge. Many people can work with a fair level
+ of ambiguity, and most organizations possess what is often referred to as
+ their “core competencies.” Mature organizations with strong domain knowledge
+ can survive, and even thrive, using more informal, less precise use cases.
+ </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Specify the use cases at
+ a low level of precision, allowing the developers to fill in the missing details
+ as necessary. The level of precision required depends on the background experiences
+ of the development team. Skip the less meaningful fields on the template, and
+ write the Main Scenario section as a simple paragraph.
+ Describe key-extension handling in the next paragraph
+ or two. Be prepared to resolve ambiguities and expand detail on the fly throughout
+ the project. </p>
+<p> When you can rely upon open and frequent communication among the developers
+ and customer, write the use case with less detail and precision. The developers
+ can fill in the gaps by asking users or by using knowledge of the domain. However,
+ the developers need a thorough understanding of the business context to be able
+ to fill out the details themselves. Even the most knowledgeable developer will
+ still need access to the customers and users to get answers to questions and
+ clarify requirements. </p>
+<p> Ideally, the project will be structured to enable effective communication
+ between the customer and the developers. Typically, this will involve having
+ a small, co-located team, with the developers having easy access to the users
+ throughout the project. The risk of misunderstanding can be resolved by frequent
+ incremental delivery if the development organization
+ has a relatively low-ceremony culture. </p>
+<p> Jazz improvisation does not always work. It can become tedious and unpleasant
+ to listen to, even for the committed connoisseur.
+ For this reason, you also need feedback from the audience to determine the success
+ of the improvisations. Multi-level or two-tier reviews are critical to success
+ (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline:
+ Effective Requirement Reviews</a>). </p>
+<p> Improvisation may not always be suitable for the organizational culture, a
+ full <strong>symphonic score</strong> may be preferable in large, high-ceremony
+ teams (see section that follows). For instance,
+ I once watched a conductor toss his baton away in disgust when a pianist improvised
+ to such an extent that the orchestra could not follow the score. If the organization
+ deems the risk of improvising to be unacceptably high, then you can specify
+ the use cases with a higher level of detail and precision. You could start with
+ a strategy of specifying low levels of detail and precision, and then adapt
+ as necessary. </p>
+<h4> Symphonic score </h4>
+<p> <strong>Context: </strong>Writing structure for high-ceremony situations,
+ such as when there are many developers or when development teams are geographically
+ dispersed. </p>
+<p> <strong>Problem: </strong>Writing low-ceremony use cases for high-ceremony
+ situations raises the risk of miscommunication to unacceptable levels. </p>
+<p> A conductor’s version of a symphonic score contains the music for the entire
+ orchestra, as well as any accompanying vocals. The parts to be performed by
+ different voices or instruments are written on a separate staff, with all of
+ the staves aligned, one above another. This score specifies each note and its
+ associated timing in precise detail, so that the orchestra can perform a symphony
+ as the composer intended. </p>
+<p> As with use cases, a score tells the musician what to play, not how to play
+ it. For most symphonies, the orchestra will not be able to meet the composer,
+ so instead, they must rely upon the director to interpret the
+ score and the composer's intentions. </p>
+<p> <strong>Forces: </strong></p>
+<ul>
+ <li>
+ <p><strong>Certain development situations and cultures require high degrees
+ of formality. </strong>Some organizations operate in a highly formal manner,
+ thus require a highly formal process. While this formality may not
+ be desirable, it is the company's way of doing business, so things need
+ to be done that way. Other organizations are highly formal because they
+ do highly complex, life-critical work, where even small failures could have
+ disastrous consequences. For instance, no one would feel comfortable flying
+ on an airliner with an off-the-shelf, one-size-fits-all flight management
+ system. </p>
+ </li>
+ <li>
+ <p><strong>The cost of repairing miscommunication
+ is high. </strong>It is easy to write vague, inadequate use cases full of
+ ambiguity. Use cases can be too brief and ambiguous, or contain domain-specific
+ details that may be beyond the understanding of many stakeholders. Either
+ way, they provide an opportunity for a misunderstanding that leads to an
+ incorrect implementation. The cost of correcting these mistakes depends
+ on when they are discovered. <em>Earlier</em> is cheaper than<em> later</em>,
+ especially when later means customers finding the problem in the delivered
+ product. To avoid miscommunication, aim to write use cases that are general
+ enough for all of the stakeholders to follow, yet precise enough for the
+ developers to use when building the system. </p>
+ </li>
+ <li>
+ <p><strong>Developers need detail for implementing steps, business rules,
+ data fields, and, especially, for handling extensions. </strong>No one has
+ developed a program that can take a set of use cases as input, and churn
+ out a completed system. Even the best-case tools seem to require human intervention
+ to flesh out details and resolve ambiguities. Similarly, developers who
+ do not understand the business context or lack domain expertise may not
+ be able to fully comprehend a product. In an ideal project, software developers
+ would have access to the domain experts to ask questions, so they could
+ fill in any areas that may have been missed (see<em> Improvisational score</em>,
+ previously). But often, they do not ask. Therefore, they misunderstand the
+ more complex or ambiguous use cases in the set. To develop a system correctly,
+ a team needs either access to domain experts or additional information that
+ describe the steps, business rules, data fields, and extension handling
+ that they are implementing. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Specify your use cases with a high level of precision,
+ explicitly filling in all of the details in the use case template, while staying
+ technology-neutral. The level of precision required depends on the background
+ experiences of the development team. </p>
+<p> Intuition may tell you that if some detail is good, then more must be better.
+ However, be careful about falling into the trap of over-specifying details.
+ It’s naive to believe that everyone who reads your use cases will be able to
+ understand them. Different people may interpret the use cases differently. Prepare
+ for this eventuality in your process, and avoid the tendency to over-specify
+ your use cases. If you try to specify a use case in too much detail, you may
+ fall into the classic analysis paralysis trap. </p>
+<p> People are often tempted to address the communication problem by trying to
+ explain the business domain within the use cases. In a similar manner, they
+ include too much technical detail. Succumbing to these temptations by explaining
+ the business domain or including technical details is always a mistake, because
+ it complicates the process and obfuscates the requirements. The reader of the
+ use cases cannot distinguish the real requirements from the boring background
+ information, so will soon get distracted and lose interest. Instead, include
+ this information in an extra section. </p>
+<p> If you are handing over the requirements to a development team whose members
+ are unfamiliar with the domain, then you will need an alternative strategy for
+ teaching them the domain knowledge. </p><!-- END:mainDescription,-pQrBSyxJHLLodLbS4R_Zdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/using_patterns.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/using_patterns.html
new file mode 100644
index 0000000..0c44d19
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/using_patterns.html
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\using_patterns.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: using_patterns.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0cr7cACrEdu8m4dIntu6jA CRC: 4266121887 -->Using Patterns<!-- END:presentationName,_0cr7cACrEdu8m4dIntu6jA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0cr7cACrEdu8m4dIntu6jA CRC: 639031276 -->This guidance discusses the practical application of patterns in a project.<!-- END:briefDescription,_0cr7cACrEdu8m4dIntu6jA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-U-5cLUk-mdaO518lh5CxTQ CRC: 499017275 --><p>
+ In software design, it is primarily the development method and not the pattern and its pattern language that influences
+ the process of pattern selection and use. As discussed in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/patterns,_0YJvUMlgEdmt3adZL5Dmdw.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Patterns</a>, Alexander developed the concept of generative pattern languages
+ to guide a designer’s application of individual patterns to the entire design. In software design, however, as
+ Alexander observed [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">OOP96</a>] there is little evidence of using generative pattern languages.
+</p>
+<p>
+ For iterative development methods, software patterns and pattern languages support the development method through their
+ ability to be applied incrementally, or by piecemeal growth, and by providing extensible structures. From an
+ architectural perspective, these two qualities allow software architecture to be designed and refactored incrementally,
+ thus so avoid the need for a so-called "big, up-front design."
+</p>
+<h4>
+ Piecemeal growth
+</h4>
+<p>
+ The term <strong>piecemeal growth</strong>, as it applies to patterns, originates in Alexander's work. It refers to a
+ top-down design process in which a design starts from a high-level structure that is embellished or refined through the
+ implementation of lower-level patterns. For software development, this corresponds to using hierarchies of
+ architectural and design patterns and idioms like those proposed by Buschmann et. al. [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>]. Using the idea of piecemeal growth, an architect can start with one or more
+ architectural patterns to provide an architectural vision for the design, and then progressively extend the design
+ using design patterns. For example, an interactive application may use the Model-View-Controller pattern as its
+ architectural vision, then during implementation the Command pattern may be selected to implement the Controller
+ component.
+</p>
+<h4>
+ Extensibility
+</h4>
+<p>
+ A key aspect of object oriented design patterns is their ability to support extension without causing the rewriting of
+ existing code. This feature allows a bottom up approach to the design process through code refactoring. When a problem
+ is encountered during coding such as duplicate code, the developer can weighed up various patterns and their tradeoffs
+ and select the appropriate solution in the context of the application.
+</p><!-- END:mainDescription,-U-5cLUk-mdaO518lh5CxTQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/work_items_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/work_items_list.html
new file mode 100644
index 0000000..7de0fb0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/work_items_list.html
@@ -0,0 +1,162 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\work_items_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_items_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7vEXEMA4EdqSgKaj2SZBmg CRC: 699774998 -->Work Items List<!-- END:presentationName,_7vEXEMA4EdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_7vEXEMA4EdqSgKaj2SZBmg CRC: 1795823392 -->This guideline explains the lifecycle of work items, and how the Work Items List is used.<!-- END:briefDescription,_7vEXEMA4EdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-G1Oxlk6F0R09vClqy1EzOw CRC: 509522752 --><h3>
+ Introduction
+</h3>
+<p>
+ The <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> captures all scheduled work to be done within the
+ project, as well as proposed work that may affect the product. Some of the Work Items may be implemented in this
+ project, some of them may be implemented in a future project, and some of them may never be implemented.
+</p>
+<p>
+ Some of the work items may still be poorly defined, representing a big chunk of work requiring potentially several
+ staff months of effort. As the priority of these work items increase, they are typically decomposed into smaller work
+ items that represent specific and well-defined tasks that may take hours or days to address. In other cases, specific
+ and well-defined work items are created directly, representing for example a defect to be addressed, see Figure 1.
+</p>
+<br />
+<img height="369" alt="work item list overview" src="./resources/wil_overview.bmp" width="600" /><br />
+<br />
+<p>
+ <strong><em>Figure 1. Work Items List provides one prioritized list of scheduled and proposed work.</em></strong>
+</p>
+<p>
+ A Work Item may represent work associated with a defect, enhancement request, use case, scenario, user story,
+ supporting requirement, or anything else that captures a potential requirement or improvement to your system. A Work
+ Item may reference any type of requirement, defect, enhancement request, or other useful information guiding you in
+ what needs to be done.
+</p>
+<p>
+ A big advantage with the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> is that it enables you to prioritize only one list
+ containing all the things that may need to be addressed, whether the work item represent a work related to a
+ requirement, enhancement, or defect. The one exception is that we separately prioritize the risk list.
+</p>
+<p>
+ Nothing in the project will get done if not represented or mapped to a Work Item. This means that all requirements,
+ defects and change requests have to at some stage be mapped to a work item. Also, a developer will not take on work
+ that is not represented in a Work Item. Only Work Items needs to be prioritized. This also means that tracking Work
+ Items are a primary means of understanding status of the project.
+</p>
+<p>
+ There are two major types of Work Items:
+</p>
+<ul>
+ <li>
+ <strong>Un-scheduled Work Items:</strong> These Work Items have not yet been assigned to an iteration, and there is
+ no detailed effort estimate for the Work Item yet.
+ </li>
+ <li>
+ <strong>Scheduled Work Items:</strong> These Work Items are assigned to an iteration, and typically have an
+ additional set of attributes filled in, such as detailed effort estimates.
+ </li>
+</ul>
+<h3>
+ Un-scheduled Work Items
+</h3>
+<p>
+ Most Work Items are initially un-scheduled, meaning that it has not yet been decided whether to do them, and when to do
+ them. Unscheduled Work Items should always represent something meaningful to deliver to stakeholders, such a scenario
+ to be detailed, designed, implemented and tested. You may consider capturing the following data for such Work Items:
+</p>
+<ul>
+ <li>
+ Name
+ </li>
+ <li>
+ Description
+ </li>
+ <li>
+ Priority
+ </li>
+ <li>
+ Size estimate, such as a point estimate, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+ </li>
+ <li>
+ State, such as New, Assigned, Resolved, Verified, Closed, see Work Items States below
+ </li>
+ <li>
+ Links to other reference material, such as requirements or detailed specifications of what needs to be done
+ </li>
+</ul>
+<h3>
+ Scheduled Work Items
+</h3>
+<p>
+ Once a Work Item has been assigned to an iteration, it becomes scheduled. Note that we only assign Work Items to the
+ current or next iteration. There is no point in assigning Work Items to a specific future iteration, since we cannot
+ predict what a meaningful schedule will be more than an iteration in advance, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/iteration_planning,_0auiMMlgEdmt3adZL5Dmdw.html" guid="_0auiMMlgEdmt3adZL5Dmdw">Guideline: Iteration Planning</a>.
+</p>
+<p>
+ The following additional attributes are useful for Scheduled Work Items:
+</p>
+<ul>
+ <li>
+ Target iteration
+ </li>
+ <li>
+ Responsible team member
+ </li>
+ <li>
+ Effort estimate left, such as actual hours of work, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+ </li>
+ <li>
+ Hours worked
+ </li>
+</ul>
+<p>
+ This provides the information required to plan and manage an iteration. We can plan iterations by understanding effort
+ involved and we can do <a class="elementLinkWithType" href="./../../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> by tracking how much work is left.
+</p>
+<h3>
+ Work Items States
+</h3>
+<p>
+ We have found the following states to be useful to track Work Items:
+</p>
+<ul>
+ <li>
+ New: Work Item has been created, but not yet assigned to a team member.
+ </li>
+ <li>
+ Assigned: A team member has been identified as responsible for the Work Item.
+ </li>
+ <li>
+ Resolved: The team member responsible for the work items has implemented and tested the Work Item.
+ </li>
+ <li>
+ Verified: The Work Item has been independently tested.
+ </li>
+ <li>
+ Closed: The Work Item is no longer active.
+ </li>
+</ul>
+<p>
+ You may choose another set of states, based on your needs.
+</p><!-- END:mainDescription,-G1Oxlk6F0R09vClqy1EzOw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/writing_good_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/writing_good_requirements.html
new file mode 100644
index 0000000..f2afaf0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/writing_good_requirements.html
@@ -0,0 +1,120 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\guidelines\writing_good_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: writing_good_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_6jXzYNcKEdqz_d2XWoVt6Q CRC: 3943194408 -->Writing Good Requirements<!-- END:presentationName,_6jXzYNcKEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_6jXzYNcKEdqz_d2XWoVt6Q CRC: 2478461860 -->This guideline describes ways of writing good requirements.<!-- END:briefDescription,_6jXzYNcKEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-AJQLv2ldVv5KN9eUbdQe_g CRC: 1305963723 --><P>To write a good requirement,
+ you must write it<strong> </strong>as a complete sentence, with a subject
+ and a predicate (usually a verb). The subject is
+ an Actor, a stakeholder, the system under development, or a design entity that
+ is related to the requirement. The predicate specifies a condition, action,
+ or intended result that is done for, by, with, or to the subject.</P>
+<P>Consistent use of the verb <strong>to be </strong>solidifies
+ the link between the subject and the predicate.<strong>
+ </strong>Thus, you can analyze a requirement from
+ a grammatical point of view. </P>
+<P>Beware of lists, bullets, and words such as <strong>all</strong>, <strong>every</strong>and <strong>some</strong>. For example:<strong> </strong></P>
+<blockquote>
+ <p>The order entry clerk must<strong> </strong>be
+ able to complete 10 customer orders in less than two hours.</p>
+</blockquote>
+<P>This requirement has a subject (the order entry clerk, who<strong>
+ </strong>is an Actor), a specific and measurable
+ end state (10 customer orders completed), and a performance criterion
+ (in less than two hours).</P>
+<P>Follow these simple guidelines<strong> </strong>
+ in writing any requirement. For consistency, these examples
+ are all in the context of an aircraft. [[WAS: is used throughout.]] <a class=elementlinkwithusertext href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</P>
+<ul>
+ <li>Define one requirement at a time.
+ <blockquote>
+ <p>The pilot shall be able to control the aircraft's angle of climb with
+ one hand.</p>
+ </blockquote>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p> The pilot shall be able to feel the angle of climb from the climb control.</p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>Avoid conjunctions (and, or) that make multiple requirements. </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p>The navigator shall be able to view the aircraft's position relative to
+ the route's radio beacons. </p>
+ <p>The navigator shall be able to view the aircraft's position as
+ estimated by inertial guidance.</p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>Avoid let-out clauses or words that imply options
+ or exceptions (unless, except, if necessary, but). </li>
+ <blockquote>
+ <p>The design shall provide a rear-facing seat
+ for each cabin crew member.</p>
+ </blockquote>
+ <li>Use simple, direct sentences. </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>The pilot shall be able to see<strong> </strong>the
+ airspeed indicator.</p>
+ </blockquote>
+ <li>Use a limited (500-word) vocabulary, especially if your audience is international.
+ <blockquote>
+ <p>The airline shall be able to convert the
+ aircraft from business to holiday charter use in less than 12 hours </p>
+ </blockquote>
+ </li>
+ <blockquote>
+ <p><strong>Note: </strong>There is no need to use words such
+ as <strong> reconfigured. </strong></p>
+ </blockquote>
+ <li>Identify the type of user who needs each requirement.
+ </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>The navigator shall be able to...</p>
+ </blockquote>
+ <li>Focus on stating what result you will provide<strong>
+ </strong> for that type of user. </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>...view storm clouds by radar...</p>
+ </blockquote>
+ <li>Define verifiable criteria
+ <blockquote>
+ <p> ...at least 100 miles ahead.</p>
+ </blockquote>
+ </li>
+</ul><!-- END:mainDescription,-AJQLv2ldVv5KN9eUbdQe_g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/iteration_burndown.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/iteration_burndown.html
new file mode 100644
index 0000000..e7d0e85
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/iteration_burndown.html
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\reports\iteration_burndown.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration_burndown.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_uAzgkDg3Edu4E8ZdmlYjtA CRC: 130522951 -->Iteration Burndown<!-- END:presentationName,_uAzgkDg3Edu4E8ZdmlYjtA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_uAzgkDg3Edu4E8ZdmlYjtA CRC: 2347347768 -->The iteration burndown shows the trend for how much work is left to do within that iteration.<!-- END:briefDescription,_uAzgkDg3Edu4E8ZdmlYjtA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Aw8p59vJ9rWsOV82rljQiQ CRC: 1463150831 --><p>
+ The iteration burndown is the primary tool for understanding the status of the current iteration. It shows the
+ trend for how much work is left to do within the iteration. This is accomplished by adding up the estimated effort left
+ for each of the work items to be addressed within the iteration, and showing how the estimated effort is changing over
+ the duration of the iteration. The iteration backlog should be updated frequently, preferably on a daily basis.
+</p>
+<p>
+ Factors that impact the team’s assessment of how much work remains include:
+</p>
+<ul>
+ <li>
+ Work that has been completed, which means there is less work remaining.
+ </li>
+ <li>
+ The developer responsible for a work item changes the assessment of effort required to complete the work item. This
+ should be expected, since we typically understand what it really takes to complete a task after we have done a
+ subset of the task. It's common for estimates of the work remaining to increase in the beginning of the
+ iteration, especially for inexperienced teams, since they often underestimate efforts. Expect estimates to continue
+ changing as teams become more experienced, but the modifications are as frequently upward as downward.
+ </li>
+ <li>
+ Estimated effort left can increase during the iteration as a result of the team learning more about what needs to
+ be done.
+ </li>
+</ul>
+<p>
+ Daily or frequent updates to the iteration burndown allows the team to react to changes. For example, cutting scope by
+ removing work items from the iteration, reducing the ambition level associated with a work item, or finding better ways
+ of approaching work items such as having an expert team member help out with difficult work items.
+</p>
+<p>
+ See <a href="./resources/ex_iteration_burndown.xls" target="_blank">ex_iteration_burndown.xls</a> for an example
+ iteration burndown report.<br />
+</p><!-- END:mainDescription,-Aw8p59vJ9rWsOV82rljQiQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/project_burndown.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/project_burndown.html
new file mode 100644
index 0000000..52ac912
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/project_burndown.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\reports\project_burndown.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_burndown.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ePrt8Dj3EduxovfWMDsntw CRC: 3908186902 -->Project Burndown<!-- END:presentationName,_ePrt8Dj3EduxovfWMDsntw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ePrt8Dj3EduxovfWMDsntw CRC: 113527674 -->An effective way of communicating project progress.<!-- END:briefDescription,_ePrt8Dj3EduxovfWMDsntw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-hrDndmFd0zexB0HNYX3gww CRC: 3622886228 --><p>
+ Project burndown is usually communicated in graphical form. Project burndown is very useful to quickly communicate
+ the overall project progress based on actual data and to diagnose a trend for the remainder of the project.
+</p>
+<p>
+ The project burndown chart consists of two perspectives, the horizontal axis showing the iterations and the vertical
+ axis indicating the remaining points from the work items list. Additionally the average burndown from previous
+ iterations is calculated and a trend for the remainder of the project diagnosed and forecasted.
+</p>
+<p>
+ Project burndown management is a enabling technique that allows direct linkage of iteration goals to work items. The
+ project manager will use the project burndown information for communicating progress and trend to senior management.
+</p>
+See <a href="./resources/ex_project_burndown.xls" target="_blank">ex_project_burndown.xls</a> for an example of
+project burndown.<br /><!-- END:mainDescription,-hrDndmFd0zexB0HNYX3gww -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls
new file mode 100644
index 0000000..67cb1b6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/resources/ex_project_burndown.xls b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/resources/ex_project_burndown.xls
new file mode 100644
index 0000000..e63fef8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/reports/resources/ex_project_burndown.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/roadmaps/openup_basic_roadmap.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/roadmaps/openup_basic_roadmap.html
new file mode 100644
index 0000000..77512b0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/roadmaps/openup_basic_roadmap.html
@@ -0,0 +1,220 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\roadmaps\openup_basic_roadmap.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_roadmap.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_vEruwN-rEdqiM_wFaqLjNg CRC: 561715492 -->OpenUP/Basic Roadmap<!-- END:presentationName,_vEruwN-rEdqiM_wFaqLjNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_vEruwN-rEdqiM_wFaqLjNg CRC: 1540090830 -->This roadmap presents an overview of OpenUP/Basic, its purpose and lifecycle.<!-- END:briefDescription,_vEruwN-rEdqiM_wFaqLjNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-At_b3UIzbgdmtJsb2Ymfhg CRC: 4143424056 --><h3>
+ Introduction
+</h3>
+<p>
+ OpenUP/Basic is for small teams, working together in the same location. The team needs to engage in plenty of daily
+ face-to-face interaction. Team members include the stakeholders, developers, architects, project manager, and testers.
+ Team members engage in significant collaboration, making their own decisions as to what needs to be worked on, what the
+ priorities are, and how best to address stakeholder needs. The organization must support the team by allowing them this
+ responsibility.
+</p>
+<p>
+ Team members collaborate extensively. The presence of stakeholders as team members is critical to successfully
+ realizing OpenUP/Basic.
+</p>
+<p>
+ Team members participate in daily stand-up meetings to communicate status and issues. Problems are addressed outside of
+ the daily meetings.
+</p>
+<p>
+ OpenUP/Basic focuses on signficantly reducing risk early in the lifecycle. This requires regular risk review
+ meetings and rigorous implementation of mitigation strategies.
+</p>
+<p>
+ All work is listed, tracked, and assigned through the Work Item List. Team mebers use this single repository for all
+ tasks that need to be recorded and tracked. This includes all change requests, bugs, and stakeholder requests.
+</p>
+<p>
+ Use cases are used to elicit and describe requirements. Team members should develop skills at writing good use cases.
+ Stakeholders are responsbile for reviewing and certifying the requirements are correct. Use cases are developed
+ collaboratively.
+</p>
+<p>
+ Architecturally significant requirements must be identified and stabilized in Elaboration so a robust architecture can
+ be created that is the core of the system. An architecturally significant requirement change may arise later in
+ development that must be addressed, but the risk of this happening is significantly reduced in the Elaboration
+ iteration.
+</p>
+<p>
+ Testing is performed....
+</p>
+<p>
+ OpenUP/Basic doesn't include content for deployment, change management, or environment (such as customizing this
+ process or setting up development environments). OpenUP/Basic is focused on a singe team, and these areas are generally
+ addressed at an organizational or enterprise level. Look for extensions to OpenUP that address these wider areas.<br />
+</p>
+<p>
+ OpenUP/Basic is an iterative software development process that is minimal, complete, and extensible. It is governed by
+ four core <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA">principles</a>:
+</p>
+<ul>
+ <li>
+ Balance competing priorities to maximize stakeholder value.
+ </li>
+ <li>
+ Collaborate to align interests and share understanding
+ </li>
+ <li>
+ Evolve to continuously obtain feedback and improve
+ </li>
+ <li>
+ Focus on articulating the architecture
+ </li>
+</ul>
+<p>
+ <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">Roles</a> perform <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> that consume and produce <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/artifact,_x7cUM9nmEdmO6L4XMImrsA.html"
+ guid="_x7cUM9nmEdmO6L4XMImrsA">artifacts</a>. OpenUP/Basic describes the minimal set of roles, tasks, and
+ artifacts involved in software development:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ">Tasks</a> (organized by disciplines)
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg">Artifacts</a> (organized by domains)
+ </li>
+</ul>
+<h3>
+ Software development lifecycle
+</h3>
+<p>
+ OpenUP/Basic is an iterative process distributed throughout four <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html"
+ guid="__7xOEC7aEdqHMdmRzC0-2g">phases</a>: Inception, Elaboration, Construction, and Transition. Each phase consists of
+ one or more iterations, where stable, working versions of the software are developed and released, with the completion
+ of each iteration representing a minor <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">milestone</a> for the project and contributing to the successful achievement of the
+ Phase's major milestone where phase objectives are met.
+</p>
+<p>
+ The following diagram depicts the OpenUP/Basic <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">lifecycle</a>.
+</p>
+<p align="center">
+ <img height="192" alt="Figure 1: Diagram of the OpenUP/Basic Lifecycle" src="./resources/openup-basic_lifecycle.jpg"
+ width="667" usemap="#Map" border="0" />
+</p>
+<p align="center">
+ Figure 1: The OpenUP/Basic lifecycle
+</p>
+<map id="Map" name="Map">
+ <h4>
+ How to get started?
+ </h4>
+ <p>
+ The fourth OpenUP core principle, "Evolve to continuously obtain feedback and improve", suggests an iterative and
+ incremental approach to adopting OpenUP/Basic.
+ </p>
+ <ul>
+ <li>
+ Start with the core principles and understand the intentions behind OpenUP.
+ </li>
+ <li>
+ Then assess your existing process, and select one or two key areas that you would like to improve.
+ </li>
+ <li>
+ Begin using OpenUP/Basic to improve these areas first.
+ </li>
+ <li>
+ In later iterations or development cycles, make incremental improvements in other areas.
+ </li>
+ <li>
+ If you have little or no experience with unified processes or other iterative processes, use OpenUP/Basic in a
+ small pilot project, perhaps with only three to four people working for only two to three months.
+ </li>
+ </ul>
+ <p>
+ While OpenUP/Basic is a ready to use as-is, you may choose to extend the process or modify the work product
+ templates to suit your specific needs. For example:
+ </p>
+ <ul>
+ <li>
+ You may require more or less precision in your work products.
+ </li>
+ <li>
+ Your organization may have specific configuration management practices or safety protocols to include in your
+ process.
+ </li>
+ <li>
+ You may simply want to put your own corporate logo on the banner.
+ </li>
+ <li>
+ You may want to incorporate lessons learned from a retrospective review into OpenUP/Basic.
+ </li>
+ </ul>
+ <p>
+ Use EPF Composer to extend and tailor OpenUP/Basic. For more information about EPF composer, visit <a
+ href="http://www.eclipse.org/epf" target="_blank">www.eclipse.org/epf</a>.
+ </p>
+ <area shape="RECT" coords="116,7,175,25" alt="link to inception phase concept"
+ href="./../../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="255,11,327,27" alt="link to elaboration phase concept"
+ href="./../../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="395,11,476,27" alt="link to construction phase concept"
+ href="./../../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="554,10,619,27" alt="link to transition phase concept"
+ href="./../../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="39,98,100,162" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/inception_phase_iteration,_xupMvxOKEduCNqgZdt_OaA.html"
+ guid="_xupMvxOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="188,99,250,168" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="332,100,397,165" alt="link to construction phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="480,98,541,167" alt="link to transition phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/transition_phase_iteration,_467NIhOKEduCNqgZdt_OaA.html"
+ guid="_467NIhOKEduCNqgZdt_OaA" />
+</map><!-- END:mainDescription,-At_b3UIzbgdmtJsb2Ymfhg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg
new file mode 100644
index 0000000..4719cad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/about_openup_basic.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/about_openup_basic.html
new file mode 100644
index 0000000..ffc7d79
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/about_openup_basic.html
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\supportingmaterials\about_openup_basic.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: about_openup_basic.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8tSNMPGYEdqiDINUyockoA CRC: 387569400 -->About OpenUP/Basic<!-- END:presentationName,_8tSNMPGYEdqiDINUyockoA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-WFD3nKccpkueaG15cHT-fA CRC: 786172926 --><h3>
+ <a id="version" name="version">Version Information</a>
+</h3>
+<p>
+ OpenUP/Basic Plug-in Version 0.9<br />
+ Based on: Base Concepts Plug-in Version: 0.9
+</p>
+<h3>
+ Legal Statement
+</h3>
+<p class="node">
+ See <a href="./resources/copyrite.htm">Intellectual Property Notices</a>.
+</p>
+<h3>
+ Browser Support
+</h3>
+<p>
+ <b>Note 1:</b> OpenUP/Basic does not currently support Netscape Navigator 6.x.
+</p>
+<p>
+ <b>Note 2:</b> Some versions of Microsoft Internet Explorer 4.x and Netscape Navigator 4.x may not be able to display
+ all pages of OpenUP/Basic.
+</p><!-- END:mainDescription,-WFD3nKccpkueaG15cHT-fA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/copyright_oup.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/copyright_oup.html
new file mode 100644
index 0000000..09d44f6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/copyright_oup.html
@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\supportingmaterials\copyright_oup.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: copyright_oup.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-PZ0CqCcJHB-nbxs8fbP7bg CRC: 2189745471 --><p>
+ View copyright information here: <a class="elementLink"
+ href="./../../../openup_basic/guidances/supportingmaterials/openup_copyright,_UaGfECcTEduSX6N2jUafGA.html"
+ guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a>.
+</p><!-- END:mainDescription,-PZ0CqCcJHB-nbxs8fbP7bg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/delivery_process_graph.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/delivery_process_graph.html
new file mode 100644
index 0000000..cf75b5d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/delivery_process_graph.html
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\supportingmaterials\delivery_process_graph.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: delivery_process_graph.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Pt_fYBjoEduxUfEVCtmW4Q CRC: 3829670232 -->Delivery Process Graph<!-- END:presentationName,_Pt_fYBjoEduxUfEVCtmW4Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-cy0DcnEk7uJJ1OOH3_E6rg CRC: 3624835576 --><img height="192" alt="OpenUP/Basic Lifecycle" src="./resources/openup-basic_lifecycle.jpg" width="667" usemap="#Map"
+border="0" /> <map id="Map" name="Map">
+ <area shape="RECT" coords="116,7,175,25" alt="link to inception phase concept"
+ href="./../../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="255,11,327,27" alt="link to elaboration phase concept"
+ href="./../../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="395,11,476,27" alt="link to construction phase concept"
+ href="./../../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="554,10,619,27" alt="link to transition phase concept"
+ href="./../../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="39,98,100,162" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/inception_phase_iteration,_xupMvxOKEduCNqgZdt_OaA.html"
+ guid="_xupMvxOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="188,99,250,168" alt="link to elaboration phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="332,100,397,165" alt="link to construction phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="480,98,541,167" alt="link to transition phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/transition_phase_iteration,_467NIhOKEduCNqgZdt_OaA.html"
+ guid="_467NIhOKEduCNqgZdt_OaA" />
+</map><!-- END:mainDescription,-cy0DcnEk7uJJ1OOH3_E6rg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/openup_basic_home.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/openup_basic_home.html
new file mode 100644
index 0000000..9087a4b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/openup_basic_home.html
@@ -0,0 +1,171 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\supportingmaterials\openup_basic_home.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_home.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_i-BDsNogEdqfmNgIq7q3Xw CRC: 991700899 -->OpenUP/Basic<!-- END:presentationName,_i-BDsNogEdqfmNgIq7q3Xw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-XR2Rbg25yN80p1exWC4MHg CRC: 1945992895 --><table>
+ <tbody>
+ <tr>
+ <td>
+ <table width="100%" border="0">
+ <tbody>
+ <tr>
+ <td width="58%">
+ <div align="center">
+ <table width="589" align="center" border="0">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <img height="48" alt="getting started" src="./resources/GetStarted_48.gif" width="48" usemap="#Map" border="0" />
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <img height="48" alt="core principles" src="./resources/CorePrinciples_48.gif" width="48" usemap="#Map2" border="0" />
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <img height="48" alt="roles" src="./resources/Roles_48.gif" width="48" usemap="#Map3" border="0" />
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <img height="48" alt="work products" src="./resources/WorkProducts_48.gif" width="48" usemap="#Map4" border="0" />
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <img height="48" alt="disciplines" src="./resources/Disciplines_48.gif" width="48" usemap="#Map5" border="0" />
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <img height="48" alt="lifecycle" src="./resources/LifeCycle_48.gif" width="48" usemap="#Map6" border="0" />
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/customcategories/getting_started,_cp6ycBOGEduCNqgZdt_OaA.html" guid="_cp6ycBOGEduCNqgZdt_OaA">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" guid="_HEu9QBOHEduCNqgZdt_OaA">Core Principles</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html" guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html" guid="_s4Z9AMWXEdqWePvIjHInwg">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html" guid="__BZycP1UEdmek8CQTQgrOQ">Disciplines</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">Lifecycle</a>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <p>
+ OpenUP/Basic is organized into four major areas of content, Communication and Collaboration,
+ Intent, Solution, and Management, also known as sub-processes.
+ </p>
+ <br />
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ <img height="350" alt="Four major areas upon which the OpenUP/Basic content is organized" src="./resources/OpenUp1_350.jpg" width="350" usemap="#Map7" border="0" /> <map id="Map7" name="Map7">
+ <area shape="RECT" alt="Stakeholder" coords="144,5,207,62" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ" />
+ <area shape="POLY" alt="Tester" coords="336,242,310,287,254,256,278,209" href="./../../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw" />
+ <area shape="RECT" alt="Developer" coords="148,282,201,347" href="./../../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmd" />
+ <area shape="POLY" alt="Architect" coords="66,199,14,232,40,283,96,249" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Project Manager" coords="11,118,68,146,99,91,50,52" href="./../../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Analyst" coords="258,99,312,66,338,114,284,145" href="./../../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw" />
+ <area shape="CIRCLE" alt="Communication and Collaboration" coords="176,176,47" href="./../../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Management" coords="85,219,70,163,115,89,169,72,169,117,124,144,120,197" href="./../../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Intent" coords="181,116,223,143,229,196,264,219,283,160,245,94,181,70" href="./../../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Solution" coords="129,211,176,235,221,210,257,231,214,271,133,272,94,232" href="./../../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" />
+ </map><br />
+
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="left">
+ OpenUP/Basic is an iterative software development process with the following characteristics:
+ </p>
+ <div align="left">
+ <ul>
+ <li>
+ <strong>Minimal:</strong> Only fundamental process content is included
+ </li>
+ <li>
+ <strong>Complete:</strong> It can be manifested as an entire process to build a system
+ </li>
+ <li>
+ <strong>Extensible:</strong> It can be used as a foundation to add or tailor process
+ content
+ </li>
+ </ul>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ <map id="Map" name="Map">
+ <area shape="RECT" coords="0,1,47,47" alt="Getting Started" href="./../../../openup_basic/customcategories/getting_started,_cp6ycBOGEduCNqgZdt_OaA.html" />
+ </map><map id="Map2" name="Map2">
+ <area shape="RECT" coords="0,0,48,47" alt="Core principles" href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" />
+ </map><map id="Map3" name="Map3">
+ <area shape="RECT" coords="0,0,48,48" alt="Openup basic roles" href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html" />
+ </map><map id="Map4" name="Map4">
+ <area shape="RECT" coords="0,1,48,48" alt="Openup basic work product" href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html" />
+ </map><map id="Map5" name="Map5">
+ <area shape="RECT" coords="0,0,47,48" alt="Openup basic disciplines" href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html" />
+ </map><map id="Map6" name="Map6">
+ <area shape="RECT" coords="0,0,47,48" alt="Openup basic process" href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" />
+ </map>
+</p><!-- END:mainDescription,-XR2Rbg25yN80p1exWC4MHg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/openup_copyright.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/openup_copyright.html
new file mode 100644
index 0000000..1c87026
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/openup_copyright.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\supportingmaterials\openup_copyright.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_copyright.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_UaGfECcTEduSX6N2jUafGA CRC: 2035959685 -->OpenUP Copyright<!-- END:presentationName,_UaGfECcTEduSX6N2jUafGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_UaGfECcTEduSX6N2jUafGA CRC: 1386695868 -->OpenUP Copyright Information<!-- END:briefDescription,_UaGfECcTEduSX6N2jUafGA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-RNyaB6jxqoopm9fJU8k9vg CRC: 1000965452 --><p>
+ Copyright © 1987, 2006 IBM Corp. All Rights Reserved.<br />
+ Copyright © 2006 Telelogic AB. All Rights Reserved.<br />
+ Copyright © 2006 Armstrong Process Group, Inc. All Rights Reserved.<br />
+ Copyright © 2006 Number Six Software, Inc. All Rights Reserved.<br />
+</p>
+<p>
+ And others. All rights reserved
+</p><!-- END:mainDescription,-RNyaB6jxqoopm9fJU8k9vg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/references.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/references.html
new file mode 100644
index 0000000..b0ddaca
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/references.html
@@ -0,0 +1,239 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\supportingmaterials\references.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: references.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9ToeIB83Edqsvps02rpOOg CRC: 3494063692 -->References<!-- END:presentationName,_9ToeIB83Edqsvps02rpOOg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_9ToeIB83Edqsvps02rpOOg CRC: 2125815431 -->Additional references that may be useful, including books, method plug-ins, and commercial methodology products.<!-- END:briefDescription,_9ToeIB83Edqsvps02rpOOg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-aCI9T-9TIe8D35yXBU6qvg CRC: 3878684956 --><TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ADO03</a> </TD>
+<TD colSpan=2>Adolph, Bramble, Cockburn, and Pols <EM>Patterns for Effective Use Cases</EM>, Addison Wesley, 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ADO04</a> </TD>
+<TD colSpan=2>Adolph, Bramble, Cockburn, and Pols <EM>Tutorial 17: Patterns for Writing Effective Use Cases</EM>, presented at the 19th Annual Conference on Object-Oriented Programming, Systems, Languages and Applications, 2004.</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALE77</a> </TD>
+<TD colSpan=2>Alexander, C. <EM>A Pattern Language</EM>, Oxford University Press, 1977 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALE79</a> </TD>
+<TD colSpan=2>Alexander, C., <EM>A Timeless Way of Building</EM>, Oxford University Press, 1979 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALL02</a> </TD>
+<TD colSpan=2>Allamaraju, S. <EM>Architecture Paradox</EM>, <a href="http://www.sei.cmu.edu/architecture/essays.html">http://www.sei.cmu.edu/architecture/essays.html</a>. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALU03</a> </TD>
+<TD colSpan=2>
+<P>Alur, D., Crupi, J., Malks, D., <EM>Core J2EE Patterns: Best Practices and Design Strategies</EM>, Prentice Hall/Sun Press, 2001.</P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P>AMB02</P>
+<P>AMB03</P>
+<P>AMB04</P>
+<P>AMB06</P>
+<P><a name="">BOE88</a> </P></TD>
+<TD colSpan=2>
+<P>Ambler, S.W. <EM>Agile Modeling: Effective Practices for Extreme Programming and Unified Process</EM>. Wiley Publishing, 2002.</P>
+<P>Ambler, S.W. <EM>Agile Database Techniques: Effective Strategies for the Agile Software Developer</EM>. Wiley Publishing, 2003.</P>
+<P>Ambler, S.W. <EM>The Object Primer 3rd Edition: Agile Model Driven Development with UML 2</EM>. Cambridge University Press, 2004.</P>
+<P>Ambler, S.W. and Sadalage, P.J. <EM>Refactoring Databases: Evolutionary Database Design</EM>. Addison Wesley, 2006.</P>
+<P>Boehm, B., Papaccio, C. <EM>Understanding and Controlling Software Cost</EM>, IEEE Trans. on Software Engineering, Oct. 1988. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BOE95</a> </TD>
+<TD colSpan=2>Boehm, B. <EM>Anchoring the Software Process</EM>, <a href="http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf">http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P>BRO95</P></TD>
+<TD colSpan=2>
+<P>Brooks, F.P <EM>The Mythical Man Month: Essays on Software Engineering, 20th Anniversary Edition</EM>. Addison Wesley Professional, 1995. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BOO05</a> </TD>
+<TD colSpan=2>Booch, G., Rumbaugh, J., Jacobson, I.<EM>The Unified Modeling Language User Guide</EM>, Addison-Wesley Professional, 2005</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BUS96</a> </TD>
+<TD colSpan=2>Buschmann, F., Meunier, R., Rohnert, H.,Sommerlad, P., Stal, M., <EM>Pattern-Oriented Software Architecture -- A System of Patterns</EM>, Wiley, 1996. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P><a name="">COH05</a> </P>
+<P><a name="">COP95</a> </P></TD>
+<TD colSpan=2>
+<P>Cohn, M. <EM>Agile Estimation and Planning</EM>, Addison Wesley Longman, 2005 </P>Coplien, J., Schmidt, D., <EM>Pattern Languages of Program Design</EM>,Addison-Wesley Professional, 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">COP95</a> </TD>
+<TD colSpan=2>Coplien, J., Schmidt, D., <EM>Pattern Languages of Program Design</EM>,Addison-Wesley Professional, 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">CRO79</a> </TD>
+<TD colSpan=2>Crosby, Philip. <EM>Quality is Free: The Art of Making Quality Certain</EM>, McGraw-Hill, 1979. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAM95</a> </TD>
+<TD colSpan=2>Gamma, E., Helm, R., Johnson, R., Vlissides, J., <EM>Design Patterns: Elements of Reusable Object-Oriented Software</EM>, Addison-Wesley Professional; 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAB98</a> </TD>
+<TD colSpan=2>Gabriel, Richard P., <EM>Patterns of Software: Tales from the Software Community</EM>, Oxford University Press, 1998. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAR93</a> </TD>
+<TD colSpan=2>David Garlan and Mary Shaw. <EM>An Introduction to Software Architecture</EM>, SEI Technical Report CMU/SEI-94-TR-21. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">HIC03</a> </TD>
+<TD colSpan=2>Hickey A., Davis, A. <EM>Elicitation Technique Selection: How Do the Experts Do It?</EM>, International Conference on Requirements Engineering (RE03), Los Alamitos, California: IEEE Computer Society Press, September 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">HUL05</a> </TD>
+<TD colSpan=2>Hull, E., Jackson, K. and Dick, J. <EM>Requirements Engineering</EM>, Second Edition. Springer, 2005. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">IEP1471</a> </TD>
+<TD colSpan=2>IEEE <EM>Recommended Practice for Architectural Description</EM>, IEEE Std P1471, 2000.</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KAZ00</a> </TD>
+<TD colSpan=2>Kazman, R., Carriere, S. J., Woods, S. G. <a href="http://www.sei.cmu.edu/staff/rkazman/annals-scenario.pdf">Toward a Discipline of Scenario-Based Architectural Engineering</a>,(Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) <a href="http://manta.cs.vt.edu./ase/">Annals of Software Engineering</a>, Vol. 9, 2000, 5-33. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KAZ04</a> </TD>
+<TD colSpan=2>Kazman, R., Kruchten, P., Nord, R., Tomayko, J. <EM>Integrating Software-Architecture-Centric Methods into the Rational Unified Process</EM>, CMU-SEI Technical Reports, 2004. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KRO03</a> </TD>
+<TD colSpan=2>Kroll, P. and Kruchten, P. <EM>The Rational Unified Process Made Easy</EM>, Addison Wesley, 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">KRO05 </TD>
+<TD colSpan=2>Kroll, P. and MacIsaac, B. <EM>Agility and Discipline Made Easy</EM>, Addison Wesley, 2005. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KRU95</a> </TD>
+<TD colSpan=2>Kruchten, Phillipe B., <EM>The 4+1 View Model of Architecture</EM>, IEEE Software, vol. 12, no. 6, pp 42-50, November 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">MAR03</a> </TD>
+<TD colSpan=2>Marick, B., <EM>Exploration Through Example</EM>, <a href="http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1">http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1</a></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">NBG01</a> </TD>
+<TD colSpan=2>Eric J. Naiburg and Robert A. Maksimchuk. <EM>UML for Database Design</EM>, New York, NY: Addison Wesley, 2001</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">RUP06</a> </TD>
+<TD colSpan=2>IBM Rational 2006. <EM>The Rational Unified Process.</EM> </TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">A commercial methodology, also based on the Eclipse Process Framework, and advanced guidance on topics such as business modeling, portfolio management, asset-based development, real-time design, user experience, and so on. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">OOP96</a> </TD>
+<TD colSpan=2>The 1996 ACM Conference on Object-Oriented Programs, Systems, Languages and Applications (OOPSLA), <EM>The Origins of Pattern Theory, the Future of the Theory, And The Generation of a Living World.</EM></TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">See <a href="http://www.patternlanguage.com/archive/ieee/ieeetext.htm" target="">http://www.patternlanguage.com/archive/ieee/ieeetext.htm</a></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">PW92</a> </TD>
+<TD colSpan=2>Dewayne E. Perry and Alexander L. Wolf. <EM>Foundations for the Study of Software Architecture</EM>. ACM SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992.</TD></TR>
+<TR>
+<TD vAlign=top width="12%"><a name="">SCH04</a> </TD>
+<TD colSpan=2>Schwaber, K. <EM>Agile Project Management with Scrum.</EM> Microsoft Press 2004. </TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">
+<P>An excellent reference by one of the co-inventors of the Scrum project management method. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0 <table >>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">SEI99</a> </TD>
+<TD colSpan=2>SEI, 1999. <EM>Software Risk Evaluation (SRE) Method Description, v2.0.</EM> <BR><a href="http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf#search=%22software%20risk%20evaluation%22">http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf#search=%22software%20risk%20evaluation%22</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.)</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">TEL06</a> </TD>
+<TD colSpan=2>Telelogic, 2006. <EM>Get It Right the First Time: Writing Better Requirements.</EM> </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">THA00</a> </TD>
+<TD colSpan=2>Thayer, Richard H. and Dorfman, Merlin <EM>Software Requirements Engineering Second Edition</EM>, IEEE Computer Society, 2000 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">UML05</a> </TD>
+<TD colSpan=2>OMG, 2005. <EM>Unified Modeling Language 2.0: Superstructure.</EM> <BR><a href="http://www.omg.org/docs/formal/05-07-04.pdf" target="">http://www.omg.org/docs/formal/05-07-04.pdf</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) </TD></TR></TBODY>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">WIB04</a> </TD>
+<TD colSpan=2>Wiborg-Weber, D., Vignaud, J. L. <EM>A Framework for Managing Component Based Development</EM>, Telelogic Whitepaper, 2004 <BR><a href="http://www.telelogic.com/download/index.cfm?id=4423" target="">http://www.telelogic.com/download/index.cfm?id=4423</a></TD></TR></TBODY>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">WIKP-MVC</a> </TD>
+<TD colSpan=2>Wikipedia <EM>Model-view-controller</EM> <BR><a href="http://en.wikipedia.org/wiki/Model-view-controller" target="">http://en.wikipedia.org/wiki/Model-view-controller</a> </TD></TR></TBODY></TABLE><!-- END:mainDescription,-aCI9T-9TIe8D35yXBU6qvg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif
new file mode 100644
index 0000000..da5215c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif
new file mode 100644
index 0000000..36f36b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif
new file mode 100644
index 0000000..5839c94
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif
new file mode 100644
index 0000000..f7f4665
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg
new file mode 100644
index 0000000..0bb0b38
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif
new file mode 100644
index 0000000..3fb662d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif
new file mode 100644
index 0000000..9554964
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/copyrite.htm b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/copyrite.htm
new file mode 100644
index 0000000..51edd3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/copyrite.htm
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>IBM(R) Rational(R) Intellectual Property Notices and Other Licensing Requirements</title>
+</head>
+
+<body>
+NOTICES AND INFORMATION <br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+About This Content
+</p>
+<p>
+May 2, 2006
+</p>
+<p>
+License
+</p>
+<p>
+The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
+</p>
+<p>
+If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributors license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
+ <br>
+</BODY>
+</HTML>
\ No newline at end of file
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg
new file mode 100644
index 0000000..4719cad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/architecture.html
new file mode 100644
index 0000000..44c5fb5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/architecture.html
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__JXkoCk8EduLGM8dfVsrKg CRC: 1822983426 -->Architecture<!-- END:presentationName,__JXkoCk8EduLGM8dfVsrKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,__JXkoCk8EduLGM8dfVsrKg CRC: 2701263748 -->Templates for representing the architecture work product.<!-- END:briefDescription,__JXkoCk8EduLGM8dfVsrKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-1Lm8-0FY-QIC56u5t2SC9w CRC: 2598173112 --><p>
+ Here are some templates for representing the architecture. Architecture can be represented in a variety of ways,
+ according to the needs of the project team. See <a class="elementLink"
+ href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture</a> for more information.
+</p>
+<p>
+ Feel free to use one or more of these templates or create your own.
+</p>
+<p>
+ The <a class="elementLink" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> should decide what views are useful for describing the system under
+ consideration.
+</p>
+<p>
+ Consider one or more relevant views of the architecture and document each one using the provided template for the
+ architectural view. If needed, document information that applies to more than one view using the template provided for
+ the Software Architecture Document to get an integrated representation of the architecture instead of just snapshots
+ taken from different angles.
+</p>
+<p>
+ The structuring of the documents must support the needs of the intended audience. For example, instead of a document
+ for the implementation view developers may find more useful alternative forms for the project directory structure like
+ the template provided for the project startup kit.
+</p>
+<p>
+ Keep documentation up-to-date but to an essential minimum. When the architecture is under development, decisions are
+ reconsidered frequently so constant revision of the documentation is an unnecessary expense. Determine points in
+ the development lifecycle when documentation should be updated.
+</p><!-- END:mainDescription,-1Lm8-0FY-QIC56u5t2SC9w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/iteration_plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/iteration_plan.html
new file mode 100644
index 0000000..2404f05
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/iteration_plan.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\iteration_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0dBoQMlgEdmt3adZL5Dmdw CRC: 3699738420 -->Iteration Plan<!-- END:presentationName,_0dBoQMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0dBoQMlgEdmt3adZL5Dmdw CRC: 1123118651 -->This is the informal template suggested for an iteration plan.<!-- END:briefDescription,_0dBoQMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/project_plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/project_plan.html
new file mode 100644
index 0000000..c9f08e1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/project_plan.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\project_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0c7hoMlgEdmt3adZL5Dmdw CRC: 659198141 -->Project Plan<!-- END:presentationName,_0c7hoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0c7hoMlgEdmt3adZL5Dmdw CRC: 447316026 -->This is the informal template for representing the project plan.<!-- END:briefDescription,_0c7hoMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/iteration_plan.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/iteration_plan.dot
new file mode 100644
index 0000000..0c5aa32
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/iteration_plan.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/project_plan.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/project_plan.dot
new file mode 100644
index 0000000..7d0f02b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/project_plan.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/project_startup_kit.zip b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/project_startup_kit.zip
new file mode 100644
index 0000000..01f305a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/project_startup_kit.zip
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/risk_list.xls b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/risk_list.xls
new file mode 100644
index 0000000..e3970a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/risk_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/software_arch_document.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/software_arch_document.dot
new file mode 100644
index 0000000..e13bc09
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/software_arch_document.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/status_assessment.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/status_assessment.dot
new file mode 100644
index 0000000..02c5cd1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/status_assessment.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/supporting_req_spec.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/supporting_req_spec.dot
new file mode 100644
index 0000000..3baaa46
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/supporting_req_spec.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot
new file mode 100644
index 0000000..1839b44
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot
new file mode 100644
index 0000000..5a9581f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/test_case.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/test_case.dot
new file mode 100644
index 0000000..2395e41
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/test_case.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/uc_specification.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/uc_specification.dot
new file mode 100644
index 0000000..fdcd90c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/uc_specification.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/vision.dot b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/vision.dot
new file mode 100644
index 0000000..9628c3b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/vision.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/work_items_list.xls b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/work_items_list.xls
new file mode 100644
index 0000000..9f0b462
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/resources/work_items_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/risk_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/risk_list.html
new file mode 100644
index 0000000..7f30dd9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/risk_list.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\risk_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: risk_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MIUO0C8FEduzydamRseoUw CRC: 3469038815 -->Risk List<!-- END:presentationName,_MIUO0C8FEduzydamRseoUw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_MIUO0C8FEduzydamRseoUw CRC: 3678946493 -->A list or table containing risk attributes. As it is usual to rank risks by priority, spreadsheets may be an alternative to capture risks<!-- END:briefDescription,_MIUO0C8FEduzydamRseoUw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/software_arch_document.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/software_arch_document.html
new file mode 100644
index 0000000..8114355
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/software_arch_document.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\software_arch_document.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: software_arch_document.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0dN1gMlgEdmt3adZL5Dmdw CRC: 221099149 -->Software Architecture Document<!-- END:presentationName,_0dN1gMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0dN1gMlgEdmt3adZL5Dmdw CRC: 3017668450 -->This is the informal template suggested for representing architecture.<!-- END:briefDescription,_0dN1gMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/status_assessment.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/status_assessment.html
new file mode 100644
index 0000000..f5a0f5b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/status_assessment.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\status_assessment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: status_assessment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_1awLIEp2Edup0IY9DKDPkg CRC: 4196749033 -->Status Assessment<!-- END:presentationName,_1awLIEp2Edup0IY9DKDPkg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_1awLIEp2Edup0IY9DKDPkg CRC: 3574469558 -->This is the informal template suggested for capturing and communicating the results of iteration assessments.<!-- END:briefDescription,_1awLIEp2Edup0IY9DKDPkg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/supporting_requirements_spec.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/supporting_requirements_spec.html
new file mode 100644
index 0000000..ca024fe
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/supporting_requirements_spec.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\supporting_requirements_spec.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirements_spec.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ItYXcNa9Edqrw4BYKyYKiA CRC: 965547734 -->Supporting Requirements Specification<!-- END:presentationName,_ItYXcNa9Edqrw4BYKyYKiA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ItYXcNa9Edqrw4BYKyYKiA CRC: 3018347072 -->This is the template suggested for specifying requirements and constraints in accordance with the FURPS+ classification.<!-- END:briefDescription,_ItYXcNa9Edqrw4BYKyYKiA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-FsyxZy4tyX8k5CxT5Jww_w CRC: 2054300789 -->This template provides a starting point for capturing supporting requirement in a consistent manner and to provide a
+useful checklist when determining the types of requirements that may apply. It is not expected that one would
+complete every section of this template in all circumstances. Tailor as you see fit for your particular
+circumstances.<!-- END:mainDescription,-FsyxZy4tyX8k5CxT5Jww_w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/test_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/test_case.html
new file mode 100644
index 0000000..886967b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/test_case.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\test_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0dT8IMlgEdmt3adZL5Dmdw CRC: 607185224 -->Test Case<!-- END:presentationName,_0dT8IMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0dT8IMlgEdmt3adZL5Dmdw CRC: 1029022586 -->This is the informal template suggested for representing test cases.<!-- END:briefDescription,_0dT8IMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/uc_specification.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/uc_specification.html
new file mode 100644
index 0000000..6bcf807
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/uc_specification.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\uc_specification.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uc_specification.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0cpNwMlgEdmt3adZL5Dmdw CRC: 2598744912 -->Use-Case Specification<!-- END:presentationName,_0cpNwMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0cpNwMlgEdmt3adZL5Dmdw CRC: 3684507779 -->This is the informal template suggested for representing a use case specification.<!-- END:briefDescription,_0cpNwMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/vision.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/vision.html
new file mode 100644
index 0000000..980e63a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/vision.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0cW54MlgEdmt3adZL5Dmdw CRC: 2312412063 -->Vision<!-- END:presentationName,_0cW54MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0cW54MlgEdmt3adZL5Dmdw CRC: 1646739882 -->This is the informal template suggested for representing the Vision document.<!-- END:briefDescription,_0cW54MlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/work_items_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/work_items_list.html
new file mode 100644
index 0000000..e2255e3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/templates/work_items_list.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\templates\work_items_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_items_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_QwUJYDg0Edu4E8ZdmlYjtA CRC: 699774998 -->Work Items List<!-- END:presentationName,_QwUJYDg0Edu4E8ZdmlYjtA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_QwUJYDg0Edu4E8ZdmlYjtA CRC: 3486649596 -->This is a spreadsheet suggested for representing a work items list. Alternative templates would be usage of a specific tool or database with similar information.<!-- END:briefDescription,_QwUJYDg0Edu4E8ZdmlYjtA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/actor.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/actor.html
new file mode 100644
index 0000000..72e10f8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/actor.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\actor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: actor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZsK30EvBEdunZcj9T5hrMQ CRC: 1148540665 -->actor<!-- END:presentationName,_ZsK30EvBEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-4RQJzq_1URTZ5FGCBKnTIw CRC: 2546156017 -->Someone or something, outside the system that interacts with the system.<!-- END:mainDescription,-4RQJzq_1URTZ5FGCBKnTIw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/agile.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/agile.html
new file mode 100644
index 0000000..7d07b91
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/agile.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\agile.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: agile.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3PJ38EvqEdunZcj9T5hrMQ CRC: 1998006153 -->agile<!-- END:presentationName,_3PJ38EvqEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qZE4XgeMK93LmJMKuQWGFg CRC: 1016987815 -->A set of values and principles for software development that use lean production techniques to deliver value to
+stakeholders quickly and frequently.<!-- END:mainDescription,-qZE4XgeMK93LmJMKuQWGFg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/analyst.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/analyst.html
new file mode 100644
index 0000000..87fb2f4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/analyst.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\analyst.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analyst.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_GEAwAEvCEdunZcj9T5hrMQ CRC: 1605053580 -->analyst<!-- END:presentationName,_GEAwAEvCEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-1RwpgmmY974S0YkxEOFDCw CRC: 1136765981 -->Role representing customer and end-user concerns<!-- END:mainDescription,-1RwpgmmY974S0YkxEOFDCw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architect.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architect.html
new file mode 100644
index 0000000..7d4fd50
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architect.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\architect.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architect.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wI3R4EvCEdunZcj9T5hrMQ CRC: 977693334 -->architect<!-- END:presentationName,_wI3R4EvCEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-2QB1bosN011CudkwZ0cn-g CRC: 3120439180 -->Role representing someone responsible for designing the software architecture, which includes making the key technical
+decisions that constrain the overall design and implementation of the project<!-- END:mainDescription,-2QB1bosN011CudkwZ0cn-g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architectural_mechanism.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architectural_mechanism.html
new file mode 100644
index 0000000..3db0035
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architectural_mechanism.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\architectural_mechanism.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architectural_mechanism.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VHFGkEvCEdunZcj9T5hrMQ CRC: 1016554436 -->architectural mechanisms<!-- END:presentationName,_VHFGkEvCEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Vvwb6EupIB9kfSQ_mhjURA CRC: 1056731299 -->Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of
+structure, patterns of behavior, or both.<!-- END:mainDescription,-Vvwb6EupIB9kfSQ_mhjURA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architectural_view.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architectural_view.html
new file mode 100644
index 0000000..684e7ac
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architectural_view.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\architectural_view.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architectural_view.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_n7GmQEvCEdunZcj9T5hrMQ CRC: 2220438640 -->architectural view<!-- END:presentationName,_n7GmQEvCEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-0vih7gB84YYDheaH7jeYFQ CRC: 3873587048 -->A view of the architecture from a given perspective.<!-- END:mainDescription,-0vih7gB84YYDheaH7jeYFQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architecture.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architecture.html
new file mode 100644
index 0000000..8f038da
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/architecture.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\architecture.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architecture.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_siyjEEvCEdunZcj9T5hrMQ CRC: 1956208378 -->architecture<!-- END:presentationName,_siyjEEvCEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-YMvJ5LwexkcVWWqLdm5-nQ CRC: 3740406261 -->Describes the blueprint for software development, frequently represented using a number of architectural views. It also
+contains the rationale, assumptions, explanations and implications of the decisions that where made in forming the
+architecture as well as the global mapping between views<!-- END:mainDescription,-YMvJ5LwexkcVWWqLdm5-nQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/build.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/build.html
new file mode 100644
index 0000000..bdb8374
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/build.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\build.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: build.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Z-AukEvpEdunZcj9T5hrMQ CRC: 3181441755 -->build<!-- END:presentationName,_Z-AukEvpEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Wh-byAGHoy_gGry0Jq6VaA CRC: 3760122732 -->An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the
+final product<!-- END:mainDescription,-Wh-byAGHoy_gGry0Jq6VaA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/business_rule.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/business_rule.html
new file mode 100644
index 0000000..c98839c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/business_rule.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\business_rule.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: business_rule.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NtGL0EvDEdunZcj9T5hrMQ CRC: 1841420767 -->business rule<!-- END:presentationName,_NtGL0EvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-COrjB4k8Qtf6ZpPEcBNwpw CRC: 2985293454 -->A declaration of policy or condition that must be satisfied by the system under consideration. For more information see
+Supporting Requirements<!-- END:mainDescription,-COrjB4k8Qtf6ZpPEcBNwpw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/code_instrumentation.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/code_instrumentation.html
new file mode 100644
index 0000000..0311225
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/code_instrumentation.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\code_instrumentation.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: code_instrumentation.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_JiqnEJt1EdutoZjlV3a4Lg CRC: 2640842355 -->Code Instrumentation<!-- END:presentationName,_JiqnEJt1EdutoZjlV3a4Lg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-RlYzPnl6Pig2H851hHebBA CRC: 4232423360 --><p>
+ "Extra" statements added to source code for the purposes of testing, debugging, tuning, or tracing.
+</p><!-- END:mainDescription,-RlYzPnl6Pig2H851hHebBA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/component.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/component.html
new file mode 100644
index 0000000..a3edf98
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/component.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\component.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: component.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d82_AEvDEdunZcj9T5hrMQ CRC: 1241424215 -->component<!-- END:presentationName,_d82_AEvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-BWZsh3vKrqSOzfkBJmDTLA CRC: 323336582 -->A nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined
+architecture. A component conforms to and provides the realization of a set of interfaces<!-- END:mainDescription,-BWZsh3vKrqSOzfkBJmDTLA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/configuration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/configuration.html
new file mode 100644
index 0000000..8299c72
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/configuration.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\configuration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: configuration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,__Cw30ElxEducWJcS4yanqg CRC: 2783094231 -->configuration<!-- END:presentationName,__Cw30ElxEducWJcS4yanqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-VPoMu7qzVX9grE4-nB3kMw CRC: 2493176294 -->The performance, functional, and physical attributes of an existing or planned product, or a combination of products.<!-- END:mainDescription,-VPoMu7qzVX9grE4-nB3kMw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/construction.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/construction.html
new file mode 100644
index 0000000..682bd75
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/construction.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\construction.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: construction.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0sD60EvDEdunZcj9T5hrMQ CRC: 3298834838 -->Construction<!-- END:presentationName,_0sD60EvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-5wJmUR0WqX7lCIxsyqFsdA CRC: 2798511671 -->The third phase of the OpenUP/ Basic project lifecycle, in which the software is brought from an executable architectural
+baseline to the point at which it is ready to be transitioned to the user community.<!-- END:mainDescription,-5wJmUR0WqX7lCIxsyqFsdA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/developer.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/developer.html
new file mode 100644
index 0000000..228a7eb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/developer.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\developer.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: developer.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-61a8EvOEdunZcj9T5hrMQ CRC: 1710984090 -->developer<!-- END:presentationName,_-61a8EvOEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-802sCZ4lJcejyRbhLmkxkw CRC: 105044977 -->Role representing someone responsible for developing a part of the system, including designing it to fit into the
+architecture, and then implementing, unit-testing, and integrating the components that are part of the solution.<!-- END:mainDescription,-802sCZ4lJcejyRbhLmkxkw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/effort.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/effort.html
new file mode 100644
index 0000000..233f89e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/effort.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\effort.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: effort.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_nJSDwEvuEdunZcj9T5hrMQ CRC: 3895342900 -->effort<!-- END:presentationName,_nJSDwEvuEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-WIgtkwJN71D51FdcQs-TzQ CRC: 1209583469 --><p>
+ Indicates how long it will take the team member(s) assigned to the work item to do the work. Typically uses the units
+ of Actual Days or Actual Hours
+</p><!-- END:mainDescription,-WIgtkwJN71D51FdcQs-TzQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/elaboration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/elaboration.html
new file mode 100644
index 0000000..6dccf91
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/elaboration.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\elaboration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: elaboration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8DkT4EvDEdunZcj9T5hrMQ CRC: 2867323126 -->Elaboration<!-- END:presentationName,_8DkT4EvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-0g2jTHQla8lbP6xGB3iGlg CRC: 3426159571 -->Second of four phases in the in the OpenUP/ Basic project lifecycle, when architecturally-significant risks are addressed<!-- END:mainDescription,-0g2jTHQla8lbP6xGB3iGlg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/feature.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/feature.html
new file mode 100644
index 0000000..2100034
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/feature.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\feature.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: feature.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PgYREAeYEduWycDgioo5rg CRC: 3496627450 -->Feature<!-- END:presentationName,_PgYREAeYEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qpBnpWqiD7gjT08LjTMbsQ CRC: 229890744 -->An externally observable service provided by the system that directly fulfills
+a <a class="elementLink"
+href="./../../../openup_basic/guidances/termdefinitions/stakeholder_need,_WUiFcAeYEduWycDgioo5rg.html"
+guid="_WUiFcAeYEduWycDgioo5rg">Stakeholder Need</a> .<!-- END:mainDescription,-qpBnpWqiD7gjT08LjTMbsQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/furps.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/furps.html
new file mode 100644
index 0000000..142bb1f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/furps.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\furps.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: furps.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZH6M0EvEEdunZcj9T5hrMQ CRC: 2829194791 -->FURPS+<!-- END:presentationName,_ZH6M0EvEEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-vq2pL6yQuqGhql9Wo_Av4w CRC: 91292186 -->Functional, usability, reliability, performance, supportability + others. This acronym represents categories that can be
+used in the definition of product requirements. For more information see Supporting Requirements<!-- END:mainDescription,-vq2pL6yQuqGhql9Wo_Av4w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/glossary.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/glossary.html
new file mode 100644
index 0000000..6191070
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/glossary.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\glossary.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: glossary.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_VhhDMEvrEdunZcj9T5hrMQ CRC: 2961509187 -->glossary<!-- END:presentationName,_VhhDMEvrEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-05pn_DGdNui9qqwx46iKZQ CRC: 1858786553 -->An artifact in OpenUP that defines the vocabulary and other important terms that are part of a project and the problem
+domain.<!-- END:mainDescription,-05pn_DGdNui9qqwx46iKZQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/inception.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/inception.html
new file mode 100644
index 0000000..b893b0a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/inception.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\inception.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: inception.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_525A8EvDEdunZcj9T5hrMQ CRC: 2715338614 -->Inception<!-- END:presentationName,_525A8EvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dhgOQQ4GsV0-dNJmTmF9GA CRC: 2033049533 -->First of the four phases in the OpenUP/ Basic project lifecycle, it is about understanding the project scope and objectives
+and getting enough information to confirm that the project should proceed or not.<!-- END:mainDescription,-dhgOQQ4GsV0-dNJmTmF9GA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/ioc_milestone.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/ioc_milestone.html
new file mode 100644
index 0000000..25cd500
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/ioc_milestone.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\ioc_milestone.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: ioc_milestone.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_O7JBYEvFEdunZcj9T5hrMQ CRC: 2167702653 -->Initial Operational Capability Milestone.<!-- END:presentationName,_O7JBYEvFEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-gEgZg2UkFLjGeXkJLpAP6A CRC: 3521770506 -->At the end of Construction phase is the third important project milestone.<!-- END:mainDescription,-gEgZg2UkFLjGeXkJLpAP6A -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/iteration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/iteration.html
new file mode 100644
index 0000000..893fc2d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/iteration.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\iteration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZBUnMEvFEdunZcj9T5hrMQ CRC: 4006727965 -->iteration<!-- END:presentationName,_ZBUnMEvFEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_G0VvVOdMoajk615LwFtxg CRC: 2879671434 -->Short and time-boxed division of a project. Iterations allow to demonstrate incremental value and obtain early and
+continuous feedback<!-- END:mainDescription,-_G0VvVOdMoajk615LwFtxg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/iteration_burndown.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/iteration_burndown.html
new file mode 100644
index 0000000..e3c73b2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/iteration_burndown.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\iteration_burndown.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration_burndown.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8b20EEvvEdunZcj9T5hrMQ CRC: 2750891297 -->iteration burndown<!-- END:presentationName,_8b20EEvvEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-3G3HV0opAmFWGxYgsD5AhA CRC: 3616990335 -->A primary tool for understanding the status of an iteration. It shows the trend for how much work is left to do within
+that iteration.<!-- END:mainDescription,-3G3HV0opAmFWGxYgsD5AhA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/lca_milestone.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/lca_milestone.html
new file mode 100644
index 0000000..881dfd1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/lca_milestone.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\lca_milestone.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: lca_milestone.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NL4DMEvFEdunZcj9T5hrMQ CRC: 3153209871 -->Lifecycle Architecture Milestone<!-- END:presentationName,_NL4DMEvFEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-MllWL01NL93RTB7VsY69fw CRC: 54264259 -->At the end of the Elaboration phase is the second important project milestone<!-- END:mainDescription,-MllWL01NL93RTB7VsY69fw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/lco_milestone.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/lco_milestone.html
new file mode 100644
index 0000000..2b9bb45
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/lco_milestone.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\lco_milestone.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: lco_milestone.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_LGRBkEvFEdunZcj9T5hrMQ CRC: 3130156852 -->Lifecycle Objectives Milestone<!-- END:presentationName,_LGRBkEvFEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Rl8kaRW9Bxqdvq32kVCi7w CRC: 1862721127 -->At the end of the Inception phase is the first major project milestone<!-- END:mainDescription,-Rl8kaRW9Bxqdvq32kVCi7w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/milestone.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/milestone.html
new file mode 100644
index 0000000..1f68e19
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/milestone.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\milestone.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: milestone.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ByXNcEvqEdunZcj9T5hrMQ CRC: 1336705922 -->milestone<!-- END:presentationName,_ByXNcEvqEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-9fXEOvMc4t7y6s5GscBD1Q CRC: 3232187758 --><p>
+ The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready
+ to move to the next iteration or phase.
+</p><!-- END:mainDescription,-9fXEOvMc4t7y6s5GscBD1Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/pattern.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/pattern.html
new file mode 100644
index 0000000..6cd8203
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/pattern.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\pattern.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: pattern.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ctrEgEvCEdunZcj9T5hrMQ CRC: 2747071630 -->pattern<!-- END:presentationName,_ctrEgEvCEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-VJBtRm2brEKpRlnLWNF8_g CRC: 2345884366 -->Generalized solutions that can be implemented and applied in a problem situation (a context)<!-- END:mainDescription,-VJBtRm2brEKpRlnLWNF8_g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/point.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/point.html
new file mode 100644
index 0000000..3dd48d6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/point.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\point.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: point.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MvOuAEvGEdunZcj9T5hrMQ CRC: 3081106212 -->point<!-- END:presentationName,_MvOuAEvGEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-oShmMITo9RIi1AzACWI9vw CRC: 1811025878 -->A relative measure of size is typically used for Agile estimation<!-- END:mainDescription,-oShmMITo9RIi1AzACWI9vw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/pr_milestone.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/pr_milestone.html
new file mode 100644
index 0000000..67d1aa6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/pr_milestone.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\pr_milestone.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: pr_milestone.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_QuywUEvFEdunZcj9T5hrMQ CRC: 3857641588 -->Product Release Milestone<!-- END:presentationName,_QuywUEvFEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-JegYQHIteCRN0iV2EKMjSA CRC: 2953976012 -->At the end of the Transition phase is the last major project milestone<!-- END:mainDescription,-JegYQHIteCRN0iV2EKMjSA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/project_burndown.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/project_burndown.html
new file mode 100644
index 0000000..411a3e1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/project_burndown.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\project_burndown.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_burndown.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eX0YsEvvEdunZcj9T5hrMQ CRC: 112929341 -->project burndown<!-- END:presentationName,_eX0YsEvvEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-NNByAM5YsjCu39flaOSZtQ CRC: 2019164038 -->A chart consisting of two perspectives, the horizontal axis showing the iterations and the vertical axis indicating the
+remaining points from the work items list.<!-- END:mainDescription,-NNByAM5YsjCu39flaOSZtQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/requirement.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/requirement.html
new file mode 100644
index 0000000..10975f4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/requirement.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\requirement.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: requirement.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_feKVQLULEdqI644ssJaKYg CRC: 1754233426 -->Requirements<!-- END:presentationName,_feKVQLULEdqI644ssJaKYg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-0sCBiohjw_wBDKk0WEeDJQ CRC: 4045824488 --><ol>
+ <li>
+ A capability needed by the user to solve a problem [in order to] to achieve an objective
+ </li>
+ <li>
+ A capability that must be met or possessed by a system or system component to satisfy a contract, standard,
+ specification, or other formally imposed documentation <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[THA00]</a><br />
+ </li>
+</ol><!-- END:mainDescription,-0sCBiohjw_wBDKk0WEeDJQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/risk.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/risk.html
new file mode 100644
index 0000000..ddcb4ef
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/risk.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\risk.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: risk.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ii2LUEvGEdunZcj9T5hrMQ CRC: 2030490945 -->risk<!-- END:presentationName,_ii2LUEvGEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-hOtatvr8wIjqW8UD0MSGhQ CRC: 4089993765 -->A condition that can potentially affect, prevent, or limit a project's success. Project risks may be seen as threats or
+opportunities<!-- END:mainDescription,-hOtatvr8wIjqW8UD0MSGhQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/scope.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/scope.html
new file mode 100644
index 0000000..70c6c90
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/scope.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\scope.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: scope.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_t7JOkEvtEdunZcj9T5hrMQ CRC: 11490771 -->scope<!-- END:presentationName,_t7JOkEvtEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-h1poMaxtQbmg6hD5772oVw CRC: 611825758 -->A description of the breadth of a system's behavior, specifying the boundaries of the problem domain or system.<!-- END:mainDescription,-h1poMaxtQbmg6hD5772oVw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/stakeholder_need.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/stakeholder_need.html
new file mode 100644
index 0000000..5cdefd3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/stakeholder_need.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\stakeholder_need.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: stakeholder_need.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_WUiFcAeYEduWycDgioo5rg CRC: 3560542253 -->Stakeholder Need<!-- END:presentationName,_WUiFcAeYEduWycDgioo5rg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-1pmL5bC27rtWB84PXAgq9Q CRC: 2250725666 -->The business or operational problem (opportunity) that must be fulfilled to justify
+purchase or use of the system.<!-- END:mainDescription,-1pmL5bC27rtWB84PXAgq9Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/supporting_requirement.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/supporting_requirement.html
new file mode 100644
index 0000000..1a94e1a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/supporting_requirement.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\supporting_requirement.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirement.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_U_olUEvDEdunZcj9T5hrMQ CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_U_olUEvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-ketzwgDgY82DMyfuHqu3Cw CRC: 4157133330 -->Supporting requirements are requirements that define necessary system quality attributes such as performance,
+usability and reliability, as well as global functional requirements that are not captured in behavioral requirements
+artifacts such as use-cases.<!-- END:mainDescription,-ketzwgDgY82DMyfuHqu3Cw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/test_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/test_case.html
new file mode 100644
index 0000000..c8a0d05
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/test_case.html
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\test_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_U4RYEEvOEdunZcj9T5hrMQ CRC: 116638933 -->test case<!-- END:presentationName,_U4RYEEvOEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-6oW2YOnoWq_xPpmoil91KA CRC: 2181917590 --><p>
+ The specification of a set of test inputs, execution conditions, and expected results, which need to be validated to
+ enable an assessment of some particular aspects of the system under test.
+</p><!-- END:mainDescription,-6oW2YOnoWq_xPpmoil91KA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/tester.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/tester.html
new file mode 100644
index 0000000..e530e31
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/tester.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\tester.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: tester.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_WB6rQEvPEdunZcj9T5hrMQ CRC: 4233123397 -->tester<!-- END:presentationName,_WB6rQEvPEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-prQBbamJ4CLPywfEbyaPaA CRC: 330785205 -->Role representing someone responsible for the core activities of the test effort.<!-- END:mainDescription,-prQBbamJ4CLPywfEbyaPaA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/transition.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/transition.html
new file mode 100644
index 0000000..ca5dae8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/transition.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\transition.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: transition.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-5ms4EvDEdunZcj9T5hrMQ CRC: 3091768458 -->Transition<!-- END:presentationName,_-5ms4EvDEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-yoFF90pq-_UV3fm-5oDenw CRC: 2333223806 -->The fourth and last <span class="docEmphasis">phase</span> of the OpenUP/ Basic project lifecycle, which results in a final
+product <span class="docEmphasis">release</span>.<!-- END:mainDescription,-yoFF90pq-_UV3fm-5oDenw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case.html
new file mode 100644
index 0000000..8cff7b7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\use_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_IHRO8EvHEdunZcj9T5hrMQ CRC: 2628156894 -->use case<!-- END:presentationName,_IHRO8EvHEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-HDfMzDXoilK-f2iNreHRVg CRC: 2404107851 -->Captures requirements as a sequence of actions a system performs that yields an observable result of value to
+those interacting with the system.<!-- END:mainDescription,-HDfMzDXoilK-f2iNreHRVg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case_model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case_model.html
new file mode 100644
index 0000000..4012f84
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case_model.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\use_case_model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case_model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_k6B3kEvmEdunZcj9T5hrMQ CRC: 3643945530 -->use-case model<!-- END:presentationName,_k6B3kEvmEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-UTrE64wEDJIC1FRUomEYDg CRC: 3363190280 -->A model of the system use cases and actors and the relationships between them<!-- END:mainDescription,-UTrE64wEDJIC1FRUomEYDg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case_scenario.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case_scenario.html
new file mode 100644
index 0000000..a102e21
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/use_case_scenario.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\use_case_scenario.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case_scenario.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_oXmYMEvGEdunZcj9T5hrMQ CRC: 757784417 -->use-case scenario<!-- END:presentationName,_oXmYMEvGEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-t3jNM5ZWkYtzB8A4Chz2Vw CRC: 499569367 -->Represents specific instances of the use case that correspond to specific inputs from the Actor or to specific conditions
+in the environment. Each scenario describes alternate ways that the system provides a behavior, or it may describe failure
+or exception cases<!-- END:mainDescription,-t3jNM5ZWkYtzB8A4Chz2Vw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/velocity.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/velocity.html
new file mode 100644
index 0000000..29ea922
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/velocity.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\velocity.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: velocity.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Nj2hsEvuEdunZcj9T5hrMQ CRC: 3201881769 -->velocity<!-- END:presentationName,_Nj2hsEvuEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-mgWkuUy3q0zzFaxE7DY1ag CRC: 2820215910 -->A key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a
+certain team and project.<!-- END:mainDescription,-mgWkuUy3q0zzFaxE7DY1ag -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/version.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/version.html
new file mode 100644
index 0000000..73908b9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/version.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\version.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: version.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_eX8K8ElyEducWJcS4yanqg CRC: 3206337475 -->version<!-- END:presentationName,_eX8K8ElyEducWJcS4yanqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-4iL0UEFR2Fg7oWkh1TymIg CRC: 2425576117 -->A variant of some artifact; later versions of an artifact typically expand upon earlier versions.<!-- END:mainDescription,-4iL0UEFR2Fg7oWkh1TymIg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/vision.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/vision.html
new file mode 100644
index 0000000..8568a1e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/vision.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_J_5kgEvHEdunZcj9T5hrMQ CRC: 2390269609 -->vision<!-- END:presentationName,_J_5kgEvHEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-VMnkFJpPLdEDUpbz2QDgow CRC: 2268944519 -->The user's or customer's view of the product to be developed, specified at the level of key stakeholder needs and features
+of the system.<!-- END:mainDescription,-VMnkFJpPLdEDUpbz2QDgow -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/work_breakdown_structure.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/work_breakdown_structure.html
new file mode 100644
index 0000000..1467b66
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/work_breakdown_structure.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\work_breakdown_structure.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_breakdown_structure.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_RK9nwEvtEdunZcj9T5hrMQ CRC: 3508737264 -->work breakdown structure<!-- END:presentationName,_RK9nwEvtEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KQTbqDSJXR8KLBxIgGVquA CRC: 1515472658 -->Breaks the project into individual units of work, or tasks, for which cost, milestones, and activities can be allocated and
+tracked.<!-- END:mainDescription,-KQTbqDSJXR8KLBxIgGVquA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/work_item.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/work_item.html
new file mode 100644
index 0000000..0b49049
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/termdefinitions/work_item.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\guidances\termdefinitions\work_item.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_item.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_jyVgcEvKEdunZcj9T5hrMQ CRC: 2639979320 -->work item<!-- END:presentationName,_jyVgcEvKEdunZcj9T5hrMQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-1Oc9t_TLaBgW_YLugZcq7w CRC: 1964935301 -->Scheduled work to be done within the project<!-- END:mainDescription,-1Oc9t_TLaBgW_YLugZcq7w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/plugin.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/plugin.html
new file mode 100644
index 0000000..dbb03de
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/plugin.html
@@ -0,0 +1,270 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\plugin.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plugin.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0TLvwMlgEdmt3adZL5Dmdw CRC: 1894151989 -->The OpenUP/Basic is an iterative software development process that is minimal, complete, and extensible.<!-- END:briefDescription,_0TLvwMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_W2SgEDR5EdutE_HNDTJk5Q CRC: 2596955702 -->Use-Case Model<!-- END:presentationName,_W2SgEDR5EdutE_HNDTJk5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_dTa6gMAYEdqX-s4mWhkyqQ CRC: 218410109 -->Stakeholder<!-- END:presentationName,_dTa6gMAYEdqX-s4mWhkyqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_dTa6gMAYEdqX-s4mWhkyqQ CRC: 1540103505 -->This role represents interest groups whose needs must be satisfied by the project. It is a role that may be played by anyone who is (or potentially will be) materially affected by the outcome of the project.<!-- END:briefDescription,_dTa6gMAYEdqX-s4mWhkyqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_cp6ycBOGEduCNqgZdt_OaA CRC: 282220576 -->Getting Started<!-- END:presentationName,_cp6ycBOGEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_cp6ycBOGEduCNqgZdt_OaA CRC: 3803324311 -->This area provides information useful for understanding how to deploy and adopt OpenUP/Basic.<!-- END:briefDescription,_cp6ycBOGEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ClDF4BOHEduCNqgZdt_OaA CRC: 1949634023 -->About<!-- END:presentationName,_ClDF4BOHEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HEu9QBOHEduCNqgZdt_OaA CRC: 2827210875 -->Core Principles<!-- END:presentationName,_HEu9QBOHEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_HEu9QBOHEduCNqgZdt_OaA CRC: 2570515932 -->Four core principles capture the general intentions behind this process and create the foundation for interpreting roles and work products and performing tasks.<!-- END:briefDescription,_HEu9QBOHEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2l8U4K4sEdudp4CB-AFxtw CRC: 2367463022 -->Architectural Mechanisms<!-- END:presentationName,_2l8U4K4sEdudp4CB-AFxtw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_2l8U4K4sEdudp4CB-AFxtw CRC: 3569006312 -->Information about how to use use architectural mechansims to create a robust architecture.<!-- END:briefDescription,_2l8U4K4sEdudp4CB-AFxtw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_RdM7MMXnEduywMSzPTUUwA CRC: 991700899 -->OpenUP/Basic<!-- END:presentationName,_RdM7MMXnEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Nm5vUK__EduMeuOwJ2MpeQ CRC: 4069719772 -->Minimal, Complete, and Extensible<!-- END:presentationName,_Nm5vUK__EduMeuOwJ2MpeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Nm5vUK__EduMeuOwJ2MpeQ CRC: 1574384663 -->OpenUP/Basic is minimal, complete, and extensible. It's the minimum amount of process for a small team, it can be used as-is, and it can be extended and customized for specific purposes.<!-- END:briefDescription,_Nm5vUK__EduMeuOwJ2MpeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZRHNUMXwEduywMSzPTUUwA CRC: 37110622 -->OpenUP Fundamental Concepts<!-- END:presentationName,_ZRHNUMXwEduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_omneEMX4EduywMSzPTUUwA CRC: 2391106565 -->Resources for Modifying Methods<!-- END:presentationName,_omneEMX4EduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_t9yXEMX4EduywMSzPTUUwA CRC: 2275068308 -->Resources for Contributing to OpenUP<!-- END:presentationName,_t9yXEMX4EduywMSzPTUUwA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0UCrYclgEdmt3adZL5Dmdw CRC: 3661292323 -->collaboration<!-- END:name,_0UCrYclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0UCrYclgEdmt3adZL5Dmdw CRC: 2290568627 -->Collaboration sub-process.<!-- END:briefDescription,_0UCrYclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_OGGKkMpyEdqC_NfSivunjA CRC: 46222080 -->core_principles<!-- END:name,_OGGKkMpyEdqC_NfSivunjA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_L79ggDR5EdutE_HNDTJk5Q CRC: 2570078296 -->uc_modeling<!-- END:name,_L79ggDR5EdutE_HNDTJk5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_L79ggDR5EdutE_HNDTJk5Q CRC: 1659827244 -->Elements specific to UC modeling.<!-- END:briefDescription,_L79ggDR5EdutE_HNDTJk5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NOHy0BOGEduCNqgZdt_OaA CRC: 1899054650 -->Using OpenUP/Basic<!-- END:presentationName,_NOHy0BOGEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_NOHy0BOGEduCNqgZdt_OaA CRC: 2459398151 -->This guideline explains the various usage scenarios of this Web site.<!-- END:briefDescription,_NOHy0BOGEduCNqgZdt_OaA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0cQzQMlgEdmt3adZL5Dmdw CRC: 1864924558 -->templates<!-- END:name,_0cQzQMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_3E1NwDPBEduyTOpiJx8z_g CRC: 3194813201 -->intent<!-- END:name,_3E1NwDPBEduyTOpiJx8z_g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_3E1NwDPBEduyTOpiJx8z_g CRC: 81853213 -->Intent sub-process.<!-- END:briefDescription,_3E1NwDPBEduyTOpiJx8z_g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0b4YwMlgEdmt3adZL5Dmdw CRC: 3753031832 -->change_management<!-- END:name,_0b4YwMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0UCrYslgEdmt3adZL5Dmdw CRC: 1891541418 -->requirements<!-- END:name,_0UCrYslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_FtSMYAFjEduDPKiaP0pu-Q CRC: 2570078296 -->uc_modeling<!-- END:name,_FtSMYAFjEduDPKiaP0pu-Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_FtSMYAFjEduDPKiaP0pu-Q CRC: 3835340280 -->This package contains elements specific to Use-Case Modeling technique.<!-- END:briefDescription,_FtSMYAFjEduDPKiaP0pu-Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_IIPZQDRjEduU7vV49F9N0A CRC: 3632233996 -->test<!-- END:name,_IIPZQDRjEduU7vV49F9N0A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_IIPZQDRjEduU7vV49F9N0A CRC: 4096801348 -->Portion of testing discipline that relates to Intent.<!-- END:briefDescription,_IIPZQDRjEduU7vV49F9N0A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_kB42IDRiEduU7vV49F9N0A CRC: 2670930395 -->solution<!-- END:name,_kB42IDRiEduU7vV49F9N0A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_kB42IDRiEduU7vV49F9N0A CRC: 1766494260 -->Solution sub-process.<!-- END:briefDescription,_kB42IDRiEduU7vV49F9N0A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0WuL8MlgEdmt3adZL5Dmdw CRC: 1956208378 -->architecture<!-- END:name,_0WuL8MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0WuL8clgEdmt3adZL5Dmdw CRC: 2008714766 -->visual_modeling<!-- END:name,_0WuL8clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_douywISSEdu8NaFPL8nS_w CRC: 2570078296 -->uc_modeling<!-- END:name,_douywISSEdu8NaFPL8nS_w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_h15dULCxEdujaOuld2kPdg CRC: 4266238264 -->deprecated<!-- END:name,_h15dULCxEdujaOuld2kPdg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_h15dULCxEdujaOuld2kPdg CRC: 155062375 -->This is a temporary content package to hold old copies of elements while they are refactored for release 1.0 It should be deleted before final release. This package should not be published.<!-- END:briefDescription,_h15dULCxEdujaOuld2kPdg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0YcDMMlgEdmt3adZL5Dmdw CRC: 3235258666 -->development<!-- END:name,_0YcDMMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_PGDx8PisEdmjyaJMRcPDWA CRC: 2008714766 -->visual_modeling<!-- END:name,_PGDx8PisEdmjyaJMRcPDWA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0ZM4MMlgEdmt3adZL5Dmdw CRC: 3632233996 -->test<!-- END:name,_0ZM4MMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_5la48DR2EdutE_HNDTJk5Q CRC: 189699407 -->management<!-- END:name,_5la48DR2EdutE_HNDTJk5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_5la48DR2EdutE_HNDTJk5Q CRC: 2762044205 -->Management sub-process.<!-- END:briefDescription,_5la48DR2EdutE_HNDTJk5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0aQBEMlgEdmt3adZL5Dmdw CRC: 334032509 -->project_management<!-- END:name,_0aQBEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_bxcS4B_REdq3EKSIdbj-MA CRC: 2844350371 -->Phase Iteration Templates<!-- END:name,_bxcS4B_REdq3EKSIdbj-MA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_mpl9kDbmEduMn613sF6-Uw CRC: 4159162018 -->Sub-processes<!-- END:name,_mpl9kDbmEduMn613sF6-Uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_JEyxADboEduMn613sF6-Uw CRC: 1142134431 -->Management<!-- END:name,_JEyxADboEduMn613sF6-Uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_TFSlkDboEduMn613sF6-Uw CRC: 3116432935 -->Intent<!-- END:name,_TFSlkDboEduMn613sF6-Uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_XzhPQDboEduMn613sF6-Uw CRC: 1715817357 -->Solution<!-- END:name,_XzhPQDboEduMn613sF6-Uw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/analyst.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/analyst.html
new file mode 100644
index 0000000..bcea45d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/analyst.html
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\analyst.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analyst.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0VxJsMlgEdmt3adZL5Dmdw CRC: 2417366288 -->Analyst<!-- END:presentationName,_0VxJsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0VxJsMlgEdmt3adZL5Dmdw CRC: 3726974023 -->The person in this role represents customer and end-user concerns by gathering input from stakeholders to understand the problem to be solved and by capturing and setting priorities for requirements.<!-- END:briefDescription,_0VxJsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,_Nx8icKYdEdmvhNXG0Oc2uA CRC: 2697751416 --><p>
+ An analyst needs the following knowledge, skills, and abilities:
+</p>
+<ul>
+ <li>
+ Expertise in identifying and understanding problems and opportunities
+ </li>
+ <li>
+ Ability to articulate the needs that are associated with the key problem to be solved or opportunity to be
+ realized
+ </li>
+ <li>
+ Ability to collaborate effectively with the extended team through collaborative working sessions, workshops, JAD
+ sessions and other techniques.
+ </li>
+ <li>
+ Good communication skills, verbally and in writing
+ </li>
+ <li>
+ Knowledge of the business and technology domains or the ability to quickly absorb and understand such information
+ </li>
+</ul>
+<br /><!-- END:skills,_Nx8icKYdEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,_Nx8icKYdEdmvhNXG0Oc2uA CRC: 2643459207 --><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ On small, agile teams this role is often shared among several team members that also perform other roles. See
+ <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self Organize Work Assignments</a> and <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/staffing_project,_Jq64EJjsEduad8I_c-ogIA.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a> for more information on this approach.
+ </li>
+ <li>
+ One (or more) team member(s) performs this role exclusively. This commonly adopted approach is suitable for
+ complex requirements that are difficult to gather.
+ </li>
+ <li>
+ One staff (or more) team member(s) performs both this role and the <a class="elementLink"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>
+ role. This is a good option for smaller or resource<font color="#ff0000">-</font>constrained test teams.
+ </li>
+</ul><!-- END:assignmentApproaches,_Nx8icKYdEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/any_role.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/any_role.html
new file mode 100644
index 0000000..f5916bf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/any_role.html
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\any_role.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: any_role.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0dsWoMlgEdmt3adZL5Dmdw CRC: 1617929191 -->Any Role<!-- END:presentationName,_0dsWoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0dsWoMlgEdmt3adZL5Dmdw CRC: 1242609930 -->Anyone on a team can fill this role of performing general tasks.<!-- END:briefDescription,_0dsWoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NqqcUqeqEdmKDbQuyzCoqQ CRC: 453227197 --><p>
+ This role allows anyone on a team to perform general tasks:
+</p>
+<ul>
+ <li>
+ Access artifacts in the configuration control system for development and maintenance
+ </li>
+ <li>
+ Submit change requests for the project
+ </li>
+ <li>
+ Participate in assessments and reviews
+ </li>
+ <li>
+ Volunteer to work on a particular iteration
+ </li>
+</ul><!-- END:mainDescription,_NqqcUqeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/architect.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/architect.html
new file mode 100644
index 0000000..9aab934
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/architect.html
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\architect.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architect.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0X9iEMlgEdmt3adZL5Dmdw CRC: 3099060277 -->Architect<!-- END:presentationName,_0X9iEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0X9iEMlgEdmt3adZL5Dmdw CRC: 4004525279 -->This role is responsible for defining the software architecture, which includes making the key technical decisions that constrain the overall design and implementation of the project.<!-- END:briefDescription,_0X9iEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Y6tLEKbXEdm9d-ircVOUCA CRC: 359290313 --><p>
+ This role leads or coordinates the technical design of the system and has overall responsibility for facilitating the
+ major technical decisions expressed as software architecture. This typically includes identifying and documenting the
+ architecturally significant aspects of the system as views that describe requirements, design, implementation, and
+ deployment.
+</p>
+<p>
+ This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various
+ stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and
+ followed.
+</p>
+<p>
+ This role is closely involved in organizing the team around the architecture by working closely with the <a
+ class="elementLink" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> in staffing and planning the project.
+</p><!-- END:mainDescription,_Y6tLEKbXEdm9d-ircVOUCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_Y6tLEKbXEdm9d-ircVOUCA CRC: 1742841034 -->This role places emphasis on the core principle <a class="elementLink"
+href="./../../openup_basic/guidances/concepts/core_principle_focus,_9gocwMvoEdqukPpotm3DYg.html"
+guid="_9gocwMvoEdqukPpotm3DYg">Focus on articulating the architecture</a>.<!-- END:keyConsiderations,_Y6tLEKbXEdm9d-ircVOUCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,_Y6tLEKbXEdm9d-ircVOUCA CRC: 4200014938 --><p>
+ Architects must be well-rounded people with maturity, vision, and a depth of experience that allows for grasping issues
+ quickly and making educated, critical judgments in the absence of complete information. Specifically, the person must
+ possess this combination of qualifications:
+</p>
+<ul>
+ <li>
+ <b>Experience</b> <strong>in both problem and software engineering domains</strong>, with evidence of a thorough
+ understanding of the requirements to solve the problem and active participation in software development. If there
+ is a team, this experience can be represented by different team members, but at least one person must be able to
+ provide the overall vision for the project.
+ </li>
+ <li>
+ <b>Leadership ability</b> to motivate and maintain momentum for the technical effort across the various teams and
+ to make critical decisions under pressure, plus make those decisions stick. To be effective, this role must have
+ the authority to make technical decisions.
+ </li>
+ <li>
+ <b>Excellent communication</b> <strong>skills</strong> to earn trust, persuade, motivate, and mentor. This role
+ cannot lead by decree, but only by the consent of the rest of the project team. To be effective, this person
+ must earn the respect of the team members, the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a>, the customer, and the user community, as well as the management
+ team.
+ </li>
+ <li>
+ <b>Goal-oriented and proactive</b> <strong>orientation</strong> with a relentless focus on results. This
+ person is the technical driving force behind the project, not a visionary or dreamer. The career of a successful
+ architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can
+ focus on doing what needs to be done will be successful.
+ </li>
+</ul>
+<p>
+ From an expertise standpoint, this role also needs to show both design and implementation abilities. However, from the
+ design perspective, the effective architect typically exhibits these traits:
+</p>
+<ul>
+ <li>
+ Tends to be a generalist, rather than a specialist, who knows many technologies at a high level rather than a few
+ technologies at the detail level
+ </li>
+ <li>
+ Makes the broader technical decisions, thereby demonstrating broad knowledge and experience, as well as
+ communication and leadership skills
+ </li>
+</ul><!-- END:skills,_Y6tLEKbXEdm9d-ircVOUCA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,_Y6tLEKbXEdm9d-ircVOUCA CRC: 3809105371 --><p>
+ This person in this role should be engaged in the project from start to finish.
+</p>
+<p>
+ For smaller projects, a single person may act as both Architect and <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a>. However, it is better to have these roles performed by different people to ensure that the pressures one
+ role doesn't cause neglect of the other role. The Architect and Project Manager must work together closely.
+</p><!-- END:assignmentApproaches,_Y6tLEKbXEdm9d-ircVOUCA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/developer.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/developer.html
new file mode 100644
index 0000000..a8f25e8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/developer.html
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\developer.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: developer.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0YDosMlgEdmt3adZL5Dmdw CRC: 3876194617 -->Developer<!-- END:presentationName,_0YDosMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0YDosMlgEdmt3adZL5Dmdw CRC: 279253799 -->This role is responsible for developing a part of the system, including designing it to fit into the architecture, possibly prototyping the user-interface, and then implementing, unit-testing, and integrating the components that are part of the solution.<!-- END:briefDescription,_0YDosMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,_NqL7MqeqEdmKDbQuyzCoqQ CRC: 1216531078 --><p>
+ This role needs the following knowledge, skills, and abilities:
+</p>
+<ul>
+ <li>
+ Define and create technical solutions in the project's technology
+ </li>
+ <li>
+ Understand and conform to the architecture
+ </li>
+ <li>
+ Identify and build developer tests that cover required behavior of the technical components
+ </li>
+ <li>
+ Communicate the design in a way that other team members understand
+ </li>
+</ul><!-- END:skills,_NqL7MqeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,_NqL7MqeqEdmKDbQuyzCoqQ CRC: 4077836811 --><p>
+ On small, agile teams this role is often shared among several team members that also perform other roles. See <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self Organize Work Assignments</a> and <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/staffing_project,_Jq64EJjsEduad8I_c-ogIA.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a> for more information on this approach.
+</p>
+<p>
+ Even in the smallest team, multiple individuals should be working together to create the technical solution.
+</p>
+<p>
+ A person performing this role can have specialized skills in a particular technical area, but should also have a broad
+ understanding of all the technologies involved to be able to work with other technical team members.
+</p><!-- END:assignmentApproaches,_NqL7MqeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/developer_vm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/developer_vm.html
new file mode 100644
index 0000000..4f01d1a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/developer_vm.html
@@ -0,0 +1,23 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\developer_vm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: developer_vm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-xbAirPdH1IOKcnklk8hdqw CRC: 1312748724 --><p>
+ In addition, to create a visual model of the system, this role needs the ability to render the design in the
+ Unified Modeling Language (UML).
+</p><!-- END:skills,-xbAirPdH1IOKcnklk8hdqw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/project_manager.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/project_manager.html
new file mode 100644
index 0000000..fbfaccb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/project_manager.html
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\project_manager.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_manager.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0a0o0MlgEdmt3adZL5Dmdw CRC: 1580379618 -->Project Manager<!-- END:presentationName,_0a0o0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0a0o0MlgEdmt3adZL5Dmdw CRC: 2893883256 -->Leads the planning of the project, coordinates interactions with the stakeholders, and keeps the project team focused on meeting the project objectives.<!-- END:briefDescription,_0a0o0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Fdq-8KX4EdmvhNXG0Oc2uA CRC: 1649063884 --><p>
+ This role:
+</p>
+<ul>
+ <li>
+ Applies management knowledge, skills, tools and techniques to a broad range of tasks in order to deliver the
+ desired result for a particular project in a timely fashion.
+ </li>
+ <li>
+ Is accountable for the outcome of the project and the acceptance of the product by the customer.
+ </li>
+ <li>
+ Responsible for the evaluation of project's risks, and controling these risks through mitigation strategies.
+ </li>
+</ul><!-- END:mainDescription,_Fdq-8KX4EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,_Fdq-8KX4EdmvhNXG0Oc2uA CRC: 2054669594 --><p>
+ A person performing this role needs the following skills:
+</p>
+<ul>
+ <li>
+ Good in presentation, facilitation, communication, and negotiation.
+ </li>
+ <li>
+ Leadership and team building capabilities.
+ </li>
+ <li>
+ Thorough experience in the software development lifecycle to teach, guide and support other team members.
+ </li>
+ <li>
+ Proficient in conflict resolution and problem solving techniques.
+ </li>
+</ul><!-- END:skills,_Fdq-8KX4EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,_Fdq-8KX4EdmvhNXG0Oc2uA CRC: 294516326 --><p>
+ This role is often played by a single person. This role is difficult to share with others, but might not consume all of
+ a person’s availability.
+</p>
+<br />
+<br /><!-- END:assignmentApproaches,_Fdq-8KX4EdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/tester.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/tester.html
new file mode 100644
index 0000000..b4a914f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/roles/tester.html
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\roles\tester.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: tester.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0ZM4MclgEdmt3adZL5Dmdw CRC: 4227617651 -->Tester<!-- END:presentationName,_0ZM4MclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0ZM4MclgEdmt3adZL5Dmdw CRC: 3016298646 -->This role is responsible for the core activities of the test effort. Those activities include identifying, defining, implementing, and conducting the necessary tests, as well as logging the outcomes of the testing and analyzing the results.<!-- END:briefDescription,_0ZM4MclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NqYIcKeqEdmKDbQuyzCoqQ CRC: 2462596497 --><p>
+ This role is primarily responsible for the following tasks:
+</p>
+<ul>
+ <li>
+ Identify the tests that need to be performed
+ </li>
+ <li>
+ Identify the most appropriate implementation approach for a given test
+ </li>
+ <li>
+ Implement individual tests
+ </li>
+ <li>
+ Set up and execute the tests
+ </li>
+ <li>
+ Log outcomes and verify that the tests have been run
+ </li>
+ <li>
+ Analyze and recover from execution errors
+ </li>
+ <li>
+ Communicate test results to the team
+ </li>
+</ul><!-- END:mainDescription,_NqYIcKeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,_NqYIcKeqEdmKDbQuyzCoqQ CRC: 946409371 --><p>
+ A person filling the this role should have the following skills:
+</p>
+<ul>
+ <li>
+ Knowledge of testing approaches and techniques
+ </li>
+ <li>
+ Diagnostic and problem-solving skills
+ </li>
+ <li>
+ Knowledge of the system or application being tested (desirable)
+ </li>
+ <li>
+ Knowledge of networking and system architecture (desirable)
+ </li>
+</ul>
+<p>
+ Where automated testing is required, consider requiring these additional qualifications:
+</p>
+<ul>
+ <li>
+ Training in the appropriate use of test automation tools
+ </li>
+ <li>
+ Experience using test automation tools
+ </li>
+ <li>
+ Programming skills
+ </li>
+ <li>
+ Debugging and diagnostic skills
+ </li>
+</ul>
+<p>
+ <strong>Note:</strong> Specific skill requirements vary depending on the type of testing that you are conducting. For
+ example, the skills needed to successfully use system load testing automation tools are different from those needed for
+ the automation of system functional testing.
+</p><!-- END:skills,_NqYIcKeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,_NqYIcKeqEdmKDbQuyzCoqQ CRC: 2387141259 --><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ Assign one or more testing staff members to perform this role. This is a fairly standard approach and is
+ particularly suitable for small teams, as well as for teams of any size where the team is made up of an experienced
+ group of testers of relatively equal skill levels.
+ </li>
+ <li>
+ Assign one or more testing staff members to perform only this role. This works well in large teams. It is also
+ useful to separate responsibilities when some of the testing staff has more test automation experience than other
+ team members.
+ </li>
+ <li>
+ Assign one or more team members that is already playing another role in the project to be responsible for the
+ testing of some part of the system’s capabilities. The team member will have to have the appropriate test
+ skills
+ </li>
+</ul><!-- END:assignmentApproaches,_NqYIcKeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/rolesets/openup_basic_roles.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/rolesets/openup_basic_roles.html
new file mode 100644
index 0000000..f43eb3c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/rolesets/openup_basic_roles.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\rolesets\openup_basic_roles.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: openup_basic_roles.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_TZIJ0O8NEdmKSqa_gSYthg CRC: 3643482185 -->OpenUP/Basic Roles<!-- END:presentationName,_TZIJ0O8NEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_TZIJ0O8NEdmKSqa_gSYthg CRC: 971177141 -->This is the list of roles in OpenUP/Basic.<!-- END:briefDescription,_TZIJ0O8NEdmKSqa_gSYthg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_Tb5J8O8NEdmKSqa_gSYthg CRC: 221213795 --><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">roles</a>. You can see the roles that have been included, and visit each role page to
+ see its definition and relationships to other elements.
+</p><!-- END:mainDescription,_Tb5J8O8NEdmKSqa_gSYthg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/analyze_arch_reqs.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/analyze_arch_reqs.html
new file mode 100644
index 0000000..7162f9a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/analyze_arch_reqs.html
@@ -0,0 +1,212 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\analyze_arch_reqs.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: analyze_arch_reqs.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0f-1oMlgEdmt3adZL5Dmdw CRC: 1105243094 -->Analyze the Architectural Requirements<!-- END:presentationName,_0f-1oMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0f-1oMlgEdmt3adZL5Dmdw CRC: 1307016786 -->Analyze the architecturally significant requirements and define a candidate architecture for the system. Define the architectural patterns, key mechanisms, and where applicable, modeling conventions for the system.<!-- END:briefDescription,_0f-1oMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_qDRSULBKEdm7Eph_l9Cn9w CRC: 1670503031 --><p>
+ This task focuses on defining a candidate architecture that will guide the development, testing, and
+ operation of the system. It relies on gathering experience gained in similar systems or problem domains to constrain
+ and focus the architecture so that effort is not wasted in re-inventing architecture.
+</p>
+<p>
+ Capture architectural decisions in the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. Make sure that this is communicated across the team.
+</p><!-- END:mainDescription,_qDRSULBKEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_qDRSULBKEdm7Eph_l9Cn9w CRC: 754740029 --><p>
+ This task is most beneficial when developing new and unprecedented systems. In systems where there is already a
+ well-defined architecture, this task might be omitted, or performed quickly as a review of the existing
+ architecture.
+</p>
+<p>
+ It is critical that this task is performed collaboratively with active involvement of other team members and project
+ stakeholders so that consensus and common understanding is reached. It is particularly vital for the architect to
+ involve the developer(s) throughout this task. The architecture effort is about providing leadership and
+ coordination of the technical work rather than putting in a solo performance.
+</p><!-- END:keyConsiderations,_qDRSULBKEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_qDRSULBKEdm7Eph_l9Cn9w CRC: 2219543873 -->To provide sufficient guidance and direction for the team to be able to perform analysis and design in consistent and
+coherent ways.<!-- END:purpose,_qDRSULBKEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_3nMQQA3rEduibvKwrGxWxA CRC: 4188258520 -->Identify architectural goals<!-- END:name,_3nMQQA3rEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_3nMQQA3rEduibvKwrGxWxA CRC: 104080436 --><p>
+ Describe the goals of the architecture by examining the product <a class="elementLink"
+ href="./../../openup_basic/guidances/checklists/vision,_0WoFUMlgEdmt3adZL5Dmdw.html"
+ guid="_0WoFUMlgEdmt3adZL5Dmdw">Vision</a> and requirements, including architecturally significant requirements.
+ Also, talk to the project <a class="elementLink"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> and <a class="elementLink"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a>.
+ These goals will guide your approach to important architectural and design decisions.
+</p><!-- END:sectionDescription,_3nMQQA3rEduibvKwrGxWxA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_9o6Z4CSCEdqDjNgZyGMf5w CRC: 682473524 -->Identify architectural constraints<!-- END:name,_9o6Z4CSCEdqDjNgZyGMf5w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_9o6Z4CSCEdqDjNgZyGMf5w CRC: 3808627684 --><p>
+ Understand any constraints (or opportunities) on the solution that are inherent in the existing environment
+ or organization. If available, examine the <a class="elementLink"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a> for any constraints that have already been
+ identified. Discuss any critical time and resource constraints with the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a>, as these will also need to be taken into account when arriving at your decisions. Discuss potential
+ constraints with the tester such as hooks for tests, and to identify architectural areas that may be difficult to test.
+</p><!-- END:sectionDescription,_9o6Z4CSCEdqDjNgZyGMf5w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_B899cMP2EdmWKcx6ixEiwg CRC: 3778903375 -->Survey, assess, and select available assets<!-- END:name,_B899cMP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_B899cMP2EdmWKcx6ixEiwg CRC: 574882805 --><p>
+ Establish the availability of any existing software assets as suitable candidates for re-use. Make sure you consult
+ with others who have knowledge of existing assets, particularly the <a class="elementLink"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html"
+ guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a>(s) and other people outside the project team (such as production
+ support teams) in order to form a balanced view of the suitability of existing assets for re-use. Identifying reusable
+ assets could be done as a team brainstorming session.
+</p><!-- END:sectionDescription,_B899cMP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_FVrlsMP2EdmWKcx6ixEiwg CRC: 1513915210 -->Define approach for structuring the system<!-- END:name,_FVrlsMP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_FVrlsMP2EdmWKcx6ixEiwg CRC: 3781079967 --><p>
+ Decide how to structure the software, both in logical and physical terms. As a minimum, decide on:
+</p>
+<ul>
+ <li>
+ How to partition the software when managing development
+ </li>
+ <li>
+ How the software will be composed at run time.
+ </li>
+</ul>
+<p>
+ For each software partition, briefly describe
+</p>
+<ul>
+ <li>
+ Their name and purpose.
+ </li>
+ <li>
+ Their relationships to other partitions.
+ </li>
+</ul>
+<p>
+ These decisions will form the basis for structuring the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a> and the <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>.
+</p><!-- END:sectionDescription,_FVrlsMP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_tmvWwE5cEducxZ_XZXh-vw CRC: 642273882 -->Define approach for deploying the system<!-- END:name,_tmvWwE5cEducxZ_XZXh-vw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_tmvWwE5cEducxZ_XZXh-vw CRC: 1743408890 -->Outline how the software will deploy over the nodes on the network. Work with stakeholders such as as network support and
+deployment teams to ensure that the proposed approach is a good fit for the wider technical environment.<!-- END:sectionDescription,_tmvWwE5cEducxZ_XZXh-vw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_I32E4MP2EdmWKcx6ixEiwg CRC: 3813839569 -->Identify key abstractions<!-- END:name,_I32E4MP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_I32E4MP2EdmWKcx6ixEiwg CRC: 2506284794 --><p>
+ Identify the key abstractions that the system needs to handle. You can usually find these by looking for nouns that the
+ requirements emphasize or repeat, because they help identify what is important to the business. The <a
+ class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html"
+ guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> is particularly useful for this. Work with the analyst and stakeholder
+ here, as they will have knowledge and materials that are relevant to this step. Work with the developer to identify key
+ abstractions internal to the system.
+</p><!-- END:sectionDescription,_I32E4MP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_KBAsYMP2EdmWKcx6ixEiwg CRC: 1108778023 -->Identify architectural mechanisms<!-- END:name,_KBAsYMP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_KBAsYMP2EdmWKcx6ixEiwg CRC: 4100470580 --><p>
+ Catalog the architectural mechanisms that are necessary to fulfil the requirements. At this stage, it only
+ necessary to capture a relatively small amount of detail for each mechanism. Discuss the requirements
+ (especially <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) that are being addressed by each mechanisms with the
+ analysts and stakeholders to make sure that the requirements are unambiguous and well understood.
+</p><!-- END:sectionDescription,_KBAsYMP2EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_xTdYACGAEdqk6N_Ot_YEvA CRC: 3359460101 -->Capture architectural decisions<!-- END:name,_xTdYACGAEdqk6N_Ot_YEvA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_xTdYACGAEdqk6N_Ot_YEvA CRC: 3271402410 --><p>
+ Capture important decisions about the architecture for future reference. Consider using the templates
+ provided for the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>.
+</p><!-- END:sectionDescription,_xTdYACGAEdqk6N_Ot_YEvA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/assess_results.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/assess_results.html
new file mode 100644
index 0000000..51dcf9c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/assess_results.html
@@ -0,0 +1,181 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\assess_results.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: assess_results.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0l53cMlgEdmt3adZL5Dmdw CRC: 2553329503 -->Assess Results<!-- END:presentationName,_0l53cMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0l53cMlgEdmt3adZL5Dmdw CRC: 3775991754 -->Determine success or failure of the iteration. Apply the lessons learned to modify the project or improve the process.<!-- END:briefDescription,_0l53cMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_a3uz4LBYEdm7Eph_l9Cn9w CRC: 1759221735 -->Capture and communicate whether the project is on track, requires corrective actions, and whether there are opportunities
+for improvement.<br /><!-- END:purpose,_a3uz4LBYEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_PABe4MQIEdmaiYJe8-Eaqg CRC: 3624607776 -->Gather stakeholder feedback<!-- END:name,_PABe4MQIEdmaiYJe8-Eaqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_PABe4MQIEdmaiYJe8-Eaqg CRC: 1232513160 --><p>
+ The team should demonstrate the product to customer, end-users, and other <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>s to collect their feedback, or better yet, have end users to use the product themselves. This
+ should be done throughout the iteration, or at least in a separate session towards the end of the iteration. Record
+ requested changes to the product in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> for later prioritization. Factor the feedback
+ into the overall iteration assessment.
+</p><!-- END:sectionDescription,_PABe4MQIEdmaiYJe8-Eaqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_o28GgMMsEdmdo9HxCRR_Gw CRC: 1468894915 -->Assess results<!-- END:name,_o28GgMMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_o28GgMMsEdmdo9HxCRR_Gw CRC: 2954641234 --><p>
+ Towards the end of the iteration, the team should jointly assess whether the objectives and evaluation criteria
+ established in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a> were met, and whether the team adhered to the
+ iteration plan and completed all the planned work items. Below are some sample questions that the team can ask
+ themselves as a part of the assessment:
+</p>
+<ul>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
+ release meet performance and capacity goals?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Were risks reduced or eliminated? Can we identify new risks?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Were all planned work items addressed? What was the teams velocity relative to plan?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Did the end users provide favorable feedback on what we built in this iteration?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Are changes to the project plan required?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ What portion of the current release will be baselined? What portion will need to be reworked?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ Have there been external changes such as changes in the marketplace, in the user community, or in the
+ requirements?
+ </div>
+ </li>
+</ul>
+<p dir="ltr">
+ The assessments should be based on objective measures to the greatest extent possible. For example, to assess that a
+ given requirement is developed, the team should ensure that the corresponding test cases were successfully run against
+ it, rather than considering it done when the implementation is done.
+</p><!-- END:sectionDescription,_o28GgMMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_iL7cQEpqEdup0IY9DKDPkg CRC: 1178255518 -->Perform a retrospective<!-- END:name,_iL7cQEpqEdup0IY9DKDPkg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_iL7cQEpqEdup0IY9DKDPkg CRC: 1583221476 --><p>
+ Review the approach taken to development and team collaboration, the effectiveness of the development environment, the
+ suitability of the working environment, and other factors and discuss what things went well, what could have gone
+ better, and how things could be changed to deliver better results. Capture actions to be taken to improve the
+ development approach for next iteration in the <a class="elementLink" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a>.
+</p><!-- END:sectionDescription,_iL7cQEpqEdup0IY9DKDPkg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_YdoAAM1DEdmLoKw_mVTvhQ CRC: 942688607 -->Refine project scope and duration<!-- END:name,_YdoAAM1DEdmLoKw_mVTvhQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_YdoAAM1DEdmLoKw_mVTvhQ CRC: 307789206 --><p>
+ Depending on the results of the assessment and the stakeholders' feedback, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a> could need to revise the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a> to adapt to those changes. If a change affects defined
+ project milestones, the project manager should consult with the stakeholders before committing to the changes.
+</p>
+<p>
+ Necessary changes can also encompass the need to acquire new resources, to absorb an unplanned effort increase, or to
+ implement a specific change request.
+</p><!-- END:sectionDescription,_YdoAAM1DEdmLoKw_mVTvhQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_wp2CIMMsEdmdo9HxCRR_Gw CRC: 1148511179 -->Close-out phase<!-- END:name,_wp2CIMMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_wp2CIMMsEdmdo9HxCRR_Gw CRC: 2323626501 --><p>
+ This step is optional and must be performed only when the assessment period coincide with the end of a phase.
+</p>
+<p>
+ The end of a phase represents a point of synchronization of technical and management expectations and closure for
+ a project. In iterative development, it coincides with the end of an iteration. However, phase ends mark a point
+ when it is possible to consider re-scoping and even re-contracting a project. For example, the inception phase is
+ exploratory and may be appropriately performed under a time-and-materials contract or a cost-plus type of contract. The
+ elaboration phase could be done as a fixed-price contract or a cost-plus contract, depending on the extent to which the
+ development is unusual. By the construction and transition phases, enough is known about the system that fixed-price
+ contracts are more appealing to the acquirer and vendor.
+</p>
+<p>
+ The phase end is marked by a major milestone and a corresponding milestone review. The degree of formality of
+ these reviews depends on the project. The important thing is to take advantage of this milestone review to
+ achieve agreement among all stakeholders on the current state of the project. For more information, refer to <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Concept: Milestones</a>.
+</p><!-- END:sectionDescription,_wp2CIMMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_1YHH8DLqEdueZPye-FaNgA CRC: 2030100740 -->Close-out project<!-- END:name,_1YHH8DLqEdueZPye-FaNgA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_1YHH8DLqEdueZPye-FaNgA CRC: 20249945 --><p>
+ This step is optional and must be performed only when the assessment period coincide with the end of the project.
+</p>
+<p>
+ Involve the team and stakeholders in a final assessment for project acceptance which, if successful, marks the
+ point when the customer accepts ownership of the software product. Gather and record the lessons learned to be used in
+ future projects. Complete the close-out of the project by disposing of the remaining assets and reassigning the
+ remaining staff.
+</p><!-- END:sectionDescription,_1YHH8DLqEdueZPye-FaNgA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/create_test_cases.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/create_test_cases.html
new file mode 100644
index 0000000..9d60042
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/create_test_cases.html
@@ -0,0 +1,165 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\create_test_cases.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: create_test_cases.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0iwc0clgEdmt3adZL5Dmdw CRC: 857280619 -->Create Test Cases<!-- END:presentationName,_0iwc0clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0iwc0clgEdmt3adZL5Dmdw CRC: 289248017 -->Develop the test cases and test data for the requirements to be tested.<!-- END:briefDescription,_0iwc0clgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NrVKsKeqEdmKDbQuyzCoqQ CRC: 4055571068 --><p>
+ To achieve a shared understanding of the specific conditions that the solution must meet.
+</p><!-- END:purpose,_NrVKsKeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_IJFSsKuSEdmhFZtkg1nakg CRC: 3206599424 -->Review the requirements to be tested<!-- END:name,_IJFSsKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_IJFSsKuSEdmhFZtkg1nakg CRC: 1578709741 --><p>
+ Work with <a class="elementLinkWithType" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html"
+ guid="_0VxJsMlgEdmt3adZL5Dmdw">Role: Analyst</a> and <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Role:
+ Developer</a> to identify which use-case scenarios need new or additional test cases. Review the <a
+ class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a> to ensure you understand the scope of development for
+ the current iteration.<br />
+</p><!-- END:sectionDescription,_IJFSsKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_aDe_ILGcEdubqf8m_Zrvvg CRC: 4098412583 -->Identify relevant Test Cases<!-- END:name,_aDe_ILGcEdubqf8m_Zrvvg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_aDe_ILGcEdubqf8m_Zrvvg CRC: 3723386697 --><p>
+ Identify paths through the use-case scenario as unique test conditions. Consider alternative or exception paths
+ from both a positive and negative perspective. Review the test ideas list for patterns of test cases that
+ apply to the use-case scenario.
+</p>
+<p>
+ Discuss the requirement with the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role:
+ Stakeholder</a> to identify other conditions of satisfaction for the requirement.
+</p>
+<p>
+ List the test cases with a unique name that identifies the condition they evaluate or their expected result.
+</p><!-- END:sectionDescription,_aDe_ILGcEdubqf8m_Zrvvg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_LpbM8KuSEdmhFZtkg1nakg CRC: 3864306435 -->Outline the Test Cases<!-- END:name,_LpbM8KuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_LpbM8KuSEdmhFZtkg1nakg CRC: 3262180619 --><p>
+ For each test case, write a brief description with an expected result. Ensure that a casual reader can clearly
+ understand the difference between test cases. Note the logical pre-conditions and post-conditions that apply to
+ each test case. Optionally, outline steps for the test case.
+</p>
+<p>
+ Verify that test cases meet the <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/checklists/test_case,_0Zxf8MlgEdmt3adZL5Dmdw.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a> guidelines.
+</p>
+<p>
+ For more information on the test case, see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/templates/test_case,_0dT8IMlgEdmt3adZL5Dmdw.html"
+ guid="_0dT8IMlgEdmt3adZL5Dmdw">Template: Test Case</a>.
+</p><!-- END:sectionDescription,_LpbM8KuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_NK18YKuSEdmhFZtkg1nakg CRC: 3090862946 -->Identify test data needs<!-- END:name,_NK18YKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_NK18YKuSEdmhFZtkg1nakg CRC: 3087839731 --><p>
+ Review each test case and note where data input or output might be required. Identify the type, quantity, and
+ uniqueness of the required data, and add these observations to the test case. Focus on articulating the data needed and
+ not on creating specific data.
+</p>
+<p>
+ For more information on test data selection, see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/checklists/test_case,_0Zxf8MlgEdmt3adZL5Dmdw.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>.
+</p><!-- END:sectionDescription,_NK18YKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Ok_mMKuSEdmhFZtkg1nakg CRC: 157813010 -->Share and evaluate the Test Cases<!-- END:name,_Ok_mMKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Ok_mMKuSEdmhFZtkg1nakg CRC: 3562070331 --><p>
+ Walk through the test cases with the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Role:
+ Analyst</a> and <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Role:
+ Developer</a> responsible for the related use-case scenario. Ideally, the <a
+ class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a> also participates.
+</p>
+<p>
+ Ask the participants to agree that if <em>these test cases pass</em>, they will consider these requirements
+ implemented. Elicit additional test ideas from the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Role: Analyst</a>
+ and the <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a> to ensure you understand the expected behavior of the use-case
+ scenario.
+</p>
+<p>
+ During the walkthrough, ensure that:
+</p>
+<ul>
+ <li>
+ The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a> planned for the current iteration have
+ test cases.
+ </li>
+ <li>
+ All the participants agree with the expected results of the test cases.
+ </li>
+ <li>
+ There are no <em>other</em> conditions of satisfaction for the requirement being tested, which indicates
+ either a missing test case or a missing requirement.
+ </li>
+</ul>
+<p>
+ Optionally, capture new patterns of test cases in the test ideas list (see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/concepts/test_ideas_list,_0jnYcMlgEdmt3adZL5Dmdw.html"
+ guid="_0jnYcMlgEdmt3adZL5Dmdw">Concept: Test Ideas List</a>).
+</p><!-- END:sectionDescription,_Ok_mMKuSEdmhFZtkg1nakg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/define_vision.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/define_vision.html
new file mode 100644
index 0000000..cdfd736
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/define_vision.html
@@ -0,0 +1,201 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\define_vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: define_vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0fOAoMlgEdmt3adZL5Dmdw CRC: 2887983663 -->Define Vision<!-- END:presentationName,_0fOAoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0fOAoMlgEdmt3adZL5Dmdw CRC: 2748033547 -->Define the vision for the future system. Describe the problem and features based on Stakeholder requests.<!-- END:briefDescription,_0fOAoMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_5rJ78Lj3Edmy88CC3LfB_w CRC: 2508452536 -->The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to
+express and document their problems, needs, and potential features for the system to be, so the project team can better
+understand what has to be done.<!-- END:purpose,_5rJ78Lj3Edmy88CC3LfB_w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_tvzDULwPEdm6DujQZORGLQ CRC: 4020447428 -->Identify Stakeholders<!-- END:name,_tvzDULwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_tvzDULwPEdm6DujQZORGLQ CRC: 2609616649 --><p>
+ Identify the decision-makers, customers, potential users, partners, domain experts, industry analysts and other
+ interested parties (see <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role:
+ Stakeholder</a>). Develop profiles of potential (or actual) users of the system that map to the roles of human actors
+ of the system that you are developing. Document the initial information on key users and their environment in the <a
+ class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>.
+</p><!-- END:sectionDescription,_tvzDULwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_sa5F4LwPEdm6DujQZORGLQ CRC: 3957171804 -->Gain agreement on the problem to be solved<!-- END:name,_sa5F4LwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_sa5F4LwPEdm6DujQZORGLQ CRC: 2285729573 -->Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the stakeholders
+what they see as the problem. Then search for root causes, or the “problem behind the problem.”
+Use techniques like the ones described in <a class="elementlinkwithtype"
+href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html"
+guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>. Formulate the problem statement, and then
+fill in the corresponding section from <a class="elementlinkwithtype"
+href="./../../openup_basic/guidances/templates/vision,_0cW54MlgEdmt3adZL5Dmdw.html"
+guid="_0cW54MlgEdmt3adZL5Dmdw">Template: Vision</a>. The purpose of this is to help you distinguish solutions and answers
+from problems and questions.<br />
+<br /><!-- END:sectionDescription,_sa5F4LwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_rliOAOz2Edq2wJOsmRwmhg CRC: 2019227070 -->Capture a common vocabulary<!-- END:name,_rliOAOz2Edq2wJOsmRwmhg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_rliOAOz2Edq2wJOsmRwmhg CRC: 2505467041 -->Every project has its own specialized terminology that everyone on the team must understand well to communicate effectively
+with stakeholders. Work with stakeholders to create a glossary that defines acronyms, abbreviations, and relevant
+business and technical terms. Work with stakeholder to continually expand and refine the glossary throughout the
+project life cycle.<!-- END:sectionDescription,_rliOAOz2Edq2wJOsmRwmhg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_vGg-oLwPEdm6DujQZORGLQ CRC: 1906815529 -->Gather stakeholder requests<!-- END:name,_vGg-oLwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_vGg-oLwPEdm6DujQZORGLQ CRC: 1308523979 --><p>
+ Use the most appropriate method to gather information, such as the ones in <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html"
+ guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>. Each one is applicable in a particular
+ situation or to a certain type of stakeholder.
+</p>
+<p>
+ If you can meet stakeholders in person, then you can conduct an interview or a brainstorming session. This face to face
+ collaboration is extremely valuable and reduces the chances of the project team misunderstanding the needs of the
+ stakeholders.
+</p>
+<p>
+ Some requirements may already be documented in an existing Work Item List. This can often be used as a solid starting
+ position from which a full set of requirements can be created.
+</p>
+<p>
+ Any requirements gathered during this step should be captured in the Work Item List.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>.
+</p><!-- END:sectionDescription,_vGg-oLwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_z7ZC4LwPEdm6DujQZORGLQ CRC: 3642748269 -->Define the system boundaries<!-- END:name,_z7ZC4LwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_z7ZC4LwPEdm6DujQZORGLQ CRC: 1228391698 --><p>
+ Find and define the line that divides the solution and the real world that surrounds the solution. Identify interfaces,
+ as well as input and output information exchanged with users, machines, or systems.
+</p>
+<p>
+ A Use Case Model is one technique that can prove useful in defining the system boundaries.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>.
+</p><!-- END:sectionDescription,_z7ZC4LwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_1LVn0LwPEdm6DujQZORGLQ CRC: 3411033524 -->Identify constraints on the system<!-- END:name,_1LVn0LwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_1LVn0LwPEdm6DujQZORGLQ CRC: 2523321536 --><p>
+ Consider the various sources of constraints that can impact the design or the project itself:
+</p>
+<ul>
+ <li>
+ Political
+ </li>
+ <li>
+ Economic (budget, licensing)
+ </li>
+ <li>
+ Environmental (regulatory constraints, legal, standards)
+ </li>
+ <li>
+ Technical (platforms, technology)
+ </li>
+ <li>
+ Feasibility (schedule, resources allocation, outsourcing)
+ </li>
+ <li>
+ System (solutions compatibility, support of operating systems and environments).
+ </li>
+</ul><!-- END:sectionDescription,_1LVn0LwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_2VixILwPEdm6DujQZORGLQ CRC: 233204114 -->Define features of the system<!-- END:name,_2VixILwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_2VixILwPEdm6DujQZORGLQ CRC: 3048054225 --><p>
+ Work with stakeholders to capture a list of <a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a> that stakeholders want in the system, briefly describing them and giving <a
+ class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/requirement_attributes,_VQ268O0KEdqHTdbLTmC5IQ.html"
+ guid="_VQ268O0KEdqHTdbLTmC5IQ">attributes</a> to help define their general status and priority in the project.
+</p>
+<p>
+ Update the <a class="elementLinkWithType"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture the features identified and their
+ attributes.
+</p><!-- END:sectionDescription,_2VixILwPEdm6DujQZORGLQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_AhjmAL-GEdqb7N6KIeDL8Q CRC: 832005153 -->Achieve concurrence<!-- END:name,_AhjmAL-GEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_AhjmAL-GEdqb7N6KIeDL8Q CRC: 2154759509 -->Conduct a review of the project vision with relevant Stakeholders and the development team to ensure agreement, assess
+quality, and identify required changes. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a> for more information.<!-- END:sectionDescription,_AhjmAL-GEdqb7N6KIeDL8Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/design_solution.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/design_solution.html
new file mode 100644
index 0000000..815b918
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/design_solution.html
@@ -0,0 +1,327 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\design_solution.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design_solution.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0fshwMlgEdmt3adZL5Dmdw CRC: 4165556380 -->Design the Solution<!-- END:presentationName,_0fshwMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0fshwMlgEdmt3adZL5Dmdw CRC: 838213958 -->Identify the elements and devise the interactions, behavior, relations, and data necessary to realize some functionality.<!-- END:briefDescription,_0fshwMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NrC20qeqEdmKDbQuyzCoqQ CRC: 577162411 --><p>
+ This task is about designing part of the system, not the whole system. It should be applied based upon some small
+ subset of requirements. The requirements driving the design could be scenario-based functional requirements,
+ non-functional requirements, or a combination.
+</p>
+<p>
+ This task can be applied in some specific context such as the database access elements required for some
+ scenario. In this case the task might be applied again later to deal with a different context on the
+ same requirements. Keep in mind that to actually build some functionality of value to the users, all
+ contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
+ will have to have been designed and implemented all its context such as user interface, business rules, database
+ access, etc.
+</p>
+<p>
+ If this task is being performed on an architecturally significant element the results of this design should be
+ referenced by the architecture.
+</p><!-- END:mainDescription,_NrC20qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_NrC20qeqEdmKDbQuyzCoqQ CRC: 607647162 --><P>Each step in this task can cause all previous steps to be revisited in light of new information and decisions. For example, while determining how elements collaborate you might find a gap in the requirements that causes you to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer could note that a reusable element being used doesn't work as expected and that could cause you to identify new elements to take its place.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
+<P>Consider the architecture while performing this task. All design work must be done while regarding the architecture within which the design exists. Furthermore, certain design elements will be deemed architecturally significant; those elements will require updates to the architecture. </P>
+<P>This task will be applied numerous times. Design is best performed in small chunks.</P>
+<P>Even when starting the design for a particular project it is expected that there will be existing frameworks and reusable elements. Every step of this task must give attention to the existing design and existing implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate while designing this portion of the solution. </P>
+<P>Apply patterns throughout this task. Patterns represent proven designs and their usage promotes quality and consistency across the design. </P><!-- END:keyConsiderations,_NrC20qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NrC20qeqEdmKDbQuyzCoqQ CRC: 4034027761 --><p>
+ The purpose of this task is to describe the elements of the system so that they support the
+ required behavior, are of high quality, and fit within the architecture.
+</p><!-- END:purpose,_NrC20qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_4Z7WYKuKEdmhFZtkg1nakg CRC: 3539482445 -->Understand requirement details<!-- END:name,_4Z7WYKuKEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_4Z7WYKuKEdmhFZtkg1nakg CRC: 1012897478 --><p>
+ Examine the relevant <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a> to understand the scope of the design task and the
+ expectations on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
+ information.
+</p>
+<p>
+ If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might
+ not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the
+ requirements under consideration.
+</p>
+<p>
+ If the requirements are determined to be incomplete or incorrect, work with the analyst to get the
+ requirements improved and possibly submit a change request against the requirements.
+</p><!-- END:sectionDescription,_4Z7WYKuKEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Ci7aYFixEdusJoWkvSRO9Q CRC: 1313874932 -->Understand the architecture<!-- END:name,_Ci7aYFixEdusJoWkvSRO9Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Ci7aYFixEdusJoWkvSRO9Q CRC: 3306830448 --><p>
+ Understand how the architecture applies to this part of the design, and how this design work fits with the rest of the
+ system. Incorporate any applicable interfaces, key abstractions, mechanisms and patterns into the design work. Discuss
+ possible refinements to the architecture and new areas of potential re-use with the architect.
+</p><!-- END:sectionDescription,_Ci7aYFixEdusJoWkvSRO9Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_--6tYKuKEdmhFZtkg1nakg CRC: 3224594196 -->Identify design elements<!-- END:name,_--6tYKuKEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_--6tYKuKEdmhFZtkg1nakg CRC: 2341138125 --><p>
+ Identify the elements that collaborate together to provide the required behavior. This can start with the key
+ abstractions identified in the architecture, domain analysis, and classical analysis of the requirements (noun
+ filtering) to derive the elements that would be required to fulfill them.
+</p>
+<p>
+ Identify elements in all perspectives being considered when performing this task. This could include identifying
+ user interface elements, control elements, data elements, and elements relating to interfacing to other
+ systems or devices.
+</p>
+<p>
+ Existing elements of the design should be examined to see if they should participate in the collaboration. It is
+ a mistake to create all new elements in each execution of this task.
+</p>
+<p>
+ This list of candidates must be expanded to include special-purpose participants that handle particular roles in
+ providing the required behavior such as transaction processing or adherence to some security specification. The
+ <a class="elementLink" href="./../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides a good start for identifying elements.
+</p><!-- END:sectionDescription,_--6tYKuKEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_A_LU8KuLEdmhFZtkg1nakg CRC: 2844361739 -->Determine how elements collaborate to realize the scenario<!-- END:name,_A_LU8KuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_A_LU8KuLEdmhFZtkg1nakg CRC: 2669209812 -->Walk through the scenario distributing responsibilities to the participating elements. These responsibilities can be simple
+statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc. This
+step is about ensuring that a quality model is being created that is robust enough to support the requirements.
+<p>
+ Identify the required relationships between the elements based on the walkthrough of the scenario examining how
+ the elements initiate each other's behavior. An element that requests behavior from another element is represented as a
+ relationship between those elements. As with the responsibilities, these relationships can just be defined at this
+ step.
+</p>
+<p>
+ Look to the architecture and previous design work to create a consistent collaboration. Use the Architect to explain
+ the details and motivations of the architecture. Look to reuse existing behavior and relations or to apply similar
+ structure to simplify the design of the overall system.
+</p>
+<p>
+ Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the
+ existing elements.
+</p><!-- END:sectionDescription,_A_LU8KuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ENwJwKuLEdmhFZtkg1nakg CRC: 352956516 -->Refine design decisions<!-- END:name,_ENwJwKuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ENwJwKuLEdmhFZtkg1nakg CRC: 2451428892 --><p>
+ Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
+ architecture. In this step the design can take into consideration the actual implementation language and other
+ technical decisions. Revisit the identification of the elements and the collaborations that realize the
+ scenarios if necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss
+ testability issues, such as design elements that are difficult to test or critical performance areas, with
+ the Tester and Architect.
+</p>
+<p>
+ In particular make decisions in regard to the considerations below:
+</p>
+<ul>
+ <li>
+ Specific details of relationships between the elements such as multiplicity and navigability
+ </li>
+ <li>
+ Operation detail such as parameters and return values
+ </li>
+ <li>
+ Existence and detail of data attributes necessary
+ </li>
+ <li>
+ Usage of inheritance and interfaces to improve the design
+ </li>
+</ul>
+<p>
+ Incorporate <a class="elementLink" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s from the architecture. Apply consistent structure of the elements
+ and organization of the behavior as in other areas of the design and use patterns identified in the architecture.
+</p><!-- END:sectionDescription,_ENwJwKuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_KNZYAKuLEdmhFZtkg1nakg CRC: 419770836 -->Design internals (for large or complex elements)<!-- END:name,_KNZYAKuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_KNZYAKuLEdmhFZtkg1nakg CRC: 405028966 --><p>
+ Design large or complex elements or some complex internal behavior in more detail.
+</p>
+<p>
+ This might just involve devising an algorithm that could be performed to produce the desired behavior. Add
+ additional operations, attributes, and relationships to support the expectations of an element. Discuss testability
+ issues, such as design elements that are difficult to test or critical performance areas, with the Tester and
+ Architect.
+</p>
+<p>
+ The state of the element managed over the course of its lifetime can be designed to ensure proper behavior in
+ various usages.
+</p><!-- END:sectionDescription,_KNZYAKuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_9LeFME42EdudDeUNeAxPCQ CRC: 3123982209 -->Design the database schema<!-- END:name,_9LeFME42EdudDeUNeAxPCQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_9LeFME42EdudDeUNeAxPCQ CRC: 2352077700 --><p>
+ If the system has persistent data, the design will need to address the database (or file) schema. For a
+ relational database schema, identify the following:
+</p>
+<ul>
+ <li>
+ The structure of tables and views
+ </li>
+ <li>
+ Relationships between tables
+ </li>
+ <li>
+ Triggers which enforce referential integrity
+ </li>
+ <li>
+ Constraints on columns
+ </li>
+ <li>
+ Default values for columns
+ </li>
+ <li>
+ Stored procedures and functions
+ </li>
+</ul><!-- END:sectionDescription,_9LeFME42EdudDeUNeAxPCQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_mUVt8BfnEduD353bkQ4frw CRC: 1605738521 -->Evaluate the design<!-- END:name,_mUVt8BfnEduD353bkQ4frw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_mUVt8BfnEduD353bkQ4frw CRC: 1610019147 --><p>
+ Evaluate the object design for coupling, cohesion, and other quality design measurements.
+</p>
+<p>
+ Evaluate the database/file design for performance, referential integrity, and normalization.
+</p>
+<p>
+ Consider the design from various angles to ensure that it is a high-quality, communicable design. Work with other
+ technical team members; an independent party can provide a fresh perspective. Use the Tester and Architect to
+ provide perspectives on design quality and adherence to the architecture. However, when identifying potential
+ reviewers keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even
+ more value by actively participating in the design effort itself.
+</p>
+<p>
+ If design flaws are identified, improve the design.
+</p><!-- END:sectionDescription,_mUVt8BfnEduD353bkQ4frw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_OGYbwKuLEdmhFZtkg1nakg CRC: 1999328299 -->Communicate the design<!-- END:name,_OGYbwKuLEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_OGYbwKuLEdmhFZtkg1nakg CRC: 3988272218 --><p>
+ Communicate the design to those who need to understand it. Though this is described here toward the end of
+ the task, communication should be going on throughout the steps. Working collaboratively is always better than
+ reviewing the work after it is complete.
+</p>
+<p>
+ Here are some ways to communicate the design:
+</p>
+<ul>
+ <li>
+ Formal models specified in UML .
+ </li>
+ <li>
+ Informal diagrams that render static structure and capture dynamic behavior.
+ </li>
+ <li>
+ Annotated code that communicates information about the static structure supplemented with textual descriptions of
+ dynamic behavior across code modules .
+ </li>
+ <li>
+ Physical data models to describe the database schema.
+ </li>
+</ul>
+<p>
+ Here are some examples of individuals who will need to understand the design:
+</p>
+<ul>
+ <li>
+ Developers who will implement a solution based on the design.
+ </li>
+ <li>
+ An architect who can review the design to ensure that it conforms to the architecture or who might examine the
+ design for opportunities to improve the architecture.
+ </li>
+ <li>
+ Other designers who can examine the design for applicability to other parts of the system.
+ </li>
+ <li>
+ Developers or other designers who will be working on other parts of the system that will depend on the
+ elements designed in this task.
+ </li>
+ <li>
+ Other reviewers who will review the design for quality and adherence to standards.
+ </li>
+</ul><!-- END:sectionDescription,_OGYbwKuLEdmhFZtkg1nakg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/design_solution_vm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/design_solution_vm.html
new file mode 100644
index 0000000..59848e9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/design_solution_vm.html
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\design_solution_vm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design_solution_vm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_T8WvwL3vEdqLRJZPGVbHDA CRC: 4018617737 -->Render the design visually to aid in solving the problem and communicating the solution.<!-- END:briefDescription,_T8WvwL3vEdqLRJZPGVbHDA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/detail_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/detail_requirements.html
new file mode 100644
index 0000000..1420d15
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/detail_requirements.html
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\detail_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: detail_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0e1mIMlgEdmt3adZL5Dmdw CRC: 3482111992 -->Detail Requirements<!-- END:presentationName,_0e1mIMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0e1mIMlgEdmt3adZL5Dmdw CRC: 3172934708 -->This task describes how to detail one or more requirements for the system.<!-- END:briefDescription,_0e1mIMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_Nqwi8KeqEdmKDbQuyzCoqQ CRC: 26759261 --><p>
+ The purpose of this task is to describe one or more requirements in sufficient detail to validate understanding of
+ the requirement, to ensure concurrence with stakeholders expectations, and to permit software development to
+ begin.
+</p><!-- END:purpose,_Nqwi8KeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_vWeHMCxSEdqjsdw1QLH_6Q CRC: 733310024 -->Detail Use Cases and Scenarios<!-- END:name,_vWeHMCxSEdqjsdw1QLH_6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_vWeHMCxSEdqjsdw1QLH_6Q CRC: 1909911892 --><p>
+ Some <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s and Scenarios may need to be described in more detail to validate our
+ understanding of the requirement and to permit software development to begin. This does not imply that all use
+ cases and scenarios will be detailed prior to commencing implementation. Work with stakeholders to
+ detail only those that are prioritized for implementation in the next iteration or two (see <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>), or those that are deemed architecturally significant
+ (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>.)
+</p>
+<p>
+ The level of detail captured will vary depending upon the needs of the project and the complexity of the use
+ case. For a discussion of the different levels of detail that may be applicable see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
+</p>
+<p>
+ Capture the use case details in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>. For additional information on detailing use cases and scenarios, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>. For assistance in assessing the
+ quality of your use cases see <a class="elementLinkWithType" href="./../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html" guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>.
+</p><!-- END:sectionDescription,_vWeHMCxSEdqjsdw1QLH_6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_B47VwCxTEdqjsdw1QLH_6Q CRC: 1322327703 -->Detail supporting requirements<!-- END:name,_B47VwCxTEdqjsdw1QLH_6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_B47VwCxTEdqjsdw1QLH_6Q CRC: 2781639432 --><p>
+ Some <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a> may need to be clarified or described in more detail, new
+ requirements may have been discovered as we detailed the use cases and scenarios, and new requirements may have
+ been submitted as <a class="elementLink" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a>. Work with stakeholders to capture, refine and validate those
+ requirements that will have an impact on near term work (see <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>) or are deemed architecturally significant (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>).
+</p>
+<p>
+ Capture these requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. For additional guidance on detailing
+ supporting requirements see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q.html" guid="_wr24gNcGEdqz_d2XWoVt6Q">Guideline: Supporting Requirements</a>. For assistance in assessing the quality of
+ your supporting requirements see <a class="elementLinkWithType" href="./../../openup_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.html" guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a>.
+</p><!-- END:sectionDescription,_B47VwCxTEdqjsdw1QLH_6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_2389cOz2Edq2wJOsmRwmhg CRC: 4140312912 -->Detail glossary terms<!-- END:name,_2389cOz2Edq2wJOsmRwmhg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_2389cOz2Edq2wJOsmRwmhg CRC: 30940822 -->Review the use case flow of events. If information is exchanged, be specific about what is passed back and
+forth. Work with stakeholders to ensure that you define newly discovered domain terms, or ambiguous
+terms properly in the <a class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a>.
+If your understanding of the domain has improved, refine existing glossary terms.<!-- END:sectionDescription,_2389cOz2Edq2wJOsmRwmhg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_BYbboN-bEdqiM_wFaqLjNg CRC: 832005153 -->Achieve concurrence<!-- END:name,_BYbboN-bEdqiM_wFaqLjNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_BYbboN-bEdqiM_wFaqLjNg CRC: 4193235022 -->Conduct a review of the requirements (<a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>) with relevant <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> and the development team to ensure consistency with the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>, assess quality, and identify required changes. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a> for more information.<!-- END:sectionDescription,_BYbboN-bEdqiM_wFaqLjNg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/detail_requirements_intent_req_ucm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/detail_requirements_intent_req_ucm.html
new file mode 100644
index 0000000..3246915
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/detail_requirements_intent_req_ucm.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\detail_requirements_intent_req_ucm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: detail_requirements_intent_req_ucm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_w2JYgEf6EduISP1GQDlvVQ CRC: 2710386598 -->Update Use-Case Model<!-- END:name,_w2JYgEf6EduISP1GQDlvVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_w2JYgEf6EduISP1GQDlvVQ CRC: 2557242338 -->Based on your work update the <a class="elementLink"
+href="./../../openup_basic/workproducts/uc_model,_W2SgEDR5EdutE_HNDTJk5Q.html" guid="_W2SgEDR5EdutE_HNDTJk5Q">Use-Case
+Model</a>. Add, remove or update <a class="elementLinkWithUserText"
+href="./../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a>
+and <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s as required. For more information on creating and structuring your use
+case model see <a class="elementLinkWithType"
+href="./../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html"
+guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>. For assistance in assessing the quality of your use
+case model see <a class="elementLinkWithType"
+href="./../../openup_basic/guidances/checklists/uc_model,_0U6OEMlgEdmt3adZL5Dmdw.html"
+guid="_0U6OEMlgEdmt3adZL5Dmdw">Checklist: Use-Case Model</a>.<!-- END:sectionDescription,_w2JYgEf6EduISP1GQDlvVQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/develop_arch.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/develop_arch.html
new file mode 100644
index 0000000..6f0a3de
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/develop_arch.html
@@ -0,0 +1,236 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\develop_arch.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: develop_arch.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0gRJgMlgEdmt3adZL5Dmdw CRC: 514934396 -->Develop the Architecture<!-- END:presentationName,_0gRJgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0gRJgMlgEdmt3adZL5Dmdw CRC: 3868901055 -->Make concrete decisions about the architecture to provide guidance and direction to the development work for the iteration.<!-- END:briefDescription,_0gRJgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_rUis8LBKEdm7Eph_l9Cn9w CRC: 2181898083 --><p>
+ This task builds on the work performed during <a class="elementLink"
+ href="./../../openup_basic/tasks/analyze_arch_reqs,_0f-1oMlgEdmt3adZL5Dmdw.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Analyze
+ the Architectural Requirements</a> to produce a concrete approach for the main development work to follow.
+</p>
+<p>
+ The objective is to resolve the overarching issues which affect the design and development activity for the current
+ iteration. These are:
+</p>
+<ul>
+ <li>
+ To specify common mechanisms or patterns to be used.
+ </li>
+ <li>
+ To specify what use will be made of existing software assets and how they will integrate with the overall
+ solution.
+ </li>
+ <li>
+ To specify what new software needs to be developed.
+ </li>
+ <li>
+ To ensure that the appropriate hardware and software resources are specified to support the development and
+ testing of the solution.
+ </li>
+ <li>
+ To ensure that the architecture is useful to and used by the project team.
+ </li>
+</ul>
+<p>
+ The technical decisions taken as part of this task are concrete and unambiguous. Capture architectural
+ decisions in the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. Make sure that this is communicated across the team.
+</p>
+<p>
+ This task is applied iteratively; iterations after the first will need to take account of the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a> and <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> products that have been developed so far.
+</p><!-- END:mainDescription,_rUis8LBKEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_rUis8LBKEdm7Eph_l9Cn9w CRC: 608248401 --><p>
+ The architect should perform this task through collaboration with the whole team to promote consensus and a
+ common understanding of the overall solution. The architect should be working to coordinate and guide the technical
+ activities of the team, rather than seeking to do all the work alone. The architect should place emphasis on
+ involving the developer(s) throughout this task.
+</p><!-- END:keyConsiderations,_rUis8LBKEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_rUis8LBKEdm7Eph_l9Cn9w CRC: 1093268120 --><p>
+ Provide a skeletal design to enable more comprehensive design activities to be performed coherently by the team.
+</p><!-- END:purpose,_rUis8LBKEdm7Eph_l9Cn9w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_P28vkMP3EdmWKcx6ixEiwg CRC: 1090065480 -->Identify architectural priorities<!-- END:name,_P28vkMP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_P28vkMP3EdmWKcx6ixEiwg CRC: 3577363164 --><p>
+ Determine the priorities for this iteration of architecture work. Balance the objectives for the
+ current iteration against the overall project objectives, ensuring that the architecture can support current and future
+ needs.
+</p><!-- END:sectionDescription,_P28vkMP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0qoQ8CikEduQBKSg5n118w CRC: 249519268 -->Refine architectural mechanisms<!-- END:name,_0qoQ8CikEduQBKSg5n118w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_0qoQ8CikEduQBKSg5n118w CRC: 1838413154 --><p>
+ Refine each architectural mechanism into a <a class="elementLink"
+ href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a> by looking at the requirements in the context of the current
+ iteration. Include each architecturally significant scenario in scope. Look for commonality across scenarios and
+ propose common components and patterns for their solution. Work with the developers and analysts to gain consensus
+ on the architecture mechanisms.
+</p><!-- END:sectionDescription,_0qoQ8CikEduQBKSg5n118w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_QtKuoCilEduQBKSg5n118w CRC: 852188111 -->Identify business patterns<!-- END:name,_QtKuoCilEduQBKSg5n118w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_QtKuoCilEduQBKSg5n118w CRC: 4180485019 --><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ The architecture of the system can often be best communicated by showing how it handles important areas business
+ behaviour.
+</p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ See <a class="elementLink" href="./../../openup_basic/guidances/concepts/business_pattern,_Z53x0BapEduSTJywppIxVQ.html"
+ guid="_Z53x0BapEduSTJywppIxVQ">Business Pattern</a>. Work with the stakeholders to assure the business patterns are
+ based on sound knowledge.
+</p><!-- END:sectionDescription,_QtKuoCilEduQBKSg5n118w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Vdln8MP3EdmWKcx6ixEiwg CRC: 617336826 -->Identify reuse opportunities<!-- END:name,_Vdln8MP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Vdln8MP3EdmWKcx6ixEiwg CRC: 4144782941 --><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Leverage reuse of existing components by evaluating their interfaces and the behavior that they provide. Reuse
+ components when their interfaces are similar or match the interfaces of components you would need to develop from
+ scratch. If not similar, modify the newly identified interfaces so you improve the fit with existing components
+ interfaces.
+</p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Work with developers to gain consensus on the suitability of using existing components.
+</p><!-- END:sectionDescription,_Vdln8MP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_G_k1kBaqEduSTJywppIxVQ CRC: 3203302437 -->Identify architecturally significant design elements<!-- END:name,_G_k1kBaqEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_G_k1kBaqEduSTJywppIxVQ CRC: 1102330509 --><p align="left">
+ Refine the key abstractions to decide on the important design elements (such as classes and subsystems) that
+ make up the architecture, and provide at least a name and brief description for each. Add them to the <a
+ class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Gain consensus with the developers on architecturally significant design
+ choices.
+</p><!-- END:sectionDescription,_G_k1kBaqEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_xIIVkMUbEdu5GrwIlTJV7g CRC: 3066678315 -->Map the software to the hardware<!-- END:name,_xIIVkMUbEdu5GrwIlTJV7g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_xIIVkMUbEdu5GrwIlTJV7g CRC: 81186899 -->Map the architecturally significant design elements to the target deployment environment. Work with hardware and network
+specialists to ensure that the hardware is sufficient to meet the needs of the system; and that any new hardware is
+available in time.<!-- END:sectionDescription,_xIIVkMUbEdu5GrwIlTJV7g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_LsyLkBaqEduSTJywppIxVQ CRC: 302179484 -->Define development architecture and test architecture<!-- END:name,_LsyLkBaqEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_LsyLkBaqEduSTJywppIxVQ CRC: 1956169730 --><p>
+ Ensure that the development and test architectures are defined. Note any architecturally significant differences
+ between these environments and work with the team to devise strategies to mitigate any risks these may introduce.
+</p><!-- END:sectionDescription,_LsyLkBaqEduSTJywppIxVQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Zlw-QMP3EdmWKcx6ixEiwg CRC: 1717202689 -->Validate the architecture<!-- END:name,_Zlw-QMP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Zlw-QMP3EdmWKcx6ixEiwg CRC: 949711322 --><p>
+ Verify that the architecture decisions are appropriate for their purpose.
+</p>
+<p>
+ Development work should be performed to produce a <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>
+ that shows that the software architecture is viable. This should provide the definitive basis for validating the
+ suitability of the architecture. As the software should be developed iteratively, more than one
+ increment of the build may be required to prove the architecture. During the early stages of the project (up to
+ the end of <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA">Elaboration</a>), it may be acceptable for the software to have a incomplete or
+ prototypical feel, as it will be primarily concerned with baselining the architecture to provide a stable
+ foundation for the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA">Construction</a> phase.
+</p><!-- END:sectionDescription,_Zlw-QMP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_aRCI0MP3EdmWKcx6ixEiwg CRC: 2281511155 -->Communicate decisions<!-- END:name,_aRCI0MP3EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_aRCI0MP3EdmWKcx6ixEiwg CRC: 2969611872 --><p>
+ Ensure that those who need to act upon the architectural work understand it and are able to work with
+ it. Make sure that the description of the architecture clearly conveys not only the solution but also the
+ motivation and objectives related to the decisions that have been made in shaping the architecture. This will make
+ it easier for others to understand the architecture and to adapt it over time.
+</p><!-- END:sectionDescription,_aRCI0MP3EdmWKcx6ixEiwg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/find_and_outline_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/find_and_outline_requirements.html
new file mode 100644
index 0000000..3c2566b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/find_and_outline_requirements.html
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\find_and_outline_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: find_and_outline_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_P9cMUPV_EdmdHa9MmVPgqQ CRC: 4169312566 -->Find and Outline Requirements<!-- END:presentationName,_P9cMUPV_EdmdHa9MmVPgqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_P9cMUPV_EdmdHa9MmVPgqQ CRC: 1408528730 -->This task describes how to capture the requirements for the system.<!-- END:briefDescription,_P9cMUPV_EdmdHa9MmVPgqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_P9iS8PV_EdmdHa9MmVPgqQ CRC: 1233802591 -->Close collaboration with stakeholders on this task is critical for the success of project.<!-- END:keyConsiderations,_P9iS8PV_EdmdHa9MmVPgqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_P9iS8PV_EdmdHa9MmVPgqQ CRC: 98378258 -->The purpose of this task is to understand Stakeholder requirements and communicate these to the development team.<!-- END:purpose,_P9iS8PV_EdmdHa9MmVPgqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ckG-cCY-EdqNHcQ-rAojXw CRC: 3322021346 -->Gather information<!-- END:name,_ckG-cCY-EdqNHcQ-rAojXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ckG-cCY-EdqNHcQ-rAojXw CRC: 967771506 --><p>
+ Be prepared by gathering and reviewing information related to the problem domain, problem statement, business
+ environment and key stakeholders. Most of this information should be available in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>. You can use various techniques to make gathering
+ requirements easier. Face-to-face meetings with stakeholders is the most effective way to understand stakeholder needs
+ and to gather and validate requirements, but you must prepare in order for these meetings to run efficiently.
+ See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html" guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a> for more information.
+</p><!-- END:sectionDescription,_ckG-cCY-EdqNHcQ-rAojXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_GAr3IOz3Edq2wJOsmRwmhg CRC: 1862364187 -->Identify and capture domain terms<!-- END:name,_GAr3IOz3Edq2wJOsmRwmhg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_GAr3IOz3Edq2wJOsmRwmhg CRC: 2896861950 -->Work closely with stakeholder to make sure that ambiguous or domain-specific terms are clearly defined in the <a class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> and that you use these terms consistently.<!-- END:sectionDescription,_GAr3IOz3Edq2wJOsmRwmhg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_fDbgkCY-EdqNHcQ-rAojXw CRC: 1286658439 -->Capture requirements<!-- END:name,_fDbgkCY-EdqNHcQ-rAojXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_fDbgkCY-EdqNHcQ-rAojXw CRC: 577845406 -->Identify the types of requirements relevant to your system (see <a class="elementlinkwithtype" href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>).
+<p>
+ Work with stakeholders to identify and capture the actors and Use Cases. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a> for more information.
+</p>
+<p>
+ Work with stakeholders to identify and capture the other types of requirements relevant to your system. See
+ <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q.html" guid="_wr24gNcGEdqz_d2XWoVt6Q">Guideline: Supporting Requirements</a> for more information.
+</p><!-- END:sectionDescription,_fDbgkCY-EdqNHcQ-rAojXw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0WhHsN-eEdqiM_wFaqLjNg CRC: 832005153 -->Achieve concurrence<!-- END:name,_0WhHsN-eEdqiM_wFaqLjNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_0WhHsN-eEdqiM_wFaqLjNg CRC: 720530515 -->Conduct a review of the requirements with relevant <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>
+and the development team to ensure consistency with the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>,
+assess quality, and identify any required changes. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a> for more information.<!-- END:sectionDescription,_0WhHsN-eEdqiM_wFaqLjNg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Mgb9IC4DEduBP8F-6-95NQ CRC: 4284467680 -->Update the Work Items List<!-- END:name,_Mgb9IC4DEduBP8F-6-95NQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Mgb9IC4DEduBP8F-6-95NQ CRC: 2943620257 -->Capture references to the requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>, so that you can prioritize the work.<!-- END:sectionDescription,_Mgb9IC4DEduBP8F-6-95NQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.html
new file mode 100644
index 0000000..101339a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\find_and_outline_requirements_intent_req_ucm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: find_and_outline_requirements_intent_req_ucm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_XRKgkAFoEduDPKiaP0pu-Q CRC: 948959104 -->Capture Use Case and Actors in a Use-Case Model<!-- END:name,_XRKgkAFoEduDPKiaP0pu-Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_XRKgkAFoEduDPKiaP0pu-Q CRC: 4228180197 --><p>
+ While capturing requirements, it may be useful to identify and capture the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use
+ Case</a>s and <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a> in a <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/uc_model_intent_req_ucm,_0UCrZclgEdmt3adZL5Dmdw.html"
+ guid="_0UCrZclgEdmt3adZL5Dmdw">Use-Case Model</a>. That can help people better understand the proposed system
+ functionality and its surroundings. See <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a> for more details.
+</p><!-- END:sectionDescription,_XRKgkAFoEduDPKiaP0pu-Q -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/impl_developer_tests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/impl_developer_tests.html
new file mode 100644
index 0000000..a4216b0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/impl_developer_tests.html
@@ -0,0 +1,179 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\impl_developer_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: impl_developer_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0iL1EMlgEdmt3adZL5Dmdw CRC: 3713996132 -->Implement Developer Tests<!-- END:presentationName,_0iL1EMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0iL1EMlgEdmt3adZL5Dmdw CRC: 2809950841 -->Implement one or more tests that enable the validation of the individual software components through execution.<!-- END:briefDescription,_0iL1EMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_dWPe8KrMEdmqUqi7YGiSxw CRC: 120746317 --><p>
+ Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
+ rather than being directly based on the system requirements.
+</p>
+<p>
+ It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
+ course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
+ etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
+ additional behavior.
+</p><!-- END:mainDescription,_dWPe8KrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_dWPe8KrMEdmqUqi7YGiSxw CRC: 2953983583 --><ol>
+ <li>
+ Automate tests via a unit regression testing tool (for example, xUnit) so that tests may be run by developers
+ whenever they make changes to the code.
+ </li>
+ <li>
+ Test to the risk of the component. For example, the more critical a component is, the more important it is to test
+ it thoroughly.
+ </li>
+ <li>
+ Pair with the <a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html"
+ guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> in all steps of this task to gain insight on testing and quality
+ considerations.
+ </li>
+</ol><!-- END:keyConsiderations,_dWPe8KrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_dWPe8KrMEdmqUqi7YGiSxw CRC: 2691434226 -->Prepare to validate a software component (e.g. an operation, a class, a stored procedure) through unit testing. The result
+is one or more new developer tests.<!-- END:purpose,_dWPe8KrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: alternatives<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:alternatives,_dWPe8KrMEdmqUqi7YGiSxw CRC: 7092648 -->Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
+developer testing in identifying bugs and finding their location in the code.<!-- END:alternatives,_dWPe8KrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_2LYo8KuPEdmhFZtkg1nakg CRC: 2273716744 -->Refine scope and identify the test(s)<!-- END:name,_2LYo8KuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_2LYo8KuPEdmhFZtkg1nakg CRC: 2741027733 --><p>
+ Select the increment of work to be tested and identify developer test(s) to verify that the <a class="elementLink"
+ href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html"
+ guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> being developed behaves correctly. One source for the expected
+ behavior for a software component is the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>.
+</p>
+<p>
+ In identifying the tests or in any other part of this task, consider collaborating with a <a class="elementLink"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> who
+ should be well-versed in the issues of testing.
+</p><!-- END:sectionDescription,_2LYo8KuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_g8npoC5UEduVhuZHT5jKZQ CRC: 1377779743 -->Write the test setup<!-- END:name,_g8npoC5UEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_g8npoC5UEduVhuZHT5jKZQ CRC: 774218038 -->To successfully run a test the system must be in a known state so that the correct behavior can be defined. Implement the
+setup logic that must be performed as part of the <a class="elementLink"
+href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
+guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>.<!-- END:sectionDescription,_g8npoC5UEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_g1eDUC5VEduVhuZHT5jKZQ CRC: 2701737739 -->Define the expected results<!-- END:name,_g1eDUC5VEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_g1eDUC5VEduVhuZHT5jKZQ CRC: 1052907200 --><p>
+ Define the expected results of each test so that it can be verified.
+</p>
+<p>
+ After a test runs, you need to be able to compare the results of running the test against what was expected to happen.
+ The test is successful when the actual results match the expected results.
+</p><!-- END:sectionDescription,_g1eDUC5VEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_5WtVcKuPEdmhFZtkg1nakg CRC: 2746982786 -->Write the test logic<!-- END:name,_5WtVcKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_5WtVcKuPEdmhFZtkg1nakg CRC: 617361698 -->Write the steps that perform the actual test(s).<!-- END:sectionDescription,_5WtVcKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_j30aAC5VEduVhuZHT5jKZQ CRC: 3452165955 -->Define the test response<!-- END:name,_j30aAC5VEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_j30aAC5VEduVhuZHT5jKZQ CRC: 1078148829 -->Define the information the test(s) must produce to successfully indicate success or failure. Consider if a response of True
+or False is sufficient, or if a detailed message should be logged as well.<!-- END:sectionDescription,_j30aAC5VEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ku06gC5VEduVhuZHT5jKZQ CRC: 4075690081 -->Write clean-up code<!-- END:name,_ku06gC5VEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ku06gC5VEduVhuZHT5jKZQ CRC: 4275660162 -->Identify, and then implement, the steps to be followed in order to restore the environment to the original state for each
+test. The goal is to ensure that there are no side effects from running the tests.<!-- END:sectionDescription,_ku06gC5VEduVhuZHT5jKZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_6wZFMKuPEdmhFZtkg1nakg CRC: 2628067035 -->Test the test<!-- END:name,_6wZFMKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_6wZFMKuPEdmhFZtkg1nakg CRC: 3768184763 --><p>
+ Verify that each developer test works correctly. To do this:
+</p>
+<ul>
+ <li>
+ Run the test(s), observe their behavior, and fix any defects in the tests.
+ </li>
+ <li>
+ Ensure that the expected results are defined properly and that they're being checked correctly.
+ </li>
+ <li>
+ Check the clean-up logic for each test.
+ </li>
+ <li>
+ Ensure that each developer test works within your test suite framework.
+ </li>
+</ul><!-- END:sectionDescription,_6wZFMKuPEdmhFZtkg1nakg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/implement_solution.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/implement_solution.html
new file mode 100644
index 0000000..7640504
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/implement_solution.html
@@ -0,0 +1,242 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\implement_solution.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implement_solution.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0hyzgMlgEdmt3adZL5Dmdw CRC: 4143109244 -->Implement the Solution<!-- END:presentationName,_0hyzgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0hyzgMlgEdmt3adZL5Dmdw CRC: 3037338676 -->Implement source code to provide new functionality or fix defects.<!-- END:briefDescription,_0hyzgMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_d2aMwKrMEdmqUqi7YGiSxw CRC: 2658401817 --><p>
+ Usually, this task is focused on a specific element, such as a class or component, but it does not need to be.
+</p>
+<p>
+ You implement a portion of the design during each iteration by performing this task. You can perform the task any
+ number of times during an iteration.
+</p>
+<p>
+ Modify the implementation incrementally. Make additions and changes to the implementation for an issue, run the unit
+ and regression tests, and then complete the issue before moving on to other issues.
+</p>
+<p>
+ See the associated guidelines for information on how to perform the steps described in this task.
+</p><!-- END:mainDescription,_d2aMwKrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_d2aMwKrMEdmqUqi7YGiSxw CRC: 4055917555 --><p>
+ This task is complete once the build has successfully completed. The implementation should then be immediately tested.
+</p><!-- END:keyConsiderations,_d2aMwKrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_d2aMwKrMEdmqUqi7YGiSxw CRC: 2968539442 --><p>
+ The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to
+ fix one or more defects. The result is typically new or modified source code, which is generally referred to <em>the
+ implementation</em>.<br />
+</p><!-- END:purpose,_d2aMwKrMEdmqUqi7YGiSxw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_2sxisE2iEduU655MA_3VXg CRC: 2952321852 -->Determine a strategy<!-- END:name,_2sxisE2iEduU655MA_3VXg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_2sxisE2iEduU655MA_3VXg CRC: 2880397127 --><p>
+ You need to determine a strategy, based on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a> of the work item being worked on, for how you're going to implement it.
+ Your fundamental options are:
+</p>
+<ol>
+ <li>
+ Apply existing, reusable assets.
+ </li>
+ <li>
+ Model the design in detail and generate the source code (by model transformation).
+ </li>
+ <li>
+ Write the source code.
+ </li>
+ <li>
+ Any combination thereof.
+ </li>
+</ol><!-- END:sectionDescription,_2sxisE2iEduU655MA_3VXg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_iMMWoKuPEdmhFZtkg1nakg CRC: 2355737883 -->Identify opportunities for reuse<!-- END:name,_iMMWoKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_iMMWoKuPEdmhFZtkg1nakg CRC: 1065575463 --><p>
+ Complete the implementation by reusing code at every opportunity.
+</p>
+<p>
+ Identify existing code or other implementation elements that you can reuse in the portion of the <a class="elementLink" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> that you are creating or changing. A comprehensive understanding
+ of the overall design is helpful, because it is best to leverage reuse opportunities when you have a thorough
+ understanding of the proposed solution.<br />
+</p><!-- END:sectionDescription,_iMMWoKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_pjehkNb7Edq_LtLvi4w2yw CRC: 211604240 -->Transform design into implementation<!-- END:name,_pjehkNb7Edq_LtLvi4w2yw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_pjehkNb7Edq_LtLvi4w2yw CRC: 3423206138 --><p>
+ If you are using sophisticated modeling tools, you should be able to generate a portion of the required source code
+ from the model. Note that programming is often required to complete the implementation after the design
+ model has been transformed into code.
+</p><!-- END:sectionDescription,_pjehkNb7Edq_LtLvi4w2yw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_mFQ58KuPEdmhFZtkg1nakg CRC: 1364477963 -->Write source code<!-- END:name,_mFQ58KuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_mFQ58KuPEdmhFZtkg1nakg CRC: 3270119313 --><p>
+ You should strive to reuse and/or generate code wherever possible, but you will still need to do some
+ programming. To do so, consider the following:
+</p>
+<ul>
+ <li>
+ Examine the requirements. Because some requirements information does not translate directly into your design
+ you should examine the requirement(s) (potentially including both the <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) to ensure that they are fully realized in the
+ implementation.
+ </li>
+ <li>
+ Refactor your code to improve its design. <a class="elementLink" href="./../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> is a technique where you improve the quality of your code via
+ small changes.
+ </li>
+ <li>
+ Tuning the results of the existing implementation by improving performance, the user interface, security, and other
+ nonfunctional areas.
+ </li>
+ <li>
+ Adding missing details, such as completing the logic of operations or adding supporting classes and data structures
+ </li>
+ <li>
+ Handling boundary conditions.
+ </li>
+ <li>
+ Dealing with unusual circumstances or error states.
+ </li>
+ <li>
+ Restricting behavior (preventing users from executing illegal flows, scenarios, or combinations of options).
+ </li>
+ <li>
+ Adding critical sections for multi-threaded or re-entrant code.<br />
+ </li>
+</ul><!-- END:sectionDescription,_mFQ58KuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_-0yzwDH4EduMqpUNhaTSRA CRC: 1454371900 -->Create a build<!-- END:name,_-0yzwDH4EduMqpUNhaTSRA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_-0yzwDH4EduMqpUNhaTSRA CRC: 2933548742 --><p>
+ Create a new <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>. This might involve simply running an existing build script and/or updating an
+ existing build script.
+</p><!-- END:sectionDescription,_-0yzwDH4EduMqpUNhaTSRA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ni25UKuPEdmhFZtkg1nakg CRC: 4213619129 -->Evaluate the implementation<!-- END:name,_ni25UKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ni25UKuPEdmhFZtkg1nakg CRC: 2586302880 --><p>
+ Verify that the implementation is fit for its purpose. Examine the code for its suitability to perform its
+ intended function. This is a quality assurance step that you perform in addition to testing, and it is described in
+ other tasks. Consider these strategies:
+</p>
+<ul>
+ <li>
+ Pair programming. By pairing to implement the code in the first place, you effectively evaluate the code as
+ its being written.
+ </li>
+ <li>
+ Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a
+ reminder reference.
+ </li>
+ <li>
+ Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or
+ set the compiler to the most detailed warning level.
+ </li>
+ <li>
+ Use tools that can visualize the code. Code visualization, such as the UML visualizations in the Eclipse IDE,
+ help developers identify issues such as excessive coupling or circular dependencies.
+ </li>
+ <li>
+ Perform informal, targeted code inspections. Ask colleagues to review small critical sections of code and code
+ with significant churn. Avoid reviewing large sections of code.
+ </li>
+ <li>
+ Use the Tester to assure the implementation is testable and understandable to testing resources.
+ </li>
+</ul>
+<p>
+ Improve the implementation based on the results of these evaluations.
+</p><!-- END:sectionDescription,_ni25UKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_q5XiIKuPEdmhFZtkg1nakg CRC: 3985354331 -->Communicate significant decisions<!-- END:name,_q5XiIKuPEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_q5XiIKuPEdmhFZtkg1nakg CRC: 4224173571 --><p>
+ Communicate the impact of unexpected changes to the design and requirements.
+</p>
+<p>
+ The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact
+ of issues discovered during implementation must be incorporated into future decisions. If appropriate, update use cases
+ and supporting requirements to reflect ambiguities that you identified and resolved in the implementation so they can
+ be tested and you can manage the <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> expectations appropriately. Similarly, update the design to reflect
+ new constraints and issues uncovered during implementation to be sure that the new information is communicated to other
+ developers.
+</p>
+<p>
+ Usually, there is no need for a change request if the required change is small and the same person is designing and
+ implementing the class. That individual can make the design change directly. If the required change has a broad impact,
+ such as a change in a public operation, it may be necessary to communicate that change to the other team members
+ through a change request.<br />
+ <br />
+</p><!-- END:sectionDescription,_q5XiIKuPEdmhFZtkg1nakg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/implement_tests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/implement_tests.html
new file mode 100644
index 0000000..f0a296d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/implement_tests.html
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\implement_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implement_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0jO98MlgEdmt3adZL5Dmdw CRC: 467065627 -->Implement Tests<!-- END:presentationName,_0jO98MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0jO98MlgEdmt3adZL5Dmdw CRC: 363878856 -->Implement one or more test artifacts to enable the validation of the software product through actually running the system. Combine tests to facilitate appropriate breadth and depth of test coverage.<!-- END:briefDescription,_0jO98MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NrbRUKeqEdmKDbQuyzCoqQ CRC: 776360132 --><p>
+ To implement one or more tests that can be executed to validate a system.
+</p><!-- END:purpose,_NrbRUKeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_S8JzsKuSEdmhFZtkg1nakg CRC: 17534694 -->Select appropriate implementation technique<!-- END:name,_S8JzsKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_S8JzsKuSEdmhFZtkg1nakg CRC: 3668959222 --><p>
+ Select one or several of the following test implementation techniques:
+</p>
+<ul>
+ <li>
+ manual test scripts
+ </li>
+ <li>
+ programmed test scripts
+ </li>
+ <li>
+ recorded test scripts
+ </li>
+</ul><!-- END:sectionDescription,_S8JzsKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_VN5M0KuSEdmhFZtkg1nakg CRC: 3796032468 -->Implement the test<!-- END:name,_VN5M0KuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_VN5M0KuSEdmhFZtkg1nakg CRC: 3485335602 --><p>
+ Using your test-ideas list and test cases as inputs, set up your specifications, spreadsheet, or automated
+ tool to record scripts needed to conduct the test. If you are recording explicit steps for your test,
+ navigate through the system under test identifying steps, groups of related steps, verification points, and control
+ points.
+</p><!-- END:sectionDescription,_VN5M0KuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_WvBoYKuSEdmhFZtkg1nakg CRC: 1091386899 -->Establish external data sets<!-- END:name,_WvBoYKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_WvBoYKuSEdmhFZtkg1nakg CRC: 2925873557 -->Create containers for your test data sets. Separate the production data from generated data. Associate your data sets with
+a given build of the system under test. If data sets are associated with a particular part of the system under test,
+mark them accordingly.<!-- END:sectionDescription,_WvBoYKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_X0dmcKuSEdmhFZtkg1nakg CRC: 3804472598 -->Verify Test implementation<!-- END:name,_X0dmcKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_X0dmcKuSEdmhFZtkg1nakg CRC: 3858350611 --><p>
+ Run the test script to verify that it implements the tests correctly. For manual testing, conduct a walkthrough of
+ the test script. For automated tests, verify that the test implementation will involve some degree of the
+ configuration of the testing tool.
+</p><!-- END:sectionDescription,_X0dmcKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Y-ABYKuSEdmhFZtkg1nakg CRC: 2274590756 -->Organize tests into test suites<!-- END:name,_Y-ABYKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Y-ABYKuSEdmhFZtkg1nakg CRC: 2296266041 --><p>
+ Collect tests into related groups. The grouping you use depends on your test environment. For example, you can organize
+ test cases, test scripts, and test data hierarchically to facilitate navigation within a test, as well as within the
+ suite. Another form of test suite organization is based on system functionality and uses the quality attributes of
+ usability, reliability, and performance as categories for groups. You may choose to follow an iteration-based test
+ suite organization, instead. Since the system under test is undergoing its own evolution, create your test suites
+ to facilitate regression testing, as well as system configuration identification.
+</p><!-- END:sectionDescription,_Y-ABYKuSEdmhFZtkg1nakg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/manage_iteration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/manage_iteration.html
new file mode 100644
index 0000000..90af03f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/manage_iteration.html
@@ -0,0 +1,127 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\manage_iteration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: manage_iteration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8S2aICbYEdqh1LYUOGRh2A CRC: 475284402 -->Manage Iteration<!-- END:presentationName,_8S2aICbYEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_8S2aICbYEdqh1LYUOGRh2A CRC: 3426038205 -->Assess project status and identify any blocking issues and/or opportunities. Identify and manage exceptions, problems and risks. Communicate project status.<!-- END:briefDescription,_8S2aICbYEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-PbfqVxB_j9KN-Jx39_pEUA CRC: 615557520 --><p>
+ Identify blocking issues and/or opportunities early to take action and keep the project on track.
+</p><!-- END:purpose,-PbfqVxB_j9KN-Jx39_pEUA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_OE65ICuxEdqTIKp3l5PtzQ CRC: 116850368 -->Capture status<!-- END:name,_OE65ICuxEdqTIKp3l5PtzQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_OE65ICuxEdqTIKp3l5PtzQ CRC: 2351524981 --><p>
+ The project manager needs to continuously monitor the project to ensure its appropriate progress, and to enable the
+ team to react as soon as possible to any change. Many alternative means may be used to track the status:
+</p>
+<ul>
+ <li>
+ Quick, daily meetings with the entire project team, also called "scrum meetings” are useful to understand what team
+ members have accomplished since the last meeting, and what they plan to accomplish before the next meeting. It
+ also allows the team to identify any blocking issues. See <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[SCH04]</a> for guidance on scrum meetings.
+ </li>
+ <li>
+ Basic metrics, ideally automatically generated from the tools at hand, or manually assembled. The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a> should outline which metrics the project should use.
+ Examples of such metrics include <a class="elementLinkWithType" href="./../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> and <a class="elementLinkWithType" href="./../../openup_basic/guidances/reports/project_burndown,_ePrt8Dj3EduxovfWMDsntw.html" guid="_ePrt8Dj3EduxovfWMDsntw">Report: Project Burndown</a> charts, which are reports on the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. See also <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html" guid="_0mYYkMlgEdmt3adZL5Dmdw">Concept: Metrics</a> for more information.
+ </li>
+</ul>
+<br /><!-- END:sectionDescription,_OE65ICuxEdqTIKp3l5PtzQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ztF0UCuxEdqTIKp3l5PtzQ CRC: 3829857704 -->Communicate status<!-- END:name,_ztF0UCuxEdqTIKp3l5PtzQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ztF0UCuxEdqTIKp3l5PtzQ CRC: 3040873295 --><p>
+ Communicating project status is as important as gathering it. Communication is usually done at two levels: the task
+ level and project level.
+</p>
+<ul>
+ <li>
+ <strong>Task Level – Communicated within the project team:</strong> status can be communicated through quick, daily
+ meetings. This allows you to combine the status capturing with the status communications.
+ </li>
+ <li>
+ <strong>Project Level – Communicated to the stakeholders and the project team:</strong> status is usually
+ communicated through core metrics rather than detailed information. This can be done through meetings, e-mail, or
+ Web publishing.
+ </li>
+</ul><!-- END:sectionDescription,_ztF0UCuxEdqTIKp3l5PtzQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oIZdkCbZEdqh1LYUOGRh2A CRC: 395784438 -->Handle exceptions and problems<!-- END:name,_oIZdkCbZEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oIZdkCbZEdqh1LYUOGRh2A CRC: 687981015 --><p>
+ One of the project manager's key responsibilities is to know about the project team's problems and issues. The manager
+ needs to focus on problems that are blocking progress. A quick, daily meeting is usually a good way to monitor those
+ problems and issues.
+</p>
+<p>
+ Identify the cause and impact of problems and exceptions as they arise. Identify possible solutions for problems that
+ have an immediate impact on the short-term goals and objectives and identify who needs to be involved in implementing
+ the solution. Then, define the corrective actions and implement them. <br />
+</p><!-- END:sectionDescription,_oIZdkCbZEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_xiFJwCbZEdqh1LYUOGRh2A CRC: 509729981 -->Identify and manage risks<!-- END:name,_xiFJwCbZEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_xiFJwCbZEdqh1LYUOGRh2A CRC: 179667628 --><p>
+ Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. The
+ risk list should be revisited weekly, or as a minimum once per iteration, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a> and <a class="elementLinkWithType" href="./../../openup_basic/workproducts/risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Artifact: Risk List</a> for more details. The entire team should be involved in
+ identifying and mitigating risk.
+</p><!-- END:sectionDescription,_xiFJwCbZEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Br6VECuxEdqTIKp3l5PtzQ CRC: 479485767 -->Reprioritize work as needed<!-- END:name,_Br6VECuxEdqTIKp3l5PtzQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Br6VECuxEdqTIKp3l5PtzQ CRC: 3611697103 -->When a team is falling significantly behind, or critical problems occur, it may be necessary to reprioritize tasks to
+ensure that the team delivers a useful product increment by the end of the iteration, while maximizing stakeholder value.
+In these rare cases, the project manager should work with the team and stakeholders on revising the iteration plan and, as
+necessary, reduce the emphasis on less critical tasks.<!-- END:sectionDescription,_Br6VECuxEdqTIKp3l5PtzQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/plan_iteration.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/plan_iteration.html
new file mode 100644
index 0000000..6c2db09
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/plan_iteration.html
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\plan_iteration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plan_iteration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0keUEMlgEdmt3adZL5Dmdw CRC: 383256678 -->Plan Iteration<!-- END:presentationName,_0keUEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0keUEMlgEdmt3adZL5Dmdw CRC: 3530237166 -->Plan the scope and responsibilities for a single iteration.<!-- END:briefDescription,_0keUEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_Wk7noKe1EdmGSrcKGOYDGg CRC: 925856257 --><p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ Develop a fine-grained plan for a single iteration, identifying the goals and evaluation criteria of an iteration
+ (usually the next one).
+</p><!-- END:purpose,_Wk7noKe1EdmGSrcKGOYDGg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_CtKCMMBHEdqSgKaj2SZBmg CRC: 598045111 -->Define the iteration objectives<!-- END:name,_CtKCMMBHEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_CtKCMMBHEdqSgKaj2SZBmg CRC: 1493795383 --><p>
+ At the beginning of an iteration, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a> works with the team to define 1-5 objectives. These objectives should be a refinement of the
+ iteration objectives found in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>, and should provide high-level direction to what should be
+ targeted for the iteration. The objectives should be driven based on <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a> priorities, and will be revised as the iteration plan is finalized. The objectives are
+ usually defined as high-level capabilities or scenarios that need to be implemented and tested during the
+ iteration.<br />
+</p><!-- END:sectionDescription,_CtKCMMBHEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_307v0MMsEdmdo9HxCRR_Gw CRC: 233233971 -->Produce detailed plan<!-- END:name,_307v0MMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_307v0MMsEdmdo9HxCRR_Gw CRC: 298288182 -->The <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a> works with the rest of the team, and especially the project
+stakeholders, to identify the high-priority work items from the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to be addressed within the iteration. The high-level
+objectives provide guidance on what work items should be considered. The team should break down work items so they fit
+within the iteration as necessary. Actual effort to complete each Work Item should be estimated. When a team has decided to
+take on a Work Item, it will assign the work to one or several team members. Ideally, this is done by team members signing
+up to do the work, since this makes people motivated and committed to doing the job, but based on culture, you may instead
+have the project manager assign the work.<!-- END:sectionDescription,_307v0MMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_7Hqr4MMsEdmdo9HxCRR_Gw CRC: 3549691797 -->Define evaluation criteria<!-- END:name,_7Hqr4MMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_7Hqr4MMsEdmdo9HxCRR_Gw CRC: 2064344630 --><p>
+ Each iteration should include testing as a part of the evaluation, and the test objectives and test cases needs to be
+ detailed. Other evaluation criteria may include successful demonstrations to key stakeholders, or favorable usage by a
+ small group of target users.<br />
+</p><!-- END:sectionDescription,_7Hqr4MMsEdmdo9HxCRR_Gw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/plan_the_project.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/plan_the_project.html
new file mode 100644
index 0000000..af0997d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/plan_the_project.html
@@ -0,0 +1,190 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\plan_the_project.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plan_the_project.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0lC70MlgEdmt3adZL5Dmdw CRC: 871430590 -->Plan Project<!-- END:presentationName,_0lC70MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0lC70MlgEdmt3adZL5Dmdw CRC: 2413656457 -->Define a coarse-grained plan for the project.<!-- END:briefDescription,_0lC70MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_fPbdIKe2Edmzde8VFK5bxg CRC: 3594467576 -->To describe a roadmap that provides direction to the team and continually adapt it based on feedback and changes in the
+environment.<!-- END:purpose,_fPbdIKe2Edmzde8VFK5bxg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_lrYj0MBAEdqSgKaj2SZBmg CRC: 2521238138 -->Evaluate risks<!-- END:name,_lrYj0MBAEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_lrYj0MBAEdqSgKaj2SZBmg CRC: 3015748586 --><p>
+ The project manager evaluates project risks with the team and updates the <a class="elementLink" href="./../../openup_basic/workproducts/risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Risk List</a>. The risk list will aid the team in prioritization of what to do in which iteration. Higher-ranked risks are
+ addressed in the earlier iterations.
+</p><!-- END:sectionDescription,_lrYj0MBAEdqSgKaj2SZBmg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_k1bY4MMsEdmdo9HxCRR_Gw CRC: 2517186121 -->Determine project size and scope<!-- END:name,_k1bY4MMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_k1bY4MMsEdmdo9HxCRR_Gw CRC: 3217445886 --><p>
+ Analyze the size and the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> of the project, and whether it is realistic to deliver what is asked for
+ within the constraints of the project.
+</p>
+<p>
+ If the project is feature-driven, meaning that release criteria is defined as a set of features captured in the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, the team assesses the size of these work items, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. They then look at how many people they would need to
+ complete these work items, which gives them a ballpark understanding of project duration, staffing profile, and scope.
+</p>
+<p>
+ If the project instead is date-driven, the team assesses how much work can roughly be done in the time-frame given and
+ using the available team, captured as a candidate list of work items.
+</p>
+<p>
+ The end result of the two approaches is the same; a rough understanding of the size of the capabilities to be
+ delivered, the size of the team, and expected time of completion.
+</p><!-- END:sectionDescription,_k1bY4MMsEdmdo9HxCRR_Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_OfFTEABjEdqHlpDr8LcRqg CRC: 232507844 -->Define length, number, and objectives of iterations<!-- END:name,_OfFTEABjEdqHlpDr8LcRqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_OfFTEABjEdqHlpDr8LcRqg CRC: 2702495349 --><p>
+ Determine iteration length, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>, or use 4 weeks as default iteration length. Use iteration length
+ to assess target velocity, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. Based on the target velocity and overall size of the
+ project, calculate the number of iterations required.
+</p>
+<p>
+ Determine 1-3 high-level objectives for each iteration. The goal is to create a high-level plan outlining how you can
+ build the resulting application in the given set of iterations. The plan will change as you learn more, so time-box
+ this analysis to a few hours or less. Use the Work Items List to outline what features to implement in what iteration,
+ putting top priority work items first. This can be done rapidly by leveraging expected velocity and size estimate of
+ work items.
+</p>
+<p>
+ Produce a brief summary of your analysis in your plan by documenting 1-3 objectives for each iteration. Do not commit
+ individual work items to the plan, since this will force too much re-planning. For some projects, you may have to wait
+ until after the first iteration until you can provide a meaningful plan at this level of detail.<br />
+</p><!-- END:sectionDescription,_OfFTEABjEdqHlpDr8LcRqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_qcOtIE5dEdu3aqt7VHtzgw CRC: 3313139274 -->Define phase milestones and refine iteration objectives<!-- END:name,_qcOtIE5dEdu3aqt7VHtzgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_qcOtIE5dEdu3aqt7VHtzgw CRC: 716037130 --><p>
+ Phases provide a focus for a team on meeting key management objectives, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>. For example the Elaboration phase should answer the question “Do
+ we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?”
+</p>
+<p>
+ With this in mind, the project manager determines the start and end dates of the phases and aligns the content of the
+ iterations with the perspective of the phase. Therefore the objectives of the iterations assigned to a phase, need to
+ map to the goals of its phase. The milestones, which guard the transition from one phase to another, will provide
+ checkpoints if these goals are satisfied. Revisit the plan to see if you should change the focus of iterations to
+ allow more rapid completion of certain phases.
+</p><!-- END:sectionDescription,_qcOtIE5dEdu3aqt7VHtzgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_F2dQYABjEdqHlpDr8LcRqg CRC: 2444141415 -->Map roles to team members<!-- END:name,_F2dQYABjEdqHlpDr8LcRqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_F2dQYABjEdqHlpDr8LcRqg CRC: 2171074615 --><p>
+ The project manager assigns project members (people) to roles according to a table like this:<br />
+ <br />
+</p>
+<table style="WIDTH: 227px; HEIGHT: 116px" cellspacing="2" cellpadding="2" width="227" border="2">
+ <tbody>
+ <tr>
+ <td>
+ <strong>Team Member </strong>
+ </td>
+ <td>
+ <strong>Analyst</strong>
+ </td>
+ <td>
+ <strong>Developer</strong>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ John
+ </td>
+ <td>
+ X
+ </td>
+ <td>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Judy
+ </td>
+ <td>
+ </td>
+ <td>
+ X
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Jim
+ </td>
+ <td>
+ X
+ </td>
+ <td>
+ X
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<p>
+ The project manager needs to make sure that the roles are staffed according to skills and interests and that every role
+ is covered.
+</p><!-- END:sectionDescription,_F2dQYABjEdqHlpDr8LcRqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_toVK0E5fEdu3aqt7VHtzgw CRC: 2130441254 -->Tune and get concurrence on the plan<!-- END:name,_toVK0E5fEdu3aqt7VHtzgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_toVK0E5fEdu3aqt7VHtzgw CRC: 2585633942 -->Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of the
+project and make adjustments as necessary.<!-- END:sectionDescription,_toVK0E5fEdu3aqt7VHtzgw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/request_change.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/request_change.html
new file mode 100644
index 0000000..a9f77a8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/request_change.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\request_change.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: request_change.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0mwzEclgEdmt3adZL5Dmdw CRC: 3689341175 -->Request Change<!-- END:presentationName,_0mwzEclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0mwzEclgEdmt3adZL5Dmdw CRC: 3669369891 -->Capture and record change requests.<!-- END:briefDescription,_0mwzEclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_qEkewKuoEdmEGLSmmpF1Sg CRC: 2463323691 -->Gather change request information<!-- END:name,_qEkewKuoEdmEGLSmmpF1Sg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_qEkewKuoEdmEGLSmmpF1Sg CRC: 2997100252 --><p> Gather the information required to describe the change request. This should
+ include a description of the requested change, the reason for the change (defect
+ or enhancement), the artifact affected,
+ including the version, and the priority
+ of the change. If possible, provide an estimate of the effort required
+ to implement the change. </p><!-- END:sectionDescription,_qEkewKuoEdmEGLSmmpF1Sg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_r2aP0KuoEdmEGLSmmpF1Sg CRC: 2312306278 -->Update the Work Item List<!-- END:name,_r2aP0KuoEdmEGLSmmpF1Sg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_r2aP0KuoEdmEGLSmmpF1Sg CRC: 240993937 -->Update the <a class="elementLinkWithType" href="./../../basic_unified_process/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
+Work Items List</a> to document the information
+that you gathered in the previous step.<!-- END:sectionDescription,_r2aP0KuoEdmEGLSmmpF1Sg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/run_developer_tests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/run_developer_tests.html
new file mode 100644
index 0000000..32a8ddd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/run_developer_tests.html
@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\run_developer_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: run_developer_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0iYCUMlgEdmt3adZL5Dmdw CRC: 1641130134 -->Run Developer Tests<!-- END:presentationName,_0iYCUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0iYCUMlgEdmt3adZL5Dmdw CRC: 2361968274 -->Run tests of the individual software components to verify that their internal structures work as specified.<!-- END:briefDescription,_0iYCUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_W6rc0Lv7EdmmUvZAZjqE3g CRC: 3718479650 --><p>
+ It is common to require that code pass all Developer tests before it can be delivered in an integrated build (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/promoting_builds,_SM4YIL6dEdqti4GwqTkbsQ.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Builds</a>).
+</p>
+<p>
+ Pair with the Tester during all steps of this task to gain insight on testing and quality considerations.
+</p><!-- END:keyConsiderations,_W6rc0Lv7EdmmUvZAZjqE3g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_W6rc0Lv7EdmmUvZAZjqE3g CRC: 3502019315 -->To verify that the implementation works as specified.<!-- END:purpose,_W6rc0Lv7EdmmUvZAZjqE3g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_MSnQsMP4EdmWKcx6ixEiwg CRC: 1641130134 -->Run Developer Tests<!-- END:name,_MSnQsMP4EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_MSnQsMP4EdmWKcx6ixEiwg CRC: 1291443858 --><p>
+ Run the <a class="elementLink" href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>s. The procedure will vary, depending on whether the test is manual or
+ automated and whether additional test components are necessary, such as drivers or stubs.
+</p>
+<p>
+ To run the tests, you need to make sure that you have initialized the test environment with all necessary elements,
+ such as software, hardware, tools, data, and so on.
+</p>
+<p>
+ Automated tests will often update a <a class="elementLink"
+ href="./../../openup_basic/workproducts/test_log,_0ZlSsMlgEdmt3adZL5Dmdw.html" guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test
+ Log</a> which you can evaluate to determine where your tests went wrong.
+</p><!-- END:sectionDescription,_MSnQsMP4EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_NkRF0MP4EdmWKcx6ixEiwg CRC: 2972435227 -->Evaluate test execution<!-- END:name,_NkRF0MP4EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_NkRF0MP4EdmWKcx6ixEiwg CRC: 1624875948 --><p>
+ Evaluate the test execution by analyzing the test run.
+</p>
+<p>
+ Testing will complete either normally or abnormally. For correctly implemented tests, a normal
+ completion represents a passed test, though it could warrant additional examination of the test log to ensure the
+ test ran as expected. Abnormal termination could be premature termination or just a test that does not
+ complete as intended.
+</p>
+<p>
+ Review the test log to understand any reported failures, warnings, or unexpected results. The cause of the problem(s)
+ might be that the implementation element being tested is faulty, a problem with the developer tests, or a problem with
+ the environment.
+</p><!-- END:sectionDescription,_NkRF0MP4EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_SXPFkMP4EdmWKcx6ixEiwg CRC: 1739647734 -->Respond to test results<!-- END:name,_SXPFkMP4EdmWKcx6ixEiwg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_SXPFkMP4EdmWKcx6ixEiwg CRC: 94705704 --><p>
+ Determine the appropriate corrective action to recover from a "failed" developer test run. If the implementation
+ element under test is faulty, fix the problem if possible and rerun the tests. If the problem is serious and cannot be
+ immediately addressed, perform the task <a class="elementLink"
+ href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request
+ Change</a> to report the defect. If the developer test is faulty fix the test and rerun the tests. If there was a
+ problem with the environment,resolve it and then rerun the tests.
+</p>
+<p>
+ When the developer tests pass, communicate the results. If the passing of these tests represent completion of a
+ requirement, this could involve updating the status of something on the <a class="elementLink"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
+</p><!-- END:sectionDescription,_SXPFkMP4EdmWKcx6ixEiwg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/run_tests.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/run_tests.html
new file mode 100644
index 0000000..7bb06ee
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/tasks/run_tests.html
@@ -0,0 +1,241 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\tasks\run_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: run_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0jVEkMlgEdmt3adZL5Dmdw CRC: 2545677411 -->Run Tests<!-- END:presentationName,_0jVEkMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0jVEkMlgEdmt3adZL5Dmdw CRC: 3595529747 -->Run the appropriate collections of tests required to evaluate product quality. Capture test results that facilitate ongoing assessment of the product.<!-- END:briefDescription,_0jVEkMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NrbRUqeqEdmKDbQuyzCoqQ CRC: 4087532239 -->Run the system test, which addresses functional and system integration tests and, potentially, user acceptance tests.<!-- END:mainDescription,_NrbRUqeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_NrbRUqeqEdmKDbQuyzCoqQ CRC: 1019361853 --><ul>
+ <li>
+ Run the test regularly. Ideally, that means whenever the code changes but, minimally, once a day.
+ </li>
+ <li>
+ It should be possible for anyone on the test team to run the test at any time.
+ </li>
+</ul><!-- END:keyConsiderations,_NrbRUqeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NrbRUqeqEdmKDbQuyzCoqQ CRC: 1105804481 -->To execute tests and evaluate the test results.<!-- END:purpose,_NrbRUqeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_fR4aQKuSEdmhFZtkg1nakg CRC: 3985836831 -->Schedule test execution<!-- END:name,_fR4aQKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_fR4aQKuSEdmhFZtkg1nakg CRC: 1420022442 --><p>
+ Run the system tests as often as possible. Ideally, run the tests whenever new code is checked into the
+ version control tool.
+</p>
+<p>
+ For larger systems, this will be too expensive. The tests may take several hours to run; therefore, you'll need to
+ schedule tests less frequently. If possible, however, run the tests several times a day. As a minimum,
+ run automated tests each night.
+</p><!-- END:sectionDescription,_fR4aQKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_gV408KuSEdmhFZtkg1nakg CRC: 2579482424 -->Run the test<!-- END:name,_gV408KuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_gV408KuSEdmhFZtkg1nakg CRC: 3515341533 --><p>
+ Run the test at the scheduled time based on the instructions in the <a class="elementLink" href="./../../openup_basic/workproducts/test_script,_0ZfMEMlgEdmt3adZL5Dmdw.html" guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test Script</a>. It is best that the script be automated.
+</p>
+<p>
+ Good practices:
+</p>
+<ol>
+ <li>
+ Run the test in a separate test environment.
+ </li>
+ <li>
+ Ensure that you run the test against the latest clean build.
+ </li>
+ <li>
+ The first step of the test should be to set up the test environment (ensure that the network is available, that the
+ test database is available and reset to a known state, and so on).
+ </li>
+</ol><!-- END:sectionDescription,_gV408KuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_hfVJQKuSEdmhFZtkg1nakg CRC: 2405848560 -->Close test run<!-- END:name,_hfVJQKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_hfVJQKuSEdmhFZtkg1nakg CRC: 2769718961 -->Close the actual run as the last step of running the test. To do this:
+<ol>
+ <li>
+ Close the test logs. The test log files should be closed and placed in the appropriate folder or directory.
+ </li>
+ <li>
+ Announce results. Send a notice to everyone involved in the project informing them of the result of the test run
+ and where they can find the test logs.
+ </li>
+</ol><!-- END:sectionDescription,_hfVJQKuSEdmhFZtkg1nakg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_sQaC4DO2EduqsLmIADMQ9g CRC: 556134948 -->Examine the test log<!-- END:name,_sQaC4DO2EduqsLmIADMQ9g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_sQaC4DO2EduqsLmIADMQ9g CRC: 309771938 --><p>
+ Collect and compile information from test execution logs so you can:
+</p>
+<ul>
+ <li>
+ Capture the high-impact and risk issues discovered in running the tests.
+ </li>
+ <li>
+ Identify errors in test creation, data inputs, or integrating applications and any architectural anomalies.
+ </li>
+ <li>
+ Isolate the target of the test to determine failure points.
+ </li>
+ <li>
+ Diagnose failure symptoms and characteristics.
+ </li>
+ <li>
+ Assess and identify possible solutions.
+ </li>
+</ul>
+<p>
+ After completing these steps, verify that you have enough details to determine the impact of the results. In addition,
+ make sure that enough information exists to assist individuals who are performing dependent tasks.
+</p><!-- END:sectionDescription,_sQaC4DO2EduqsLmIADMQ9g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_0XzAwDO2EduqsLmIADMQ9g CRC: 47886765 -->Identify failures and propose solutions<!-- END:name,_0XzAwDO2EduqsLmIADMQ9g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_0XzAwDO2EduqsLmIADMQ9g CRC: 3417445203 --><p>
+ Identify whether or not the test has failed and propose a solution based on the type of test and category of
+ failure. The approach to testing will determine the identified failures and candidates for solutions.
+</p>
+<p>
+ Tests that are programmer supporting are used to help prepare and ensure confidence in the code. When identifying
+ failures and proposing solutions for programmer supporting tests:
+</p>
+<ul>
+ <li>
+ Failures will be identified at an object or element level.
+ </li>
+ <li>
+ Solutions will be to help clarify the problem.
+ </li>
+</ul>
+<p>
+ Test that are business supporting are used to uncover prior mistakes and omissions.
+</p>
+<ul>
+ <li>
+ Failures will identify omissions in requirements.
+ </li>
+ <li>
+ Solutions will help to clarify expectations of the system.
+ </li>
+</ul>
+<p>
+ After you have this information and the steps proposed to resolve the failures, you can effectively categorize the type
+ of failure and the appropriate type of solution.
+</p>
+<p>
+ See <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[MAR03]</a> for more information.
+</p><!-- END:sectionDescription,_0XzAwDO2EduqsLmIADMQ9g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_3t6oADO2EduqsLmIADMQ9g CRC: 512718462 -->Communicate test results<!-- END:name,_3t6oADO2EduqsLmIADMQ9g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_3t6oADO2EduqsLmIADMQ9g CRC: 2039249076 --><p>
+ Communicate the test results to the team. For failed tests this might involve adding bugs to the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
+</p>
+<p>
+ Communicating test results can affect the perception of the effectiveness of the tests. When communicating test
+ results, it is important that you:
+</p>
+<ul>
+ <li>
+ Know the audience, so that appropriate information is communicated appropriately
+ </li>
+ <li>
+ Run tests or scenarios that are likely to uncover the high-impact and risk issues or represent actual use of the
+ system
+ </li>
+</ul>
+<p>
+ When preparing test result reports, answer the following questions:
+</p>
+<ul>
+ <li>
+ How many test cases exist, and what are their states (pass, fail, blocked, and so on)?
+ </li>
+ <li>
+ How many bug reports have been filed, and what are their states (open, assigned, ready for testing, closed,
+ deferred)?
+ </li>
+ <li>
+ What trends and patterns do you see in test case and bug report states, especially opened and closed bug reports
+ and passed and failed test cases?
+ </li>
+ <li>
+ For test cases that were blocked or skipped, why are they in this state?
+ </li>
+ <li>
+ Considering all test cases not yet run (and perhaps not even created yet), what key risks and areas of
+ functionality remain untested?
+ </li>
+ <li>
+ For failed test cases, what are the associated bug reports?
+ </li>
+ <li>
+ For bug reports ready for confirmation testing, when can your team perform the test?
+ </li>
+</ul><!-- END:sectionDescription,_3t6oADO2EduqsLmIADMQ9g -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/architecture_notebook.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/architecture_notebook.html
new file mode 100644
index 0000000..334ad01
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/architecture_notebook.html
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\architecture_notebook.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: architecture_notebook.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0XAf0MlgEdmt3adZL5Dmdw CRC: 814628873 -->Architecture Notebook<!-- END:presentationName,_0XAf0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0XAf0MlgEdmt3adZL5Dmdw CRC: 4041001655 -->The Architecture Notebook describes the blueprint for software development. It contains the rationale, assumptions, explanations and implications of the decisions that were made in forming the architecture.<!-- END:briefDescription,_0XAf0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_H4gOYKYTEdmvhNXG0Oc2uA CRC: 2057583533 --><p>
+ This artifact is a communication vehicle that tells Developers what pieces to build, as well as how those pieces
+ behave and interact with each other. It determines the project structure so that managers can plan the project. It also
+ gives whoever must maintain and change the architecture later their first glimpse of the system; and an understanding
+ of the motivation behind the important technical decisions.
+</p>
+<p>
+ This artifact focuses on specific aspects of the design, concentrating on structure, essential elements, key scenarios
+ and those aspects that have a lasting impact on system qualities such as performance, reliability, adaptability and
+ cost. It defines the set of mechanisms, patterns and styles that will guide the rest of the design, assuring its
+ integrity.
+</p>
+<p>
+ Architectural elements make excellent units of implementation, unit testing, integration, configuration management
+ and documentation. The organisation of the architecture can also help the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a> decide on the organisation of the team.
+</p><!-- END:mainDescription,_H4gOYKYTEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_H4gOYKYTEdmvhNXG0Oc2uA CRC: 2013104446 --><p>
+ To describe the essential part of the design of the system so the integrity and understandability of the system is
+ assured.
+</p><!-- END:purpose,_H4gOYKYTEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_H4gOYKYTEdmvhNXG0Oc2uA CRC: 3956999878 --><p>
+ The he architecture can be represented in many forms and from many viewpoints, depending on the needs of the project
+ and the preferences of the project team. The architecture can be expressed as a simple metaphor or as a comparison to a
+ predefined architectural style or set of styles. It may be a precise set of models or documents that describe the
+ various aspects of the system's key elements. Expressing it as skeletal build is another option - although this build
+ may need to be baselined and preserved to ensure that the essence of the system can be understood as the system grows.
+</p>
+<p>
+ It is frequently a design artifact that must be represented in a readable and accessible way. It can reference models
+ that describe <a class="elementLink"
+ href="./../../openup_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html"
+ guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>s for communicating the architecture. A view is a representation
+ of a system from the perspective of a related set of concerns. To choose the appropriate set of
+ views, identify the Stakeholders who depend on software architecture documentation and the information that they
+ need.
+</p>
+<p>
+ It need not be a formal document. The essence of the architecture can often be communicated through a series of simple
+ diagrams on a whiteboard; or as a list of decisions. Choose the medium that best meets the needs of the project.
+</p><!-- END:representationOptions,_H4gOYKYTEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/build.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/build.html
new file mode 100644
index 0000000..eb1df0b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/build.html
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\build.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: build.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0YuXEMlgEdmt3adZL5Dmdw CRC: 2086788575 -->Build<!-- END:presentationName,_0YuXEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0YuXEMlgEdmt3adZL5Dmdw CRC: 1269242842 -->An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product.<!-- END:briefDescription,_0YuXEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NqSB0KeqEdmKDbQuyzCoqQ CRC: 1700061741 --><p>
+ This working version of the system is the result of putting the implementation of the system through a build process
+ (typically an automated build script) that creates an executable version of the system, or one that runs. This
+ executable version of the system will typically have a number of supporting files that are also considered part of this
+ composite artifact.
+</p><!-- END:mainDescription,_NqSB0KeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,_NqSB0KeqEdmKDbQuyzCoqQ CRC: 2550804768 --><p>
+ In an iterative lifecycle, each build must evolve from the previous iteration's build, adding more functionality and
+ improving quality.
+</p>
+<p>
+ The purpose of early builds that minimize or eliminate a risk or verify architectural decisions is to achieve
+ consistently stable builds in later iterations.
+</p><!-- END:keyConsiderations,_NqSB0KeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NqSB0KeqEdmKDbQuyzCoqQ CRC: 762566038 -->Deliver incremental value to the user and customer, and provide a testable artifact for verification.<!-- END:purpose,_NqSB0KeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: reasonsForNotNeeding<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:reasonsForNotNeeding,_NqSB0KeqEdmKDbQuyzCoqQ CRC: 671250120 --><p>
+ There will always need to be an operational version of the system.
+</p><!-- END:reasonsForNotNeeding,_NqSB0KeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_NqSB0KeqEdmKDbQuyzCoqQ CRC: 4148945722 --><p>
+ This work product is almost always a composite product made up of numerous parts required to make the executable
+ system. Therefore a build is more than just executable files; it additionally includes such things as configuration
+ files, help files, and data repositories that will be put together resulting in the product that will be run by the
+ users. The specifics of those parts will vary by technology in use.
+</p><!-- END:representationOptions,_NqSB0KeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/design.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/design.html
new file mode 100644
index 0000000..e70cf84
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/design.html
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0WuL8slgEdmt3adZL5Dmdw CRC: 3403898630 -->Design<!-- END:presentationName,_0WuL8slgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0WuL8slgEdmt3adZL5Dmdw CRC: 2998401465 -->This artifact describes the realization of required system functionality in terms of components and serves as an abstraction of the source code.<!-- END:briefDescription,_0WuL8slgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zxB-QKYcEdmvhNXG0Oc2uA CRC: 304156181 --><p>
+ This product can describe multiple static and dynamic views of the system for examination. Although various views may
+ focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit
+ together without contradiction.
+</p>
+<p>
+ It describes the elements that will make up the implemented system. It communicates abstractions of particular portions
+ of the implementation and can describe an encapsulated subsystem, a high-level analysis of the system, a view of
+ the system in only one context, or other perspectives that explain a solution to a specific problem that needs to be
+ communicated.
+</p><!-- END:mainDescription,_zxB-QKYcEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_zxB-QKYcEdmvhNXG0Oc2uA CRC: 3846250428 --><p>
+ Describe the elements of the system so they can be examined and understood in ways not possible by
+ reading the source code.
+</p><!-- END:purpose,_zxB-QKYcEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,_zxB-QKYcEdmvhNXG0Oc2uA CRC: 4157366389 --><p>
+ Implementation will proceed with fine-grained, inconsistent tactical decisions that lead to poor-quality software.
+</p><!-- END:impactOfNotHaving,_zxB-QKYcEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: reasonsForNotNeeding<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:reasonsForNotNeeding,_zxB-QKYcEdmvhNXG0Oc2uA CRC: 778658421 -->Some representation of the design will always be necessary. In circumstances where a project involves applying
+well-understood, existing strategies for architecture and design, it is possible that you will not need a <em>new</em>
+design. In those cases, you can simply refer to some existing design.<!-- END:reasonsForNotNeeding,_zxB-QKYcEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_zxB-QKYcEdmvhNXG0Oc2uA CRC: 547625323 --><p>
+ It is important that the author of this work product be able to analyze key decisions about the structure and behavior
+ of the system and communicate them to other collaborators. It is also important that these decisions can be
+ communicated at various levels of abstraction and granularity. Some aspects of the design can be represented by source
+ code, possibly with some extra annotations. But more abstract representations of the design will be at a higher-level
+ than source code.
+</p>
+<p>
+ The more abstract representation could use various representation options. UML could be used either strictly or
+ informally; it is a preferred notation based on its rich semantics and broad usage in the industry. Other techniques
+ could be used to communicate the design. Or the design could use a mix of techniques as applicable.
+</p>
+<p>
+ Whether you record these representations on a white board or use a formal tool is not governed by this process. But any
+ representation, whether characterized as formal or informal, should unambiguously communicate the technical decisions
+ embodied by the design.
+</p><!-- END:representationOptions,_zxB-QKYcEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/developer_test.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/developer_test.html
new file mode 100644
index 0000000..7d0c166
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/developer_test.html
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\developer_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: developer_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0YuXEclgEdmt3adZL5Dmdw CRC: 2474353591 -->Developer Test<!-- END:presentationName,_0YuXEclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0YuXEclgEdmt3adZL5Dmdw CRC: 949374461 -->The instructions that validate individual software components perform as specified.<!-- END:briefDescription,_0YuXEclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 2159502479 --><p> This artifact covers all of
+ the steps that are required to validate
+ a software component. It specifies test entries,
+ execution conditions, and expected results. These details
+ are identified for the purpose of evaluating a
+ particular aspect of a scenario. </p>
+<p> The tests should be self-documenting in a way that
+ makes it clear upon completion of the test whether the component has
+ run correctly. </p><!-- END:mainDescription,_NqSB0qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 528181499 -->Evaluate that a software component performs as specified.<!-- END:purpose,_NqSB0qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 1718076459 -->Not having developer tests can inhibit iterative development, because
+there is no assurance that modified components are still working correctly
+when you modify components iteration by iteration.<!-- END:impactOfNotHaving,_NqSB0qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: reasonsForNotNeeding<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:reasonsForNotNeeding,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 72249732 -->If the tests can be embedded into the actual production code, you might not need a separate work product. Nonetheless, some
+level of support for developer testing is always necessary.<!-- END:reasonsForNotNeeding,_NqSB0qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefOutline<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefOutline,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 738054710 --><p>
+ There is no predefined template for this work product and a testing tool will affect how the work product is
+ handled, but here are some key issues that should be addressed:
+</p>
+<ul>
+ <li>
+ Setup
+ </li>
+ <li>
+ Inputs
+ </li>
+ <li>
+ Script
+ </li>
+ <li>
+ Expected Results
+ </li>
+ <li>
+ Evaluation Criteria
+ </li>
+ <li>
+ Clean-Up
+ </li>
+</ul><!-- END:briefOutline,_NqSB0qeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_NqSB0qeqEdmKDbQuyzCoqQ CRC: 706436263 --><p align="left">
+ The following are recommendation and options for representing this work product.
+</p>
+<h4>
+ Recommendation: Automated Code Unit
+</h4>
+<p>
+ The most appropriate technique for running these tests is using code that tests the components fully and that you can
+ run regularly as you update the system during development.
+</p>
+<p>
+ When code is the sole form of the tests, you must take care to ensure that the code is self-documenting, including
+ specifications of what conditions you are testing and what setup or clean-up is required for the test to run properly.
+</p>
+<h4>
+ Option: Manual Instructions
+</h4>
+<p>
+ In some cases, manual instructions can suffice. For example, when testing a user interface, a Developer could walk
+ through a script, explaining the component. In this case, it can still be valuable to create a test harness that goes
+ straight to the user interface. That way, the Developer can follow the script without having to walk through a
+ complicated set of instructions to get to a particular screen or page.
+</p>
+<h4>
+ Option: Embedded Code
+</h4>
+<p>
+ Certain technologies (such as Java™ 5 Test Annotation) enable you to embed tests in the implementation. In those cases,
+ there will be a logical work product, but it will be assimilated into the code that you are testing. Here, too, take
+ into consideration that you must ensure that the code is self-documenting.
+</p><!-- END:representationOptions,_NqSB0qeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/glossary.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/glossary.html
new file mode 100644
index 0000000..d0d9659
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/glossary.html
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\glossary.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: glossary.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Wn7HcNcEEdqz_d2XWoVt6Q CRC: 1240688917 -->Glossary<!-- END:presentationName,_Wn7HcNcEEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Wn7HcNcEEdqz_d2XWoVt6Q CRC: 3150292985 -->This artifact defines important terms used by the project. These terms are the basis for effective collaboration with the stakeholders and other team members.<!-- END:briefDescription,_Wn7HcNcEEdqz_d2XWoVt6Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-iOn7_gfX_iELWRNGJ2JKPQ CRC: 1353371380 --><p>
+ The Glossary helps you avoid miscommunication by providing two essential resources:
+</p>
+<ul>
+ <li>
+ A central location to look for terms and abbreviations that are new to development team members
+ </li>
+ <li>
+ Definitions of terms that are used in specific ways within the domain
+ </li>
+</ul>
+<p>
+ Definitions for the Glossary terms come from several sources, such as requirements documents, specifications, and
+ discussions with Stakeholders and domain experts.
+</p><!-- END:mainDescription,-iOn7_gfX_iELWRNGJ2JKPQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-iOn7_gfX_iELWRNGJ2JKPQ CRC: 1818373714 --><p>
+ In some projects that do not involve business or domain modeling, the Glossary is the primary artifact for capturing
+ information about the project's business domain.
+</p>
+<p>
+ Although listed as an output from, and an input to tasks associated with the requirements discipline, this artifact can
+ be updated at any time, by any role, as new terms are identified.
+</p><!-- END:keyConsiderations,-iOn7_gfX_iELWRNGJ2JKPQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-iOn7_gfX_iELWRNGJ2JKPQ CRC: 1386461132 -->The goal is for the Glossary to provide a common
+vocabulary agreed upon by all Stakeholders. It can
+help people from different functional groups reach a mutual
+understanding of the system.
+<!--StartFragment -->
+The goal is not to record all possible terms, but only those
+that are unclear, ambiguous, or require elaboration.<!-- END:purpose,-iOn7_gfX_iELWRNGJ2JKPQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,-iOn7_gfX_iELWRNGJ2JKPQ CRC: 1584332027 -->Misunderstandings about the meanings of data items account for many failed projects.
+Some of them become obvious only in the late stages of system testing and can
+be extremely expensive to correct.<!-- END:impactOfNotHaving,-iOn7_gfX_iELWRNGJ2JKPQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-iOn7_gfX_iELWRNGJ2JKPQ CRC: 1782748874 --><p>
+ The Glossary is a simple alphabetized listing of domain terms and their definitions. It can be captured in a
+ spreadheet, document, or published on a Wiki site to simplify access and maintenance.
+</p><!-- END:representationOptions,-iOn7_gfX_iELWRNGJ2JKPQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/implementation.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/implementation.html
new file mode 100644
index 0000000..34d397c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/implementation.html
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\implementation.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implementation.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0YoQcMlgEdmt3adZL5Dmdw CRC: 263885700 -->Implementation<!-- END:presentationName,_0YoQcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0YoQcMlgEdmt3adZL5Dmdw CRC: 2132301333 -->Software code files, data files, and supporting files such as online help files that represent the raw parts of a system that can be built.<!-- END:briefDescription,_0YoQcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_6u9ZsKYcEdmvhNXG0Oc2uA CRC: 4139072772 --><p>
+ This artifact is the collection of one or more of these elements:
+</p>
+<ul>
+ <li>
+ Source code files
+ </li>
+ <li>
+ Data files
+ </li>
+ <li>
+ Build scripts
+ </li>
+ <li>
+ Other files that are transformed into the executable system
+ </li>
+</ul><!-- END:mainDescription,_6u9ZsKYcEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_6u9ZsKYcEdmvhNXG0Oc2uA CRC: 3311639936 --><p>
+ To represent the physical parts that make up the system to be built, organized in a way that is understandable and
+ manageable.
+</p><!-- END:purpose,_6u9ZsKYcEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_6u9ZsKYcEdmvhNXG0Oc2uA CRC: 3163080578 --><p>
+ Implementation files represented as files in the local file system. File folders (directories), represented as
+ packages, group the files into logical units.
+</p><!-- END:representationOptions,_6u9ZsKYcEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/iteration_plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/iteration_plan.html
new file mode 100644
index 0000000..7cc379c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/iteration_plan.html
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\iteration_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: iteration_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0aQBEslgEdmt3adZL5Dmdw CRC: 3699738420 -->Iteration Plan<!-- END:presentationName,_0aQBEslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0aQBEslgEdmt3adZL5Dmdw CRC: 1797260890 -->A fine-grained plan describing the objectives, work assignments, and evaluation criteria for the iteration.<!-- END:briefDescription,_0aQBEslgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_BcBR8KX5EdmvhNXG0Oc2uA CRC: 3633059591 --><p>
+ The main objectives of the iteration plan is to provide the team with one central place for information regarding
+ iteration objectives, detailed plan with task assignments, and evaluation results. This artifcat also helps the team to
+ monitor the progress of the iteration.
+</p>
+<p>
+ The task assignments for an iteration is a subset of all tasks on the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>, therefore the iteration plan ideally references those
+ work items.
+</p><!-- END:mainDescription,_BcBR8KX5EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_BcBR8KX5EdmvhNXG0Oc2uA CRC: 1070096743 --><p>
+ Communicate the objectives, task assignment, and evaluation criteria for a given iteration.
+</p><!-- END:purpose,_BcBR8KX5EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_BcBR8KX5EdmvhNXG0Oc2uA CRC: 1216991123 --><p>
+ The level of detail/formality of the plan must be adapted to what you need to successfully meet these objectives.The
+ plan could, for example, be captured
+</p>
+<ul>
+ <li>
+ on a whiteboard listing the objectives, task assignments and evaluation criteria,
+ </li>
+ <li>
+ a 1-page document listing the objectives and evaluation criteria of the iteration, as well as referencing the
+ Work Items List for assignments for that iteration,
+ </li>
+ <li>
+ a more complex document, supported by a Gantt or Pert chart in a project planning tool.
+ </li>
+</ul><!-- END:representationOptions,_BcBR8KX5EdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/project_plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/project_plan.html
new file mode 100644
index 0000000..30bfcba
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/project_plan.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\project_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0a6vcMlgEdmt3adZL5Dmdw CRC: 659198141 -->Project Plan<!-- END:presentationName,_0a6vcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0a6vcMlgEdmt3adZL5Dmdw CRC: 692924651 -->This artifact gathers all information required to manage the project. Its main part consists of a coarse-grained plan, containing project phases and milestones.<!-- END:briefDescription,_0a6vcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_IbVp8KX4EdmvhNXG0Oc2uA CRC: 1849216530 --><P><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p>This artifact defines the parameters for project progress tracking and specifies the high-level objectives of the iterations and their milestones. Additionally, it describes how the project is organized and which roles are assigned to whom.</o:p></SPAN></P>
+<P><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><o:p>The project manager is responsible for developing the project plan, working very closely with the rest of the team. The project plan allows stakeholders and other team members to understand the big picture and, roughly, when to expect what level of functionality.</o:p></SPAN><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><o:p><BR></P></o:p></SPAN><!-- END:mainDescription,_IbVp8KX4EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_IbVp8KX4EdmvhNXG0Oc2uA CRC: 3127796674 --><p>
+ The purpose of this artifact is to provide a central document where any project team member can find the
+ information on how the project will be managed.
+</p><!-- END:purpose,_IbVp8KX4EdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/resources/supporting_reguirements2.gif b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/resources/supporting_reguirements2.gif
new file mode 100644
index 0000000..cf4c368
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/resources/supporting_reguirements2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/risk_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/risk_list.html
new file mode 100644
index 0000000..0a3e079
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/risk_list.html
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\risk_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: risk_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Ckay8Cc_EduIsqH1Q6ZuqA CRC: 3469038815 -->Risk List<!-- END:presentationName,_Ckay8Cc_EduIsqH1Q6ZuqA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Ckay8Cc_EduIsqH1Q6ZuqA CRC: 3304101902 -->This artifact is a sorted list of known and open risks to the project, sorted in order of importance and associated with specific mitigation or contingency actions.<!-- END:briefDescription,_Ckay8Cc_EduIsqH1Q6ZuqA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-4VJ_0upihz-bR7VRlm63Vw CRC: 563057949 -->This list identifies, in decreasing order of priority, the events that could lead to a significant negative outcome. It
+serves as a focal point for project activities and is the basis around which iterations are organized. <!--EndFragment--><!-- END:mainDescription,-4VJ_0upihz-bR7VRlm63Vw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-4VJ_0upihz-bR7VRlm63Vw CRC: 2857835184 --><p>
+ This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider
+ whether they are really serious risks. Tracking more than 20 risks is an onerous task.
+</p><!-- END:keyConsiderations,-4VJ_0upihz-bR7VRlm63Vw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-4VJ_0upihz-bR7VRlm63Vw CRC: 3274451424 -->To capture the perceived risks to the success of the project.<!-- END:purpose,-4VJ_0upihz-bR7VRlm63Vw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-4VJ_0upihz-bR7VRlm63Vw CRC: 480867447 --><h4>
+ Option: list of risks captured in the project plan
+</h4>
+<p>
+ In this approach you put the overall risk list in the project plan. The iteration plan will contain only the tasks you
+ will be doing during the iteration to mitigate the risks. This will ensure that the iteration plan contains only
+ iteration information. The project plan has to be revisited constantly as you update risks.
+</p>
+<h4>
+ Option: list of risks captured in the iteration plan
+</h4>
+<p>
+ In this approach you enter the overall risk list in the current iteration plan. This approach ensures that you look at
+ the risk list at each iteration, as it is part of your iteration plan. The only drawback is that your iteration plan
+ will contain information that is not relevant to the current iteration. All the risks you have not mitigated
+ during the iteration have to be transferred to the next iteration plan.
+</p><!-- END:representationOptions,-4VJ_0upihz-bR7VRlm63Vw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/status_assessment.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/status_assessment.html
new file mode 100644
index 0000000..6a7d594
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/status_assessment.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\status_assessment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: status_assessment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0bA2EMlgEdmt3adZL5Dmdw CRC: 4196749033 -->Status Assessment<!-- END:presentationName,_0bA2EMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0bA2EMlgEdmt3adZL5Dmdw CRC: 1799779189 -->Capture and communicate results and actions from assessments. This is typically done at the end of each iteration.<!-- END:briefDescription,_0bA2EMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_K-e8IKX4EdmvhNXG0Oc2uA CRC: 1427235238 --><p>
+ Capture and communicate whether the project is on track, requires corrective actions, and whether there are
+ opportunities for improvement.
+</p><!-- END:purpose,_K-e8IKX4EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,_K-e8IKX4EdmvhNXG0Oc2uA CRC: 4179707242 -->The team may not understand whether they are on track or not, and whether established iteration objectives and evaluation
+criteria are met. The team may not be able to improve the way they develop software.<!-- END:impactOfNotHaving,_K-e8IKX4EdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_K-e8IKX4EdmvhNXG0Oc2uA CRC: 227428847 --><p>
+ The format of the status assessment varies from one project to another. It can be the minutes of an assessment
+ meeting, an update to a web site, or just an email. The important thing is to effectively communicate to all
+ involved parties whether iteration objectives and evaluation criteria were addressed, and what improvements are
+ needed to the way the team is working.
+</p><!-- END:representationOptions,_K-e8IKX4EdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/supporting_requirements.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/supporting_requirements.html
new file mode 100644
index 0000000..add4e68
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/supporting_requirements.html
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\supporting_requirements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BVh9cL-CEdqb7N6KIeDL8Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_BVh9cL-CEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_BVh9cL-CEdqb7N6KIeDL8Q CRC: 301387017 -->This artifact captures system-wide requirements not captured in scenarios or use cases, including requirements on quality attributes and global functional requirements.<!-- END:briefDescription,_BVh9cL-CEdqb7N6KIeDL8Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_dNuyh-0q5vpCiIiLfbj6w CRC: 2532495142 --><p>
+ Supporting Requirements and Use Cases, together, define the system requirements. Use Cases describe the behavioral
+ requirements for the system, and Supporting Requirements describe system-wide requirements that are not captured in Use
+ Case Specifications. Making this distinction simplifies maintenance.
+</p>
+<p>
+ Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,
+ Performance, Supportability + Constraints). For more information on this classification, see <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html"
+ guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.
+</p>
+<p>
+ The figure that follows illustrates the relationship among the Supporting Requirements, Use Case Specifications, and
+ Actors.
+</p>
+<p>
+ <img height="400" alt="" src="./resources/supporting_reguirements2.gif" width="600" />
+</p><!-- END:mainDescription,-_dNuyh-0q5vpCiIiLfbj6w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,-_dNuyh-0q5vpCiIiLfbj6w CRC: 107606050 --><p> The goal of this work product is to make sure that all types
+ of requirements are covered, which reduces the risk of not considering some
+ important facet of the system. FURPS+ requirements are system-wide, and
+ they influence the Architectural Mechanisms that you will create, thus
+ guiding development of the system's foundation.
+ These requirements are frequently the major cost item,
+ because they determine architectural choices.<strong>
+ </strong></p>
+<p> Furthermore, if you do not capture system-wide requirements in a central location,
+ but repeat them throughout the Use Cases, the result will
+ be more maintenance and more chance for error. </p><!-- END:impactOfNotHaving,-_dNuyh-0q5vpCiIiLfbj6w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-_dNuyh-0q5vpCiIiLfbj6w CRC: 523446910 --><p> This work product does not imply using only one
+ document to capture all requirement types. To manage the communication of the
+ information, it makes more sense to separate the information into separate documents
+ or to use the Work Items List.<strong> </strong></p>
+<p align="left"> The following are recommendation and options for representing
+ the Supporting Requirements:</p>
+<h4> Option: Use the Work Items List</h4>
+<p> Consider capturing Supporting Requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
+ Work Items List</a>, which you can use for prioritizing and managing requirements.
+ If Stakeholders are comfortable with it, or with accessing a report automatically
+ generated from it, then you do not need a separate document. </p>
+<h4>
+ Option: Include as Part of the Vision Document
+</h4>
+<p> Consider including some types of Supporting Requirements in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact:
+ Vision</a>. To keep the Vision stable, follow this option for the requirements
+ types that need less refinement, such as Product Qualities, Documentation, or
+ Compliance. </p><!-- END:representationOptions,-_dNuyh-0q5vpCiIiLfbj6w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/supporting_requirements_intent_req.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/supporting_requirements_intent_req.html
new file mode 100644
index 0000000..8dd9f6a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/supporting_requirements_intent_req.html
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\supporting_requirements_intent_req.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: supporting_requirements_intent_req.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-SUqkkwrs1D_5YXZls-3YBg CRC: 3187753078 --><h4>
+ Recommendation: Use the Supporting Requirements Specification Template
+</h4>
+<p>
+ <a class="elementLinkWithType" href="./../../openup_basic/guidances/templates/supporting_requirements_spec,_ItYXcNa9Edqrw4BYKyYKiA.html" guid="_ItYXcNa9Edqrw4BYKyYKiA">Template: Supporting Requirements Specification</a> provides a tool to capture,
+ structure, and organize the supporting requirements.
+</p>
+<p>
+ Even in a small project, a requirements management tool, a database, or a spreadsheet, are recommended for prioritizing
+ and managing requirements. If Stakeholders are comfortable with accessing requirements directly from that tool or with
+ accessing a report automatically generated from the tool, you will not need a separate document.
+</p><!-- END:representationOptions,-SUqkkwrs1D_5YXZls-3YBg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_case.html
new file mode 100644
index 0000000..43d1581
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_case.html
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\test_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0ZS-0MlgEdmt3adZL5Dmdw CRC: 607185224 -->Test Case<!-- END:presentationName,_0ZS-0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0ZS-0MlgEdmt3adZL5Dmdw CRC: 2910135722 -->This artifact is the specification of a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a scenario.<!-- END:briefDescription,_0ZS-0MlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NqYIdKeqEdmKDbQuyzCoqQ CRC: 1634782957 --><p>
+ A test case specifies the conditions which need to be validated to enable an assessment of some particular aspects of
+ the system under test. A test case is more formal than a test idea and usually takes the form of a
+ specification. In less formal environments, test cases can be created by identifying a unique ID, name, associated
+ test data, and expected results. For an example of this type of test case, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/templates/test_case,_0dT8IMlgEdmt3adZL5Dmdw.html" guid="_0dT8IMlgEdmt3adZL5Dmdw">Template: Test Case</a>.
+</p>
+<p>
+ Test cases may be derived from many sources but will usually include a subset of both the requirements (such
+ as use cases, performance characteristics, reliability concerns) and other types of quality attributes. For more
+ information on types of tests and their relationship to quality test attributes, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/types_of_test,_0aJ6cMlgEdmt3adZL5Dmdw.html" guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Types of Test</a>.
+</p><!-- END:mainDescription,_NqYIdKeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NqYIdKeqEdmKDbQuyzCoqQ CRC: 998012423 --><p>
+ The purpose of this artifact is to:
+</p>
+<ul>
+ <li>
+ provide a way to capture test inputs, conditions, and expected results for a system
+ </li>
+ <li>
+ systematically identify aspects of the software to test
+ </li>
+ <li>
+ specify whether an expected result has been reached based on verification of a system requirement, set of
+ requirements, or scenario
+ </li>
+</ul><!-- END:purpose,_NqYIdKeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_log.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_log.html
new file mode 100644
index 0000000..4cd3698
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_log.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\test_log.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_log.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0ZlSsMlgEdmt3adZL5Dmdw CRC: 69542014 -->Test Log<!-- END:presentationName,_0ZlSsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0ZlSsMlgEdmt3adZL5Dmdw CRC: 4069260096 -->This artifact collects raw output captured during a unique execution of one or more tests for a single test cycle run.<!-- END:briefDescription,_0ZlSsMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_NqePEKeqEdmKDbQuyzCoqQ CRC: 4082743966 -->This artifact provides a detailed, typically time-based record that serves both as verification that a set of tests
+were executed, and provides information relating to the success of those tests. The focus is typically on the
+provision of an accurate audit trail, enabling post-execution diagnosis of failures to be undertaken. This raw data
+will subsequently be analyzed to help determine the results of some aspect of the test effort.<!-- END:mainDescription,_NqePEKeqEdmKDbQuyzCoqQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_NqePEKeqEdmKDbQuyzCoqQ CRC: 2492405336 --><ul>
+ <li>
+ To provide verification that a set of tests was executed
+ </li>
+ <li>
+ To provide information relating to the success of those tests
+ </li>
+</ul><!-- END:purpose,_NqePEKeqEdmKDbQuyzCoqQ -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_script.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_script.html
new file mode 100644
index 0000000..6bdfd96
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/test_script.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\test_script.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_script.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0ZfMEMlgEdmt3adZL5Dmdw CRC: 273197623 -->Test Script<!-- END:presentationName,_0ZfMEMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0ZfMEMlgEdmt3adZL5Dmdw CRC: 1543329836 -->This artifact contains the step-by-step instructions that realize a test, enabling its execution. These may take the form of either documented textual instructions that are executed manually or computer readable instructions that enable automated test execution.<!-- END:briefDescription,_0ZfMEMlgEdmt3adZL5Dmdw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/uc_model_intent_req_ucm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/uc_model_intent_req_ucm.html
new file mode 100644
index 0000000..632ada2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/uc_model_intent_req_ucm.html
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\uc_model_intent_req_ucm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: uc_model_intent_req_ucm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0UCrZclgEdmt3adZL5Dmdw CRC: 4169554661 -->This artifact captures a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers.<!-- END:briefDescription,_0UCrZclgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_zHZW9KYSEdmvhNXG0Oc2uA CRC: 562578854 --><p>
+ This artifact presents an overview of the system's intended behavior. It is the basis for agreement
+ between stakeholders and the project team regarding the intended functionality for the system. It also helps to
+ guide the various tasks in the software development lifecycle.
+</p><!-- END:purpose,_zHZW9KYSEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_zHZW9KYSEdmvhNXG0Oc2uA CRC: 2425512235 --><p>
+ Tailor this artifact to support the project team's needs.
+</p>
+<p>
+ Representation options include: reports and diagrams from UML modeling tools, graphical representations created using
+ drawing tools, drawings on whiteboards. Most of the information in the use-case model is captured in the use-case
+ specifications.
+</p><!-- END:representationOptions,_zHZW9KYSEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/use_case.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/use_case.html
new file mode 100644
index 0000000..e6c1c60
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/use_case.html
@@ -0,0 +1,67 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\use_case.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0VGbUMlgEdmt3adZL5Dmdw CRC: 3319967926 -->Use Case<!-- END:presentationName,_0VGbUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0VGbUMlgEdmt3adZL5Dmdw CRC: 2735006813 -->This artifact captures the sequence of actions a system performs that yields an observable result of value to those interacting with the system.<!-- END:briefDescription,_0VGbUMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_zHZW8qYSEdmvhNXG0Oc2uA CRC: 4252402079 --><p> The primary purpose of the Use Case is to capture the required system behavior
+ from the perspective of the end user, to achieve one or more goals. Different
+ users benefit in different ways, of course: </p>
+<ul>
+ <li> <strong>Customers</strong> use them to describe, or at least to approve,
+ the description of the system's behavior. </li>
+ <li><strong> Potential users</strong> use them to understand the system's behavior.
+ </li>
+ <li><strong> Architects </strong>use them to identify architecturally significant
+ functionality. </li>
+ <li><strong> Developers </strong>use them<strong> </strong> to understand the
+ required system behavior so they can identify classes from the Use Cases'
+ flow of events. </li>
+ <li><strong> Testers</strong> use them as a basis for identifying a subset of
+ the required Test Cases. </li>
+ <li> <strong>M</strong><b>anagers</b> use them<b> </b> to plan and assess the
+ work for each iteration. </li>
+ <li><strong> Technical writers </strong>use them
+ to understand the sequence of system behavior
+ that they need to describe in the documentation. </li>
+</ul><!-- END:purpose,_zHZW8qYSEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_zHZW8qYSEdmvhNXG0Oc2uA CRC: 734904562 --><p> Decide the extent to which you will elaborate on Use
+ Cases: </p>
+<ul>
+
+ <li> Describe only major flows? </li>
+
+ <li> Describe only the most important Use Cases? </li>
+
+ <li>Fully describe preconditions and post-conditions? </li>
+
+ <li> Describe scenarios first, and then raise the level of abstraction by describing
+ Use Case flows? </li>
+</ul><!-- END:representationOptions,_zHZW8qYSEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/use_case_intent_req.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/use_case_intent_req.html
new file mode 100644
index 0000000..0a364af
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/use_case_intent_req.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\use_case_intent_req.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: use_case_intent_req.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-JcGDIeBIMM099mbWX5fXbA CRC: 205132673 --><p>
+ Some projects apply Use Cases informally to help discover requirements, documenting and maintaining these requirements
+ in another form such as user stories. How you tailor Use Cases may depend on project size, team experience, your tool
+ set, the customer relationship, and so forth. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a> for guidance related to documenting
+ Use Cases.
+</p><!-- END:representationOptions,-JcGDIeBIMM099mbWX5fXbA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/vision.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/vision.html
new file mode 100644
index 0000000..90945e5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/vision.html
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_0WVxcMlgEdmt3adZL5Dmdw CRC: 2312412063 -->Vision<!-- END:presentationName,_0WVxcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_0WVxcMlgEdmt3adZL5Dmdw CRC: 3004616621 -->This artifact contains the definition of the stakeholders' view of the product to be developed, specified in terms of the stakeholders' key needs and features. It contains an outline of the envisioned core requirements for the system.<!-- END:briefDescription,_0WVxcMlgEdmt3adZL5Dmdw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,_zHTQUKYSEdmvhNXG0Oc2uA CRC: 2241564169 --><p>
+ This artifact provides a complete vision for the software system under development and supports the contract
+ between the customer and the development organization. Every project needs a source for capturing all Stakeholders'
+ expectations.
+</p>
+<p>
+ This artifact is written from the customers' perspective, focusing on the essential features of the system and
+ acceptable levels of quality. The artifact should include a description of what <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a> will be included, as well as those considered but not included.
+</p><!-- END:mainDescription,_zHTQUKYSEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,_zHTQUKYSEdmvhNXG0Oc2uA CRC: 3095683621 --><p> This artifact provides a high-level, sometimes contractual, basis for
+ the more detailed technical requirements that are visible to the Stakeholders.
+ It captures the essence of the system by describing high-level
+ requirements and design constraints that give the reader an overview of the
+ system from a behavioral requirements perspective. It serves
+ as input for the project-approval process,
+ communicates the fundamental "what and why" for the project, and provides
+ a plan against which all future decisions should be validated. </p><!-- END:purpose,_zHTQUKYSEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,_zHTQUKYSEdmvhNXG0Oc2uA CRC: 3013390951 -->If this artifact is not used, there is a high risk that Stakeholders and the development
+team will have different expectations. This could lead to cancellation of
+the project.<!-- END:impactOfNotHaving,_zHTQUKYSEdmvhNXG0Oc2uA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,_zHTQUKYSEdmvhNXG0Oc2uA CRC: 1180025763 -->Tailor this artifact as necessary for your project's needs. It is generally good
+practice to keep this artifact brief so you can release
+it to Stakeholders as soon as possible, and to make it easy for Stakeholders to
+read and understand. You can
+accomplish this by including only the most important Stakeholder requests
+and features and avoiding details of requirements.
+You can describe details in the other requirement
+artifacts.<!-- END:representationOptions,_zHTQUKYSEdmvhNXG0Oc2uA -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/work_items_list.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/work_items_list.html
new file mode 100644
index 0000000..fb829e9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/work_items_list.html
@@ -0,0 +1,85 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\work_items_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_items_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_rGNWsCbSEdqh1LYUOGRh2A CRC: 699774998 -->Work Items List<!-- END:presentationName,_rGNWsCbSEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_rGNWsCbSEdqh1LYUOGRh2A CRC: 1905799635 -->This artifact contains a list of all scheduled work to be done within the project, as well as proposed work that may affect the product in this or future projects. Each Work Item may contain references to information relevant to carry out the work described within the work item.<!-- END:briefDescription,_rGNWsCbSEdqh1LYUOGRh2A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-buxz4BVToq97bSxaqyjySg CRC: 929956055 --><p>
+ This artifact provides a focal point for the entire team:
+</p>
+<ul>
+ <li>
+ It provides one list containing all requests for additional capabilities or enhancement for that application. Note
+ that some of these requests may never be implemented, or be implemented in later projects
+ </li>
+ <li>
+ It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list
+ is prioritized separately.
+ </li>
+ <li>
+ It provides one place to go to for the development team to understand what needs to be done, get references to
+ material required to carry out the work, and one place to go to report progress made.
+ </li>
+</ul>
+<p>
+ Work items can be very large in scope, especially when capturing requests for enhancements, such as “Support Financial
+ Planning” for a personal finance application. Work Items are analyzed and broken down into smaller Work Items so they
+ can assigned to an iteration, such as a use case scenario for “Calculate Net Worth”. Further breakdown may be
+ required to identify suitable tasks to be assigned to developers, such as “Develop UI for Calculate Net Worth”. This
+ means that Work Items often have parent / child relationships.
+</p><!-- END:mainDescription,-buxz4BVToq97bSxaqyjySg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-buxz4BVToq97bSxaqyjySg CRC: 4044898541 -->To collect all requests for work that will potentially be taken on within the project, so work can be prioritized, effort
+estimated and progress tracked.<!-- END:purpose,-buxz4BVToq97bSxaqyjySg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-buxz4BVToq97bSxaqyjySg CRC: 2697716961 --><h3>
+ As a spreadsheet or database
+</h3>
+<p>
+ The Work Items List can be captured as a separate artifact, represented by a spreadsheet or database table, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/examples/work_items_list,_nHomIDgzEdu4E8ZdmlYjtA.html" guid="_nHomIDgzEdu4E8ZdmlYjtA">Example: Work Items List</a>.
+</p>
+<h3>
+ In specific tools
+</h3>
+<p>
+ Project Management, Requirements Management and Change Request tools are an option to capture the list of work to be
+ done.
+</p>
+<h3>
+ Subset As part of the Iteration Plan
+</h3>
+<p>
+ The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a> typically references Work Items that are assigned to that
+ iteration. If the team is capturing the Iteration Plan on a Whiteboard for example, the team may choose to reference
+ high-level work items in the Work Items List that are assigned to the iteration, and maintain low-level child work
+ items used to track day-to-day work only within an iteration plan.<br />
+</p><!-- END:representationOptions,-buxz4BVToq97bSxaqyjySg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/work_items_list_pm.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/work_items_list_pm.html
new file mode 100644
index 0000000..2e3dd89
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducts/work_items_list_pm.html
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducts\work_items_list_pm.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: work_items_list_pm.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-fDVhZTkf1TqDyExbI9DM-w CRC: 2803731875 --><p>
+ Work Items should contain estimates, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/work_items_list,_7vEXEMA4EdqSgKaj2SZBmg.html" guid="_7vEXEMA4EdqSgKaj2SZBmg">Guideline: Work Items List</a> and <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+</p><!-- END:mainDescription,-fDVhZTkf1TqDyExbI9DM-w -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/assessment.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/assessment.html
new file mode 100644
index 0000000..f323174
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/assessment.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\assessment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: assessment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_2VBNIDz6Edq03rqPoNVoKg CRC: 3088006816 -->Assessment<!-- END:presentationName,_2VBNIDz6Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_2VBNIDz6Edq03rqPoNVoKg CRC: 3670639000 -->These work products result from the analysis or evaluation of some particular aspect of the project, organization, business, or solution being developed. They are often used to determine the health of different aspects of the project or the organization.<!-- END:briefDescription,_2VBNIDz6Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/concept.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/concept.html
new file mode 100644
index 0000000..8d18296
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/concept.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\concept.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: concept.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8XKVwDz6Edq03rqPoNVoKg CRC: 687299020 -->Concept<!-- END:presentationName,_8XKVwDz6Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_8XKVwDz6Edq03rqPoNVoKg CRC: 3267865381 -->These work products present an overview of key ideas or basic background information. They ensure that everyone on a project has a common understanding of these items.<!-- END:briefDescription,_8XKVwDz6Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/infrastructure.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/infrastructure.html
new file mode 100644
index 0000000..1161eb7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/infrastructure.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\infrastructure.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: infrastructure.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_EL6rgDz7Edq03rqPoNVoKg CRC: 474859848 -->Infrastructure<!-- END:presentationName,_EL6rgDz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_EL6rgDz7Edq03rqPoNVoKg CRC: 556150340 -->These work products provide the required tools and technical environment to setup the required development infrastructure for a project.<!-- END:briefDescription,_EL6rgDz7Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/model.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/model.html
new file mode 100644
index 0000000..e5bf87b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/model.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MQbUgDz7Edq03rqPoNVoKg CRC: 374627805 -->Model<!-- END:presentationName,_MQbUgDz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_MQbUgDz7Edq03rqPoNVoKg CRC: 698929512 -->These work products are a special kind of specification that are an abstract representation or simulation of a &quot;system&quot; that provides a complete description of the system from a particular perspective. Models are often used to gain a better understanding of how the system works or to document design decisions for the actual implementation. Models are often made up of several different kinds of parts, these parts are categorized as Model Elements.<!-- END:briefDescription,_MQbUgDz7Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/model_element.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/model_element.html
new file mode 100644
index 0000000..ee6a9e1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/model_element.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\model_element.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model_element.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SxUOoDz7Edq03rqPoNVoKg CRC: 677430941 -->Model Element<!-- END:presentationName,_SxUOoDz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_SxUOoDz7Edq03rqPoNVoKg CRC: 1099250863 -->These work products are the individual parts that make-up a Model.<!-- END:briefDescription,_SxUOoDz7Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/plan.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/plan.html
new file mode 100644
index 0000000..cf12451
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/plan.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ZR7b8Dz7Edq03rqPoNVoKg CRC: 2104030275 -->Plan<!-- END:presentationName,_ZR7b8Dz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ZR7b8Dz7Edq03rqPoNVoKg CRC: 276185589 -->These work products provide a description of the means of achieving an objective. A successful project may include many different types of plans.<!-- END:briefDescription,_ZR7b8Dz7Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/project_data.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/project_data.html
new file mode 100644
index 0000000..82e0e88
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/project_data.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\project_data.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: project_data.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_hOaxYDz7Edq03rqPoNVoKg CRC: 1474508963 -->Project Data<!-- END:presentationName,_hOaxYDz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_hOaxYDz7Edq03rqPoNVoKg CRC: 1955920040 -->These work products identify the information that is used to manage the project. Collected information may either be kept as permanent records or used solely on an interim basis at a particular point in the project.<!-- END:briefDescription,_hOaxYDz7Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/solution.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/solution.html
new file mode 100644
index 0000000..a00919e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/solution.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\solution.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: solution.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mC_6sDz7Edq03rqPoNVoKg CRC: 1715817357 -->Solution<!-- END:presentationName,_mC_6sDz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_mC_6sDz7Edq03rqPoNVoKg CRC: 2074295705 -->These work products consist of those that are part of the overall solution or product, or that contribute directly to it.<!-- END:briefDescription,_mC_6sDz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-sIh01vzZACgxRrG_sv7DVw CRC: 2765394731 --><p>
+ <font face="Arial" size="2">Many work products contribute to the overall solution or product. Tests and test data
+ is needed to validate the solution. User support materials of all sorts are needed in the final product.
+ Source code and other implementation elements are required to build the final product. These work products,
+ including those that ship with the product, are categorized as Solution.</font>
+</p><!-- END:mainDescription,-sIh01vzZACgxRrG_sv7DVw -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/specification.html b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/specification.html
new file mode 100644
index 0000000..0d28add
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/workproducttypes/specification.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\openup_basic\workproducttypes\specification.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: specification.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_tJJeADz7Edq03rqPoNVoKg CRC: 3175174511 -->Specification<!-- END:presentationName,_tJJeADz7Edq03rqPoNVoKg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_tJJeADz7Edq03rqPoNVoKg CRC: 4242435240 -->These work products define the interfaces between different parts of the project, especially between different domains. They define exactly what something is or what it must do. For example, the Architecture shows how system requirements are mapped into design.<!-- END:briefDescription,_tJJeADz7Edq03rqPoNVoKg -->
+</body>
+</html>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/Custom Categories.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/Custom Categories.xmi
new file mode 100644
index 0000000..452d87a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/Custom Categories.xmi
@@ -0,0 +1,2 @@
+<?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="_rgwycf1WEdmek8CQTQgrOQ" name="Custom Categories,_WCguSe8KEdmKSqa_gSYthg" guid="_rgwycf1WEdmek8CQTQgrOQ"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/base_concepts_view_building_blocks.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/base_concepts_view_building_blocks.xmi
new file mode 100644
index 0000000..9d7f4f4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/base_concepts_view_building_blocks.xmi
@@ -0,0 +1,2 @@
+<?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="__cpIYBTLEdqrUt4zetC1gg" guid="__cpIYBTLEdqrUt4zetC1gg"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/base_concepts_view_inserts.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/base_concepts_view_inserts.xmi
new file mode 100644
index 0000000..cd7ead7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/base_concepts_view_inserts.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="__cpIYBTLEdqrUt4zetC1gg" name="base_concepts_view_building_blocks,_7-x6YBTLEdqrUt4zetC1gg" guid="__cpIYBTLEdqrUt4zetC1gg" changeDate="2005-09-01T16:58:54.943-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/categories.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/categories.xmi
new file mode 100644
index 0000000..c427fd2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/categories.xmi
@@ -0,0 +1,23 @@
+<?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="_yrIvUBTMEdqrUt4zetC1gg" name="categories,_yqwU0BTMEdqrUt4zetC1gg" guid="_yrIvUBTMEdqrUt4zetC1gg" changeDate="2005-10-26T23:27:36.315-0700">
+ <mainDescription><p>
+ Categories provide different ways to logically organize Content Elements. In addition to Standard Categories that have
+ been predefined for most Content Element types in UMA, <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/concepts/custom_category,_xuO10BUGEdqrUt4zetC1gg.html"
+ guid="_xuO10BUGEdqrUt4zetC1gg">Custom Categories</a> can be used to either of the following:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Categorize content based on the user's criteria.
+ </li>
+ <li>
+ Define tree-structures of nested categories allowing the user to systematically navigate and browse Method
+ Content as well as Processes based on these categories. When&nbsp;Custom Categories are used in this way they
+ are also referred to&nbsp;as <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/concepts/view,_uMKSsBUFEdqrUt4zetC1gg.html"
+ guid="_uMKSsBUFEdqrUt4zetC1gg">Views</a>.
+ </li>
+ </ul>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/cc_list.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/cc_list.xmi
new file mode 100644
index 0000000..20114de
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/cc_list.xmi
@@ -0,0 +1,2 @@
+<?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="_6B9_MO8KEdmKSqa_gSYthg" guid="_6B9_MO8KEdmKSqa_gSYthg"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/guidance 2.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/guidance 2.xmi
new file mode 100644
index 0000000..293561a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/guidance 2.xmi
@@ -0,0 +1,15 @@
+<?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="_xy2SAQIsEdqEutyfYo0quQ" guid="_xy2SAQIsEdqEutyfYo0quQ" changeDate="2005-10-28T22:47:06.839-0700">
+ <mainDescription><p>
+ UMA&nbsp;defines a number of pre-defined concrete Guidance Types.
+</p>
+<p>
+ Associations and multiplicities have been predefined on the level of detail as depicted to ensure that Guidance is only
+ related to appropriate Content Elements. For example, UMA defines that Templates can only be associated with Work
+ Products. Guidance association rules are specified with the following UML diagram:
+</p>
+<p align="center">
+ <img height="571" alt="UML diagram showing Guidance relationships"
+ src="./../guidances/concepts/resources/guidance_uml.gif" width="586" />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/guidance.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/guidance.xmi
new file mode 100644
index 0000000..4fe6ec7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/guidance.xmi
@@ -0,0 +1,2 @@
+<?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="_RdU9MAIhEdqEutyfYo0quQ" name="guidance,_RdIv8AIhEdqEutyfYo0quQ" guid="_RdU9MAIhEdqEutyfYo0quQ" changeDate="2005-07-31T17:15:02.367-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_and_process_fundamentals.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_and_process_fundamentals.xmi
new file mode 100644
index 0000000..ca3e085
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_and_process_fundamentals.xmi
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_uDU1oQSEEdq61bDkWg1SXw" name="method_architecture_fundamentals,_uDU1oASEEdq61bDkWg1SXw" guid="_uDU1oQSEEdq61bDkWg1SXw" changeDate="2005-09-07T00:41:01.369-0700">
+ <mainDescription><h3>
+ What is UMA?
+</h3>
+<p>
+ UMA is a state-of-the-art architecture for the conceiving, specifying, and storing of method and process metadata
+ (a.ka. content). Its defining feature and fundamental innovation is that it achieves clear separation between generic
+ core method content and it its application in the specification of business processes.
+</p>
+<h3>
+ Key Aspects of UMA
+</h3>
+<h4>
+ Fundamental Elements
+</h4>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif">< alt="Method versus Process Content"
+ src="./../guidances/concepts/resources/uma_m_vs_p.gif" width="480" border="0" /></font>
+</p>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif">Overview of how the key UMA concepts positioned based on whether they
+ represent methodcontent or process</font>
+</p>
+<!--EndFragment-->
+<h4>
+ Separation of Concerns
+</h4>
+<p>
+ <font face="Arial, Helvetica, sans-serif">Key <em>separations of concerns</em> in the design UMA<em>:</em></font>
+</p>
+<blockquote>
+ <p>
+ <font face="Arial, Helvetica, sans-serif">•The separation of core method content versus the application of method
+ content in processes<br />
+ •The definition of an optional extensibility mechanism in the method for large scale management of method and
+ process repositories<br />
+ •Packaging and configuration of method content, processes, and plugins in method libraries<br />
+ •A separation of recommended method and guidance description fields<br />
+ •A separation of semantic elements from their notation in process diagrams</font>
+ </p>
+</blockquote>
+<h4>
+ <font face="Arial, Helvetica, sans-serif">Method Content versus Process</font>
+</h4>
+<p>
+ <font face="Arial, Helvetica, sans-serif">The Unified Method Architecture (UMA) separates reusable core method content
+ from its application inprocesses.Methodcontent provides step-by-step explanations, describing how specific development
+ goals are achievedindependent oftheplacement of these steps within a development lifecycle. Processes take these method
+ elements and relatethemintosemi-ordered sequences that are customized to specific types of projects.<br />
+ For example, a software development project that develops an application from scratch performs development
+ taskssuchas“Develop Vision” or “Use Case Design” similar to a project that extends an existing software system.
+ However,thetwoprojects will perform the Tasks at different points in time with a different emphasis, i.e. they will
+ perform thestepsofthese tasks at different point of time and perhaps apply individual variations and additions.<br />
+ In contrast to other method engineering approaches, UMA’s unique solution allows each process to
+ referencecommonmethodguidance from a common method content pool, which then makes up the actual process guidance.
+ Becauseofthesereferences, changes in the methods will automatically be reflected in all processes using it.
+ However,UMAstillallows overwriting certain method related guidance within a process as well as
+ definingindividualprocess-specificrelationships for each process element (such as work breakdown and new relations to
+ work productsandroles).<br />
+ Figure 4 shows the difference between method content and process by representing them as twodifferentdimensions.Method
+ content describing how development work is being performed is categorized bydisciplines.Each discipline iscomprised of
+ tasks (not visible in Figure 4) that provide step-by-step descriptions ofhow specificdevelopment goals areachieved. For
+ a process, tasks have been selected from the method content and placedintoworkflows ready forinstantiation by
+ allocating resources to perform the work and having real work products as theinputsand outputs of thetasks. As a
+ result, the workload graphs shown in Figure 4 can be computed showing work effortforeach disciplineover time (from left
+ to right).<br />
+ <br />
+ </font>
+</p>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif"><img alt=&Structure of the UMA Meta-Model"
+ src="./../guidances/concepts/resources/uma_hump.gif" border="0" /></font>
+</p>
+<p class="picturetext" align="center">
+ <font face="Arial, Helvetica, sans-serif">Figure 4: Method Content definition versus<br />
+ the application of Method Content in a Process.</font>
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_architecture_fundamentals.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_architecture_fundamentals.xmi
new file mode 100644
index 0000000..cff070d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_architecture_fundamentals.xmi
@@ -0,0 +1,199 @@
+<?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" epf:version="1.0.0" xmi:id="_uDU1oQSEEdq61bDkWg1SXw" guid="_uDU1oQSEEdq61bDkWg1SXw" changeDate="2005-10-30T16:58:11.631-0800">
+ <mainDescription><h3>
+ What is UMA?
+</h3>
+<p>
+ The Unified Method Architecture (UMA) is a process engineering meta-model that defines schema and terminology for
+ representing methods consisting of method content and processes. Also see <a class="elementLinkWithType" href="./../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html" guid="_94_eoO8LEdmKSqa_gSYthg">Concept: Key Capabilities of the Unified Method Architecture (UMA)</a>&nbsp;for more
+ details.
+</p>
+<h3>
+ Fundamental principle within UMA
+</h3>
+<p>
+ UMA is based&nbsp;on the following fundamental&nbsp;separations of concern:
+</p>
+<ul>
+ <li>
+ The separation of core method content versus the application of method content in processes
+ </li>
+ <li>
+ The definition of an optional extensibility mechanism in the method for large scale management of method and
+ process repositories
+ </li>
+ <li>
+ Packaging and configuration of method content, processes, and plugins in method libraries
+ </li>
+ <li>
+ A separation of recommended method and guidance description fields
+ </li>
+ <li>
+ A separation of semantic elements from their notation in process diagrams
+ </li>
+</ul>
+<h3>
+ The Basic Elements of UMA
+</h3>
+<p>
+ The most fundamental principle of the Unified Method Architecture (UMA) is the separation of&nbsp;reusable core method
+ content from its application in processes and almost all of UMA's elements are categorized along this separations.
+</p>
+<p>
+ The Unified Method Architecture separates reusable core method content from its application in processes.&nbsp; Method
+ content describes what is to be produced, the necessary skills required and the step-by-step explanation describing how
+ specific development goals are achieved, independently of the placement of these items within a development
+ lifecycle.&nbsp; Processes take these method elements and relate them into semi-ordered sequences that are customized
+ to specific types of projects. For example, a software development project that develops an application from scratch
+ performs development tasks such as "Develop Vision" or "Use Case Design" similar to a project that extends an existing
+ software system.&nbsp; However, the two projects will perform the Tasks at different points in time with a different
+ emphasis, i.e. they will perform the steps of these tasks at different point of time and perhaps apply individual
+ variations and additions.
+</p>
+<p>
+ The figure below shows the difference between method content and process by representing them as two different
+ dimensions:
+</p>
+<ul>
+ <li>
+ Method content describing how development work is being performed is categorized by disciplines.&nbsp; Each
+ discipline is comprised of tasks (not visible in the figure) that provide step-by-step descriptions of how specific
+ development goals are achieved.&nbsp;
+ </li>
+ <li>
+ For a process, tasks have been referenced by the process from the method content and placed into breakdown
+ structures and workflows ready for instantiation by allocating resources to perform the work and having real work
+ products as the inputs and outputs of the tasks.<br />
+ </li>
+</ul>
+<p align="center">
+ <img alt="Diagram illustrating the separation of Method and Process content within the UMA Meta-Model" src="../guidances/concepts/resources/uma_hump.jpg" border="0" />
+</p>
+<p class="picturetext" align="center">
+ Method Content definition versus<br />
+ the application of Method Content in a Process.
+</p>
+<p>
+ UMA's key concepts reflect this separation of method content from process as shown in the figure below.&nbsp; It show
+ that a Method (also refered to as a Method Framework) comprises on method content described with concepts such Work
+ Products, Roles, Task and Categories as well as Processes described with Activities, Capability Patterns, or Delivery
+ Processes.
+</p>
+<p align="center">
+ <img alt="Diagram illustrating that the intersection between Method and Process content is guidance" src="../guidances/concepts/resources/uma_m_vs_p.gif" />
+</p>
+<p align="center">
+ Overview of how the key UMA concepts are positioned based on whether they represent method content or process
+</p>
+<p class="picturetext" align="left">
+ Key <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/method_concepts,_WfL28BTMEdqrUt4zetC1gg.html" guid="_WfL28BTMEdqrUt4zetC1gg">Method Content Elements</a> &nbsp;are:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html" guid="4.804531471620803E-306">Work Product</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/role,1.1609745730665898E-304.html" guid="1.1609745730665898E-304">Role</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html" guid="7.624729048911575E-305">Task</a>
+ </div>
+ </li>
+ </ul>
+</div>
+<p class="picturetext" align="left">
+ Key <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/process_concepts,_AtM0gBTQEdqrUt4zetC1gg.html" guid="_AtM0gBTQEdqrUt4zetC1gg">Process Elements</a> &nbsp;are:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html" guid="3.132140065969088E-305">Activity</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html" guid="1.7072348895114264E-305">Capability Pattern</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html" guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>
+ </div>
+ </li>
+ </ul>
+</div>
+<p class="picturetext" align="left">
+ <a class="elementLinkWithUserText" href="./../../base_concepts/customcategories/guidance,_xy2SAAIsEdqEutyfYo0quQ.html" guid="_xy2SAAIsEdqEutyfYo0quQ">Guidance</a> &nbsp;comes in many types:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/checklist,_2vVuUBT9EdqrUt4zetC1gg.html" guid="_2vVuUBT9EdqrUt4zetC1gg">Checklist</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/concept,_8wobABUAEdqrUt4zetC1gg.html" guid="_8wobABUAEdqrUt4zetC1gg">Concept</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/example,_dCG-UBUBEdqrUt4zetC1gg.html" guid="_dCG-UBUBEdqrUt4zetC1gg">Example</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/guideline,_IAwkEBUEEdqrUt4zetC1gg.html" guid="_IAwkEBUEEdqrUt4zetC1gg">Guideline</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/practice,_szl6EBUBEdqrUt4zetC1gg.html" guid="_szl6EBUBEdqrUt4zetC1gg">Practice</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/report,_x2sAgBUBEdqrUt4zetC1gg.html" guid="_x2sAgBUBEdqrUt4zetC1gg">Report</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/reusable_asset,_20bs4BUBEdqrUt4zetC1gg.html" guid="_20bs4BUBEdqrUt4zetC1gg">Reusable Asset</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/roadmap,_JCQbIBnXEdqYreeU3jqaDQ.html" guid="_JCQbIBnXEdqYreeU3jqaDQ">Roadmap</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/supporting_material,_80XPABUBEdqrUt4zetC1gg.html" guid="_80XPABUBEdqrUt4zetC1gg">Supporting Material</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/template,_G_UnIBUCEdqrUt4zetC1gg.html" guid="_G_UnIBUCEdqrUt4zetC1gg">Template</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/term_definition,_Z45fwBUDEdqrUt4zetC1gg.html" guid="_Z45fwBUDEdqrUt4zetC1gg">Term Definition</a>
+ </div>
+ </li>
+ <li>
+ <div class="picturetext" align="left">
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/tool_mentor,1.0762105093945226E-304.html" guid="1.0762105093945226E-304">Tool Mentor</a>
+ </div>
+ </li>
+ </ul>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_concepts.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_concepts.xmi
new file mode 100644
index 0000000..45a30a7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_concepts.xmi
@@ -0,0 +1,33 @@
+<?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="_WfkRcBTMEdqrUt4zetC1gg" name="method_concepts,_WfL28BTMEdqrUt4zetC1gg" guid="_WfkRcBTMEdqrUt4zetC1gg" changeDate="2005-11-07T15:54:23.625-0800">
+ <mainDescription><p>
+ Method Content is fundamentally described by defining Tasks described with Steps that have Work Products as input and
+ output and which are&nbsp;performed by Roles.&nbsp; Roles also define important responsibility relationships to work
+ products.
+</p>
+<p>
+ The fundamental Method Content abstractions are:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">Work Product</a>, which includes <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/artifact,_fdRfkBUJEdqrUt4zetC1gg.html"
+ guid="_fdRfkBUJEdqrUt4zetC1gg">Artifact</a>, <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/deliverable,_lBgkMBUJEdqrUt4zetC1gg.html"
+ guid="_lBgkMBUJEdqrUt4zetC1gg">Deliverable</a>&nbsp;and <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/outcome,_pROF4BUJEdqrUt4zetC1gg.html"
+ guid="_pROF4BUJEdqrUt4zetC1gg">Outcome</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/role,1.1609745730665898E-304.html"
+ guid="1.1609745730665898E-304">Role</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">Task</a>
+ </li>
+</ul>
+<br align="center" />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_package.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_package.xmi
new file mode 100644
index 0000000..1e7633b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/method_package.xmi
@@ -0,0 +1,20 @@
+<?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="-G5kN9IUns9GPxohNmAeeyw" name="method_package,_R5Vk4BtpEdqSLrJ4Ij2LVA" guid="-G5kN9IUns9GPxohNmAeeyw" changeDate="2005-10-27T14:50:07.109-0700">
+ <mainDescription><p>
+ Method Packages physically organize Method Elements&nbsp;into package hierarchies. All Method Elements are located in
+ exactly one Method Package.
+</p>
+<p>
+ There are two type of Method Package:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/content_package,_49a10BUFEdqrUt4zetC1gg.html"
+ guid="_49a10BUFEdqrUt4zetC1gg">Content Package</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/process_package,_MT6U8BneEdqYreeU3jqaDQ.html"
+ guid="_MT6U8BneEdqYreeU3jqaDQ">Process Package</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/navigating_the_process.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/navigating_the_process.xmi
new file mode 100644
index 0000000..30e1322
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/navigating_the_process.xmi
@@ -0,0 +1,2 @@
+<?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="_3uTl0QSHEdq61bDkWg1SXw" guid="_3uTl0QSHEdq61bDkWg1SXw" changeDate="2005-09-07T04:00:10.170-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/organizational_concepts.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/organizational_concepts.xmi
new file mode 100644
index 0000000..d8137b1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/organizational_concepts.xmi
@@ -0,0 +1,35 @@
+<?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="_TqJmsBTQEdqrUt4zetC1gg" name="organizational_concepts,_Tp3S0BTQEdqrUt4zetC1gg" guid="_TqJmsBTQEdqrUt4zetC1gg" changeDate="2005-11-08T15:04:09.331-0800">
+ <mainDescription><p>
+ This section describes concepts that are only used to organize method content and processes in an authoring
+ environment.None of these UMA abstractions are subject to publication.&nbsp;They include:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/method_library,_m8lGkBUFEdqrUt4zetC1gg.html"
+ guid="_m8lGkBUFEdqrUt4zetC1gg">Method Library</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+ guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugin</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+ guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>
+ </li>
+ <li>
+ Method Package, which includes <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/content_package,_49a10BUFEdqrUt4zetC1gg.html"
+ guid="_49a10BUFEdqrUt4zetC1gg">Content Package</a>, and <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/process_package,_MT6U8BneEdqYreeU3jqaDQ.html"
+ guid="_MT6U8BneEdqYreeU3jqaDQ">Process Package</a>
+ </li>
+</ul>
+<p>
+ These abstractions as well as their relationships are presented with the the following UML 2.0 class diagram:
+</p>
+<p align="center">
+ &nbsp;<img alt="UML Diagram describing the modeling or organizational abstractions"
+ src="../../base_concepts/guidances/concepts/resources/packaging_uml.gif" />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/process_concepts.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/process_concepts.xmi
new file mode 100644
index 0000000..f30bf9c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/process_concepts.xmi
@@ -0,0 +1,46 @@
+<?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="_AtZBwBTQEdqrUt4zetC1gg" name="process_concepts,_AtM0gBTQEdqrUt4zetC1gg" guid="_AtZBwBTQEdqrUt4zetC1gg" changeDate="2005-10-27T00:17:01.670-0700">
+ <mainDescription><p>
+ A Development Process defines the structured work definitions that need to be performed to develop a system, e.g. by
+ performing a project that follows the process.&nbsp; Such structured work definitions delineate the work to be
+ performed along a timeline or lifecycle and organize it in so called breakdown structures and/or activity diagrams. A
+ process takes reusable core method elements such as Tasks and Work Products and relates them into semi-ordered
+ sequences that are then customized to specific types of projects.
+</p>
+<p>
+ Fundamental concepts used in UMA to define processes include:
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html"
+ guid="3.132140065969088E-305">Activity</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../base_concepts/guidances/concepts/process_contribution,_NYASQBtqEdqSLrJ4Ij2LVA.html"
+ guid="_NYASQBtqEdqSLrJ4Ij2LVA">Process Contribution</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/descriptor,_5V9HEBUEEdqrUt4zetC1gg.html"
+ guid="_5V9HEBUEEdqrUt4zetC1gg">Descriptor</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/composite_role,_P9gp0BtHEdqSLrJ4Ij2LVA.html"
+ guid="_P9gp0BtHEdqSLrJ4Ij2LVA">Composite Role</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../base_concepts/guidances/concepts/team_profile,_dRKRMBtHEdqSLrJ4Ij2LVA.html"
+ guid="_dRKRMBtHEdqSLrJ4Ij2LVA">Team Profile</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/compass.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/compass.gif
new file mode 100644
index 0000000..39f306a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/compass.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/compassL.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/compassL.gif
new file mode 100644
index 0000000..4117414
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/compassL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/concept_dgm32.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/concept_dgm32.gif
new file mode 100644
index 0000000..fa195bd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/concept_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/concept_obj.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/concept_obj.gif
new file mode 100644
index 0000000..03af38b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/concept_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/wp_uml_structure.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/wp_uml_structure.gif
new file mode 100644
index 0000000..c2aad65
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/resources/wp_uml_structure.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/view_building_blocks.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/view_building_blocks.xmi
new file mode 100644
index 0000000..d8c3666
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/customcategories/view_building_blocks.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_6B9_MO8KEdmKSqa_gSYthg" name="obsolete,_5_90EO8KEdmKSqa_gSYthg" guid="_6B9_MO8KEdmKSqa_gSYthg" changeDate="2005-09-01T16:54:43.741-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/activity.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/activity.xmi
new file mode 100644
index 0000000..68d4b36
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/activity.xmi
@@ -0,0 +1,26 @@
+<?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="_zaqEMNnmEdmO6L4XMImrsA" name="activity,3.132140065969088E-305" guid="_zaqEMNnmEdmO6L4XMImrsA" changeDate="2005-10-27T01:00:09.167-0700">
+ <mainDescription><p>
+ Activities are the fundamental concept for defining processes.&nbsp; Activities define the breakdown as well as flow of
+ work.&nbsp; In other words, Activities can be nested into each other defining a breakdown structure of work or they can
+ define predecessor relationships to other Activities defining a flow presented in Activity diagrams.&nbsp; Activities
+ can also contain references to Task, Roles, and Work Products called <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/descriptor,_5V9HEBUEEdqrUt4zetC1gg.html"
+ guid="_5V9HEBUEEdqrUt4zetC1gg">Descriptor</a>.&nbsp; Activities as well as Descriptors relate to timelines by allowing
+ their instances to define start and/or end dates.&nbsp; Further, they specify information relevant to the instantiation
+ of work in project such as if an Activity shall be performed several times and if so if they can be performed in
+ parallel (hasMultipleOccurrences attribute) or one after other (isRepeatable attribute).&nbsp; Activities and Task
+ Descriptors can also be event driven or describing ongoing work that does not have a fixed start and end time.
+</p>
+<p>
+ UMA defines several&nbsp;special Activities that allow expressing processes with terms many users are familiar
+ with.&nbsp; For example, Phase or Iteration are just special Activities for which specific attribute values have been
+ set with predefined values. A process such as a <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>&nbsp;or <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Process</a>&nbsp;is also nothing else than just a special Activity that
+ contains additional documentation on why and how to use the process. Hence, because Activities could be nested into
+ each other, so can processes.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/artifact.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/artifact.xmi
new file mode 100644
index 0000000..987f095
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/artifact.xmi
@@ -0,0 +1,59 @@
+<?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="_fdds0BUJEdqrUt4zetC1gg" name="artifact,_fdRfkBUJEdqrUt4zetC1gg" guid="_fdds0BUJEdqrUt4zetC1gg" changeDate="2006-04-13T14:05:00.252-0700">
+ <mainDescription><p>
+ Artifacts are tangible well-defined Work Products consumed, produced, or modified by Tasks.&nbsp; Artifacts may be
+ composed of other Artifacts. For example, a model Artifact can be composed of model elements, which are also Artifacts.
+ They may serve as a basis for defining Reusable Assets.&nbsp; Roles use Artifacts to perform Tasks and produce
+ Artifacts in the course of performing Tasks.
+</p>
+<p>
+ Artifacts are the responsibility of a single Role, making responsibility easy to identify and understand, and promoting
+ the idea that every piece of information produced in the method requires the appropriate set of skills. Even though one
+ Role might "own" a specific type of Artifact, other Roles can still use the Artifacts, and perhaps even update them if
+ the Role has been given permission to do so.
+</p>
+<p>
+ <b>Artifacts&nbsp;are generally <i>not</i> documents</b>. Many methods have an excessive focus on documents, and in
+ particular on <i>paper documentation</i>. The most efficient and pragmatic approach to managing project Artifacts is to
+ maintain&nbsp;them <i>within</i> the appropriate tool used to create and manage them. When necessary, one may generate
+ documents (snapshots) from these tools, on a just-in-time basis.
+</p>
+<p>
+ Examples Artifacts:
+</p>
+<ul>
+ <li>
+ A use case specification stored in&nbsp;a word processor tool&nbsp;
+ </li>
+ <li>
+ A design model stored in&nbsp;a visual modeling tool.&nbsp;
+ </li>
+ <li>
+ A project plan stored in&nbsp;a project planning tool.&nbsp;
+ </li>
+ <li>
+ A defect stored in&nbsp;a change requests tools&nbsp;
+ </li>
+ <li>
+ A project requirements database in a requirements management tool.
+ </li>
+</ul>
+<p>
+ Note also that formats such as on <b>whiteboards</b> or <b>flip charts</b> can be used to capture pictorial information
+ such as UML diagrams, tabular information such as short lists of status information or even textual information such as
+ short vision statements. These formats work well for smaller, collocated teams where all team members have ready access
+ to these resources.
+</p>
+<p>
+ However, there are still Artifacts which either have to be or are best suited to being plain text documents, as in the
+ case of external input to the project, or in some cases where it is simply the best means of presenting descriptive
+ information. Where possible, teams should consider using collaborative <b>Work Group</b> tools, such as WikiWiki webs
+ or Groove to capture textual documentation electronically, thus simplifying ongoing content and version management.
+ This is especially of importance where historic records must be maintained for purposes such as fulfilling audit
+ requirements. For any nontrivial development effort, especially where large development teams are involved, Work
+ Products <strong>are</strong> <strong>most likely to be subject to version control and configuration
+ management.</strong> This is sometimes only achieved by versioning the container Work Product, when it is not possible
+ to do it for the elementary, contained Work Products. For example, in software development, you may control the
+ versions of a whole design model, or design package, and not the individual classes they contain.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/capability_pattern.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/capability_pattern.xmi
new file mode 100644
index 0000000..7a7ec12
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/capability_pattern.xmi
@@ -0,0 +1,52 @@
+<?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="_zag6RdnmEdmO6L4XMImrsA" name="capability_pattern,1.7072348895114264E-305" guid="_zag6RdnmEdmO6L4XMImrsA" changeDate="2006-04-13T14:10:52.188-0700">
+ <mainDescription><a id="XE_WORKFLOW__KEY_CONCEPTS" name="XE_workflow__key_concepts"></a>
+<p>
+ Capabilities Patterns express and communicate process knowledge for a key area of interest such as a Discipline
+ or&nbsp;a practice and can be directly used by process practitioners to guide their work.&nbsp; They are also used as
+ building blocks to assemble <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Delivery Processes</a>&nbsp;or larger Capability Patterns ensuring optimal reuse and
+ application of the key practices they express.
+</p>
+<p>
+ Examples for Capability Pattern could be 'use case-based requirements management', 'use case analysis', or 'unit
+ testing'. Typically but not necessarily, Capability Patterns have the scope of one Discipline providing a breakdown of
+ reusable complex Activities, relationships to the Roles which perform Tasks within these Activities, as well as to the
+ Work Products that are used and produced.&nbsp; Generally, a Capability Pattern does not relate to any specific phase
+ or iteration of a development lifecycle, and should not imply any.&nbsp; In other words, a pattern should be designed
+ in a way that it is applicable anywhere in a Delivery Process.&nbsp; This enables its Activities to be flexibly
+ assigned to whatever phases there are in the Delivery Process to which it is being applied.&nbsp; An exception to this
+ would be capability patterns that are intended to provide a template for quickly creating an iteration or portion of an
+ iteration for a particular phase in a Delivery Process.<br />
+ <br />
+ Key applications&nbsp;or areas of reuse for Capability Patterns are:
+</p>
+<ul>
+ <li>
+ To serve as building blocks for assembling Delivery Processes or larger Capability Patterns.&nbsp; Normally
+ developing a Delivery Process is not done from scratch but by systematically applying and binding patterns.
+ </li>
+ <li>
+ To support direct execution in a development project that does not work following a well-defined process, but works
+ based on loosely connected process fragments of practices in a flexible manner (for example, Agile Development).
+ </li>
+ <li>
+ To support process education by describing knowledge for a key area such as practices on how to perform the work
+ for a Discipline (for example, Requirements Management), for a specific development technique (aspect-oriented
+ development), or a specific technical area (for example, relational database design), which is used for education
+ and teaching.<br />
+ </li>
+</ul>
+<p>
+ The workflow of a Capability Pattern is usually represented using the UML Activity Diagram notation.&nbsp;
+</p>
+<p align="center">
+ <img alt="Sample activity diagram representing the workflow of a Capability Pattern" src="resources/wf_req.gif" />
+</p>
+<p>
+ <font size="1">Sample activity diagram representing the workflow of a Capability Pattern</font>.<br />
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/checklist.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/checklist.xmi
new file mode 100644
index 0000000..04de421
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/checklist.xmi
@@ -0,0 +1,12 @@
+<?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="_2wY3MBT9EdqrUt4zetC1gg" name="checklist,_2vVuUBT9EdqrUt4zetC1gg" guid="_2wY3MBT9EdqrUt4zetC1gg" changeDate="2005-10-21T19:21:29.297-0700">
+ <mainDescription><p>
+ In UMA, a Content Element has at most one Checklist. Checklists, are useful in a number of contexts: they help you
+ decide what to do, they help doing it, they help&nbsp;assess the quality of the work, and they help understand how a
+ particular Work Product relates to the rest of the process.<!--EndFragment-->
+</p>
+<p>
+ Work products typically have an associated Checklist which present information on how to develop, evaluate and
+ use&nbsp;them .
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/composite_role.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/composite_role.xmi
new file mode 100644
index 0000000..f3cba48
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/composite_role.xmi
@@ -0,0 +1,18 @@
+<?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="-FD4UbInbyzlaGxB9oPHdcg" name="composite_role,_P9gp0BtHEdqSLrJ4Ij2LVA" guid="-FD4UbInbyzlaGxB9oPHdcg" changeDate="2005-09-01T17:19:52.101-0700">
+ <mainDescription><p>
+ A Composite Role is a grouping of Roles that can be used in an Activity or Process to reduce the number of Roles. A
+ Composite Role is thus for the Tasks and Work Products defined for the Roles it refers to. A typical use of this
+ construct occurs within a Process designed for a small team in which multiple standard Roles from the Method Content
+ are assigned to a single resource. By using a Composite Role the Process suggests a typical clustering of Roles to
+ Resources.<br />
+</p>
+<p>
+ A simple example is a Composite Role named <em><strong>Developer</strong></em> that groups together the
+ <em><strong>Implementer</strong></em> and <em><strong>Tester</strong></em> Roles. Now, every time one of the Roles
+ Implementer or Tester would normally be used within the breakdown structure, Developer is used instead. Hence, if a
+ Task Descriptor is added to the Process, that has Implementer or Tester as the primary performer, this Role would be
+ automatically be substituted by&nbsp;the Composite Role instance Developer that links back to either Tester or
+ Implementer (or both if both were listed as the Task performers).
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/concept.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/concept.xmi
new file mode 100644
index 0000000..e9fbfdf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/concept.xmi
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_8w0oQBUAEdqrUt4zetC1gg" name="concept,_8wobABUAEdqrUt4zetC1gg" guid="_8w0oQBUAEdqrUt4zetC1gg" changeDate="2005-10-30T17:17:56.590-0800">
+ <mainDescription><p>
+ In the context of Software Engineering, key Concepts such as risk, performance testing, and so on, are introduced at
+ different levels in the process, and attached to the most appropriate Content Element. Some concepts are best
+ associated to a Discipline because they describe multiple Work Products and Tasks within this Discipline.
+</p>
+<p>
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/configuration.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/configuration.xmi
new file mode 100644
index 0000000..80c3e14
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/configuration.xmi
@@ -0,0 +1,30 @@
+<?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="_d7QQABUFEdqrUt4zetC1gg" name="configuration,_d698IBUFEdqrUt4zetC1gg" guid="_d7QQABUFEdqrUt4zetC1gg" changeDate="2005-11-04T18:15:35.245-0800">
+ <mainDescription><p>
+ A Method Configuration is a collection of selected <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+ guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugins</a>, <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/customcategories/method_package,_R5Vk4BtpEdqSLrJ4Ij2LVA.html"
+ guid="_R5Vk4BtpEdqSLrJ4Ij2LVA">Method Packages</a> and Processes (see <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Concept: Capability Pattern</a>, <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/delivery_process,_EhgqwO8MEdmKSqa_gSYthg.html"
+ guid="_EhgqwO8MEdmKSqa_gSYthg">Concept: Delivery Process</a>). A Configuration can be exported into its own stand-alone
+ library when it includes the full transitive closure of all elements it depends on. A Method Configuration defines a
+ logical subset of a <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/method_library,_m8lGkBUFEdqrUt4zetC1gg.html"
+ guid="_m8lGkBUFEdqrUt4zetC1gg">Method Library</a>.
+</p>
+<h3>
+ Applications
+</h3>
+<p>
+ A Configuration is often built around one or more Delivery Processes. A Delivery Process can be valid for different
+ Method Configurations, but each Configuration may include or exclude particular content for specific situations. For
+ example, a Delivery Process can be defined to include content for developing schemas for different types of database
+ management systems, such as content for RDBMS and OODBMS. When using such a Delivery Process, users may want to select
+ just the type of DBMS used within their project, and hence exclude all content pertaining to other types of DBMS. They
+ achieve this by selecting a Configuration which excludes the respective content or by creating a new one if none such
+ already exists.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/content_package.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/content_package.xmi
new file mode 100644
index 0000000..0c459a5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/content_package.xmi
@@ -0,0 +1,2 @@
+<?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="_49tJsBUFEdqrUt4zetC1gg" name="content_package,_49a10BUFEdqrUt4zetC1gg" guid="_49tJsBUFEdqrUt4zetC1gg" changeDate="2005-09-22T14:32:00.057-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/custom_category.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/custom_category.xmi
new file mode 100644
index 0000000..47c1f76
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/custom_category.xmi
@@ -0,0 +1,24 @@
+<?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="_xuhJsBUGEdqrUt4zetC1gg" name="custom_category,_xuO10BUGEdqrUt4zetC1gg" guid="_xuhJsBUGEdqrUt4zetC1gg" changeDate="2005-10-26T23:47:50.212-0700">
+ <mainDescription><p>
+ A Custom Category is a category introduced by a method author to structure any number of Method Content Elements of any
+ type based on user-defined criteria. Custom categories can be used to categorize content based on the user's criteria
+ as well as to define whole tree-structures of nested categories allowing the user to systematically navigate and browse
+ Method Content and Processes based on these categories. This application of Custom Categories is also called <a
+ class="elementLink" href="./../../../base_concepts/guidances/concepts/view,_uMKSsBUFEdqrUt4zetC1gg.html"
+ guid="_uMKSsBUFEdqrUt4zetC1gg">View</a>.
+</p>
+<h3>
+ Examples
+</h3>
+<p>
+ One could create a Custom Category to logically organize content relevant for the user development organization's
+ departments: A "Testing" category would group together all Roles, Work Products, Tasks, Capability Patterns and
+ Guidance relevant to testing.
+</p>
+<p>
+ Another example would be categories that express licensing levels of the content: These categories would separate
+ freely distributable Method Content from Method Content that represents intellectual property and requires a purchased
+ license for use.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/deliverable.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/deliverable.xmi
new file mode 100644
index 0000000..6b1a966
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/deliverable.xmi
@@ -0,0 +1,13 @@
+<?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="_lBy4EBUJEdqrUt4zetC1gg" name="deliverable,_lBgkMBUJEdqrUt4zetC1gg" guid="_lBy4EBUJEdqrUt4zetC1gg" changeDate="2005-10-26T18:16:48.795-0700">
+ <mainDescription><p>
+ A deliverable is a Work Product that provides a description and definition for packaging other Work Products, and may
+ be delivered to an internal or external party.&nbsp; Therefore, a Deliverable aggregates other Work Products.&nbsp;
+</p>
+<p>
+ A Deliverable is used to pre-define typical or recommended content in the form or work products that would be packaged
+ for delivery.&nbsp; The actual content and packaging of the Deliverable may need to be modified for individual projects
+ based on these recommendations.&nbsp; Deliverables are used to represent an output from a process that has value,
+ material or otherwise, to a client, customer or other stakeholder.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/delivery_process.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/delivery_process.xmi
new file mode 100644
index 0000000..de9437c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/delivery_process.xmi
@@ -0,0 +1,29 @@
+<?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="_EijzoO8MEdmKSqa_gSYthg" name="delivery_process,_EhgqwO8MEdmKSqa_gSYthg" guid="_EijzoO8MEdmKSqa_gSYthg" changeDate="2005-10-27T14:10:27.282-0700">
+ <mainDescription><p>
+ A Delivery Process is a special <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific
+ project type. <!--StartFragment-->It provides a complete lifecycle model that has been detailed by sequencing Method
+ Content in breakdown structures. It describes a complete project lifecycle end-to-end and is used as a reference for
+ running projects with similar characteristics.
+</p>
+<p>
+ A&nbsp;process engineer can define alternative Delivery Processes for software development projects that differ in the
+ scale of the engagement and staffing necessary, the type of the software application to be developed, the development
+ methods and technologies to be used, etc. Although, the Delivery Process aims to cover a whole project it keeps certain
+ decision that are too project specific open.&nbsp;&nbsp;For example, the breakdown structure defines which Breakdown
+ Elements have multiple occurrences or are repeatable via its specific attributes, but does not say how many occurrences
+ and how many repeats/iterations it will have.&nbsp; These decisions have to be done by a project manager when planning
+ a concrete project, project phase, or project iterations.<!--EndFragment-->
+</p>
+<h3>
+ <a id="Software Engineering Process" name="Software Engineering Process">Example</a>
+</h3>
+<p>
+ In software engineering, the goal is to build a software product or to enhance an existing one. The Delivery Process
+ for software could be an iterative process, where the product is built incrementally over time, or it could be a
+ traditional waterfall Delivery Process in which all requirements are specified up front, followed by design,
+ implementation, and test phases.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/descriptor.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/descriptor.xmi
new file mode 100644
index 0000000..380efab
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/descriptor.xmi
@@ -0,0 +1,47 @@
+<?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="_5WJUUBUEEdqrUt4zetC1gg" name="descriptor,_5V9HEBUEEdqrUt4zetC1gg" guid="_5WJUUBUEEdqrUt4zetC1gg" changeDate="2005-11-15T10:35:38.218-0800">
+ <mainDescription><p>
+ A Descriptor represent an occurrence of one concrete Content Element (such as Task, Role, Work Product) in an Activity.
+ Descriptors provides a proxy-like representation for these Content Elements within breakdown structures. In addition to
+ just referencing Content Elements it allows overriding the Content Elements' structural relationships by defining its
+ own sets of associations.
+</p>
+<p>
+ Descriptors are a key concept for realizing the separation of Processes from Method Content. A Descriptor can be
+ characterized as a reference object for one particular Content Element, which has its own relationships and properties.
+ When a Descriptor is created, it has the same relationships as the referenced Content Element. However, users can
+ modify these relationships for the particular process situation for which the Descriptor has been created. The
+ Descriptor concept allows defining new relationships and specific process related properties. Descriptors are not
+ Content Elements and do not contain their own full descriptions. They refer or trace back to the Content Elements they
+ are based on instead.
+</p>
+<h3>
+ Example&nbsp;
+</h3>
+<p align="center">
+ <img alt="Example of Method Content referenced by Descriptor" src="resources/descriptors_uml.gif" />
+</p>
+<p align="center">
+ Example of Method Content referenced by Descriptors
+</p>
+<p>
+ <br />
+ The above illustration depicts an example using the UML 2.0 profile representation for UMA&nbsp;in which Descriptors
+ have been created for a Task, its performing Roles, as well as its input/output Work Products. The situation implied by
+ this example is that the Task "Prioritize Use Cases" is to be performed differently in a project's Inception phase than
+ in its Elaboration phase. (that is, with different emphasis on different Steps, utilizing different inputs, etc.). In
+ particular, we can observe the following:
+</p>
+<ul>
+ <li>
+ The Task in Inception has an additional assisting Role (Customer.Project Manager) and does not provide a
+ relationship to the Risk List Work Product that had been defined as an optional input in the Method Content (that
+ is, Steps of the Task that work with the Risk List will be omitted in this phase).
+ </li>
+ <li>
+ Two different types of Use Case Model Work Products are distinguished here: a Use Case Model as it is normally
+ being used during Inception, which describes use cases only briefly, versus use cases that have been detailed as it
+ is the case during the Elaboration phase.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/discipline.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/discipline.xmi
new file mode 100644
index 0000000..cb390a8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/discipline.xmi
@@ -0,0 +1,64 @@
+<?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="_zag6Q9nmEdmO6L4XMImrsA" name="discipline,3.409251897849429E-305" guid="_zag6Q9nmEdmO6L4XMImrsA" changeDate="2005-10-28T23:12:26.440-0700">
+ <mainDescription><a id="XE_DISCIPLINE__KEY_CONCEPTS" name="XE_discipline__key_concepts"></a>
+<p>
+ A Discipline is a collection of Tasks that are related to a major "area of concern" within the overall project. The
+ grouping of Tasks into Disciplines is mainly an aid to understanding the project from a traditional waterfall
+ perspective. Although it is more common to perform Tasks concurrently across several Disciplines (for example, certain
+ requirements Tasks are performed in close coordination with analysis and design Tasks), separating these Tasks into
+ distinct Disciplines is simply an effective way to organize content, which makes comprehension easier.
+</p>
+<p>
+ Another reason that several Tasks are all categorized by the same Discipline is that they all represent a part in
+ achieving a higher goal or performing work that is all related to each other.&nbsp; Every Discipline defines standard
+ ways of doing the work it categorizes.&nbsp; Such standard ways are expressed by so-called reference workflows
+ described with <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/capability_pattern,1.7072348895114264E-305.html"
+ guid="1.7072348895114264E-305">Capability Pattern</a>s defining how the Tasks categorized by the Discipline 'work
+ together' in the most generic way.&nbsp; These reference workflows are often used for educating and teaching
+ practitioners.
+</p>
+<p>
+ Like other workflows, a Discipline's reference workflow is a semi-ordered sequence of activities presented as either a
+ breakdown structure or an activity diagram performed to achieve a particular result. The "semi-ordered" nature of
+ Discipline workflows emphasizes that the Discipline workflows cannot present the real nuances of scheduling "real
+ work", for they cannot depict the optionality of activities or iterative nature of real projects. Yet they still have
+ value as a way for us to understand the process by breaking it into smaller areas of concern.
+</p>
+<h4>
+ Example: The role of Disciplines in Software Engineering
+</h4>
+<p>
+ In Software Development, each Discipline has associated with it one or more 'models', which are in turn composed of
+ associated Work Products. Some fundamental disciplines identified in Software are:
+</p>
+<ul>
+ <li>
+ Business Modeling
+ </li>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Analysis and Design
+ </li>
+ <li>
+ Implementation
+ </li>
+ <li>
+ Test
+ </li>
+ <li>
+ Deployment
+ </li>
+ <li>
+ Configuration and Change Management
+ </li>
+ <li>
+ Project Management
+ </li>
+ <li>
+ Environment
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/domain.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/domain.xmi
new file mode 100644
index 0000000..e7a057d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/domain.xmi
@@ -0,0 +1,11 @@
+<?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="_DiKm8BUGEdqrUt4zetC1gg" name="domain,_Dh4TEBUGEdqrUt4zetC1gg" guid="_DiKm8BUGEdqrUt4zetC1gg" changeDate="2005-09-22T14:32:59.052-0700">
+ <mainDescription><p>
+ A Domain is a refineable hierarchy designed to classify related Work Products. In other words, Domains are organized
+ into trees where individual Work Products appear as the leaves. Conceptually, each Domain is a grouping of related Work
+ Products that tend to be used for a similar purpose.
+</p>
+<p>
+ A&nbsp;single Work Product can be categorized in only one Domain.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/example.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/example.xmi
new file mode 100644
index 0000000..379f606
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/example.xmi
@@ -0,0 +1,12 @@
+<?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="_dCTLkBUBEdqrUt4zetC1gg" name="example,_dCG-UBUBEdqrUt4zetC1gg" guid="_dCTLkBUBEdqrUt4zetC1gg" changeDate="2005-09-07T03:57:41.587-0700">
+ <mainDescription><p>
+ An Example represents a typical, partially completed, sample instance of one or more Content Elements. Examples are
+ most commonly provided for Work Products. A Work Product Example is a good supplement to its prescriptive and
+ descriptive process Guidance.
+</p>
+<p>
+ Examples should be associated with specific Work Products to give their producer a view of how it should look like when
+ it is done.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/guideline.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/guideline.xmi
new file mode 100644
index 0000000..de190a9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/guideline.xmi
@@ -0,0 +1,31 @@
+<?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="_IBPFMBUEEdqrUt4zetC1gg" name="guideline,_IAwkEBUEEdqrUt4zetC1gg" guid="_IBPFMBUEEdqrUt4zetC1gg" changeDate="2005-10-30T17:23:28.397-0800">
+ <mainDescription><p>
+ A Guideline usually focuses on how to perform a particular Task or grouping of Tasks (for example, grouped together as
+ activities) or provides additional detail, rules, and recommendations on Work Products and their properties. Guidelines
+ can include details about a variety of topics including:
+</p>
+<ul>
+ <li>
+ Practices and different approaches for doing work,
+ </li>
+ <li>
+ How to handle particular kinds of Content Elements,
+ </li>
+ <li>
+ Information on different subtypes and variants of Content Elements and how they evolve throughout a lifecycle,
+ </li>
+ <li>
+ Discussions on skills the performing Roles should acquire,
+ </li>
+ <li>
+ Measurements of progress and maturity, etc.
+ </li>
+</ul>
+<p>
+ Work products typically have associated guidelines which present information on how to develop, evaluate and use the
+ Work Products . Guidelines contain much of the substance of a method and provide assistance in a number of contexts:
+ they help you decide what to do, they help doing it, they help assess the quality of the work, and they help understand
+ how a particular Work Product relates to the rest of the process.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/introduction_to_uma.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/introduction_to_uma.xmi
new file mode 100644
index 0000000..ee0edb8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/introduction_to_uma.xmi
@@ -0,0 +1,121 @@
+<?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>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/library.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/library.xmi
new file mode 100644
index 0000000..1b7f65c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/library.xmi
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_m83acBUFEdqrUt4zetC1gg" name="library,_m8lGkBUFEdqrUt4zetC1gg" guid="_m83acBUFEdqrUt4zetC1gg" changeDate="2005-09-07T03:52:29.278-0700">
+ <mainDescription><p align="center">
+ <font face="Arial, Helvetica, sans-serif"><img height="631" src="resources/packaging_picl.gif" width="905" /></font>
+</p>
+<p align="center">
+ <font face="Arial, Helvetica, sans-serif">Illustration of a Library with a Method Configuration highlighted in
+ Red</font>
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_library.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_library.xmi
new file mode 100644
index 0000000..04deb46
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_library.xmi
@@ -0,0 +1,10 @@
+<?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="_m83acBUFEdqrUt4zetC1gg" guid="_m83acBUFEdqrUt4zetC1gg" changeDate="2005-10-28T07:34:36.302-0700">
+ <mainDescription>Method Libraries represent physical storage of&nbsp;all Content and Process Elements as well as <a class="elementLink"
+href="./../../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>s. A Method Library defines a closed universe for all elements in
+it,&nbsp;since &nbsp;library elements cannot refer to other libraries.&nbsp; All user-defined extensions to method content
+and processes have to be done with <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/concepts/method_plugin,_0KeEMBUFEdqrUt4zetC1gg.html"
+guid="_0KeEMBUFEdqrUt4zetC1gg">Method Plugins</a>&nbsp;within the same physical library.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_package.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_package.xmi
new file mode 100644
index 0000000..1655135
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_package.xmi
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_iegZwBncEdqYreeU3jqaDQ" name="method_package,_idpeIBncEdqYreeU3jqaDQ" guid="_iegZwBncEdqYreeU3jqaDQ" changeDate="2005-09-07T01:34:01.431-0700">
+ <mainDescription><p>
+ <font face="Arial, Helvetica, sans-serif">A Method Package package defines how the method elements can be physically
+ organized in package hierarchies. It is an abstract class for packaging Method Elements. All Method Elements shall be
+ located in exactly one of Method Package’s concrete specializations (e.g. Content Package). Method Package defines
+ common properties for all of its specializations.</font>
+</p>
+<p>
+ <font face="Arial, Helvetica, sans-serif">Elements are organized in Method Packages to structure large scale of method
+ content and processes as well as to define a mechanism for reuse. Method Elements from one package can reuse element
+ from other packages by defining a reusedPackages link.</font>
+</p>
+<p>
+ <font face="Arial, Helvetica, sans-serif">For example, a work product defined in one package can be used as an input
+ for Tasks defined in other packages. By reusing it from one common place (i.e. the package in which it has been
+ defined) ensures that no redundant definitions of the same elements are required. Also maintenance of method content is
+ greatly improved as changes can be performed in only one place.</font>
+</p>
+<p>
+ <font face="Arial, Helvetica, sans-serif"><br />
+ Note, that other packages will introduce more specializations of Method Package, e.g. Process Package and Process
+ Component</font>.
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_plugin.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_plugin.xmi
new file mode 100644
index 0000000..6e52da4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/method_plugin.xmi
@@ -0,0 +1,18 @@
+<?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="_0LCr8BUFEdqrUt4zetC1gg" guid="_0LCr8BUFEdqrUt4zetC1gg" changeDate="2006-04-13T14:26:20.262-0700">
+ <mainDescription><p>
+ Method Plugin conceptually represents a unit for configuration, modularization, extension, packaging, and deployment of
+ method content and processes.&nbsp; A Process Engineer shall design&nbsp;Plugins and allocate content to these Plugins
+ with requirements for extensibility, modularity, reuse, and maintainability in mind.
+</p>
+<p>
+ Plug-ins can directly contribute new content, replace existing content, or to cross-reference to any Content Element or
+ Process within another Plug-in that it extends.&nbsp; Similar to UML 2.0's 'package merge' mechanism transformation
+ interpretations, interpreting these Method Plug-in mechanisms results into new extended Method Content and
+ Processes.&nbsp; For example, a might contain additional steps for Tasks, new Work Products extensions to existing
+ Roles to be responsible for the new Work Products, additional relationships of existing Content Elements to new
+ specific Guidance elements (such as Guidelines, White Papers, Checklists), additional Activities for a Delivery
+ Process, new Capability Patterns, etc.&nbsp; A Method Plug-in defines these extension using Variability Element
+ relationships and interpretation of these leads to new Method Content and Processes.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/outcome.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/outcome.xmi
new file mode 100644
index 0000000..81441e7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/outcome.xmi
@@ -0,0 +1,10 @@
+<?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="_pRmgYBUJEdqrUt4zetC1gg" name="outcome,_pROF4BUJEdqrUt4zetC1gg" guid="_pRmgYBUJEdqrUt4zetC1gg" changeDate="2005-10-26T18:17:53.880-0700">
+ <mainDescription><p>
+ An Outcome describes intangible Work Products that are a result or state, such as an installed server or optimized
+ network.&nbsp;As the occurrence of an Outcome is often informally documented (for example, through minutes or memos),
+ Outcomes may also be used to describe Work Products that are not formally defined.&nbsp;A key differentiator for
+ Outcomes against Artifacts is that Outcomes are not candidates for harvesting as reusable assets.&nbsp; Outcomes can
+ not have associated templates or examples and are not possible to reuse as assets on other projects.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/phase.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/phase.xmi
new file mode 100644
index 0000000..03e57de
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/phase.xmi
@@ -0,0 +1,36 @@
+<?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" epf:version="1.0.0" xmi:id="-bhzuf6RMHP3d-AHkoKDg7g" name="phase,__7xOEC7aEdqHMdmRzC0-2g" guid="-bhzuf6RMHP3d-AHkoKDg7g" changeDate="2007-02-27T09:17:14.810-0800" version="1.0.0">
+ <mainDescription><h3>
+ What is a Phase?
+</h3>
+<p>
+ While the entire purpose of a project is to produce a product, the specific goals of the team will vary substantially
+ throughout the project. In the beginning, there usually is considerable latitude in the requirements for the product.
+ It may not be clear whether the project is feasible or even if it is likely to be profitable. At that time, it is
+ critical to bring an answer to these questions, and of little to no value to start developing the product in
+ earnest.&nbsp;Towards the end of the project, the product itself is usually complete, and issues of quality, delivery,
+ and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work
+ products will have new content.
+</p>
+<p>
+ To coordinate the team’s efforts in a manner that takes these fundamental observations into account, the project
+ lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, its own iteration style
+ and customized <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">tasks</a> and <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">work products</a> to address the unique needs of the project at that point in time.
+</p>
+<p>
+ We recommend&nbsp;dividing the project lifecycle into&nbsp;four phases: Inception, Elaboration, Construction and
+ Transition.
+</p>
+<h3>
+ Iteration and Phases
+</h3>
+<p>
+ Each phase is divided into iterations. An iteration is a complete development loop resulting in a build (internal or
+ external) of an executable system, usually a subset of the final product under development, which grows incrementally
+ from iteration to iteration to become the final product.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/plugin.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/plugin.xmi
new file mode 100644
index 0000000..a0e21be
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/plugin.xmi
@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_0LCr8BUFEdqrUt4zetC1gg" name="method_plugin,_0KeEMBUFEdqrUt4zetC1gg" guid="_0LCr8BUFEdqrUt4zetC1gg" changeDate="2005-09-07T02:03:28.352-0700">
+ <mainDescription><p>
+ A Method Plugin is a Method Element that represents a physical container for Method Packages.&nbsp; It defines a
+ granularity level for the modularization and organization of method content and processes.&nbsp; A Method Plugin can
+ extend many other Method Plugins and it can be extended by many Method Plugins.&nbsp; It can also be used stand-alone,
+ i.e. with no Extension relationship to other plug-ins.
+</p>
+<p>
+ Method Plugin conceptually represents a unit for configuration, modularization, extension, packaging, and deployment of
+ method content and processes.&nbsp; A Process Engineer must design his Plugins and allocate his content to these
+ Plugins with requirements for extensibility, modularity, reuse, and maintainability in mind.&nbsp;<br />
+</p>
+<p>
+ Another use of Plugins is that they allow factoring out context or technology specific content into separate Method
+ Plugins.For example, his factoring allows one to alternatively choose one Method Plugin over another depending on the
+ technology used for the project (e.g. J2EE vs. .NET)
+</p></mainDescription>
+</com.ibm.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/practice.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/practice.xmi
new file mode 100644
index 0000000..5377fbb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/practice.xmi
@@ -0,0 +1,19 @@
+<?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="_s0dcwBUBEdqrUt4zetC1gg" name="practice,_szl6EBUBEdqrUt4zetC1gg" guid="_s0dcwBUBEdqrUt4zetC1gg" changeDate="2005-10-30T17:24:23.678-0800">
+ <mainDescription><p>
+ Practices are orthogonal to methods and processes. They often summarize aspects that impact many different parts of a
+ method or specific processes.
+</p>
+In Software Engineering, examples for practices include:
+<ul>
+ <li>
+ Manage Risks,
+ </li>
+ <li>
+ Continuously verify quality,
+ </li>
+ <li>
+ Architecture-centric and component-based development, etc.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/process_contribution.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/process_contribution.xmi
new file mode 100644
index 0000000..31cf786
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/process_contribution.xmi
@@ -0,0 +1,19 @@
+<?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="-x11qt8TVnuIKeMC69UP1TQ" name="process_contribution,_NYASQBtqEdqSLrJ4Ij2LVA" guid="-x11qt8TVnuIKeMC69UP1TQ" changeDate="2005-11-15T11:34:50.224-0800">
+ <mainDescription><p>
+ A Process Contribution is a special Process that externally defines additions and changes to an existing Process
+ without directly modifying the existing Process. It achieves this by describing these additions and changes in a
+ separate Process structure. This structures' elements relate to the other Process's elements using "Contributes" and
+ "Replace" specializations. Process Contributions are normally packaged with Method Plug-ins that extend existing Method
+ Plug-in with new capabilities.
+</p>
+<p>
+ A Process Contribution is a kind of "process plug-in" that plugs additional breakdown structures into an existing
+ Process and therefore updates it afterwards with new or changed capabilities. For example, the J2EE Plug-in plugs into
+ the technology independent main Plug-in. It may update the generic Delivery Processes defined in that Plug-in with J2EE
+ specific Activities. A respective ".NET Plug-in" could define similar updates relevant for that technology platform. A
+ process practitioner could then apply the chosen Plug-in, thereby generating a technology specific Process, but keeping
+ maintenance of his/her Processes minimal, because technology specific parts are kept separate and will be applied on
+ demand only.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/process_package.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/process_package.xmi
new file mode 100644
index 0000000..8de9fcb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/process_package.xmi
@@ -0,0 +1,2 @@
+<?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="_MUGiMBneEdqYreeU3jqaDQ" name="process_package,_MT6U8BneEdqYreeU3jqaDQ" guid="_MUGiMBneEdqYreeU3jqaDQ" changeDate="2005-09-22T14:34:16.793-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/release.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/release.xmi
new file mode 100644
index 0000000..c5175ed
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/release.xmi
@@ -0,0 +1,26 @@
+<?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="-dsgUC_uXte9wj6nt8DLHtw" name="release,_L5BIkC7uEdqHMdmRzC0-2g" guid="-dsgUC_uXte9wj6nt8DLHtw" changeDate="2005-09-26T17:32:36.683-0700">
+ <mainDescription><p>
+ A release can be internal or external. An internal release is used only by the development organization, as part of a
+ milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to users. A
+ release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured
+ only from an engineering perspective. Releases act as a forcing function that drives the development team to get
+ closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome.
+</p>
+<p>
+ <a class="elementLinkWithType" href="./../../../base_concepts/guidances/concepts/iteration,3.379871268737602E-305.html"
+ guid="3.379871268737602E-305">Concept: Iteration</a>s and releases allow a better usage over time of the various
+ specialties in the team: designers, testers, writers, and so forth. Regular releases let you break down the integration
+ and test issues and spread them across the development cycle. These issues have often been the downfall of large
+ projects because all problems were discovered at once during the single massive integration step, which occurred very
+ late in the cycle, and where a single problem halts the whole team.
+</p>
+<p>
+ With each Release,&nbsp;many <a class="elementLinkWithType"
+ href="./../../../base_concepts/guidances/concepts/work_product,4.804531471620803E-306.html"
+ guid="4.804531471620803E-306">Concept: Work Product</a>s&nbsp;are updated. It is said that this is a bit like "growing"
+ software. Instead of developing Work Products one after another, in a pipeline fashion, they are evolving across the
+ cycle, although at different rates.
+</p>
+<!--EndFragment--><!--EndFragment--><!--EndFragment--><!--EndFragment--></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/report.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/report.xmi
new file mode 100644
index 0000000..3986b7b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/report.xmi
@@ -0,0 +1,12 @@
+<?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="_x2-UYBUBEdqrUt4zetC1gg" name="report,_x2sAgBUBEdqrUt4zetC1gg" guid="_x2-UYBUBEdqrUt4zetC1gg" changeDate="2005-10-30T17:28:20.686-0800">
+ <mainDescription><p>
+ An example for a report would be a use case model survey, which is generated by extracting diagram information from a
+ graphical model and textual information from documents and combines these two types of information into a report.
+</p>
+<p>
+ Unlike regular Work Products, reports are not subject to version control. However they may be baselined to provide a
+ historic audit trail of the report over time. In some cases, the development tools enable the report to be reproduced
+ at any time by rerunning the report against the Work product's History.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl1.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl1.gif
new file mode 100644
index 0000000..ed7a877
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl2.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl2.gif
new file mode 100644
index 0000000..0204883
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl3.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl3.gif
new file mode 100644
index 0000000..adc6baa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl4.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl4.gif
new file mode 100644
index 0000000..15ed91e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/co_lfcl4.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/descriptors_uml.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/descriptors_uml.gif
new file mode 100644
index 0000000..29dd96e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/descriptors_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/guidance_uml.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/guidance_uml.gif
new file mode 100644
index 0000000..21d2b32
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/guidance_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/im_prar6.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/im_prar6.gif
new file mode 100644
index 0000000..122011d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/im_prar6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/infoset.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/infoset.gif
new file mode 100644
index 0000000..ee1442f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/infoset.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/iterative.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/iterative.gif
new file mode 100644
index 0000000..91f174f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/iterative.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/method_uml.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/method_uml.gif
new file mode 100644
index 0000000..a254a57
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/method_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/overview.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/overview.gif
new file mode 100644
index 0000000..b898efd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/overview.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/packaging_picl.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/packaging_picl.gif
new file mode 100644
index 0000000..376133d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/packaging_picl.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/packaging_uml.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/packaging_uml.gif
new file mode 100644
index 0000000..fa91c2d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/packaging_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma-evo.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma-evo.gif
new file mode 100644
index 0000000..350cc98
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma-evo.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_hump.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_hump.gif
new file mode 100644
index 0000000..fa0ad27
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_hump.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_hump.jpg b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_hump.jpg
new file mode 100644
index 0000000..7f4596e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_hump.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_m_vs_p.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_m_vs_p.gif
new file mode 100644
index 0000000..28cf1c3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_m_vs_p.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_processElts_uml.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_processElts_uml.gif
new file mode 100644
index 0000000..abb4fae
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/uma_processElts_uml.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/waterfall.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/waterfall.gif
new file mode 100644
index 0000000..495b64b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/waterfall.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/wf_req.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/wf_req.gif
new file mode 100644
index 0000000..d48bef3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/resources/wf_req.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/reusable_asset.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/reusable_asset.xmi
new file mode 100644
index 0000000..5bace2c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/reusable_asset.xmi
@@ -0,0 +1,8 @@
+<?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="_21rDABUBEdqrUt4zetC1gg" name="reusable_asset,_20bs4BUBEdqrUt4zetC1gg" guid="_21rDABUBEdqrUt4zetC1gg" changeDate="2005-10-07T18:47:08.091-0700">
+ <mainDescription><p>
+ &nbsp;A Reusable Asset typically includes source code, templates, patterns, but may also include architectural
+ frameworks, domain models, and so on.&nbsp; A Reusable Asset has usage rules which are the instructions describing how
+ the asset should be used.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/roadmap.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/roadmap.xmi
new file mode 100644
index 0000000..07e39f1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/roadmap.xmi
@@ -0,0 +1,14 @@
+<?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="_JCivABnXEdqYreeU3jqaDQ" name="roadmap,_JCQbIBnXEdqYreeU3jqaDQ" guid="_JCivABnXEdqYreeU3jqaDQ" changeDate="2005-10-07T18:47:16.384-0700">
+ <mainDescription><p>
+ An instance of a Roadmap represents important documentation for the Activity or Process it is related to. Often a
+ complex Activity such as a Process can be much easier understood by providing a walkthrough with a linear thread of a
+ typical instantiation of this Activity.
+</p>
+<p>
+ In addition to making the process practitioner understand how work in the process is being performed, a Roadmap
+ provides additional information about how Activities and Tasks relate to each other over time. Roadmaps are also used
+ to show how specific aspects are distributed over a whole process providing a kind of filter on the Process for this
+ information.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/role.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/role.xmi
new file mode 100644
index 0000000..82806f6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/role.xmi
@@ -0,0 +1,21 @@
+<?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="_zaqEMtnmEdmO6L4XMImrsA" name="role,1.1609745730665898E-304" guid="_zaqEMtnmEdmO6L4XMImrsA" changeDate="2006-04-13T14:30:25.906-0700">
+ <mainDescription><a id="Top" name="Top"></a><a id="XE_key_concepts__role" name="XE_key_concepts__role"></a><a id="XE_role__key_concepts"
+name="XE_role__key_concepts"></a>
+<p>
+ A Role is a Method Content element that defines a set of related skills, competencies, and responsibilities. Roles are
+ used by Tasks to specify who performs them as well as define a set of Work Products they are responsible for.
+</p>
+<p class="node" align="left">
+ Roles are typically realized by an individual, or a set of individuals, working together as a team. A project team
+ member typically fulfills many different roles. Note that <b>Roles are not individuals nor are they necessarily
+ equivalent to job titles;</b> instead, they describe how individuals should behave in the project and the
+ responsibilities of an individual. Individual members of the organization will wear different hats, or perform
+ different Roles. The mapping from individual to Role is performed by the project manager when planning and staffing the
+ project.
+</p>
+<p class="node" align="left">
+ While most roles are realized by people within the organization, people outside of the development organization play an
+ important role: for example, that of the stakeholder of the project or product being developed.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/role_set.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/role_set.xmi
new file mode 100644
index 0000000..5653cd4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/role_set.xmi
@@ -0,0 +1,24 @@
+<?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="_u4APkBUGEdqrUt4zetC1gg" name="role_set,_u3t7sBUGEdqrUt4zetC1gg" guid="_u4APkBUGEdqrUt4zetC1gg" changeDate="2005-10-28T23:15:33.184-0700">
+ <mainDescription><p>
+ Role Sets are used to group Roles together that have certain commonalities.
+</p>
+<p>
+ For example, in Software Engineering, the "Analysts" Role Set could group the
+</p>
+<ul>
+ <li>
+ Business Process Analyst
+ </li>
+ <li>
+ System Analyst
+ </li>
+ <li>
+ Requirements Specifier
+ </li>
+</ul>
+<p>
+ All of these Roles&nbsp;work with similar techniques and have overlapping skills, but are required to be
+ distinct&nbsp;by the&nbsp;software engineering method.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/supporting_material.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/supporting_material.xmi
new file mode 100644
index 0000000..7e0e02c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/supporting_material.xmi
@@ -0,0 +1,2 @@
+<?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="_80pi4BUBEdqrUt4zetC1gg" name="supporting_material,_80XPABUBEdqrUt4zetC1gg" guid="_80pi4BUBEdqrUt4zetC1gg" changeDate="2005-10-30T17:28:33.114-0800"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/task.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/task.xmi
new file mode 100644
index 0000000..40813dc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/task.xmi
@@ -0,0 +1,130 @@
+<?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="_zaqENNnmEdmO6L4XMImrsA" name="task,7.624729048911575E-305" guid="_zaqENNnmEdmO6L4XMImrsA" changeDate="2006-04-27T15:39:25.282-0700">
+ <mainDescription><a id="XE_ACTIVITY__KEY_CONCEPTS" name="XE_activity__key_concepts"></a>
+<h3>
+ Definition
+</h3>
+<p>
+ A Task describes a unit of work. Every Task is performed by specific Roles. The granularity of a Task is generally a
+ few hours to a few days. It usually affects one or only a small number of Work Products. Tasks are not necessarily used
+ as&nbsp;a basis for planning and tracking progress - they are often too fine-grained for that purpose; Activity
+ groupings of Tasks are often the better units for planning and tracking.
+</p>
+<p>
+ A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models,
+ classes, or&nbsp;plans. Within a Task, each performing Role achieves a well defined goal. A Task provides complete
+ step-by-step explanations of doing all the work required to achieve this goal. This description is complete,
+ independent of when in a process lifecycle the work would actually be done. Therefore, it does not describe when you do
+ what work at what point of time, but describes all the work that gets done throughout the development lifecycle that
+ contributes to the achievement of the Tasks' goal.
+</p>
+<p>
+ When a Task is being applied in a Process, a reference object defined as Task Descriptor provides information, which
+ includes what elements of the Task will actually be performed at that point in time. This assumes that a Task will
+ usually be performed in the Process over and over again, but each time with a slightly different emphasis on different
+ steps or aspects of the Task description&nbsp;as well as perhaps different or additional performing roles or different
+ input/output (also refer to <a class="elementLink"
+ href="./../../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html"
+ guid="_94_eoO8LEdmKSqa_gSYthg">Key Capabilities of the Unified Method Architecture (UMA)</a> for the difference between
+ Method Content and Process).
+</p>
+<h3>
+ Steps
+</h3>
+<p>
+ Tasks can be broken down into sections of Steps. A Step describes a meaningful and consistent part of the overall work
+ described for a Task. Steps fall into three main categories:
+</p>
+<ul>
+ <li>
+ <b>Thinking</b> Steps: where the individual performing the Role understands the nature of the Task, gathers and
+ examines the input Work Products, and formulates the result.
+ </li>
+ <li>
+ <b>Performing</b> Steps: where the individual performing the Role creates or updates some Work Products.
+ </li>
+ <li>
+ <b>Reviewing</b> Steps: where the individual performing the Role inspects the results against some criteria.
+ </li>
+</ul>
+<p>
+ Not all Steps are necessarily performed each time a Task is invoked, so they can be expressed in the form of alternate
+ flows (similar to Use Cases).
+</p>
+<h3>
+ Examples
+</h3>
+<h4>
+ A Typical Task
+</h4>
+<p>
+ A typical Task&nbsp;to "Develop Use-Case Model" would describe all the work that needs to be done to develop a complete
+ use-case model. This would consist of the following:
+</p>
+<ul>
+ <li>
+ The identification and naming of use cases and actors
+ </li>
+ <li>
+ The writing of a brief description
+ </li>
+ <li>
+ The modeling of use cases and their relationships in diagrams
+ </li>
+ <li>
+ The detailed description of a basic flow
+ </li>
+ <li>
+ The detailed description of alternative flows
+ </li>
+ <li>
+ Performing of walkthroughs, workshops and reviews, etc.
+ </li>
+</ul>
+<p>
+ All of these parts contribute to the development goal of developing the use case model, but the parts will be performed
+ at different points in time in a Process. Identification, naming, and brief descriptions would be performed
+ <strong>early</strong> in a typical development process versus the writing of detailed alternative flows which would be
+ performed much <strong>later</strong>. All these parts or Steps within the same Task define the "method" of developing
+ a use-case model. Applying such a method in a lifecycle is defining which Steps are done when going from one iteration
+ to the next.
+</p>
+<h4>
+ A Task and its Steps
+</h4>
+<p class="example">
+ A&nbsp;typical Task to "Find Use Cases and Actors"&nbsp;would be decomposed into the following Steps:
+</p>
+<blockquote>
+ <blockquote>
+ <ol>
+ <li>
+ Find actors
+ </li>
+ <li>
+ Find use cases
+ </li>
+ <li>
+ Describe how actors interact with use cases
+ </li>
+ <li>
+ Package use cases and actors
+ </li>
+ <li>
+ Present the use-case model in use-case diagrams
+ </li>
+ <li>
+ Develop a survey of the use-case model
+ </li>
+ <li>
+ Evaluate your results
+ </li>
+ </ol>
+ </blockquote>
+</blockquote>
+<p class="example">
+ The finding part [Steps 1 to 3] requires some thinking; the performing part [Steps 4 to 6] involves capturing the
+ result in the use-case model; the reviewing part [Step 7] is where the individual performing the Role evaluates the
+ result to assess completeness, robustness, intelligibility, or other qualities.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/team_profile.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/team_profile.xmi
new file mode 100644
index 0000000..1b32406
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/team_profile.xmi
@@ -0,0 +1,18 @@
+<?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="-J7jcN9p3FRyhuwV5Hq42Kw" name="team_profile,_dRKRMBtHEdqSLrJ4Ij2LVA" guid="-J7jcN9p3FRyhuwV5Hq42Kw" changeDate="2005-11-07T14:47:07.040-0800">
+ <mainDescription><p>
+ Work assignments and Work Product responsibilities can be different from Activity to Activity in a development project.
+ Different phases require different staffing profiles, that is, different skills and resources doing different types of
+ work. Therefore, a Process needs to define these profiles in a flexible manner. Whereas Core Method Content defines
+ standard responsibilities and assignments, a Process expressed in breakdown structures needs to be able to refine and
+ redefine these throughout its definition.
+</p>
+<p>
+ Role Descriptors, Composite Roles, as well as Team Profiles provide the data structure necessary to achieve this
+ flexibility and to provide&nbsp;Process users with the capability to define different teams and Role relationships for
+ every Activity (including Activities on any nesting level as well as Iterations or Phases). Hence, in addition to the
+ work breakdown and Work Product breakdown structures, Team Profiles are used to define a third type of breakdown
+ structure: The Team Breakdown Structure. It is created as an Activity specific hierarchy of Team Profiles comprising of
+ Role Descriptors and Composite Roles. These structures can be presented as Org-Charts.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/template.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/template.xmi
new file mode 100644
index 0000000..4605f7b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/template.xmi
@@ -0,0 +1,27 @@
+<?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="_G_m7ABUCEdqrUt4zetC1gg" name="template,_G_UnIBUCEdqrUt4zetC1gg" guid="_G_m7ABUCEdqrUt4zetC1gg" changeDate="2006-04-13T14:38:58.693-0700">
+ <mainDescription><p>
+ Templates are "models," or prototypes, of Work Products. Within a Work Product description, there usually are one or
+ more templates that can be used to create the corresponding Work Product. Templates are linked to the tool that is to
+ be used to create the Work Product. Prior to project start, organizations may want to customize the templates by adding
+ the company logo, some project identification, or information specific to the type of project.
+</p>
+<h3>
+ Example:
+</h3>
+<ul>
+ <li>
+ Word processor tools&nbsp;templates can be used for Work Products that are documents, and for some reports.
+ </li>
+ <li>
+ Automated report generation tools templates extract information from tools such as visual modeling tools,
+ requirements management tools or testing tools.
+ </li>
+ <li>
+ HTML tool templates for the various elements of the process.
+ </li>
+ <li>
+ Project planning tool&nbsp;template for the project plan.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/term_definition.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/term_definition.xmi
new file mode 100644
index 0000000..02e763f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/term_definition.xmi
@@ -0,0 +1,2 @@
+<?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="_Z7wmgBUDEdqrUt4zetC1gg" name="term_definition,_Z45fwBUDEdqrUt4zetC1gg" guid="_Z7wmgBUDEdqrUt4zetC1gg" changeDate="2005-09-07T02:52:32.005-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/tool.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/tool.xmi
new file mode 100644
index 0000000..1aebb22
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/tool.xmi
@@ -0,0 +1,13 @@
+<?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="_66cGsBUGEdqrUt4zetC1gg" name="tool,_66Jy0BUGEdqrUt4zetC1gg" guid="_66cGsBUGEdqrUt4zetC1gg" changeDate="2005-10-27T12:38:43.264-0700">
+ <mainDescription><p>
+ <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/tool_mentor,1.0762105093945226E-304.html"
+ guid="1.0762105093945226E-304">Tool Mentors</a>&nbsp;are a guidance type that define how work described with <a
+ class="elementLinkWithUserText" href="./../../../base_concepts/guidances/concepts/task,7.624729048911575E-305.html"
+ guid="7.624729048911575E-305">Tasks</a>&nbsp;or <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/activity,3.132140065969088E-305.html"
+ guid="3.132140065969088E-305">Activities</a>&nbsp;is to be performed using a specific tool.&nbsp; Every Tool Mentor
+ shall therefore be categorized by exactly one Tool category.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/tool_mentor.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/tool_mentor.xmi
new file mode 100644
index 0000000..66b0a40
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/tool_mentor.xmi
@@ -0,0 +1,13 @@
+<?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="_zaz1MtnmEdmO6L4XMImrsA" name="tool_mentor,1.0762105093945226E-304" guid="_zaz1MtnmEdmO6L4XMImrsA" changeDate="2006-04-13T14:41:01.910-0700">
+ <mainDescription><a id="Top" name="Top"></a><a id="XE_key_concepts__tool_mentor" name="XE_key_concepts__tool_mentor"></a><a
+id="XE_TOOL_MENTOR__KEY_CONCEPTS" name="XE_tool_mentor__key_concepts"></a>
+<p>
+ Tasks, Steps, and associated guidelines provide general guidance to the practitioner. To go one step further, Tool
+ Mentors are an additional means of providing guidance by showing how to achieve certain goals with a specific software
+ tool. Tool mentors link Tasks with tools such as visual modeling tools, requirements management tools, configuration
+ management tools, change requests/tracking tools and automated testing tools. Tool Mentors almost completely
+ encapsulate the dependencies of the content on the tool set, keeping the tasks free from tool details. An organization
+ can extend the concept of Tool Mentor to provide guidance for other tools.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/uma_diagrams.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/uma_diagrams.xmi
new file mode 100644
index 0000000..e78fbcf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/uma_diagrams.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="_H7U1ABUFEdqrUt4zetC1gg" name="uma_diagrams,_H7InwBUFEdqrUt4zetC1gg" guid="_H7U1ABUFEdqrUt4zetC1gg" changeDate="2005-08-24T18:11:23.031-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/view.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/view.xmi
new file mode 100644
index 0000000..44b4381
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/view.xmi
@@ -0,0 +1,16 @@
+<?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="_uMcmkBUFEdqrUt4zetC1gg" name="view,_uMKSsBUFEdqrUt4zetC1gg" guid="_uMcmkBUFEdqrUt4zetC1gg" changeDate="2005-10-26T23:55:52.721-0700">
+ <mainDescription><p>
+ Views are tabs that appear at the top of the tree browser within a published site. They identify pre-arranged
+ structured collections of content designed to facilitate its browsing by process users and practitioners.
+</p>
+<p>
+ A View is specified by defining a nested structure of <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/custom_category,_xuO10BUGEdqrUt4zetC1gg.html"
+ guid="_xuO10BUGEdqrUt4zetC1gg">Custom Categories</a> containing references to the&nbsp;Content Elements one desires to
+ publish within the view. Structurally, Views represent a selection of Custom Categories for one specific&nbsp;<a
+ class="elementLink" href="./../../../base_concepts/guidances/concepts/configuration,_d698IBUFEdqrUt4zetC1gg.html"
+ guid="_d698IBUFEdqrUt4zetC1gg">Method Configuration</a>. In other words, every configuration defines its views by
+ referring to a set of Custom Categories.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/white_paper.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/white_paper.xmi
new file mode 100644
index 0000000..61779cd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/white_paper.xmi
@@ -0,0 +1,7 @@
+<?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="_iePk8BUDEdqrUt4zetC1gg" name="white_paper,_id9REBUDEdqrUt4zetC1gg" guid="_iePk8BUDEdqrUt4zetC1gg" changeDate="2005-09-07T03:45:10.597-0700">
+ <mainDescription><p>
+ A whitepaper is a&nbsp;Guidance Type for externally&nbsp;published papers&nbsp;that can be read and understood in
+ isolation of other Content Elements and Guidance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/work_product.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/work_product.xmi
new file mode 100644
index 0000000..4bb5684
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/work_product.xmi
@@ -0,0 +1,47 @@
+<?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="_zaz1MNnmEdmO6L4XMImrsA" name="work_product,4.804531471620803E-306" guid="_zaz1MNnmEdmO6L4XMImrsA" changeDate="2006-04-13T15:39:29.597-0700">
+ <mainDescription><a id="XE_ARTIFACT__KEY_CONCEPTS" name="XE_artifact__key_concepts"></a>
+<h3>
+ Work Product
+</h3>
+<p>
+ A Work Product is a general abstraction that represents something resulting from the process.&nbsp; Work Products
+ include:
+</p>
+<ul>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/artifact,_fdRfkBUJEdqrUt4zetC1gg.html"
+ guid="_fdRfkBUJEdqrUt4zetC1gg">Artifact</a>
+ </li>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/deliverable,_lBgkMBUJEdqrUt4zetC1gg.html"
+ guid="_lBgkMBUJEdqrUt4zetC1gg">Deliverable</a>
+ </li>
+ <li>
+ <a class="elementlink" href="./../../../base_concepts/guidances/concepts/outcome,_pROF4BUJEdqrUt4zetC1gg.html"
+ guid="_pROF4BUJEdqrUt4zetC1gg">Outcome</a>
+ </li>
+</ul>
+<p>
+ Tasks have input and output Work Products. Roles use Work Products to perform Tasks, and produce other Work Products in
+ the course of performing Tasks. Work Products are the responsibility of a single Role, making responsibility easy to
+ identify and understand, and promoting the idea that every piece of information produced in the process requires the
+ appropriate set of skills. Even though one Role may "own" the Work Product, other Roles will use the Work Product,
+ perhaps even updating it if the Role has been given permission to do so.
+</p>
+<p align="center">
+ <map id="FPMap1" name="FPMap1">
+ </map><img height="569"
+ alt="Popular Work Products in Software Development, and the approximate dependency relationships between them."
+ src="resources/overview.gif" width="536" usemap="#FPMap1" border="0" />
+</p>
+<p class="picturetext" align="center">
+ Popular Work Products in Software Development, and the approximate dependency relationships between them.
+</p>
+<p>
+ Note that "<b>Work Product</b> " is the term used to describe what other processes denote using terms such as
+ <b>Artifact</b>, <b>work unit</b>, and so on. In UMA, <b>Deliverables</b> are only considered to be the subset of all
+ Work Products that will end up being delivered into the hands of the customers and users, usually as part of a formal
+ or contractually agreed hand-over.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/work_product_kind.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/work_product_kind.xmi
new file mode 100644
index 0000000..b3665aa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/concepts/work_product_kind.xmi
@@ -0,0 +1,31 @@
+<?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="_VRz4gBUGEdqrUt4zetC1gg" name="work_product_kind,_VRhkoBUGEdqrUt4zetC1gg" guid="_VRz4gBUGEdqrUt4zetC1gg" changeDate="2005-10-14T01:31:27.275-0700">
+ <mainDescription><p>
+ Work Products may take various shapes or forms, such as:
+</p>
+<ul>
+ <li>
+ A <b>model</b>, such as the Use-Case Model or the Design Model, which contains other Artifacts.
+ </li>
+ <li>
+ A <b>model element</b>; that is, an element within a model, such as a Design Class, a Use-Case or a Design
+ Subsystem.
+ </li>
+ <li>
+ <strong>Project data</strong> that might be kept in databases or other types of tabular information repositories
+ such as spreadsheets.
+ </li>
+ <li>
+ Source code and executable programs&nbsp;that contribute to the product or <strong>Solution.</strong>
+ </li>
+ <li>
+ Various types of documents, for example a <strong>specification</strong> document<strong>,</strong> such as
+ Requirements Specification, or a <strong>plan</strong> document, such as the Software Requirements Plan.
+ </li>
+</ul>
+<p>
+ They can therefore be categorized accordingly. An example is "<strong>Specification</strong>", which categorizes
+ requirements specifications that define a system with a well-defined system boundary, such as use case or functional
+ requirements specification. Unlike in Domains, a single Work Product can be categorized in multiple Work Product Kinds.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/about_base_concepts.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/about_base_concepts.xmi
new file mode 100644
index 0000000..1f9a5c0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/about_base_concepts.xmi
@@ -0,0 +1,28 @@
+<?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" epf:version="1.0.0" xmi:id="-V2B7_NtU_O7-45ldkX0Rrw" name="new_supporting_material,_uvje4D_fEdqDFvujd6NHiA" guid="-V2B7_NtU_O7-45ldkX0Rrw" changeDate="2006-09-27T19:24:54.186-0400" version="1.0.0">
+ <mainDescription><h3>
+ <a id="version" name="version">Version Information</a>
+</h3>
+<p>
+ Version 0.9
+</p>
+<h3>
+ Content
+</h3>
+<p>
+ This plug-in is a formal introduction to the Unified Method Architecture (UMA).
+</p>
+<p>
+ It&nbsp;positions UMA in terms of its goals and its novel aspects and defines all fundamental abstractions central to
+ UMA.
+</p>
+<p>
+ It is not dependent upon any other plug-ins.
+</p>
+<h3>
+ Legal Statement
+</h3>
+<p class="node">
+ See <a href="resources/copyrite.htm">Intellectual Property Notices</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/copyright.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/copyright.xmi
new file mode 100644
index 0000000..b2ea81a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/copyright.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="_u_Zg4PsDEdmyhNQr5STrZQ" name="copyright,_uuunoPsDEdmyhNQr5STrZQ" guid="_u_Zg4PsDEdmyhNQr5STrZQ" changeDate="2007-01-25T16:10:08.377-0800">
+ <mainDescription><p>
+ This program and the accompanying materials are made available under the<br />
+ <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a> which
+ accompanies this distribution.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/keyword_index.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/keyword_index.xmi
new file mode 100644
index 0000000..13e8257
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/keyword_index.xmi
@@ -0,0 +1,13 @@
+<?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="_zZxTYNnmEdmO6L4XMImrsA" name="keyword_index,2.0088322577945588E-305" guid="_zZxTYNnmEdmO6L4XMImrsA" changeDate="2005-06-14T08:32:05.050-0700">
+ <mainDescription><p class="banner" align="left">
+ The keyword index provides the ability to look-up topics in the method website based on keywords or topics. At the time
+ the pages are created, keywords are identified which allows the keyword index to be built. The top frame of the keyword
+ index window allows topics beginning with a letter or number to be displayed. The lower frame displays a list of topics
+ and their related links. Clicking on a link causes the related page to be displayed in the main frame of the published
+ site browser window.
+</p>
+<p class="banner" align="left">
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif
new file mode 100644
index 0000000..d1f6a31
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/about.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/about.gif
new file mode 100644
index 0000000..1316610
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/about.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/bookc.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/bookc.gif
new file mode 100644
index 0000000..7f2ab85
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/bookc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/bookcL.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/bookcL.gif
new file mode 100644
index 0000000..6c5b064
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/bookcL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/copyrite.htm b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/copyrite.htm
new file mode 100644
index 0000000..51edd3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/copyrite.htm
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>IBM(R) Rational(R) Intellectual Property Notices and Other Licensing Requirements</title>
+</head>
+
+<body>
+NOTICES AND INFORMATION <br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+About This Content
+</p>
+<p>
+May 2, 2006
+</p>
+<p>
+License
+</p>
+<p>
+The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
+</p>
+<p>
+If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributors license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
+ <br>
+</BODY>
+</HTML>
\ No newline at end of file
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/whats_new.gif b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/whats_new.gif
new file mode 100644
index 0000000..7039631
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/resources/whats_new.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/search_engine.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/search_engine.xmi
new file mode 100644
index 0000000..317a834
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/search_engine.xmi
@@ -0,0 +1,147 @@
+<?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="_zZxTYtnmEdmO6L4XMImrsA" name="search_engine,3.1789140222665413E-305" guid="_zZxTYtnmEdmO6L4XMImrsA" changeDate="2005-11-09T12:02:32.459-0800">
+ <mainDescription><p>
+ <a id="using" name="using"><strong>Note</strong>: The&nbsp;Search Engine, implemented as applets, requires JRE 1.4.2 or
+ higher (you can download a JRE from</a> <a href="http://java.sun.com/j2se"
+ target="_blank">http://java.sun.com/j2se</a><a id="using" name="using">).</a>
+</p>
+<h3>
+ Tips on Using the Search Engine
+</h3>
+<p>
+ The search engine allows you to search for pages in the&nbsp;published&nbsp;Web site in a number of ways. For example,
+ you can:
+</p>
+<ul>
+ <li>
+ Search for pages that contain <b>all</b> of the words that you have typed.
+ </li>
+ <li>
+ Search for pages that contain <b>any</b> of the words that you have typed.
+ </li>
+ <li>
+ Search for pages that contain the <b>exact phrase</b> that you have typed.
+ </li>
+ <li>
+ Search for pages that contain <b>none of the words</b> that you have typed.
+ </li>
+</ul>
+<p>
+ To enter a search query, type the words to be searched for in your choice of the <b>All the words</b>, <b>Any word</b>,
+ <b>Exact phrase</b>, and <b>Without the words</b> fields, and then press <tt>ENTER</tt> or click the <b>Search Now</b>
+ button. When the search is complete, each matching page will be listed in the <b>Results</b> field, showing the page
+ title and a short summary of the content. Click a title to open the page in your published siteWeb browser window.
+</p>
+<p>
+ For example, to search for pages that contain all of the words "Rational", "Unified", and "Process", and either or both
+ of the words "adopt" and "vision", type the words <tt>Rational Unified Process</tt> in the <b>All the words</b> field,
+ and <tt>adopt vision</tt> in the <b>Any word</b> field.
+</p>
+<p>
+ You can select how many results per page that you want by using the <b>Show</b> list. If the results are more than what
+ you selected to see per page, click the <b>next</b> and <b>previous</b> buttons to page through the results.
+</p>
+<p>
+ You can also indicate whether you want the query to be applied against the published web-site or developerWorks. To
+ choose between the published web-site and developerWorks, click the <b>In section</b> list, and then select the desired
+ section.
+</p>
+<h3>
+ <a id="finding" name="finding">Finding a Word on a Page</a>
+</h3>
+<p>
+ Once a page is displayed by the search engine, use the Web browser's search tool to find a specific word on that page.
+ Press <tt>CTRL+F</tt> to start the Web browser's search tool.
+</p>
+<h3>
+ <a id="entering" name="entering">Entering a Search Query</a>
+</h3>
+<p>
+ A search query consists of one or more specified words. Boolean operators cannot be used. Instead of Boolean operators,
+ use the <b>All the words</b>, <b>Any word</b>, <b>Exact phrase</b>, or <b>Without the word</b> fields that are
+ provided. The search process is not case-sensitive, which means that <font size="3"><tt>Hello, HELLO, and
+ hElLo</tt></font> are all considered the same. The wildcard symbol is not supported: <font size="3"><tt>*</tt></font>.
+</p>
+<p>
+ When more than one field is used, the query is evaluated with precedence from top to bottom. For example, the query:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="4" bordercolordark="#808080" cellpadding="4" width="350" bordercolorlight="#808080" border="0">
+ <tbody>
+ <tr>
+ <th align="left" width="40%">
+ All the words:
+ </th>
+ <td width="60%">
+ project management
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Any word</b>:
+ </th>
+ <td width="60%">
+ adopt vision
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Exact phrase</b>:
+ </th>
+ <td width="60%">
+ Rational Unified Process
+ </td>
+ </tr>
+ <tr>
+ <th align="left" width="40%">
+ <b>Without the words</b>:
+ </th>
+ <td width="60%">
+ implementation
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+ <br />
+</div>
+<p>
+ This can be expressed as the following: (project AND management) AND (adopt OR vision) AND (Rational Unified Process)
+ NOT (implementation). In other words, the matching pages must contain both of the words "project" and "management", the
+ word "adopt" or "vision", along with the phrase "Rational Unified Process". Matching pages must not contain the word
+ "implementation".
+</p>
+<h3>
+ <a id="special_considerations" name="special_considerations">Special Considerations</a>
+</h3>
+<ul>
+ <li>
+ The search engine automatically excludes common words such as "where", "when", and "the" from search queries,
+ because these words are excluded during the creation of the index files on which the search operates. Excluding
+ these words improves performance of the search without impacting the precision of the results.
+ </li>
+ <li>
+ In order for a query using the <b>Without the words</b> field to make sense, there must be text in at least one of
+ the other search fields. In other words, unless you first specify that you want the search to find pages that
+ <b>do</b> contain certain words or a specific phrase, the search engine cannot find pages that <b>do not</b>
+ contain certain words.
+ </li>
+ <li>
+ Wildcard searches using the wildcard character are not supported.
+ </li>
+ <li>
+ Boolean operators are not supported. See the section titled <a href="#entering">Entering a Search Query</a> for
+ instructions on how to perform searches that are equivalent to using Boolean operators.
+ </li>
+ <li>
+ You may obtain unsatisfactory search results for queries that attempt to search for single digit numbers in their
+ numeric format, especially the numbers 0 though 9. Instead of searching for the numeric value, either omit the
+ number from the search or use the full textual spelling of the number, for example "zero", "six", "nine", "ten" and
+ so forth.
+ </li>
+</ul>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.xmi
new file mode 100644
index 0000000..eefeca4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/supportingmaterials/whats_new_base_concepts.xmi
@@ -0,0 +1,25 @@
+<?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="-eyFTMGu83WSs-yJedYCY3g" name="new_supporting_material,_qxY8MEALEdqTMtYjAib0og" guid="-eyFTMGu83WSs-yJedYCY3g" changeDate="2006-01-18T23:07:01.069-0800">
+ <mainDescription><p>
+ For a description of this plug-in's contents, refer to <a class="elementLink"
+ href="./../../../base_concepts/guidances/supportingmaterials/about_base_concepts,_uvje4D_fEdqDFvujd6NHiA.html"
+ guid="_uvje4D_fEdqDFvujd6NHiA">About Base Concepts</a>.
+</p>
+<p>
+ The new features and changes from version to version are described below.
+</p>
+<ul>
+ <li>
+ <a href="#2.0">From&nbsp;2.0 to 2.0.1</a>
+ </li>
+ <li>
+ <a href="#1.0">1.0</a>
+ </li>
+</ul>
+<h2>
+ <a id="1.0" name="1.0">1.0</a>
+</h2>
+<p>
+ This is the initial release of this plug-in.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/activity.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/activity.xmi
new file mode 100644
index 0000000..aaac032
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/activity.xmi
@@ -0,0 +1,18 @@
+<?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" epf:version="1.0.0" xmi:id="-67u6-WRUmTOB9IdLgQg6aw" name="activity,_yoVhMB_IEdq6CKKKq4D7YA" guid="-67u6-WRUmTOB9IdLgQg6aw" changeDate="2007-02-27T09:04:48.571-0800" version="1.0.0">
+ <mainDescription><p>
+ An activity is something that one or more roles do.
+</p>
+<p>
+ In the <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html"
+ guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;, an activity is a <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html"
+ guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>&nbsp;which supports the nesting and logical grouping of related
+ process elements such as <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/descriptor,_7rS6AB_JEdq6CKKKq4D7YA.html"
+ guid="_7rS6AB_JEdq6CKKKq4D7YA">descriptor</a>&nbsp;and sub-activities, thus forming <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html"
+ guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/activity_detail_diagram.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/activity_detail_diagram.xmi
new file mode 100644
index 0000000..7b42d08
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/activity_detail_diagram.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="_ycE8HdnmEdmO6L4XMImrsA" name="activity_detail_diagram,_ycE8HNnmEdmO6L4XMImrsA" guid="_ycE8HdnmEdmO6L4XMImrsA" changeDate="2006-09-28T16:40:16.078-0400">
+ <mainDescription>Diagram depicting all the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s within the scope of an <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/activity,_yoVhMB_IEdq6CKKKq4D7YA.html" guid="_yoVhMB_IEdq6CKKKq4D7YA">activity</a>. This diagram also depicts input/output relationships between <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s,&nbsp;activities, and <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s;&nbsp;as well as responsibility relationships between <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html" guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and tasks. Activity detail diagrams are used to provide a complete summary of an
+activity&nbsp;and thus&nbsp;improve their comprehensibility.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/artifact.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/artifact.xmi
new file mode 100644
index 0000000..fbde4f9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/artifact.xmi
@@ -0,0 +1,12 @@
+<?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="_x7cUNNnmEdmO6L4XMImrsA" name="artifact,_x7cUM9nmEdmO6L4XMImrsA" guid="_x7cUNNnmEdmO6L4XMImrsA" changeDate="2006-08-31T13:52:50.953-0700">
+ <mainDescription>A formal <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;that:
+<div style="MARGIN-LEFT: 2em">
+ 1) is produced, modified, or used by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>,<br />
+ 2) defines an area of responsibility<br />
+ 3) is subject to version control.
+</div>
+<p>
+ An artifact can have multiple forms including a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/model,_yNefY9nmEdmO6L4XMImrsA.html" guid="_yNefY9nmEdmO6L4XMImrsA">model</a></i>, a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/model_element,_yNnpVdnmEdmO6L4XMImrsA.html" guid="_yNnpVdnmEdmO6L4XMImrsA">model element</a></i>, or a <i><a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/document,_yG6kY9nmEdmO6L4XMImrsA.html" guid="_yG6kY9nmEdmO6L4XMImrsA">document</a></i>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/breakdown_element.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/breakdown_element.xmi
new file mode 100644
index 0000000..060a3d4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/breakdown_element.xmi
@@ -0,0 +1,8 @@
+<?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="-7pbyO29v0VnsosWHabeZDQ" name="breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA" guid="-7pbyO29v0VnsosWHabeZDQ" changeDate="2005-09-22T19:07:46.580-0700">
+ <mainDescription>Any element modeled in <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html"
+guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that is part of <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;structure.<!--EndFragment--></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/breakdown_structure.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/breakdown_structure.xmi
new file mode 100644
index 0000000..f16fbc6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/breakdown_structure.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-dpUlq7kJXlJBUjvh7lHW7Q" name="breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA" guid="-dpUlq7kJXlJBUjvh7lHW7Q" changeDate="2006-09-28T16:44:00.796-0400">
+ <mainDescription><p>
+ A <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;construct that specifies a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;as the hierarchical composition of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/capability_pattern.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/capability_pattern.xmi
new file mode 100644
index 0000000..d951bc1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/capability_pattern.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-AY7-wWpxUmZp4c-odX8e7g" name="capability_pattern,_2RUJACO4EdqaNq6Ptg8uyA" guid="-AY7-wWpxUmZp4c-odX8e7g" changeDate="2007-02-27T09:52:34.463-0800" version="1.0.0">
+ <mainDescription><p>
+ <!--StartFragment-->A&nbsp;special <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;that describes a reusable cluster of <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/activity,_yoVhMB_IEdq6CKKKq4D7YA.html"
+ guid="_yoVhMB_IEdq6CKKKq4D7YA">activity</a>. Capability patterns express and communicate process knowledge for a key
+ area of interest such as a <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/discipline,_yGUuidnmEdmO6L4XMImrsA.html"
+ guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a>&nbsp;and can be directly used by&nbsp;practitioners to guide their work.
+ <!--EndFragment-->
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/checklist.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/checklist.xmi
new file mode 100644
index 0000000..0a16c51
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/checklist.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-d9uOWrjeHbE_1Xu2RIs-0A" name="new_term_definition,_7vpJsMaCEduMlb2cQZNTYw" guid="-d9uOWrjeHbE_1Xu2RIs-0A" changeDate="2007-02-27T09:01:08.783-0800">
+ <mainDescription>Identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as
+walkthroughs or inspections.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/composite_role.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/composite_role.xmi
new file mode 100644
index 0000000..0ff4765
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/composite_role.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-KNw2PnSSEEogCvg4sj1ebg" name="new_term_definition,_PzL7EMaEEduMlb2cQZNTYw" guid="-KNw2PnSSEEogCvg4sj1ebg" changeDate="2007-02-27T09:02:53.638-0800">
+ <mainDescription>A special role descriptor that relates to more than one <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a>. It represents a grouping of roles with the main purpose of reducing the number of
+roles defined in method content for a process.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/concept.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/concept.xmi
new file mode 100644
index 0000000..6dd4eef
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/concept.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-5bvXXNVzF7mZf0R7Oez5_g" name="new_term_definition,_wMchYMaEEduMlb2cQZNTYw" guid="-5bvXXNVzF7mZf0R7Oez5_g" changeDate="2007-02-27T09:06:17.781-0800">
+ <mainDescription>Outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general
+topics than <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guideline,_uK8HMMaFEduMlb2cQZNTYw.html"
+guid="_uK8HMMaFEduMlb2cQZNTYw">guidelines</a> and span across several work products, tasks, or activities.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/content_element.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/content_element.xmi
new file mode 100644
index 0000000..8ede4d2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/content_element.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-We7G-7OM2QspR_i1ErwtLA" name="content_element,_N8x34B_LEdq6CKKKq4D7YA" guid="-We7G-7OM2QspR_i1ErwtLA" changeDate="2006-09-28T16:46:45.015-0400">
+ <mainDescription>Any element modeled in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that is part of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/method_content,_Ts2joB_MEdq6CKKKq4D7YA.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">Method Content</a>. Content elements providestep-by-step explanations,describing how very
+specific development goals are achieved independent of the placement of these steps within a development lifecycle. They
+are instantiated and adapted to the specific situation within <a class="ELEMENTLINK" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;structures.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/content_package.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/content_package.xmi
new file mode 100644
index 0000000..89eafb7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/content_package.xmi
@@ -0,0 +1,15 @@
+<?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" epf:version="1.0.0" xmi:id="-t4Xac9J5DWCA6r1b9L40Mw" name=",_SAWgwMaFEduMlb2cQZNTYw" guid="-t4Xac9J5DWCA6r1b9L40Mw" changeDate="2007-02-27T09:10:22.988-0800">
+ <mainDescription>A&nbsp;special method package that contains <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a> exclusively. Examples for content element are <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/artifact,_x7cUM9nmEdmO6L4XMImrsA.html"
+guid="_x7cUM9nmEdmO6L4XMImrsA">artifacts</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>, <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a>, and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/custom_category.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/custom_category.xmi
new file mode 100644
index 0000000..506b86c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/custom_category.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-G9dXZH2IkpWGi4NZK-2vEw" name="new_term_definition,_eqw94MaFEduMlb2cQZNTYw" guid="-G9dXZH2IkpWGi4NZK-2vEw" changeDate="2007-02-27T09:11:39.800-0800">
+ <mainDescription>Used to categorize content based on the user's criteria. One important use is for constructing <a
+class="elementLinkWithUserText" href="./../../../base_concepts/guidances/termdefinitions/view,_GH6WUMaJEduMlb2cQZNTYw.html"
+guid="_GH6WUMaJEduMlb2cQZNTYw">views</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/customer.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/customer.xmi
new file mode 100644
index 0000000..4b69f3e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/customer.xmi
@@ -0,0 +1,7 @@
+<?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="_yE05tNnmEdmO6L4XMImrsA" name="customer,_yE05s9nmEdmO6L4XMImrsA" guid="_yE05tNnmEdmO6L4XMImrsA">
+ <mainDescription>A person or organization, internal or external to the producing organization, who takes financial responsibility for the
+system. In a large system this may or may not be the user. The customer is the ultimate recipient of the developed product.
+See also: <i><a class="elementLink" href="rup/guidances/termdefinitions/stakeholder,_yWHeDNnmEdmO6L4XMImrsA.html"
+guid="_yWHeDNnmEdmO6L4XMImrsA">stakeholder</a>.</i></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/deliverable.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/deliverable.xmi
new file mode 100644
index 0000000..98cd159
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/deliverable.xmi
@@ -0,0 +1,10 @@
+<?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="_yFbWodnmEdmO6L4XMImrsA" name="deliverable,_yFbWoNnmEdmO6L4XMImrsA" guid="_yFbWodnmEdmO6L4XMImrsA">
+ <mainDescription>An output from a <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that has a value, material or otherwise, to a <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/customer,_yE05s9nmEdmO6L4XMImrsA.html"
+guid="_yE05s9nmEdmO6L4XMImrsA">customer</a></i> or other <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/stakeholder,_yWHeDNnmEdmO6L4XMImrsA.html"
+guid="_yWHeDNnmEdmO6L4XMImrsA">stakeholder</a></i> .</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/delivery_process.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/delivery_process.xmi
new file mode 100644
index 0000000..9172121
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/delivery_process.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-IsV3QdyMdwFlqznd4UAYhw" name="delivery_process,_ZufeMCO3EdqaNq6Ptg8uyA" guid="-IsV3QdyMdwFlqznd4UAYhw" changeDate="2006-09-28T16:49:17.984-0400">
+ <mainDescription>A delivery process is a special <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific project
+type. <!--StartFragment-->It provides a complete lifecycle model that has been detailed by sequencing <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/method_content,_Ts2joB_MEdq6CKKKq4D7YA.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/descriptor.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/descriptor.xmi
new file mode 100644
index 0000000..3d05553
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/descriptor.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-TI6lqoTE1op3-SnmGa2S9Q" name="descriptor,_7rS6AB_JEdq6CKKKq4D7YA" guid="-TI6lqoTE1op3-SnmGa2S9Q" changeDate="2006-09-28T16:52:03.671-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a description is an abstract generalization for special <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s&nbsp;that reference one concrete <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>. Descriptors are the key concept for realizing the separation of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;from Method Content. A descriptor can be characterized as a reference
+object for one particular content element. In addition, a descriptor&nbsp;has its own relationships and properties whose
+purpose is to modify the semantics of the content element it refers to.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/discipline.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/discipline.xmi
new file mode 100644
index 0000000..23ec67e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/discipline.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="_yGUuitnmEdmO6L4XMImrsA" name="discipline,_yGUuidnmEdmO6L4XMImrsA" guid="_yGUuitnmEdmO6L4XMImrsA" changeDate="2006-09-28T16:52:55.750-0400">
+ <mainDescription>A&nbsp;collection of related <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s&nbsp;that define&nbsp;a major 'area of concern'. In software engineering,
+Disciplines include:&nbsp;<em>Requirements, Analysis &amp; Design, Implementation,Test,</em> and <em>Project
+Management</em>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/document.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/document.xmi
new file mode 100644
index 0000000..9316713
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/document.xmi
@@ -0,0 +1,7 @@
+<?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="_yG6kZNnmEdmO6L4XMImrsA" name="document,_yG6kY9nmEdmO6L4XMImrsA" guid="_yG6kZNnmEdmO6L4XMImrsA">
+ <mainDescription>A document is a collection of information intended to be represented on paper, or in a medium using a paper metaphor. The
+paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The
+information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets,
+schedules, Gantt charts, web-pages,&nbsp;and overhead slide presentations.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/domain.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/domain.xmi
new file mode 100644
index 0000000..34706f9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/domain.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="_yHEVYtnmEdmO6L4XMImrsA" name="domain,_yHEVYdnmEdmO6L4XMImrsA" guid="_yHEVYtnmEdmO6L4XMImrsA" changeDate="2007-02-27T11:45:19.192-0800">
+ <mainDescription><p>
+ (1)An area of knowledge or activity characterized by a family of related values.
+</p>
+<p>
+ (2) A specific problem category that is characterized by a body of knowledge, activities, and behaviors.
+</p>
+<p>
+ (3)A refineable hierarchy that groups related <a class="elementLink"
+ href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s.&nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/example.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/example.xmi
new file mode 100644
index 0000000..05a1c4e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/example.xmi
@@ -0,0 +1,12 @@
+<?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" epf:version="1.0.0" xmi:id="-WGi50KpVG9oQbP82Xvk1UA" name="new_term_definition,_nE6fsMaFEduMlb2cQZNTYw" guid="-WGi50KpVG9oQbP82Xvk1UA" changeDate="2007-02-27T09:12:23.699-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that represents a typical, partially completed, sample instance of one or more
+<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a>. Examples are most commonly provided for <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/guidance.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/guidance.xmi
new file mode 100644
index 0000000..50f31fd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/guidance.xmi
@@ -0,0 +1,10 @@
+<?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" epf:version="1.0.0" xmi:id="-CTatxBir28UK-VwWwDij-g" name="guidance,_83ttAB_NEdq6CKKKq4D7YA" guid="-CTatxBir28UK-VwWwDij-g" changeDate="2006-09-28T17:13:32.046-0400">
+ <mainDescription><p>
+ Guidance describes proven advice for accomplishing a goal.&nbsp;
+</p>
+<p>
+ In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, guidance generalizes all forms of content whose primary purpose is to provide
+ explanations about other UMA&nbsp;elements. Guidance being itself a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>, it is possible to associate guidance to other guidance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/guideline.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/guideline.xmi
new file mode 100644
index 0000000..6e83686
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/guideline.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-EEF1Y386HZ1XRsyHmGLE3g" name="new_term_definition,_uK8HMMaFEduMlb2cQZNTYw" guid="-EEF1Y386HZ1XRsyHmGLE3g" changeDate="2007-02-27T09:13:09.406-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that provides additional detail on how to handle a particular <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>. Guidelines most commonly apply to <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/input.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/input.xmi
new file mode 100644
index 0000000..eed2e20
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/input.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="_yK8IydnmEdmO6L4XMImrsA" name="input,_yK8IyNnmEdmO6L4XMImrsA" guid="_yK8IydnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:14:16.437-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>,
+input is a type of&nbsp;<a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;used by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a> See: <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/static_work_product,_yWaY9tnmEdmO6L4XMImrsA.html" guid="_yWaY9tnmEdmO6L4XMImrsA">static work product</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_configuration.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_configuration.xmi
new file mode 100644
index 0000000..75eaf45
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_configuration.xmi
@@ -0,0 +1,12 @@
+<?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" epf:version="1.0.0" xmi:id="-kzN6-iqn9zDtfnJc7IWkIg" name="new_term_definition,__V7pAMaEEduMlb2cQZNTYw" guid="-kzN6-iqn9zDtfnJc7IWkIg" changeDate="2007-02-27T09:08:12.573-0800">
+ <mainDescription>A method configuration specifies the selection of a logical subset of a <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_library,_1xELEMaFEduMlb2cQZNTYw.html"
+guid="_1xELEMaFEduMlb2cQZNTYw">method library</a>, in terms of <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_plugin,_D4TLgMaGEduMlb2cQZNTYw.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a>,&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_package,_SAWgwMaFEduMlb2cQZNTYw.html"
+guid="_SAWgwMaFEduMlb2cQZNTYw">content packages</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process_package,_MN1doMaHEduMlb2cQZNTYw.html"
+guid="_MN1doMaHEduMlb2cQZNTYw">process packages</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_content.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_content.xmi
new file mode 100644
index 0000000..6f07548
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_content.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-akU0PqDaad4Ns5MQhVBJ7Q" name="method_content,_Ts2joB_MEdq6CKKKq4D7YA" guid="-akU0PqDaad4Ns5MQhVBJ7Q" changeDate="2006-09-28T16:50:35.656-0400">
+ <mainDescription><p>
+ <!--StartFragment-->Describes generic <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a> methodological concepts and <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;which provide step-by-step explanations, describing how specific goals
+ are achieved independently of the placement of these steps within a process lifecycle. <!--EndFragment-->UMA separates
+ method content from its application in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_library.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_library.xmi
new file mode 100644
index 0000000..6e4d6fa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_library.xmi
@@ -0,0 +1,10 @@
+<?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" epf:version="1.0.0" xmi:id="-m6mx-VR4CReQNhrf4b8ykQ" name="new_term_definition,_1xELEMaFEduMlb2cQZNTYw" guid="-m6mx-VR4CReQNhrf4b8ykQ" changeDate="2007-02-27T09:13:59.698-0800">
+ <mainDescription>A&nbsp;physical container for <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/method_plugin,_D4TLgMaGEduMlb2cQZNTYw.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/configuration,__V7pAMaEEduMlb2cQZNTYw.html"
+guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a> definitions. All <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+guid="_N8x34B_LEdq6CKKKq4D7YA">method elements</a> are stored in a method library.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_plugin.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_plugin.xmi
new file mode 100644
index 0000000..359dad7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/method_plugin.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-q0ixH8duU7qb8agEywAFHQ" name="new_term_definition,_D4TLgMaGEduMlb2cQZNTYw" guid="-q0ixH8duU7qb8agEywAFHQ" changeDate="2007-02-27T09:15:37.261-0800">
+ <mainDescription>Represents a physical container for method packages. It defines a largest granularity level for the modularization and
+organization of <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/content_package,_SAWgwMaFEduMlb2cQZNTYw.html"
+guid="_SAWgwMaFEduMlb2cQZNTYw">method content</a> and <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">processes</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/model.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/model.xmi
new file mode 100644
index 0000000..e7c78fd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/model.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="_yNefZNnmEdmO6L4XMImrsA" name="model,_yNefY9nmEdmO6L4XMImrsA" guid="_yNefZNnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:16:05.562-0400">
+ <mainDescription><p>
+ A model is an abstraction of a more complicated thing.
+</p>
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/model_element.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/model_element.xmi
new file mode 100644
index 0000000..33a1591
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/model_element.xmi
@@ -0,0 +1,6 @@
+<?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="_yNnpVtnmEdmO6L4XMImrsA" name="model_element,_yNnpVdnmEdmO6L4XMImrsA" guid="_yNnpVtnmEdmO6L4XMImrsA" changeDate="2006-04-13T15:20:00.937-0700">
+ <mainDescription>An element that is an abstraction drawn from the system being modeled. Contrast: <i><a class="elementLink"
+href="./../../../base_concepts/guidances/termdefinitions/view_element,_ybefKdnmEdmO6L4XMImrsA.html"
+guid="_ybefKdnmEdmO6L4XMImrsA">view element</a></i>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/outcome.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/outcome.xmi
new file mode 100644
index 0000000..1827144
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/outcome.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-SQyJsrOEI73uLZzjRVmSBA" name="outcome,_LNAAcB_iEdqAHrsQ7-jSbw" guid="-SQyJsrOEI73uLZzjRVmSBA" changeDate="2006-09-28T17:18:20.984-0400">
+ <mainDescription><p>
+ <!--StartFragment-->Primarily describes intangible <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s that are a result or state. An outcome can also be used to represent
+ an informal work product.<!--EndFragment-->
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/output.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/output.xmi
new file mode 100644
index 0000000..8d2551e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/output.xmi
@@ -0,0 +1,10 @@
+<?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="_yPaZGtnmEdmO6L4XMImrsA" name="output,_yPaZGdnmEdmO6L4XMImrsA" guid="_yPaZGtnmEdmO6L4XMImrsA">
+ <mainDescription>(1) Any <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">Work Product</a>&nbsp;that is the result of a <a class="elementLink"
+href="file://./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>. See: <i><a class="elementLink"
+href="base_concepts/guidances/termdefinitions/deliverable,_yFbWoNnmEdmO6L4XMImrsA.html"
+guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a></i>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/phase.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/phase.xmi
new file mode 100644
index 0000000..13b85c7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/phase.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-88Vj7cM5EcVnfesDYaAkww" name="new_term_definition,_K9eecMaGEduMlb2cQZNTYw" guid="-88Vj7cM5EcVnfesDYaAkww" changeDate="2007-02-27T09:19:05.139-0800">
+ <mainDescription>The time between two major project <span class="docEmphasis">milestones</span>, during which a well-defined set of
+objectives is met, and decisions are made to move or not to move into the next phase.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/practice.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/practice.xmi
new file mode 100644
index 0000000..6b6bda4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/practice.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-kxtQBsUei9KRl8Z6tOSQ-g" name="new_term_definition,_wxYvkMaGEduMlb2cQZNTYw" guid="-kxtQBsUei9KRl8Z6tOSQ-g" changeDate="2007-02-27T09:20:41.644-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that presents a proven way or strategy of doing work to achieve a goal that has
+a positive impact on work product or process quality.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process.xmi
new file mode 100644
index 0000000..4756054
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="_yQ5m2dnmEdmO6L4XMImrsA" name="process,_yQ5m2NnmEdmO6L4XMImrsA" guid="_yQ5m2dnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:18:49.609-0400">
+ <mainDescription><p>
+ (1) A general structure for particular types of development projects.&nbsp;Processes take <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>s and relate them into semi-ordered sequences that are customized to
+ specific types of projects.&nbsp;Thus, a process is a set of partially ordered work descriptions intended to reach a
+ higher development goal, such as the release of a specific software&nbsp; <!--StartFragment-->These work descriptions
+ are organized into a hierarchical&nbsp;breakdown-structure A process focuses on the lifecycle and the sequencing of
+ work in <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.<br />
+</p>
+<p>
+ (2) The part of&nbsp; <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that models processes.
+</p>
+<!--EndFragment--></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process_contribution.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process_contribution.xmi
new file mode 100644
index 0000000..d9154a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process_contribution.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-fkIJikbdLETPdu0ALqo7fw" name="new_term_definition,_3iqPEMaGEduMlb2cQZNTYw" guid="-fkIJikbdLETPdu0ALqo7fw" changeDate="2007-02-27T09:21:33.607-0800">
+ <mainDescription>A special <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> that externally defines additions and changes to an existing process without
+directly modifying it.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process_package.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process_package.xmi
new file mode 100644
index 0000000..994f8cf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/process_package.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-GBZOfgyCAdK00NMpe1N5_Q" name="new_term_definition,_MN1doMaHEduMlb2cQZNTYw" guid="-GBZOfgyCAdK00NMpe1N5_Q" changeDate="2007-02-27T09:23:38.044-0800">
+ <mainDescription>A&nbsp;method package that contains processes such as <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/capability_pattern,_2RUJACO4EdqaNq6Ptg8uyA.html"
+guid="_2RUJACO4EdqaNq6Ptg8uyA">capability patterns</a> or <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/delivery_process,_ZufeMCO3EdqaNq6Ptg8uyA.html"
+guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery processes</a> only.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/release.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/release.xmi
new file mode 100644
index 0000000..a67c2e8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/release.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-hFYlBf3iN29RqVmHB9C4ug" name="new_term_definition,_Ua93IMaHEduMlb2cQZNTYw" guid="-hFYlBf3iN29RqVmHB9C4ug" changeDate="2007-02-27T11:26:19.003-0800">
+ <mainDescription>The delivery of a functional system meeting predefined objectives.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/report.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/report.xmi
new file mode 100644
index 0000000..d06aa80
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/report.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-lEbg0SKqsikKdCRXPVvRmw" name="new_term_definition,_bDCXUMaHEduMlb2cQZNTYw" guid="-lEbg0SKqsikKdCRXPVvRmw" changeDate="2007-02-27T09:25:39.894-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that is a predefined template of a result&nbsp;generated on the basis of other
+work products.&nbsp;An output from some form of tool automation.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/reusable_asset.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/reusable_asset.xmi
new file mode 100644
index 0000000..4029abf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/reusable_asset.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-H9RSfWhEhOJscNkDKGPcBA" name="new_term_definition,_kSKZUMaHEduMlb2cQZNTYw" guid="-H9RSfWhEhOJscNkDKGPcBA" changeDate="2007-02-27T09:27:04.167-0800">
+ <mainDescription>A <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that describes an asset -&nbsp;such as source code, templates, patterns,
+architectural frameworks, domain models, and so on - that can be reused in a different context.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/roadmap.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/roadmap.xmi
new file mode 100644
index 0000000..b47445e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/roadmap.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-gCtPvpHU3vmCQKQ1ymqBvw" name="new_term_definition,_19dWYMaHEduMlb2cQZNTYw" guid="-gCtPvpHU3vmCQKQ1ymqBvw" changeDate="2007-02-27T09:28:53.098-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that summarizes a process, often from a particular perspective, such as by
+providing a walkthrough with a linear thread of a typical instantiation of activities.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/role.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/role.xmi
new file mode 100644
index 0000000..02590bf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/role.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="_yUefQdnmEdmO6L4XMImrsA" name="role,_yUefQNnmEdmO6L4XMImrsA" guid="_yUefQdnmEdmO6L4XMImrsA" changeDate="2007-02-27T09:57:49.238-0800" version="1.0.0">
+ <mainDescription>A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/role_set.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/role_set.xmi
new file mode 100644
index 0000000..13fe6f4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/role_set.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-gOXu6EqfZHMmtekNk8IDqA" name="new_term_definition,_Fs8HAMaIEduMlb2cQZNTYw" guid="-gOXu6EqfZHMmtekNk8IDqA" changeDate="2007-02-27T09:30:38.023-0800">
+ <mainDescription>Used to group <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a> with certain commonalities together.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/stakeholder.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/stakeholder.xmi
new file mode 100644
index 0000000..0db1446
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/stakeholder.xmi
@@ -0,0 +1,8 @@
+<?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="_yWHeDdnmEdmO6L4XMImrsA" name="stakeholder,_yWHeDNnmEdmO6L4XMImrsA" guid="_yWHeDdnmEdmO6L4XMImrsA">
+ <mainDescription>An individual who is who is materially affected by the&nbsp;outcome of the <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;(i.e. the <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/deliverable,_yFbWoNnmEdmO6L4XMImrsA.html"
+guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s&nbsp;the process produces).</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/static_work_product.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/static_work_product.xmi
new file mode 100644
index 0000000..3ba979b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/static_work_product.xmi
@@ -0,0 +1,7 @@
+<?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="_yWaY99nmEdmO6L4XMImrsA" name="static_work_product,_yWaY9tnmEdmO6L4XMImrsA" guid="_yWaY99nmEdmO6L4XMImrsA" changeDate="2005-09-07T12:07:47.378-0700">
+ <mainDescription>A <a class="elementLink" href="base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;that is used, but not changed, by a <a class="elementLink"
+href="base_concepts/guidances/termdefinitions/process,_yQ5m2NnmEdmO6L4XMImrsA.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/step.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/step.xmi
new file mode 100644
index 0000000..91de21d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/step.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-KfXoeGTRnQImE1byTBtryQ" name="step,_BqZloB_eEdqAHrsQ7-jSbw" guid="-KfXoeGTRnQImE1byTBtryQ" changeDate="2006-09-28T17:22:18.140-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a step is <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>&nbsp;used to organize <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s into parts or subunits of work.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/supporting_material.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/supporting_material.xmi
new file mode 100644
index 0000000..62a65b8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/supporting_material.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-_-iQ4eQyiQVM7YhXcb90-g" name="new_term_definition,_SwvUgMaIEduMlb2cQZNTYw" guid="-_-iQ4eQyiQVM7YhXcb90-g" changeDate="2007-02-27T09:33:31.807-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that is a catch-all for other types of guidance not specifically defined
+elsewhere.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/task.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/task.xmi
new file mode 100644
index 0000000..0ebff29
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/task.xmi
@@ -0,0 +1,6 @@
+<?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="_x459k9nmEdmO6L4XMImrsA" name="task,_x459ktnmEdmO6L4XMImrsA" guid="_x459k9nmEdmO6L4XMImrsA" changeDate="2005-08-11T21:05:04.825-0700">
+ <mainDescription>A unit of work a <i><a class="elementLink"
+href="./../../../rup/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a></i> may be asked to perform.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/team_profile.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/team_profile.xmi
new file mode 100644
index 0000000..98ab95c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/team_profile.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-0cxbeJahkc1eqGKztRpcPw" name="new_term_definition,_rZOGIMaIEduMlb2cQZNTYw" guid="-0cxbeJahkc1eqGKztRpcPw" changeDate="2007-02-27T09:34:15.884-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA.html"
+guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a> that groups role descriptors or composite roles, thus defining a
+nested hierarchy of teams and team members.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/template.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/template.xmi
new file mode 100644
index 0000000..6abc890
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/template.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="--SOXfR7BTPs3CqtNP8R6Rw" name="new_term_definition,_1MLN8MaIEduMlb2cQZNTYw" guid="--SOXfR7BTPs3CqtNP8R6Rw" changeDate="2007-02-27T09:35:17.199-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that specifies the structure of a work product by providing a pre-defined
+table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions on how the sections
+and packages are supposed to be used and completed.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/term_definition.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/term_definition.xmi
new file mode 100644
index 0000000..b1aef3b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/term_definition.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-4JztP2JNqE36rtSC0UoYDw" name="new_term_definition,_6SluIMaIEduMlb2cQZNTYw" guid="-4JztP2JNqE36rtSC0UoYDw" changeDate="2007-02-27T09:36:03.287-0800">
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that defines concepts that are used to build up the glossary.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/tool.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/tool.xmi
new file mode 100644
index 0000000..3c9b629
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/tool.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-XnXEM7GkN21zwj7pKPmu3A" name="new_term_definition,_BangwMaJEduMlb2cQZNTYw" guid="-XnXEM7GkN21zwj7pKPmu3A" changeDate="2007-02-27T09:36:33.570-0800">
+ <mainDescription>A&nbsp;standard category used as a container for <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/tool_mentor,_yYy-mdnmEdmO6L4XMImrsA.html"
+guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentors</a>. It can also provide general descriptions of the tool and its general
+capabilities.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/tool_mentor.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/tool_mentor.xmi
new file mode 100644
index 0000000..fa53ebc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/tool_mentor.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="_yYy-mtnmEdmO6L4XMImrsA" name="tool_mentor,_yYy-mdnmEdmO6L4XMImrsA" guid="_yYy-mtnmEdmO6L4XMImrsA" changeDate="2006-09-28T17:23:13.140-0400">
+ <mainDescription>A tool mentor is a type of <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that explains how to perform specific <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>&nbsp;or <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/step,_BqZloB_eEdqAHrsQ7-jSbw.html" guid="_BqZloB_eEdqAHrsQ7-jSbw">step</a>s using a specific software tool.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/uma.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/uma.xmi
new file mode 100644
index 0000000..21cdf8f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/uma.xmi
@@ -0,0 +1,5 @@
+<?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="-QBSZ9hFRr8q6kvRyq1cESQ" name="uma,_cj6jkB_PEdq6CKKKq4D7YA" guid="-QBSZ9hFRr8q6kvRyq1cESQ" changeDate="2005-09-07T11:44:46.648-0700">
+ <mainDescription>Stands for&nbsp;Unified Method&nbsp;Architecture. UMA is a state-of-the-art architecture for the conceiving, specifying,
+and storing of method and process metadata.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/view.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/view.xmi
new file mode 100644
index 0000000..f724b3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/view.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-dLRBfqnBlgy_0_H13LmV3A" name="new_term_definition,_GH6WUMaJEduMlb2cQZNTYw" guid="-dLRBfqnBlgy_0_H13LmV3A" changeDate="2007-02-27T09:37:06.441-0800">
+ <mainDescription>Structured content collections designed to drive publication and facilitate browsing. They are specified using <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/custom_category,_eqw94MaFEduMlb2cQZNTYw.html"
+guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/view_element.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/view_element.xmi
new file mode 100644
index 0000000..85cbec7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/view_element.xmi
@@ -0,0 +1,6 @@
+<?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="_ybefKtnmEdmO6L4XMImrsA" name="view_element,_ybefKdnmEdmO6L4XMImrsA" guid="_ybefKtnmEdmO6L4XMImrsA" changeDate="2006-04-13T15:22:45.153-0700">
+ <mainDescription>A view element is a textual and/or graphical projection of a collection of <i><a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/model_element,_yNnpVdnmEdmO6L4XMImrsA.html"
+guid="_yNnpVdnmEdmO6L4XMImrsA">model elements</a></i>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/white_paper.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/white_paper.xmi
new file mode 100644
index 0000000..7d80d0a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/white_paper.xmi
@@ -0,0 +1,11 @@
+<?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" epf:version="1.0.0" xmi:id="-QLPRVsXtlVpWZiWmQPSsnw" name="new_term_definition,_Kc1IIMaJEduMlb2cQZNTYw" guid="-QLPRVsXtlVpWZiWmQPSsnw" changeDate="2007-02-27T09:37:42.024-0800">
+ <mainDescription><p>
+ A&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/guidance,_83ttAB_NEdq6CKKKq4D7YA.html"
+ guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;type for externally&nbsp;published papers&nbsp;that can be read and
+ understood in isolation of other <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html"
+ guid="_N8x34B_LEdq6CKKKq4D7YA">content elements</a> and guidance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/work_product.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/work_product.xmi
new file mode 100644
index 0000000..7fdf215
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/work_product.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-dcYwPivhczonAxeyXweyIQ" name="work_product,_H4JXwB_SEdq6CKKKq4D7YA" guid="-dcYwPivhczonAxeyXweyIQ" changeDate="2006-09-28T17:23:50.015-0400">
+ <mainDescription>In the <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/uma,_cj6jkB_PEdq6CKKKq4D7YA.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, a
+work product is a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/content_element,_N8x34B_LEdq6CKKKq4D7YA.html" guid="_N8x34B_LEdq6CKKKq4D7YA">content element</a>&nbsp;that represents&nbsp;anything used, produced, or modified by a <a class="elementLink" href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/work_product_kind.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/work_product_kind.xmi
new file mode 100644
index 0000000..d8991f3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/guidances/termdefinitions/work_product_kind.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-on4oCT1DzfksdshYPKAqGg" name="new_term_definition,_QWhfYMaJEduMlb2cQZNTYw" guid="-on4oCT1DzfksdshYPKAqGg" changeDate="2007-02-27T09:39:17.894-0800">
+ <mainDescription>Standard category that represents a grouping of related work products which, in contrast to <a
+class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/domain,_yHEVYdnmEdmO6L4XMImrsA.html"
+guid="_yHEVYdnmEdmO6L4XMImrsA">domain</a>, is more presentation oriented (like <a class="elementLinkWithUserText"
+href="./../../../base_concepts/guidances/termdefinitions/model,_yNefY9nmEdmO6L4XMImrsA.html"
+guid="_yNefY9nmEdmO6L4XMImrsA">models</a>, specifications, plans, and so on).</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/base_concepts/plugin.xmi b/OpenUP/OpenUP_baseline_EN/library/base_concepts/plugin.xmi
new file mode 100644
index 0000000..ca62d84
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/base_concepts/plugin.xmi
@@ -0,0 +1,502 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nIcf4fL5Edm6Nvont3uinw" guid="_nIcf4fL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nIPrkfL5Edm6Nvont3uinw" id="_6B9_MO8KEdmKSqa_gSYthg" uri="customcategories/obsolete.xmi"/>
+ <resourceDescriptors xmi:id="_nIPrlvL5Edm6Nvont3uinw" id="_972lYO8LEdmKSqa_gSYthg" uri="guidances/concepts/introduction_to_uma.xmi"/>
+ <resourceDescriptors xmi:id="_nIVyMvL5Edm6Nvont3uinw" id="_EijzoO8MEdmKSqa_gSYthg" uri="guidances/concepts/delivery_process.xmi"/>
+ <resourceDescriptors xmi:id="_vAKV4PsDEdmyhNQr5STrZQ" id="_u_Zg4PsDEdmyhNQr5STrZQ" uri="guidances/supportingmaterials/copyright.xmi"/>
+ <resourceDescriptors xmi:id="_b7_AgP1XEdmek8CQTQgrOQ" id="_rgwycf1WEdmek8CQTQgrOQ" uri="customcategories/Custom%20Categories.xmi"/>
+ <resourceDescriptors xmi:id="_RdbD0AIhEdqEutyfYo0quQ" id="_RdU9MAIhEdqEutyfYo0quQ" uri="customcategories/guidance.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE5fIwEdm7AIOuZcqunQ" id="_zaz1MtnmEdmO6L4XMImrsA" uri="guidances/concepts/tool_mentor.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE5PIwEdm7AIOuZcqunQ" id="_zaz1MNnmEdmO6L4XMImrsA" uri="guidances/concepts/work_product.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4_IwEdm7AIOuZcqunQ" id="_zaqENNnmEdmO6L4XMImrsA" uri="guidances/concepts/task.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4vIwEdm7AIOuZcqunQ" id="_zaqEMtnmEdmO6L4XMImrsA" uri="guidances/concepts/role.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4fIwEdm7AIOuZcqunQ" id="_zaqEMNnmEdmO6L4XMImrsA" uri="guidances/concepts/activity.xmi"/>
+ <resourceDescriptors xmi:id="_4RgE4PIwEdm7AIOuZcqunQ" id="_zag6RdnmEdmO6L4XMImrsA" uri="guidances/concepts/capability_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_xy2SAgIsEdqEutyfYo0quQ" id="_xy2SAQIsEdqEutyfYo0quQ" uri="customcategories/guidance%202.xmi"/>
+ <resourceDescriptors xmi:id="_4RT3pPIwEdm7AIOuZcqunQ" id="_zZxTYtnmEdmO6L4XMImrsA" uri="guidances/supportingmaterials/search_engine.xmi"/>
+ <resourceDescriptors xmi:id="_uDU1ogSEEdq61bDkWg1SXw" id="_uDU1oQSEEdq61bDkWg1SXw" uri="customcategories/method_architecture_fundamentals.xmi"/>
+ <resourceDescriptors xmi:id="_5_GjwASHEdq61bDkWg1SXw" id="_3uTl0QSHEdq61bDkWg1SXw" uri="customcategories/navigating_the_process.xmi"/>
+ <resourceDescriptors xmi:id="_4RZ-SPIwEdm7AIOuZcqunQ" id="_zag6Q9nmEdmO6L4XMImrsA" uri="guidances/concepts/discipline.xmi"/>
+ <resourceDescriptors xmi:id="_cdlH0ArjEdqtvYgC7fo_aQ" id="_xy2SAQIsEdqEutyfYo0quQ" uri="customcategories/guidance%202.xmi"/>
+ <resourceDescriptors xmi:id="_ceiKEArjEdqtvYgC7fo_aQ" id="_zZxTYNnmEdmO6L4XMImrsA" uri="guidances/supportingmaterials/keyword_index.xmi"/>
+ <resourceDescriptors xmi:id="_4R4fZfIwEdm7AIOuZcqunQ" id="_x459k9nmEdmO6L4XMImrsA" uri="guidances/termdefinitions/task.xmi"/>
+ <resourceDescriptors xmi:id="_4SQ55vIwEdm7AIOuZcqunQ" id="_x7cUNNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/artifact.xmi"/>
+ <resourceDescriptors xmi:id="_4Ud5VfIwEdm7AIOuZcqunQ" id="_yFbWodnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/deliverable.xmi"/>
+ <resourceDescriptors xmi:id="_4U2T0vIwEdm7AIOuZcqunQ" id="_yGUuitnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/discipline.xmi"/>
+ <resourceDescriptors xmi:id="_4VChEPIwEdm7AIOuZcqunQ" id="_yHEVYtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/domain.xmi"/>
+ <resourceDescriptors xmi:id="_4WkLEfIwEdm7AIOuZcqunQ" id="_yK8IydnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/input.xmi"/>
+ <resourceDescriptors xmi:id="_4YSCUPIwEdm7AIOuZcqunQ" id="_yPaZGtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/output.xmi"/>
+ <resourceDescriptors xmi:id="_4cGLVvIwEdm7AIOuZcqunQ" id="_ycE8HdnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/activity_detail_diagram.xmi"/>
+ <resourceDescriptors xmi:id="_4ZzsVvIwEdm7AIOuZcqunQ" id="_yUefQdnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/role.xmi"/>
+ <resourceDescriptors xmi:id="_4bbc8fIwEdm7AIOuZcqunQ" id="_yYy-mtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/tool_mentor.xmi"/>
+ <resourceDescriptors xmi:id="_4Yqc1fIwEdm7AIOuZcqunQ" id="_yQ5m2dnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/process.xmi"/>
+ <resourceDescriptors xmi:id="__c1VoBTLEdqrUt4zetC1gg" id="__cpIYBTLEdqrUt4zetC1gg" uri="customcategories/base_concepts_view_building_blocks.xmi"/>
+ <resourceDescriptors xmi:id="_WfwesBTMEdqrUt4zetC1gg" id="_WfkRcBTMEdqrUt4zetC1gg" uri="customcategories/method_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_ysYFcBTMEdqrUt4zetC1gg" id="_yrIvUBTMEdqrUt4zetC1gg" uri="customcategories/categories.xmi"/>
+ <resourceDescriptors xmi:id="_AtfIYBTQEdqrUt4zetC1gg" id="_AtZBwBTQEdqrUt4zetC1gg" uri="customcategories/process_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_TqVz8BTQEdqrUt4zetC1gg" id="_TqJmsBTQEdqrUt4zetC1gg" uri="customcategories/organizational_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_2w3YUBT9EdqrUt4zetC1gg" id="_2wY3MBT9EdqrUt4zetC1gg" uri="guidances/concepts/checklist.xmi"/>
+ <resourceDescriptors xmi:id="_dCZSMBUBEdqrUt4zetC1gg" id="_dCTLkBUBEdqrUt4zetC1gg" uri="guidances/concepts/example.xmi"/>
+ <resourceDescriptors xmi:id="_s0dcwRUBEdqrUt4zetC1gg" id="_s0dcwBUBEdqrUt4zetC1gg" uri="guidances/concepts/practice.xmi"/>
+ <resourceDescriptors xmi:id="_x3EbABUBEdqrUt4zetC1gg" id="_x2-UYBUBEdqrUt4zetC1gg" uri="guidances/concepts/report.xmi"/>
+ <resourceDescriptors xmi:id="_22VxYBUBEdqrUt4zetC1gg" id="_21rDABUBEdqrUt4zetC1gg" uri="guidances/concepts/reusable_asset.xmi"/>
+ <resourceDescriptors xmi:id="_80pi4RUBEdqrUt4zetC1gg" id="_80pi4BUBEdqrUt4zetC1gg" uri="guidances/concepts/supporting_material.xmi"/>
+ <resourceDescriptors xmi:id="_G_tBoBUCEdqrUt4zetC1gg" id="_G_m7ABUCEdqrUt4zetC1gg" uri="guidances/concepts/template.xmi"/>
+ <resourceDescriptors xmi:id="_Z72tIBUDEdqrUt4zetC1gg" id="_Z7wmgBUDEdqrUt4zetC1gg" uri="guidances/concepts/term_definition.xmi"/>
+ <resourceDescriptors xmi:id="_ieVrkBUDEdqrUt4zetC1gg" id="_iePk8BUDEdqrUt4zetC1gg" uri="guidances/concepts/white_paper.xmi"/>
+ <resourceDescriptors xmi:id="_IBPFMRUEEdqrUt4zetC1gg" id="_IBPFMBUEEdqrUt4zetC1gg" uri="guidances/concepts/guideline.xmi"/>
+ <resourceDescriptors xmi:id="_5WPa8BUEEdqrUt4zetC1gg" id="_5WJUUBUEEdqrUt4zetC1gg" uri="guidances/concepts/descriptor.xmi"/>
+ <resourceDescriptors xmi:id="_d7WWoBUFEdqrUt4zetC1gg" id="_d7QQABUFEdqrUt4zetC1gg" uri="guidances/concepts/configuration.xmi"/>
+ <resourceDescriptors xmi:id="_m9DnsBUFEdqrUt4zetC1gg" id="_m83acBUFEdqrUt4zetC1gg" uri="guidances/concepts/method_library.xmi"/>
+ <resourceDescriptors xmi:id="_uMitMBUFEdqrUt4zetC1gg" id="_uMcmkBUFEdqrUt4zetC1gg" uri="guidances/concepts/view.xmi"/>
+ <resourceDescriptors xmi:id="_0LCr8RUFEdqrUt4zetC1gg" id="_0LCr8BUFEdqrUt4zetC1gg" uri="guidances/concepts/method_plugin.xmi"/>
+ <resourceDescriptors xmi:id="_49tJsRUFEdqrUt4zetC1gg" id="_49tJsBUFEdqrUt4zetC1gg" uri="guidances/concepts/content_package.xmi"/>
+ <resourceDescriptors xmi:id="_DiQtkBUGEdqrUt4zetC1gg" id="_DiKm8BUGEdqrUt4zetC1gg" uri="guidances/concepts/domain.xmi"/>
+ <resourceDescriptors xmi:id="_VR5_IBUGEdqrUt4zetC1gg" id="_VRz4gBUGEdqrUt4zetC1gg" uri="guidances/concepts/work_product_kind.xmi"/>
+ <resourceDescriptors xmi:id="_u4GWMBUGEdqrUt4zetC1gg" id="_u4APkBUGEdqrUt4zetC1gg" uri="guidances/concepts/role_set.xmi"/>
+ <resourceDescriptors xmi:id="_xunQUBUGEdqrUt4zetC1gg" id="_xuhJsBUGEdqrUt4zetC1gg" uri="guidances/concepts/custom_category.xmi"/>
+ <resourceDescriptors xmi:id="_66iNUBUGEdqrUt4zetC1gg" id="_66cGsBUGEdqrUt4zetC1gg" uri="guidances/concepts/tool.xmi"/>
+ <resourceDescriptors xmi:id="_fdwAsBUJEdqrUt4zetC1gg" id="_fdds0BUJEdqrUt4zetC1gg" uri="guidances/concepts/artifact.xmi"/>
+ <resourceDescriptors xmi:id="_lCFL8BUJEdqrUt4zetC1gg" id="_lBy4EBUJEdqrUt4zetC1gg" uri="guidances/concepts/deliverable.xmi"/>
+ <resourceDescriptors xmi:id="_pRsnABUJEdqrUt4zetC1gg" id="_pRmgYBUJEdqrUt4zetC1gg" uri="guidances/concepts/outcome.xmi"/>
+ <resourceDescriptors xmi:id="_Tp7-8BUKEdqrUt4zetC1gg" id="_TpLJ8BUKEdqrUt4zetC1gg" uri="customcategories/uma_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_JCo1oBnXEdqYreeU3jqaDQ" id="_JCivABnXEdqYreeU3jqaDQ" uri="guidances/concepts/roadmap.xmi"/>
+ <resourceDescriptors xmi:id="_MUMo0BneEdqYreeU3jqaDQ" id="_MUGiMBneEdqYreeU3jqaDQ" uri="guidances/concepts/process_package.xmi"/>
+ <resourceDescriptors xmi:id="_dSHTcBtHEdqSLrJ4Ij2LVA" id="-FD4UbInbyzlaGxB9oPHdcg" uri="guidances/concepts/composite_role.xmi"/>
+ <resourceDescriptors xmi:id="_ghRXEBtHEdqSLrJ4Ij2LVA" id="-J7jcN9p3FRyhuwV5Hq42Kw" uri="guidances/concepts/team_profile.xmi"/>
+ <resourceDescriptors xmi:id="_nOZd8BtpEdqSLrJ4Ij2LVA" id="-G5kN9IUns9GPxohNmAeeyw" uri="customcategories/method_package.xmi"/>
+ <resourceDescriptors xmi:id="_sXC9UBtqEdqSLrJ4Ij2LVA" id="-x11qt8TVnuIKeMC69UP1TQ" uri="guidances/concepts/process_contribution.xmi"/>
+ <resourceDescriptors xmi:id="_3EDZoB87Edq-0cJih6RYrQ" id="_yNefZNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/model.xmi"/>
+ <resourceDescriptors xmi:id="_BHbGkB89Edq-0cJih6RYrQ" id="_ybefKtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/view_element.xmi"/>
+ <resourceDescriptors xmi:id="_IItYAB89Edq-0cJih6RYrQ" id="_yNnpVtnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/model_element.xmi"/>
+ <resourceDescriptors xmi:id="_OucV4B89Edq-0cJih6RYrQ" id="_yG6kZNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/document.xmi"/>
+ <resourceDescriptors xmi:id="_FETWYB8-Edq-0cJih6RYrQ" id="_yWHeDdnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/stakeholder.xmi"/>
+ <resourceDescriptors xmi:id="_NMio0B8-Edq-0cJih6RYrQ" id="_yE05tNnmEdmO6L4XMImrsA" uri="guidances/termdefinitions/customer.xmi"/>
+ <resourceDescriptors xmi:id="_x-GsIB8-Edq-0cJih6RYrQ" id="_yWaY99nmEdmO6L4XMImrsA" uri="guidances/termdefinitions/static_work_product.xmi"/>
+ <resourceDescriptors xmi:id="_7trfoB_JEdq6CKKKq4D7YA" id="-67u6-WRUmTOB9IdLgQg6aw" uri="guidances/termdefinitions/activity.xmi"/>
+ <resourceDescriptors xmi:id="_i_kKoB_KEdq6CKKKq4D7YA" id="-TI6lqoTE1op3-SnmGa2S9Q" uri="guidances/termdefinitions/descriptor.xmi"/>
+ <resourceDescriptors xmi:id="_auhsEB_LEdq6CKKKq4D7YA" id="-We7G-7OM2QspR_i1ErwtLA" uri="guidances/termdefinitions/content_element.xmi"/>
+ <resourceDescriptors xmi:id="_BRIPMB_MEdq6CKKKq4D7YA" id="-7pbyO29v0VnsosWHabeZDQ" uri="guidances/termdefinitions/breakdown_element.xmi"/>
+ <resourceDescriptors xmi:id="_t5D8YB_NEdq6CKKKq4D7YA" id="-akU0PqDaad4Ns5MQhVBJ7Q" uri="guidances/termdefinitions/method_content.xmi"/>
+ <resourceDescriptors xmi:id="_vOY7IB_OEdq6CKKKq4D7YA" id="-CTatxBir28UK-VwWwDij-g" uri="guidances/termdefinitions/guidance.xmi"/>
+ <resourceDescriptors xmi:id="_wnDhwB_PEdq6CKKKq4D7YA" id="-QBSZ9hFRr8q6kvRyq1cESQ" uri="guidances/termdefinitions/uma.xmi"/>
+ <resourceDescriptors xmi:id="_dYLAIB_REdq6CKKKq4D7YA" id="-dpUlq7kJXlJBUjvh7lHW7Q" uri="guidances/termdefinitions/breakdown_structure.xmi"/>
+ <resourceDescriptors xmi:id="_SqguIB_SEdq6CKKKq4D7YA" id="-dcYwPivhczonAxeyXweyIQ" uri="guidances/termdefinitions/work_product.xmi"/>
+ <resourceDescriptors xmi:id="_eZBtQB_eEdqAHrsQ7-jSbw" id="-KfXoeGTRnQImE1byTBtryQ" uri="guidances/termdefinitions/step.xmi"/>
+ <resourceDescriptors xmi:id="_mWA1IB_iEdqAHrsQ7-jSbw" id="-SQyJsrOEI73uLZzjRVmSBA" uri="guidances/termdefinitions/outcome.xmi"/>
+ <resourceDescriptors xmi:id="_LzRYcB_xEdq5PKe91GlWMA" id="_TpLJ8BUKEdqrUt4zetC1gg" uri="customcategories/uma_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_8MLCkCACEdqum6ped11dHA" id="_TpLJ8BUKEdqrUt4zetC1gg" uri="customcategories/uma_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_ZwaJwCO3EdqaNq6Ptg8uyA" id="_6B9_MO8KEdmKSqa_gSYthg" uri="customcategories/cc_list.xmi"/>
+ <resourceDescriptors xmi:id="_ZwmXACO3EdqaNq6Ptg8uyA" id="_uDU1oQSEEdq61bDkWg1SXw" uri="customcategories/method_architecture_fundamentals.xmi"/>
+ <resourceDescriptors xmi:id="_ZwsdoSO3EdqaNq6Ptg8uyA" id="__cpIYBTLEdqrUt4zetC1gg" uri="customcategories/base_concepts_view_building_blocks.xmi"/>
+ <resourceDescriptors xmi:id="_ZzjkYCO3EdqaNq6Ptg8uyA" id="_m83acBUFEdqrUt4zetC1gg" uri="guidances/concepts/method_library.xmi"/>
+ <resourceDescriptors xmi:id="_ZzprACO3EdqaNq6Ptg8uyA" id="_0LCr8BUFEdqrUt4zetC1gg" uri="guidances/concepts/method_plugin.xmi"/>
+ <resourceDescriptors xmi:id="_2RyqIiO4EdqaNq6Ptg8uyA" id="-IsV3QdyMdwFlqznd4UAYhw" uri="guidances/termdefinitions/delivery_process.xmi"/>
+ <resourceDescriptors xmi:id="_b2aiECO5EdqaNq6Ptg8uyA" id="-AY7-wWpxUmZp4c-odX8e7g" uri="guidances/termdefinitions/capability_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_XS6AsC7oEdqHMdmRzC0-2g" id="-bhzuf6RMHP3d-AHkoKDg7g" uri="guidances/concepts/phase.xmi"/>
+ <resourceDescriptors xmi:id="_nCEuoC7wEdqHMdmRzC0-2g" id="-dsgUC_uXte9wj6nt8DLHtw" uri="guidances/concepts/release.xmi"/>
+ <resourceDescriptors xmi:id="_1Uo8gD_fEdqDFvujd6NHiA" id="-V2B7_NtU_O7-45ldkX0Rrw" uri="guidances/supportingmaterials/about_base_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_3AVlUEALEdqTMtYjAib0og" id="-eyFTMGu83WSs-yJedYCY3g" uri="guidances/supportingmaterials/whats_new_base_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_Hq7agMaEEduMlb2cQZNTYw" id="-d9uOWrjeHbE_1Xu2RIs-0A" uri="guidances/termdefinitions/checklist.xmi"/>
+ <resourceDescriptors xmi:id="_XR3TIMaEEduMlb2cQZNTYw" id="-KNw2PnSSEEogCvg4sj1ebg" uri="guidances/termdefinitions/composite_role.xmi"/>
+ <resourceDescriptors xmi:id="_1su6IMaEEduMlb2cQZNTYw" id="-5bvXXNVzF7mZf0R7Oez5_g" uri="guidances/termdefinitions/concept.xmi"/>
+ <resourceDescriptors xmi:id="_OjgmcMaFEduMlb2cQZNTYw" id="-kzN6-iqn9zDtfnJc7IWkIg" uri="guidances/termdefinitions/method_configuration.xmi"/>
+ <resourceDescriptors xmi:id="_aPpdcMaFEduMlb2cQZNTYw" id="-t4Xac9J5DWCA6r1b9L40Mw" uri="guidances/termdefinitions/content_package.xmi"/>
+ <resourceDescriptors xmi:id="_lsCBMMaFEduMlb2cQZNTYw" id="-G9dXZH2IkpWGi4NZK-2vEw" uri="guidances/termdefinitions/custom_category.xmi"/>
+ <resourceDescriptors xmi:id="_sOPxAMaFEduMlb2cQZNTYw" id="-WGi50KpVG9oQbP82Xvk1UA" uri="guidances/termdefinitions/example.xmi"/>
+ <resourceDescriptors xmi:id="_zB_VscaFEduMlb2cQZNTYw" id="-EEF1Y386HZ1XRsyHmGLE3g" uri="guidances/termdefinitions/guideline.xmi"/>
+ <resourceDescriptors xmi:id="_6h6D4MaFEduMlb2cQZNTYw" id="-m6mx-VR4CReQNhrf4b8ykQ" uri="guidances/termdefinitions/method_library.xmi"/>
+ <resourceDescriptors xmi:id="_JEMooMaGEduMlb2cQZNTYw" id="-q0ixH8duU7qb8agEywAFHQ" uri="guidances/termdefinitions/method_plugin.xmi"/>
+ <resourceDescriptors xmi:id="_oC-N8MaGEduMlb2cQZNTYw" id="-88Vj7cM5EcVnfesDYaAkww" uri="guidances/termdefinitions/phase.xmi"/>
+ <resourceDescriptors xmi:id="_2bAqgcaGEduMlb2cQZNTYw" id="-kxtQBsUei9KRl8Z6tOSQ-g" uri="guidances/termdefinitions/practice.xmi"/>
+ <resourceDescriptors xmi:id="_-Kk-QMaGEduMlb2cQZNTYw" id="-fkIJikbdLETPdu0ALqo7fw" uri="guidances/termdefinitions/process_contribution.xmi"/>
+ <resourceDescriptors xmi:id="_SVMdcMaHEduMlb2cQZNTYw" id="-GBZOfgyCAdK00NMpe1N5_Q" uri="guidances/termdefinitions/process_package.xmi"/>
+ <resourceDescriptors xmi:id="_jkh3QcaHEduMlb2cQZNTYw" id="-lEbg0SKqsikKdCRXPVvRmw" uri="guidances/termdefinitions/report.xmi"/>
+ <resourceDescriptors xmi:id="_zUUJ4caHEduMlb2cQZNTYw" id="-H9RSfWhEhOJscNkDKGPcBA" uri="guidances/termdefinitions/reusable_asset.xmi"/>
+ <resourceDescriptors xmi:id="_D5S_IcaIEduMlb2cQZNTYw" id="-gCtPvpHU3vmCQKQ1ymqBvw" uri="guidances/termdefinitions/roadmap.xmi"/>
+ <resourceDescriptors xmi:id="_PS1DMMaIEduMlb2cQZNTYw" id="-gOXu6EqfZHMmtekNk8IDqA" uri="guidances/termdefinitions/role_set.xmi"/>
+ <resourceDescriptors xmi:id="_pL22sMaIEduMlb2cQZNTYw" id="-_-iQ4eQyiQVM7YhXcb90-g" uri="guidances/termdefinitions/supporting_material.xmi"/>
+ <resourceDescriptors xmi:id="_vwNUgMaIEduMlb2cQZNTYw" id="-0cxbeJahkc1eqGKztRpcPw" uri="guidances/termdefinitions/team_profile.xmi"/>
+ <resourceDescriptors xmi:id="_45GysMaIEduMlb2cQZNTYw" id="--SOXfR7BTPs3CqtNP8R6Rw" uri="guidances/termdefinitions/template.xmi"/>
+ <resourceDescriptors xmi:id="__wfhQMaIEduMlb2cQZNTYw" id="-4JztP2JNqE36rtSC0UoYDw" uri="guidances/termdefinitions/term_definition.xmi"/>
+ <resourceDescriptors xmi:id="_ERlt4caJEduMlb2cQZNTYw" id="-XnXEM7GkN21zwj7pKPmu3A" uri="guidances/termdefinitions/tool.xmi"/>
+ <resourceDescriptors xmi:id="_JK7bYcaJEduMlb2cQZNTYw" id="-dLRBfqnBlgy_0_H13LmV3A" uri="guidances/termdefinitions/view.xmi"/>
+ <resourceDescriptors xmi:id="_OekfQcaJEduMlb2cQZNTYw" id="-QLPRVsXtlVpWZiWmQPSsnw" uri="guidances/termdefinitions/white_paper.xmi"/>
+ <resourceDescriptors xmi:id="_hXmawcaJEduMlb2cQZNTYw" id="-on4oCT1DzfksdshYPKAqGg" uri="guidances/termdefinitions/work_product_kind.xmi"/>
+ <resourceDescriptors xmi:id="_ZkcCocaYEduMlb2cQZNTYw" id="-hFYlBf3iN29RqVmHB9C4ug" uri="guidances/termdefinitions/release.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_WCUhAO8KEdmKSqa_gSYthg" name="base_concepts" guid="_WCUhAO8KEdmKSqa_gSYthg" briefDescription="This plug-in contains basic concepts necessary to use the method composition tooling. This plug-in should be in ALL configurations." authors="IBM Rational" changeDate="2006-01-18T23:00:35.464-0800" version="1.0.1" copyrightStatement="_uuunoPsDEdmyhNQr5STrZQ">
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCanoO8KEdmKSqa_gSYthg" name="Content" guid="_WCanoO8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQO8KEdmKSqa_gSYthg" name="Categories" guid="_WCguQO8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQe8KEdmKSqa_gSYthg" name="Domains" guid="_WCguQe8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQu8KEdmKSqa_gSYthg" name="Disciplines" guid="_WCguQu8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguQ-8KEdmKSqa_gSYthg" name="RoleSets" guid="_WCguQ-8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguRO8KEdmKSqa_gSYthg" name="WP Types" guid="_WCguRO8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguRe8KEdmKSqa_gSYthg" name="Tools" guid="_WCguRe8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguRu8KEdmKSqa_gSYthg" name="StandardCategories" guid="_WCguRu8KEdmKSqa_gSYthg"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguR-8KEdmKSqa_gSYthg" name="CustomCategories" guid="_WCguR-8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguSO8KEdmKSqa_gSYthg" name="Hidden" guid="_WCguSO8KEdmKSqa_gSYthg">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_WCguSe8KEdmKSqa_gSYthg" name="Custom Categories" guid="_WCguSe8KEdmKSqa_gSYthg" categorizedElements="_5_90EO8KEdmKSqa_gSYthg _7-x6YBTLEdqrUt4zetC1gg">
+ <presentation xmi:id="_rgwycf1WEdmek8CQTQgrOQ" href="uma://_rgwycf1WEdmek8CQTQgrOQ#_rgwycf1WEdmek8CQTQgrOQ"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_5_90EO8KEdmKSqa_gSYthg" name="cc_list" guid="_5_90EO8KEdmKSqa_gSYthg" briefDescription="This is a package of custom categories that can be used to compose views. It should never be used as a view itself." presentationName="Component Category List" categorizedElements="_3uTl0ASHEdq61bDkWg1SXw _xy2SAAIsEdqEutyfYo0quQ _AtM0gBTQEdqrUt4zetC1gg _R5Vk4BtpEdqSLrJ4Ij2LVA _Tp3S0BTQEdqrUt4zetC1gg _uDU1oASEEdq61bDkWg1SXw _WfL28BTMEdqrUt4zetC1gg _yqwU0BTMEdqrUt4zetC1gg">
+ <presentation xmi:id="_6B9_MO8KEdmKSqa_gSYthg" href="uma://_6B9_MO8KEdmKSqa_gSYthg#_6B9_MO8KEdmKSqa_gSYthg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_RdIv8AIhEdqEutyfYo0quQ" name="guidance" guid="_RdIv8AIhEdqEutyfYo0quQ" presentationName="Guidance" categorizedElements="1.0762105093945226E-304">
+ <presentation xmi:id="_RdU9MAIhEdqEutyfYo0quQ" href="uma://_RdU9MAIhEdqEutyfYo0quQ#_RdU9MAIhEdqEutyfYo0quQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_xy2SAAIsEdqEutyfYo0quQ" name="guidance" guid="_xy2SAAIsEdqEutyfYo0quQ" briefDescription="Guidance is an abstract concept that generalizes all forms of content whose primary purpose is to provide additional explanations and illustrations to elements such as Roles, Tasks, Work Products, Activities, or Processes." presentationName="Guidance" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_7vpJsMaCEduMlb2cQZNTYw _wMchYMaEEduMlb2cQZNTYw _nE6fsMaFEduMlb2cQZNTYw _uK8HMMaFEduMlb2cQZNTYw _wxYvkMaGEduMlb2cQZNTYw _bDCXUMaHEduMlb2cQZNTYw _kSKZUMaHEduMlb2cQZNTYw _19dWYMaHEduMlb2cQZNTYw _SwvUgMaIEduMlb2cQZNTYw _1MLN8MaIEduMlb2cQZNTYw _6SluIMaIEduMlb2cQZNTYw _yYy-mdnmEdmO6L4XMImrsA _Kc1IIMaJEduMlb2cQZNTYw">
+ <presentation xmi:id="_xy2SAQIsEdqEutyfYo0quQ" href="uma://_xy2SAQIsEdqEutyfYo0quQ#_xy2SAQIsEdqEutyfYo0quQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_uDU1oASEEdq61bDkWg1SXw" name="method_architecture_fundamentals" guid="_uDU1oASEEdq61bDkWg1SXw" briefDescription="Introduces fundamental UMA principles, concepts, abstractions." presentationName="Method Architecture Fundamentals" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_WfL28BTMEdqrUt4zetC1gg _xy2SAAIsEdqEutyfYo0quQ _AtM0gBTQEdqrUt4zetC1gg _Tp3S0BTQEdqrUt4zetC1gg _cj6jkB_PEdq6CKKKq4D7YA">
+ <presentation xmi:id="_uDU1oQSEEdq61bDkWg1SXw" href="uma://_uDU1oQSEEdq61bDkWg1SXw#_uDU1oQSEEdq61bDkWg1SXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_3uTl0ASHEdq61bDkWg1SXw" name="navigating_the_process" guid="_3uTl0ASHEdq61bDkWg1SXw" briefDescription="This guidance explains how to navigate a typical method Web site." presentationName="Navigating the Method Web Site" shapeicon="base_concepts/customcategories/resources/compassL.gif" nodeicon="base_concepts/customcategories/resources/compass.gif" categorizedElements="3.1789140222665413E-305 2.0088322577945588E-305">
+ <presentation xmi:id="_3uTl0QSHEdq61bDkWg1SXw" href="uma://_3uTl0QSHEdq61bDkWg1SXw#_3uTl0QSHEdq61bDkWg1SXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_7-x6YBTLEdqrUt4zetC1gg" name="base_concepts_view_building_blocks" guid="_7-x6YBTLEdqrUt4zetC1gg" briefDescription="This is a package of custom categories that can be used to compose views. It should never be used as a view itself." presentationName="Base Concepts View Building Blocks" categorizedElements="_3uTl0ASHEdq61bDkWg1SXw _uDU1oASEEdq61bDkWg1SXw">
+ <presentation xmi:id="__cpIYBTLEdqrUt4zetC1gg" href="uma://__cpIYBTLEdqrUt4zetC1gg#__cpIYBTLEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_WfL28BTMEdqrUt4zetC1gg" name="method_concepts" guid="_WfL28BTMEdqrUt4zetC1gg" briefDescription="UMA's fundamental Method Content abstractions are Work Products, Roles, Tasks, and Guidance." presentationName="Method Content Concepts" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_yqwU0BTMEdqrUt4zetC1gg _yUefQNnmEdmO6L4XMImrsA _x459ktnmEdmO6L4XMImrsA _x7cUM9nmEdmO6L4XMImrsA _yFbWoNnmEdmO6L4XMImrsA _LNAAcB_iEdqAHrsQ7-jSbw _H4JXwB_SEdq6CKKKq4D7YA">
+ <presentation xmi:id="_WfkRcBTMEdqrUt4zetC1gg" href="uma://_WfkRcBTMEdqrUt4zetC1gg#_WfkRcBTMEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_yqwU0BTMEdqrUt4zetC1gg" name="categories" guid="_yqwU0BTMEdqrUt4zetC1gg" briefDescription="Categories provide different ways to logically organize Method Content elements." presentationName="Categories and Views" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_eqw94MaFEduMlb2cQZNTYw _yGUuidnmEdmO6L4XMImrsA _yHEVYdnmEdmO6L4XMImrsA _Fs8HAMaIEduMlb2cQZNTYw _BangwMaJEduMlb2cQZNTYw _GH6WUMaJEduMlb2cQZNTYw _QWhfYMaJEduMlb2cQZNTYw">
+ <presentation xmi:id="_yrIvUBTMEdqrUt4zetC1gg" href="uma://_yrIvUBTMEdqrUt4zetC1gg#_yrIvUBTMEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_AtM0gBTQEdqrUt4zetC1gg" name="process_concepts" guid="_AtM0gBTQEdqrUt4zetC1gg" briefDescription="UMA defines concepts for defining processes. This section lists the most important ones." presentationName="Process Concepts" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_yoVhMB_IEdq6CKKKq4D7YA _2RUJACO4EdqaNq6Ptg8uyA _ZufeMCO3EdqaNq6Ptg8uyA _7rS6AB_JEdq6CKKKq4D7YA _3iqPEMaGEduMlb2cQZNTYw">
+ <presentation xmi:id="_AtZBwBTQEdqrUt4zetC1gg" href="uma://_AtZBwBTQEdqrUt4zetC1gg#_AtZBwBTQEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_Tp3S0BTQEdqrUt4zetC1gg" name="organizational_concepts" guid="_Tp3S0BTQEdqrUt4zetC1gg" briefDescription="This section lists several key concepts define in UMA for packaging and extending methods." presentationName="Organizational Concepts" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_SAWgwMaFEduMlb2cQZNTYw _1xELEMaFEduMlb2cQZNTYw _D4TLgMaGEduMlb2cQZNTYw __V7pAMaEEduMlb2cQZNTYw">
+ <presentation xmi:id="_TqJmsBTQEdqrUt4zetC1gg" href="uma://_TqJmsBTQEdqrUt4zetC1gg#_TqJmsBTQEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_R5Vk4BtpEdqSLrJ4Ij2LVA" name="method_package" guid="_R5Vk4BtpEdqSLrJ4Ij2LVA" briefDescription="This packaging structure defines how Method Elements can be physically organized into package hierarchies." presentationName="Method Package" shapeicon="base_concepts/customcategories/resources/concept_dgm32.gif" nodeicon="base_concepts/customcategories/resources/concept_obj.gif" categorizedElements="_SAWgwMaFEduMlb2cQZNTYw _MN1doMaHEduMlb2cQZNTYw">
+ <presentation xmi:id="-G5kN9IUns9GPxohNmAeeyw" href="uma://-G5kN9IUns9GPxohNmAeeyw#-G5kN9IUns9GPxohNmAeeyw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_WCguSu8KEdmKSqa_gSYthg" name="CoreContent" guid="_WCguSu8KEdmKSqa_gSYthg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_eNnSAO8LEdmKSqa_gSYthg" name="General Guidance" guid="_eNnSAO8LEdmKSqa_gSYthg" briefDescription="This Content package concepts and other general guidance related to UMA and related tooling.">
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_uuunoPsDEdmyhNQr5STrZQ" name="copyright" guid="_uuunoPsDEdmyhNQr5STrZQ" presentationName="Copyright" nodeicon="base_concepts/guidances/supportingmaterials/resources/CRsym_obj.gif">
+ <presentation xmi:id="_u_Zg4PsDEdmyhNQr5STrZQ" href="uma://_u_Zg4PsDEdmyhNQr5STrZQ#_u_Zg4PsDEdmyhNQr5STrZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="3.1789140222665413E-305" name="search_engine" guid="3.1789140222665413E-305" briefDescription="The search engine allows you to search for pages in the published Web Site." presentationName="Search Engine" shapeicon="base_concepts/guidances/supportingmaterials/resources/bookcL.gif" nodeicon="base_concepts/guidances/supportingmaterials/resources/bookc.gif">
+ <presentation xmi:id="_zZxTYtnmEdmO6L4XMImrsA" href="uma://_zZxTYtnmEdmO6L4XMImrsA#_zZxTYtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="2.0088322577945588E-305" name="keyword_index" guid="2.0088322577945588E-305" briefDescription="The keyword index provides the ability to look-up topics based on keywords or topics." presentationName="Keyword Index" nodeicon="base_concepts/guidances/supportingmaterials/resources/bookc.gif">
+ <presentation xmi:id="_zZxTYNnmEdmO6L4XMImrsA" href="uma://_zZxTYNnmEdmO6L4XMImrsA#_zZxTYNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_x459ktnmEdmO6L4XMImrsA" name="task" guid="_x459ktnmEdmO6L4XMImrsA" presentationName="task">
+ <presentation xmi:id="_x459k9nmEdmO6L4XMImrsA" href="uma://_x459k9nmEdmO6L4XMImrsA#_x459k9nmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_x7cUM9nmEdmO6L4XMImrsA" name="artifact" guid="_x7cUM9nmEdmO6L4XMImrsA" presentationName="artifact">
+ <presentation xmi:id="_x7cUNNnmEdmO6L4XMImrsA" href="uma://_x7cUNNnmEdmO6L4XMImrsA#_x7cUNNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yFbWoNnmEdmO6L4XMImrsA" name="deliverable" guid="_yFbWoNnmEdmO6L4XMImrsA" presentationName="deliverable">
+ <presentation xmi:id="_yFbWodnmEdmO6L4XMImrsA" href="uma://_yFbWodnmEdmO6L4XMImrsA#_yFbWodnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yGUuidnmEdmO6L4XMImrsA" name="discipline" guid="_yGUuidnmEdmO6L4XMImrsA" presentationName="discipline">
+ <presentation xmi:id="_yGUuitnmEdmO6L4XMImrsA" href="uma://_yGUuitnmEdmO6L4XMImrsA#_yGUuitnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yHEVYdnmEdmO6L4XMImrsA" name="domain" guid="_yHEVYdnmEdmO6L4XMImrsA" presentationName="domain">
+ <presentation xmi:id="_yHEVYtnmEdmO6L4XMImrsA" href="uma://_yHEVYtnmEdmO6L4XMImrsA#_yHEVYtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yK8IyNnmEdmO6L4XMImrsA" name="input" guid="_yK8IyNnmEdmO6L4XMImrsA" presentationName="input">
+ <presentation xmi:id="_yK8IydnmEdmO6L4XMImrsA" href="uma://_yK8IydnmEdmO6L4XMImrsA#_yK8IydnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yPaZGdnmEdmO6L4XMImrsA" name="output" guid="_yPaZGdnmEdmO6L4XMImrsA" presentationName="output">
+ <presentation xmi:id="_yPaZGtnmEdmO6L4XMImrsA" href="uma://_yPaZGtnmEdmO6L4XMImrsA#_yPaZGtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ycE8HNnmEdmO6L4XMImrsA" name="activity_detail_diagram" guid="_ycE8HNnmEdmO6L4XMImrsA" presentationName="activity detail diagram">
+ <presentation xmi:id="_ycE8HdnmEdmO6L4XMImrsA" href="uma://_ycE8HdnmEdmO6L4XMImrsA#_ycE8HdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yUefQNnmEdmO6L4XMImrsA" name="role" guid="_yUefQNnmEdmO6L4XMImrsA" presentationName="role">
+ <presentation xmi:id="_yUefQdnmEdmO6L4XMImrsA" href="uma://_yUefQdnmEdmO6L4XMImrsA#_yUefQdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yYy-mdnmEdmO6L4XMImrsA" name="tool_mentor" guid="_yYy-mdnmEdmO6L4XMImrsA" presentationName="tool mentor">
+ <presentation xmi:id="_yYy-mtnmEdmO6L4XMImrsA" href="uma://_yYy-mtnmEdmO6L4XMImrsA#_yYy-mtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yQ5m2NnmEdmO6L4XMImrsA" name="process" guid="_yQ5m2NnmEdmO6L4XMImrsA" presentationName="process">
+ <presentation xmi:id="_yQ5m2dnmEdmO6L4XMImrsA" href="uma://_yQ5m2dnmEdmO6L4XMImrsA#_yQ5m2dnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yNefY9nmEdmO6L4XMImrsA" name="model" guid="_yNefY9nmEdmO6L4XMImrsA" presentationName="model">
+ <presentation xmi:id="_yNefZNnmEdmO6L4XMImrsA" href="uma://_yNefZNnmEdmO6L4XMImrsA#_yNefZNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ybefKdnmEdmO6L4XMImrsA" name="view_element" guid="_ybefKdnmEdmO6L4XMImrsA" presentationName="view element">
+ <presentation xmi:id="_ybefKtnmEdmO6L4XMImrsA" href="uma://_ybefKtnmEdmO6L4XMImrsA#_ybefKtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yNnpVdnmEdmO6L4XMImrsA" name="model_element" guid="_yNnpVdnmEdmO6L4XMImrsA" presentationName="model element">
+ <presentation xmi:id="_yNnpVtnmEdmO6L4XMImrsA" href="uma://_yNnpVtnmEdmO6L4XMImrsA#_yNnpVtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yG6kY9nmEdmO6L4XMImrsA" name="document" guid="_yG6kY9nmEdmO6L4XMImrsA" presentationName="document">
+ <presentation xmi:id="_yG6kZNnmEdmO6L4XMImrsA" href="uma://_yG6kZNnmEdmO6L4XMImrsA#_yG6kZNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yWHeDNnmEdmO6L4XMImrsA" name="stakeholder" guid="_yWHeDNnmEdmO6L4XMImrsA" presentationName="stakeholder">
+ <presentation xmi:id="_yWHeDdnmEdmO6L4XMImrsA" href="uma://_yWHeDdnmEdmO6L4XMImrsA#_yWHeDdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yE05s9nmEdmO6L4XMImrsA" name="customer" guid="_yE05s9nmEdmO6L4XMImrsA" presentationName="customer">
+ <presentation xmi:id="_yE05tNnmEdmO6L4XMImrsA" href="uma://_yE05tNnmEdmO6L4XMImrsA#_yE05tNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yWaY9tnmEdmO6L4XMImrsA" name="static_work_product" guid="_yWaY9tnmEdmO6L4XMImrsA" presentationName="static work product">
+ <presentation xmi:id="_yWaY99nmEdmO6L4XMImrsA" href="uma://_yWaY99nmEdmO6L4XMImrsA#_yWaY99nmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_yoVhMB_IEdq6CKKKq4D7YA" name="activity" guid="_yoVhMB_IEdq6CKKKq4D7YA" presentationName="activity">
+ <presentation xmi:id="-67u6-WRUmTOB9IdLgQg6aw" href="uma://-67u6-WRUmTOB9IdLgQg6aw#-67u6-WRUmTOB9IdLgQg6aw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_7rS6AB_JEdq6CKKKq4D7YA" name="descriptor" guid="_7rS6AB_JEdq6CKKKq4D7YA" presentationName="descriptor">
+ <presentation xmi:id="-TI6lqoTE1op3-SnmGa2S9Q" href="uma://-TI6lqoTE1op3-SnmGa2S9Q#-TI6lqoTE1op3-SnmGa2S9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_N8x34B_LEdq6CKKKq4D7YA" name="content_element" guid="_N8x34B_LEdq6CKKKq4D7YA" presentationName="content element">
+ <presentation xmi:id="-We7G-7OM2QspR_i1ErwtLA" href="uma://-We7G-7OM2QspR_i1ErwtLA#-We7G-7OM2QspR_i1ErwtLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_cvdpEB_LEdq6CKKKq4D7YA" name="breakdown_element" guid="_cvdpEB_LEdq6CKKKq4D7YA" presentationName="breakdown element">
+ <presentation xmi:id="-7pbyO29v0VnsosWHabeZDQ" href="uma://-7pbyO29v0VnsosWHabeZDQ#-7pbyO29v0VnsosWHabeZDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Ts2joB_MEdq6CKKKq4D7YA" name="method_content" guid="_Ts2joB_MEdq6CKKKq4D7YA" presentationName="method content">
+ <presentation xmi:id="-akU0PqDaad4Ns5MQhVBJ7Q" href="uma://-akU0PqDaad4Ns5MQhVBJ7Q#-akU0PqDaad4Ns5MQhVBJ7Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_83ttAB_NEdq6CKKKq4D7YA" name="guidance" guid="_83ttAB_NEdq6CKKKq4D7YA" presentationName="guidance">
+ <presentation xmi:id="-CTatxBir28UK-VwWwDij-g" href="uma://-CTatxBir28UK-VwWwDij-g#-CTatxBir28UK-VwWwDij-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_cj6jkB_PEdq6CKKKq4D7YA" name="uma" guid="_cj6jkB_PEdq6CKKKq4D7YA" presentationName="UMA">
+ <presentation xmi:id="-QBSZ9hFRr8q6kvRyq1cESQ" href="uma://-QBSZ9hFRr8q6kvRyq1cESQ#-QBSZ9hFRr8q6kvRyq1cESQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_95LCoB_QEdq6CKKKq4D7YA" name="breakdown_structure" guid="_95LCoB_QEdq6CKKKq4D7YA" presentationName="breakdown structure">
+ <presentation xmi:id="-dpUlq7kJXlJBUjvh7lHW7Q" href="uma://-dpUlq7kJXlJBUjvh7lHW7Q#-dpUlq7kJXlJBUjvh7lHW7Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_H4JXwB_SEdq6CKKKq4D7YA" name="work_product" guid="_H4JXwB_SEdq6CKKKq4D7YA" presentationName="work product">
+ <presentation xmi:id="-dcYwPivhczonAxeyXweyIQ" href="uma://-dcYwPivhczonAxeyXweyIQ#-dcYwPivhczonAxeyXweyIQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_BqZloB_eEdqAHrsQ7-jSbw" name="step" guid="_BqZloB_eEdqAHrsQ7-jSbw" presentationName="step">
+ <presentation xmi:id="-KfXoeGTRnQImE1byTBtryQ" href="uma://-KfXoeGTRnQImE1byTBtryQ#-KfXoeGTRnQImE1byTBtryQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_LNAAcB_iEdqAHrsQ7-jSbw" name="outcome" guid="_LNAAcB_iEdqAHrsQ7-jSbw" presentationName="outcome">
+ <presentation xmi:id="-SQyJsrOEI73uLZzjRVmSBA" href="uma://-SQyJsrOEI73uLZzjRVmSBA#-SQyJsrOEI73uLZzjRVmSBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZufeMCO3EdqaNq6Ptg8uyA" name="delivery_process" guid="_ZufeMCO3EdqaNq6Ptg8uyA" presentationName="delivery process">
+ <presentation xmi:id="-IsV3QdyMdwFlqznd4UAYhw" href="uma://-IsV3QdyMdwFlqznd4UAYhw#-IsV3QdyMdwFlqznd4UAYhw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_2RUJACO4EdqaNq6Ptg8uyA" name="capability_pattern" guid="_2RUJACO4EdqaNq6Ptg8uyA" presentationName="capability pattern">
+ <presentation xmi:id="-AY7-wWpxUmZp4c-odX8e7g" href="uma://-AY7-wWpxUmZp4c-odX8e7g#-AY7-wWpxUmZp4c-odX8e7g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="__7xOEC7aEdqHMdmRzC0-2g" name="phase" guid="__7xOEC7aEdqHMdmRzC0-2g" briefDescription="This guidance introduces the concept of a phase and its purpose within a project." presentationName="Phase">
+ <presentation xmi:id="-bhzuf6RMHP3d-AHkoKDg7g" href="uma://-bhzuf6RMHP3d-AHkoKDg7g#-bhzuf6RMHP3d-AHkoKDg7g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_L5BIkC7uEdqHMdmRzC0-2g" name="release" guid="_L5BIkC7uEdqHMdmRzC0-2g" briefDescription="A Release is the delivery of a functional system meeting predefined objectives." presentationName="Release">
+ <presentation xmi:id="-dsgUC_uXte9wj6nt8DLHtw" href="uma://-dsgUC_uXte9wj6nt8DLHtw#-dsgUC_uXte9wj6nt8DLHtw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_uvje4D_fEdqDFvujd6NHiA" name="about_base_concepts" guid="_uvje4D_fEdqDFvujd6NHiA" presentationName="About Base Concepts" nodeicon="base_concepts/guidances/supportingmaterials/resources/about.gif">
+ <presentation xmi:id="-V2B7_NtU_O7-45ldkX0Rrw" href="uma://-V2B7_NtU_O7-45ldkX0Rrw#-V2B7_NtU_O7-45ldkX0Rrw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_qxY8MEALEdqTMtYjAib0og" name="whats_new_base_concepts" guid="_qxY8MEALEdqTMtYjAib0og" presentationName="What's New in Base Concepts" nodeicon="base_concepts/guidances/supportingmaterials/resources/whats_new.gif">
+ <presentation xmi:id="-eyFTMGu83WSs-yJedYCY3g" href="uma://-eyFTMGu83WSs-yJedYCY3g#-eyFTMGu83WSs-yJedYCY3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_7vpJsMaCEduMlb2cQZNTYw" name="checklist" guid="_7vpJsMaCEduMlb2cQZNTYw" presentationName="checklist">
+ <presentation xmi:id="-d9uOWrjeHbE_1Xu2RIs-0A" href="uma://-d9uOWrjeHbE_1Xu2RIs-0A#-d9uOWrjeHbE_1Xu2RIs-0A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_PzL7EMaEEduMlb2cQZNTYw" name="composite_role" guid="_PzL7EMaEEduMlb2cQZNTYw" presentationName="composite role">
+ <presentation xmi:id="-KNw2PnSSEEogCvg4sj1ebg" href="uma://-KNw2PnSSEEogCvg4sj1ebg#-KNw2PnSSEEogCvg4sj1ebg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_wMchYMaEEduMlb2cQZNTYw" name="concept" guid="_wMchYMaEEduMlb2cQZNTYw" presentationName="concept">
+ <presentation xmi:id="-5bvXXNVzF7mZf0R7Oez5_g" href="uma://-5bvXXNVzF7mZf0R7Oez5_g#-5bvXXNVzF7mZf0R7Oez5_g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="__V7pAMaEEduMlb2cQZNTYw" name="method_configuration" guid="__V7pAMaEEduMlb2cQZNTYw" presentationName="method configuration">
+ <presentation xmi:id="-kzN6-iqn9zDtfnJc7IWkIg" href="uma://-kzN6-iqn9zDtfnJc7IWkIg#-kzN6-iqn9zDtfnJc7IWkIg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_SAWgwMaFEduMlb2cQZNTYw" name="content_package" guid="_SAWgwMaFEduMlb2cQZNTYw" presentationName="content package">
+ <presentation xmi:id="-t4Xac9J5DWCA6r1b9L40Mw" href="uma://-t4Xac9J5DWCA6r1b9L40Mw#-t4Xac9J5DWCA6r1b9L40Mw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_eqw94MaFEduMlb2cQZNTYw" name="custom_category" guid="_eqw94MaFEduMlb2cQZNTYw" presentationName="custom category">
+ <presentation xmi:id="-G9dXZH2IkpWGi4NZK-2vEw" href="uma://-G9dXZH2IkpWGi4NZK-2vEw#-G9dXZH2IkpWGi4NZK-2vEw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_nE6fsMaFEduMlb2cQZNTYw" name="example" guid="_nE6fsMaFEduMlb2cQZNTYw" presentationName="example">
+ <presentation xmi:id="-WGi50KpVG9oQbP82Xvk1UA" href="uma://-WGi50KpVG9oQbP82Xvk1UA#-WGi50KpVG9oQbP82Xvk1UA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_uK8HMMaFEduMlb2cQZNTYw" name="guideline" guid="_uK8HMMaFEduMlb2cQZNTYw" presentationName="guideline">
+ <presentation xmi:id="-EEF1Y386HZ1XRsyHmGLE3g" href="uma://-EEF1Y386HZ1XRsyHmGLE3g#-EEF1Y386HZ1XRsyHmGLE3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_1xELEMaFEduMlb2cQZNTYw" name="method_library" guid="_1xELEMaFEduMlb2cQZNTYw" presentationName="method library">
+ <presentation xmi:id="-m6mx-VR4CReQNhrf4b8ykQ" href="uma://-m6mx-VR4CReQNhrf4b8ykQ#-m6mx-VR4CReQNhrf4b8ykQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_D4TLgMaGEduMlb2cQZNTYw" name="method_plugin" guid="_D4TLgMaGEduMlb2cQZNTYw" presentationName="method plug-in">
+ <presentation xmi:id="-q0ixH8duU7qb8agEywAFHQ" href="uma://-q0ixH8duU7qb8agEywAFHQ#-q0ixH8duU7qb8agEywAFHQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_K9eecMaGEduMlb2cQZNTYw" name="phase" guid="_K9eecMaGEduMlb2cQZNTYw" presentationName="phase">
+ <presentation xmi:id="-88Vj7cM5EcVnfesDYaAkww" href="uma://-88Vj7cM5EcVnfesDYaAkww#-88Vj7cM5EcVnfesDYaAkww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_wxYvkMaGEduMlb2cQZNTYw" name="practice" guid="_wxYvkMaGEduMlb2cQZNTYw" presentationName="practice">
+ <presentation xmi:id="-kxtQBsUei9KRl8Z6tOSQ-g" href="uma://-kxtQBsUei9KRl8Z6tOSQ-g#-kxtQBsUei9KRl8Z6tOSQ-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3iqPEMaGEduMlb2cQZNTYw" name="process_contribution" guid="_3iqPEMaGEduMlb2cQZNTYw" presentationName="process contribution">
+ <presentation xmi:id="-fkIJikbdLETPdu0ALqo7fw" href="uma://-fkIJikbdLETPdu0ALqo7fw#-fkIJikbdLETPdu0ALqo7fw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_MN1doMaHEduMlb2cQZNTYw" name="process_package" guid="_MN1doMaHEduMlb2cQZNTYw" presentationName="process package">
+ <presentation xmi:id="-GBZOfgyCAdK00NMpe1N5_Q" href="uma://-GBZOfgyCAdK00NMpe1N5_Q#-GBZOfgyCAdK00NMpe1N5_Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Ua93IMaHEduMlb2cQZNTYw" name="release" guid="_Ua93IMaHEduMlb2cQZNTYw" presentationName="release">
+ <presentation xmi:id="-hFYlBf3iN29RqVmHB9C4ug" href="uma://-hFYlBf3iN29RqVmHB9C4ug#-hFYlBf3iN29RqVmHB9C4ug"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_bDCXUMaHEduMlb2cQZNTYw" name="report" guid="_bDCXUMaHEduMlb2cQZNTYw" presentationName="report">
+ <presentation xmi:id="-lEbg0SKqsikKdCRXPVvRmw" href="uma://-lEbg0SKqsikKdCRXPVvRmw#-lEbg0SKqsikKdCRXPVvRmw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_kSKZUMaHEduMlb2cQZNTYw" name="reusable_asset" guid="_kSKZUMaHEduMlb2cQZNTYw" presentationName="reusable asset">
+ <presentation xmi:id="-H9RSfWhEhOJscNkDKGPcBA" href="uma://-H9RSfWhEhOJscNkDKGPcBA#-H9RSfWhEhOJscNkDKGPcBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_19dWYMaHEduMlb2cQZNTYw" name="roadmap" guid="_19dWYMaHEduMlb2cQZNTYw" presentationName="roadmap">
+ <presentation xmi:id="-gCtPvpHU3vmCQKQ1ymqBvw" href="uma://-gCtPvpHU3vmCQKQ1ymqBvw#-gCtPvpHU3vmCQKQ1ymqBvw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Fs8HAMaIEduMlb2cQZNTYw" name="role_set" guid="_Fs8HAMaIEduMlb2cQZNTYw" presentationName="role set">
+ <presentation xmi:id="-gOXu6EqfZHMmtekNk8IDqA" href="uma://-gOXu6EqfZHMmtekNk8IDqA#-gOXu6EqfZHMmtekNk8IDqA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_SwvUgMaIEduMlb2cQZNTYw" name="supporting_material" guid="_SwvUgMaIEduMlb2cQZNTYw" presentationName="supporting material">
+ <presentation xmi:id="-_-iQ4eQyiQVM7YhXcb90-g" href="uma://-_-iQ4eQyiQVM7YhXcb90-g#-_-iQ4eQyiQVM7YhXcb90-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_rZOGIMaIEduMlb2cQZNTYw" name="team_profile" guid="_rZOGIMaIEduMlb2cQZNTYw" presentationName="team profile">
+ <presentation xmi:id="-0cxbeJahkc1eqGKztRpcPw" href="uma://-0cxbeJahkc1eqGKztRpcPw#-0cxbeJahkc1eqGKztRpcPw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_1MLN8MaIEduMlb2cQZNTYw" name="template" guid="_1MLN8MaIEduMlb2cQZNTYw" presentationName="template">
+ <presentation xmi:id="--SOXfR7BTPs3CqtNP8R6Rw" href="uma://--SOXfR7BTPs3CqtNP8R6Rw#--SOXfR7BTPs3CqtNP8R6Rw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_6SluIMaIEduMlb2cQZNTYw" name="term_definition" guid="_6SluIMaIEduMlb2cQZNTYw" presentationName="term definition">
+ <presentation xmi:id="-4JztP2JNqE36rtSC0UoYDw" href="uma://-4JztP2JNqE36rtSC0UoYDw#-4JztP2JNqE36rtSC0UoYDw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_BangwMaJEduMlb2cQZNTYw" name="tool" guid="_BangwMaJEduMlb2cQZNTYw" presentationName="tool">
+ <presentation xmi:id="-XnXEM7GkN21zwj7pKPmu3A" href="uma://-XnXEM7GkN21zwj7pKPmu3A#-XnXEM7GkN21zwj7pKPmu3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_GH6WUMaJEduMlb2cQZNTYw" name="view" guid="_GH6WUMaJEduMlb2cQZNTYw" presentationName="view">
+ <presentation xmi:id="-dLRBfqnBlgy_0_H13LmV3A" href="uma://-dLRBfqnBlgy_0_H13LmV3A#-dLRBfqnBlgy_0_H13LmV3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Kc1IIMaJEduMlb2cQZNTYw" name="white_paper" guid="_Kc1IIMaJEduMlb2cQZNTYw" presentationName="white paper">
+ <presentation xmi:id="-QLPRVsXtlVpWZiWmQPSsnw" href="uma://-QLPRVsXtlVpWZiWmQPSsnw#-QLPRVsXtlVpWZiWmQPSsnw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_QWhfYMaJEduMlb2cQZNTYw" name="work_product_kind" guid="_QWhfYMaJEduMlb2cQZNTYw" presentationName="work product kind">
+ <presentation xmi:id="-on4oCT1DzfksdshYPKAqGg" href="uma://-on4oCT1DzfksdshYPKAqGg#-on4oCT1DzfksdshYPKAqGg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_AejKAMadEduMlb2cQZNTYw" name="to_a_method_authoring_plugin" guid="_AejKAMadEduMlb2cQZNTYw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2vVuUBT9EdqrUt4zetC1gg" name="checklist" guid="_2vVuUBT9EdqrUt4zetC1gg" briefDescription="A Checklist identifies a series of items that need to be completed or verified. Checklists are often used in reviews such as walkthroughs or inspections." presentationName="Checklist">
+ <presentation xmi:id="_2wY3MBT9EdqrUt4zetC1gg" href="uma://_2wY3MBT9EdqrUt4zetC1gg#_2wY3MBT9EdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_8wobABUAEdqrUt4zetC1gg" name="concept2" guid="_8wobABUAEdqrUt4zetC1gg" briefDescription="A Concept outlines key ideas or basic principles underlying a topic central to the method. Concepts normally address more general topics than Guidelines and span across several Work Products, Tasks, or activities." presentationName="Concept">
+ <presentation xmi:id="_8w0oQBUAEdqrUt4zetC1gg" href="uma://_8w0oQBUAEdqrUt4zetC1gg#_8w0oQBUAEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_dCG-UBUBEdqrUt4zetC1gg" name="example" guid="_dCG-UBUBEdqrUt4zetC1gg" briefDescription="This Guidance Type represents a typical, partially completed, sample instance of one or more Content Elements. Examples are most commonly provided for Work Products." presentationName="Example">
+ <presentation xmi:id="_dCTLkBUBEdqrUt4zetC1gg" href="uma://_dCTLkBUBEdqrUt4zetC1gg#_dCTLkBUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_IAwkEBUEEdqrUt4zetC1gg" name="guideline" guid="_IAwkEBUEEdqrUt4zetC1gg" briefDescription="This Guidance type provides additional detail on how to handle a particular Content Element. Guidelines most commonly apply to Tasks and Work Products." presentationName="Guideline">
+ <presentation xmi:id="_IBPFMBUEEdqrUt4zetC1gg" href="uma://_IBPFMBUEEdqrUt4zetC1gg#_IBPFMBUEEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_szl6EBUBEdqrUt4zetC1gg" name="practice" guid="_szl6EBUBEdqrUt4zetC1gg" briefDescription="This Guidance Type presents a proven way or strategy of doing work to achieve a goal that has a positive impact on Work Product or process quality." presentationName="Practice">
+ <presentation xmi:id="_s0dcwBUBEdqrUt4zetC1gg" href="uma://_s0dcwBUBEdqrUt4zetC1gg#_s0dcwBUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_x2sAgBUBEdqrUt4zetC1gg" name="report" guid="_x2sAgBUBEdqrUt4zetC1gg" briefDescription="This Guidance Type is a predefined template of a result that is generated on the basis of other Work Products as an output from some form of tool automation." presentationName="Report">
+ <presentation xmi:id="_x2-UYBUBEdqrUt4zetC1gg" href="uma://_x2-UYBUBEdqrUt4zetC1gg#_x2-UYBUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_20bs4BUBEdqrUt4zetC1gg" name="reusable_asset" guid="_20bs4BUBEdqrUt4zetC1gg" briefDescription="This Guidance Type describes an asset that can be reused in a different context." presentationName="Reusable Asset">
+ <presentation xmi:id="_21rDABUBEdqrUt4zetC1gg" href="uma://_21rDABUBEdqrUt4zetC1gg#_21rDABUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_JCQbIBnXEdqYreeU3jqaDQ" name="roadmap" guid="_JCQbIBnXEdqYreeU3jqaDQ" briefDescription="This Guidance Type summarizes a Process, often from a particular perspective." presentationName="Roadmap">
+ <presentation xmi:id="_JCivABnXEdqYreeU3jqaDQ" href="uma://_JCivABnXEdqYreeU3jqaDQ#_JCivABnXEdqYreeU3jqaDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_80XPABUBEdqrUt4zetC1gg" name="supporting_material" guid="_80XPABUBEdqrUt4zetC1gg" briefDescription="This Guidance Type is a catch-all for other types of Guidance not specifically defined elsewhere." presentationName="Supporting Material">
+ <presentation xmi:id="_80pi4BUBEdqrUt4zetC1gg" href="uma://_80pi4BUBEdqrUt4zetC1gg#_80pi4BUBEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_G_UnIBUCEdqrUt4zetC1gg" name="template" guid="_G_UnIBUCEdqrUt4zetC1gg" briefDescription="This Guidance Type specifies the structure of a Work Product by providing a pre-defined table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions how the sections and packages are supposed to be used and completed." presentationName="Template">
+ <presentation xmi:id="_G_m7ABUCEdqrUt4zetC1gg" href="uma://_G_m7ABUCEdqrUt4zetC1gg#_G_m7ABUCEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Z45fwBUDEdqrUt4zetC1gg" name="term_definition" guid="_Z45fwBUDEdqrUt4zetC1gg" briefDescription="This Guidance Type defines concepts that are used to build up the Glossary." presentationName="Term Definition">
+ <presentation xmi:id="_Z7wmgBUDEdqrUt4zetC1gg" href="uma://_Z7wmgBUDEdqrUt4zetC1gg#_Z7wmgBUDEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.0762105093945226E-304" name="tool_mentor" guid="1.0762105093945226E-304" briefDescription="This Guidance Type shows how to use a specific tool to create part of a Work Product either in the context of or independently from a Task or Activity." presentationName="Tool Mentor">
+ <presentation xmi:id="_zaz1MtnmEdmO6L4XMImrsA" href="uma://_zaz1MtnmEdmO6L4XMImrsA#_zaz1MtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_id9REBUDEdqrUt4zetC1gg" name="white_paper" guid="_id9REBUDEdqrUt4zetC1gg" briefDescription="This Guidance Type is an externally published paper that is incorporated as an attachment." presentationName="White Paper">
+ <presentation xmi:id="_iePk8BUDEdqrUt4zetC1gg" href="uma://_iePk8BUDEdqrUt4zetC1gg#_iePk8BUDEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_fdRfkBUJEdqrUt4zetC1gg" name="artifact" guid="_fdRfkBUJEdqrUt4zetC1gg" briefDescription="Artifact is a Work Product that provides a description and definition for tangible, non-trivial work products." presentationName="Artifact">
+ <presentation xmi:id="_fdds0BUJEdqrUt4zetC1gg" href="uma://_fdds0BUJEdqrUt4zetC1gg#_fdds0BUJEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_lBgkMBUJEdqrUt4zetC1gg" name="deliverable" guid="_lBgkMBUJEdqrUt4zetC1gg" briefDescription="A Deliverable is a Work Product that provides a description and definition for packaging other Work Products, and may be delivered to an internal or external party." presentationName="Deliverable">
+ <presentation xmi:id="_lBy4EBUJEdqrUt4zetC1gg" href="uma://_lBy4EBUJEdqrUt4zetC1gg#_lBy4EBUJEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_pROF4BUJEdqrUt4zetC1gg" name="outcome" guid="_pROF4BUJEdqrUt4zetC1gg" briefDescription="An Outcome describes intangible Work Products that are a result or state." presentationName="Outcome">
+ <presentation xmi:id="_pRmgYBUJEdqrUt4zetC1gg" href="uma://_pRmgYBUJEdqrUt4zetC1gg#_pRmgYBUJEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.132140065969088E-305" name="activity" guid="3.132140065969088E-305" briefDescription="An Activity supports the nesting and logical grouping of related process elements also referred to as Breakdown Elements (e.g. other Activities or Task Descriptors). The concepts Phase, Iteration, Delivery Process, and Capability Pattern are defined as special Activities." presentationName="Activity">
+ <presentation xmi:id="_zaqEMNnmEdmO6L4XMImrsA" href="uma://_zaqEMNnmEdmO6L4XMImrsA#_zaqEMNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.7072348895114264E-305" name="capability_pattern" guid="1.7072348895114264E-305" briefDescription="A Capability Pattern is a special Process that describes a reusable cluster of Activities in common process areas that produces a result of observable value." presentationName="Capability Pattern">
+ <presentation xmi:id="_zag6RdnmEdmO6L4XMImrsA" href="uma://_zag6RdnmEdmO6L4XMImrsA#_zag6RdnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_EhgqwO8MEdmKSqa_gSYthg" name="delivery_process" guid="_EhgqwO8MEdmKSqa_gSYthg" briefDescription="A Delivery Process is a special Process describing a complete and integrated approach for performing a specific type of project." presentationName="Delivery Process">
+ <presentation xmi:id="_EijzoO8MEdmKSqa_gSYthg" href="uma://_EijzoO8MEdmKSqa_gSYthg#_EijzoO8MEdmKSqa_gSYthg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_5V9HEBUEEdqrUt4zetC1gg" name="descriptor" guid="_5V9HEBUEEdqrUt4zetC1gg" briefDescription="A Descriptor is a Process Element that represents the use or application of a Method Content element in the Process. The Descriptor provides the ability to override or add to what is defined in the original Method Content Element. Descriptors include Role, Task, and Work Product Descriptors." presentationName="Descriptor">
+ <presentation xmi:id="_5WJUUBUEEdqrUt4zetC1gg" href="uma://_5WJUUBUEEdqrUt4zetC1gg#_5WJUUBUEEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_49a10BUFEdqrUt4zetC1gg" name="content_package" guid="_49a10BUFEdqrUt4zetC1gg" briefDescription="A Content Package is a special Method Package that contains Content Elements exclusively. Examples for Content Element are Artifacts, Tasks, Roles, and so on." presentationName="Content Package">
+ <presentation xmi:id="_49tJsBUFEdqrUt4zetC1gg" href="uma://_49tJsBUFEdqrUt4zetC1gg#_49tJsBUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_MT6U8BneEdqYreeU3jqaDQ" name="process_package" guid="_MT6U8BneEdqYreeU3jqaDQ" briefDescription="A Process Package is a special Method Package that contains Processes such as Capability Patterns or Delivery Processes only." presentationName="Process Package">
+ <presentation xmi:id="_MUGiMBneEdqYreeU3jqaDQ" href="uma://_MUGiMBneEdqYreeU3jqaDQ#_MUGiMBneEdqYreeU3jqaDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_d698IBUFEdqrUt4zetC1gg" name="configuration" guid="_d698IBUFEdqrUt4zetC1gg" briefDescription="A Method Configuration specifies the selection of a logical subset of a Method Library." presentationName="Method Configuration">
+ <presentation xmi:id="_d7QQABUFEdqrUt4zetC1gg" href="uma://_d7QQABUFEdqrUt4zetC1gg#_d7QQABUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_m8lGkBUFEdqrUt4zetC1gg" name="method_library" guid="_m8lGkBUFEdqrUt4zetC1gg" briefDescription="A Method Library is a physical container for Method Plug-ins and Method Configuration definitions. All Method Elements are stored in a Method Library." presentationName="Method Library">
+ <presentation xmi:id="_m83acBUFEdqrUt4zetC1gg" href="uma://_m83acBUFEdqrUt4zetC1gg#_m83acBUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0KeEMBUFEdqrUt4zetC1gg" name="method_plugin" guid="_0KeEMBUFEdqrUt4zetC1gg" briefDescription="A Method Plugin represents a physical container for Method Packages. It defines a largest granularity level for the modularization and organization of method content and processes." presentationName="Method Plugin">
+ <presentation xmi:id="_0LCr8BUFEdqrUt4zetC1gg" href="uma://_0LCr8BUFEdqrUt4zetC1gg#_0LCr8BUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_94_eoO8LEdmKSqa_gSYthg" name="introduction_to_uma" guid="_94_eoO8LEdmKSqa_gSYthg" briefDescription="The Unified Method Architecture (UMA) is a process engineering meta-model that defines schema and terminology for representing methods consisting of method content and processes." presentationName="Key Capabilities of the Unified Method Architecture (UMA)">
+ <presentation xmi:id="_972lYO8LEdmKSqa_gSYthg" href="uma://_972lYO8LEdmKSqa_gSYthg#_972lYO8LEdmKSqa_gSYthg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.1609745730665898E-304" name="role" guid="1.1609745730665898E-304" briefDescription="A Role defines a set of related skills, competencies, and responsibilities." presentationName="Role">
+ <presentation xmi:id="_zaqEMtnmEdmO6L4XMImrsA" href="uma://_zaqEMtnmEdmO6L4XMImrsA#_zaqEMtnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="7.624729048911575E-305" name="task" guid="7.624729048911575E-305" briefDescription="A Task describes a unit of work assigned to a Role that provides a meaningful result." presentationName="Task">
+ <presentation xmi:id="_zaqENNnmEdmO6L4XMImrsA" href="uma://_zaqENNnmEdmO6L4XMImrsA#_zaqENNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_xuO10BUGEdqrUt4zetC1gg" name="custom_category" guid="_xuO10BUGEdqrUt4zetC1gg" briefDescription="Custom categories are used to categorize content based on the user's criteria. One important use is for constructing Views." presentationName="Custom Category">
+ <presentation xmi:id="_xuhJsBUGEdqrUt4zetC1gg" href="uma://_xuhJsBUGEdqrUt4zetC1gg#_xuhJsBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.409251897849429E-305" name="discipline" guid="3.409251897849429E-305" briefDescription="A Discipline is a categorization of Tasks based upon similarity of concerns and cooperation of work effort." presentationName="Discipline">
+ <presentation xmi:id="_zag6Q9nmEdmO6L4XMImrsA" href="uma://_zag6Q9nmEdmO6L4XMImrsA#_zag6Q9nmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Dh4TEBUGEdqrUt4zetC1gg" name="domain" guid="_Dh4TEBUGEdqrUt4zetC1gg" briefDescription="Domain is a Standard Category that is a logical grouping of work products which have an affinity to each other based on resources, timing, or relationship." presentationName="Domain">
+ <presentation xmi:id="_DiKm8BUGEdqrUt4zetC1gg" href="uma://_DiKm8BUGEdqrUt4zetC1gg#_DiKm8BUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_u3t7sBUGEdqrUt4zetC1gg" name="role_set" guid="_u3t7sBUGEdqrUt4zetC1gg" briefDescription="This Standard Category organizes Roles into categories." presentationName="Role Set">
+ <presentation xmi:id="_u4APkBUGEdqrUt4zetC1gg" href="uma://_u4APkBUGEdqrUt4zetC1gg#_u4APkBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_66Jy0BUGEdqrUt4zetC1gg" name="tool" guid="_66Jy0BUGEdqrUt4zetC1gg" briefDescription="This Standard Category is a container for Tool Mentors. It can also provide general descriptions of the tool and its general capabilities." presentationName="Tool">
+ <presentation xmi:id="_66cGsBUGEdqrUt4zetC1gg" href="uma://_66cGsBUGEdqrUt4zetC1gg#_66cGsBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_uMKSsBUFEdqrUt4zetC1gg" name="view" guid="_uMKSsBUFEdqrUt4zetC1gg" briefDescription="Views are structured content collections designed to drive publication and facilitate browsing. They are specified using Custom Categories." presentationName="View">
+ <presentation xmi:id="_uMcmkBUFEdqrUt4zetC1gg" href="uma://_uMcmkBUFEdqrUt4zetC1gg#_uMcmkBUFEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VRhkoBUGEdqrUt4zetC1gg" name="work_product_kind" guid="_VRhkoBUGEdqrUt4zetC1gg" briefDescription="This Standard Category represents a grouping of related Work Products which, in contrast to Domain, is more presentation oriented." presentationName="Work Product Kind">
+ <presentation xmi:id="_VRz4gBUGEdqrUt4zetC1gg" href="uma://_VRz4gBUGEdqrUt4zetC1gg#_VRz4gBUGEdqrUt4zetC1gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="4.804531471620803E-306" name="work_product" guid="4.804531471620803E-306" briefDescription="A Work Product is something meaningful resulting from a process: Roles use Work Products to perform Tasks and produce Work Products in the course of performing Tasks." presentationName="Work Product">
+ <presentation xmi:id="_zaz1MNnmEdmO6L4XMImrsA" href="uma://_zaz1MNnmEdmO6L4XMImrsA#_zaz1MNnmEdmO6L4XMImrsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_NYASQBtqEdqSLrJ4Ij2LVA" name="process_contribution" guid="_NYASQBtqEdqSLrJ4Ij2LVA" briefDescription="A Process Contribution is a special Process that externally defines additions and changes to an existing Process without directly modifying it." presentationName="Process Contribution">
+ <presentation xmi:id="-x11qt8TVnuIKeMC69UP1TQ" href="uma://-x11qt8TVnuIKeMC69UP1TQ#-x11qt8TVnuIKeMC69UP1TQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_P9gp0BtHEdqSLrJ4Ij2LVA" name="composite_role" guid="_P9gp0BtHEdqSLrJ4Ij2LVA" briefDescription="A Composite Role is a special Role Descriptor that relates to more than one Role. It represents a grouping of Roles with the main purpose of reducing the number of Roles defined in Method Content for a Process." presentationName="Composite Role">
+ <presentation xmi:id="-FD4UbInbyzlaGxB9oPHdcg" href="uma://-FD4UbInbyzlaGxB9oPHdcg#-FD4UbInbyzlaGxB9oPHdcg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_dRKRMBtHEdqSLrJ4Ij2LVA" name="team_profile" guid="_dRKRMBtHEdqSLrJ4Ij2LVA" briefDescription="A Team Profile is a Breakdown Element that groups Role Descriptors or Composite Roles, thus defining a nested hierarchy of teams and team members." presentationName="Team Profile">
+ <presentation xmi:id="-J7jcN9p3FRyhuwV5Hq42Kw" href="uma://-J7jcN9p3FRyhuwV5Hq42Kw#-J7jcN9p3FRyhuwV5Hq42Kw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_WCguS-8KEdmKSqa_gSYthg" name="CapabilityPatterns" guid="_WCguS-8KEdmKSqa_gSYthg"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_WCguTO8KEdmKSqa_gSYthg" name="DeliveryProcesses" guid="_WCguTO8KEdmKSqa_gSYthg"/>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_WCguTe8KEdmKSqa_gSYthg" name="ProcessContributions" guid="_WCguTe8KEdmKSqa_gSYthg"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/configurations/OpenUPBasic.xmi b/OpenUP/OpenUP_baseline_EN/library/configurations/OpenUPBasic.xmi
new file mode 100644
index 0000000..e37d9a5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/configurations/OpenUPBasic.xmi
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:MethodConfiguration xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_0u-T4clgEdmt3adZL5Dmdw" name="OpenUPBasic" guid="_0u-T4clgEdmt3adZL5Dmdw" briefDescription="This configuration includes plug-ins a packages needed for the OpenUP/Basic process." version="1.0.0">
+ <methodPluginSelection href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TLvwMlgEdmt3adZL5Dmdw"/>
+ <methodPluginSelection href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCUhAO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0UCrYMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2YMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T2eIMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2YclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2Y8lgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TR2YslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T2eIslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0nJNkMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0uHYQMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T2eIclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0u-T4MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T8kwclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T8kwMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0T8kwslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0UCrYclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_OGGKkMpyEdqC_NfSivunjA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_L79ggDR5EdutE_HNDTJk5Q"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_3E1NwDPBEduyTOpiJx8z_g"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0b4YwMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0UCrYslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_FtSMYAFjEduDPKiaP0pu-Q"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_IIPZQDRjEduU7vV49F9N0A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_5la48DR2EdutE_HNDTJk5Q"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0aQBEMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_kB42IDRiEduU7vV49F9N0A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8clgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YcDMMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_PGDx8PisEdmjyaJMRcPDWA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0cQzQMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_bxcS4B_REdq3EKSIdbj-MA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-etQOtQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-k0a-tQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_eE5nEEbpEduLBN1xMBngqw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_MWFjoE9HEdudU75l2xOQTw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-q7QOtQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y_PjEOtQEdqc1LGhiSPqRg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0ruyoMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rcewMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_Wq_VQPinEdmugcVr9AdHjQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rilYMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_S_IQ4CliEdqjQsaFX0CJTw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdEclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdEslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_jK8QsP77Edm1zMZYtD3GjA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0okw8MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oreoMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0q33AMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0CtdMPinEdmugcVr9AdHjQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qxwYMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_mpl9kDbmEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_TFSlkDboEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygMlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_JEyxADboEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNAslgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_XzhPQDboEduMn613sF6-Uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7iclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAPimEdmugcVr9AdHjQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79MlgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uHYQclgEdmt3adZL5Dmdw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_xujGABOKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0SpacBOKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_3CqrABOKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_467NIROKEduCNqgZdt_OaA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguSu8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCanoO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQ-8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQu8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguQe8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguRe8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguS-8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguTO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguRO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguTe8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguR-8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguRu8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCguSO8KEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_eNnSAO8LEdmKSqa_gSYthg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_douywISSEdu8NaFPL8nS_w"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_AejKAMadEduMlb2cQZNTYw"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_RdM7MMXnEduywMSzPTUUwA"/>
+</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/OpenUP/OpenUP_baseline_EN/library/library.xmi b/OpenUP/OpenUP_baseline_EN/library/library.xmi
new file mode 100644
index 0000000..c7d2e0c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/library.xmi
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_mtb_FPL5Edm6Nvont3uinw" guid="_mtb_FPL5Edm6Nvont3uinw">
+ <subManagers xmi:id="_nHk9MPL5Edm6Nvont3uinw" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_nHk9MPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_ezIJEtVpEdqWcvghdb0qxA" guid="_ezIJEtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJE9VpEdqWcvghdb0qxA" guid="_ezIJE9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJFNVpEdqWcvghdb0qxA" guid="_ezIJFNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJFdVpEdqWcvghdb0qxA" guid="_ezIJFdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJFtVpEdqWcvghdb0qxA" guid="_ezIJFtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJF9VpEdqWcvghdb0qxA" guid="_ezIJF9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJGNVpEdqWcvghdb0qxA" guid="_ezIJGNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJGdVpEdqWcvghdb0qxA" guid="_ezIJGdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJGtVpEdqWcvghdb0qxA" guid="_ezIJGtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJG9VpEdqWcvghdb0qxA" guid="_ezIJG9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJHNVpEdqWcvghdb0qxA" guid="_ezIJHNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJHdVpEdqWcvghdb0qxA" guid="_ezIJHdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJHtVpEdqWcvghdb0qxA" guid="_ezIJHtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJH9VpEdqWcvghdb0qxA" guid="_ezIJH9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJINVpEdqWcvghdb0qxA" guid="_ezIJINVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJIdVpEdqWcvghdb0qxA" guid="_ezIJIdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJItVpEdqWcvghdb0qxA" guid="_ezIJItVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJI9VpEdqWcvghdb0qxA" guid="_ezIJI9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJNVpEdqWcvghdb0qxA" guid="_ezIJJNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJdVpEdqWcvghdb0qxA" guid="_ezIJJdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJtVpEdqWcvghdb0qxA" guid="_ezIJJtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJJ9VpEdqWcvghdb0qxA" guid="_ezIJJ9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJKNVpEdqWcvghdb0qxA" guid="_ezIJKNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJKdVpEdqWcvghdb0qxA" guid="_ezIJKdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJKtVpEdqWcvghdb0qxA" guid="_ezIJKtVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJK9VpEdqWcvghdb0qxA" guid="_ezIJK9VpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJLNVpEdqWcvghdb0qxA" guid="_ezIJLNVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_ezIJLdVpEdqWcvghdb0qxA" guid="_ezIJLdVpEdqWcvghdb0qxA"/>
+ <subManagers xmi:id="_nIcf4fL5Edm6Nvont3uinw" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_nIcf4fL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nIcf4fL5Edm6Nvont3uinw" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_nIcf4fL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nIcf4fL5Edm6Nvont3uinw" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_nIcf4fL5Edm6Nvont3uinw"/>
+ <resourceDescriptors xmi:id="_mtiFgPL5Edm6Nvont3uinw" id="_y62TUKVPEdmMZJIzZ1W7Pw" uri=""/>
+ <resourceDescriptors xmi:id="_muNa8PL5Edm6Nvont3uinw" id="_0TLvwMlgEdmt3adZL5Dmdw" uri="openup_basic/plugin.xmi"/>
+ <resourceDescriptors xmi:id="_muThkPL5Edm6Nvont3uinw" id="_WCUhAO8KEdmKSqa_gSYthg" uri="base_concepts/plugin.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodLibrary xmi:id="_y62TUKVPEdmMZJIzZ1W7Pw" name="library.xmi" guid="_y62TUKVPEdmMZJIzZ1W7Pw">
+ <methodPlugins xmi:id="_0TLvwMlgEdmt3adZL5Dmdw" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0TLvwMlgEdmt3adZL5Dmdw"/>
+ <methodPlugins xmi:id="_WCUhAO8KEdmKSqa_gSYthg" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCUhAO8KEdmKSqa_gSYthg"/>
+ </org.eclipse.epf.uma:MethodLibrary>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi
new file mode 100644
index 0000000..f2944b1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi
@@ -0,0 +1,284 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-OC3td1csl7lqV15vimYOaw" guid="-OC3td1csl7lqV15vimYOaw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-C3RmtvThtego5U5cOk8uCA" guid="-C3RmtvThtego5U5cOk8uCA"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="-239OBD2wagT2qp8fuPWcHQ" guid="-239OBD2wagT2qp8fuPWcHQ">
+ <mainDescription><h3>
+ Introduction
+</h3>
+Iterations in Construction phase have a work breakdown structure (WBS) similar to iterations in the Elaboration phase, with
+activities happening in parallel. There is a different&nbsp;emphasis on how activities&nbsp;address the phase objectives,
+though.
+<p>
+ The <a href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> is expected to be stable when this phase starts, allowing the remaining
+ requirements to be implemented on top of it. Another advantage of validating the architecture and eliminating as many
+ risks as possible during Elaboration is to provide more predictability in Construction, which allows the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project manager</a> to focus on team efficiency and cost reduction.
+</p>
+<p>
+ Functionality is continuously implemented, tested, and integrated, resulting in <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
+ that are more and more complete and stable. A beta or prerelease may be deployed to a sampling of the intended audience
+ at the end of Construction. Delivery of the actual release is the main focus of the next phase.
+</p>
+<p>
+ The activities performed in a typical iteration during&nbsp;Construction phase are described after the following
+ introductions to each activity.
+</p>
+<h4>
+ Manage iteration
+</h4>
+<p>
+ This activity is performed throughout the project lifecycle. The goal of this activity is to identify risks and issues
+ early enough to mitigate them, to establish the goals for the iteration, and to support the development team in
+ reaching these goals.
+</p>
+<p>
+ Similarly to other phases, the project manager (supported by the team) launches the iteration, allocates work, tracks
+ status, and handles issues and risks. Although the high-priority and architecturally significant risks were mitigated
+ during Elaboration, new risks may appear during Construction, such as not having the right amount of resources to
+ obtain the desired degree of parallel&nbsp;development.
+</p>
+<p>
+ The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements)
+ takes place. project manager,&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>, and the remaining team members agree on what is supposed to be
+ developed during that iteration.
+</p>
+<p>
+ At the end of the iteration, the team performs an iteration assessment. The goal is to conduct a retrospective review
+ of the iteration that is ending. As part of this assessment, the objectives for the Construction phase are expected to
+ be demonstrated by the beta-quality release of the software, thus supporting the possibility of transitioning the
+ software to its end users.
+</p>
+<h4>
+ Manage requirements
+</h4>
+<p>
+ This activity is repeated throughout the lifecycle. The goal of this activity is to understand and prioritize
+ stakeholder needs and associated requirements for the system, as well as to capture these in a form that will support
+ effective communication and collaboration between the stakeholders and the development team.
+</p>
+<p>
+ During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated
+ (through a working architecture) during Elaboration.
+</p>
+<p>
+ During the Construction phase, requirements management demands less time from the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>.
+ There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
+</p>
+<p>
+ <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test cases</a> describe which&nbsp;requirements are being tested&nbsp;in that iteration.
+</p>
+<h4>
+ Develop solution
+</h4>
+<p>
+ This activity is repeated multiple times, in parallel, for each development task planned for that iteration. The main
+ goal of this activity is an executable system that provides the incremental quality and functionality for the specified
+ requirements, within the specified context.
+</p>
+<p>
+ The architecture &nbsp;was proposed and a baseline established at the end of Elaboration. Critical requirements were
+ expected to be implemented, tested, and integrated as part of the baseline architecture. As the remaining requirements
+ are implemented during Construction, the Architect identifies commonalities among solutions being developed by the
+ various developers and leverages reuse where possible. Some degree of refactoring of the architecture may be needed to
+ accommodate putting common pieces together.
+</p>
+<p>
+ A pattern similar to the Elaboration phase happens during Construction when it comes to breaking down requirements into
+ development tasks and assigning each requirement within a context to a developer. Requirements at this stage are mostly
+ of medium-to-low level of risk, but usually they represent the largest slice from the total amount of requirements to
+ be implemented in a project. Thus, it is expected that this activity is repeated, or instantiated, multiple times (once
+ per requirement within context),&nbsp;thus allowing&nbsp;parallel development. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ.html" guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous integration</a> allows functionality to be added to the code base constantly,
+ which helps the achievement of more and more complete <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
+ of the software.
+</p>
+<h4>
+ Validate build
+</h4>
+<p>
+ This activity is repeated throughout the project lifecycle. The main goal of this activity is to validate the current
+ increment of the system against the requirements allocated to it.
+</p>
+<p>
+ Similarly to Elaboration, this activity happens in parallel with the <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/develop_solution,_h2-iAfimEdmugcVr9AdHjQ.html" guid="_h2-iAfimEdmugcVr9AdHjQ">develop solution</a> activity. The intent is to validate that a stable beta release is
+ achieved and that users can perform acceptance tests.
+</p>
+<h4>
+ Ongoing tasks
+</h4>
+<p>
+ Similarly to any other phase, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any role</a> on
+ the team can submit <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">change requests</a>. The software being developed is achieving beta quality by this
+ point; therefore, defects of high priority&nbsp;are generally&nbsp;addressed during Construction iterations&nbsp;and
+ Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next
+ release of the product.
+</p></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-y0fMHq2z6qGyUlEC8ptYCQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-y0fMHq2z6qGyUlEC8ptYCQ">
+ <mainDescription><h3> Introduction </h3>
+<p> Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform
+ a goal-based planning and management. Work is assigned to developers and work
+ progress is tracked&nbsp;based on the goals to be achieved using
+ the designed, unit-tested, and&nbsp;integrated&nbsp;source code. </p>
+<h4> Context of what is being developed </h4>
+<p> A context can be specified when a requirement is assigned to be developed,
+ thus specifying how broadly a requirement is to be developed in a iteration.
+ Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business
+ logic, or&nbsp;database access),&nbsp;on a component, and so on. </p>
+<p> Whether a context is specified or not, the developer's
+ responsibility is to create a design and implementation for that requirement,
+ then to&nbsp;write and run unit tests against the implementation to make sure
+ the&nbsp;implementation works as designed, both as a unit&nbsp;and&nbsp;integrated
+ into the code base. </p>
+<h4> Overview of workflow </h4>
+<p> To accommodate major changes or&nbsp;major functionality to be developed,
+ architecture may have to be refined. Small changes and functionality may reflect
+ changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+ </p>
+<p> In any case, there is no strict sequence for how writing code and creating
+ or running &nbsp;developer tests should happen, because they can happen in parallel.&nbsp;You
+ may choose to create and run developer tests before the actual code is created
+ or the reverse sequence.</p></mainDescription>
+ <purpose><ul>
+ <li> <strong>For developers: </strong>To create a solution for the requirement
+ assigned to them </li>
+ <li> <strong>For project managers: </strong>To have a goal-based way of assigning
+ work and tracking project status </li>
+</ul></purpose>
+ </org.eclipse.epf.uma:ActivityDescription>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-q-X9OHGNRjU5gIyWVibSGQ" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
+ unit-tested, and&nbsp;integrated&nbsp;source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
+ or&nbsp;database access),&nbsp;on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
+ works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
+ happen, because they can happen in parallel.&nbsp;You may choose to create and run developer tests before the actual
+ code is created or the reverse sequence.
+</p></mainDescription>
+ <purpose><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul></purpose>
+ <usageNotes><p>
+ This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
+ requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
+ be assigned to a developer, and it should be renamed to include the actual requirement name.&nbsp;Optionally, the word
+ <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
+</p>
+<blockquote>
+ <p align="left">
+ Develop <font face="Courier New, Courier, mono">requirement_name</font> (within <font face="Courier New, Courier, mono">context_name</font> context)
+ </p>
+</blockquote>
+<p>
+ If&nbsp;a context&nbsp;is specified, there will be one instance of this pattern for each requirement&nbsp;for each
+ context.
+</p>
+<blockquote>
+ <p>
+ <strong>Example</strong>
+ </p>
+ <ol>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">user interface</font> context)
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">business logic and DB access</font> context)
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">scenario 2</font>
+ </li>
+ <li>
+ Develop <font face="Courier New, Courier, mono">supplemental requirement 1</font>
+ </li>
+ </ol>
+</blockquote>
+<p>
+ Note that there are four instances of this pattern in the preceding example:
+</p>
+<ul>
+ <li>
+ The first two are related to the same requirement (scenario 1) but within two different contexts
+ </li>
+ <li>
+ The last two are related to different requirements, with no context specified.
+ </li>
+</ul></usageNotes>
+ </org.eclipse.epf.uma:ProcessDescription>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-q-X9OHGNRjU5gIyWVibSGQ" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
+ unit-tested, and&nbsp;integrated&nbsp;source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
+ or&nbsp;database access),&nbsp;on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
+ works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
+ happen, because they can happen in parallel.&nbsp;You may choose to create developer tests and run them before the actual
+ code is created or the reverse sequence.
+</p></mainDescription>
+ <purpose><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul></purpose>
+ </org.eclipse.epf.uma:ActivityDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/construction_phase_iteration/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/construction_phase_iteration/model.xmi
new file mode 100644
index 0000000..83f727a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/construction_phase_iteration/model.xmi
@@ -0,0 +1,591 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_z-Z5MOtQEdqc1LGhiSPqRg" guid="_z-Z5MOtQEdqc1LGhiSPqRg">
+ <resourceDescriptors xmi:id="_z-Z5MetQEdqc1LGhiSPqRg" id="-OC3td1csl7lqV15vimYOaw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_z-yTsOtQEdqc1LGhiSPqRg" id="-C3RmtvThtego5U5cOk8uCA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_z_2DoOtQEdqc1LGhiSPqRg" id="-239OBD2wagT2qp8fuPWcHQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_fwowIEbpEduLBN1xMBngqw" id="-Xfm5yDx3AVScrP1ZdLT-Sw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_u6fOsUbqEdu_9u69oWmeLA" id="-y0fMHq2z6qGyUlEC8ptYCQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_Gi_joE9HEdudU75l2xOQTw" id="-yIYJv-X_OmLGox-TBmsEOQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_Rk_4gU9HEdudU75l2xOQTw" id="-q-X9OHGNRjU5gIyWVibSGQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_y-etQOtQEdqc1LGhiSPqRg" name="construction_phase_iteration" guid="_y-etQOtQEdqc1LGhiSPqRg">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_y-k0a-tQEdqc1LGhiSPqRg" name="manage_iteration" guid="_y-k0a-tQEdqc1LGhiSPqRg">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_y-k0bOtQEdqc1LGhiSPqRg" name="manage_iteration" guid="_y-k0bOtQEdqc1LGhiSPqRg" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_y-3IrutQEdqc1LGhiSPqRg" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="-OC3td1csl7lqV15vimYOaw" href="uma://-OC3td1csl7lqV15vimYOaw#-OC3td1csl7lqV15vimYOaw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_y-q7QOtQEdqc1LGhiSPqRg" name="validate_build" guid="_y-q7QOtQEdqc1LGhiSPqRg">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_y-3IretQEdqc1LGhiSPqRg" name="validate_build" guid="_y-3IretQEdqc1LGhiSPqRg" presentationName="Validate Build" hasMultipleOccurrences="true" superActivities="_y-3IrutQEdqc1LGhiSPqRg" variabilityType="extends">
+ <presentation xmi:id="-C3RmtvThtego5U5cOk8uCA" href="uma://-OC3td1csl7lqV15vimYOaw#-C3RmtvThtego5U5cOk8uCA"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_y_PjEOtQEdqc1LGhiSPqRg" name="ongoing_tasks" guid="_y_PjEOtQEdqc1LGhiSPqRg">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_y_PjTOtQEdqc1LGhiSPqRg" name="ongoing_tasks" guid="_y_PjTOtQEdqc1LGhiSPqRg" presentationName="Ongoing Tasks" isPlanned="false" superActivities="_y-3IrutQEdqc1LGhiSPqRg" isOngoing="true" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_eE5nEEbpEduLBN1xMBngqw" name="manage_requirements" guid="_eE5nEEbpEduLBN1xMBngqw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_eE5nEUbpEduLBN1xMBngqw" name="manage_requirements" guid="_eE5nEUbpEduLBN1xMBngqw" briefDescription="Detail a set of requirements (one or more use cases, scenarios, or supporting requirements)." presentationName="Manage Requirements" superActivities="_y-3IrutQEdqc1LGhiSPqRg" breakdownElements="_eFeO0EbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw _eFeO00bpEduLBN1xMBngqw _eGoFYkbpEduLBN1xMBngqw _eGoFY0bpEduLBN1xMBngqw _eGoFZEbpEduLBN1xMBngqw _eGuMBUbpEduLBN1xMBngqw _eGuMB0bpEduLBN1xMBngqw _eG0SoEbpEduLBN1xMBngqw _eHAf4EbpEduLBN1xMBngqw _eHAf4UbpEduLBN1xMBngqw _eHAf4kbpEduLBN1xMBngqw">
+ <presentation xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" href="uma://-OC3td1csl7lqV15vimYOaw#-Xfm5yDx3AVScrP1ZdLT-Sw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_eFeO0EbpEduLBN1xMBngqw" name="analyst" guid="_eFeO0EbpEduLBN1xMBngqw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_eE5nEUbpEduLBN1xMBngqw" responsibleFor="_eG0SoEbpEduLBN1xMBngqw _eGoFZEbpEduLBN1xMBngqw _eFeO00bpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eFeO0UbpEduLBN1xMBngqw" name="use_case" guid="_eFeO0UbpEduLBN1xMBngqw" presentationName="Use Case" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eFeO0kbpEduLBN1xMBngqw" name="vision" guid="_eFeO0kbpEduLBN1xMBngqw" presentationName="Vision" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eFeO00bpEduLBN1xMBngqw" name="uc_model" guid="_eFeO00bpEduLBN1xMBngqw" presentationName="Use-Case Model" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_eGoFYkbpEduLBN1xMBngqw" name="find_and_outline_requirements" guid="_eGoFYkbpEduLBN1xMBngqw" presentationName="Find and Outline Requirements" superActivities="_eE5nEUbpEduLBN1xMBngqw" isSynchronizedWithSource="false" additionallyPerformedBy="_eGuMB0bpEduLBN1xMBngqw" mandatoryInput="_eG0SoEbpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw" output="_eGoFY0bpEduLBN1xMBngqw _eGoFZEbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw" performedPrimarilyBy="_eFeO0EbpEduLBN1xMBngqw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_P9cMUPV_EdmdHa9MmVPgqQ"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_fDbgkCY-EdqNHcQ-rAojXw"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_0WhHsN-eEdqiM_wFaqLjNg"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_Mgb9IC4DEduBP8F-6-95NQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eGoFY0bpEduLBN1xMBngqw" name="work_items_list" guid="_eGoFY0bpEduLBN1xMBngqw" presentationName="Work Items List" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eGoFZEbpEduLBN1xMBngqw" name="supporting_requirements" guid="_eGoFZEbpEduLBN1xMBngqw" presentationName="Supporting Requirements" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_eGuMBUbpEduLBN1xMBngqw" name="detail_requirements" guid="_eGuMBUbpEduLBN1xMBngqw" presentationName="Detail Requirements" superActivities="_eE5nEUbpEduLBN1xMBngqw" isSynchronizedWithSource="false" additionallyPerformedBy="_eGuMB0bpEduLBN1xMBngqw" mandatoryInput="_eGoFZEbpEduLBN1xMBngqw _eFeO0kbpEduLBN1xMBngqw _eG0SoEbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw _eFeO00bpEduLBN1xMBngqw" output="_eGoFZEbpEduLBN1xMBngqw _eFeO0UbpEduLBN1xMBngqw" performedPrimarilyBy="_eFeO0EbpEduLBN1xMBngqw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0e1mIMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_vWeHMCxSEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_B47VwCxTEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_BYbboN-bEdqiM_wFaqLjNg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_eGuMB0bpEduLBN1xMBngqw" name="stakeholder" guid="_eGuMB0bpEduLBN1xMBngqw" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eG0SoEbpEduLBN1xMBngqw" name="glossary" guid="_eG0SoEbpEduLBN1xMBngqw" presentationName="Glossary" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_eHAf4EbpEduLBN1xMBngqw" name="create_test_case" guid="_eHAf4EbpEduLBN1xMBngqw" presentationName="Create Test Cases" superActivities="_eE5nEUbpEduLBN1xMBngqw" isSynchronizedWithSource="false" additionallyPerformedBy="_eFeO0EbpEduLBN1xMBngqw" mandatoryInput="_eFeO0UbpEduLBN1xMBngqw" optionalInput="_eHAf4kbpEduLBN1xMBngqw" output="_eHAf4kbpEduLBN1xMBngqw" performedPrimarilyBy="_eHAf4UbpEduLBN1xMBngqw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iwc0clgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_IJFSsKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_LpbM8KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_NK18YKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_Ok_mMKuSEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_eHAf4UbpEduLBN1xMBngqw" name="tester" guid="_eHAf4UbpEduLBN1xMBngqw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_eE5nEUbpEduLBN1xMBngqw" responsibleFor="_eHAf4kbpEduLBN1xMBngqw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_eHAf4kbpEduLBN1xMBngqw" name="test_case" guid="_eHAf4kbpEduLBN1xMBngqw" presentationName="Test Case" superActivities="_eE5nEUbpEduLBN1xMBngqw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZS-0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_MWFjoE9HEdudU75l2xOQTw" name="develop_solution" guid="_MWFjoE9HEdudU75l2xOQTw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_MWFjoU9HEdudU75l2xOQTw" name="develop_solution" guid="_MWFjoU9HEdudU75l2xOQTw" briefDescription="Design, implement, test and integrate the solution for a requirement within a given context." presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" superActivities="_y-3IrutQEdqc1LGhiSPqRg" breakdownElements="_MWFjo09HEdudU75l2xOQTw _MWFjpE9HEdudU75l2xOQTw _MWFjpU9HEdudU75l2xOQTw _MWFjpk9HEdudU75l2xOQTw _MWFjp09HEdudU75l2xOQTw _MWLqSU9HEdudU75l2xOQTw _MWLqQE9HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw _MWLqRE9HEdudU75l2xOQTw _MWLqQ09HEdudU75l2xOQTw _MWLqRU9HEdudU75l2xOQTw _MWLqRk9HEdudU75l2xOQTw _MWLqR09HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw _MWLqTU9HEdudU75l2xOQTw _-uRRkE_fEduE1dJ2XtzzkQ _-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ">
+ <ownedRules xmi:id="_MWFjok9HEdudU75l2xOQTw" name="diagram" guid="_MWFjok9HEdudU75l2xOQTw" body="ad_image_uri=|publish_ad_image=false|add_image_uri=|publish_add_image=false|wpd_image_uri=|publish_wpd_image=false"/>
+ <presentation xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" href="uma://-OC3td1csl7lqV15vimYOaw#-q-X9OHGNRjU5gIyWVibSGQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MWFjo09HEdudU75l2xOQTw" name="developer" guid="_MWFjo09HEdudU75l2xOQTw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWFjp09HEdudU75l2xOQTw _MWFjpk9HEdudU75l2xOQTw _MWFjpU9HEdudU75l2xOQTw _MWFjpE9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjpE9HEdudU75l2xOQTw" name="design" guid="_MWFjpE9HEdudU75l2xOQTw" presentationName="Design" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjpU9HEdudU75l2xOQTw" name="implementation" guid="_MWFjpU9HEdudU75l2xOQTw" presentationName="Implementation" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YoQcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjpk9HEdudU75l2xOQTw" name="developer_test" guid="_MWFjpk9HEdudU75l2xOQTw" presentationName="Developer Test" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWFjp09HEdudU75l2xOQTw" name="build" guid="_MWFjp09HEdudU75l2xOQTw" presentationName="Build" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqQE9HEdudU75l2xOQTw" name="design_solution" guid="_MWLqQE9HEdudU75l2xOQTw" presentationName="Design the Solution" superActivities="_MWFjoU9HEdudU75l2xOQTw" linkToPredecessor="_MWLqS09HEdudU75l2xOQTw" additionallyPerformedBy="_MWLqR09HEdudU75l2xOQTw _-uRRkE_fEduE1dJ2XtzzkQ _-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWLqQU9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw" optionalInput="_MWFjpE9HEdudU75l2xOQTw" output="_MWFjpE9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0fshwMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_4Z7WYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_Ci7aYFixEdusJoWkvSRO9Q"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_--6tYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_A_LU8KuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_ENwJwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_KNZYAKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_OGYbwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_9LeFME42EdudDeUNeAxPCQ"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_mUVt8BfnEduD353bkQ4frw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqQU9HEdudU75l2xOQTw" name="supporting_requirements" guid="_MWLqQU9HEdudU75l2xOQTw" presentationName="Supporting Requirements" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqQk9HEdudU75l2xOQTw" name="architecture" guid="_MWLqQk9HEdudU75l2xOQTw" presentationName="Architecture" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqQ09HEdudU75l2xOQTw" name="impl_developer_tests" guid="_MWLqQ09HEdudU75l2xOQTw" presentationName="Implement Developer Tests" superActivities="_MWFjoU9HEdudU75l2xOQTw" additionallyPerformedBy="_-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpU9HEdudU75l2xOQTw" optionalInput="_MWFjpE9HEdudU75l2xOQTw _MWLqTU9HEdudU75l2xOQTw" output="_MWFjpk9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iL1EMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_2LYo8KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g8npoC5UEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_5WtVcKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g1eDUC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_j30aAC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_ku06gC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_6wZFMKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqRE9HEdudU75l2xOQTw" name="implement_solution" guid="_MWLqRE9HEdudU75l2xOQTw" presentationName="Implement the Solution" superActivities="_MWFjoU9HEdudU75l2xOQTw" additionallyPerformedBy="_-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpE9HEdudU75l2xOQTw" optionalInput="_MWFjpU9HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw" output="_MWFjpU9HEdudU75l2xOQTw _MWFjp09HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw _MWLqSE9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hyzgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_2sxisE2iEduU655MA_3VXg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_iMMWoKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_pjehkNb7Edq_LtLvi4w2yw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_mFQ58KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_-0yzwDH4EduMqpUNhaTSRA"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_ni25UKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_q5XiIKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqRU9HEdudU75l2xOQTw" name="run_developer_tests" guid="_MWLqRU9HEdudU75l2xOQTw" presentationName="Run Developer Tests" superActivities="_MWFjoU9HEdudU75l2xOQTw" linkToPredecessor="_MWLqTk9HEdudU75l2xOQTw" additionallyPerformedBy="_-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpk9HEdudU75l2xOQTw _MWFjpU9HEdudU75l2xOQTw" output="_MWLqRk9HEdudU75l2xOQTw" performedPrimarilyBy="_MWFjo09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iYCUMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_MSnQsMP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_NkRF0MP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_SXPFkMP4EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqRk9HEdudU75l2xOQTw" name="test_log" guid="_MWLqRk9HEdudU75l2xOQTw" presentationName="Test Log" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZlSsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MWLqR09HEdudU75l2xOQTw" name="architect" guid="_MWLqR09HEdudU75l2xOQTw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWLqQk9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqSE9HEdudU75l2xOQTw" name="use_case" guid="_MWLqSE9HEdudU75l2xOQTw" presentationName="Use Case" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_MWLqSU9HEdudU75l2xOQTw" name="develop_arch" guid="_MWLqSU9HEdudU75l2xOQTw" presentationName="Develop the Architecture" superActivities="_MWFjoU9HEdudU75l2xOQTw" isSynchronizedWithSource="false" additionallyPerformedBy="_MWFjo09HEdudU75l2xOQTw _-uRRkE_fEduE1dJ2XtzzkQ _-uRRkU_fEduE1dJ2XtzzkQ _-uRRkk_fEduE1dJ2XtzzkQ" mandatoryInput="_MWFjpE9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw" output="_MWFjpE9HEdudU75l2xOQTw _MWLqQk9HEdudU75l2xOQTw" performedPrimarilyBy="_MWLqR09HEdudU75l2xOQTw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0gRJgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Vdln8MP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_G_k1kBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_LsyLkBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Zlw-QMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_aRCI0MP3EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MWLqS09HEdudU75l2xOQTw" guid="_MWLqS09HEdudU75l2xOQTw" linkType="finishToFinish" pred="_MWLqSU9HEdudU75l2xOQTw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_MWLqTU9HEdudU75l2xOQTw" name="test_script" guid="_MWLqTU9HEdudU75l2xOQTw" presentationName="Test Script" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MWLqTk9HEdudU75l2xOQTw" guid="_MWLqTk9HEdudU75l2xOQTw" linkType="finishToFinish" pred="_MWLqQ09HEdudU75l2xOQTw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_-uRRkE_fEduE1dJ2XtzzkQ" name="analyst" guid="_-uRRkE_fEduE1dJ2XtzzkQ" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWLqSE9HEdudU75l2xOQTw _MWLqQU9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_-uRRkU_fEduE1dJ2XtzzkQ" name="stakeholder" guid="_-uRRkU_fEduE1dJ2XtzzkQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_-uRRkk_fEduE1dJ2XtzzkQ" name="tester" guid="_-uRRkk_fEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_MWFjoU9HEdudU75l2xOQTw" responsibleFor="_MWLqTU9HEdudU75l2xOQTw _MWLqRk9HEdudU75l2xOQTw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <diagrams xmi:id="_MWLqT09HEdudU75l2xOQTw" guid="_MWLqT09HEdudU75l2xOQTw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqUE9HEdudU75l2xOQTw" guid="_MWLqUE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM8E9HEdudU75l2xOQTw" x="168.0" y="12.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqUU9HEdudU75l2xOQTw" guid="_MWLqUU9HEdudU75l2xOQTw" anchor="_MWLqU09HEdudU75l2xOQTw _MWLqWE9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqUk9HEdudU75l2xOQTw" guid="_MWLqUk9HEdudU75l2xOQTw" element="_MWLqS09HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_MWLqU09HEdudU75l2xOQTw" guid="_MWLqU09HEdudU75l2xOQTw" graphEdge="_MWLqUU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqVE9HEdudU75l2xOQTw" guid="_MWLqVE9HEdudU75l2xOQTw" graphEdge="_MWLqck9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqVU9HEdudU75l2xOQTw" guid="_MWLqVU9HEdudU75l2xOQTw" element="_MWLqSU9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM8U9HEdudU75l2xOQTw" width="112.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqVk9HEdudU75l2xOQTw" guid="_MWLqVk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM8k9HEdudU75l2xOQTw" x="178.0" y="99.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqV09HEdudU75l2xOQTw" guid="_MWLqV09HEdudU75l2xOQTw" anchor="_MWLqWk9HEdudU75l2xOQTw _MWLqmk9HEdudU75l2xOQTw">
+ <waypoints xmi:id="_MXDM809HEdudU75l2xOQTw" x="223.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_MWLqWE9HEdudU75l2xOQTw" guid="_MWLqWE9HEdudU75l2xOQTw" graphEdge="_MWLqUU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqWU9HEdudU75l2xOQTw" guid="_MWLqWU9HEdudU75l2xOQTw" graphEdge="_MWLqeE9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqWk9HEdudU75l2xOQTw" guid="_MWLqWk9HEdudU75l2xOQTw" graphEdge="_MWLqV09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM9E9HEdudU75l2xOQTw" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqW09HEdudU75l2xOQTw" guid="_MWLqW09HEdudU75l2xOQTw" element="_MWLqQE9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM9U9HEdudU75l2xOQTw" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqXE9HEdudU75l2xOQTw" guid="_MWLqXE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM9k9HEdudU75l2xOQTw" x="28.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqXU9HEdudU75l2xOQTw" guid="_MWLqXU9HEdudU75l2xOQTw" anchor="_MWLqX09HEdudU75l2xOQTw _MWLqkU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqXk9HEdudU75l2xOQTw" guid="_MWLqXk9HEdudU75l2xOQTw" graphEdge="_MWLqhk9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqX09HEdudU75l2xOQTw" guid="_MWLqX09HEdudU75l2xOQTw" graphEdge="_MWLqXU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM909HEdudU75l2xOQTw" x="101.0" y="286.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqYE9HEdudU75l2xOQTw" guid="_MWLqYE9HEdudU75l2xOQTw" element="_MWLqRE9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM-E9HEdudU75l2xOQTw" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqYU9HEdudU75l2xOQTw" guid="_MWLqYU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM-U9HEdudU75l2xOQTw" x="179.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqYk9HEdudU75l2xOQTw" guid="_MWLqYk9HEdudU75l2xOQTw" anchor="_MWLqZU9HEdudU75l2xOQTw _MWLqak9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqY09HEdudU75l2xOQTw" guid="_MWLqY09HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_MWLqZE9HEdudU75l2xOQTw" guid="_MWLqZE9HEdudU75l2xOQTw" graphEdge="_MWLqhU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqZU9HEdudU75l2xOQTw" guid="_MWLqZU9HEdudU75l2xOQTw" graphEdge="_MWLqYk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM-k9HEdudU75l2xOQTw" x="239.0" y="284.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqZk9HEdudU75l2xOQTw" guid="_MWLqZk9HEdudU75l2xOQTw" element="_MWLqQ09HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM-09HEdudU75l2xOQTw" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqZ09HEdudU75l2xOQTw" guid="_MWLqZ09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM_E9HEdudU75l2xOQTw" x="191.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqaE9HEdudU75l2xOQTw" guid="_MWLqaE9HEdudU75l2xOQTw" anchor="_MWLqaU9HEdudU75l2xOQTw _MWLqkk9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqaU9HEdudU75l2xOQTw" guid="_MWLqaU9HEdudU75l2xOQTw" graphEdge="_MWLqaE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM_U9HEdudU75l2xOQTw" x="374.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqak9HEdudU75l2xOQTw" guid="_MWLqak9HEdudU75l2xOQTw" graphEdge="_MWLqYk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDM_k9HEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqa09HEdudU75l2xOQTw" guid="_MWLqa09HEdudU75l2xOQTw" element="_MWLqRU9HEdudU75l2xOQTw"/>
+ <size xmi:id="_MXDM_09HEdudU75l2xOQTw" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqbE9HEdudU75l2xOQTw" guid="_MWLqbE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNAE9HEdudU75l2xOQTw" x="24.0" y="31.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqbU9HEdudU75l2xOQTw" guid="_MWLqbU9HEdudU75l2xOQTw" anchor="_MWLqbk9HEdudU75l2xOQTw _MWLqc09HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqbk9HEdudU75l2xOQTw" guid="_MWLqbk9HEdudU75l2xOQTw" graphEdge="_MWLqbU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNAU9HEdudU75l2xOQTw" x="117.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqb09HEdudU75l2xOQTw" guid="_MWLqb09HEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_MXDNAk9HEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqcE9HEdudU75l2xOQTw" guid="_MWLqcE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNA09HEdudU75l2xOQTw" x="83.0" y="30.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqcU9HEdudU75l2xOQTw" guid="_MWLqcU9HEdudU75l2xOQTw" anchor="_MWLqdE9HEdudU75l2xOQTw _MWLqek9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqck9HEdudU75l2xOQTw" guid="_MWLqck9HEdudU75l2xOQTw" anchor="_MWLqdU9HEdudU75l2xOQTw _MWLqVE9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqc09HEdudU75l2xOQTw" guid="_MWLqc09HEdudU75l2xOQTw" graphEdge="_MWLqbU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNBE9HEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqdE9HEdudU75l2xOQTw" guid="_MWLqdE9HEdudU75l2xOQTw" graphEdge="_MWLqcU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNBU9HEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqdU9HEdudU75l2xOQTw" guid="_MWLqdU9HEdudU75l2xOQTw" graphEdge="_MWLqck9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNBk9HEdudU75l2xOQTw" x="23.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqdk9HEdudU75l2xOQTw" guid="_MWLqdk9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_MXDNB09HEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqd09HEdudU75l2xOQTw" guid="_MWLqd09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNCE9HEdudU75l2xOQTw" x="83.0" y="110.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqeE9HEdudU75l2xOQTw" guid="_MWLqeE9HEdudU75l2xOQTw" anchor="_MWLqe09HEdudU75l2xOQTw _MWLqWU9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqeU9HEdudU75l2xOQTw" guid="_MWLqeU9HEdudU75l2xOQTw" anchor="_MWLqfE9HEdudU75l2xOQTw _MWLqm09HEdudU75l2xOQTw">
+ <waypoints xmi:id="_MXDNCU9HEdudU75l2xOQTw" x="94.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_MWLqek9HEdudU75l2xOQTw" guid="_MWLqek9HEdudU75l2xOQTw" graphEdge="_MWLqcU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNCk9HEdudU75l2xOQTw" x="11.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqe09HEdudU75l2xOQTw" guid="_MWLqe09HEdudU75l2xOQTw" graphEdge="_MWLqeE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNC09HEdudU75l2xOQTw" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqfE9HEdudU75l2xOQTw" guid="_MWLqfE9HEdudU75l2xOQTw" graphEdge="_MWLqeU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNDE9HEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqfU9HEdudU75l2xOQTw" guid="_MWLqfU9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_MXDNDU9HEdudU75l2xOQTw" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqfk9HEdudU75l2xOQTw" name="Add Free Text" guid="_MWLqfk9HEdudU75l2xOQTw">
+ <property xmi:id="_MWLqf09HEdudU75l2xOQTw" guid="_MWLqf09HEdudU75l2xOQTw" key="free text" value="[major change]"/>
+ <position xmi:id="_MXDNDk9HEdudU75l2xOQTw" x="107.0" y="25.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqgE9HEdudU75l2xOQTw" guid="_MWLqgE9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_MXDND09HEdudU75l2xOQTw" width="71.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqgU9HEdudU75l2xOQTw" name="Add Free Text" guid="_MWLqgU9HEdudU75l2xOQTw">
+ <property xmi:id="_MWLqgk9HEdudU75l2xOQTw" guid="_MWLqgk9HEdudU75l2xOQTw" key="free text" value="[small change]"/>
+ <position xmi:id="_MXDNEE9HEdudU75l2xOQTw" x="106.0" y="105.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqg09HEdudU75l2xOQTw" guid="_MWLqg09HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_MXDNEU9HEdudU75l2xOQTw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqhE9HEdudU75l2xOQTw" guid="_MWLqhE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNEk9HEdudU75l2xOQTw" x="42.0" y="232.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqhU9HEdudU75l2xOQTw" guid="_MWLqhU9HEdudU75l2xOQTw" anchor="_MWLqiE9HEdudU75l2xOQTw _MWLqZE9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqhk9HEdudU75l2xOQTw" guid="_MWLqhk9HEdudU75l2xOQTw" anchor="_MWLqiU9HEdudU75l2xOQTw _MWLqXk9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqh09HEdudU75l2xOQTw" guid="_MWLqh09HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_MWLqiE9HEdudU75l2xOQTw" guid="_MWLqiE9HEdudU75l2xOQTw" graphEdge="_MWLqhU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNE09HEdudU75l2xOQTw" x="201.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqiU9HEdudU75l2xOQTw" guid="_MWLqiU9HEdudU75l2xOQTw" graphEdge="_MWLqhk9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNFE9HEdudU75l2xOQTw" x="38.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqik9HEdudU75l2xOQTw" guid="_MWLqik9HEdudU75l2xOQTw" graphEdge="_MWLqmU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNFU9HEdudU75l2xOQTw" x="116.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqi09HEdudU75l2xOQTw" guid="_MWLqi09HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_MXDNFk9HEdudU75l2xOQTw" width="262.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqjE9HEdudU75l2xOQTw" name="Add Free Text" guid="_MWLqjE9HEdudU75l2xOQTw">
+ <property xmi:id="_MWLqjU9HEdudU75l2xOQTw" guid="_MWLqjU9HEdudU75l2xOQTw" key="free text" value="[trivial change]"/>
+ <position xmi:id="_MXDNF09HEdudU75l2xOQTw" x="98.0" y="153.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqjk9HEdudU75l2xOQTw" guid="_MWLqjk9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_MXDNGE9HEdudU75l2xOQTw" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqj09HEdudU75l2xOQTw" guid="_MWLqj09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNGU9HEdudU75l2xOQTw" x="42.0" y="382.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqkE9HEdudU75l2xOQTw" guid="_MWLqkE9HEdudU75l2xOQTw" anchor="_MWLqk09HEdudU75l2xOQTw _MWLqlk9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqkU9HEdudU75l2xOQTw" guid="_MWLqkU9HEdudU75l2xOQTw" graphEdge="_MWLqXU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNGk9HEdudU75l2xOQTw" x="39.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqkk9HEdudU75l2xOQTw" guid="_MWLqkk9HEdudU75l2xOQTw" graphEdge="_MWLqaE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNG09HEdudU75l2xOQTw" x="199.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqk09HEdudU75l2xOQTw" guid="_MWLqk09HEdudU75l2xOQTw" graphEdge="_MWLqkE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNHE9HEdudU75l2xOQTw" x="129.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqlE9HEdudU75l2xOQTw" guid="_MWLqlE9HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_MXDNHU9HEdudU75l2xOQTw" width="274.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqlU9HEdudU75l2xOQTw" guid="_MWLqlU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNHk9HEdudU75l2xOQTw" x="160.0" y="410.0"/>
+ <anchorage xmi:id="_MWLqlk9HEdudU75l2xOQTw" guid="_MWLqlk9HEdudU75l2xOQTw" graphEdge="_MWLqkE9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLql09HEdudU75l2xOQTw" guid="_MWLql09HEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_MXDNH09HEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MWLqmE9HEdudU75l2xOQTw" guid="_MWLqmE9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNIE9HEdudU75l2xOQTw" x="145.0" y="180.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MWLqmU9HEdudU75l2xOQTw" guid="_MWLqmU9HEdudU75l2xOQTw" anchor="_MWLqnE9HEdudU75l2xOQTw _MWLqik9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_MWLqmk9HEdudU75l2xOQTw" guid="_MWLqmk9HEdudU75l2xOQTw" graphEdge="_MWLqV09HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNIU9HEdudU75l2xOQTw" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqm09HEdudU75l2xOQTw" guid="_MWLqm09HEdudU75l2xOQTw" graphEdge="_MWLqeU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNIk9HEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MWLqnE9HEdudU75l2xOQTw" guid="_MWLqnE9HEdudU75l2xOQTw" graphEdge="_MWLqmU9HEdudU75l2xOQTw">
+ <position xmi:id="_MXDNI09HEdudU75l2xOQTw" x="13.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MWLqnU9HEdudU75l2xOQTw" guid="_MWLqnU9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_MXDNJE9HEdudU75l2xOQTw" width="28.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_MWLqnk9HEdudU75l2xOQTw" guid="_MWLqnk9HEdudU75l2xOQTw" presentation="Workflow" element="_MWFjoU9HEdudU75l2xOQTw"/>
+ </diagrams>
+ </childPackages>
+ <diagrams xmi:id="_y-k0C-tQEdqc1LGhiSPqRg" guid="_y-k0C-tQEdqc1LGhiSPqRg">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0TutQEdqc1LGhiSPqRg" guid="_y-k0TutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1NutQEdqc1LGhiSPqRg" x="334.0" y="79.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0UetQEdqc1LGhiSPqRg" guid="_y-k0UetQEdqc1LGhiSPqRg" anchor="_y-k0UutQEdqc1LGhiSPqRg _y-k0YutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0UOtQEdqc1LGhiSPqRg" guid="_y-k0UOtQEdqc1LGhiSPqRg" graphEdge="_y-k0I-tQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0UutQEdqc1LGhiSPqRg" guid="_y-k0UutQEdqc1LGhiSPqRg" graphEdge="_y-k0UetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1N-tQEdqc1LGhiSPqRg" x="488.0" y="118.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0T-tQEdqc1LGhiSPqRg" guid="_y-k0T-tQEdqc1LGhiSPqRg" element="_y-k0bOtQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1OOtQEdqc1LGhiSPqRg" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0WOtQEdqc1LGhiSPqRg" guid="_y-k0WOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1OetQEdqc1LGhiSPqRg" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0WetQEdqc1LGhiSPqRg" guid="_y-k0WetQEdqc1LGhiSPqRg" anchor="_y-k0WutQEdqc1LGhiSPqRg _y-k0YetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0WutQEdqc1LGhiSPqRg" guid="_y-k0WutQEdqc1LGhiSPqRg" graphEdge="_y-k0WetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1OutQEdqc1LGhiSPqRg" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0W-tQEdqc1LGhiSPqRg" guid="_y-k0W-tQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1O-tQEdqc1LGhiSPqRg" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0U-tQEdqc1LGhiSPqRg" guid="_y-k0U-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1POtQEdqc1LGhiSPqRg" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0VOtQEdqc1LGhiSPqRg" guid="_y-k0VOtQEdqc1LGhiSPqRg" anchor="_y-k0V-tQEdqc1LGhiSPqRg _y-k0QetQEdqc1LGhiSPqRg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0VetQEdqc1LGhiSPqRg" guid="_y-k0VetQEdqc1LGhiSPqRg"/>
+ </contained>
+ <anchorage xmi:id="_y-k0V-tQEdqc1LGhiSPqRg" guid="_y-k0V-tQEdqc1LGhiSPqRg" graphEdge="_y-k0VOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1PetQEdqc1LGhiSPqRg" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0VutQEdqc1LGhiSPqRg" guid="_y-k0VutQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1PutQEdqc1LGhiSPqRg" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0PutQEdqc1LGhiSPqRg" guid="_y-k0PutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1P-tQEdqc1LGhiSPqRg" x="245.0" y="215.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0QutQEdqc1LGhiSPqRg" guid="_y-k0QutQEdqc1LGhiSPqRg" anchor="_y-k0P-tQEdqc1LGhiSPqRg _y-k0XetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0QetQEdqc1LGhiSPqRg" guid="_y-k0QetQEdqc1LGhiSPqRg" graphEdge="_y-k0VOtQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0QOtQEdqc1LGhiSPqRg" guid="_y-k0QOtQEdqc1LGhiSPqRg" graphEdge="_y-k0JetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0P-tQEdqc1LGhiSPqRg" guid="_y-k0P-tQEdqc1LGhiSPqRg" graphEdge="_y-k0QutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1QOtQEdqc1LGhiSPqRg" x="568.0" y="250.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0Q-tQEdqc1LGhiSPqRg" guid="_y-k0Q-tQEdqc1LGhiSPqRg" element="_y-3IretQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1QetQEdqc1LGhiSPqRg" width="96.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0FutQEdqc1LGhiSPqRg" guid="_y-k0FutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1QutQEdqc1LGhiSPqRg" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0GetQEdqc1LGhiSPqRg" guid="_y-k0GetQEdqc1LGhiSPqRg" anchor="_y-k0F-tQEdqc1LGhiSPqRg _y-k0ZutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0F-tQEdqc1LGhiSPqRg" guid="_y-k0F-tQEdqc1LGhiSPqRg" graphEdge="_y-k0GetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1Q-tQEdqc1LGhiSPqRg" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0GOtQEdqc1LGhiSPqRg" guid="_y-k0GOtQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1ROtQEdqc1LGhiSPqRg" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0MutQEdqc1LGhiSPqRg" guid="_y-k0MutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1RetQEdqc1LGhiSPqRg" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0M-tQEdqc1LGhiSPqRg" guid="_y-k0M-tQEdqc1LGhiSPqRg" anchor="_y-k0NOtQEdqc1LGhiSPqRg _y-k0Y-tQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0NutQEdqc1LGhiSPqRg" guid="_y-k0NutQEdqc1LGhiSPqRg" graphEdge="_y-k0IutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0NOtQEdqc1LGhiSPqRg" guid="_y-k0NOtQEdqc1LGhiSPqRg" graphEdge="_y-k0M-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1RutQEdqc1LGhiSPqRg" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0NetQEdqc1LGhiSPqRg" guid="_y-k0NetQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1R-tQEdqc1LGhiSPqRg" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0N-tQEdqc1LGhiSPqRg" guid="_y-k0N-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1SOtQEdqc1LGhiSPqRg" x="306.0" y="10.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0OutQEdqc1LGhiSPqRg" guid="_y-k0OutQEdqc1LGhiSPqRg" anchor="_y-k0OetQEdqc1LGhiSPqRg _y-k0HutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0OetQEdqc1LGhiSPqRg" guid="_y-k0OetQEdqc1LGhiSPqRg" graphEdge="_y-k0OutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1SetQEdqc1LGhiSPqRg" x="10.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0OOtQEdqc1LGhiSPqRg" guid="_y-k0OOtQEdqc1LGhiSPqRg" typeInfo="start node"/>
+ <size xmi:id="_z8f1SutQEdqc1LGhiSPqRg" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0O-tQEdqc1LGhiSPqRg" guid="_y-k0O-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1S-tQEdqc1LGhiSPqRg" x="298.0" y="354.0"/>
+ <anchorage xmi:id="_y-k0PetQEdqc1LGhiSPqRg" guid="_y-k0PetQEdqc1LGhiSPqRg" graphEdge="_y-k0aetQEdqc1LGhiSPqRg"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0POtQEdqc1LGhiSPqRg" guid="_y-k0POtQEdqc1LGhiSPqRg" typeInfo="end node"/>
+ <size xmi:id="_z8f1TOtQEdqc1LGhiSPqRg" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0GutQEdqc1LGhiSPqRg" guid="_y-k0GutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1TetQEdqc1LGhiSPqRg" x="42.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0KOtQEdqc1LGhiSPqRg" guid="_y-k0KOtQEdqc1LGhiSPqRg" anchor="_y-k0H-tQEdqc1LGhiSPqRg _y-k0TetQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0HetQEdqc1LGhiSPqRg" guid="_y-k0HetQEdqc1LGhiSPqRg" anchor="_y-k0K-tQEdqc1LGhiSPqRg _y-k0L-tQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0G-tQEdqc1LGhiSPqRg" guid="_y-k0G-tQEdqc1LGhiSPqRg" anchor="_y-k0KutQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0IOtQEdqc1LGhiSPqRg" guid="_y-k0IOtQEdqc1LGhiSPqRg" anchor="_y-k0JutQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0KetQEdqc1LGhiSPqRg" guid="_y-k0KetQEdqc1LGhiSPqRg" anchor="_y-k0LOtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0JetQEdqc1LGhiSPqRg" guid="_y-k0JetQEdqc1LGhiSPqRg" anchor="_y-k0HOtQEdqc1LGhiSPqRg _y-k0QOtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0I-tQEdqc1LGhiSPqRg" guid="_y-k0I-tQEdqc1LGhiSPqRg" anchor="_y-k0JOtQEdqc1LGhiSPqRg _y-k0UOtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0IutQEdqc1LGhiSPqRg" guid="_y-k0IutQEdqc1LGhiSPqRg" anchor="_y-k0J-tQEdqc1LGhiSPqRg _y-k0NutQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__jK84etQEdqc1LGhiSPqRg" guid="__jK84etQEdqc1LGhiSPqRg" anchor="__jK84OtQEdqc1LGhiSPqRg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_p5fPcUbpEduLBN1xMBngqw" guid="_p5fPcUbpEduLBN1xMBngqw" anchor="_p5fPcEbpEduLBN1xMBngqw _p5fPckbpEduLBN1xMBngqw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_h3gEEUbrEduez5pdMGsX2w" guid="_h3gEEUbrEduez5pdMGsX2w" anchor="_h3gEEEbrEduez5pdMGsX2w"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_wm_J4U9HEdudU75l2xOQTw" guid="_wm_J4U9HEdudU75l2xOQTw" anchor="_wm_J4E9HEdudU75l2xOQTw _wm_J4k9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_y-k0HutQEdqc1LGhiSPqRg" guid="_y-k0HutQEdqc1LGhiSPqRg" graphEdge="_y-k0OutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1TutQEdqc1LGhiSPqRg" x="273.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0H-tQEdqc1LGhiSPqRg" guid="_y-k0H-tQEdqc1LGhiSPqRg" graphEdge="_y-k0KOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1T-tQEdqc1LGhiSPqRg" x="477.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0K-tQEdqc1LGhiSPqRg" guid="_y-k0K-tQEdqc1LGhiSPqRg" graphEdge="_y-k0HetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1UOtQEdqc1LGhiSPqRg" x="162.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0KutQEdqc1LGhiSPqRg" guid="_y-k0KutQEdqc1LGhiSPqRg" graphEdge="_y-k0G-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1UetQEdqc1LGhiSPqRg" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0JutQEdqc1LGhiSPqRg" guid="_y-k0JutQEdqc1LGhiSPqRg" graphEdge="_y-k0IOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1UutQEdqc1LGhiSPqRg" x="101.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0LOtQEdqc1LGhiSPqRg" guid="_y-k0LOtQEdqc1LGhiSPqRg" graphEdge="_y-k0KetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1U-tQEdqc1LGhiSPqRg" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0HOtQEdqc1LGhiSPqRg" guid="_y-k0HOtQEdqc1LGhiSPqRg" graphEdge="_y-k0JetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1VOtQEdqc1LGhiSPqRg" x="251.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0JOtQEdqc1LGhiSPqRg" guid="_y-k0JOtQEdqc1LGhiSPqRg" graphEdge="_y-k0I-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1VetQEdqc1LGhiSPqRg" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0J-tQEdqc1LGhiSPqRg" guid="_y-k0J-tQEdqc1LGhiSPqRg" graphEdge="_y-k0IutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1VutQEdqc1LGhiSPqRg" x="393.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="__jK84OtQEdqc1LGhiSPqRg" guid="__jK84OtQEdqc1LGhiSPqRg" graphEdge="__jK84etQEdqc1LGhiSPqRg">
+ <position xmi:id="__jK84-tQEdqc1LGhiSPqRg" x="407.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_p5fPcEbpEduLBN1xMBngqw" guid="_p5fPcEbpEduLBN1xMBngqw" graphEdge="_p5fPcUbpEduLBN1xMBngqw">
+ <position xmi:id="_swYkEEbpEduLBN1xMBngqw" x="59.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_h3gEEEbrEduez5pdMGsX2w" guid="_h3gEEEbrEduez5pdMGsX2w" graphEdge="_h3gEEUbrEduez5pdMGsX2w">
+ <position xmi:id="_h3gEE0brEduez5pdMGsX2w" x="159.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wm_J4E9HEdudU75l2xOQTw" guid="_wm_J4E9HEdudU75l2xOQTw" graphEdge="_wm_J4U9HEdudU75l2xOQTw">
+ <position xmi:id="_wm_J409HEdudU75l2xOQTw" x="151.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0IetQEdqc1LGhiSPqRg" guid="_y-k0IetQEdqc1LGhiSPqRg" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z8f1V-tQEdqc1LGhiSPqRg" width="523.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0XOtQEdqc1LGhiSPqRg" guid="_y-k0XOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1WOtQEdqc1LGhiSPqRg" x="47.0" y="313.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0aetQEdqc1LGhiSPqRg" guid="_y-k0aetQEdqc1LGhiSPqRg" anchor="_y-k0YOtQEdqc1LGhiSPqRg _y-k0PetQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0YetQEdqc1LGhiSPqRg" guid="_y-k0YetQEdqc1LGhiSPqRg" graphEdge="_y-k0WetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1WetQEdqc1LGhiSPqRg" x="148.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0ZutQEdqc1LGhiSPqRg" guid="_y-k0ZutQEdqc1LGhiSPqRg" graphEdge="_y-k0GetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1WutQEdqc1LGhiSPqRg" x="542.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0X-tQEdqc1LGhiSPqRg" guid="_y-k0X-tQEdqc1LGhiSPqRg" graphEdge="_y-k0S-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1W-tQEdqc1LGhiSPqRg" x="472.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0XutQEdqc1LGhiSPqRg" guid="_y-k0XutQEdqc1LGhiSPqRg" graphEdge="_y-k0MOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1XOtQEdqc1LGhiSPqRg" x="151.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0ZOtQEdqc1LGhiSPqRg" guid="_y-k0ZOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1XetQEdqc1LGhiSPqRg" x="16.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0Z-tQEdqc1LGhiSPqRg" guid="_y-k0Z-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1XutQEdqc1LGhiSPqRg" x="95.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0aOtQEdqc1LGhiSPqRg" guid="_y-k0aOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_KCFy0OtREdqc1LGhiSPqRg" x="170.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0XetQEdqc1LGhiSPqRg" guid="_y-k0XetQEdqc1LGhiSPqRg" graphEdge="_y-k0QutQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1YOtQEdqc1LGhiSPqRg" x="246.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0YutQEdqc1LGhiSPqRg" guid="_y-k0YutQEdqc1LGhiSPqRg" graphEdge="_y-k0UetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1YetQEdqc1LGhiSPqRg" x="328.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0Y-tQEdqc1LGhiSPqRg" guid="_y-k0Y-tQEdqc1LGhiSPqRg" graphEdge="_y-k0M-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1YutQEdqc1LGhiSPqRg" x="387.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0YOtQEdqc1LGhiSPqRg" guid="_y-k0YOtQEdqc1LGhiSPqRg" graphEdge="_y-k0aetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1Y-tQEdqc1LGhiSPqRg" x="262.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_A0fa0utREdqc1LGhiSPqRg" guid="_A0fa0utREdqc1LGhiSPqRg">
+ <position xmi:id="_A0fa1OtREdqc1LGhiSPqRg" x="403.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_qsrm8kbpEduLBN1xMBngqw" guid="_qsrm8kbpEduLBN1xMBngqw" graphEdge="_qsrm8UbpEduLBN1xMBngqw">
+ <position xmi:id="_qsrm9EbpEduLBN1xMBngqw" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_jQOKgkbrEduez5pdMGsX2w" guid="_jQOKgkbrEduez5pdMGsX2w">
+ <position xmi:id="_jQOKhEbrEduez5pdMGsX2w" x="154.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_yEykok9HEdudU75l2xOQTw" guid="_yEykok9HEdudU75l2xOQTw" graphEdge="_yEykoU9HEdudU75l2xOQTw">
+ <position xmi:id="_0v9xcE9HEdudU75l2xOQTw" x="146.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_y-k0ZetQEdqc1LGhiSPqRg" guid="_y-k0ZetQEdqc1LGhiSPqRg" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z8f1ZOtQEdqc1LGhiSPqRg" width="509.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0SetQEdqc1LGhiSPqRg" guid="_y-k0SetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1aOtQEdqc1LGhiSPqRg" x="477.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0S-tQEdqc1LGhiSPqRg" guid="_y-k0S-tQEdqc1LGhiSPqRg" anchor="_y-k0SutQEdqc1LGhiSPqRg _y-k0X-tQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0TetQEdqc1LGhiSPqRg" guid="_y-k0TetQEdqc1LGhiSPqRg" graphEdge="_y-k0KOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1aetQEdqc1LGhiSPqRg" x="38.0" y="-91.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0SutQEdqc1LGhiSPqRg" guid="_y-k0SutQEdqc1LGhiSPqRg" graphEdge="_y-k0S-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1autQEdqc1LGhiSPqRg" x="-28.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0TOtQEdqc1LGhiSPqRg" guid="_y-k0TOtQEdqc1LGhiSPqRg" element="_y_PjTOtQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1a-tQEdqc1LGhiSPqRg" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y-k0LetQEdqc1LGhiSPqRg" guid="_y-k0LetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1bOtQEdqc1LGhiSPqRg" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_y-k0MOtQEdqc1LGhiSPqRg" guid="_y-k0MOtQEdqc1LGhiSPqRg" anchor="_y-k0MetQEdqc1LGhiSPqRg _y-k0XutQEdqc1LGhiSPqRg"/>
+ <anchorage xmi:id="_y-k0L-tQEdqc1LGhiSPqRg" guid="_y-k0L-tQEdqc1LGhiSPqRg" graphEdge="_y-k0HetQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1betQEdqc1LGhiSPqRg" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_y-k0MetQEdqc1LGhiSPqRg" guid="_y-k0MetQEdqc1LGhiSPqRg" graphEdge="_y-k0MOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_z8f1butQEdqc1LGhiSPqRg" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0LutQEdqc1LGhiSPqRg" guid="_y-k0LutQEdqc1LGhiSPqRg"/>
+ <size xmi:id="_z8f1b-tQEdqc1LGhiSPqRg" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kEWoEEbpEduLBN1xMBngqw" guid="_kEWoEEbpEduLBN1xMBngqw">
+ <position xmi:id="_kEWoEUbpEduLBN1xMBngqw" x="48.0" y="77.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_qsrm8UbpEduLBN1xMBngqw" guid="_qsrm8UbpEduLBN1xMBngqw" anchor="_qsrm8EbpEduLBN1xMBngqw _qsrm8kbpEduLBN1xMBngqw"/>
+ <anchorage xmi:id="_p5fPckbpEduLBN1xMBngqw" guid="_p5fPckbpEduLBN1xMBngqw" graphEdge="_p5fPcUbpEduLBN1xMBngqw"/>
+ <anchorage xmi:id="_qsrm8EbpEduLBN1xMBngqw" guid="_qsrm8EbpEduLBN1xMBngqw" graphEdge="_qsrm8UbpEduLBN1xMBngqw">
+ <position xmi:id="_qsrm80bpEduLBN1xMBngqw" x="101.0" y="93.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kEWoEkbpEduLBN1xMBngqw" guid="_kEWoEkbpEduLBN1xMBngqw" element="_eE5nEUbpEduLBN1xMBngqw"/>
+ <size xmi:id="_kEWoE0bpEduLBN1xMBngqw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_r4KqUE9HEdudU75l2xOQTw" guid="_r4KqUE9HEdudU75l2xOQTw">
+ <position xmi:id="_r4KqUU9HEdudU75l2xOQTw" x="144.0" y="158.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_yEykoU9HEdudU75l2xOQTw" guid="_yEykoU9HEdudU75l2xOQTw" anchor="_yEykoE9HEdudU75l2xOQTw _yEykok9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_wm_J4k9HEdudU75l2xOQTw" guid="_wm_J4k9HEdudU75l2xOQTw" graphEdge="_wm_J4U9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_yEykoE9HEdudU75l2xOQTw" guid="_yEykoE9HEdudU75l2xOQTw" graphEdge="_yEykoU9HEdudU75l2xOQTw">
+ <position xmi:id="_yEyko09HEdudU75l2xOQTw" x="193.0" y="179.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_r4KqUk9HEdudU75l2xOQTw" guid="_r4KqUk9HEdudU75l2xOQTw" element="_MWFjoU9HEdudU75l2xOQTw"/>
+ <size xmi:id="_r4KqU09HEdudU75l2xOQTw" width="98.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y-k0autQEdqc1LGhiSPqRg" guid="_y-k0autQEdqc1LGhiSPqRg" presentation="Workflow" element="_y-3IrutQEdqc1LGhiSPqRg"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_y-3IrutQEdqc1LGhiSPqRg" name="construction_phase_iteration" guid="_y-3IrutQEdqc1LGhiSPqRg" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Construction phase. Each activity and its goals is described." presentationName="Construction Phase Iteration" isRepeatable="true" breakdownElements="_y-k0bOtQEdqc1LGhiSPqRg _eE5nEUbpEduLBN1xMBngqw _MWFjoU9HEdudU75l2xOQTw _y-3IretQEdqc1LGhiSPqRg _y_PjTOtQEdqc1LGhiSPqRg">
+ <ownedRules xmi:id="_y-3Ir-tQEdqc1LGhiSPqRg" guid="_y-3Ir-tQEdqc1LGhiSPqRg"/>
+ <presentation xmi:id="-239OBD2wagT2qp8fuPWcHQ" href="uma://-OC3td1csl7lqV15vimYOaw#-239OBD2wagT2qp8fuPWcHQ"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/define_architecture/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/define_architecture/content.xmi
new file mode 100644
index 0000000..1d8755f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/define_architecture/content.xmi
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb_DvL5Edm6Nvont3uinw" guid="_mtb_DvL5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity is repeated in each iteration in the Elaboration phase. The main&nbsp;goal of this activity is&nbsp;to
+ propose an <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> that addresses the requirements with high architectural risks, thus
+ providing a solid, yet resilient, foundation on which to build the system functionality.
+</p>
+<p>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> analyzes the architectural constraints, identifies available assets to
+ build the system, defines how the system will be structured, and identifies the initial abstractions and mechanisms
+ that must be provided by the architecture.
+</p>
+<p>
+ Throughout all of the iterations, the architect:
+</p>
+<ul>
+ <li>
+ Identifies commonalities between different requirements to leverage reuse
+ </li>
+ <li>
+ Defines strategies for achieving requirements related to quality
+ </li>
+ <li>
+ Captures and communicates architectural decisions
+ </li>
+</ul></mainDescription>
+ <howtoStaff><p>
+ These activities are best carried out by a small team staffed by cross-functional team members. Issues that are
+ typically architecturally significant include usability, performance, scaling, process and thread synchronization, and
+ distribution. The team should also include members with domain experience who can identify key abstractions. The team
+ should also have experience with model organization and layering. The team will need to be able to pull all these
+ disparate threads into a cohesive, coherent (albeit preliminary) architecture.
+</p>
+<p>
+ Because the focus of the architecture effort is shifting toward implementation issues, greater attention needs to be
+ paid to specific technology issues. This will force the architecture team to shift members or expand to include people
+ with distribution and deployment expertise (if those issues are architecturally significant). In order to understand
+ the potential impact of the structure on the implementation model on the ease of integration, expertise in the software
+ build management process is useful to have.
+</p>
+<p>
+ At the same time, it is essential that the architecture team not be composed of a large extended team. A strategy for
+ countering this trend is to retain a relatively small core team with a satellite group of extended team members that
+ are brought in as "consultants" on key issues<b>.</b> This structure also works well for smaller projects where
+ specific expertise may be borrowed or contracted from other organizations; they can be brought in as specific issues
+ need to be addressed.
+</p></howtoStaff>
+ <usageNotes><p>
+ The work is best done in several sessions, perhaps performed over a few days (or weeks and months for very large
+ systems). The initial focus will be on the identifying <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Concept: Design Mechanism</a>s&nbsp;and&nbsp;specifiying the&nbsp;important&nbsp;design
+ elements.&nbsp;Care should also be taken to incorporate existing design elements to ensure that new&nbsp;design do not
+ duplicate existing functionality.
+</p>
+<p>
+ As the design emerges, concurrency and distribution issues are introduced. As these issues are considered, changes to
+ design elements may be required to split behavior across processes, threads or nodes.
+</p>
+<p>
+ As the individual models are refined to incorporate the architectural decisions, the results are documented in the
+ Architecture description. The resulting architecture is reviewed.
+</p></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/define_architecture/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/define_architecture/model.xmi
new file mode 100644
index 0000000..c4397f9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/define_architecture/model.xmi
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nLga8vL5Edm6Nvont3uinw" guid="_nLga8vL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nLga8fL5Edm6Nvont3uinw" id="_mtb_DvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0sx7iclgEdmt3adZL5Dmdw" name="define_architecture" guid="_0sx7iclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_d5-nQFY4EdqI9sTOt2pjHw" name="architect" guid="_d5-nQFY4EdqI9sTOt2pjHw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw" responsibleFor="_d6Q7IVY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_d6Q7IVY4EdqI9sTOt2pjHw" name="architecture" guid="_d6Q7IVY4EdqI9sTOt2pjHw" presentationName="Architecture" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_ukbHgL-EEdqb7N6KIeDL8Q" name="analyze_arch_reqs" guid="_ukbHgL-EEdqb7N6KIeDL8Q" presentationName="Analyze the Architectural Requirements" superActivities="_0sx7islgEdmt3adZL5Dmdw" additionallyPerformedBy="_ezOKIE9DEdudU75l2xOQTw _ezOKIU9DEdudU75l2xOQTw _HTBBME_dEduE1dJ2XtzzkQ _HTBBMU_dEduE1dJ2XtzzkQ _r1QxIDeqEduCsbgJNeFsSw" mandatoryInput="_VZk0YxeDEduXJrZWmtC8tg _VZk0ZBeDEduXJrZWmtC8tg _r1Xe0DeqEduCsbgJNeFsSw" optionalInput="_uknUwb-EEdqb7N6KIeDL8Q _d6Q7IVY4EdqI9sTOt2pjHw _ezOKIk9DEdudU75l2xOQTw _uknUwL-EEdqb7N6KIeDL8Q" output="_d6Q7IVY4EdqI9sTOt2pjHw _uknUwb-EEdqb7N6KIeDL8Q" performedPrimarilyBy="_d5-nQFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0f-1oMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_3nMQQA3rEduibvKwrGxWxA"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_9o6Z4CSCEdqDjNgZyGMf5w"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_B899cMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_FVrlsMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_tmvWwE5cEducxZ_XZXh-vw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_I32E4MP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_KBAsYMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_xTdYACGAEdqk6N_Ot_YEvA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_uknUwL-EEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_uknUwL-EEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_uknUwb-EEdqb7N6KIeDL8Q" name="design" guid="_uknUwb-EEdqb7N6KIeDL8Q" presentationName="Design" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_vAmGIL-EEdqb7N6KIeDL8Q" name="develop_arch" guid="_vAmGIL-EEdqb7N6KIeDL8Q" presentationName="Develop the Architecture" superActivities="_0sx7islgEdmt3adZL5Dmdw" additionallyPerformedBy="_ezOKIE9DEdudU75l2xOQTw _HTBBMU_dEduE1dJ2XtzzkQ _r1QxIDeqEduCsbgJNeFsSw _ezOKIU9DEdudU75l2xOQTw _HTBBME_dEduE1dJ2XtzzkQ" mandatoryInput="_uknUwb-EEdqb7N6KIeDL8Q _d6Q7IVY4EdqI9sTOt2pjHw _uknUwL-EEdqb7N6KIeDL8Q _ezOKIk9DEdudU75l2xOQTw _VZk0ZBeDEduXJrZWmtC8tg _m_gdUMWrEduoutjwLchi0g" output="_uknUwb-EEdqb7N6KIeDL8Q _d6Q7IVY4EdqI9sTOt2pjHw" performedPrimarilyBy="_d5-nQFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0gRJgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_P28vkMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_0qoQ8CikEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_QtKuoCilEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Vdln8MP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_G_k1kBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_xIIVkMUbEdu5GrwIlTJV7g"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_LsyLkBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Zlw-QMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_aRCI0MP3EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_VZk0YxeDEduXJrZWmtC8tg" name="glossary" guid="_VZk0YxeDEduXJrZWmtC8tg" presentationName="Glossary" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_VZk0ZBeDEduXJrZWmtC8tg" name="vision" guid="_VZk0ZBeDEduXJrZWmtC8tg" presentationName="Vision" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_r1QxIDeqEduCsbgJNeFsSw" name="project_manager" guid="_r1QxIDeqEduCsbgJNeFsSw" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_r1Xe0DeqEduCsbgJNeFsSw" name="uc_model" guid="_r1Xe0DeqEduCsbgJNeFsSw" presentationName="Use-Case Model" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_ezOKIE9DEdudU75l2xOQTw" name="analyst" guid="_ezOKIE9DEdudU75l2xOQTw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw" responsibleFor="_r1Xe0DeqEduCsbgJNeFsSw _VZk0ZBeDEduXJrZWmtC8tg _VZk0YxeDEduXJrZWmtC8tg _uknUwL-EEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_ezOKIU9DEdudU75l2xOQTw" name="stakeholder" guid="_ezOKIU9DEdudU75l2xOQTw" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_ezOKIk9DEdudU75l2xOQTw" name="use_case" guid="_ezOKIk9DEdudU75l2xOQTw" presentationName="Use Case" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_HTBBME_dEduE1dJ2XtzzkQ" name="tester" guid="_HTBBME_dEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_HTBBMU_dEduE1dJ2XtzzkQ" name="developer" guid="_HTBBMU_dEduE1dJ2XtzzkQ" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0sx7islgEdmt3adZL5Dmdw" responsibleFor="_m_gdUMWrEduoutjwLchi0g _uknUwb-EEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_m_gdUMWrEduoutjwLchi0g" name="build" guid="_m_gdUMWrEduoutjwLchi0g" presentationName="Build" superActivities="_0sx7islgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0sx7islgEdmt3adZL5Dmdw" name="define_architecture" guid="_0sx7islgEdmt3adZL5Dmdw" briefDescription="This activity completes the architecture for an iteration." presentationName="Define the Architecture" hasMultipleOccurrences="true" breakdownElements="_d5-nQFY4EdqI9sTOt2pjHw _d6Q7IVY4EdqI9sTOt2pjHw _ukbHgL-EEdqb7N6KIeDL8Q _uknUwL-EEdqb7N6KIeDL8Q _uknUwb-EEdqb7N6KIeDL8Q _vAmGIL-EEdqb7N6KIeDL8Q _VZk0YxeDEduXJrZWmtC8tg _VZk0ZBeDEduXJrZWmtC8tg _r1QxIDeqEduCsbgJNeFsSw _r1Xe0DeqEduCsbgJNeFsSw _ezOKIE9DEdudU75l2xOQTw _ezOKIU9DEdudU75l2xOQTw _ezOKIk9DEdudU75l2xOQTw _HTBBME_dEduE1dJ2XtzzkQ _HTBBMU_dEduE1dJ2XtzzkQ _m_gdUMWrEduoutjwLchi0g">
+ <presentation xmi:id="_mtb_DvL5Edm6Nvont3uinw" href="uma://_mtb_DvL5Edm6Nvont3uinw#_mtb_DvL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.xmi
new file mode 100644
index 0000000..99fd498
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/content.xmi
@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb_DfL5Edm6Nvont3uinw" guid="_mtb_DfL5Edm6Nvont3uinw">
+ <howtoStaff><p>
+ As with <a class="elementLinkWithType" href="./../../openup_basic/capabilitypatterns/define_architecture,_0rcewclgEdmt3adZL5Dmdw.html" guid="_0rcewclgEdmt3adZL5Dmdw">Activity: Define the Architecture</a>, this activity is best carried out by a small team
+ staffed by cross-functional team members. Issues that are typically architecturally significant include performance,
+ scaling, process and thread synchronization, and distribution. The team should also include members with domain
+ experience who can identify key abstractions. The team should also have experience with model organization and
+ layering. From these inputs, the team will need to be able to synthesize a model, or even a prototype, of a solution.
+</p></howtoStaff>
+ <usageNotes><p>
+ The major effort occurs early in the Inception phase; thereafter, the system should be assessed at&nbsp;every iteration
+ to ensure that the design is still on track with the architecture (see <a class="elementLinkWithType" href="./../../openup_basic/capabilitypatterns/manage_iteration,_0nJNkslgEdmt3adZL5Dmdw.html" guid="_0nJNkslgEdmt3adZL5Dmdw">Capability Pattern: Plan and Manage Iteration</a>).
+</p></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.xmi
new file mode 100644
index 0000000..ab78e76
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/determine_architectural_feasibility/model.xmi
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nKu-4vL5Edm6Nvont3uinw" guid="_nKu-4vL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nKu-4fL5Edm6Nvont3uinw" id="_mtb_DfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0sluQclgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0sluQclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_qQROgFY4EdqI9sTOt2pjHw" name="architect" guid="_qQROgFY4EdqI9sTOt2pjHw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw" responsibleFor="_qQppAFY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_qQjiYFY4EdqI9sTOt2pjHw" name="design" guid="_qQjiYFY4EdqI9sTOt2pjHw" presentationName="Design" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_qQppAFY4EdqI9sTOt2pjHw" name="architecture" guid="_qQppAFY4EdqI9sTOt2pjHw" presentationName="Architecture" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_qoEDcFY4EdqI9sTOt2pjHw" name="developer" guid="_qoEDcFY4EdqI9sTOt2pjHw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw" responsibleFor="_NXkrwsWpEduoutjwLchi0g _qQjiYFY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_lqOzsL-EEdqb7N6KIeDL8Q" name="analyze_arch_reqs" guid="_lqOzsL-EEdqb7N6KIeDL8Q" presentationName="Analyze the Architectural Requirements" superActivities="_0sluQslgEdmt3adZL5Dmdw" additionallyPerformedBy="_PJJ3AE_dEduE1dJ2XtzzkQ _PJJ3AU_dEduE1dJ2XtzzkQ _PJJ3Ak_dEduE1dJ2XtzzkQ _qoEDcFY4EdqI9sTOt2pjHw _PJJ3A0_dEduE1dJ2XtzzkQ" mandatoryInput="_g2XAwheDEduXJrZWmtC8tg _mKmV0L-EEdqb7N6KIeDL8Q _HTpzcDSLEdursMWmT1aZyw" optionalInput="_qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw _NXkrwcWpEduoutjwLchi0g _lqbA8L-EEdqb7N6KIeDL8Q" output="_qQppAFY4EdqI9sTOt2pjHw _qQjiYFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_qQROgFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0f-1oMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_3nMQQA3rEduibvKwrGxWxA"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_9o6Z4CSCEdqDjNgZyGMf5w"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_B899cMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_FVrlsMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_tmvWwE5cEducxZ_XZXh-vw"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_I32E4MP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_KBAsYMP2EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_xTdYACGAEdqk6N_Ot_YEvA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_lqbA8L-EEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_lqbA8L-EEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_mKmV0L-EEdqb7N6KIeDL8Q" name="vision" guid="_mKmV0L-EEdqb7N6KIeDL8Q" presentationName="Vision" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_g2XAwheDEduXJrZWmtC8tg" name="glossary" guid="_g2XAwheDEduXJrZWmtC8tg" presentationName="Glossary" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_HTpzcDSLEdursMWmT1aZyw" name="uc_model" guid="_HTpzcDSLEdursMWmT1aZyw" presentationName="Use-Case Model" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3AE_dEduE1dJ2XtzzkQ" name="analyst" guid="_PJJ3AE_dEduE1dJ2XtzzkQ" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw" responsibleFor="_HTpzcDSLEdursMWmT1aZyw _g2XAwheDEduXJrZWmtC8tg _mKmV0L-EEdqb7N6KIeDL8Q _lqbA8L-EEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3AU_dEduE1dJ2XtzzkQ" name="stakeholder" guid="_PJJ3AU_dEduE1dJ2XtzzkQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3Ak_dEduE1dJ2XtzzkQ" name="tester" guid="_PJJ3Ak_dEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_PJJ3A0_dEduE1dJ2XtzzkQ" name="project_manager" guid="_PJJ3A0_dEduE1dJ2XtzzkQ" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_NXkrwMWpEduoutjwLchi0g" name="develop_arch" guid="_NXkrwMWpEduoutjwLchi0g" presentationName="Develop the Architecture" superActivities="_0sluQslgEdmt3adZL5Dmdw" additionallyPerformedBy="_PJJ3AE_dEduE1dJ2XtzzkQ _qoEDcFY4EdqI9sTOt2pjHw _PJJ3A0_dEduE1dJ2XtzzkQ _PJJ3AU_dEduE1dJ2XtzzkQ _PJJ3Ak_dEduE1dJ2XtzzkQ" mandatoryInput="_qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw _lqbA8L-EEdqb7N6KIeDL8Q _NXkrwcWpEduoutjwLchi0g _mKmV0L-EEdqb7N6KIeDL8Q _NXkrwsWpEduoutjwLchi0g" output="_qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_qQROgFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0gRJgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_P28vkMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_0qoQ8CikEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_QtKuoCilEduQBKSg5n118w"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Vdln8MP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_G_k1kBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_xIIVkMUbEdu5GrwIlTJV7g"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_LsyLkBaqEduSTJywppIxVQ"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_Zlw-QMP3EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_aRCI0MP3EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_NXkrwcWpEduoutjwLchi0g" name="use_case" guid="_NXkrwcWpEduoutjwLchi0g" presentationName="Use Case" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_NXkrwsWpEduoutjwLchi0g" name="build" guid="_NXkrwsWpEduoutjwLchi0g" presentationName="Build" superActivities="_0sluQslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0sluQslgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0sluQslgEdmt3adZL5Dmdw" briefDescription="Confirm that the project is feasible by constructing an architectural proof-of-concept." presentationName="Determine Architectural Feasibility" breakdownElements="_qQROgFY4EdqI9sTOt2pjHw _qQjiYFY4EdqI9sTOt2pjHw _qQppAFY4EdqI9sTOt2pjHw _qoEDcFY4EdqI9sTOt2pjHw _lqOzsL-EEdqb7N6KIeDL8Q _lqbA8L-EEdqb7N6KIeDL8Q _mKmV0L-EEdqb7N6KIeDL8Q _g2XAwheDEduXJrZWmtC8tg _HTpzcDSLEdursMWmT1aZyw _PJJ3AE_dEduE1dJ2XtzzkQ _PJJ3AU_dEduE1dJ2XtzzkQ _PJJ3Ak_dEduE1dJ2XtzzkQ _PJJ3A0_dEduE1dJ2XtzzkQ _NXkrwMWpEduoutjwLchi0g _NXkrwcWpEduoutjwLchi0g _NXkrwsWpEduoutjwLchi0g">
+ <presentation xmi:id="_mtb_DfL5Edm6Nvont3uinw" href="uma://_mtb_DfL5Edm6Nvont3uinw#_mtb_DfL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/develop_solution/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/develop_solution/content.xmi
new file mode 100644
index 0000000..92dc5a1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/develop_solution/content.xmi
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_h6zSEPimEdmugcVr9AdHjQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="_h6zSEPimEdmugcVr9AdHjQ" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
+ is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
+ unit-tested, and&nbsp;integrated&nbsp;source code.
+</p>
+<h4>
+ Context of what is being developed
+</h4>
+<p>
+ A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
+ to be developed in a iteration. Development&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
+ or&nbsp;database access),&nbsp;on a component, and so on.
+</p>
+<p>
+ Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
+ requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
+ works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
+</p>
+<h4>
+ Overview of workflow
+</h4>
+<p>
+ To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small
+ changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
+ changes and functionality to be developed, only the source code may be affected.
+</p>
+<p>
+ In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
+ happen, because they can happen in parallel.&nbsp;You may choose to create developer tests and run them before the actual
+ code is created or the reverse sequence.
+</p></mainDescription>
+ <purpose><ul>
+ <li>
+ For developers: To create a solution for the requirement assigned to them
+ </li>
+ <li>
+ For project managers: To have a goal-based way of assigning work and tracking project status
+ </li>
+</ul></purpose>
+ <usageNotes><p>
+ This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
+ requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
+ be assigned to a developer, and it should be renamed to include the actual requirement name.&nbsp;Optionally, the word
+ <strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
+</p>
+<blockquote>
+ <p align="left">
+ Develop requirement_name (within context_name context)
+ </p>
+</blockquote>
+<p>
+ If&nbsp;a context&nbsp;is specified, there will be one instance of this pattern for each requirement&nbsp;for each
+ context.
+</p>
+<blockquote>
+ <p>
+ <strong>Example</strong>
+ </p>
+ <ol>
+ <li>
+ Develop scenario 1 (within user interface context)
+ </li>
+ <li>
+ Develop scenario 1 (within business logic and DB access context)
+ </li>
+ <li>
+ Develop scenario 2
+ </li>
+ <li>
+ Develop supplemental requirement 1
+ </li>
+ </ol>
+</blockquote>
+<p>
+ Note that there are four instances of this pattern in the preceding example:
+</p>
+<ul>
+ <li>
+ The first two are related to the same requirement (scenario 1) but within two different contexts
+ </li>
+ <li>
+ The last two are related to different requirements, with no context specified.
+ </li>
+</ul></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/develop_solution/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/develop_solution/model.xmi
new file mode 100644
index 0000000..91010e4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/develop_solution/model.xmi
@@ -0,0 +1,264 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_h7wUUPimEdmugcVr9AdHjQ" guid="_h7wUUPimEdmugcVr9AdHjQ">
+ <resourceDescriptors xmi:id="_h72a8PimEdmugcVr9AdHjQ" id="_h6zSEPimEdmugcVr9AdHjQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_h2-iAPimEdmugcVr9AdHjQ" name="develop_solution" guid="_h2-iAPimEdmugcVr9AdHjQ">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_9kUSEFY4EdqI9sTOt2pjHw" name="developer" guid="_9kUSEFY4EdqI9sTOt2pjHw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_AdllQFY5EdqI9sTOt2pjHw _-Y3UcFY4EdqI9sTOt2pjHw _-YrHMFY4EdqI9sTOt2pjHw _9k_AcFY4EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_9k_AcFY4EdqI9sTOt2pjHw" name="design" guid="_9k_AcFY4EdqI9sTOt2pjHw" presentationName="Design" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WuL8slgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_-YrHMFY4EdqI9sTOt2pjHw" name="implementation" guid="_-YrHMFY4EdqI9sTOt2pjHw" presentationName="Implementation" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YoQcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_-Y3UcFY4EdqI9sTOt2pjHw" name="developer_test" guid="_-Y3UcFY4EdqI9sTOt2pjHw" presentationName="Developer Test" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_AdllQFY5EdqI9sTOt2pjHw" name="build" guid="_AdllQFY5EdqI9sTOt2pjHw" presentationName="Build" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_cL1KIL-FEdqb7N6KIeDL8Q" name="design_solution" guid="_cL1KIL-FEdqb7N6KIeDL8Q" presentationName="Design the Solution" superActivities="_h2-iAfimEdmugcVr9AdHjQ" linkToPredecessor="_TiPK8DLwEdueZPye-FaNgA" additionallyPerformedBy="_rQ9xIMjkEdqIm8AJUZUQYg _KAnAYE9PEdumneEH4I4Yqg _BmbHQE_cEduE1dJ2XtzzkQ _BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_cMHeAL-FEdqb7N6KIeDL8Q _cMHeAb-FEdqb7N6KIeDL8Q _QN4E4ALlEduHjPEP_YPH-g" optionalInput="_9k_AcFY4EdqI9sTOt2pjHw" output="_9k_AcFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0fshwMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_4Z7WYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_--6tYKuKEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_A_LU8KuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_ENwJwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_KNZYAKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_OGYbwKuLEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_Ci7aYFixEdusJoWkvSRO9Q"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_9LeFME42EdudDeUNeAxPCQ"/>
+ <selectedSteps href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_mUVt8BfnEduD353bkQ4frw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_cMHeAL-FEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_cMHeAL-FEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_cMHeAb-FEdqb7N6KIeDL8Q" name="architecture" guid="_cMHeAb-FEdqb7N6KIeDL8Q" presentationName="Architecture" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_cnzUcL-FEdqb7N6KIeDL8Q" name="impl_developer_tests" guid="_cnzUcL-FEdqb7N6KIeDL8Q" presentationName="Implement Developer Tests" superActivities="_h2-iAfimEdmugcVr9AdHjQ" linkToPredecessor="__26sYMmIEduwrYVlQ9zp3w" additionallyPerformedBy="_BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_-YrHMFY4EdqI9sTOt2pjHw" optionalInput="_9k_AcFY4EdqI9sTOt2pjHw" output="_-Y3UcFY4EdqI9sTOt2pjHw" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iL1EMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_2LYo8KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g8npoC5UEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_g1eDUC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_5WtVcKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_j30aAC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_ku06gC5VEduVhuZHT5jKZQ"/>
+ <selectedSteps href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_6wZFMKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_dAoEIL-FEdqb7N6KIeDL8Q" name="implement_solution" guid="_dAoEIL-FEdqb7N6KIeDL8Q" presentationName="Implement the Solution" superActivities="_h2-iAfimEdmugcVr9AdHjQ" additionallyPerformedBy="_BmbHQE_cEduE1dJ2XtzzkQ _BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_9k_AcFY4EdqI9sTOt2pjHw" optionalInput="_-YrHMFY4EdqI9sTOt2pjHw _cMHeAL-FEdqb7N6KIeDL8Q _QN4E4ALlEduHjPEP_YPH-g" output="_-YrHMFY4EdqI9sTOt2pjHw _AdllQFY5EdqI9sTOt2pjHw _cMHeAL-FEdqb7N6KIeDL8Q _QN4E4ALlEduHjPEP_YPH-g" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hyzgMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_2sxisE2iEduU655MA_3VXg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_iMMWoKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_pjehkNb7Edq_LtLvi4w2yw"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_mFQ58KuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_-0yzwDH4EduMqpUNhaTSRA"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_ni25UKuPEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_q5XiIKuPEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_d4GesL-FEdqb7N6KIeDL8Q" name="run_developer_tests" guid="_d4GesL-FEdqb7N6KIeDL8Q" presentationName="Run Developer Tests" superActivities="_h2-iAfimEdmugcVr9AdHjQ" linkToPredecessor="_EjyMUE9EEdudU75l2xOQTw _c84V8MmJEduwrYVlQ9zp3w" additionallyPerformedBy="_BmbHQU_cEduE1dJ2XtzzkQ" mandatoryInput="_-Y3UcFY4EdqI9sTOt2pjHw _-YrHMFY4EdqI9sTOt2pjHw" output="_d4k_0L-FEdqb7N6KIeDL8Q" performedPrimarilyBy="_9kUSEFY4EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iYCUMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_MSnQsMP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_NkRF0MP4EdmWKcx6ixEiwg"/>
+ <selectedSteps href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_SXPFkMP4EdmWKcx6ixEiwg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_d4k_0L-FEdqb7N6KIeDL8Q" name="test_log" guid="_d4k_0L-FEdqb7N6KIeDL8Q" presentationName="Test Log" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZlSsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_rQ9xIMjkEdqIm8AJUZUQYg" name="architect" guid="_rQ9xIMjkEdqIm8AJUZUQYg" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_cMHeAb-FEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_QN4E4ALlEduHjPEP_YPH-g" name="use_case" guid="_QN4E4ALlEduHjPEP_YPH-g" presentationName="Use Case" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_TiPK8DLwEdueZPye-FaNgA" guid="_TiPK8DLwEdueZPye-FaNgA" linkType="finishToFinish"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_RfwvEDOvEduqsLmIADMQ9g" name="test_script" guid="_RfwvEDOvEduqsLmIADMQ9g" presentationName="Test Script" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_EjyMUE9EEdudU75l2xOQTw" guid="_EjyMUE9EEdudU75l2xOQTw" linkType="finishToFinish" pred="_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_KAnAYE9PEdumneEH4I4Yqg" name="analyst" guid="_KAnAYE9PEdumneEH4I4Yqg" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_cMHeAL-FEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_BmbHQE_cEduE1dJ2XtzzkQ" name="stakeholder" guid="_BmbHQE_cEduE1dJ2XtzzkQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_BmbHQU_cEduE1dJ2XtzzkQ" name="tester" guid="_BmbHQU_cEduE1dJ2XtzzkQ" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_h2-iAfimEdmugcVr9AdHjQ" responsibleFor="_RfwvEDOvEduqsLmIADMQ9g _d4k_0L-FEdqb7N6KIeDL8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="__26sYMmIEduwrYVlQ9zp3w" guid="__26sYMmIEduwrYVlQ9zp3w" linkType="finishToFinish" pred="_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_c84V8MmJEduwrYVlQ9zp3w" guid="_c84V8MmJEduwrYVlQ9zp3w" linkType="finishToFinish" pred="_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ <diagrams xmi:id="_OqnlAERlEduP07d3x5Xi-g" guid="_OqnlAERlEduP07d3x5Xi-g">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlBkRlEduP07d3x5Xi-g" guid="_OqnlBkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlB0RlEduP07d3x5Xi-g" x="188.0" y="40.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_sJ5GcURlEduP07d3x5Xi-g" guid="_sJ5GcURlEduP07d3x5Xi-g" anchor="_sJ5GcERlEduP07d3x5Xi-g _sJ5GckRlEduP07d3x5Xi-g">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="__26sYcmIEduwrYVlQ9zp3w" guid="__26sYcmIEduwrYVlQ9zp3w"/>
+ </contained>
+ <anchorage xmi:id="_OqnlGERlEduP07d3x5Xi-g" guid="_OqnlGERlEduP07d3x5Xi-g"/>
+ <anchorage xmi:id="_X2KukkRlEduP07d3x5Xi-g" guid="_X2KukkRlEduP07d3x5Xi-g" graphEdge="_X2KukURlEduP07d3x5Xi-g"/>
+ <anchorage xmi:id="_sJ5GcERlEduP07d3x5Xi-g" guid="_sJ5GcERlEduP07d3x5Xi-g" graphEdge="_sJ5GcURlEduP07d3x5Xi-g">
+ <position xmi:id="_sJ5Gc0RlEduP07d3x5Xi-g" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlCERlEduP07d3x5Xi-g" guid="_OqnlCERlEduP07d3x5Xi-g" element="_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlCURlEduP07d3x5Xi-g" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlCkRlEduP07d3x5Xi-g" guid="_OqnlCkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlC0RlEduP07d3x5Xi-g" x="182.0" y="336.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_c8f7ccmJEduwrYVlQ9zp3w" guid="_c8f7ccmJEduwrYVlQ9zp3w" anchor="_c8f7cMmJEduwrYVlQ9zp3w _c8f7csmJEduwrYVlQ9zp3w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_c84V8cmJEduwrYVlQ9zp3w" guid="_c84V8cmJEduwrYVlQ9zp3w"/>
+ <waypoints xmi:id="_HjEDQMmKEduwrYVlQ9zp3w" x="340.0" y="359.0"/>
+ <waypoints xmi:id="_EddkQMmKEduwrYVlQ9zp3w" x="340.0" y="230.0"/>
+ </contained>
+ <anchorage xmi:id="_Q9sAEsmJEduwrYVlQ9zp3w" guid="_Q9sAEsmJEduwrYVlQ9zp3w" graphEdge="_Q9sAEcmJEduwrYVlQ9zp3w"/>
+ <anchorage xmi:id="_c8f7cMmJEduwrYVlQ9zp3w" guid="_c8f7cMmJEduwrYVlQ9zp3w" graphEdge="_c8f7ccmJEduwrYVlQ9zp3w">
+ <position xmi:id="_c8f7c8mJEduwrYVlQ9zp3w" x="207.0" y="312.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlDERlEduP07d3x5Xi-g" guid="_OqnlDERlEduP07d3x5Xi-g" element="_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlDURlEduP07d3x5Xi-g" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlDkRlEduP07d3x5Xi-g" guid="_OqnlDkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlD0RlEduP07d3x5Xi-g" x="170.0" y="128.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_SVYKEURmEduP07d3x5Xi-g" guid="_SVYKEURmEduP07d3x5Xi-g" anchor="_SVYKEERmEduP07d3x5Xi-g _SVYKEkRmEduP07d3x5Xi-g">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_EjyMUU9EEdudU75l2xOQTw" guid="_EjyMUU9EEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_SVYKEERmEduP07d3x5Xi-g" guid="_SVYKEERmEduP07d3x5Xi-g" graphEdge="_SVYKEURmEduP07d3x5Xi-g">
+ <position xmi:id="_SVYKE0RmEduP07d3x5Xi-g" x="239.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_sJ5GckRlEduP07d3x5Xi-g" guid="_sJ5GckRlEduP07d3x5Xi-g" graphEdge="_sJ5GcURlEduP07d3x5Xi-g">
+ <position xmi:id="_i7ZrsERnEduP07d3x5Xi-g" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_IWdC0kRmEduP07d3x5Xi-g" guid="_IWdC0kRmEduP07d3x5Xi-g" graphEdge="_IWdC0URmEduP07d3x5Xi-g">
+ <position xmi:id="_kCRNIERnEduP07d3x5Xi-g" x="0.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlEERlEduP07d3x5Xi-g" guid="_OqnlEERlEduP07d3x5Xi-g" element="_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlEURlEduP07d3x5Xi-g" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OqnlEkRlEduP07d3x5Xi-g" guid="_OqnlEkRlEduP07d3x5Xi-g">
+ <position xmi:id="_OqnlE0RlEduP07d3x5Xi-g" x="184.0" y="208.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_aLbiAcmJEduwrYVlQ9zp3w" guid="_aLbiAcmJEduwrYVlQ9zp3w" anchor="_aLbiAMmJEduwrYVlQ9zp3w _aLbiAsmJEduwrYVlQ9zp3w"/>
+ <anchorage xmi:id="_SVYKEkRmEduP07d3x5Xi-g" guid="_SVYKEkRmEduP07d3x5Xi-g" graphEdge="_SVYKEURmEduP07d3x5Xi-g">
+ <position xmi:id="_SVYKFERmEduP07d3x5Xi-g" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_aLbiAMmJEduwrYVlQ9zp3w" guid="_aLbiAMmJEduwrYVlQ9zp3w" graphEdge="_aLbiAcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_aLbiA8mJEduwrYVlQ9zp3w" x="192.0" y="222.0"/>
+ </anchorage>
+ <anchorage xmi:id="_c8f7csmJEduwrYVlQ9zp3w" guid="_c8f7csmJEduwrYVlQ9zp3w" graphEdge="_c8f7ccmJEduwrYVlQ9zp3w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlFERlEduP07d3x5Xi-g" guid="_OqnlFERlEduP07d3x5Xi-g" element="_d4GesL-FEdqb7N6KIeDL8Q"/>
+ <size xmi:id="_OqnlFURlEduP07d3x5Xi-g" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_QPeqAERlEduP07d3x5Xi-g" guid="_QPeqAERlEduP07d3x5Xi-g">
+ <position xmi:id="_QPeqAURlEduP07d3x5Xi-g" x="45.0" y="12.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_WP4tQURlEduP07d3x5Xi-g" guid="_WP4tQURlEduP07d3x5Xi-g" anchor="_WP4tQERlEduP07d3x5Xi-g _WP4tQkRlEduP07d3x5Xi-g"/>
+ <anchorage xmi:id="_WP4tQERlEduP07d3x5Xi-g" guid="_WP4tQERlEduP07d3x5Xi-g" graphEdge="_WP4tQURlEduP07d3x5Xi-g">
+ <position xmi:id="_WP4tQ0RlEduP07d3x5Xi-g" x="117.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_QPeqAkRlEduP07d3x5Xi-g" guid="_QPeqAkRlEduP07d3x5Xi-g" typeInfo="start node"/>
+ <size xmi:id="_QPeqA0RlEduP07d3x5Xi-g" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_SccQ0ERlEduP07d3x5Xi-g" guid="_SccQ0ERlEduP07d3x5Xi-g">
+ <position xmi:id="_SccQ0URlEduP07d3x5Xi-g" x="93.0" y="51.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_X2KukURlEduP07d3x5Xi-g" guid="_X2KukURlEduP07d3x5Xi-g" anchor="_X2KukERlEduP07d3x5Xi-g _X2KukkRlEduP07d3x5Xi-g"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_IWdC0URmEduP07d3x5Xi-g" guid="_IWdC0URmEduP07d3x5Xi-g" anchor="_IWdC0ERmEduP07d3x5Xi-g _IWdC0kRmEduP07d3x5Xi-g">
+ <waypoints xmi:id="_L37xwMmKEduwrYVlQ9zp3w" x="104.0" y="151.0"/>
+ </contained>
+ <anchorage xmi:id="_X2KukERlEduP07d3x5Xi-g" guid="_X2KukERlEduP07d3x5Xi-g" graphEdge="_X2KukURlEduP07d3x5Xi-g">
+ <position xmi:id="_X2Kuk0RlEduP07d3x5Xi-g" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_WP4tQkRlEduP07d3x5Xi-g" guid="_WP4tQkRlEduP07d3x5Xi-g" graphEdge="_WP4tQURlEduP07d3x5Xi-g">
+ <position xmi:id="_5pI7gMmIEduwrYVlQ9zp3w" x="11.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_IWdC0ERmEduP07d3x5Xi-g" guid="_IWdC0ERmEduP07d3x5Xi-g" graphEdge="_IWdC0URmEduP07d3x5Xi-g">
+ <position xmi:id="_IWdC00RmEduP07d3x5Xi-g" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_TnZ0UsmJEduwrYVlQ9zp3w" guid="_TnZ0UsmJEduwrYVlQ9zp3w" graphEdge="_TnZ0UcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_TnZ0VMmJEduwrYVlQ9zp3w" x="0.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_SccQ0kRlEduP07d3x5Xi-g" guid="_SccQ0kRlEduP07d3x5Xi-g" typeInfo="decision node"/>
+ <size xmi:id="_SccQ00RlEduP07d3x5Xi-g" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mXzzEERlEduP07d3x5Xi-g" name="Add Free Text" guid="_mXzzEERlEduP07d3x5Xi-g">
+ <property xmi:id="_mXzzEURlEduP07d3x5Xi-g" guid="_mXzzEURlEduP07d3x5Xi-g" key="free text" value="[typical change]"/>
+ <position xmi:id="_mXzzEkRlEduP07d3x5Xi-g" x="116.0" y="46.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mXzzE0RlEduP07d3x5Xi-g" guid="_mXzzE0RlEduP07d3x5Xi-g" typeInfo="free text"/>
+ <size xmi:id="_mXzzFERlEduP07d3x5Xi-g" width="93.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JJvg8ERmEduP07d3x5Xi-g" name="Add Free Text" guid="_JJvg8ERmEduP07d3x5Xi-g">
+ <property xmi:id="_JJvg8URmEduP07d3x5Xi-g" guid="_JJvg8URmEduP07d3x5Xi-g" key="free text" value="[trivial change]"/>
+ <position xmi:id="_JJvg8kRmEduP07d3x5Xi-g" x="115.0" y="135.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JJvg80RmEduP07d3x5Xi-g" guid="_JJvg80RmEduP07d3x5Xi-g" typeInfo="free text"/>
+ <size xmi:id="_JJvg9ERmEduP07d3x5Xi-g" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_UF-lAERmEduP07d3x5Xi-g" guid="_UF-lAERmEduP07d3x5Xi-g">
+ <position xmi:id="_UF-lAURmEduP07d3x5Xi-g" x="63.0" y="378.0"/>
+ <anchorage xmi:id="_OSdI4smJEduwrYVlQ9zp3w" guid="_OSdI4smJEduwrYVlQ9zp3w" graphEdge="_OSdI4cmJEduwrYVlQ9zp3w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_UF-lAkRmEduP07d3x5Xi-g" guid="_UF-lAkRmEduP07d3x5Xi-g" typeInfo="end node"/>
+ <size xmi:id="_UF-lA0RmEduP07d3x5Xi-g" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_MRCqwMmJEduwrYVlQ9zp3w" guid="_MRCqwMmJEduwrYVlQ9zp3w">
+ <position xmi:id="_MRCqwcmJEduwrYVlQ9zp3w" x="51.0" y="276.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_OSdI4cmJEduwrYVlQ9zp3w" guid="_OSdI4cmJEduwrYVlQ9zp3w" anchor="_OSdI4MmJEduwrYVlQ9zp3w _OSdI4smJEduwrYVlQ9zp3w"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_TnZ0UcmJEduwrYVlQ9zp3w" guid="_TnZ0UcmJEduwrYVlQ9zp3w" anchor="_TnZ0UMmJEduwrYVlQ9zp3w _TnZ0UsmJEduwrYVlQ9zp3w">
+ <waypoints xmi:id="_fNw-AMmKEduwrYVlQ9zp3w" x="74.0" y="79.0"/>
+ </contained>
+ <anchorage xmi:id="_OSdI4MmJEduwrYVlQ9zp3w" guid="_OSdI4MmJEduwrYVlQ9zp3w" graphEdge="_OSdI4cmJEduwrYVlQ9zp3w">
+ <position xmi:id="_OSdI48mJEduwrYVlQ9zp3w" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_RVFzcsmJEduwrYVlQ9zp3w" guid="_RVFzcsmJEduwrYVlQ9zp3w" graphEdge="_RVFzccmJEduwrYVlQ9zp3w">
+ <position xmi:id="_sJ-yQMmJEduwrYVlQ9zp3w" x="47.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_TnZ0UMmJEduwrYVlQ9zp3w" guid="_TnZ0UMmJEduwrYVlQ9zp3w" graphEdge="_TnZ0UcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_rdqe0MmJEduwrYVlQ9zp3w" x="23.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_MRCqwsmJEduwrYVlQ9zp3w" guid="_MRCqwsmJEduwrYVlQ9zp3w" typeInfo="decision node"/>
+ <size xmi:id="_MRCqw8mJEduwrYVlQ9zp3w" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_P-Lq4MmJEduwrYVlQ9zp3w" guid="_P-Lq4MmJEduwrYVlQ9zp3w">
+ <position xmi:id="_P-Lq4cmJEduwrYVlQ9zp3w" x="211.0" y="276.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_RVFzccmJEduwrYVlQ9zp3w" guid="_RVFzccmJEduwrYVlQ9zp3w" anchor="_RVFzcMmJEduwrYVlQ9zp3w _RVFzcsmJEduwrYVlQ9zp3w"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Q9sAEcmJEduwrYVlQ9zp3w" guid="_Q9sAEcmJEduwrYVlQ9zp3w" anchor="_Q9sAEMmJEduwrYVlQ9zp3w _Q9sAEsmJEduwrYVlQ9zp3w"/>
+ <anchorage xmi:id="_RVFzcMmJEduwrYVlQ9zp3w" guid="_RVFzcMmJEduwrYVlQ9zp3w" graphEdge="_RVFzccmJEduwrYVlQ9zp3w">
+ <position xmi:id="_VAgVQMmJEduwrYVlQ9zp3w" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Q9sAEMmJEduwrYVlQ9zp3w" guid="_Q9sAEMmJEduwrYVlQ9zp3w" graphEdge="_Q9sAEcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_jAJf8MmJEduwrYVlQ9zp3w" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_aLbiAsmJEduwrYVlQ9zp3w" guid="_aLbiAsmJEduwrYVlQ9zp3w" graphEdge="_aLbiAcmJEduwrYVlQ9zp3w">
+ <position xmi:id="_aLbiBMmJEduwrYVlQ9zp3w" x="23.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_P-Lq4smJEduwrYVlQ9zp3w" guid="_P-Lq4smJEduwrYVlQ9zp3w" typeInfo="decision node"/>
+ <size xmi:id="_P-Lq48mJEduwrYVlQ9zp3w" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jrCQAMmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_jrCQAMmJEduwrYVlQ9zp3w">
+ <property xmi:id="_jrCQAcmJEduwrYVlQ9zp3w" guid="_jrCQAcmJEduwrYVlQ9zp3w" key="free text" value="[fail]"/>
+ <position xmi:id="_jrCQAsmJEduwrYVlQ9zp3w" x="236.0" y="304.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_jrCQA8mJEduwrYVlQ9zp3w" guid="_jrCQA8mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_jrCQBMmJEduwrYVlQ9zp3w" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mAr4wMmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_mAr4wMmJEduwrYVlQ9zp3w">
+ <property xmi:id="_mAr4wcmJEduwrYVlQ9zp3w" guid="_mAr4wcmJEduwrYVlQ9zp3w" key="free text" value="[pass]"/>
+ <position xmi:id="_mAr4wsmJEduwrYVlQ9zp3w" x="177.0" y="269.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mAr4w8mJEduwrYVlQ9zp3w" guid="_mAr4w8mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_mAr4xMmJEduwrYVlQ9zp3w" width="30.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_tM7dAMmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_tM7dAMmJEduwrYVlQ9zp3w">
+ <property xmi:id="_tM7dAcmJEduwrYVlQ9zp3w" guid="_tM7dAcmJEduwrYVlQ9zp3w" key="free text" value="[more work to do]"/>
+ <position xmi:id="_tM7dAsmJEduwrYVlQ9zp3w" x="15.0" y="250.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_tM7dA8mJEduwrYVlQ9zp3w" guid="_tM7dA8mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_tM7dBMmJEduwrYVlQ9zp3w" width="61.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_yzpN4MmJEduwrYVlQ9zp3w" name="Add Free Text" guid="_yzpN4MmJEduwrYVlQ9zp3w">
+ <property xmi:id="_yzpN4cmJEduwrYVlQ9zp3w" guid="_yzpN4cmJEduwrYVlQ9zp3w" key="free text" value="[requirement realized]"/>
+ <position xmi:id="_yzpN4smJEduwrYVlQ9zp3w" x="6.0" y="300.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_yzpN48mJEduwrYVlQ9zp3w" guid="_yzpN48mJEduwrYVlQ9zp3w" typeInfo="free text"/>
+ <size xmi:id="_yzpN5MmJEduwrYVlQ9zp3w" width="68.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OqnlAURlEduP07d3x5Xi-g" guid="_OqnlAURlEduP07d3x5Xi-g" presentation="Workflow" element="_h2-iAfimEdmugcVr9AdHjQ"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_h2-iAfimEdmugcVr9AdHjQ" name="develop_solution" guid="_h2-iAfimEdmugcVr9AdHjQ" briefDescription="Design, implement, test and integrate the solution for a requirement within a given context." presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" breakdownElements="_9kUSEFY4EdqI9sTOt2pjHw _9k_AcFY4EdqI9sTOt2pjHw _-YrHMFY4EdqI9sTOt2pjHw _-Y3UcFY4EdqI9sTOt2pjHw _AdllQFY5EdqI9sTOt2pjHw _cL1KIL-FEdqb7N6KIeDL8Q _cMHeAL-FEdqb7N6KIeDL8Q _cMHeAb-FEdqb7N6KIeDL8Q _dAoEIL-FEdqb7N6KIeDL8Q _cnzUcL-FEdqb7N6KIeDL8Q _d4GesL-FEdqb7N6KIeDL8Q _d4k_0L-FEdqb7N6KIeDL8Q _rQ9xIMjkEdqIm8AJUZUQYg _QN4E4ALlEduHjPEP_YPH-g _RfwvEDOvEduqsLmIADMQ9g _KAnAYE9PEdumneEH4I4Yqg _BmbHQE_cEduE1dJ2XtzzkQ _BmbHQU_cEduE1dJ2XtzzkQ">
+ <ownedRules xmi:id="_Prih4DR_EduGhYMJfagftQ" name="diagram" guid="_Prih4DR_EduGhYMJfagftQ" body="ad_image_uri=|publish_ad_image=false|add_image_uri=|publish_add_image=false|wpd_image_uri=|publish_wpd_image=false"/>
+ <presentation xmi:id="_h6zSEPimEdmugcVr9AdHjQ" href="uma://_h6zSEPimEdmugcVr9AdHjQ#_h6zSEPimEdmugcVr9AdHjQ"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.xmi
new file mode 100644
index 0000000..427aee5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/content.xmi
@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BfL5Edm6Nvont3uinw" guid="_mtb_BfL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_B_L5Edm6Nvont3uinw" guid="_mtb_B_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CfL5Edm6Nvont3uinw" guid="_mtb_CfL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CvL5Edm6Nvont3uinw" guid="_mtb_CvL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BvL5Edm6Nvont3uinw" guid="_mtb_BvL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_C_L5Edm6Nvont3uinw" guid="_mtb_C_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb_BPL5Edm6Nvont3uinw" guid="_mtb_BPL5Edm6Nvont3uinw">
+ <mainDescription><h3> Introduction </h3>
+<p> Most activities during a typical iteration in Elaboration phase happen in
+ parallel. Essentially, the main objectives for Elaboration are related to better
+ understanding the requirements, creating and establishing
+ a baseline for the architecture for the system, and mitigating top-priority
+ risks. </p>
+<p> The activities performed in a typical iteration during&nbsp;the
+ Elaboration phase are described below. </p>
+<h4> Manage iteration </h4>
+<p> This activity is performed throughout the project lifecycle.
+ The goal of this activity is to identify risks and issues early enough
+ that they can be mitigated, to establish the goals for the iteration,
+ and to support the development team in reaching these goals. </p>
+<p> The <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> and the team launche the iteration, allocating work items to team
+ members (some project teams will prefer to have members volunteer to perform
+ work). The project manager collaborates with the team to break down the work
+ items into development tasks to perform in that iteration. This provides a more
+ accurate estimate of time to spend on what can be realistically achieved. </p>
+<p> As the iteration runs, the project manager performs
+ monitoring and control of&nbsp;the project by regularly checking the
+ status of work completed, the work to do
+ next, and issues blocking the progress<strong>.
+ </strong>In some projects, this checking occurs
+ in daily meetings, which allows for a&nbsp;more precise&nbsp;understanding
+ of how the work in an iteration is progressing. As
+ needed, the&nbsp;team makes corrections to achieve what was planned. The overall
+ idea is that risks and issues are identified and managed throughout the iteration.
+ And everyone knows the project status.</p>
+<p>The prioritization of work for a given iteration takes place. Project manager,&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>,
+ and the remaining team members agree on what is supposed to be developed during
+ that iteration.</p>
+<p>As in any other iteration assessment, demonstration of implemented functionality
+ planned for that iteration is the key success criterion. During iteration assessments
+ in Elaboration, though, keep the phase objectives in mind. As Elaboration iterations
+ are performed, an executable architecture evolves, and you establish a baseline
+ at the end of the phase. In addition, requirements are better understood and
+ detailed. Essential risks, including the architectural ones, have been mitigated.
+ These results&nbsp;help the project manager produce more accurate estimates
+ for the project schedule and cost.</p>
+<h4> Manage requirements </h4>
+<p> This activity is repeated throughout the project lifecycle.
+ The goal of this activity is to understand and prioritize stakeholder needs
+ and associated requirements for the system, and also to
+ capture these in a form that supports effective communication and collaboration
+ between the stakeholders and development team. </p>
+<p> During the Elaboration phase,
+ requirements can still be captured and outlined as customer needs arise. The
+ prioritization of requirements determines when
+ new requirements are going to be implemented. High-risk, architecturally significant
+ requirements are detailed to the extent necessary to be
+ able to use that information as input to architecture and development
+ activities in the current iteration, plus in planning
+ for the next iteration.</p>
+<p><a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test
+ cases</a> describe which&nbsp;requirements are being tested&nbsp;in that iteration.
+</p>
+<p> <strong>Note: <br />
+ <br/>
+ </strong>The emphasis on finding, outlining and detailing requirements varies
+ from phase to phase. Iterations in Inception and early Elaboration tend to focus
+ more on identifying and outlining requirements in general and on
+ detailing high-priority and architecturally
+ significant requirements. During iterations in late Elaboration and early Construction,
+ the remaining requirements are usually outlined and detailed. </p>
+<h4> Define the architecture </h4>
+<p> This activity is repeated in each iteration in the
+ Elaboration phase. The main&nbsp;goal of this activity is&nbsp;to propose an
+ <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a>
+ that addresses the requirements with high architectural risks, thus providing
+ a solid, yet resilient, foundation on which to build the system functionality.</p>
+<p> The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a>
+ analyzes the architectural constraints, identifies available assets to build
+ the system, defines how the system will be structured, and identifies the initial
+ abstractions and mechanisms that must be provided by the architecture. </p>
+<p> Throughout all of the iterations, the architect: </p>
+<ul>
+
+ <li> Identifies commonalities between different requirements to leverage reuse
+ </li>
+ <li> Defines strategies for achieving requirements related
+ to quality</li>
+ <li> Captures and communicates architectural decisions </li>
+</ul>
+<h4> Develop solution for requirement within context</h4>
+<p> This activity is instantiated multiple times, in parallel, for each development
+ task planned for that iteration. The main goal of this activity is an executable
+ system that provides the incremental quality and functionality for the specified
+ requirements within the specified context. </p>
+<p> As the requirements planned for the iteration are broken down into development
+ tasks, these are assigned by the project managers to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>
+ (some project teams prefer to have team members sign up for development tasks
+ themselves). </p>
+<p> The solution to be developed is for a particular requirement within a context,
+ which reflects the idea of breaking down requirements into development tasks.
+ As an example, a particular use-case scenario within the context of database
+ access could be assigned to a developer; whereas, the same scenario within the
+ user interface and business logic contexts could be assigned to a different
+ developer. In this example, more than one developer is working on a particular
+ piece of functionality to be delivered in a particular iteration. As they develop
+ the requirement within the context they were assigned to, they perform&nbsp;<a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html" guid="_0YuXEclgEdmt3adZL5Dmdw">tests</a>
+ and integrate their work to create <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>.
+</p>
+<h4> Validate build </h4>
+<p> This activity is repeated throughout the project
+ lifecycle. The main goal of this activity is to validate the current increment
+ of the system against the requirements allocated to it. </p>
+<p> The intent is to validate that the high-priority requirements implemented
+ reflect a robust architecture so that remaining requirements can be implemented
+ on top of that architecture. As developer develop the solution for the requirements
+ in a given iteration, the integrated source code is unit-tested. Then, a separate
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">tester</a>
+ conducts system-level testing in parallel with development to make sure that
+ the solution, which is continuously being integrated, matches what is specified
+ in the requirements. Then, the tester defines what techniques to use, what the
+ data input is, what <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/test_suite,_0aDz0MlgEdmt3adZL5Dmdw.html" guid="_0aDz0MlgEdmt3adZL5Dmdw">test
+ suites</a> to create. As tests are performed, defects found are reported and
+ added to the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">work
+ items list</a>, so they can be prioritized and assigned to team members. </p>
+<h4> Ongoing tasks </h4>
+<p> This activity includes tasks that happen throughout the iteration on an ongoing
+ basis but are not necessarily part of a plan. For example, at any time, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any
+ role</a> in the project team can issue a <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">change
+ request</a>, either because there are requests for enhancements, or defects
+ are found. These change requests are part of the work items list and are prioritized
+ and assigned to team members. Anyone can be assigned to make changes that develop
+ enhancements or fix defects. </p>
+<h4>&nbsp; </h4></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.xmi
new file mode 100644
index 0000000..58e08f3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/elaboration_phase_iteration/model.xmi
@@ -0,0 +1,422 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nNCE8PL5Edm6Nvont3uinw" guid="_nNCE8PL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_b7urcPe9Edm6qtYFDZ-o3w" id="_mtb_B_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b7urcfe9Edm6qtYFDZ-o3w" id="_mtb_CfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b7urcve9Edm6qtYFDZ-o3w" id="_mtb_CvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b7urc_e9Edm6qtYFDZ-o3w" id="_mtb_BvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b8fgcPe9Edm6qtYFDZ-o3w" id="_mtb_CPL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_b8x0UPe9Edm6qtYFDZ-o3w" id="_mtb_C_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_cA-X0Pe9Edm6qtYFDZ-o3w" id="_mtb_BPL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_ozOm4EsCEdqj8KrJkiMlfA" id="_mtb_BfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0rWYIMlgEdmt3adZL5Dmdw" name="elaboration_phase_iteration" guid="_0rWYIMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0rWYIclgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0rWYIclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0rWYIslgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0rWYIslgEdmt3adZL5Dmdw" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="_mtb_BfL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_BfL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0rcewMlgEdmt3adZL5Dmdw" name="define_architecture" guid="_0rcewMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0rcewclgEdmt3adZL5Dmdw" name="define_architecture" guid="_0rcewclgEdmt3adZL5Dmdw" presentationName="Define the Architecture" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_B_L5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_B_L5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0rilYMlgEdmt3adZL5Dmdw" name="validate_build" guid="_0rilYMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0rilYclgEdmt3adZL5Dmdw" name="validate_build" guid="_0rilYclgEdmt3adZL5Dmdw" presentationName="Validate Build" hasMultipleOccurrences="true" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_CfL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_CfL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0ruyoMlgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0ruyoMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0ruyoclgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0ruyoclgEdmt3adZL5Dmdw" presentationName="Manage Requirements" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_BvL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_BvL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_Wq_VQPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_Wq_VQPinEdmugcVr9AdHjQ">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_WrXvwPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_WrXvwPinEdmugcVr9AdHjQ" presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ </processElements>
+ <diagrams xmi:id="_rsGFwDSDEduGhYMJfagftQ" guid="_rsGFwDSDEduGhYMJfagftQ">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts0E9EEdudU75l2xOQTw" guid="_z9Ts0E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts0U9EEdudU75l2xOQTw" x="190.0" y="63.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts0k9EEdudU75l2xOQTw" guid="_z9Ts0k9EEdudU75l2xOQTw" anchor="_z9Ts1E9EEdudU75l2xOQTw _z9Ts3E9EEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts009EEdudU75l2xOQTw" guid="_z9Ts009EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_TiPK8DLwEdueZPye-FaNgA"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_z9Ts1E9EEdudU75l2xOQTw" guid="_z9Ts1E9EEdudU75l2xOQTw" graphEdge="_z9Ts0k9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts1U9EEdudU75l2xOQTw" guid="_z9Ts1U9EEdudU75l2xOQTw" graphEdge="_z9TtBk9EEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts1k9EEdudU75l2xOQTw" guid="_z9Ts1k9EEdudU75l2xOQTw"/>
+ <size xmi:id="_z9Ts109EEdudU75l2xOQTw" width="112.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts2E9EEdudU75l2xOQTw" guid="_z9Ts2E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts2U9EEdudU75l2xOQTw" x="200.0" y="150.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts2k9EEdudU75l2xOQTw" guid="_z9Ts2k9EEdudU75l2xOQTw" anchor="_z9Ts3k9EEdudU75l2xOQTw _z9TtS09EEdudU75l2xOQTw">
+ <waypoints xmi:id="_z9Ts209EEdudU75l2xOQTw" x="245.0" y="242.0"/>
+ </contained>
+ <anchorage xmi:id="_z9Ts3E9EEdudU75l2xOQTw" guid="_z9Ts3E9EEdudU75l2xOQTw" graphEdge="_z9Ts0k9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts3U9EEdudU75l2xOQTw" guid="_z9Ts3U9EEdudU75l2xOQTw" graphEdge="_z9TtEU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts3k9EEdudU75l2xOQTw" guid="_z9Ts3k9EEdudU75l2xOQTw" graphEdge="_z9Ts2k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts309EEdudU75l2xOQTw" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts4E9EEdudU75l2xOQTw" guid="_z9Ts4E9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts4U9EEdudU75l2xOQTw" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts4k9EEdudU75l2xOQTw" guid="_z9Ts4k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts409EEdudU75l2xOQTw" x="50.0" y="320.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts5E9EEdudU75l2xOQTw" guid="_z9Ts5E9EEdudU75l2xOQTw" anchor="_z9Ts5k9EEdudU75l2xOQTw _z9TtO09EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_wHZQ8c6VEdu_q7xi9VPgyA" guid="_wHZQ8c6VEdu_q7xi9VPgyA" anchor="_wHZQ8M6VEdu_q7xi9VPgyA _wHZQ8s6VEdu_q7xi9VPgyA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_wHZQ886VEdu_q7xi9VPgyA" guid="_wHZQ886VEdu_q7xi9VPgyA">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_c84V8MmJEduwrYVlQ9zp3w"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_z9Ts5U9EEdudU75l2xOQTw" guid="_z9Ts5U9EEdudU75l2xOQTw" graphEdge="_z9TtKU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts5k9EEdudU75l2xOQTw" guid="_z9Ts5k9EEdudU75l2xOQTw" graphEdge="_z9Ts5E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts509EEdudU75l2xOQTw" x="101.0" y="286.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wHZQ8M6VEdu_q7xi9VPgyA" guid="_wHZQ8M6VEdu_q7xi9VPgyA" graphEdge="_wHZQ8c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts6E9EEdudU75l2xOQTw" guid="_z9Ts6E9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts6U9EEdudU75l2xOQTw" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts6k9EEdudU75l2xOQTw" guid="_z9Ts6k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts609EEdudU75l2xOQTw" x="201.0" y="304.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts7E9EEdudU75l2xOQTw" guid="_z9Ts7E9EEdudU75l2xOQTw" anchor="_z9Ts709EEdudU75l2xOQTw _z9Ts-E9EEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts7U9EEdudU75l2xOQTw" guid="_z9Ts7U9EEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_z9Ts7k9EEdudU75l2xOQTw" guid="_z9Ts7k9EEdudU75l2xOQTw" graphEdge="_z9TtKE9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts709EEdudU75l2xOQTw" guid="_z9Ts709EEdudU75l2xOQTw" graphEdge="_z9Ts7E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts8E9EEdudU75l2xOQTw" x="239.0" y="284.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts8U9EEdudU75l2xOQTw" guid="_z9Ts8U9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts8k9EEdudU75l2xOQTw" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts809EEdudU75l2xOQTw" guid="_z9Ts809EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts9E9EEdudU75l2xOQTw" x="213.0" y="368.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts9U9EEdudU75l2xOQTw" guid="_z9Ts9U9EEdudU75l2xOQTw" anchor="_z9Ts9k9EEdudU75l2xOQTw _z9TtPU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts9k9EEdudU75l2xOQTw" guid="_z9Ts9k9EEdudU75l2xOQTw" graphEdge="_z9Ts9U9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts909EEdudU75l2xOQTw" x="374.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9Ts-E9EEdudU75l2xOQTw" guid="_z9Ts-E9EEdudU75l2xOQTw" graphEdge="_z9Ts7E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9Ts-U9EEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wHZQ8s6VEdu_q7xi9VPgyA" guid="_wHZQ8s6VEdu_q7xi9VPgyA" graphEdge="_wHZQ8c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9Ts-k9EEdudU75l2xOQTw" guid="_z9Ts-k9EEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_d4GesL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_z9Ts-09EEdudU75l2xOQTw" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9Ts_E9EEdudU75l2xOQTw" guid="_z9Ts_E9EEdudU75l2xOQTw" briefDescription="_QPeqAERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9Ts_U9EEdudU75l2xOQTw" x="46.0" y="82.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9Ts_k9EEdudU75l2xOQTw" guid="_z9Ts_k9EEdudU75l2xOQTw" anchor="_z9Ts_09EEdudU75l2xOQTw _z9TtB09EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9Ts_09EEdudU75l2xOQTw" guid="_z9Ts_09EEdudU75l2xOQTw" graphEdge="_z9Ts_k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtAE9EEdudU75l2xOQTw" x="117.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtAU9EEdudU75l2xOQTw" guid="_z9TtAU9EEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_z9TtAk9EEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtA09EEdudU75l2xOQTw" guid="_z9TtA09EEdudU75l2xOQTw" briefDescription="_RCR_8ERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtBE9EEdudU75l2xOQTw" x="105.0" y="81.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtBU9EEdudU75l2xOQTw" guid="_z9TtBU9EEdudU75l2xOQTw" anchor="_z9TtCU9EEdudU75l2xOQTw _z9TtFE9EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtBk9EEdudU75l2xOQTw" guid="_z9TtBk9EEdudU75l2xOQTw" anchor="_z9TtC09EEdudU75l2xOQTw _z9Ts1U9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9TtB09EEdudU75l2xOQTw" guid="_z9TtB09EEdudU75l2xOQTw" graphEdge="_z9Ts_k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtCE9EEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtCU9EEdudU75l2xOQTw" guid="_z9TtCU9EEdudU75l2xOQTw" graphEdge="_z9TtBU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtCk9EEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtC09EEdudU75l2xOQTw" guid="_z9TtC09EEdudU75l2xOQTw" graphEdge="_z9TtBk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtDE9EEdudU75l2xOQTw" x="23.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtDU9EEdudU75l2xOQTw" guid="_z9TtDU9EEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_z9TtDk9EEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtD09EEdudU75l2xOQTw" guid="_z9TtD09EEdudU75l2xOQTw" briefDescription="_SccQ0ERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtEE9EEdudU75l2xOQTw" x="105.0" y="161.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtEU9EEdudU75l2xOQTw" guid="_z9TtEU9EEdudU75l2xOQTw" anchor="_z9TtFk9EEdudU75l2xOQTw _z9Ts3U9EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtEk9EEdudU75l2xOQTw" guid="_z9TtEk9EEdudU75l2xOQTw" anchor="_z9TtGE9EEdudU75l2xOQTw _z9TtTU9EEdudU75l2xOQTw">
+ <waypoints xmi:id="_z9TtE09EEdudU75l2xOQTw" x="116.0" y="242.0"/>
+ </contained>
+ <anchorage xmi:id="_z9TtFE9EEdudU75l2xOQTw" guid="_z9TtFE9EEdudU75l2xOQTw" graphEdge="_z9TtBU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtFU9EEdudU75l2xOQTw" x="11.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtFk9EEdudU75l2xOQTw" guid="_z9TtFk9EEdudU75l2xOQTw" graphEdge="_z9TtEU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtF09EEdudU75l2xOQTw" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtGE9EEdudU75l2xOQTw" guid="_z9TtGE9EEdudU75l2xOQTw" graphEdge="_z9TtEk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtGU9EEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtGk9EEdudU75l2xOQTw" guid="_z9TtGk9EEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_z9TtG09EEdudU75l2xOQTw" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtHE9EEdudU75l2xOQTw" name="Add Free Text" guid="_z9TtHE9EEdudU75l2xOQTw" briefDescription="_jEpZMERlEduP07d3x5Xi-g">
+ <property xmi:id="_z9TtHU9EEdudU75l2xOQTw" guid="_z9TtHU9EEdudU75l2xOQTw" key="free text" value="[major change]"/>
+ <position xmi:id="_z9TtHk9EEdudU75l2xOQTw" x="129.0" y="76.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtH09EEdudU75l2xOQTw" guid="_z9TtH09EEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_z9TtIE9EEdudU75l2xOQTw" width="71.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtIU9EEdudU75l2xOQTw" name="Add Free Text" guid="_z9TtIU9EEdudU75l2xOQTw" briefDescription="_mXzzEERlEduP07d3x5Xi-g">
+ <property xmi:id="_z9TtIk9EEdudU75l2xOQTw" guid="_z9TtIk9EEdudU75l2xOQTw" key="free text" value="[small change]"/>
+ <position xmi:id="_z9TtI09EEdudU75l2xOQTw" x="128.0" y="156.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtJE9EEdudU75l2xOQTw" guid="_z9TtJE9EEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_z9TtJU9EEdudU75l2xOQTw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtJk9EEdudU75l2xOQTw" guid="_z9TtJk9EEdudU75l2xOQTw" briefDescription="_pfsxEERlEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtJ09EEdudU75l2xOQTw" x="64.0" y="283.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtKE9EEdudU75l2xOQTw" guid="_z9TtKE9EEdudU75l2xOQTw" anchor="_z9TtK09EEdudU75l2xOQTw _z9Ts7k9EEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtKU9EEdudU75l2xOQTw" guid="_z9TtKU9EEdudU75l2xOQTw" anchor="_z9TtLU9EEdudU75l2xOQTw _z9Ts5U9EEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_z9TtKk9EEdudU75l2xOQTw" guid="_z9TtKk9EEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_z9TtK09EEdudU75l2xOQTw" guid="_z9TtK09EEdudU75l2xOQTw" graphEdge="_z9TtKE9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtLE9EEdudU75l2xOQTw" x="201.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtLU9EEdudU75l2xOQTw" guid="_z9TtLU9EEdudU75l2xOQTw" graphEdge="_z9TtKU9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtLk9EEdudU75l2xOQTw" x="38.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtL09EEdudU75l2xOQTw" guid="_z9TtL09EEdudU75l2xOQTw" graphEdge="_z9TtSk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtME9EEdudU75l2xOQTw" x="116.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtMU9EEdudU75l2xOQTw" guid="_z9TtMU9EEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z9TtMk9EEdudU75l2xOQTw" width="262.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtM09EEdudU75l2xOQTw" name="Add Free Text" guid="_z9TtM09EEdudU75l2xOQTw" briefDescription="_JJvg8ERmEduP07d3x5Xi-g">
+ <property xmi:id="_z9TtNE9EEdudU75l2xOQTw" guid="_z9TtNE9EEdudU75l2xOQTw" key="free text" value="[trivial change]"/>
+ <position xmi:id="_z9TtNU9EEdudU75l2xOQTw" x="120.0" y="204.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtNk9EEdudU75l2xOQTw" guid="_z9TtNk9EEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_z9TtN09EEdudU75l2xOQTw" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtOE9EEdudU75l2xOQTw" guid="_z9TtOE9EEdudU75l2xOQTw" briefDescription="_MViukERmEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtOU9EEdudU75l2xOQTw" x="64.0" y="433.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtOk9EEdudU75l2xOQTw" guid="_z9TtOk9EEdudU75l2xOQTw" anchor="_z9TtP09EEdudU75l2xOQTw _z9TtRU9EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9TtO09EEdudU75l2xOQTw" guid="_z9TtO09EEdudU75l2xOQTw" graphEdge="_z9Ts5E9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtPE9EEdudU75l2xOQTw" x="39.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtPU9EEdudU75l2xOQTw" guid="_z9TtPU9EEdudU75l2xOQTw" graphEdge="_z9Ts9U9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtPk9EEdudU75l2xOQTw" x="199.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtP09EEdudU75l2xOQTw" guid="_z9TtP09EEdudU75l2xOQTw" graphEdge="_z9TtOk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtQE9EEdudU75l2xOQTw" x="129.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtQU9EEdudU75l2xOQTw" guid="_z9TtQU9EEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_z9TtQk9EEdudU75l2xOQTw" width="274.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtQ09EEdudU75l2xOQTw" guid="_z9TtQ09EEdudU75l2xOQTw" briefDescription="_UF-lAERmEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtRE9EEdudU75l2xOQTw" x="182.0" y="461.0"/>
+ <anchorage xmi:id="_z9TtRU9EEdudU75l2xOQTw" guid="_z9TtRU9EEdudU75l2xOQTw" graphEdge="_z9TtOk9EEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtRk9EEdudU75l2xOQTw" guid="_z9TtRk9EEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_z9TtR09EEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_z9TtSE9EEdudU75l2xOQTw" guid="_z9TtSE9EEdudU75l2xOQTw" briefDescription="_gEnEwERnEduP07d3x5Xi-g">
+ <position xmi:id="_z9TtSU9EEdudU75l2xOQTw" x="167.0" y="231.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_z9TtSk9EEdudU75l2xOQTw" guid="_z9TtSk9EEdudU75l2xOQTw" anchor="_z9TtT09EEdudU75l2xOQTw _z9TtL09EEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_z9TtS09EEdudU75l2xOQTw" guid="_z9TtS09EEdudU75l2xOQTw" graphEdge="_z9Ts2k9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtTE9EEdudU75l2xOQTw" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtTU9EEdudU75l2xOQTw" guid="_z9TtTU9EEdudU75l2xOQTw" graphEdge="_z9TtEk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtTk9EEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_z9TtT09EEdudU75l2xOQTw" guid="_z9TtT09EEdudU75l2xOQTw" graphEdge="_z9TtSk9EEdudU75l2xOQTw">
+ <position xmi:id="_z9TtUE9EEdudU75l2xOQTw" x="13.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_z9TtUU9EEdudU75l2xOQTw" guid="_z9TtUU9EEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_z9TtUk9EEdudU75l2xOQTw" width="28.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_rsGGPDSDEduGhYMJfagftQ" guid="_rsGGPDSDEduGhYMJfagftQ" presentation="Workflow" element="_WrXvwPinEdmugcVr9AdHjQ"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_S_IQ4CliEdqjQsaFX0CJTw" name="ongoing_tasks" guid="_S_IQ4CliEdqjQsaFX0CJTw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_TAVx0CliEdqjQsaFX0CJTw" name="ongoing_tasks" guid="_TAVx0CliEdqjQsaFX0CJTw" presentationName="Ongoing Tasks" isPlanned="false" superActivities="_0sTaYMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <diagrams xmi:id="_ohS1wNIWEdm9Cql_SeWu_A" guid="_ohS1wNIWEdm9Cql_SeWu_A">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1wdIWEdm9Cql_SeWu_A" guid="_ohS1wdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1wtIWEdm9Cql_SeWu_A" x="338.0" y="74.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__10NIdSIEdqANo9Ox5ktZQ" guid="__10NIdSIEdqANo9Ox5ktZQ" anchor="__10NINSIEdqANo9Ox5ktZQ __10NItSIEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="__cmb4tSIEdqANo9Ox5ktZQ" guid="__cmb4tSIEdqANo9Ox5ktZQ" graphEdge="__cmb4dSIEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="__10NINSIEdqANo9Ox5ktZQ" guid="__10NINSIEdqANo9Ox5ktZQ" graphEdge="__10NIdSIEdqANo9Ox5ktZQ">
+ <position xmi:id="__10NI9SIEdqANo9Ox5ktZQ" x="449.0" y="218.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1w9IWEdm9Cql_SeWu_A" guid="_ohS1w9IWEdm9Cql_SeWu_A" element="_0rWYIslgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS1xNIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1xdIWEdm9Cql_SeWu_A" guid="_ohS1xdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1xtIWEdm9Cql_SeWu_A" x="-58.0" y="81.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5REOER_bEdq3EKSIdbj-MA" guid="_5REOER_bEdq3EKSIdbj-MA" anchor="_5REOEB_bEdq3EKSIdbj-MA _5REOEh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_43sr0h_bEdq3EKSIdbj-MA" guid="_43sr0h_bEdq3EKSIdbj-MA" graphEdge="_43sr0R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_43sr1B_bEdq3EKSIdbj-MA" x="75.0" y="-62.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5REOEB_bEdq3EKSIdbj-MA" guid="_5REOEB_bEdq3EKSIdbj-MA" graphEdge="_5REOER_bEdq3EKSIdbj-MA">
+ <position xmi:id="_5REOEx_bEdq3EKSIdbj-MA" x="78.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1x9IWEdm9Cql_SeWu_A" guid="_ohS1x9IWEdm9Cql_SeWu_A" element="_0ruyoclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS1yNIWEdm9Cql_SeWu_A" width="236.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1ydIWEdm9Cql_SeWu_A" guid="_ohS1ydIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1ytIWEdm9Cql_SeWu_A" x="63.0" y="120.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_55VvAR_bEdq3EKSIdbj-MA" guid="_55VvAR_bEdq3EKSIdbj-MA" anchor="_55VvAB_bEdq3EKSIdbj-MA _55VvAh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_5mRCAh_bEdq3EKSIdbj-MA" guid="_5mRCAh_bEdq3EKSIdbj-MA" graphEdge="_5mRCAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_5mRCBB_bEdq3EKSIdbj-MA" x="18.0" y="-88.0"/>
+ </anchorage>
+ <anchorage xmi:id="_55VvAB_bEdq3EKSIdbj-MA" guid="_55VvAB_bEdq3EKSIdbj-MA" graphEdge="_55VvAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_55VvAx_bEdq3EKSIdbj-MA" x="32.0" y="26.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1y9IWEdm9Cql_SeWu_A" guid="_ohS1y9IWEdm9Cql_SeWu_A" element="_0rcewclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS1zNIWEdm9Cql_SeWu_A" width="146.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS1zdIWEdm9Cql_SeWu_A" guid="_ohS1zdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS1ztIWEdm9Cql_SeWu_A" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS1z9IWEdm9Cql_SeWu_A" guid="_ohS1z9IWEdm9Cql_SeWu_A"/>
+ <size xmi:id="_ohS10NIWEdm9Cql_SeWu_A" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS10dIWEdm9Cql_SeWu_A" guid="_ohS10dIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS10tIWEdm9Cql_SeWu_A" x="245.0" y="221.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mDxSccmzEdqibaSI8nt1Ng" guid="_mDxSccmzEdqibaSI8nt1Ng" anchor="_mDxScMmzEdqibaSI8nt1Ng _mDxScsmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_lukegsmzEdqibaSI8nt1Ng" guid="_lukegsmzEdqibaSI8nt1Ng" graphEdge="_lukegcmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_mDxScMmzEdqibaSI8nt1Ng" guid="_mDxScMmzEdqibaSI8nt1Ng" graphEdge="_mDxSccmzEdqibaSI8nt1Ng">
+ <position xmi:id="_mDxSc8mzEdqibaSI8nt1Ng" x="612.0" y="243.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS109IWEdm9Cql_SeWu_A" guid="_ohS109IWEdm9Cql_SeWu_A" element="_0rilYclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ohS11NIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ohS11dIWEdm9Cql_SeWu_A" guid="_ohS11dIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ohS11tIWEdm9Cql_SeWu_A" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_82IQQR_bEdq3EKSIdbj-MA" guid="_82IQQR_bEdq3EKSIdbj-MA" anchor="_82IQQB_bEdq3EKSIdbj-MA _82IQQh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_82IQQB_bEdq3EKSIdbj-MA" guid="_82IQQB_bEdq3EKSIdbj-MA" graphEdge="_82IQQR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_82IQQx_bEdq3EKSIdbj-MA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS119IWEdm9Cql_SeWu_A" guid="_ohS119IWEdm9Cql_SeWu_A"/>
+ <size xmi:id="_ohS12NIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5VDG0NIWEdm9Cql_SeWu_A" guid="_5VDG0NIWEdm9Cql_SeWu_A">
+ <position xmi:id="_5VDG0dIWEdm9Cql_SeWu_A" x="309.0" y="351.0"/>
+ <anchorage xmi:id="_BQKrQtSJEdqANo9Ox5ktZQ" guid="_BQKrQtSJEdqANo9Ox5ktZQ" graphEdge="_BQKrQdSJEdqANo9Ox5ktZQ"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5VDG0tIWEdm9Cql_SeWu_A" guid="_5VDG0tIWEdm9Cql_SeWu_A" typeInfo="end node"/>
+ <size xmi:id="_5VDG09IWEdm9Cql_SeWu_A" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_vsKsEPfpEdmRMap9i-t5rw" guid="_vsKsEPfpEdmRMap9i-t5rw">
+ <position xmi:id="_vsKsEffpEdmRMap9i-t5rw" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_u3pLsfiVEdmiedAQWF94Dw" guid="_u3pLsfiVEdmiedAQWF94Dw" anchor="_u3pLsPiVEdmiedAQWF94Dw"/>
+ <anchorage xmi:id="_u3pLsPiVEdmiedAQWF94Dw" guid="_u3pLsPiVEdmiedAQWF94Dw" graphEdge="_u3pLsfiVEdmiedAQWF94Dw">
+ <position xmi:id="_u3pLs_iVEdmiedAQWF94Dw" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_vsKsEvfpEdmRMap9i-t5rw" guid="_vsKsEvfpEdmRMap9i-t5rw"/>
+ <size xmi:id="_vsKsE_fpEdmRMap9i-t5rw" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_cbi-oPinEdmugcVr9AdHjQ" guid="_cbi-oPinEdmugcVr9AdHjQ">
+ <position xmi:id="_cbi-ofinEdmugcVr9AdHjQ" x="159.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_lPt_UcmzEdqibaSI8nt1Ng" guid="_lPt_UcmzEdqibaSI8nt1Ng" anchor="_lPt_UMmzEdqibaSI8nt1Ng _lPt_UsmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_kx6pAsmzEdqibaSI8nt1Ng" guid="_kx6pAsmzEdqibaSI8nt1Ng" graphEdge="_kx6pAcmzEdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_lPt_UMmzEdqibaSI8nt1Ng" guid="_lPt_UMmzEdqibaSI8nt1Ng" graphEdge="_lPt_UcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_lPt_U8mzEdqibaSI8nt1Ng" x="466.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_cbi-ovinEdmugcVr9AdHjQ" guid="_cbi-ovinEdmugcVr9AdHjQ" element="_WrXvwPinEdmugcVr9AdHjQ"/>
+ <size xmi:id="_cbi-o_inEdmugcVr9AdHjQ" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_pKjjgPr6EdmyhNQr5STrZQ" guid="_pKjjgPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_pKjjgfr6EdmyhNQr5STrZQ" x="11.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_43sr0R_bEdq3EKSIdbj-MA" guid="_43sr0R_bEdq3EKSIdbj-MA" anchor="_43sr0B_bEdq3EKSIdbj-MA _43sr0h_bEdq3EKSIdbj-MA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5mRCAR_bEdq3EKSIdbj-MA" guid="_5mRCAR_bEdq3EKSIdbj-MA" anchor="_5mRCAB_bEdq3EKSIdbj-MA _5mRCAh_bEdq3EKSIdbj-MA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_khkz8SliEdqjQsaFX0CJTw" guid="_khkz8SliEdqjQsaFX0CJTw" anchor="_khkz8CliEdqjQsaFX0CJTw _khkz8iliEdqjQsaFX0CJTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_kx6pAcmzEdqibaSI8nt1Ng" guid="_kx6pAcmzEdqibaSI8nt1Ng" anchor="_kx6pAMmzEdqibaSI8nt1Ng _kx6pAsmzEdqibaSI8nt1Ng"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_lukegcmzEdqibaSI8nt1Ng" guid="_lukegcmzEdqibaSI8nt1Ng" anchor="_lukegMmzEdqibaSI8nt1Ng _lukegsmzEdqibaSI8nt1Ng"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__cmb4dSIEdqANo9Ox5ktZQ" guid="__cmb4dSIEdqANo9Ox5ktZQ" anchor="__cmb4NSIEdqANo9Ox5ktZQ __cmb4tSIEdqANo9Ox5ktZQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_AMu4UdSJEdqANo9Ox5ktZQ" guid="_AMu4UdSJEdqANo9Ox5ktZQ" anchor="_AMu4UNSJEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_3eQzsh_bEdq3EKSIdbj-MA" guid="_3eQzsh_bEdq3EKSIdbj-MA" graphEdge="_3eQzsR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_n8v6UCliEdqjQsaFX0CJTw" x="312.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_43sr0B_bEdq3EKSIdbj-MA" guid="_43sr0B_bEdq3EKSIdbj-MA" graphEdge="_43sr0R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_jKl-0NSIEdqANo9Ox5ktZQ" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5mRCAB_bEdq3EKSIdbj-MA" guid="_5mRCAB_bEdq3EKSIdbj-MA" graphEdge="_5mRCAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_6GkyYNSIEdqANo9Ox5ktZQ" x="125.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_khkz8CliEdqjQsaFX0CJTw" guid="_khkz8CliEdqjQsaFX0CJTw" graphEdge="_khkz8SliEdqjQsaFX0CJTw">
+ <position xmi:id="_51qF0EqaEduiL77U_PmnmA" x="474.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_kx6pAMmzEdqibaSI8nt1Ng" guid="_kx6pAMmzEdqibaSI8nt1Ng" graphEdge="_kx6pAcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_oO8pgNSIEdqANo9Ox5ktZQ" x="197.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lukegMmzEdqibaSI8nt1Ng" guid="_lukegMmzEdqibaSI8nt1Ng" graphEdge="_lukegcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_sfVgoNSIEdqANo9Ox5ktZQ" x="276.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__cmb4NSIEdqANo9Ox5ktZQ" guid="__cmb4NSIEdqANo9Ox5ktZQ" graphEdge="__cmb4dSIEdqANo9Ox5ktZQ">
+ <position xmi:id="__cmb49SIEdqANo9Ox5ktZQ" x="369.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_AMu4UNSJEdqANo9Ox5ktZQ" guid="_AMu4UNSJEdqANo9Ox5ktZQ" graphEdge="_AMu4UdSJEdqANo9Ox5ktZQ">
+ <position xmi:id="_Fh4_INSJEdqANo9Ox5ktZQ" x="440.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_pKjjgvr6EdmyhNQr5STrZQ" guid="_pKjjgvr6EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_pKjjg_r6EdmyhNQr5STrZQ" width="563.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_zkKboPr6EdmyhNQr5STrZQ" guid="_zkKboPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_zkKbofr6EdmyhNQr5STrZQ" x="313.0" y="6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3eQzsR_bEdq3EKSIdbj-MA" guid="_3eQzsR_bEdq3EKSIdbj-MA" anchor="_3eQzsB_bEdq3EKSIdbj-MA _3eQzsh_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_3eQzsB_bEdq3EKSIdbj-MA" guid="_3eQzsB_bEdq3EKSIdbj-MA" graphEdge="_3eQzsR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_3eQzsx_bEdq3EKSIdbj-MA" x="-30.0" y="13.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_zkKbovr6EdmyhNQr5STrZQ" guid="_zkKbovr6EdmyhNQr5STrZQ" typeInfo="start node"/>
+ <size xmi:id="_zkKbo_r6EdmyhNQr5STrZQ" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_045Z8Pr6EdmyhNQr5STrZQ" guid="_045Z8Pr6EdmyhNQr5STrZQ">
+ <position xmi:id="_045Z8fr6EdmyhNQr5STrZQ" x="6.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_BQKrQdSJEdqANo9Ox5ktZQ" guid="_BQKrQdSJEdqANo9Ox5ktZQ" anchor="_BQKrQNSJEdqANo9Ox5ktZQ _BQKrQtSJEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_5REOEh_bEdq3EKSIdbj-MA" guid="_5REOEh_bEdq3EKSIdbj-MA" graphEdge="_5REOER_bEdq3EKSIdbj-MA">
+ <position xmi:id="_ihuA8NSIEdqANo9Ox5ktZQ" x="53.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_55VvAh_bEdq3EKSIdbj-MA" guid="_55VvAh_bEdq3EKSIdbj-MA" graphEdge="_55VvAR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_779msNSIEdqANo9Ox5ktZQ" x="130.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_82IQQh_bEdq3EKSIdbj-MA" guid="_82IQQh_bEdq3EKSIdbj-MA" graphEdge="_82IQQR_bEdq3EKSIdbj-MA">
+ <position xmi:id="_eMr2MB_lEdq3EKSIdbj-MA" x="647.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lPt_UsmzEdqibaSI8nt1Ng" guid="_lPt_UsmzEdqibaSI8nt1Ng" graphEdge="_lPt_UcmzEdqibaSI8nt1Ng">
+ <position xmi:id="_ow8jUNSIEdqANo9Ox5ktZQ" x="201.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_mDxScsmzEdqibaSI8nt1Ng" guid="_mDxScsmzEdqibaSI8nt1Ng" graphEdge="_mDxSccmzEdqibaSI8nt1Ng">
+ <position xmi:id="_9SfUwNSIEdqANo9Ox5ktZQ" x="280.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__10NItSIEdqANo9Ox5ktZQ" guid="__10NItSIEdqANo9Ox5ktZQ" graphEdge="__10NIdSIEdqANo9Ox5ktZQ">
+ <position xmi:id="__10NJNSIEdqANo9Ox5ktZQ" x="373.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_AoJB8tSJEdqANo9Ox5ktZQ" guid="_AoJB8tSJEdqANo9Ox5ktZQ">
+ <position xmi:id="_O7ytwNSJEdqANo9Ox5ktZQ" x="445.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_BQKrQNSJEdqANo9Ox5ktZQ" guid="_BQKrQNSJEdqANo9Ox5ktZQ" graphEdge="_BQKrQdSJEdqANo9Ox5ktZQ">
+ <position xmi:id="_BQKrQ9SJEdqANo9Ox5ktZQ" x="315.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-1HpckqaEduiL77U_PmnmA" guid="_-1HpckqaEduiL77U_PmnmA" graphEdge="_-1HpcUqaEduiL77U_PmnmA">
+ <position xmi:id="_-1HpdEqaEduiL77U_PmnmA" x="480.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_045Z8vr6EdmyhNQr5STrZQ" guid="_045Z8vr6EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_045Z8_r6EdmyhNQr5STrZQ" width="578.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_TCxawCliEdqjQsaFX0CJTw" guid="_TCxawCliEdqjQsaFX0CJTw">
+ <position xmi:id="_TCxawSliEdqjQsaFX0CJTw" x="436.0" y="164.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-1HpcUqaEduiL77U_PmnmA" guid="_-1HpcUqaEduiL77U_PmnmA" anchor="_-1HpcEqaEduiL77U_PmnmA _-1HpckqaEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_khkz8iliEdqjQsaFX0CJTw" guid="_khkz8iliEdqjQsaFX0CJTw" graphEdge="_khkz8SliEdqjQsaFX0CJTw">
+ <position xmi:id="_khkz9CliEdqjQsaFX0CJTw" x="651.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-1HpcEqaEduiL77U_PmnmA" guid="_-1HpcEqaEduiL77U_PmnmA" graphEdge="_-1HpcUqaEduiL77U_PmnmA">
+ <position xmi:id="_-1Hpc0qaEduiL77U_PmnmA" x="548.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_TCxawiliEdqjQsaFX0CJTw" guid="_TCxawiliEdqjQsaFX0CJTw" element="_TAVx0CliEdqjQsaFX0CJTw"/>
+ <size xmi:id="_TCxawyliEdqjQsaFX0CJTw" width="100.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ohS13dIWEdm9Cql_SeWu_A" guid="_ohS13dIWEdm9Cql_SeWu_A" presentation="Workflow" element="_0sTaYMlgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0sTaYMlgEdmt3adZL5Dmdw" name="elaboration_phase_iteration" guid="_0sTaYMlgEdmt3adZL5Dmdw" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Elaboration phase. Each activity and related goals are described." presentationName="Elaboration Phase Iteration" isRepeatable="true" breakdownElements="_0rWYIslgEdmt3adZL5Dmdw _0ruyoclgEdmt3adZL5Dmdw _0rcewclgEdmt3adZL5Dmdw _WrXvwPinEdmugcVr9AdHjQ _0rilYclgEdmt3adZL5Dmdw _TAVx0CliEdqjQsaFX0CJTw">
+ <presentation xmi:id="_mtb_BPL5Edm6Nvont3uinw" href="uma://_mtb_BfL5Edm6Nvont3uinw#_mtb_BPL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/inception_phase_iteration/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/inception_phase_iteration/content.xmi
new file mode 100644
index 0000000..982faec
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/inception_phase_iteration/content.xmi
@@ -0,0 +1,124 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-7PL5Edm6Nvont3uinw" guid="_mtb-7PL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-7_L5Edm6Nvont3uinw" guid="_mtb-7_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-8PL5Edm6Nvont3uinw" guid="_mtb-8PL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb-8vL5Edm6Nvont3uinw" guid="_mtb-8vL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb-6_L5Edm6Nvont3uinw" guid="_mtb-6_L5Edm6Nvont3uinw">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The project starts with the assumption that the business case has been created, the <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> has been identified, the team (at least for the first iteration) has been defined, the development
+ environment (including tools and infrastructure) is in place, and the process to be followed is the <a
+ class="elementlinkwithusertext"
+ href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">delivery process</a> suggested by OpenUP/Basic. The number and length of each Inception
+ iteration will vary, depending upon the needs of the project.
+</p>
+<p>
+ In the next sections we describe the activities performed in a typical iteration during Inception phase.
+</p>
+<h4>
+ Initiate project
+</h4>
+<p>
+ This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity
+ is to establish the vision for the project and the project plan at a high level of granularity.
+</p>
+<p>
+ The people in the roles involved at this time collaborate to perform this activity:
+</p>
+<ul>
+ <li>
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html"
+ guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholder</a> roles work together to define the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> for the project, capturing the customer needs and features for the system
+ under development. Needs and features are captured to the extent required to reach agreement about the scope of the
+ project.
+ </li>
+ <li>
+ Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level <a
+ class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html"
+ guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases and time-boxed iterations for each phase. This
+ plan and the allocation of staff to the project evolve throughout the phases to reflect the project pace, as
+ necessary.
+ </li>
+</ul>
+<h4>
+ Manage iteration
+</h4>
+<p>
+ This activity is about the ongoing work performed by the project manager and the development team to initiate and
+ conduct a given iteration. It consists of status reporting, handling of exceptions and problems, identifying risks, and
+ reprioritizing work, as needed.
+</p>
+<p>
+ At the end of the iteration, the project manager conducts a&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html"
+ guid="_0bA2EMlgEdmt3adZL5Dmdw">status assessment</a> with the development team and stakeholders.
+</p>
+<p>
+ If the iteration end coincides with the phase end, meeting the objectives for that phase should be used as success
+ criteria for leaving the iteration. The iteration assessment should verify that the objectives&nbsp;for
+ the&nbsp;Iteration phase&nbsp;have been achieved, including agreement on the key functionalities and at least one
+ possible solution for the system under development, as well as a reasonable understanding of cost, schedule and risks
+ associated with the project.
+</p>
+<p>
+ Based on demonstration of key functionalities and architectural feasibility during the assessment, it becomes clear
+ that either the project can proceed at the given pace or that a reprioritization of work needs to happen. As a
+ consequence, the project manager may need to refine the project scope and duration.
+</p>
+<h4>
+ Manage requirements
+</h4>
+<p>
+ This activity is first performed in the first iteration, and repeated throughout the lifecycle.&nbsp; The goal of this
+ activity is to understand and prioritize stakeholder needs, and associated requirements for the system, and capture
+ these in a form that will support effective communications and collaboration between the stakeholders and development
+ team.
+</p>
+<p>
+ As the project is initiated, the&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>
+ gathers <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html"
+ guid="_0Wh-sMlgEdmt3adZL5Dmdw">requirements</a> from&nbsp;stakeholders and captures associated&nbsp;work items&nbsp;for
+ development in the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">work items list</a>&nbsp;to facilitate prioritization and planning. As needed,
+ requirements are outlined and detailed in&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">use-case</a> specifications and <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">supporting requirements</a>&nbsp;to the extent needed to provide information for the <a
+ class="elementLinkWithUserText" href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">architect</a> to create a prototype of the architecture and for the project manager to
+ scope and plan the next iteration.
+</p>
+<h4>
+ Determine architectural feasibility
+</h4>
+<p>
+ This activity is initiated in the Inception phase and completed in the Elaboration phase. The goal of this activity is
+ to establish an architecture for the system that provides the high-level design that maximizes&nbsp;stakeholder
+ benefit, while respecting the constraints placed on the system and the development team.
+</p>
+<p>
+ Based on requirements being captured and detailed in parallel with this activity, the architect analyzes the
+ architectural constraints and leverages the available assets and technology to propose an architectural
+ proof-of-concept. This early architectural prototype is used both to demonstrate the feasibility of the project, by
+ using the selected candidate architecture, and to mitigate one or more architecturally significant <a
+ class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html"
+ guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a>.
+</p></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/inception_phase_iteration/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/inception_phase_iteration/model.xmi
new file mode 100644
index 0000000..cc234ae
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/inception_phase_iteration/model.xmi
@@ -0,0 +1,193 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nJr2APL5Edm6Nvont3uinw" guid="_nJr2APL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nJHOQ_L5Edm6Nvont3uinw" id="_mtb-7PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74PilEdmugcVr9AdHjQ" id="_mtb-7_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74filEdmugcVr9AdHjQ" id="_mtb-8PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74vilEdmugcVr9AdHjQ" id="_mtb-8fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf74_ilEdmugcVr9AdHjQ" id="_mtb-8vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="__Kf75PilEdmugcVr9AdHjQ" id="_mtb-6_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0oSdEclgEdmt3adZL5Dmdw" name="inception_phase_iteration" guid="_0oSdEclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0oSdEslgEdmt3adZL5Dmdw" name="initiate_project" guid="_0oSdEslgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0oSdE8lgEdmt3adZL5Dmdw" name="initiate_project" guid="_0oSdE8lgEdmt3adZL5Dmdw" presentationName="Initiate Project" superActivities="_0o3r4slgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb-7PL5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-7PL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNA8lgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0okw8MlgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0okw8MlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0okw8clgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0okw8clgEdmt3adZL5Dmdw" presentationName="Manage Requirements" superActivities="_0o3r4slgEdmt3adZL5Dmdw" linkToPredecessor="_IWodoClhEdqjQsaFX0CJTw" variabilityType="extends">
+ <presentation xmi:id="_mtb-7_L5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-7_L5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_IWodoClhEdqjQsaFX0CJTw" guid="_IWodoClhEdqjQsaFX0CJTw" linkType="finishToFinish" pred="_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0oreoMlgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0oreoMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0oreoclgEdmt3adZL5Dmdw" name="determine_architectural_feasibility" guid="_0oreoclgEdmt3adZL5Dmdw" presentationName="Determine Architectural Feasibility" isOptional="true" superActivities="_0o3r4slgEdmt3adZL5Dmdw" linkToPredecessor="_IW0q4ClhEdqjQsaFX0CJTw" variabilityType="extends">
+ <presentation xmi:id="_mtb-8PL5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-8PL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_IW0q4ClhEdqjQsaFX0CJTw" guid="_IW0q4ClhEdqjQsaFX0CJTw" linkType="finishToFinish" pred="_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_jK8QsP77Edm1zMZYtD3GjA" name="manage_iteration" guid="_jK8QsP77Edm1zMZYtD3GjA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_jLaKwP77Edm1zMZYtD3GjA" name="manage_iteration" guid="_jLaKwP77Edm1zMZYtD3GjA" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_0o3r4slgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <diagrams xmi:id="_GRgRUMlzEdmkFIUsXH7ISQ" guid="_GRgRUMlzEdmkFIUsXH7ISQ">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRUclzEdmkFIUsXH7ISQ" guid="_GRgRUclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRUslzEdmkFIUsXH7ISQ" x="111.0" y="102.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_lY0Msfr5EdmyhNQr5STrZQ" guid="_lY0Msfr5EdmyhNQr5STrZQ" anchor="_lY0MsPr5EdmyhNQr5STrZQ _lY0Msvr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_kAcrkvr5EdmyhNQr5STrZQ" guid="_kAcrkvr5EdmyhNQr5STrZQ" graphEdge="_kAcrkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_kAcrlPr5EdmyhNQr5STrZQ" x="26.0" y="-28.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lY0MsPr5EdmyhNQr5STrZQ" guid="_lY0MsPr5EdmyhNQr5STrZQ" graphEdge="_lY0Msfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_lY0Ms_r5EdmyhNQr5STrZQ" x="25.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRU8lzEdmkFIUsXH7ISQ" guid="_GRgRU8lzEdmkFIUsXH7ISQ" element="_0oSdE8lgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_GRgRVMlzEdmkFIUsXH7ISQ" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRVclzEdmkFIUsXH7ISQ" guid="_GRgRVclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRVslzEdmkFIUsXH7ISQ" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRV8lzEdmkFIUsXH7ISQ" guid="_GRgRV8lzEdmkFIUsXH7ISQ"/>
+ <size xmi:id="_GRgRWMlzEdmkFIUsXH7ISQ" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRWclzEdmkFIUsXH7ISQ" guid="_GRgRWclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRWslzEdmkFIUsXH7ISQ" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRW8lzEdmkFIUsXH7ISQ" guid="_GRgRW8lzEdmkFIUsXH7ISQ"/>
+ <size xmi:id="_GRgRXMlzEdmkFIUsXH7ISQ" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRXclzEdmkFIUsXH7ISQ" guid="_GRgRXclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRXslzEdmkFIUsXH7ISQ" x="-25.0" y="204.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nSH3sfr5EdmyhNQr5STrZQ" guid="_nSH3sfr5EdmyhNQr5STrZQ" anchor="_nSH3sPr5EdmyhNQr5STrZQ _nSN-UPr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_m14novr5EdmyhNQr5STrZQ" guid="_m14novr5EdmyhNQr5STrZQ" graphEdge="_m14nofr5EdmyhNQr5STrZQ">
+ <position xmi:id="_m14npPr5EdmyhNQr5STrZQ" x="100.0" y="-13.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nSH3sPr5EdmyhNQr5STrZQ" guid="_nSH3sPr5EdmyhNQr5STrZQ" graphEdge="_nSH3sfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_nSUE8Pr5EdmyhNQr5STrZQ" x="97.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRX8lzEdmkFIUsXH7ISQ" guid="_GRgRX8lzEdmkFIUsXH7ISQ" element="_0okw8clgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_GRgRYMlzEdmkFIUsXH7ISQ" width="207.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRYclzEdmkFIUsXH7ISQ" guid="_GRgRYclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRYslzEdmkFIUsXH7ISQ" x="108.0" y="238.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oB5u0fr5EdmyhNQr5STrZQ" guid="_oB5u0fr5EdmyhNQr5STrZQ" anchor="_oB5u0Pr5EdmyhNQr5STrZQ _oB5u0vr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_nxJWAvr5EdmyhNQr5STrZQ" guid="_nxJWAvr5EdmyhNQr5STrZQ" graphEdge="_nxJWAfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_nxJWBPr5EdmyhNQr5STrZQ" x="73.0" y="-85.0"/>
+ </anchorage>
+ <anchorage xmi:id="_oB5u0Pr5EdmyhNQr5STrZQ" guid="_oB5u0Pr5EdmyhNQr5STrZQ" graphEdge="_oB5u0fr5EdmyhNQr5STrZQ">
+ <position xmi:id="_oB5u0_r5EdmyhNQr5STrZQ" x="79.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRY8lzEdmkFIUsXH7ISQ" guid="_GRgRY8lzEdmkFIUsXH7ISQ" element="_0oreoclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_GRgRZMlzEdmkFIUsXH7ISQ" width="164.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GRgRZclzEdmkFIUsXH7ISQ" guid="_GRgRZclzEdmkFIUsXH7ISQ">
+ <position xmi:id="_GRgRZslzEdmkFIUsXH7ISQ" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mESLkfr5EdmyhNQr5STrZQ" guid="_mESLkfr5EdmyhNQr5STrZQ" anchor="_mESLkPr5EdmyhNQr5STrZQ _mESLkvr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_mESLkPr5EdmyhNQr5STrZQ" guid="_mESLkPr5EdmyhNQr5STrZQ" graphEdge="_mESLkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_mESLk_r5EdmyhNQr5STrZQ" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRZ8lzEdmkFIUsXH7ISQ" guid="_GRgRZ8lzEdmkFIUsXH7ISQ"/>
+ <size xmi:id="_GRgRaMlzEdmkFIUsXH7ISQ" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_UGg-cPr5EdmyhNQr5STrZQ" guid="_UGg-cPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_UGg-cfr5EdmyhNQr5STrZQ" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_UGg-cvr5EdmyhNQr5STrZQ" guid="_UGg-cvr5EdmyhNQr5STrZQ"/>
+ <size xmi:id="_UGg-c_r5EdmyhNQr5STrZQ" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_boMAIPr5EdmyhNQr5STrZQ" guid="_boMAIPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_boMAIfr5EdmyhNQr5STrZQ" x="5.0" y="68.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_kAcrkfr5EdmyhNQr5STrZQ" guid="_kAcrkfr5EdmyhNQr5STrZQ" anchor="_kAcrkPr5EdmyhNQr5STrZQ _kAcrkvr5EdmyhNQr5STrZQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_i_klQQheEdqqjIx6JFygWA" guid="_i_klQQheEdqqjIx6JFygWA" anchor="_i_klQAheEdqqjIx6JFygWA _i_klQgheEdqqjIx6JFygWA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__xwpAdSHEdqANo9Ox5ktZQ" guid="__xwpAdSHEdqANo9Ox5ktZQ" anchor="__xwpANSHEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_kAcrkPr5EdmyhNQr5STrZQ" guid="_kAcrkPr5EdmyhNQr5STrZQ" graphEdge="_kAcrkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_87PH0NSHEdqANo9Ox5ktZQ" x="145.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_i_klQAheEdqqjIx6JFygWA" guid="_i_klQAheEdqqjIx6JFygWA" graphEdge="_i_klQQheEdqqjIx6JFygWA">
+ <position xmi:id="_41Pi0NSHEdqANo9Ox5ktZQ" x="332.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_OMFr8h_bEdq3EKSIdbj-MA" guid="_OMFr8h_bEdq3EKSIdbj-MA" graphEdge="_OMFr8R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_eJhJUMBKEdqSgKaj2SZBmg" x="179.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__xwpANSHEdqANo9Ox5ktZQ" guid="__xwpANSHEdqANo9Ox5ktZQ" graphEdge="__xwpAdSHEdqANo9Ox5ktZQ">
+ <position xmi:id="_DOlVMNSIEdqANo9Ox5ktZQ" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_boMAIvr5EdmyhNQr5STrZQ" guid="_boMAIvr5EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_boMAI_r5EdmyhNQr5STrZQ" width="454.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_cV9FEPr5EdmyhNQr5STrZQ" guid="_cV9FEPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_cWDLsPr5EdmyhNQr5STrZQ" x="26.0" y="169.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_m14nofr5EdmyhNQr5STrZQ" guid="_m14nofr5EdmyhNQr5STrZQ" anchor="_m14noPr5EdmyhNQr5STrZQ _m14novr5EdmyhNQr5STrZQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nxJWAfr5EdmyhNQr5STrZQ" guid="_nxJWAfr5EdmyhNQr5STrZQ" anchor="_nxJWAPr5EdmyhNQr5STrZQ _nxJWAvr5EdmyhNQr5STrZQ"/>
+ <anchorage xmi:id="_m14noPr5EdmyhNQr5STrZQ" guid="_m14noPr5EdmyhNQr5STrZQ" graphEdge="_m14nofr5EdmyhNQr5STrZQ">
+ <position xmi:id="_9yf8gMA6EdqSgKaj2SZBmg" x="52.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nxJWAPr5EdmyhNQr5STrZQ" guid="_nxJWAPr5EdmyhNQr5STrZQ" graphEdge="_nxJWAfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_y3M3ENSHEdqANo9Ox5ktZQ" x="163.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_lY0Msvr5EdmyhNQr5STrZQ" guid="_lY0Msvr5EdmyhNQr5STrZQ" graphEdge="_lY0Msfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_6JfY8NSHEdqANo9Ox5ktZQ" x="124.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_cWDLsfr5EdmyhNQr5STrZQ" guid="_cWDLsfr5EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_cWDLsvr5EdmyhNQr5STrZQ" width="225.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_f4q94Pr5EdmyhNQr5STrZQ" guid="_f4q94Pr5EdmyhNQr5STrZQ">
+ <position xmi:id="_f4q94fr5EdmyhNQr5STrZQ" x="4.0" y="344.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__Ubz0dSHEdqANo9Ox5ktZQ" guid="__Ubz0dSHEdqANo9Ox5ktZQ" anchor="__Ubz0NSHEdqANo9Ox5ktZQ __Ubz0tSHEdqANo9Ox5ktZQ"/>
+ <anchorage xmi:id="_mESLkvr5EdmyhNQr5STrZQ" guid="_mESLkvr5EdmyhNQr5STrZQ" graphEdge="_mESLkfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_zY-UwPr5EdmyhNQr5STrZQ" x="134.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nSN-UPr5EdmyhNQr5STrZQ" guid="_nSN-UPr5EdmyhNQr5STrZQ" graphEdge="_nSH3sfr5EdmyhNQr5STrZQ">
+ <position xmi:id="_vakYINSHEdqANo9Ox5ktZQ" x="74.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_oB5u0vr5EdmyhNQr5STrZQ" guid="_oB5u0vr5EdmyhNQr5STrZQ" graphEdge="_oB5u0fr5EdmyhNQr5STrZQ">
+ <position xmi:id="_zzkYsNSHEdqANo9Ox5ktZQ" x="186.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_jasbAgheEdqqjIx6JFygWA" guid="_jasbAgheEdqqjIx6JFygWA" graphEdge="_jasbAQheEdqqjIx6JFygWA">
+ <position xmi:id="_16__QNSHEdqANo9Ox5ktZQ" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__Ubz0NSHEdqANo9Ox5ktZQ" guid="__Ubz0NSHEdqANo9Ox5ktZQ" graphEdge="__Ubz0dSHEdqANo9Ox5ktZQ">
+ <position xmi:id="__Ubz09SHEdqANo9Ox5ktZQ" x="189.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_AIfG8tSIEdqANo9Ox5ktZQ" guid="_AIfG8tSIEdqANo9Ox5ktZQ">
+ <position xmi:id="_AIfG9NSIEdqANo9Ox5ktZQ" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_f4q94vr5EdmyhNQr5STrZQ" guid="_f4q94vr5EdmyhNQr5STrZQ" typeInfo="synchnonization bar"/>
+ <size xmi:id="_f4q94_r5EdmyhNQr5STrZQ" width="463.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_iEptQPr5EdmyhNQr5STrZQ" guid="_iEptQPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_iEptQfr5EdmyhNQr5STrZQ" x="175.0" y="19.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_OMFr8R_bEdq3EKSIdbj-MA" guid="_OMFr8R_bEdq3EKSIdbj-MA" anchor="_OMFr8B_bEdq3EKSIdbj-MA _OMFr8h_bEdq3EKSIdbj-MA"/>
+ <anchorage xmi:id="_OMFr8B_bEdq3EKSIdbj-MA" guid="_OMFr8B_bEdq3EKSIdbj-MA" graphEdge="_OMFr8R_bEdq3EKSIdbj-MA">
+ <position xmi:id="_OMFr8x_bEdq3EKSIdbj-MA" x="8.0" y="-1.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_iEptQvr5EdmyhNQr5STrZQ" guid="_iEptQvr5EdmyhNQr5STrZQ" typeInfo="start node"/>
+ <size xmi:id="_iEptQ_r5EdmyhNQr5STrZQ" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_idu7oPr5EdmyhNQr5STrZQ" guid="_idu7oPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_idu7ofr5EdmyhNQr5STrZQ" x="182.0" y="382.0"/>
+ <anchorage xmi:id="__Ubz0tSHEdqANo9Ox5ktZQ" guid="__Ubz0tSHEdqANo9Ox5ktZQ" graphEdge="__Ubz0dSHEdqANo9Ox5ktZQ"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_idu7ovr5EdmyhNQr5STrZQ" guid="_idu7ovr5EdmyhNQr5STrZQ" typeInfo="end node"/>
+ <size xmi:id="_idu7o_r5EdmyhNQr5STrZQ" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_aYcXYAheEdqqjIx6JFygWA" guid="_aYcXYAheEdqqjIx6JFygWA">
+ <position xmi:id="_aYcXYQheEdqqjIx6JFygWA" x="296.0" y="145.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_jasbAQheEdqqjIx6JFygWA" guid="_jasbAQheEdqqjIx6JFygWA" anchor="_jasbAAheEdqqjIx6JFygWA _jasbAgheEdqqjIx6JFygWA"/>
+ <anchorage xmi:id="_i_klQgheEdqqjIx6JFygWA" guid="_i_klQgheEdqqjIx6JFygWA" graphEdge="_i_klQQheEdqqjIx6JFygWA">
+ <position xmi:id="_i_klRAheEdqqjIx6JFygWA" x="33.0" y="-129.0"/>
+ </anchorage>
+ <anchorage xmi:id="_jasbAAheEdqqjIx6JFygWA" guid="_jasbAAheEdqqjIx6JFygWA" graphEdge="_jasbAQheEdqqjIx6JFygWA">
+ <position xmi:id="_jasbAwheEdqqjIx6JFygWA" x="39.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_aYieAAheEdqqjIx6JFygWA" guid="_aYieAAheEdqqjIx6JFygWA" element="_jLaKwP77Edm1zMZYtD3GjA"/>
+ <size xmi:id="_aYieAQheEdqqjIx6JFygWA" width="83.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GRgRbclzEdmkFIUsXH7ISQ" guid="_GRgRbclzEdmkFIUsXH7ISQ" presentation="Workflow" element="_0o3r4slgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0o3r4slgEdmt3adZL5Dmdw" name="inception_phase_iteration" guid="_0o3r4slgEdmt3adZL5Dmdw" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Inception phase. Each activity and related goals are described." presentationName="Inception Phase Iteration" breakdownElements="_0oSdE8lgEdmt3adZL5Dmdw _jLaKwP77Edm1zMZYtD3GjA _0okw8clgEdmt3adZL5Dmdw _0oreoclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_mtb-6_L5Edm6Nvont3uinw" href="uma://_mtb-7PL5Edm6Nvont3uinw#_mtb-6_L5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/initiate_project/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/initiate_project/content.xmi
new file mode 100644
index 0000000..02b0e2b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/initiate_project/content.xmi
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-9fL5Edm6Nvont3uinw" guid="_mtb-9fL5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity
+ is to establish the vision for the project and the project plan at a high level of granularity.
+</p>
+<p>
+ The people in the roles involved at this time collaborate to perform this activity:
+</p>
+<ul>
+ <li>
+ <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholder</a> roles work together to define the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> for the project, capturing the customer needs and features for the system
+ under development. Needs and features are captured to the extent required to reach agreement about the scope of the
+ project.
+ </li>
+ <li>
+ Project manager (with collaboration and agreement of team and stakeholders) proposes a high-level <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases and time-boxed iterations for each phase. This
+ plan and the allocation of staff to the project evolve throughout the phases&nbsp;and defines the pace of the
+ project.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/initiate_project/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/initiate_project/model.xmi
new file mode 100644
index 0000000..fddbfc9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/initiate_project/model.xmi
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nJx8oPL5Edm6Nvont3uinw" guid="_nJx8oPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nJr2A_L5Edm6Nvont3uinw" id="_mtb-9fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0pWNAslgEdmt3adZL5Dmdw" name="initiate_project" guid="_0pWNAslgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_VNpT0FY5EdqI9sTOt2pjHw" name="analyst" guid="_VNpT0FY5EdqI9sTOt2pjHw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" responsibleFor="_PFnTkOB7EdqnKu908IEluw _VNvacFY5EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_VNvacFY5EdqI9sTOt2pjHw" name="vision" guid="_VNvacFY5EdqI9sTOt2pjHw" presentationName="Vision" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_XKDWIFY5EdqI9sTOt2pjHw" name="plan_the_project" guid="_XKDWIFY5EdqI9sTOt2pjHw" presentationName="Plan the Project" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" additionallyPerformedBy="_S8dNQMBFEdqSgKaj2SZBmg _VNpT0FY5EdqI9sTOt2pjHw _S8dNQsBFEdqSgKaj2SZBmg _J8-00MAZEdqX-s4mWhkyqQ" mandatoryInput="_VNvacFY5EdqI9sTOt2pjHw _4Y1wML3JEdqfrv3k16plXw" optionalInput="_XKbwoFY5EdqI9sTOt2pjHw _hhnXEDeqEduCsbgJNeFsSw" output="_XKbwoFY5EdqI9sTOt2pjHw _4Y1wML3JEdqfrv3k16plXw _hhnXEDeqEduCsbgJNeFsSw" performedPrimarilyBy="_XKVqAFY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0lC70MlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_lrYj0MBAEdqSgKaj2SZBmg"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_k1bY4MMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_OfFTEABjEdqHlpDr8LcRqg"/>
+ <selectedSteps href="uma://_fPbdIKe2Edmzde8VFK5bxg#_F2dQYABjEdqHlpDr8LcRqg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_XKVqAFY5EdqI9sTOt2pjHw" name="project_manager" guid="_XKVqAFY5EdqI9sTOt2pjHw" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" responsibleFor="_hhnXEDeqEduCsbgJNeFsSw _4Y1wML3JEdqfrv3k16plXw _XKbwoFY5EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_XKbwoFY5EdqI9sTOt2pjHw" name="project_plan" guid="_XKbwoFY5EdqI9sTOt2pjHw" presentationName="Project Plan" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a6vcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_4Y1wML3JEdqfrv3k16plXw" name="work_items_list" guid="_4Y1wML3JEdqfrv3k16plXw" presentationName="Work Items List" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_J8-00MAZEdqX-s4mWhkyqQ" name="stakeholder" guid="_J8-00MAZEdqX-s4mWhkyqQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_S8dNQMBFEdqSgKaj2SZBmg" name="architect" guid="_S8dNQMBFEdqSgKaj2SZBmg" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_S8dNQsBFEdqSgKaj2SZBmg" name="tester" guid="_S8dNQsBFEdqSgKaj2SZBmg" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_PFnTkOB7EdqnKu908IEluw" name="glossary" guid="_PFnTkOB7EdqnKu908IEluw" presentationName="Glossary" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_hhnXEDeqEduCsbgJNeFsSw" name="risk_list" guid="_hhnXEDeqEduCsbgJNeFsSw" presentationName="Risk List" superActivities="_0pWNA8lgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Ckay8Cc_EduIsqH1Q6ZuqA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_79bQ4DoCEdu0yYZ2bsCXog" name="define_vision" guid="_79bQ4DoCEdu0yYZ2bsCXog" presentationName="Define Vision" superActivities="_0pWNA8lgEdmt3adZL5Dmdw" additionallyPerformedBy="_J8-00MAZEdqX-s4mWhkyqQ" optionalInput="_VNvacFY5EdqI9sTOt2pjHw" output="_VNvacFY5EdqI9sTOt2pjHw _PFnTkOB7EdqnKu908IEluw" performedPrimarilyBy="_VNpT0FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0fOAoMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_tvzDULwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_sa5F4LwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_rliOAOz2Edq2wJOsmRwmhg"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_vGg-oLwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_z7ZC4LwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_1LVn0LwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_2VixILwPEdm6DujQZORGLQ"/>
+ <selectedSteps href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_AhjmAL-GEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <diagrams xmi:id="_CYoF0Ml0EdmkFIUsXH7ISQ" guid="_CYoF0Ml0EdmkFIUsXH7ISQ">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_CYoF0cl0EdmkFIUsXH7ISQ" guid="_CYoF0cl0EdmkFIUsXH7ISQ" presentation="Work Product Dependency">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ </diagrams>
+ <diagrams xmi:id="_RTY08Ml0EdmkFIUsXH7ISQ" guid="_RTY08Ml0EdmkFIUsXH7ISQ">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_RTY08cl0EdmkFIUsXH7ISQ" guid="_RTY08cl0EdmkFIUsXH7ISQ" presentation="Activity Detail">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0pWNA8lgEdmt3adZL5Dmdw" name="initiate_project" guid="_0pWNA8lgEdmt3adZL5Dmdw" briefDescription="This capability pattern bundles tasks required to define the vision and create a project plan." presentationName="Initiate Project" breakdownElements="_VNpT0FY5EdqI9sTOt2pjHw _VNvacFY5EdqI9sTOt2pjHw _79bQ4DoCEdu0yYZ2bsCXog _XKDWIFY5EdqI9sTOt2pjHw _XKVqAFY5EdqI9sTOt2pjHw _XKbwoFY5EdqI9sTOt2pjHw _4Y1wML3JEdqfrv3k16plXw _J8-00MAZEdqX-s4mWhkyqQ _S8dNQMBFEdqSgKaj2SZBmg _S8dNQsBFEdqSgKaj2SZBmg _PFnTkOB7EdqnKu908IEluw _hhnXEDeqEduCsbgJNeFsSw">
+ <presentation xmi:id="_mtb-9fL5Edm6Nvont3uinw" href="uma://_mtb-9fL5Edm6Nvont3uinw#_mtb-9fL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_iteration/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_iteration/content.xmi
new file mode 100644
index 0000000..6b9e88e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_iteration/content.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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="_mtb-6PL5Edm6Nvont3uinw" guid="_mtb-6PL5Edm6Nvont3uinw"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_iteration/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_iteration/model.xmi
new file mode 100644
index 0000000..0abaee4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_iteration/model.xmi
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nI06YvL5Edm6Nvont3uinw" guid="_nI06YvL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nI06YfL5Edm6Nvont3uinw" id="_mtb-6PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0nJNkclgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0nJNkclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_mZDP4FY5EdqI9sTOt2pjHw" name="project_manager" guid="_mZDP4FY5EdqI9sTOt2pjHw" presentationName="Project Manager" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw" responsibleFor="_TPsdoUmSEduO0bs89Khm8Q _DUCuoDk-EduFTqg5hiiQIw _oNnk0FY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _mZVjwFY5EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a0o0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_mZVjwFY5EdqI9sTOt2pjHw" name="iteration_plan" guid="_mZVjwFY5EdqI9sTOt2pjHw" presentationName="Iteration Plan" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0aQBEslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_mZt-QFY5EdqI9sTOt2pjHw" name="project_plan" guid="_mZt-QFY5EdqI9sTOt2pjHw" presentationName="Project Plan" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0a6vcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_oNJDsFY5EdqI9sTOt2pjHw" name="manage_iteration" guid="_oNJDsFY5EdqI9sTOt2pjHw" presentationName="Manage Iteration" superActivities="_0nJNkslgEdmt3adZL5Dmdw" additionallyPerformedBy="_DT8oADk-EduFTqg5hiiQIw _DT8oATk-EduFTqg5hiiQIw _DT8oAjk-EduFTqg5hiiQIw _DT8oAzk-EduFTqg5hiiQIw _DT8oBDk-EduFTqg5hiiQIw _DT8oBTk-EduFTqg5hiiQIw" mandatoryInput="_mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw _DUCuoDk-EduFTqg5hiiQIw" output="_mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw _DUCuoDk-EduFTqg5hiiQIw" performedPrimarilyBy="_mZDP4FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_8S2aICbYEdqh1LYUOGRh2A"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_OE65ICuxEdqTIKp3l5PtzQ"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_ztF0UCuxEdqTIKp3l5PtzQ"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_oIZdkCbZEdqh1LYUOGRh2A"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_xiFJwCbZEdqh1LYUOGRh2A"/>
+ <selectedSteps href="uma://-PbfqVxB_j9KN-Jx39_pEUA#_Br6VECuxEdqTIKp3l5PtzQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_oNnk0FY5EdqI9sTOt2pjHw" name="work_items_list" guid="_oNnk0FY5EdqI9sTOt2pjHw" presentationName="Work Items List" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oADk-EduFTqg5hiiQIw" name="analyst" guid="_DT8oADk-EduFTqg5hiiQIw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw" responsibleFor="_SZOIoUmSEduO0bs89Khm8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oATk-EduFTqg5hiiQIw" name="architect" guid="_DT8oATk-EduFTqg5hiiQIw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw" responsibleFor="_SZOIoEmSEduO0bs89Khm8Q">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oAjk-EduFTqg5hiiQIw" name="tester" guid="_DT8oAjk-EduFTqg5hiiQIw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oAzk-EduFTqg5hiiQIw" name="developer" guid="_DT8oAzk-EduFTqg5hiiQIw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oBDk-EduFTqg5hiiQIw" name="any_role" guid="_DT8oBDk-EduFTqg5hiiQIw" presentationName="Any Role" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0dsWoMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_DT8oBTk-EduFTqg5hiiQIw" name="stakeholder" guid="_DT8oBTk-EduFTqg5hiiQIw" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_DUCuoDk-EduFTqg5hiiQIw" name="risk_list" guid="_DUCuoDk-EduFTqg5hiiQIw" presentationName="Risk List" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Ckay8Cc_EduIsqH1Q6ZuqA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_SZICAEmSEduO0bs89Khm8Q" name="plan_iteration" guid="_SZICAEmSEduO0bs89Khm8Q" presentationName="Plan Iteration" superActivities="_0nJNkslgEdmt3adZL5Dmdw" additionallyPerformedBy="_DT8oATk-EduFTqg5hiiQIw _DT8oADk-EduFTqg5hiiQIw _DT8oAjk-EduFTqg5hiiQIw _DT8oAzk-EduFTqg5hiiQIw _DT8oBTk-EduFTqg5hiiQIw" mandatoryInput="_mZt-QFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw" optionalInput="_SZOIoEmSEduO0bs89Khm8Q _SZOIoUmSEduO0bs89Khm8Q" output="_mZVjwFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw" performedPrimarilyBy="_mZDP4FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0keUEMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_CtKCMMBHEdqSgKaj2SZBmg"/>
+ <selectedSteps href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_307v0MMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_7Hqr4MMsEdmdo9HxCRR_Gw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_SZOIoEmSEduO0bs89Khm8Q" name="architecture" guid="_SZOIoEmSEduO0bs89Khm8Q" presentationName="Architecture" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0XAf0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_SZOIoUmSEduO0bs89Khm8Q" name="vision" guid="_SZOIoUmSEduO0bs89Khm8Q" presentationName="Vision" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_TPsdoEmSEduO0bs89Khm8Q" name="assess_results" guid="_TPsdoEmSEduO0bs89Khm8Q" presentationName="Assess Results" superActivities="_0nJNkslgEdmt3adZL5Dmdw" additionallyPerformedBy="_DT8oBTk-EduFTqg5hiiQIw _DT8oBDk-EduFTqg5hiiQIw" mandatoryInput="_mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw" optionalInput="_TPsdoUmSEduO0bs89Khm8Q _SZOIoUmSEduO0bs89Khm8Q" output="_TPsdoUmSEduO0bs89Khm8Q" performedPrimarilyBy="_mZDP4FY5EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0l53cMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_o28GgMMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_PABe4MQIEdmaiYJe8-Eaqg"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_YdoAAM1DEdmLoKw_mVTvhQ"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_wp2CIMMsEdmdo9HxCRR_Gw"/>
+ <selectedSteps href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_1YHH8DLqEdueZPye-FaNgA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_TPsdoUmSEduO0bs89Khm8Q" name="status_assessment" guid="_TPsdoUmSEduO0bs89Khm8Q" presentationName="Status Assessment" superActivities="_0nJNkslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0bA2EMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0nJNkslgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0nJNkslgEdmt3adZL5Dmdw" briefDescription="Initiate the iteration and assign work to team members. Monitor and communicate project status to external stakeholders. Identify and handle exceptions and problems." presentationName="Plan and Manage Iteration" isPlanned="false" hasMultipleOccurrences="true" isOngoing="true" breakdownElements="_mZDP4FY5EdqI9sTOt2pjHw _mZVjwFY5EdqI9sTOt2pjHw _mZt-QFY5EdqI9sTOt2pjHw _SZICAEmSEduO0bs89Khm8Q _oNJDsFY5EdqI9sTOt2pjHw _oNnk0FY5EdqI9sTOt2pjHw _DT8oADk-EduFTqg5hiiQIw _DT8oATk-EduFTqg5hiiQIw _DT8oAjk-EduFTqg5hiiQIw _DT8oAzk-EduFTqg5hiiQIw _DT8oBDk-EduFTqg5hiiQIw _DT8oBTk-EduFTqg5hiiQIw _DUCuoDk-EduFTqg5hiiQIw _SZOIoEmSEduO0bs89Khm8Q _SZOIoUmSEduO0bs89Khm8Q _TPsdoEmSEduO0bs89Khm8Q _TPsdoUmSEduO0bs89Khm8Q">
+ <presentation xmi:id="_mtb-6PL5Edm6Nvont3uinw" href="uma://_mtb-6PL5Edm6Nvont3uinw#_mtb-6PL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_requirements/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_requirements/content.xmi
new file mode 100644
index 0000000..f011a27
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_requirements/content.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-8_L5Edm6Nvont3uinw" guid="_mtb-8_L5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity describes the tasks performed to&nbsp;gather, specify, analyze and&nbsp;validate&nbsp;a subset of
+ system's&nbsp;requirements&nbsp;prior to&nbsp;implementation and verification. This does not imply that all
+ requirements are detailed prior to commencing implementation. Rather, this activity is performed throughout the
+ lifecycle with <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s and the entire development team collaborating to ensure that a clear,
+ consistent, correct, verifiable, and feasible&nbsp;set of requirements&nbsp;is available, as needed, to drive
+ implementation and verification.
+</p>
+<p>
+ During Inception, the focus is on&nbsp;gaining agreement on&nbsp;the problem to be solved, gathering stakeholder needs
+ and capturing high-level system features&nbsp;(see activity <a class="elementLink" href="./../../openup_basic/capabilitypatterns/initiate_project,_0pWNA8lgEdmt3adZL5Dmdw.html" guid="_0pWNA8lgEdmt3adZL5Dmdw">Initiate Project</a>).
+</p>
+<p>
+ During Elaboration, the focus shifts to defining the solution. This consists of&nbsp;finding those requirements that
+ have most value to stakeholders, that are particularly challenging or risky, or that are architecturally significant
+ (See <a class="elementLinkWithType" href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>).&nbsp;Requirements&nbsp;that
+ are&nbsp;prioritized, via the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>,&nbsp;for implementation in the early iterations are then described
+ in sufficient detail to validate the development teams understanding of the requirements, to ensure concurrence with
+ stakeholders, and to permit software development to begin (see <a class="elementLinkWithType" href="./../../openup_basic/tasks/detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw.html" guid="_0e1mIMlgEdmt3adZL5Dmdw">Task: Detail Requirements</a>). For each of these requirements, associated test cases are defined to ensure that the
+ requirements are verifiable and to provide the guidance needed for verification and validation (see <a class="elementLinkWithType" href="./../../openup_basic/tasks/create_test_case,_0iwc0clgEdmt3adZL5Dmdw.html" guid="_0iwc0clgEdmt3adZL5Dmdw">Task: Create Test Cases</a>).
+</p>
+<p>
+ During Construction, the focus shifts to refining the system definition<em>.</em> This consists of detailing the
+ remaining requirements and associated test cases as needed to drive implementation and verification, and managing
+ requirements change (see&nbsp;activity <a class="elementLink" href="./../../openup_basic/capabilitypatterns/ongoing_tasks,_0pJ_xslgEdmt3adZL5Dmdw.html" guid="_0pJ_xslgEdmt3adZL5Dmdw">Ongoing Tasks</a>).
+</p></mainDescription>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_requirements/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_requirements/model.xmi
new file mode 100644
index 0000000..c468b7a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/manage_requirements/model.xmi
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nKQdwPL5Edm6Nvont3uinw" guid="_nKQdwPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nKKXI_L5Edm6Nvont3uinw" id="_mtb-8_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0o9ygMlgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0o9ygMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_wGSUwFY6EdqI9sTOt2pjHw" name="analyst" guid="_wGSUwFY6EdqI9sTOt2pjHw" presentationName="Analyst" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw" responsibleFor="_86w-oOB4EdqnKu908IEluw _Y5DAMb-EEdqb7N6KIeDL8Q _wG28gFY6EdqI9sTOt2pjHw _wGw14FY6EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VxJsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_wGeiAFY6EdqI9sTOt2pjHw" name="use_case" guid="_wGeiAFY6EdqI9sTOt2pjHw" presentationName="Use Case" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0VGbUMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_wGw14FY6EdqI9sTOt2pjHw" name="vision" guid="_wGw14FY6EdqI9sTOt2pjHw" presentationName="Vision" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0WVxcMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_wG28gFY6EdqI9sTOt2pjHw" name="uc_model" guid="_wG28gFY6EdqI9sTOt2pjHw" presentationName="Use-Case Model" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_Y42y8L-EEdqb7N6KIeDL8Q" name="find_and_outline_requirements" guid="_Y42y8L-EEdqb7N6KIeDL8Q" presentationName="Find and Outline Requirements" superActivities="_0o9ygclgEdmt3adZL5Dmdw" additionallyPerformedBy="_2tHGoMAYEdqX-s4mWhkyqQ _F6WiEMEQEduTGJ8i4u8TMw _F6WiEcEQEduTGJ8i4u8TMw _kF8tYDbsEduMn613sF6-Uw" mandatoryInput="_86w-oOB4EdqnKu908IEluw _wGw14FY6EdqI9sTOt2pjHw" output="_Y5DAML-EEdqb7N6KIeDL8Q _Y5DAMb-EEdqb7N6KIeDL8Q _86w-oOB4EdqnKu908IEluw _wGeiAFY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw" performedPrimarilyBy="_wGSUwFY6EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_P9cMUPV_EdmdHa9MmVPgqQ"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_ckG-cCY-EdqNHcQ-rAojXw"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_GAr3IOz3Edq2wJOsmRwmhg"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_fDbgkCY-EdqNHcQ-rAojXw"/>
+ <selectedSteps href="uma://-Yt8TXGkE1rwydXR34apsrg#_XRKgkAFoEduDPKiaP0pu-Q"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_0WhHsN-eEdqiM_wFaqLjNg"/>
+ <selectedSteps href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_Mgb9IC4DEduBP8F-6-95NQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_Y5DAML-EEdqb7N6KIeDL8Q" name="work_items_list" guid="_Y5DAML-EEdqb7N6KIeDL8Q" presentationName="Work Items List" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_Y5DAMb-EEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_Y5DAMb-EEdqb7N6KIeDL8Q" presentationName="Supporting Requirements" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_BVh9cL-CEdqb7N6KIeDL8Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_ZRfVYL-EEdqb7N6KIeDL8Q" name="detail_requirements" guid="_ZRfVYL-EEdqb7N6KIeDL8Q" presentationName="Detail Requirements" superActivities="_0o9ygclgEdmt3adZL5Dmdw" additionallyPerformedBy="_2tHGoMAYEdqX-s4mWhkyqQ _F6WiEMEQEduTGJ8i4u8TMw _F6WiEcEQEduTGJ8i4u8TMw _kF8tYDbsEduMn613sF6-Uw" mandatoryInput="_Y5DAMb-EEdqb7N6KIeDL8Q _wGw14FY6EdqI9sTOt2pjHw _86w-oOB4EdqnKu908IEluw _wGeiAFY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw" output="_Y5DAMb-EEdqb7N6KIeDL8Q _86w-oOB4EdqnKu908IEluw _wGeiAFY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw" performedPrimarilyBy="_wGSUwFY6EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0e1mIMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_vWeHMCxSEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_B47VwCxTEdqjsdw1QLH_6Q"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_2389cOz2Edq2wJOsmRwmhg"/>
+ <selectedSteps href="uma://-_mfd9ziTwQV_5LE80jJw4g#_w2JYgEf6EduISP1GQDlvVQ"/>
+ <selectedSteps href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_BYbboN-bEdqiM_wFaqLjNg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_2tHGoMAYEdqX-s4mWhkyqQ" name="stakeholder" guid="_2tHGoMAYEdqX-s4mWhkyqQ" presentationName="Stakeholder" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_dTa6gMAYEdqX-s4mWhkyqQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_86w-oOB4EdqnKu908IEluw" name="glossary" guid="_86w-oOB4EdqnKu908IEluw" presentationName="Glossary" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Wn7HcNcEEdqz_d2XWoVt6Q"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_kFwgIDbsEduMn613sF6-Uw" name="create_test_cases" guid="_kFwgIDbsEduMn613sF6-Uw" presentationName="Create Test Cases" superActivities="_0o9ygclgEdmt3adZL5Dmdw" additionallyPerformedBy="_wGSUwFY6EdqI9sTOt2pjHw _2tHGoMAYEdqX-s4mWhkyqQ _F6WiEcEQEduTGJ8i4u8TMw" mandatoryInput="_wGeiAFY6EdqI9sTOt2pjHw" optionalInput="_kF8tYTbsEduMn613sF6-Uw _Y5DAMb-EEdqb7N6KIeDL8Q" output="_kF8tYTbsEduMn613sF6-Uw" performedPrimarilyBy="_kF8tYDbsEduMn613sF6-Uw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0iwc0clgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_IJFSsKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_aDe_ILGcEdubqf8m_Zrvvg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_LpbM8KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_NK18YKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_Ok_mMKuSEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_kF8tYDbsEduMn613sF6-Uw" name="tester" guid="_kF8tYDbsEduMn613sF6-Uw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw" responsibleFor="_kF8tYTbsEduMn613sF6-Uw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_kF8tYTbsEduMn613sF6-Uw" name="test_case" guid="_kF8tYTbsEduMn613sF6-Uw" presentationName="Test Case" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZS-0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_F6WiEMEQEduTGJ8i4u8TMw" name="architect" guid="_F6WiEMEQEduTGJ8i4u8TMw" presentationName="Architect" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0X9iEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_F6WiEcEQEduTGJ8i4u8TMw" name="developer" guid="_F6WiEcEQEduTGJ8i4u8TMw" presentationName="Developer" hasMultipleOccurrences="true" superActivities="_0o9ygclgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YDosMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0o9ygclgEdmt3adZL5Dmdw" name="manage_requirements" guid="_0o9ygclgEdmt3adZL5Dmdw" briefDescription="Detail a set of requirements (one or more use cases, scenarios or supporting requirements)." presentationName="Manage Requirements" hasMultipleOccurrences="true" breakdownElements="_wGSUwFY6EdqI9sTOt2pjHw _wGeiAFY6EdqI9sTOt2pjHw _wGw14FY6EdqI9sTOt2pjHw _wG28gFY6EdqI9sTOt2pjHw _Y42y8L-EEdqb7N6KIeDL8Q _Y5DAML-EEdqb7N6KIeDL8Q _Y5DAMb-EEdqb7N6KIeDL8Q _ZRfVYL-EEdqb7N6KIeDL8Q _2tHGoMAYEdqX-s4mWhkyqQ _86w-oOB4EdqnKu908IEluw _kFwgIDbsEduMn613sF6-Uw _kF8tYDbsEduMn613sF6-Uw _kF8tYTbsEduMn613sF6-Uw _F6WiEMEQEduTGJ8i4u8TMw _F6WiEcEQEduTGJ8i4u8TMw">
+ <presentation xmi:id="_mtb-8_L5Edm6Nvont3uinw" href="uma://_mtb-8_L5Edm6Nvont3uinw#_mtb-8_L5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/ongoing_tasks/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/ongoing_tasks/content.xmi
new file mode 100644
index 0000000..aa0a0b3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/ongoing_tasks/content.xmi
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-9PL5Edm6Nvont3uinw" guid="_mtb-9PL5Edm6Nvont3uinw" version="1.0.0">
+ <mainDescription><p>
+ This activity&nbsp;includes a single task, <a class="elementLink" href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request Change</a>. This task&nbsp;may occur anytime during the lifecycle in response to an observed defect, a desired
+ enhancement, or a change request. It is not planned,&nbsp;which means it does&nbsp;not appear as a scheduled activity
+ on the project plan, iteration plan or work items list. Nevertheless, it is a critical activity that must be performed
+ to ensure project success in an environment that is not static.
+</p>
+<p>
+ <a class="elementLink" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">Any Role</a>&nbsp;may perform this task, however the most common sources of&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> are&nbsp;<a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s (enhancement requests and change requests) and&nbsp;<a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>s (defect reports).
+</p></mainDescription>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/ongoing_tasks/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/ongoing_tasks/model.xmi
new file mode 100644
index 0000000..76b14ef
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/ongoing_tasks/model.xmi
@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nK7zMvL5Edm6Nvont3uinw" guid="_nK7zMvL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nK7zMfL5Edm6Nvont3uinw" id="_mtb-9PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0pJ_xclgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0pJ_xclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_4x060FY1EdqI9sTOt2pjHw" name="any_role" guid="_4x060FY1EdqI9sTOt2pjHw" presentationName="Any Role" hasMultipleOccurrences="true" superActivities="_0pJ_xslgEdmt3adZL5Dmdw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0dsWoMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_5LsMUFY1EdqI9sTOt2pjHw" name="request_change" guid="_5LsMUFY1EdqI9sTOt2pjHw" presentationName="Request Change" superActivities="_0pJ_xslgEdmt3adZL5Dmdw" optionalInput="_5M7icFY1EdqI9sTOt2pjHw" output="_5M7icFY1EdqI9sTOt2pjHw" performedPrimarilyBy="_4x060FY1EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0mwzEclgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_Nr0S4KeqEdmKDbQuyzCoqQ#_qEkewKuoEdmEGLSmmpF1Sg"/>
+ <selectedSteps href="uma://_Nr0S4KeqEdmKDbQuyzCoqQ#_r2aP0KuoEdmEGLSmmpF1Sg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_5M7icFY1EdqI9sTOt2pjHw" name="work_items_list" guid="_5M7icFY1EdqI9sTOt2pjHw" presentationName="Work Items List" superActivities="_0pJ_xslgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0pJ_xslgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0pJ_xslgEdmt3adZL5Dmdw" briefDescription="Perform ongoing tasks that are not necessarily part of project schedule." presentationName="Ongoing Tasks" isPlanned="false" hasMultipleOccurrences="true" isOngoing="true" isEventDriven="true" breakdownElements="_4x060FY1EdqI9sTOt2pjHw _5LsMUFY1EdqI9sTOt2pjHw _5M7icFY1EdqI9sTOt2pjHw">
+ <presentation xmi:id="_mtb-9PL5Edm6Nvont3uinw" href="uma://_mtb-9PL5Edm6Nvont3uinw#_mtb-9PL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/test/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/test/content.xmi
new file mode 100644
index 0000000..bfa947c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/test/content.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ProcessDescription 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" epf:version="1.0.0" xmi:id="_mtb-6vL5Edm6Nvont3uinw" guid="_mtb-6vL5Edm6Nvont3uinw" version="1.0.0">
+ <keyConsiderations><p>
+ &nbsp;
+</p></keyConsiderations>
+ <purpose>To create and run tests that validate that the system conforms to the intent.</purpose>
+ <howtoStaff><p>
+ The staff performing this activity must be integrated into the team.
+</p></howtoStaff>
+ <usageNotes><p>
+ Testing must occur throughout the process and <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ throughout&nbsp;each iteration.&nbsp;It is not some final inspection to be done at the end. As requirements are de<span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ veloped and integrated into the build they should be tested as soon as possible.</span></span>
+</p></usageNotes>
+</org.eclipse.epf.uma:ProcessDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/test/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/test/model.xmi
new file mode 100644
index 0000000..a0fc5a9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/test/model.xmi
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nJHOQPL5Edm6Nvont3uinw" guid="_nJHOQPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nJBHo_L5Edm6Nvont3uinw" id="_mtb-6vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0nz79MlgEdmt3adZL5Dmdw" name="test" guid="_0nz79MlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_a6qBUFY2EdqI9sTOt2pjHw" name="tester" guid="_a6qBUFY2EdqI9sTOt2pjHw" presentationName="Tester" hasMultipleOccurrences="true" superActivities="_0nz79clgEdmt3adZL5Dmdw" responsibleFor="_oSQYEL3SEdqfrv3k16plXw _a_F1YFY2EdqI9sTOt2pjHw _a8fNUFY2EdqI9sTOt2pjHw">
+ <Role href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZM4MclgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_a8fNUFY2EdqI9sTOt2pjHw" name="test_case" guid="_a8fNUFY2EdqI9sTOt2pjHw" presentationName="Test Case" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZS-0MlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_a_F1YFY2EdqI9sTOt2pjHw" name="test_script" guid="_a_F1YFY2EdqI9sTOt2pjHw" presentationName="Test Script" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_nykLZL3SEdqfrv3k16plXw" name="implement_tests" guid="_nykLZL3SEdqfrv3k16plXw" presentationName="Implement Tests" superActivities="_0nz79clgEdmt3adZL5Dmdw" mandatoryInput="_a8fNUFY2EdqI9sTOt2pjHw" optionalInput="_a_F1YFY2EdqI9sTOt2pjHw _ny2fQL3SEdqfrv3k16plXw" output="_a_F1YFY2EdqI9sTOt2pjHw" performedPrimarilyBy="_a6qBUFY2EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0jO98MlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_S8JzsKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_VN5M0KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_WvBoYKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_X0dmcKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_Y-ABYKuSEdmhFZtkg1nakg"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_ny2fQL3SEdqfrv3k16plXw" name="build" guid="_ny2fQL3SEdqfrv3k16plXw" presentationName="Build" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0YuXEMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_oR39mb3SEdqfrv3k16plXw" name="run_tests" guid="_oR39mb3SEdqfrv3k16plXw" presentationName="Run Tests" superActivities="_0nz79clgEdmt3adZL5Dmdw" mandatoryInput="_ny2fQL3SEdqfrv3k16plXw _a_F1YFY2EdqI9sTOt2pjHw" output="_oSQYEL3SEdqfrv3k16plXw _os33gL3SEdqfrv3k16plXw" performedPrimarilyBy="_a6qBUFY2EdqI9sTOt2pjHw">
+ <Task href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0jVEkMlgEdmt3adZL5Dmdw"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_fR4aQKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_gV408KuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_hfVJQKuSEdmhFZtkg1nakg"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_sQaC4DO2EduqsLmIADMQ9g"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_0XzAwDO2EduqsLmIADMQ9g"/>
+ <selectedSteps href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_3t6oADO2EduqsLmIADMQ9g"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_oSQYEL3SEdqfrv3k16plXw" name="test_log" guid="_oSQYEL3SEdqfrv3k16plXw" presentationName="Test Log" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0ZlSsMlgEdmt3adZL5Dmdw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_os33gL3SEdqfrv3k16plXw" name="work_items_list" guid="_os33gL3SEdqfrv3k16plXw" presentationName="Work Items List" superActivities="_0nz79clgEdmt3adZL5Dmdw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_rGNWsCbSEdqh1LYUOGRh2A"/>
+ </processElements>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0nz79clgEdmt3adZL5Dmdw" name="test" guid="_0nz79clgEdmt3adZL5Dmdw" briefDescription="Test and evaluate the requirements developed, from system perspective." presentationName="Test" hasMultipleOccurrences="true" breakdownElements="_a6qBUFY2EdqI9sTOt2pjHw _a8fNUFY2EdqI9sTOt2pjHw _a_F1YFY2EdqI9sTOt2pjHw _nykLZL3SEdqfrv3k16plXw _ny2fQL3SEdqfrv3k16plXw _oR39mb3SEdqfrv3k16plXw _oSQYEL3SEdqfrv3k16plXw _os33gL3SEdqfrv3k16plXw">
+ <presentation xmi:id="_mtb-6vL5Edm6Nvont3uinw" href="uma://_mtb-6vL5Edm6Nvont3uinw#_mtb-6vL5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/transition_phase_iteration/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/transition_phase_iteration/content.xmi
new file mode 100644
index 0000000..0a44854
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/transition_phase_iteration/content.xmi
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_AfL5Edm6Nvont3uinw" guid="_mtb_AfL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_AvL5Edm6Nvont3uinw" guid="_mtb_AvL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_APL5Edm6Nvont3uinw" guid="_mtb_APL5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_A_L5Edm6Nvont3uinw" guid="_mtb_A_L5Edm6Nvont3uinw"/>
+ <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb-__L5Edm6Nvont3uinw" guid="_mtb-__L5Edm6Nvont3uinw">
+ <mainDescription><h3> Introduction&nbsp; </h3>
+<p> In the Transition phase,
+ most activities happen in parallel. The main objectives are to fine-tune functionality,
+ performance, and overall quality of the beta product from
+ the end of Construction phase. </p>
+<p> The activities performed in a typical iteration during
+ the&nbsp;Transition phase are described below. </p>
+<h4> Manage iteration </h4>
+<p> This activity is performed throughout the lifecycle. The goal of this activity
+ is to identify risks and issues early enough that they can be mitigated, to
+ establish the goals for the iteration, and to support the development team in
+ reaching these goals. </p>
+<p> Similar to other phases, this is an activity led by the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
+ manager</a> (in collaboration with the team) to launch the iteration, to allocate
+ work, to track status, and to handle risks and issues. It’s unlikely that risks
+ of high impact will happen during the Transition, but it is recommended that
+ the project manager and team identify any potential issues&nbsp;while delivering
+ the product to the end users. </p>
+<p>If this is the last iteration of the project, the main goal is to achieve final
+ acceptance of the system. At the end of the iteration, results are assessed
+ against phase objectives<em>,</em> and <a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders'</a>
+ concurrence on the project objectives is obtained. The team conducts a retrospective
+ review to capture lessons learned and make improvements to the process for subsequent
+ <strong> </strong>projects. The project is then closed.</p>
+<h4>Ongoing tasks </h4>
+<p> Submission of change requests during the Transition phase <strong></strong>works&nbsp;differently
+ than in other phases. New requirements will rarely be identified at late stages
+ of the software development lifecycle in a way they can be implemented in the
+ current release. If there are enhancement requests, though, they can be captured
+ in the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">work
+ items list</a> and allocated to a future release, when a new software development
+ lifecycle begins. In that case, requirements will be outlined and detailed accordingly.
+</p>
+<p> However, defects are typically dealt with during the Transition phase,&nbsp;thus
+ a stable release can be accepted by the user community. If there is general
+ agreement from stakeholders, correction of low-priority defects can be postponed
+ to subsequent evolutionary releases. </p>
+<h4> Develop solution for requirement within context</h4>
+<p> This activity is repeated multiple times, in parallel, for each development
+ task planned for that iteration. The main goal of this activity is an executable
+ system that provides the incremental quality and functionality for the specified
+ requirements within the specified context. </p>
+<p> During the Transition phase, most requirements will have been already implemented
+ and validated, which is the focus of the previous phase. Nevertheless, there
+ may be a few low-priority requirements that could be accommodated in the release
+ being developed. However, enhancement requests and defects found in previous
+ iterations may need to be allocated to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
+</p>
+<h4> Validate build </h4>
+<p> This activity is repeated throughout the lifecycle. The main goal of this
+ activity is to validate the current increment of the system against the requirements
+ allocated to it. </p>
+<p> This activity happens in parallel with development of the
+ solutions for enhancement requests and defects
+ (and possibly remaining requirements), to make sure that
+ a stable release can be presented to the user community. Users can be involved
+ in performing <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/test,_0nz79clgEdmt3adZL5Dmdw.html" guid="_0nz79clgEdmt3adZL5Dmdw">tests</a>
+ to accept the release. </p>
+<h4></mainDescription>
+ </org.eclipse.epf.uma:ProcessDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/transition_phase_iteration/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/transition_phase_iteration/model.xmi
new file mode 100644
index 0000000..525f334
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/capabilitypatterns/transition_phase_iteration/model.xmi
@@ -0,0 +1,335 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nMRP8PL5Edm6Nvont3uinw" guid="_nMRP8PL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nLsoM_L5Edm6Nvont3uinw" id="_mtb_AfL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQPinEdmugcVr9AdHjQ" id="_mtb_AvL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQfinEdmugcVr9AdHjQ" id="_mtb_APL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQvinEdmugcVr9AdHjQ" id="_mtb_A_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_2MDIQ_inEdmugcVr9AdHjQ" id="_mtb-__L5Edm6Nvont3uinw" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0qrpwMlgEdmt3adZL5Dmdw" name="transition_phase_iteration" guid="_0qrpwMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0qrpwclgEdmt3adZL5Dmdw" name="validate_build" guid="_0qrpwclgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0qrpwslgEdmt3adZL5Dmdw" name="validate_build" guid="_0qrpwslgEdmt3adZL5Dmdw" presentationName="Validate Build" hasMultipleOccurrences="true" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <presentation xmi:id="_mtb_AfL5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb_AfL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0qxwYMlgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0qxwYMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0qxwYclgEdmt3adZL5Dmdw" name="ongoing_tasks" guid="_0qxwYclgEdmt3adZL5Dmdw" presentationName="Ongoing Tasks" isPlanned="false" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="_mtb_AvL5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb_AvL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0q33AMlgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0q33AMlgEdmt3adZL5Dmdw">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0q33AclgEdmt3adZL5Dmdw" name="manage_iteration" guid="_0q33AclgEdmt3adZL5Dmdw" presentationName="Plan and Manage Iteration" isPlanned="false" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" isOngoing="true" variabilityType="extends">
+ <presentation xmi:id="_mtb_APL5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb_APL5Edm6Nvont3uinw"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </processElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0CtdMPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_0CtdMPinEdmugcVr9AdHjQ">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0DMlYPinEdmugcVr9AdHjQ" name="develop_requirement_within_context" guid="_0DMlYPinEdmugcVr9AdHjQ" presentationName="Develop Solution (for requirement) (within context)" hasMultipleOccurrences="true" superActivities="_0rQRgMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ </processElements>
+ <diagrams xmi:id="_m0ZXADSDEduGhYMJfagftQ" guid="_m0ZXADSDEduGhYMJfagftQ">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69oE9HEdudU75l2xOQTw" guid="_6t69oE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69oU9HEdudU75l2xOQTw" x="168.0" y="12.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69ok9HEdudU75l2xOQTw" guid="_6t69ok9HEdudU75l2xOQTw" anchor="_6t69pE9HEdudU75l2xOQTw _6t69rE9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69o09HEdudU75l2xOQTw" guid="_6t69o09HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_TiPK8DLwEdueZPye-FaNgA"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_6t69pE9HEdudU75l2xOQTw" guid="_6t69pE9HEdudU75l2xOQTw" graphEdge="_6t69ok9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69pU9HEdudU75l2xOQTw" guid="_6t69pU9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69pk9HEdudU75l2xOQTw" guid="_6t69pk9HEdudU75l2xOQTw"/>
+ <size xmi:id="_6t69p09HEdudU75l2xOQTw" width="112.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69qE9HEdudU75l2xOQTw" guid="_6t69qE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69qU9HEdudU75l2xOQTw" x="178.0" y="99.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69qk9HEdudU75l2xOQTw" guid="_6t69qk9HEdudU75l2xOQTw" anchor="_6t69rk9HEdudU75l2xOQTw _6uBEQU9HEdudU75l2xOQTw">
+ <waypoints xmi:id="_6t69q09HEdudU75l2xOQTw" x="223.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_6t69rE9HEdudU75l2xOQTw" guid="_6t69rE9HEdudU75l2xOQTw" graphEdge="_6t69ok9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69rU9HEdudU75l2xOQTw" guid="_6t69rU9HEdudU75l2xOQTw" graphEdge="_6t694U9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69rk9HEdudU75l2xOQTw" guid="_6t69rk9HEdudU75l2xOQTw" graphEdge="_6t69qk9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69r09HEdudU75l2xOQTw" x="229.0" y="161.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69sE9HEdudU75l2xOQTw" guid="_6t69sE9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cL1KIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69sU9HEdudU75l2xOQTw" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69sk9HEdudU75l2xOQTw" guid="_6t69sk9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69s09HEdudU75l2xOQTw" x="28.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69tE9HEdudU75l2xOQTw" guid="_6t69tE9HEdudU75l2xOQTw" anchor="_6t69tk9HEdudU75l2xOQTw _6t6-C09HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_wbDz0c6VEdu_q7xi9VPgyA" guid="_wbDz0c6VEdu_q7xi9VPgyA" anchor="_wbDz0M6VEdu_q7xi9VPgyA _wbDz0s6VEdu_q7xi9VPgyA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_wbDz086VEdu_q7xi9VPgyA" guid="_wbDz086VEdu_q7xi9VPgyA">
+ <element xsi:type="org.eclipse.epf.uma:WorkOrder" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_c84V8MmJEduwrYVlQ9zp3w"/>
+ </semanticModel>
+ </contained>
+ <anchorage xmi:id="_6t69tU9HEdudU75l2xOQTw" guid="_6t69tU9HEdudU75l2xOQTw" graphEdge="_6t69-U9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69tk9HEdudU75l2xOQTw" guid="_6t69tk9HEdudU75l2xOQTw" graphEdge="_6t69tE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69t09HEdudU75l2xOQTw" x="101.0" y="286.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wbDz0M6VEdu_q7xi9VPgyA" guid="_wbDz0M6VEdu_q7xi9VPgyA" graphEdge="_wbDz0c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69uE9HEdudU75l2xOQTw" guid="_6t69uE9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_dAoEIL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69uU9HEdudU75l2xOQTw" width="106.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69uk9HEdudU75l2xOQTw" guid="_6t69uk9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69u09HEdudU75l2xOQTw" x="179.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69vE9HEdudU75l2xOQTw" guid="_6t69vE9HEdudU75l2xOQTw" anchor="_6t69v09HEdudU75l2xOQTw _6t69yE9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69vU9HEdudU75l2xOQTw" guid="_6t69vU9HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_6t69vk9HEdudU75l2xOQTw" guid="_6t69vk9HEdudU75l2xOQTw" graphEdge="_6t69-E9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69v09HEdudU75l2xOQTw" guid="_6t69v09HEdudU75l2xOQTw" graphEdge="_6t69vE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69wE9HEdudU75l2xOQTw" x="239.0" y="284.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69wU9HEdudU75l2xOQTw" guid="_6t69wU9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_cnzUcL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69wk9HEdudU75l2xOQTw" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69w09HEdudU75l2xOQTw" guid="_6t69w09HEdudU75l2xOQTw">
+ <position xmi:id="_6t69xE9HEdudU75l2xOQTw" x="191.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69xU9HEdudU75l2xOQTw" guid="_6t69xU9HEdudU75l2xOQTw" anchor="_6t69xk9HEdudU75l2xOQTw _6t6-DU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t69xk9HEdudU75l2xOQTw" guid="_6t69xk9HEdudU75l2xOQTw" graphEdge="_6t69xU9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69x09HEdudU75l2xOQTw" x="374.0" y="284.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t69yE9HEdudU75l2xOQTw" guid="_6t69yE9HEdudU75l2xOQTw" graphEdge="_6t69vE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69yU9HEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_wbDz0s6VEdu_q7xi9VPgyA" guid="_wbDz0s6VEdu_q7xi9VPgyA" graphEdge="_wbDz0c6VEdu_q7xi9VPgyA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69yk9HEdudU75l2xOQTw" guid="_6t69yk9HEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:TaskDescriptor" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_d4GesL-FEdqb7N6KIeDL8Q"/>
+ </semanticModel>
+ <size xmi:id="_6t69y09HEdudU75l2xOQTw" width="101.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69zE9HEdudU75l2xOQTw" guid="_6t69zE9HEdudU75l2xOQTw" briefDescription="_QPeqAERlEduP07d3x5Xi-g">
+ <position xmi:id="_6t69zU9HEdudU75l2xOQTw" x="25.0" y="111.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_BzU6EU9IEdudU75l2xOQTw" guid="_BzU6EU9IEdudU75l2xOQTw" anchor="_BzU6EE9IEdudU75l2xOQTw _BzU6Ek9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_BzU6EE9IEdudU75l2xOQTw" guid="_BzU6EE9IEdudU75l2xOQTw" graphEdge="_BzU6EU9IEdudU75l2xOQTw">
+ <position xmi:id="_BzU6E09IEdudU75l2xOQTw" x="37.0" y="119.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t690U9HEdudU75l2xOQTw" guid="_6t690U9HEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_6t690k9HEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t69309HEdudU75l2xOQTw" guid="_6t69309HEdudU75l2xOQTw" briefDescription="_SccQ0ERlEduP07d3x5Xi-g">
+ <position xmi:id="_6t694E9HEdudU75l2xOQTw" x="83.0" y="110.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t694U9HEdudU75l2xOQTw" guid="_6t694U9HEdudU75l2xOQTw" anchor="_6t695k9HEdudU75l2xOQTw _6t69rU9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t694k9HEdudU75l2xOQTw" guid="_6t694k9HEdudU75l2xOQTw" anchor="_6t696E9HEdudU75l2xOQTw _6uBEQ09HEdudU75l2xOQTw">
+ <waypoints xmi:id="_6t69409HEdudU75l2xOQTw" x="94.0" y="191.0"/>
+ </contained>
+ <anchorage xmi:id="_6t695k9HEdudU75l2xOQTw" guid="_6t695k9HEdudU75l2xOQTw" graphEdge="_6t694U9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69509HEdudU75l2xOQTw" x="22.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t696E9HEdudU75l2xOQTw" guid="_6t696E9HEdudU75l2xOQTw" graphEdge="_6t694k9HEdudU75l2xOQTw">
+ <position xmi:id="_6t696U9HEdudU75l2xOQTw" x="11.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_BzU6Ek9IEdudU75l2xOQTw" guid="_BzU6Ek9IEdudU75l2xOQTw" graphEdge="_BzU6EU9IEdudU75l2xOQTw">
+ <position xmi:id="_BzU6FE9IEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t696k9HEdudU75l2xOQTw" guid="_6t696k9HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_6t69609HEdudU75l2xOQTw" width="23.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t698U9HEdudU75l2xOQTw" name="Add Free Text" guid="_6t698U9HEdudU75l2xOQTw" briefDescription="_mXzzEERlEduP07d3x5Xi-g">
+ <property xmi:id="_6t698k9HEdudU75l2xOQTw" guid="_6t698k9HEdudU75l2xOQTw" key="free text" value="[small change]"/>
+ <position xmi:id="_6t69809HEdudU75l2xOQTw" x="106.0" y="105.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t699E9HEdudU75l2xOQTw" guid="_6t699E9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_6t699U9HEdudU75l2xOQTw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t699k9HEdudU75l2xOQTw" guid="_6t699k9HEdudU75l2xOQTw" briefDescription="_pfsxEERlEduP07d3x5Xi-g">
+ <position xmi:id="_6t69909HEdudU75l2xOQTw" x="42.0" y="232.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69-E9HEdudU75l2xOQTw" guid="_6t69-E9HEdudU75l2xOQTw" anchor="_6t69-09HEdudU75l2xOQTw _6t69vk9HEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t69-U9HEdudU75l2xOQTw" guid="_6t69-U9HEdudU75l2xOQTw" anchor="_6t69_U9HEdudU75l2xOQTw _6t69tU9HEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6t69-k9HEdudU75l2xOQTw" guid="_6t69-k9HEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_6t69-09HEdudU75l2xOQTw" guid="_6t69-09HEdudU75l2xOQTw" graphEdge="_6t69-E9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69_E9HEdudU75l2xOQTw" x="201.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t69_U9HEdudU75l2xOQTw" guid="_6t69_U9HEdudU75l2xOQTw" graphEdge="_6t69-U9HEdudU75l2xOQTw">
+ <position xmi:id="_6t69_k9HEdudU75l2xOQTw" x="38.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t69_09HEdudU75l2xOQTw" guid="_6t69_09HEdudU75l2xOQTw" graphEdge="_6uBEQE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-AE9HEdudU75l2xOQTw" x="116.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-AU9HEdudU75l2xOQTw" guid="_6t6-AU9HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_6t6-Ak9HEdudU75l2xOQTw" width="262.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-A09HEdudU75l2xOQTw" name="Add Free Text" guid="_6t6-A09HEdudU75l2xOQTw" briefDescription="_JJvg8ERmEduP07d3x5Xi-g">
+ <property xmi:id="_6t6-BE9HEdudU75l2xOQTw" guid="_6t6-BE9HEdudU75l2xOQTw" key="free text" value="[trivial change]"/>
+ <position xmi:id="_6t6-BU9HEdudU75l2xOQTw" x="98.0" y="153.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-Bk9HEdudU75l2xOQTw" guid="_6t6-Bk9HEdudU75l2xOQTw" typeInfo="free text"/>
+ <size xmi:id="_6t6-B09HEdudU75l2xOQTw" width="70.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-CE9HEdudU75l2xOQTw" guid="_6t6-CE9HEdudU75l2xOQTw" briefDescription="_MViukERmEduP07d3x5Xi-g">
+ <position xmi:id="_6t6-CU9HEdudU75l2xOQTw" x="42.0" y="382.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6t6-Ck9HEdudU75l2xOQTw" guid="_6t6-Ck9HEdudU75l2xOQTw" anchor="_6t6-D09HEdudU75l2xOQTw _6t6-FU9HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6t6-C09HEdudU75l2xOQTw" guid="_6t6-C09HEdudU75l2xOQTw" graphEdge="_6t69tE9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-DE9HEdudU75l2xOQTw" x="39.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t6-DU9HEdudU75l2xOQTw" guid="_6t6-DU9HEdudU75l2xOQTw" graphEdge="_6t69xU9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-Dk9HEdudU75l2xOQTw" x="199.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6t6-D09HEdudU75l2xOQTw" guid="_6t6-D09HEdudU75l2xOQTw" graphEdge="_6t6-Ck9HEdudU75l2xOQTw">
+ <position xmi:id="_6t6-EE9HEdudU75l2xOQTw" x="129.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-EU9HEdudU75l2xOQTw" guid="_6t6-EU9HEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_6t6-Ek9HEdudU75l2xOQTw" width="274.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-E09HEdudU75l2xOQTw" guid="_6t6-E09HEdudU75l2xOQTw" briefDescription="_UF-lAERmEduP07d3x5Xi-g">
+ <position xmi:id="_6t6-FE9HEdudU75l2xOQTw" x="160.0" y="410.0"/>
+ <anchorage xmi:id="_6t6-FU9HEdudU75l2xOQTw" guid="_6t6-FU9HEdudU75l2xOQTw" graphEdge="_6t6-Ck9HEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6t6-Fk9HEdudU75l2xOQTw" guid="_6t6-Fk9HEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_6t6-F09HEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6t6-GE9HEdudU75l2xOQTw" guid="_6t6-GE9HEdudU75l2xOQTw" briefDescription="_gEnEwERnEduP07d3x5Xi-g">
+ <position xmi:id="_6t6-GU9HEdudU75l2xOQTw" x="145.0" y="180.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6uBEQE9HEdudU75l2xOQTw" guid="_6uBEQE9HEdudU75l2xOQTw" anchor="_6uBERU9HEdudU75l2xOQTw _6t69_09HEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_6uBEQU9HEdudU75l2xOQTw" guid="_6uBEQU9HEdudU75l2xOQTw" graphEdge="_6t69qk9HEdudU75l2xOQTw">
+ <position xmi:id="_6uBEQk9HEdudU75l2xOQTw" x="27.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6uBEQ09HEdudU75l2xOQTw" guid="_6uBEQ09HEdudU75l2xOQTw" graphEdge="_6t694k9HEdudU75l2xOQTw">
+ <position xmi:id="_6uBERE9HEdudU75l2xOQTw" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6uBERU9HEdudU75l2xOQTw" guid="_6uBERU9HEdudU75l2xOQTw" graphEdge="_6uBEQE9HEdudU75l2xOQTw">
+ <position xmi:id="_6uBERk9HEdudU75l2xOQTw" x="13.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_6uBER09HEdudU75l2xOQTw" guid="_6uBER09HEdudU75l2xOQTw" typeInfo="decision node"/>
+ <size xmi:id="_6uBESE9HEdudU75l2xOQTw" width="28.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_m0ZXfDSDEduGhYMJfagftQ" guid="_m0ZXfDSDEduGhYMJfagftQ" presentation="Workflow" element="_0DMlYPinEdmugcVr9AdHjQ"/>
+ </diagrams>
+ </childPackages>
+ <diagrams xmi:id="_ZMDKENIWEdm9Cql_SeWu_A" guid="_ZMDKENIWEdm9Cql_SeWu_A">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKEdIWEdm9Cql_SeWu_A" guid="_ZMDKEdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKEtIWEdm9Cql_SeWu_A" x="205.0" y="96.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_GUJvodIZEdm9Cql_SeWu_A" guid="_GUJvodIZEdm9Cql_SeWu_A" anchor="_GUJvoNIZEdm9Cql_SeWu_A _GUJvotIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="_GA1LAtIZEdm9Cql_SeWu_A" guid="_GA1LAtIZEdm9Cql_SeWu_A" graphEdge="_GA1LAdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_GA1LBNIZEdm9Cql_SeWu_A" x="38.0" y="-15.0"/>
+ </anchorage>
+ <anchorage xmi:id="_GUJvoNIZEdm9Cql_SeWu_A" guid="_GUJvoNIZEdm9Cql_SeWu_A" graphEdge="_GUJvodIZEdm9Cql_SeWu_A">
+ <position xmi:id="_GUJvo9IZEdm9Cql_SeWu_A" x="38.0" y="31.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKE9IWEdm9Cql_SeWu_A" guid="_ZMDKE9IWEdm9Cql_SeWu_A" element="_0q33AclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ZMDKFNIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKFdIWEdm9Cql_SeWu_A" guid="_ZMDKFdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKFtIWEdm9Cql_SeWu_A" x="226.0" y="170.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_s1YcwdbaEdm9COXJE3Cq0g" guid="_s1YcwdbaEdm9COXJE3Cq0g" anchor="_s1YcwNbaEdm9COXJE3Cq0g _s1YcwtbaEdm9COXJE3Cq0g">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_s1w3QNbaEdm9COXJE3Cq0g" guid="_s1w3QNbaEdm9COXJE3Cq0g"/>
+ </contained>
+ <anchorage xmi:id="_s1YcwNbaEdm9COXJE3Cq0g" guid="_s1YcwNbaEdm9COXJE3Cq0g" graphEdge="_s1YcwdbaEdm9COXJE3Cq0g">
+ <position xmi:id="_s1Ycw9baEdm9COXJE3Cq0g" x="119.0" y="22.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKF9IWEdm9Cql_SeWu_A" guid="_ZMDKF9IWEdm9Cql_SeWu_A"/>
+ <size xmi:id="_ZMDKGNIWEdm9Cql_SeWu_A" width="246.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKGdIWEdm9Cql_SeWu_A" guid="_ZMDKGdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKGtIWEdm9Cql_SeWu_A" x="113.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Z0Cwwcm0EdqibaSI8nt1Ng" guid="_Z0Cwwcm0EdqibaSI8nt1Ng" anchor="_Z0CwwMm0EdqibaSI8nt1Ng _Z0Cwwsm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_s1YcwtbaEdm9COXJE3Cq0g" guid="_s1YcwtbaEdm9COXJE3Cq0g" graphEdge="_s1YcwdbaEdm9COXJE3Cq0g"/>
+ <anchorage xmi:id="_Y5ZGYsm0EdqibaSI8nt1Ng" guid="_Y5ZGYsm0EdqibaSI8nt1Ng" graphEdge="_Y5ZGYcm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_Z0CwwMm0EdqibaSI8nt1Ng" guid="_Z0CwwMm0EdqibaSI8nt1Ng" graphEdge="_Z0Cwwcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_Z0Cww8m0EdqibaSI8nt1Ng" x="484.0" y="257.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKG9IWEdm9Cql_SeWu_A" guid="_ZMDKG9IWEdm9Cql_SeWu_A" element="_0qrpwslgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ZMDKHNIWEdm9Cql_SeWu_A" width="80.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ZMDKHdIWEdm9Cql_SeWu_A" guid="_ZMDKHdIWEdm9Cql_SeWu_A">
+ <position xmi:id="_ZMDKHtIWEdm9Cql_SeWu_A" x="360.0" y="135.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Wi-usdIZEdm9Cql_SeWu_A" guid="_Wi-usdIZEdm9Cql_SeWu_A" anchor="_Wi-usNIZEdm9Cql_SeWu_A _Wi-ustIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="_WOz1gtIZEdm9Cql_SeWu_A" guid="_WOz1gtIZEdm9Cql_SeWu_A" graphEdge="_WOz1gdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_WOz1hNIZEdm9Cql_SeWu_A" x="36.0" y="-101.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Wi-usNIZEdm9Cql_SeWu_A" guid="_Wi-usNIZEdm9Cql_SeWu_A" graphEdge="_Wi-usdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_Wi-us9IZEdm9Cql_SeWu_A" x="37.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKH9IWEdm9Cql_SeWu_A" guid="_ZMDKH9IWEdm9Cql_SeWu_A" element="_0qxwYclgEdmt3adZL5Dmdw"/>
+ <size xmi:id="_ZMDKINIWEdm9Cql_SeWu_A" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="__-SZwNIYEdm9Cql_SeWu_A" guid="__-SZwNIYEdm9Cql_SeWu_A">
+ <position xmi:id="__-SZwdIYEdm9Cql_SeWu_A" x="77.0" y="8.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_FwkhcdIZEdm9Cql_SeWu_A" guid="_FwkhcdIZEdm9Cql_SeWu_A" anchor="_FwkhcNIZEdm9Cql_SeWu_A _FwkhctIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="_FwkhcNIZEdm9Cql_SeWu_A" guid="_FwkhcNIZEdm9Cql_SeWu_A" graphEdge="_FwkhcdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_Fwkhc9IZEdm9Cql_SeWu_A" x="7.0" y="10.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="__-SZwtIYEdm9Cql_SeWu_A" guid="__-SZwtIYEdm9Cql_SeWu_A" typeInfo="start node"/>
+ <size xmi:id="__-SZw9IYEdm9Cql_SeWu_A" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_ATOvANIZEdm9Cql_SeWu_A" guid="_ATOvANIZEdm9Cql_SeWu_A">
+ <position xmi:id="_ATOvAdIZEdm9Cql_SeWu_A" x="72.0" y="301.0"/>
+ <anchorage xmi:id="_G02o8tIZEdm9Cql_SeWu_A" guid="_G02o8tIZEdm9Cql_SeWu_A"/>
+ <anchorage xmi:id="__hx1okmeEduO0bs89Khm8Q" guid="__hx1okmeEduO0bs89Khm8Q" graphEdge="__hx1oUmeEduO0bs89Khm8Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_ATOvAtIZEdm9Cql_SeWu_A" guid="_ATOvAtIZEdm9Cql_SeWu_A" typeInfo="end node"/>
+ <size xmi:id="_ATOvA9IZEdm9Cql_SeWu_A" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_AyNxENIZEdm9Cql_SeWu_A" guid="_AyNxENIZEdm9Cql_SeWu_A">
+ <position xmi:id="_AyNxEdIZEdm9Cql_SeWu_A" x="20.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_GA1LAdIZEdm9Cql_SeWu_A" guid="_GA1LAdIZEdm9Cql_SeWu_A" anchor="_GA1LANIZEdm9Cql_SeWu_A _GA1LAtIZEdm9Cql_SeWu_A"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_WOz1gdIZEdm9Cql_SeWu_A" guid="_WOz1gdIZEdm9Cql_SeWu_A" anchor="_WOz1gNIZEdm9Cql_SeWu_A _WOz1gtIZEdm9Cql_SeWu_A"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_XdIjwcm0EdqibaSI8nt1Ng" guid="_XdIjwcm0EdqibaSI8nt1Ng" anchor="_XdIjwMm0EdqibaSI8nt1Ng _XdIjwsm0EdqibaSI8nt1Ng"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Y5ZGYcm0EdqibaSI8nt1Ng" guid="_Y5ZGYcm0EdqibaSI8nt1Ng" anchor="_Y5ZGYMm0EdqibaSI8nt1Ng _Y5ZGYsm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_FwkhctIZEdm9Cql_SeWu_A" guid="_FwkhctIZEdm9Cql_SeWu_A" graphEdge="_FwkhcdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_FwkhdNIZEdm9Cql_SeWu_A" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_GA1LANIZEdm9Cql_SeWu_A" guid="_GA1LANIZEdm9Cql_SeWu_A" graphEdge="_GA1LAdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_4-gsMNSKEdqANo9Ox5ktZQ" x="227.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_WOz1gNIZEdm9Cql_SeWu_A" guid="_WOz1gNIZEdm9Cql_SeWu_A" graphEdge="_WOz1gdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_8H10oNSKEdqANo9Ox5ktZQ" x="382.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_XdIjwMm0EdqibaSI8nt1Ng" guid="_XdIjwMm0EdqibaSI8nt1Ng" graphEdge="_XdIjwcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_wkOAcNSKEdqANo9Ox5ktZQ" x="49.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Y5ZGYMm0EdqibaSI8nt1Ng" guid="_Y5ZGYMm0EdqibaSI8nt1Ng" graphEdge="_Y5ZGYcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_13Lu4NSKEdqANo9Ox5ktZQ" x="133.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_AyNxEtIZEdm9Cql_SeWu_A" guid="_AyNxEtIZEdm9Cql_SeWu_A" typeInfo="synchnonization bar"/>
+ <size xmi:id="_AyNxE9IZEdm9Cql_SeWu_A" width="431.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_BocOcNIZEdm9Cql_SeWu_A" guid="_BocOcNIZEdm9Cql_SeWu_A">
+ <position xmi:id="_BocOcdIZEdm9Cql_SeWu_A" x="19.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_GhiEUdIZEdm9Cql_SeWu_A" guid="_GhiEUdIZEdm9Cql_SeWu_A" anchor="_GhiEUNIZEdm9Cql_SeWu_A"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__hx1oUmeEduO0bs89Khm8Q" guid="__hx1oUmeEduO0bs89Khm8Q" anchor="__hx1oEmeEduO0bs89Khm8Q __hx1okmeEduO0bs89Khm8Q"/>
+ <anchorage xmi:id="_GUJvotIZEdm9Cql_SeWu_A" guid="_GUJvotIZEdm9Cql_SeWu_A" graphEdge="_GUJvodIZEdm9Cql_SeWu_A">
+ <position xmi:id="_5o00gNSKEdqANo9Ox5ktZQ" x="227.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_GhiEUNIZEdm9Cql_SeWu_A" guid="_GhiEUNIZEdm9Cql_SeWu_A" graphEdge="_GhiEUdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_s3b98B_mEdqg2MzaRmO8tg" x="72.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Wi-ustIZEdm9Cql_SeWu_A" guid="_Wi-ustIZEdm9Cql_SeWu_A" graphEdge="_Wi-usdIZEdm9Cql_SeWu_A">
+ <position xmi:id="_7l160NSKEdqANo9Ox5ktZQ" x="383.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Ye14Ysm0EdqibaSI8nt1Ng" guid="_Ye14Ysm0EdqibaSI8nt1Ng" graphEdge="_Ye14Ycm0EdqibaSI8nt1Ng">
+ <position xmi:id="_tY4F0NSKEdqANo9Ox5ktZQ" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_Z0Cwwsm0EdqibaSI8nt1Ng" guid="_Z0Cwwsm0EdqibaSI8nt1Ng" graphEdge="_Z0Cwwcm0EdqibaSI8nt1Ng">
+ <position xmi:id="_0D_6ANSKEdqANo9Ox5ktZQ" x="133.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__hx1oEmeEduO0bs89Khm8Q" guid="__hx1oEmeEduO0bs89Khm8Q" graphEdge="__hx1oUmeEduO0bs89Khm8Q">
+ <position xmi:id="_Ze_lkEmfEduO0bs89Khm8Q" x="65.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_BocOctIZEdm9Cql_SeWu_A" guid="_BocOctIZEdm9Cql_SeWu_A" typeInfo="synchnonization bar"/>
+ <size xmi:id="_BocOc9IZEdm9Cql_SeWu_A" width="442.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_VAZscPr8EdmyhNQr5STrZQ" guid="_VAZscPr8EdmyhNQr5STrZQ">
+ <position xmi:id="_VAZscfr8EdmyhNQr5STrZQ" x="24.0" y="97.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ye14Ycm0EdqibaSI8nt1Ng" guid="_Ye14Ycm0EdqibaSI8nt1Ng" anchor="_Ye14YMm0EdqibaSI8nt1Ng _Ye14Ysm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_XdIjwsm0EdqibaSI8nt1Ng" guid="_XdIjwsm0EdqibaSI8nt1Ng" graphEdge="_XdIjwcm0EdqibaSI8nt1Ng"/>
+ <anchorage xmi:id="_Ye14YMm0EdqibaSI8nt1Ng" guid="_Ye14YMm0EdqibaSI8nt1Ng" graphEdge="_Ye14Ycm0EdqibaSI8nt1Ng">
+ <position xmi:id="_Ye14Y8m0EdqibaSI8nt1Ng" x="320.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_VAZscvr8EdmyhNQr5STrZQ" guid="_VAZscvr8EdmyhNQr5STrZQ" element="_0DMlYPinEdmugcVr9AdHjQ"/>
+ <size xmi:id="_VAZsc_r8EdmyhNQr5STrZQ" width="90.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZMDKJdIWEdm9Cql_SeWu_A" guid="_ZMDKJdIWEdm9Cql_SeWu_A" presentation="Workflow" element="_0rQRgMlgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:CapabilityPattern" xmi:id="_0rQRgMlgEdmt3adZL5Dmdw" name="transition_phase_iteration" guid="_0rQRgMlgEdmt3adZL5Dmdw" briefDescription="This iteration template defines the activities (and associated roles and work products) performed in a typical iteration in the Transition phase. Each activity and the related goals are described." presentationName="Transition Phase Iteration" isRepeatable="true" breakdownElements="_0q33AclgEdmt3adZL5Dmdw _0DMlYPinEdmugcVr9AdHjQ _0qrpwslgEdmt3adZL5Dmdw _0qxwYclgEdmt3adZL5Dmdw">
+ <ownedRules xmi:id="_1J_ocEbrEduez5pdMGsX2w" guid="_1J_ocEbrEduez5pdMGsX2w"/>
+ <presentation xmi:id="_mtb-__L5Edm6Nvont3uinw" href="uma://_mtb_AfL5Edm6Nvont3uinw#_mtb-__L5Edm6Nvont3uinw"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/Custom Categories.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/Custom Categories.xmi
new file mode 100644
index 0000000..2982bfa
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/Custom Categories.xmi
@@ -0,0 +1,2 @@
+<?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="_cyZ5EMfLEdmg9p6Pf0sWyw" name="Custom Categories,_pJXEIcfKEdmg9p6Pf0sWyw" guid="_cyZ5EMfLEdmg9p6Pf0sWyw"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/collab_commun_subprocess.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/collab_commun_subprocess.xmi
new file mode 100644
index 0000000..28fcef3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/collab_commun_subprocess.xmi
@@ -0,0 +1,23 @@
+<?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" epf:version="1.0.0" xmi:id="-NMF-a9hwKjzWNfHzzseDYQ" name="new_custom_category,_r8cVIEmbEdu0xduwSKie-w" guid="-NMF-a9hwKjzWNfHzzseDYQ" changeDate="2006-10-13T14:56:55.821-0700" version="1.0.0">
+ <mainDescription><p>
+ The communication and collaboration layer is the foundation for OpenUP, reflecting the collaborative nature of the
+ process. It contains all of the roles in OpenUP/Basic: Stakeholder, Analyst, Developer, Architect, Tester, Project
+ Manager, and Any Role.&nbsp;Team members taking on these roles need to collaborate to jointly capture and define the
+ intent of the stakeholders, to jointly develop the solution, and to jointly manage the project.
+</p>
+<p>
+ This foundational layer reflects and enables us to express the nature of self-organized teams, where team members must
+ broaden their perspectives of what their roles&nbsp;are and where their responsibilities end. As an example, the
+ Analyst cannot say “I documented the requirements, now it is up to the Developer to implement them.” The Analyst's job
+ is not primarily to document requirements; it is to communicate that the stakeholder intent is understood and reflected
+ in a validated build. Documenting requirements may help you&nbsp;achieve&nbsp;that objective, but it is only one of
+ many available tools. Other tools to use include working with developers on the design, working with testers on what
+ needs to be tested, and using the build to ensure that&nbsp;it does what the stakeholders need it to do.
+</p>
+<p>
+ To help the team to collaborate effectively, the foundational collaboration layer provides you with a set of <a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" guid="_HEu9QBOHEduCNqgZdt_OaA">practices</a> that have been shown to motivate effective collaboration. These practices
+ apply to work done in all sub-processes.<br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/core_principles_category.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/core_principles_category.xmi
new file mode 100644
index 0000000..feb6890
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/core_principles_category.xmi
@@ -0,0 +1,58 @@
+<?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" epf:version="1.0.0" xmi:id="-I2j8LuHkworb0Y3EIlWfDQ" name="core_principles,_HEu9QBOHEduCNqgZdt_OaA" guid="-I2j8LuHkworb0Y3EIlWfDQ" changeDate="2006-11-13T10:02:46.356-0800" version="1.0.0">
+ <mainDescription><h3>
+ OpenUP Core Principles
+</h3>
+<p>
+ OpenUP is based on four mutually supporting core principles:
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Collaborate to align interests and share understanding
+</h4>
+<p>
+ Software is created by people with different interests and skills who must work together to create software
+ effectively.
+</p>
+<p>
+ Therefore, practices that foster a healthy team environment are key to success. A healthy team environment enables
+ effective collaboration that align the interests of project participants (development team, quality assurance, product
+ stakeholders, customers) and helps project participants develop a shared understanding of the project.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Balance competing priorities to maximize stakeholder value
+</h4>
+<p>
+ Systems need to be developed by balancing different, and sometimes competing,&nbsp;perspectives. For example, do you
+ want to minimize cost by reusing an existing capability, or by custom developing the capability to get it to do exactly
+ what you want?
+</p>
+<p>
+ Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes Stakeholder
+ benefits and is compliant with constraints placed on the project. Achieving balance is a dynamic process, because, as
+ both the stakeholders and project participants learn more about the system, their priorities and constraints change.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Focus on articulating the architecture
+</h4>
+<p>
+ Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
+ proves difficult to evolve, reuse, or integrate without substantial rework. It’s also difficult to organize the team or
+ communicate ideas without the common technical focus that the architecture provides.
+</p>
+<p>
+ Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
+ essential technical decisions through the growing architecture.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<h4>
+ Evolve to continuously obtain feedback and improve
+</h4>
+<p>
+ It is usually not possible to know all stakeholders needs, be aware of all project risks, comprehend all project
+ technologies, or know how to effectively work with your colleagues. Even if it were possible to know all of this, some
+ of it is likely to change over the life of the project.
+</p>
+<p>
+ Therefore, divide the project into short, time-boxed iterations to demonstrate incremental value and to get early and
+ continuous feedback.<span style="mso-spacerun: yes">&nbsp;</span>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/getting_started_with_openup.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/getting_started_with_openup.xmi
new file mode 100644
index 0000000..57e10bf
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/getting_started_with_openup.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-zy1Q3NXKXbiCP_zrjTxwaQ" name="getting_started,_cp6ycBOGEduCNqgZdt_OaA" guid="-zy1Q3NXKXbiCP_zrjTxwaQ" authors="Jim Ruehlin" changeDate="2007-03-01T13:31:38.471-0800" version="1.0.0">
+ <keyConsiderations><p>
+ OpenUP/Basic is a process for small, co-located teams. It can be used as-is, but if your team has significantly
+ different characteristics the process should be modified or extended to address those needs.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/intent_subprocess.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/intent_subprocess.xmi
new file mode 100644
index 0000000..4b3d1dc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/intent_subprocess.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="-QRnsN2e6IQlSMaRts-wFNw" name="new_custom_category,_57_ZMEmbEdu0xduwSKie-w" guid="-QRnsN2e6IQlSMaRts-wFNw" changeDate="2006-09-29T14:16:21.596-0400" version="1.0.0">
+ <mainDescription><p>
+ The intent sub-process deals with how to channel the intent of stakeholders to the rest of the development team, to
+ ensure that validated builds with incremental capabilities reflect stakeholder intents. This is done by capturing and
+ communicating the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a>&nbsp;to all team members, and by translating the vision into test cases and
+ requirements of different types to allow the team to understand what capabilities needs to be delivered to address
+ stakeholder intent.
+</p>
+<p>
+ You find the most tasks for the intent sub-process in the <strong>Requirements</strong> discipline, and the task Create
+ Test Cases in the <strong>Test</strong> discipline. The corresponding work products are found under
+ <strong>Requirements</strong> and <strong>Test</strong> domains.
+</p>
+<p>
+ The intent sub-process is built upon the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">&nbsp;</a>layer. That layer constitutes the backbone of OpenUP in order to reflect the
+ following:
+</p>
+<ul>
+ <li>
+ all roles in OpenUP are involved in intent development to ensure that as a minimum, all team members properly
+ understand stakeholders’ intent.
+ </li>
+ <li>
+ make sure that the best practices for collaborative development provided in the collaboration layer guides any work
+ related to intent.
+ </li>
+</ul>
+<p>
+ The intent sub-process is written in such a way that your organization can modify it to fit your style of development
+ and stakeholder collaboration, without necessarily impacting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">Management</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">&nbsp;</a>and <a class="elementLink" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">Solution</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">&nbsp;</a>development .
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/introduction_to_openup_basic.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/introduction_to_openup_basic.xmi
new file mode 100644
index 0000000..051d531
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/introduction_to_openup_basic.xmi
@@ -0,0 +1,222 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-TfxeHO_AJxYCzXVva0kSzQ" name="new_custom_category,_BTJ_YMXwEduywMSzPTUUwA" guid="-TfxeHO_AJxYCzXVva0kSzQ" changeDate="2007-03-12T09:47:01.871-0700" version="1.0.0">
+ <mainDescription><table width="589" align="center" border="0">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <a
+ href="./../../openup_basic/customcategories/getting_started_with_openup,__cft0MXxEduywMSzPTUUwA.html"
+ guid="__cft0MXxEduywMSzPTUUwA"><img height="48" alt="getting started" src="./resources/GetStarted_48.gif" width="48"
+ usemap="#Map" border="0" /></a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA"><img height="48" alt="core principles" src="./resources/CorePrinciples_48.gif"
+ width="48" usemap="#Map2" border="0" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a href="./../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg"><img height="48" alt="roles" src="./resources/Roles_48.gif" width="48"
+ usemap="#Map3" border="0" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg"><img height="48" alt="work products" src="./resources/WorkProducts_48.gif" width="48"
+ usemap="#Map4" border="0" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a
+ href="./../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ"><img height="48" alt="disciplines" src="./resources/Disciplines_48.gif" width="48"
+ usemap="#Map5" border="0" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw"><img height="48" alt="lifecycle" src="./resources/LifeCycle_48.gif" width="48"
+ usemap="#Map6" border="0" /></a>
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/customcategories/getting_started_with_openup,__cft0MXxEduywMSzPTUUwA.html"
+ guid="__cft0MXxEduywMSzPTUUwA">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA">Core Principles</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ">Disciplines</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">Lifecycle</a>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ <strong>What is OpenUP/Basic?</strong>
+</p>
+<p>
+ OpenUP/Basic is an open source software development process designed for small, co-located teams who want to take an <a
+ class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/guidelines/agile_and_unified,_qg1IAK__EduMeuOwJ2MpeQ.html"
+ guid="_qg1IAK__EduMeuOwJ2MpeQ">agile approach</a> to development. OpenUP/Basic is an iterative process that is <a
+ class="elementLink"
+ href="./../../openup_basic/guidances/guidelines/minimal_complete_extensible,_Nm5vUK__EduMeuOwJ2MpeQ.html"
+ guid="_Nm5vUK__EduMeuOwJ2MpeQ">Minimal, Complete, and Extensible</a>. It&nbsp;values collaboration and stakeholder
+ value over unnecessary deliverables and formality.
+</p>
+<p>
+ OpenUP/Basic is organized into four major areas of content: Communication&nbsp;and Collaboration, Intent, Solution, and
+ Management.
+</p>
+<p align="center">
+ <img height="350" alt="Four major areas upon which the OpenUP/Basic content is organized"
+ src="./resources/OpenUp1_350.jpg" width="350" usemap="#Map7" border="0" /> <map id="Map7" name="Map7">
+ <area shape="RECT" alt="Stakeholder" coords="144,5,207,62"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ" />
+ <area shape="POLY" alt="Tester" coords="336,242,310,287,254,256,278,209"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw" />
+ <area shape="RECT" alt="Developer" coords="148,282,201,347"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmd" />
+ <area shape="POLY" alt="Architect" coords="66,199,14,232,40,283,96,249"
+ href="./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Project Manager" coords="11,118,68,146,99,91,50,52"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Analyst" coords="258,99,312,66,338,114,284,145"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw" />
+ <area shape="CIRCLE" alt="Communication and Collaboration" coords="176,176,47"
+ href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Management" coords="85,219,70,163,115,89,169,72,169,117,124,144,120,197"
+ href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Intent" coords="181,116,223,143,229,196,264,219,283,160,245,94,181,70"
+ href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Solution" coords="129,211,176,235,221,210,257,231,214,271,133,272,94,232"
+ href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" />
+ </map><br />
+ &nbsp;
+</p>
+<br />
+<br />
+<p>
+ OpenUP is characterized by four mutually supporting core principles:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA.html"
+ guid="_KkTIsMp7EdqC_NfSivunjA">Collaborate</a> to align interests and share understanding
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_balance,_ssG6MMvpEdqukPpotm3DYg.html"
+ guid="_ssG6MMvpEdqukPpotm3DYg">Balance</a> competing priorities (needs and technical costs) to maximize stakeholder
+ value
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_focus,_9gocwMvoEdqukPpotm3DYg.html"
+ guid="_9gocwMvoEdqukPpotm3DYg">Focus</a> on articulating the architecture to facilitate technical collaboration,
+ reduce risk, and minimize scrap and rework.
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/core_principle_evolve,_GXiogMvoEdqukPpotm3DYg.html"
+ guid="_GXiogMvoEdqukPpotm3DYg">Evolve</a> continuously to reduce risk, demonstrate results, and gain feedback from
+ the customer<br />
+ </li>
+</ul>
+<p>
+ OpenUP/Basic is ready to use as-is; nothing needs to be added or removed. It can also be extended in large and small
+ ways to add new development content or customize the process for your specific environment.
+</p>
+<p>
+ <strong>Who should use OpenUP/Basic?</strong>
+</p>
+<p>
+ OpenUP/Basic is most useful for four primary groups of users:
+</p>
+<ul>
+ <li>
+ Software development practitioners (developers, project managers, analysts, and testers) working together as a
+ project team
+ </li>
+ <li>
+ Stakeholders
+ </li>
+ <li>
+ Software process engineers
+ </li>
+ <li>
+ Instructors
+ </li>
+</ul>
+<p>
+ Software development practitioners can find guidance on what is required of them in the roles defined by OpenUP/Basic.
+ Each role describes a set of activities and artifacts that the role is responsible for. Guidance is also given on how
+ those roles collaborate.
+</p>
+<p>
+ Stakeholders will find guidance on what they may expect from the software development team and how the software will be
+ created. OpenUP/Basic also describes the stakeholders' responsibilities and how they can best work with the development
+ team to obtain software that meets their needs.
+</p>
+<p>
+ Software process engineers can use EPF Composer to extend and modify OpenUP/Basic. Modification may be as simple as
+ altering templates for work products or as sophisticated as adding activities necessary for creating software in your
+ specific environment, such as audits for safety-critical systems. In addition to modifying method content, process
+ engineers can add, change, or remove process flows to add organization-specific capability patterns.
+</p>
+<p>
+ OpenUP/Basic is appropriate for academic organizations also. As an open source process, it can serve as the basis for
+ software engineering courses and, when combined with the EPF Composer, courses in software process engineering.<br />
+</p></mainDescription>
+ <keyConsiderations><p>
+ Use OpenUP/Basic as-is when you have a small,&nbsp;co-located team.
+</p>
+<p>
+ Modify OpenUP/Basic for small teams with different circumstances, for instance a novel project or geographically
+ distributed team members.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/management_subprocess.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/management_subprocess.xmi
new file mode 100644
index 0000000..540b595
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/management_subprocess.xmi
@@ -0,0 +1,28 @@
+<?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" epf:version="1.0.0" xmi:id="-q8ubSlQ5miYcY1JXdj1fbQ" name="new_custom_category,_Aoz2gEmcEdu0xduwSKie-w" guid="-q8ubSlQ5miYcY1JXdj1fbQ" changeDate="2006-09-29T14:03:50.721-0400" version="1.0.0">
+ <mainDescription><p>
+ It is important to note that the Management sub-process is built on the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a>&nbsp;layer&nbsp;to reflect the collaborative nature
+ of management of an OpenUP project. The manager should not plan an iteration in isolation, and then tell the team
+ members their assignments. Instead, the manager should be more of a coach, involving the entire team in the planning
+ process to ensure that:
+</p>
+<ul>
+ <li>
+ Everybody’s knowledge is reflected in the plan
+ </li>
+ <li>
+ All team members estimate their own work
+ </li>
+ <li>
+ Each team member signs up to take on a task, rather than being told exactly what to do.
+ </li>
+</ul>
+<p>
+ You will find the tasks for the Management sub-process in the <strong>Project Management</strong> discipline and the
+ corresponding work products under Project Management domain.
+</p>
+<p>
+ The Management sub-process is written in such a way that your organization can modify it to fit your style of
+ development, without necessarily affecting how you deal with the other sub-processes of&nbsp;<a class="elementLink" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">Solution</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" guid="_HEVvgEmcEdu0xduwSKie-w">&nbsp;</a>and <a class="elementLink" href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" guid="_57_ZMEmbEdu0xduwSKie-w">Intent</a>.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/openup_basic_deprecated.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/openup_basic_deprecated.xmi
new file mode 100644
index 0000000..42e633e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/openup_basic_deprecated.xmi
@@ -0,0 +1,2 @@
+<?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" epf:version="1.0.0" xmi:id="-nY50CawHefla4zauYddVfw" name="openup_basic,_SEztkBOJEduCNqgZdt_OaA" guid="-nY50CawHefla4zauYddVfw" changeDate="2006-09-21T10:48:17.894-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/openup_basic_views.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/openup_basic_views.xmi
new file mode 100644
index 0000000..5b7d359
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/openup_basic_views.xmi
@@ -0,0 +1,4 @@
+<?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="-8uqXjzIOnt6LVDae6Uv_0w" name="openup_basic_views,_NIIYMBOJEduCNqgZdt_OaA" guid="-8uqXjzIOnt6LVDae6Uv_0w" changeDate="2006-08-22T15:16:33.704-0700">
+ <mainDescription>[to do]</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/CorePrinciples_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/CorePrinciples_48.gif
new file mode 100644
index 0000000..da5215c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/CorePrinciples_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/Disciplines_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/Disciplines_48.gif
new file mode 100644
index 0000000..36f36b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/Disciplines_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/GetStarted_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/GetStarted_48.gif
new file mode 100644
index 0000000..5839c94
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/GetStarted_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/LifeCycle_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/LifeCycle_48.gif
new file mode 100644
index 0000000..f7f4665
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/LifeCycle_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/OpenUp1_350.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/OpenUp1_350.jpg
new file mode 100644
index 0000000..0bb0b38
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/OpenUp1_350.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/Roles_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/Roles_48.gif
new file mode 100644
index 0000000..3fb662d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/Roles_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/WorkProducts_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/WorkProducts_48.gif
new file mode 100644
index 0000000..9554964
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/WorkProducts_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/about.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/about.gif
new file mode 100644
index 0000000..1316610
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/about.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/bookc.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/bookc.gif
new file mode 100644
index 0000000..7f2ab85
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/bookc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/bookcL.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/bookcL.gif
new file mode 100644
index 0000000..6c5b064
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/bookcL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/concept_dgm32.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/concept_dgm32.gif
new file mode 100644
index 0000000..fa195bd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/concept_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/concept_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/concept_obj.gif
new file mode 100644
index 0000000..03af38b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/concept_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/icon_introL.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/icon_introL.gif
new file mode 100644
index 0000000..1826cbd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/icon_introL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/mic.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/mic.gif
new file mode 100644
index 0000000..0b316db
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/mic.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/processicon.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/processicon.gif
new file mode 100644
index 0000000..c396682
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/processicon.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/roles_dgm32.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/roles_dgm32.gif
new file mode 100644
index 0000000..baa3d33
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/roles_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/roles_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/roles_obj.gif
new file mode 100644
index 0000000..90b1aae
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/roles_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproduct_dgm32.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproduct_dgm32.gif
new file mode 100644
index 0000000..009c9af
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproduct_dgm32.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproduct_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproduct_obj.gif
new file mode 100644
index 0000000..3e58c6f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproduct_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproducts_lg_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproducts_lg_obj.gif
new file mode 100644
index 0000000..deca591
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproducts_lg_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproducts_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproducts_obj.gif
new file mode 100644
index 0000000..2e097ce
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproducts_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproductstype_lg_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproductstype_lg_obj.gif
new file mode 100644
index 0000000..626c9fd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproductstype_lg_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproductstype_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproductstype_obj.gif
new file mode 100644
index 0000000..d04a7ad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/resources/workproductstype_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/solution_subprocess.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/solution_subprocess.xmi
new file mode 100644
index 0000000..c0f5041
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/solution_subprocess.xmi
@@ -0,0 +1,51 @@
+<?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" epf:version="1.0.0" xmi:id="-qwWeiX7WrSVHSluBe-J7yw" name="new_custom_category,_HEVvgEmcEdu0xduwSKie-w" guid="-qwWeiX7WrSVHSluBe-J7yw" changeDate="2006-09-29T14:25:13.091-0400" version="1.0.0">
+ <mainDescription><p>
+ The Solution sub-process, among others, guides how you perform the following actions:
+</p>
+<ul>
+ <li>
+ Determine architectural feasibility
+ </li>
+ <li>
+ Define architecture
+ </li>
+ <li>
+ Develop the architecture for, design, implement, and test a major change
+ </li>
+ <li>
+ Design, implement, and test a small change
+ </li>
+ <li>
+ Implement and test a trivial change
+ </li>
+ <li>
+ Test and validate builds of incrementally improved quality
+ </li>
+</ul>
+<p>
+ You find the tasks for this&nbsp;sub-process in the disciplines&nbsp;<strong>Analysis and Design,
+ Implementation,</strong> and <strong>Test</strong>, and the corresponding work products under the <strong>Architecture,
+ Development</strong>, and <strong>Test</strong> domains.
+</p>
+<p>
+ The Solution sub-process is built upon the foundational <a class="elementLink" href="./../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" guid="_r8cVIEmbEdu0xduwSKie-w">Collaboration and Communication</a>&nbsp;layer. This layer constitutes the backbone of
+ OpenUP to ensure that:
+</p>
+<ul>
+ <li>
+ All roles in OpenUP are involved in solution development
+ </li>
+ <li>
+ Validated builds are the responsibility of the entire team
+ </li>
+ <li>
+ Best practices for collaborative development guide development of the solution<strong>.</strong>
+ </li>
+</ul>
+<p>
+ The Solution sub-process is written in such a way that your organization can modify it to fit your style of
+ development, without necessarily affecting how you deal with the other sub-processes of <a class="elementLink" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">Management</a><a class="elementLinkWithUserText" href="./../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" guid="_Aoz2gEmcEdu0xduwSKie-w">&nbsp;</a>and <a class="elementLink" href="./../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" guid="_57_ZMEmbEdu0xduwSKie-w">Intent</a>.<br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/sub_processes.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/sub_processes.xmi
new file mode 100644
index 0000000..7fb7de3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/customcategories/sub_processes.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-1ZoXO1IRfkXUKej4bNv8cw" name="new_custom_category,_V2BQkEmbEdu0xduwSKie-w" guid="-1ZoXO1IRfkXUKej4bNv8cw" changeDate="2006-09-21T11:05:33.613-0700">
+ <mainDescription>&nbsp;</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/deliveryprocesses/openup_basic_process/content.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/deliveryprocesses/openup_basic_process/content.xmi
new file mode 100644
index 0000000..14062d2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/deliveryprocesses/openup_basic_process/content.xmi
@@ -0,0 +1,269 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" rmc:version="7.1.0" epf:version="1.0.0">
+ <org.eclipse.epf.uma:DeliveryProcessDescription xmi:id="_mtb-4PL5Edm6Nvont3uinw" guid="_mtb-4PL5Edm6Nvont3uinw">
+ <mainDescription><p> OpenUP/Basic is an iterative process with <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/concepts/core_principle_evolve,_GXiogMvoEdqukPpotm3DYg.html" guid="_GXiogMvoEdqukPpotm3DYg">iterations</a>&nbsp;distributed
+ throughout four <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html" guid="__7xOEC7aEdqHMdmRzC0-2g">phases</a>:
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html" guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>,
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html" guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>,
+ <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html" guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>,
+ and <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html" guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>.
+</p>
+<p> Each phase may have as many iterations as needed, depending on degree of novelty
+ of the business domain, technology being used, architectural complexity, and
+ project size, to name a few factors. </p>
+<p> To offer a quick start for teams to plan their iterations,&nbsp;OpenUP/Basic
+ provides&nbsp;work breakdown structure (WBS) templates for each iteration and
+ a WBS template for an end-to-end process. </p>
+<p> Iterations may have variable lengths, depending on project characteristics.
+ One-month iterations are typically recommended, because
+ this timeframe provides: </p>
+<ul>
+ <li> A reasonable amount of time for projects to
+ deliver meaningful increments in functionality. </li>
+ <li> Early and frequent customer feedback. </li>
+ <li> Timely management of risks and issues during the course of the project.
+ </li>
+</ul>
+<p> OpenUP/Basic is intended<strong> </strong>to
+ offer process guidance to small projects: </p>
+<ul>
+ <li>
+
+ <div class="O" style="mso-margin-left-alt: 216; mso-char-wrap: 1; mso-kinsoku-overflow: 1" v:shape="_x0000_s1026">
+ 3&nbsp;to&nbsp;6 people on the team </div>
+ </li>
+ <li>
+
+ <div class="O" style="mso-margin-left-alt: 216; mso-char-wrap: 1; mso-kinsoku-overflow: 1" v:shape="_x0000_s1026">
+ 3&nbsp;to&nbsp;6 months of work</div>
+ </li>
+</ul></mainDescription>
+ <purpose><p>
+ The purposes of this delivery process are to:
+</p>
+<ul>
+ <li>
+ Offer process guidance for small-scale projects
+ </li>
+ <li>
+ Allow project managers to create project plans based on the proposed work breakdown structures
+ </li>
+ <li>
+ Allow project managers to track status based on goals
+ </li>
+ <li>
+ Allow&nbsp;team members&nbsp;to understand how to perform their work to achieve project goals
+ </li>
+ <li>
+ Provide a complete, end-to-end delivery process that serves as an example for defining alternative delivery
+ processes
+ </li>
+</ul></purpose>
+ </org.eclipse.epf.uma:DeliveryProcessDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-aXO_Hxa-5gvaRMvpx9cngQ" name="lifecycle_objectives,_mRwHoMA9EdqSgKaj2SZBmg" guid="-aXO_Hxa-5gvaRMvpx9cngQ">
+ <mainDescription><p>
+ The Lifecycle Objectives Milestone is the first major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>, the following evaluation criteria should be met <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stakeholder concurrence on
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ scope definition,
+ </li>
+ <li>
+ initial cost/schedule estimates,
+ </li>
+ <li>
+ initial set of requirements defined and prioritized,
+ </li>
+ <li>
+ risks identified and mitigation strategies proposed.
+ </li>
+ </ul>
+ </li>
+</ul>
+<br />
+The project may be aborted or reconsidered if it fails to reach this milestone.<br /></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-KD_OqyKE74agcRb6I4YuAg" name="lifecycle_architecture,_RYHw4MA-EdqSgKaj2SZBmg" guid="-KD_OqyKE74agcRb6I4YuAg">
+ <mainDescription><p>
+ The Lifecycle Architecture Milestone is the&nbsp;second major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Elaboration, you should keep these&nbsp;evaluation
+ criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stability of Vision, requirements and Architecture.
+ </li>
+ <li>
+ Major risk elements addressed and resolved by testing and evaluating executable prototypes.
+ </li>
+ <li>
+ Construction iterations planned in sufficient detail and&nbsp;credibly estimated&nbsp;to allow the work to proceed.
+ </li>
+ <li>
+ Agreement of stakeholders that the current vision can be met if plans are executed to develop complete system on
+ top of current architecture.
+ </li>
+ <li>
+ Resourse expenditures versus planned expenditures are acceptable.<br />
+ </li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-zGLnE1j7yvWoX9mok6lLLQ" name="product_release,_X3F_cMA-EdqSgKaj2SZBmg" guid="-zGLnE1j7yvWoX9mok6lLLQ">
+ <mainDescription><p>
+ The Product Release Milestone is the last major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>, you decide if the objectives were met and <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/close_out_project,_0mMLUMlgEdmt3adZL5Dmdw.html" guid="_0mMLUMlgEdmt3adZL5Dmdw">close</a> the project.&nbsp;The evaluation criteria to keep in mind are <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Users satisfaction and product acceptance.
+ </li>
+ <li>
+ Stakeholders concurrence on acceptable resource expenditures versus planned expenditures.
+ </li>
+ <li>
+ Product is in production. A new development cycle for enhancements or maintenance may start.
+ </li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-R8Q0YMat1l4nMKZaSg7Law" name="initial_operational_capability,_TV_y0MA-EdqSgKaj2SZBmg" guid="-R8Q0YMat1l4nMKZaSg7Law">
+ <mainDescription><p>
+ The Initial Operational Capability&nbsp;Milestone is the&nbsp;third major project milestone. During iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Construction, you should keep these&nbsp;evaluation
+ criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Product release stable and mature enough to be deployed in the user community
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ the product is ready to be handed over to&nbsp;the users&nbsp;(beta)
+ </li>
+ <li>
+ all functionality has been developed and all alpha testing (if any) has been completed
+ </li>
+ <li>
+ in addition to the software, a user manual has been developed, and there is a description of the current
+ release
+ </li>
+ </ul>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <br />
+ </li>
+ <li>
+ Actual resource expenditures versus planned expenditures are acceptable
+ </li>
+</ul>
+<p>
+ In case the project fails to reach this milestone, an iteration can be added to Construction, thus postponing
+ Transition.
+</p></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-qk_QXyoSxOb2C-boCISB5g" name="lifecycle_objectives,_mRwHoMA9EdqSgKaj2SZBmg" guid="-qk_QXyoSxOb2C-boCISB5g">
+ <mainDescription><p> The Lifecycle Objectives Milestone is the first major project milestone. During
+ the iteration<a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw"> assessment</a>, the following evaluation criteria
+ should be met <a
+ class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>: </p>
+<ul>
+ <li>
+ Stakeholder concurrence on
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+
+ <li> scope definition</li>
+ <li> initial cost and schedule estimates</li>
+ <li>definitions and priorities for initial set of requirements</li>
+ <li>
+ risks identified and mitigation strategies proposed.
+ </li>
+ </ul>
+ </li>
+</ul>
+<p><br />
+ Note:<strong> </strong></p>
+<p>The project may be aborted or reconsidered if it fails to reach this milestone.<br /></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-3Ul1iAI1nkD0C5AsRtjHFA" name="lifecycle_architecture,_RYHw4MA-EdqSgKaj2SZBmg" guid="-3Ul1iAI1nkD0C5AsRtjHFA">
+ <mainDescription><p>
+ The Lifecycle Architecture Milestone is the&nbsp;second major project milestone. During iteration <a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Elaboration, you should keep these&nbsp;evaluation
+ criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ Stability of Vision, requirements and Architecture.
+ </li>
+ <li>
+ Major risk elements addressed and resolved by testing and evaluating executable prototypes.
+ </li>
+ <li>
+ Construction iterations planned in sufficient detail and&nbsp;credibly estimated&nbsp;to allow the work to proceed.
+ </li>
+ <li>
+ Agreement of stakeholders that the current vision can be met if plans are executed to develop complete system on
+ top of current architecture.
+ </li>
+ <li>
+ Resourse expenditures versus planned expenditures are acceptable.<br />
+ </li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-Q37Qy6ke_PQDK4jr1EIdcA" name="initial_operational_capability,_TV_y0MA-EdqSgKaj2SZBmg" guid="-Q37Qy6ke_PQDK4jr1EIdcA">
+ <mainDescription><p> The Initial Operational Capability&nbsp;Milestone is the&nbsp;third major
+ project milestone. During iteration <a
+ class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html"
+ guid="_0l53cMlgEdmt3adZL5Dmdw">assessments</a>&nbsp;in Construction, keep
+ these&nbsp;evaluation criteria&nbsp;in mind&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>: </p>
+<ul>
+
+ <li> Product release is stable and mature enough to be deployed in the user
+ community.</li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+
+ <li> The beta product is ready to be handed over to&nbsp;the users.</li>
+ <li> All functionality has been developed and all alpha testing (if any)
+ has been completed.</li>
+ <li> In addition to the software, a user manual has been developed, and
+ there is a description of the current release. </li>
+ </ul>
+ </li>
+ <li style="LIST-STYLE-TYPE: none"> </li>
+ <li> Actual resource expenditures compared to planned expenditures are acceptable.</li>
+</ul>
+<p> Note:<strong> </strong></p>
+<p>In case the project fails to reach this milestone, an iteration can be added
+ to Construction, thus postponing Transition. </p></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+ <org.eclipse.epf.uma:BreakdownElementDescription xmi:id="-Gt2aCyZVy4q1BvcJRM2E-A" name="product_release,_X3F_cMA-EdqSgKaj2SZBmg" guid="-Gt2aCyZVy4q1BvcJRM2E-A">
+ <mainDescription><p> The Product Release Milestone is the last major project milestone. During
+ iteration <a class="elementLinkWithUserText" href="./../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw">assessment</a>,
+ you decide if the objectives were met, and&nbsp;then close the project.&nbsp;These
+ are the evaluation criteria to keep in mind <a class="elementlinkwithusertext" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+
+ <li> Users satisfaction and product acceptance</li>
+
+ <li> Stakeholder concurrence on acceptable resource expenditures compared to
+ planned expenditures</li>
+
+ <li> Product is in production; therefore, a new development cycle for enhancements
+ or maintenance may start</li>
+</ul></mainDescription>
+ </org.eclipse.epf.uma:BreakdownElementDescription>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/deliveryprocesses/openup_basic_process/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/deliveryprocesses/openup_basic_process/model.xmi
new file mode 100644
index 0000000..963d474
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/deliveryprocesses/openup_basic_process/model.xmi
@@ -0,0 +1,1426 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nNtaYPL5Edm6Nvont3uinw" guid="_nNtaYPL5Edm6Nvont3uinw">
+ <resourceDescriptors xmi:id="_nNCE8_L5Edm6Nvont3uinw" id="_mtb-4fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4PVgEdmdHa9MmVPgqQ" id="_mtb-4vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4fVgEdmdHa9MmVPgqQ" id="_mtb-4_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4vVgEdmdHa9MmVPgqQ" id="_mtb-5PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUkz4_VgEdmdHa9MmVPgqQ" id="_mtb-5fL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUq6gPVgEdmdHa9MmVPgqQ" id="_mtb-5vL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUq6gfVgEdmdHa9MmVPgqQ" id="_mtb-5_L5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_SUq6gvVgEdmdHa9MmVPgqQ" id="_mtb-4PL5Edm6Nvont3uinw" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_sW9V0OqDEdqKGv75AZ0adQ" id="-aXO_Hxa-5gvaRMvpx9cngQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_fY-vkOqbEdqKGv75AZ0adQ" id="-KD_OqyKE74agcRb6I4YuAg" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_LMpNkOqlEdqS7vuq4kvZhg" id="-zGLnE1j7yvWoX9mok6lLLQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_X1zsgOqwEdqS7vuq4kvZhg" id="-R8Q0YMat1l4nMKZaSg7Law" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_CN-F0BOLEduCNqgZdt_OaA" id="-qk_QXyoSxOb2C-boCISB5g" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_COEMcBOLEduCNqgZdt_OaA" id="-3Ul1iAI1nkD0C5AsRtjHFA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_COQZsBOLEduCNqgZdt_OaA" id="-Q37Qy6ke_PQDK4jr1EIdcA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_COWgUBOLEduCNqgZdt_OaA" id="-Gt2aCyZVy4q1BvcJRM2E-A" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_0uHYQclgEdmt3adZL5Dmdw" name="openup_basic_process" guid="_0uHYQclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_xujGABOKEduCNqgZdt_OaA" name="inception_phase_iteration" guid="_xujGABOKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_xupMvxOKEduCNqgZdt_OaA" name="inception_phase_iteration" guid="_xupMvxOKEduCNqgZdt_OaA" presentationName="Inception Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0o3r4slgEdmt3adZL5Dmdw"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hmKgBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <diagrams xmi:id="_xujGAROKEduCNqgZdt_OaA" guid="_xujGAROKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGEhOKEduCNqgZdt_OaA" guid="_xujGEhOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMwhOKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGExOKEduCNqgZdt_OaA" guid="_xujGExOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMwxOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMtxOKEduCNqgZdt_OaA" guid="_xupMtxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMxBOKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xupMuROKEduCNqgZdt_OaA" guid="_xupMuROKEduCNqgZdt_OaA" anchor="_xupMuhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xupMuhOKEduCNqgZdt_OaA" guid="_xupMuhOKEduCNqgZdt_OaA" graphEdge="_xupMuROKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMxROKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMuBOKEduCNqgZdt_OaA" guid="_xupMuBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMxhOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGEBOKEduCNqgZdt_OaA" guid="_xujGEBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMxxOKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGEROKEduCNqgZdt_OaA" guid="_xujGEROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMyBOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGGhOKEduCNqgZdt_OaA" guid="_xujGGhOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMyROKEduCNqgZdt_OaA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGGxOKEduCNqgZdt_OaA" guid="_xujGGxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMyhOKEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGHBOKEduCNqgZdt_OaA" guid="_xujGHBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMyxOKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGHROKEduCNqgZdt_OaA" guid="_xujGHROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xupMzBOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMpROKEduCNqgZdt_OaA" guid="_xupMpROKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMzROKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xupMphOKEduCNqgZdt_OaA" guid="_xupMphOKEduCNqgZdt_OaA" anchor="_xupMqBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xupMqBOKEduCNqgZdt_OaA" guid="_xupMqBOKEduCNqgZdt_OaA" graphEdge="_xupMphOKEduCNqgZdt_OaA">
+ <position xmi:id="_xupMzhOKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMpxOKEduCNqgZdt_OaA" guid="_xupMpxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTQBOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGDhOKEduCNqgZdt_OaA" guid="_xujGDhOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTQROKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGDxOKEduCNqgZdt_OaA" guid="_xujGDxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTQhOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMqROKEduCNqgZdt_OaA" guid="_xupMqROKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTQxOKEduCNqgZdt_OaA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMqhOKEduCNqgZdt_OaA" guid="_xupMqhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTRBOKEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMuxOKEduCNqgZdt_OaA" guid="_xupMuxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTRROKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMvBOKEduCNqgZdt_OaA" guid="_xupMvBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTRhOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGQBOKEduCNqgZdt_OaA" guid="_xujGQBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTRxOKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xujGQxOKEduCNqgZdt_OaA" guid="_xujGQxOKEduCNqgZdt_OaA" anchor="_xujGQhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xujGQhOKEduCNqgZdt_OaA" guid="_xujGQhOKEduCNqgZdt_OaA" graphEdge="_xujGQxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTSBOKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGQROKEduCNqgZdt_OaA" guid="_xujGQROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTSROKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGRBOKEduCNqgZdt_OaA" guid="_xujGRBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTShOKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMoBOKEduCNqgZdt_OaA" guid="_xupMoBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTSxOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGFBOKEduCNqgZdt_OaA" guid="_xujGFBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTUBOKEduCNqgZdt_OaA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGFROKEduCNqgZdt_OaA" guid="_xujGFROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTUROKEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGDBOKEduCNqgZdt_OaA" guid="_xujGDBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTUhOKEduCNqgZdt_OaA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGDROKEduCNqgZdt_OaA" guid="_xujGDROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTUxOKEduCNqgZdt_OaA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMoROKEduCNqgZdt_OaA" guid="_xupMoROKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTXBOKEduCNqgZdt_OaA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xupMpBOKEduCNqgZdt_OaA" guid="_xupMpBOKEduCNqgZdt_OaA" anchor="_xupMoxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xupMoxOKEduCNqgZdt_OaA" guid="_xupMoxOKEduCNqgZdt_OaA" graphEdge="_xupMpBOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTXROKEduCNqgZdt_OaA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMohOKEduCNqgZdt_OaA" guid="_xupMohOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTXhOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xujGBxOKEduCNqgZdt_OaA" guid="_xujGBxOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTXxOKEduCNqgZdt_OaA" x="368.0" y="300.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_xujGChOKEduCNqgZdt_OaA" guid="_xujGChOKEduCNqgZdt_OaA" anchor="_xujGCROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xujGCxOKEduCNqgZdt_OaA" guid="_xujGCxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_xujGCROKEduCNqgZdt_OaA" guid="_xujGCROKEduCNqgZdt_OaA" graphEdge="_xujGChOKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTYBOKEduCNqgZdt_OaA" x="464.0" y="312.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGCBOKEduCNqgZdt_OaA" guid="_xujGCBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTYROKEduCNqgZdt_OaA" width="149.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_xupMvROKEduCNqgZdt_OaA" guid="_xupMvROKEduCNqgZdt_OaA">
+ <position xmi:id="_xuvTYhOKEduCNqgZdt_OaA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xupMvhOKEduCNqgZdt_OaA" guid="_xupMvhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_xuvTYxOKEduCNqgZdt_OaA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2QEqbEduiL77U_PmnmA" guid="_5gR2QEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2QUqbEduiL77U_PmnmA" x="111.0" y="102.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2QkqbEduiL77U_PmnmA" guid="_5gR2QkqbEduiL77U_PmnmA" anchor="_5gR2RUqbEduiL77U_PmnmA _5gR2hUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2Q0qbEduiL77U_PmnmA" guid="_5gR2Q0qbEduiL77U_PmnmA" graphEdge="_5gR2cEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2REqbEduiL77U_PmnmA" x="26.0" y="-28.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2RUqbEduiL77U_PmnmA" guid="_5gR2RUqbEduiL77U_PmnmA" graphEdge="_5gR2QkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2RkqbEduiL77U_PmnmA" x="25.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2R0qbEduiL77U_PmnmA" guid="_5gR2R0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdE8lgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_5gR2SEqbEduiL77U_PmnmA" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2SUqbEduiL77U_PmnmA" guid="_5gR2SUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2SkqbEduiL77U_PmnmA" x="146.0" y="157.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2S0qbEduiL77U_PmnmA" guid="_5gR2S0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2TEqbEduiL77U_PmnmA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2TUqbEduiL77U_PmnmA" guid="_5gR2TUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2TkqbEduiL77U_PmnmA" x="146.0" y="233.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2T0qbEduiL77U_PmnmA" guid="_5gR2T0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2UEqbEduiL77U_PmnmA" width="183.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2UUqbEduiL77U_PmnmA" guid="_5gR2UUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2UkqbEduiL77U_PmnmA" x="-25.0" y="204.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2U0qbEduiL77U_PmnmA" guid="_5gR2U0qbEduiL77U_PmnmA" anchor="_5gR2VkqbEduiL77U_PmnmA _5gR2jkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2VEqbEduiL77U_PmnmA" guid="_5gR2VEqbEduiL77U_PmnmA" graphEdge="_5gR2f0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2VUqbEduiL77U_PmnmA" x="100.0" y="-13.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2VkqbEduiL77U_PmnmA" guid="_5gR2VkqbEduiL77U_PmnmA" graphEdge="_5gR2U0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2V0qbEduiL77U_PmnmA" x="97.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2WEqbEduiL77U_PmnmA" guid="_5gR2WEqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0okw8clgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_5gR2WUqbEduiL77U_PmnmA" width="207.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2WkqbEduiL77U_PmnmA" guid="_5gR2WkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2W0qbEduiL77U_PmnmA" x="108.0" y="238.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2XEqbEduiL77U_PmnmA" guid="_5gR2XEqbEduiL77U_PmnmA" anchor="_5gR2X0qbEduiL77U_PmnmA _5gR2kEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2XUqbEduiL77U_PmnmA" guid="_5gR2XUqbEduiL77U_PmnmA" graphEdge="_5gR2gEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2XkqbEduiL77U_PmnmA" x="73.0" y="-85.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2X0qbEduiL77U_PmnmA" guid="_5gR2X0qbEduiL77U_PmnmA" graphEdge="_5gR2XEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2YEqbEduiL77U_PmnmA" x="79.0" y="23.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2YUqbEduiL77U_PmnmA" guid="_5gR2YUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oreoclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_5gR2YkqbEduiL77U_PmnmA" width="164.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2Y0qbEduiL77U_PmnmA" guid="_5gR2Y0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2ZEqbEduiL77U_PmnmA" x="123.0" y="254.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2ZUqbEduiL77U_PmnmA" guid="_5gR2ZUqbEduiL77U_PmnmA" anchor="_5gR2ZkqbEduiL77U_PmnmA _5gR2jEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2ZkqbEduiL77U_PmnmA" guid="_5gR2ZkqbEduiL77U_PmnmA" graphEdge="_5gR2ZUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2Z0qbEduiL77U_PmnmA" x="39.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2aEqbEduiL77U_PmnmA" guid="_5gR2aEqbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2aUqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2akqbEduiL77U_PmnmA" guid="_5gR2akqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2a0qbEduiL77U_PmnmA" x="300.0" y="136.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2bEqbEduiL77U_PmnmA" guid="_5gR2bEqbEduiL77U_PmnmA"/>
+ <size xmi:id="_5gR2bUqbEduiL77U_PmnmA" width="114.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2bkqbEduiL77U_PmnmA" guid="_5gR2bkqbEduiL77U_PmnmA" briefDescription="_boMAIPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2b0qbEduiL77U_PmnmA" x="5.0" y="68.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2cEqbEduiL77U_PmnmA" guid="_5gR2cEqbEduiL77U_PmnmA" anchor="_5gR2c0qbEduiL77U_PmnmA _5gR2Q0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2cUqbEduiL77U_PmnmA" guid="_5gR2cUqbEduiL77U_PmnmA" anchor="_5gR2dUqbEduiL77U_PmnmA _5gR2qUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2ckqbEduiL77U_PmnmA" guid="_5gR2ckqbEduiL77U_PmnmA" anchor="_5gR2eUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2c0qbEduiL77U_PmnmA" guid="_5gR2c0qbEduiL77U_PmnmA" graphEdge="_5gR2cEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2dEqbEduiL77U_PmnmA" x="145.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2dUqbEduiL77U_PmnmA" guid="_5gR2dUqbEduiL77U_PmnmA" graphEdge="_5gR2cUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2dkqbEduiL77U_PmnmA" x="332.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2d0qbEduiL77U_PmnmA" guid="_5gR2d0qbEduiL77U_PmnmA" graphEdge="_5gR2nEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2eEqbEduiL77U_PmnmA" x="179.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2eUqbEduiL77U_PmnmA" guid="_5gR2eUqbEduiL77U_PmnmA" graphEdge="_5gR2ckqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2ekqbEduiL77U_PmnmA" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2e0qbEduiL77U_PmnmA" guid="_5gR2e0qbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_5gR2fEqbEduiL77U_PmnmA" width="454.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2fUqbEduiL77U_PmnmA" guid="_5gR2fUqbEduiL77U_PmnmA" briefDescription="_cV9FEPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2fkqbEduiL77U_PmnmA" x="26.0" y="169.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2f0qbEduiL77U_PmnmA" guid="_5gR2f0qbEduiL77U_PmnmA" anchor="_5gR2gUqbEduiL77U_PmnmA _5gR2VEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2gEqbEduiL77U_PmnmA" guid="_5gR2gEqbEduiL77U_PmnmA" anchor="_5gR2g0qbEduiL77U_PmnmA _5gR2XUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2gUqbEduiL77U_PmnmA" guid="_5gR2gUqbEduiL77U_PmnmA" graphEdge="_5gR2f0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2gkqbEduiL77U_PmnmA" x="52.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2g0qbEduiL77U_PmnmA" guid="_5gR2g0qbEduiL77U_PmnmA" graphEdge="_5gR2gEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2hEqbEduiL77U_PmnmA" x="163.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2hUqbEduiL77U_PmnmA" guid="_5gR2hUqbEduiL77U_PmnmA" graphEdge="_5gR2QkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2hkqbEduiL77U_PmnmA" x="124.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2h0qbEduiL77U_PmnmA" guid="_5gR2h0qbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_5gR2iEqbEduiL77U_PmnmA" width="225.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2iUqbEduiL77U_PmnmA" guid="_5gR2iUqbEduiL77U_PmnmA" briefDescription="_f4q94Pr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2ikqbEduiL77U_PmnmA" x="4.0" y="344.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2i0qbEduiL77U_PmnmA" guid="_5gR2i0qbEduiL77U_PmnmA" anchor="_5gR2lEqbEduiL77U_PmnmA _5gR2o0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2jEqbEduiL77U_PmnmA" guid="_5gR2jEqbEduiL77U_PmnmA" graphEdge="_5gR2ZUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2jUqbEduiL77U_PmnmA" x="134.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2jkqbEduiL77U_PmnmA" guid="_5gR2jkqbEduiL77U_PmnmA" graphEdge="_5gR2U0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2j0qbEduiL77U_PmnmA" x="74.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2kEqbEduiL77U_PmnmA" guid="_5gR2kEqbEduiL77U_PmnmA" graphEdge="_5gR2XEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2kUqbEduiL77U_PmnmA" x="186.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2kkqbEduiL77U_PmnmA" guid="_5gR2kkqbEduiL77U_PmnmA" graphEdge="_5gR2qEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2k0qbEduiL77U_PmnmA" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2lEqbEduiL77U_PmnmA" guid="_5gR2lEqbEduiL77U_PmnmA" graphEdge="_5gR2i0qbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2lUqbEduiL77U_PmnmA" x="189.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2lkqbEduiL77U_PmnmA" guid="_5gR2lkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2l0qbEduiL77U_PmnmA" x="430.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2mEqbEduiL77U_PmnmA" guid="_5gR2mEqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_5gR2mUqbEduiL77U_PmnmA" width="463.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2mkqbEduiL77U_PmnmA" guid="_5gR2mkqbEduiL77U_PmnmA" briefDescription="_iEptQPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2m0qbEduiL77U_PmnmA" x="175.0" y="19.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2nEqbEduiL77U_PmnmA" guid="_5gR2nEqbEduiL77U_PmnmA" anchor="_5gR2nUqbEduiL77U_PmnmA _5gR2d0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2nUqbEduiL77U_PmnmA" guid="_5gR2nUqbEduiL77U_PmnmA" graphEdge="_5gR2nEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2nkqbEduiL77U_PmnmA" x="8.0" y="-1.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2n0qbEduiL77U_PmnmA" guid="_5gR2n0qbEduiL77U_PmnmA" typeInfo="start node"/>
+ <size xmi:id="_5gR2oEqbEduiL77U_PmnmA" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2oUqbEduiL77U_PmnmA" guid="_5gR2oUqbEduiL77U_PmnmA" briefDescription="_idu7oPr5EdmyhNQr5STrZQ">
+ <position xmi:id="_5gR2okqbEduiL77U_PmnmA" x="182.0" y="382.0"/>
+ <anchorage xmi:id="_5gR2o0qbEduiL77U_PmnmA" guid="_5gR2o0qbEduiL77U_PmnmA" graphEdge="_5gR2i0qbEduiL77U_PmnmA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5gR2pEqbEduiL77U_PmnmA" guid="_5gR2pEqbEduiL77U_PmnmA" typeInfo="end node"/>
+ <size xmi:id="_5gR2pUqbEduiL77U_PmnmA" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5gR2pkqbEduiL77U_PmnmA" guid="_5gR2pkqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2p0qbEduiL77U_PmnmA" x="296.0" y="145.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5gR2qEqbEduiL77U_PmnmA" guid="_5gR2qEqbEduiL77U_PmnmA" anchor="_5gR2q0qbEduiL77U_PmnmA _5gR2kkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_5gR2qUqbEduiL77U_PmnmA" guid="_5gR2qUqbEduiL77U_PmnmA" graphEdge="_5gR2cUqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2qkqbEduiL77U_PmnmA" x="33.0" y="-129.0"/>
+ </anchorage>
+ <anchorage xmi:id="_5gR2q0qbEduiL77U_PmnmA" guid="_5gR2q0qbEduiL77U_PmnmA" graphEdge="_5gR2qEqbEduiL77U_PmnmA">
+ <position xmi:id="_5gR2rEqbEduiL77U_PmnmA" x="39.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_5gR2rUqbEduiL77U_PmnmA" guid="_5gR2rUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_jLaKwP77Edm1zMZYtD3GjA"/>
+ </semanticModel>
+ <size xmi:id="_5gR2rkqbEduiL77U_PmnmA" width="83.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_xujGPxOKEduCNqgZdt_OaA" guid="_xujGPxOKEduCNqgZdt_OaA" presentation="Workflow" element="_xupMvxOKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0SpacBOKEduCNqgZdt_OaA" name="elaboration_phase_iteration" guid="_0SpacBOKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_0Spa4BOKEduCNqgZdt_OaA" name="elaboration_phase_iteration" guid="_0Spa4BOKEduCNqgZdt_OaA" presentationName="Elaboration Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" isRepeatable="true" linkToPredecessor="_8bf3QBOSEduCNqgZdt_OaA" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0sTaYMlgEdmt3adZL5Dmdw"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_2plxwBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_8bf3QBOSEduCNqgZdt_OaA" guid="_8bf3QBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_y1uwgBOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_0SpacROKEduCNqgZdt_OaA" guid="_0SpacROKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpalxOKEduCNqgZdt_OaA" guid="_0SpalxOKEduCNqgZdt_OaA">
+ <position xmi:id="_0Spa5xOKEduCNqgZdt_OaA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpamBOKEduCNqgZdt_OaA" guid="_0SpamBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0Spa6BOKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpavhOKEduCNqgZdt_OaA" guid="_0SpavhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0Spa6ROKEduCNqgZdt_OaA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpawROKEduCNqgZdt_OaA" guid="_0SpawROKEduCNqgZdt_OaA" anchor="_0SpavxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpavxOKEduCNqgZdt_OaA" guid="_0SpavxOKEduCNqgZdt_OaA" graphEdge="_0SpawROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhEBOKEduCNqgZdt_OaA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpawBOKEduCNqgZdt_OaA" guid="_0SpawBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhEROKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0Spa0BOKEduCNqgZdt_OaA" guid="_0Spa0BOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhEhOKEduCNqgZdt_OaA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0Spa0hOKEduCNqgZdt_OaA" guid="_0Spa0hOKEduCNqgZdt_OaA" anchor="_0Spa0ROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0Spa0ROKEduCNqgZdt_OaA" guid="_0Spa0ROKEduCNqgZdt_OaA" graphEdge="_0Spa0hOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhExOKEduCNqgZdt_OaA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0Spa0xOKEduCNqgZdt_OaA" guid="_0Spa0xOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhFBOKEduCNqgZdt_OaA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpamROKEduCNqgZdt_OaA" guid="_0SpamROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhFROKEduCNqgZdt_OaA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpamhOKEduCNqgZdt_OaA" guid="_0SpamhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhFhOKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpauhOKEduCNqgZdt_OaA" guid="_0SpauhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhFxOKEduCNqgZdt_OaA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpavROKEduCNqgZdt_OaA" guid="_0SpavROKEduCNqgZdt_OaA" anchor="_0SpavBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpavBOKEduCNqgZdt_OaA" guid="_0SpavBOKEduCNqgZdt_OaA" graphEdge="_0SpavROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhGBOKEduCNqgZdt_OaA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpauxOKEduCNqgZdt_OaA" guid="_0SpauxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhGROKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0Spa3BOKEduCNqgZdt_OaA" guid="_0Spa3BOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhGhOKEduCNqgZdt_OaA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0Spa3ROKEduCNqgZdt_OaA" guid="_0Spa3ROKEduCNqgZdt_OaA" anchor="_0Spa3xOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0Spa3xOKEduCNqgZdt_OaA" guid="_0Spa3xOKEduCNqgZdt_OaA" graphEdge="_0Spa3ROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhGxOKEduCNqgZdt_OaA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0Spa3hOKEduCNqgZdt_OaA" guid="_0Spa3hOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhHBOKEduCNqgZdt_OaA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpaqhOKEduCNqgZdt_OaA" guid="_0SpaqhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhKBOKEduCNqgZdt_OaA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpaqxOKEduCNqgZdt_OaA" guid="_0SpaqxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhKROKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpasROKEduCNqgZdt_OaA" guid="_0SpasROKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhLROKEduCNqgZdt_OaA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpasxOKEduCNqgZdt_OaA" guid="_0SpasxOKEduCNqgZdt_OaA" anchor="_0SpashOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpashOKEduCNqgZdt_OaA" guid="_0SpashOKEduCNqgZdt_OaA" graphEdge="_0SpasxOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhLhOKEduCNqgZdt_OaA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpatBOKEduCNqgZdt_OaA" guid="_0SpatBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhLxOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_0SpamxOKEduCNqgZdt_OaA" guid="_0SpamxOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhNROKEduCNqgZdt_OaA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_0SpanhOKEduCNqgZdt_OaA" guid="_0SpanhOKEduCNqgZdt_OaA" anchor="_0SpanBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_0SpanBOKEduCNqgZdt_OaA" guid="_0SpanBOKEduCNqgZdt_OaA" graphEdge="_0SpanhOKEduCNqgZdt_OaA">
+ <position xmi:id="_0SvhNhOKEduCNqgZdt_OaA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpanROKEduCNqgZdt_OaA" guid="_0SpanROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_0SvhNxOKEduCNqgZdt_OaA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lfukbtEduTiINs4_IZ_Q" guid="_32lfukbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfu0btEduTiINs4_IZ_Q" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lfvEbtEduTiINs4_IZ_Q" guid="_32lfvEbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lfvUbtEduTiINs4_IZ_Q" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lfxkbtEduTiINs4_IZ_Q" guid="_32lfxkbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfx0btEduTiINs4_IZ_Q" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_32lfyEbtEduTiINs4_IZ_Q" guid="_32lfyEbtEduTiINs4_IZ_Q" anchor="_32lfyUbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lfyUbtEduTiINs4_IZ_Q" guid="_32lfyUbtEduTiINs4_IZ_Q" graphEdge="_32lfyEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfykbtEduTiINs4_IZ_Q" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lfy0btEduTiINs4_IZ_Q" guid="_32lfy0btEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lfzEbtEduTiINs4_IZ_Q" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lfzUbtEduTiINs4_IZ_Q" guid="_32lfzUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lfzkbtEduTiINs4_IZ_Q" x="387.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_32lfz0btEduTiINs4_IZ_Q" guid="_32lfz0btEduTiINs4_IZ_Q" anchor="_32lf0UbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lf0EbtEduTiINs4_IZ_Q" guid="_32lf0EbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lf0UbtEduTiINs4_IZ_Q" guid="_32lf0UbtEduTiINs4_IZ_Q" graphEdge="_32lfz0btEduTiINs4_IZ_Q">
+ <position xmi:id="_32lf0kbtEduTiINs4_IZ_Q" x="525.0" y="388.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lf00btEduTiINs4_IZ_Q" guid="_32lf00btEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lf1EbtEduTiINs4_IZ_Q" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_32lf2kbtEduTiINs4_IZ_Q" guid="_32lf2kbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lf20btEduTiINs4_IZ_Q" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_32lf3EbtEduTiINs4_IZ_Q" guid="_32lf3EbtEduTiINs4_IZ_Q" anchor="_32lf3UbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_32lf3UbtEduTiINs4_IZ_Q" guid="_32lf3UbtEduTiINs4_IZ_Q" graphEdge="_32lf3EbtEduTiINs4_IZ_Q">
+ <position xmi:id="_32lf3kbtEduTiINs4_IZ_Q" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_32lf30btEduTiINs4_IZ_Q" guid="_32lf30btEduTiINs4_IZ_Q"/>
+ <size xmi:id="_32lf4EbtEduTiINs4_IZ_Q" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzIEqbEduiL77U_PmnmA" guid="_7BJzIEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzIUqbEduiL77U_PmnmA" x="338.0" y="74.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzIkqbEduiL77U_PmnmA" guid="_7BJzIkqbEduiL77U_PmnmA" anchor="_7BJzJEqbEduiL77U_PmnmA _7BJzkEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzI0qbEduiL77U_PmnmA" guid="_7BJzI0qbEduiL77U_PmnmA" graphEdge="_7BJzaEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzJEqbEduiL77U_PmnmA" guid="_7BJzJEqbEduiL77U_PmnmA" graphEdge="_7BJzIkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzJUqbEduiL77U_PmnmA" x="449.0" y="218.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzJkqbEduiL77U_PmnmA" guid="_7BJzJkqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIslgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzJ0qbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzKEqbEduiL77U_PmnmA" guid="_7BJzKEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzKUqbEduiL77U_PmnmA" x="-58.0" y="81.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzKkqbEduiL77U_PmnmA" guid="_7BJzKkqbEduiL77U_PmnmA" anchor="_7BJzLUqbEduiL77U_PmnmA _7BJzhkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzK0qbEduiL77U_PmnmA" guid="_7BJzK0qbEduiL77U_PmnmA" graphEdge="_7BJzY0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzLEqbEduiL77U_PmnmA" x="75.0" y="-62.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzLUqbEduiL77U_PmnmA" guid="_7BJzLUqbEduiL77U_PmnmA" graphEdge="_7BJzKkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzLkqbEduiL77U_PmnmA" x="78.0" y="24.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzL0qbEduiL77U_PmnmA" guid="_7BJzL0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0ruyoclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzMEqbEduiL77U_PmnmA" width="236.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzMUqbEduiL77U_PmnmA" guid="_7BJzMUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzMkqbEduiL77U_PmnmA" x="63.0" y="120.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzM0qbEduiL77U_PmnmA" guid="_7BJzM0qbEduiL77U_PmnmA" anchor="_7BJzNkqbEduiL77U_PmnmA _7BJziEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzNEqbEduiL77U_PmnmA" guid="_7BJzNEqbEduiL77U_PmnmA" graphEdge="_7BJzZEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzNUqbEduiL77U_PmnmA" x="18.0" y="-88.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzNkqbEduiL77U_PmnmA" guid="_7BJzNkqbEduiL77U_PmnmA" graphEdge="_7BJzM0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzN0qbEduiL77U_PmnmA" x="32.0" y="26.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzOEqbEduiL77U_PmnmA" guid="_7BJzOEqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rcewclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzOUqbEduiL77U_PmnmA" width="146.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzOkqbEduiL77U_PmnmA" guid="_7BJzOkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzO0qbEduiL77U_PmnmA" x="503.0" y="189.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzPEqbEduiL77U_PmnmA" guid="_7BJzPEqbEduiL77U_PmnmA"/>
+ <size xmi:id="_7BJzPUqbEduiL77U_PmnmA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzPkqbEduiL77U_PmnmA" guid="_7BJzPkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzP0qbEduiL77U_PmnmA" x="245.0" y="221.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzQEqbEduiL77U_PmnmA" guid="_7BJzQEqbEduiL77U_PmnmA" anchor="_7BJzQkqbEduiL77U_PmnmA _7BJzjkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzQUqbEduiL77U_PmnmA" guid="_7BJzQUqbEduiL77U_PmnmA" graphEdge="_7BJzZ0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzQkqbEduiL77U_PmnmA" guid="_7BJzQkqbEduiL77U_PmnmA" graphEdge="_7BJzQEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzQ0qbEduiL77U_PmnmA" x="612.0" y="243.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzREqbEduiL77U_PmnmA" guid="_7BJzREqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rilYclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzRUqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzRkqbEduiL77U_PmnmA" guid="_7BJzRkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzR0qbEduiL77U_PmnmA" x="678.0" y="256.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzSEqbEduiL77U_PmnmA" guid="_7BJzSEqbEduiL77U_PmnmA" anchor="_7BJzSUqbEduiL77U_PmnmA _7BJzikqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzSUqbEduiL77U_PmnmA" guid="_7BJzSUqbEduiL77U_PmnmA" graphEdge="_7BJzSEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzSkqbEduiL77U_PmnmA" x="0.0" y="35.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzS0qbEduiL77U_PmnmA" guid="_7BJzS0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_7BJzTEqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzTUqbEduiL77U_PmnmA" guid="_7BJzTUqbEduiL77U_PmnmA" briefDescription="_5VDG0NIWEdm9Cql_SeWu_A">
+ <position xmi:id="_7BJzTkqbEduiL77U_PmnmA" x="309.0" y="351.0"/>
+ <anchorage xmi:id="_7BJzT0qbEduiL77U_PmnmA" guid="_7BJzT0qbEduiL77U_PmnmA" graphEdge="_7BJzhUqbEduiL77U_PmnmA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzUEqbEduiL77U_PmnmA" guid="_7BJzUEqbEduiL77U_PmnmA" typeInfo="end node"/>
+ <size xmi:id="_7BJzUUqbEduiL77U_PmnmA" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzUkqbEduiL77U_PmnmA" guid="_7BJzUkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzU0qbEduiL77U_PmnmA" x="422.0" y="202.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzVEqbEduiL77U_PmnmA" guid="_7BJzVEqbEduiL77U_PmnmA" anchor="_7BJzVUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzVUqbEduiL77U_PmnmA" guid="_7BJzVUqbEduiL77U_PmnmA" graphEdge="_7BJzVEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzVkqbEduiL77U_PmnmA" x="-113.0" y="29.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzV0qbEduiL77U_PmnmA" guid="_7BJzV0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_7BJzWEqbEduiL77U_PmnmA" width="205.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzWUqbEduiL77U_PmnmA" guid="_7BJzWUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzWkqbEduiL77U_PmnmA" x="159.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzW0qbEduiL77U_PmnmA" guid="_7BJzW0qbEduiL77U_PmnmA" anchor="_7BJzXUqbEduiL77U_PmnmA _7BJzjEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzXEqbEduiL77U_PmnmA" guid="_7BJzXEqbEduiL77U_PmnmA" graphEdge="_7BJzZkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzXUqbEduiL77U_PmnmA" guid="_7BJzXUqbEduiL77U_PmnmA" graphEdge="_7BJzW0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzXkqbEduiL77U_PmnmA" x="466.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzX0qbEduiL77U_PmnmA" guid="_7BJzX0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_WrXvwPinEdmugcVr9AdHjQ"/>
+ </semanticModel>
+ <size xmi:id="_7BJzYEqbEduiL77U_PmnmA" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzYUqbEduiL77U_PmnmA" guid="_7BJzYUqbEduiL77U_PmnmA" briefDescription="_pKjjgPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_7BJzYkqbEduiL77U_PmnmA" x="11.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzY0qbEduiL77U_PmnmA" guid="_7BJzY0qbEduiL77U_PmnmA" anchor="_7BJzbEqbEduiL77U_PmnmA _7BJzK0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZEqbEduiL77U_PmnmA" guid="_7BJzZEqbEduiL77U_PmnmA" anchor="_7BJzbkqbEduiL77U_PmnmA _7BJzNEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZUqbEduiL77U_PmnmA" guid="_7BJzZUqbEduiL77U_PmnmA" anchor="_7BJzcEqbEduiL77U_PmnmA _7BJznUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZkqbEduiL77U_PmnmA" guid="_7BJzZkqbEduiL77U_PmnmA" anchor="_7BJzckqbEduiL77U_PmnmA _7BJzXEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzZ0qbEduiL77U_PmnmA" guid="_7BJzZ0qbEduiL77U_PmnmA" anchor="_7BJzdEqbEduiL77U_PmnmA _7BJzQUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzaEqbEduiL77U_PmnmA" guid="_7BJzaEqbEduiL77U_PmnmA" anchor="_7BJzdkqbEduiL77U_PmnmA _7BJzI0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzaUqbEduiL77U_PmnmA" guid="_7BJzaUqbEduiL77U_PmnmA" anchor="_7BJzeEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzakqbEduiL77U_PmnmA" guid="_7BJzakqbEduiL77U_PmnmA" graphEdge="_7BJzfkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJza0qbEduiL77U_PmnmA" x="312.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzbEqbEduiL77U_PmnmA" guid="_7BJzbEqbEduiL77U_PmnmA" graphEdge="_7BJzY0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzbUqbEduiL77U_PmnmA" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzbkqbEduiL77U_PmnmA" guid="_7BJzbkqbEduiL77U_PmnmA" graphEdge="_7BJzZEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzb0qbEduiL77U_PmnmA" x="125.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzcEqbEduiL77U_PmnmA" guid="_7BJzcEqbEduiL77U_PmnmA" graphEdge="_7BJzZUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzcUqbEduiL77U_PmnmA" x="474.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzckqbEduiL77U_PmnmA" guid="_7BJzckqbEduiL77U_PmnmA" graphEdge="_7BJzZkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzc0qbEduiL77U_PmnmA" x="197.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzdEqbEduiL77U_PmnmA" guid="_7BJzdEqbEduiL77U_PmnmA" graphEdge="_7BJzZ0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzdUqbEduiL77U_PmnmA" x="276.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzdkqbEduiL77U_PmnmA" guid="_7BJzdkqbEduiL77U_PmnmA" graphEdge="_7BJzaEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzd0qbEduiL77U_PmnmA" x="369.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzeEqbEduiL77U_PmnmA" guid="_7BJzeEqbEduiL77U_PmnmA" graphEdge="_7BJzaUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzeUqbEduiL77U_PmnmA" x="440.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzekqbEduiL77U_PmnmA" guid="_7BJzekqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_7BJze0qbEduiL77U_PmnmA" width="563.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzfEqbEduiL77U_PmnmA" guid="_7BJzfEqbEduiL77U_PmnmA" briefDescription="_zkKboPr6EdmyhNQr5STrZQ">
+ <position xmi:id="_7BJzfUqbEduiL77U_PmnmA" x="313.0" y="6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzfkqbEduiL77U_PmnmA" guid="_7BJzfkqbEduiL77U_PmnmA" anchor="_7BJzf0qbEduiL77U_PmnmA _7BJzakqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzf0qbEduiL77U_PmnmA" guid="_7BJzf0qbEduiL77U_PmnmA" graphEdge="_7BJzfkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzgEqbEduiL77U_PmnmA" x="-30.0" y="13.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzgUqbEduiL77U_PmnmA" guid="_7BJzgUqbEduiL77U_PmnmA" typeInfo="start node"/>
+ <size xmi:id="_7BJzgkqbEduiL77U_PmnmA" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzg0qbEduiL77U_PmnmA" guid="_7BJzg0qbEduiL77U_PmnmA" briefDescription="_045Z8Pr6EdmyhNQr5STrZQ">
+ <position xmi:id="_7BJzhEqbEduiL77U_PmnmA" x="6.0" y="317.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJzhUqbEduiL77U_PmnmA" guid="_7BJzhUqbEduiL77U_PmnmA" anchor="_7BJzlEqbEduiL77U_PmnmA _7BJzT0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJzhkqbEduiL77U_PmnmA" guid="_7BJzhkqbEduiL77U_PmnmA" graphEdge="_7BJzKkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzh0qbEduiL77U_PmnmA" x="53.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJziEqbEduiL77U_PmnmA" guid="_7BJziEqbEduiL77U_PmnmA" graphEdge="_7BJzM0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJziUqbEduiL77U_PmnmA" x="130.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzikqbEduiL77U_PmnmA" guid="_7BJzikqbEduiL77U_PmnmA" graphEdge="_7BJzSEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzi0qbEduiL77U_PmnmA" x="647.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzjEqbEduiL77U_PmnmA" guid="_7BJzjEqbEduiL77U_PmnmA" graphEdge="_7BJzW0qbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzjUqbEduiL77U_PmnmA" x="201.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzjkqbEduiL77U_PmnmA" guid="_7BJzjkqbEduiL77U_PmnmA" graphEdge="_7BJzQEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzj0qbEduiL77U_PmnmA" x="280.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzkEqbEduiL77U_PmnmA" guid="_7BJzkEqbEduiL77U_PmnmA" graphEdge="_7BJzIkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzkUqbEduiL77U_PmnmA" x="373.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzkkqbEduiL77U_PmnmA" guid="_7BJzkkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzk0qbEduiL77U_PmnmA" x="445.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzlEqbEduiL77U_PmnmA" guid="_7BJzlEqbEduiL77U_PmnmA" graphEdge="_7BJzhUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzlUqbEduiL77U_PmnmA" x="315.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzlkqbEduiL77U_PmnmA" guid="_7BJzlkqbEduiL77U_PmnmA" graphEdge="_7BJznEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzl0qbEduiL77U_PmnmA" x="480.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_7BJzmEqbEduiL77U_PmnmA" guid="_7BJzmEqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_7BJzmUqbEduiL77U_PmnmA" width="578.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_7BJzmkqbEduiL77U_PmnmA" guid="_7BJzmkqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzm0qbEduiL77U_PmnmA" x="436.0" y="164.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7BJznEqbEduiL77U_PmnmA" guid="_7BJznEqbEduiL77U_PmnmA" anchor="_7BJzn0qbEduiL77U_PmnmA _7BJzlkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_7BJznUqbEduiL77U_PmnmA" guid="_7BJznUqbEduiL77U_PmnmA" graphEdge="_7BJzZUqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJznkqbEduiL77U_PmnmA" x="651.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_7BJzn0qbEduiL77U_PmnmA" guid="_7BJzn0qbEduiL77U_PmnmA" graphEdge="_7BJznEqbEduiL77U_PmnmA">
+ <position xmi:id="_7BJzoEqbEduiL77U_PmnmA" x="548.0" y="181.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_7BJzoUqbEduiL77U_PmnmA" guid="_7BJzoUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_TAVx0CliEdqjQsaFX0CJTw"/>
+ </semanticModel>
+ <size xmi:id="_7BJzokqbEduiL77U_PmnmA" width="100.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_0SpapBOKEduCNqgZdt_OaA" guid="_0SpapBOKEduCNqgZdt_OaA" presentation="Workflow" element="_0Spa4BOKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_3CqrABOKEduCNqgZdt_OaA" name="construction_phase_iteration" guid="_3CqrABOKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_3CqrAROKEduCNqgZdt_OaA" name="construction_phase_iteration" guid="_3CqrAROKEduCNqgZdt_OaA" presentationName="Construction Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" isRepeatable="true" linkToPredecessor="_88coMBOSEduCNqgZdt_OaA" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-3IrutQEdqc1LGhiSPqRg"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_48EKsBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_88coMBOSEduCNqgZdt_OaA" guid="_88coMBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_16nd0BOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_3CqrAhOKEduCNqgZdt_OaA" guid="_3CqrAhOKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrVxOKEduCNqgZdt_OaA" guid="_3CqrVxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrhROKEduCNqgZdt_OaA" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrWROKEduCNqgZdt_OaA" guid="_3CqrWROKEduCNqgZdt_OaA" anchor="_3CqrWBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrWBOKEduCNqgZdt_OaA" guid="_3CqrWBOKEduCNqgZdt_OaA" graphEdge="_3CqrWROKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrhhOKEduCNqgZdt_OaA" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrWhOKEduCNqgZdt_OaA" guid="_3CqrWhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrhxOKEduCNqgZdt_OaA" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrXxOKEduCNqgZdt_OaA" guid="_3CqrXxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqriBOKEduCNqgZdt_OaA" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrYROKEduCNqgZdt_OaA" guid="_3CqrYROKEduCNqgZdt_OaA" anchor="_3CqrYxOKEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrYhOKEduCNqgZdt_OaA" guid="_3CqrYhOKEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_3CqrYxOKEduCNqgZdt_OaA" guid="_3CqrYxOKEduCNqgZdt_OaA" graphEdge="_3CqrYROKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqriROKEduCNqgZdt_OaA" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrYBOKEduCNqgZdt_OaA" guid="_3CqrYBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrihOKEduCNqgZdt_OaA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrWxOKEduCNqgZdt_OaA" guid="_3CqrWxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrjhOKEduCNqgZdt_OaA" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrXhOKEduCNqgZdt_OaA" guid="_3CqrXhOKEduCNqgZdt_OaA" anchor="_3CqrXBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrXBOKEduCNqgZdt_OaA" guid="_3CqrXBOKEduCNqgZdt_OaA" graphEdge="_3CqrXhOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrjxOKEduCNqgZdt_OaA" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrXROKEduCNqgZdt_OaA" guid="_3CqrXROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrkBOKEduCNqgZdt_OaA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrAxOKEduCNqgZdt_OaA" guid="_3CqrAxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrsxOKEduCNqgZdt_OaA" x="175.0" y="147.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrBxOKEduCNqgZdt_OaA" guid="_3CqrBxOKEduCNqgZdt_OaA" anchor="_3CqrBBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrBhOKEduCNqgZdt_OaA" guid="_3CqrBhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrBBOKEduCNqgZdt_OaA" guid="_3CqrBBOKEduCNqgZdt_OaA" graphEdge="_3CqrBxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrtBOKEduCNqgZdt_OaA" x="409.0" y="213.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrBROKEduCNqgZdt_OaA" guid="_3CqrBROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrtROKEduCNqgZdt_OaA" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrUhOKEduCNqgZdt_OaA" guid="_3CqrUhOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqruhOKEduCNqgZdt_OaA" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrUxOKEduCNqgZdt_OaA" guid="_3CqrUxOKEduCNqgZdt_OaA" anchor="_3CqrVBOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrVROKEduCNqgZdt_OaA" guid="_3CqrVROKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqruxOKEduCNqgZdt_OaA" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_3CqrVBOKEduCNqgZdt_OaA" guid="_3CqrVBOKEduCNqgZdt_OaA" graphEdge="_3CqrUxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrvBOKEduCNqgZdt_OaA" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrVhOKEduCNqgZdt_OaA" guid="_3CqrVhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CqrvROKEduCNqgZdt_OaA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrPxOKEduCNqgZdt_OaA" guid="_3CqrPxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CqrvhOKEduCNqgZdt_OaA" x="10.0" y="78.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrQxOKEduCNqgZdt_OaA" guid="_3CqrQxOKEduCNqgZdt_OaA" anchor="_3CqrQROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrQhOKEduCNqgZdt_OaA" guid="_3CqrQhOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrQROKEduCNqgZdt_OaA" guid="_3CqrQROKEduCNqgZdt_OaA" graphEdge="_3CqrQxOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CwxoBOKEduCNqgZdt_OaA" x="275.0" y="187.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrQBOKEduCNqgZdt_OaA" guid="_3CqrQBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CwxoROKEduCNqgZdt_OaA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_3CqrHBOKEduCNqgZdt_OaA" guid="_3CqrHBOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CwxohOKEduCNqgZdt_OaA" x="75.0" y="106.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_3CqrHhOKEduCNqgZdt_OaA" guid="_3CqrHhOKEduCNqgZdt_OaA" anchor="_3CqrHxOKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrHROKEduCNqgZdt_OaA" guid="_3CqrHROKEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_3CqrHxOKEduCNqgZdt_OaA" guid="_3CqrHxOKEduCNqgZdt_OaA" graphEdge="_3CqrHhOKEduCNqgZdt_OaA">
+ <position xmi:id="_3CwxoxOKEduCNqgZdt_OaA" x="385.0" y="244.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrIBOKEduCNqgZdt_OaA" guid="_3CqrIBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_3CwxpBOKEduCNqgZdt_OaA" width="136.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nZpLcETREduPB9JnYhkxmQ" guid="_nZpLcETREduPB9JnYhkxmQ">
+ <position xmi:id="_nZpLcUTREduPB9JnYhkxmQ" x="294.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nZpLckTREduPB9JnYhkxmQ" guid="_nZpLckTREduPB9JnYhkxmQ"/>
+ <size xmi:id="_nZpLc0TREduPB9JnYhkxmQ" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nZpLdETREduPB9JnYhkxmQ" guid="_nZpLdETREduPB9JnYhkxmQ">
+ <position xmi:id="_nZpLdUTREduPB9JnYhkxmQ" x="10.0" y="389.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nZpLdkTREduPB9JnYhkxmQ" guid="_nZpLdkTREduPB9JnYhkxmQ"/>
+ <size xmi:id="_nZpLd0TREduPB9JnYhkxmQ" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAWEbtEduTiINs4_IZ_Q" guid="_6YSAWEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAWUbtEduTiINs4_IZ_Q" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAWkbtEduTiINs4_IZ_Q" guid="_6YSAWkbtEduTiINs4_IZ_Q" anchor="_6YSAW0btEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAW0btEduTiINs4_IZ_Q" guid="_6YSAW0btEduTiINs4_IZ_Q" graphEdge="_6YSAWkbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAXEbtEduTiINs4_IZ_Q" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAXUbtEduTiINs4_IZ_Q" guid="_6YSAXUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAXkbtEduTiINs4_IZ_Q" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAX0btEduTiINs4_IZ_Q" guid="_6YSAX0btEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAYEbtEduTiINs4_IZ_Q" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAYUbtEduTiINs4_IZ_Q" guid="_6YSAYUbtEduTiINs4_IZ_Q" anchor="_6YSAY0btEduTiINs4_IZ_Q">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAYkbtEduTiINs4_IZ_Q" guid="_6YSAYkbtEduTiINs4_IZ_Q"/>
+ </contained>
+ <anchorage xmi:id="_6YSAY0btEduTiINs4_IZ_Q" guid="_6YSAY0btEduTiINs4_IZ_Q" graphEdge="_6YSAYUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAZEbtEduTiINs4_IZ_Q" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAZUbtEduTiINs4_IZ_Q" guid="_6YSAZUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAZkbtEduTiINs4_IZ_Q" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAcEbtEduTiINs4_IZ_Q" guid="_6YSAcEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAcUbtEduTiINs4_IZ_Q" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAckbtEduTiINs4_IZ_Q" guid="_6YSAckbtEduTiINs4_IZ_Q" anchor="_6YSAc0btEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAc0btEduTiINs4_IZ_Q" guid="_6YSAc0btEduTiINs4_IZ_Q" graphEdge="_6YSAckbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAdEbtEduTiINs4_IZ_Q" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAdUbtEduTiINs4_IZ_Q" guid="_6YSAdUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAdkbtEduTiINs4_IZ_Q" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YSAd0btEduTiINs4_IZ_Q" guid="_6YSAd0btEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAeEbtEduTiINs4_IZ_Q" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YSAeUbtEduTiINs4_IZ_Q" guid="_6YSAeUbtEduTiINs4_IZ_Q" anchor="_6YSAe0btEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAekbtEduTiINs4_IZ_Q" guid="_6YSAekbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YSAe0btEduTiINs4_IZ_Q" guid="_6YSAe0btEduTiINs4_IZ_Q" graphEdge="_6YSAeUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YSAfEbtEduTiINs4_IZ_Q" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YSAfUbtEduTiINs4_IZ_Q" guid="_6YSAfUbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YSAfkbtEduTiINs4_IZ_Q" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YYHQUbtEduTiINs4_IZ_Q" guid="_6YYHQUbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHQkbtEduTiINs4_IZ_Q" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YYHQ0btEduTiINs4_IZ_Q" guid="_6YYHQ0btEduTiINs4_IZ_Q" anchor="_6YYHRkbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YYHREbtEduTiINs4_IZ_Q" guid="_6YYHREbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHRUbtEduTiINs4_IZ_Q" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_6YYHRkbtEduTiINs4_IZ_Q" guid="_6YYHRkbtEduTiINs4_IZ_Q" graphEdge="_6YYHQ0btEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHR0btEduTiINs4_IZ_Q" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YYHSEbtEduTiINs4_IZ_Q" guid="_6YYHSEbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YYHSUbtEduTiINs4_IZ_Q" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6YYHSkbtEduTiINs4_IZ_Q" guid="_6YYHSkbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHS0btEduTiINs4_IZ_Q" x="385.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_6YYHTEbtEduTiINs4_IZ_Q" guid="_6YYHTEbtEduTiINs4_IZ_Q" anchor="_6YYHTkbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YYHTUbtEduTiINs4_IZ_Q" guid="_6YYHTUbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="_6YYHTkbtEduTiINs4_IZ_Q" guid="_6YYHTkbtEduTiINs4_IZ_Q" graphEdge="_6YYHTEbtEduTiINs4_IZ_Q">
+ <position xmi:id="_6YYHT0btEduTiINs4_IZ_Q" x="445.0" y="262.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6YYHUEbtEduTiINs4_IZ_Q" guid="_6YYHUEbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="_6YYHUUbtEduTiINs4_IZ_Q" width="129.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehiEqbEduiL77U_PmnmA" guid="_8jehiEqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehiUqbEduiL77U_PmnmA" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehikqbEduiL77U_PmnmA" guid="_8jehikqbEduiL77U_PmnmA" anchor="_8jehi0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jehi0qbEduiL77U_PmnmA" guid="_8jehi0qbEduiL77U_PmnmA" graphEdge="_8jehikqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehjEqbEduiL77U_PmnmA" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehjUqbEduiL77U_PmnmA" guid="_8jehjUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehjkqbEduiL77U_PmnmA" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehj0qbEduiL77U_PmnmA" guid="_8jehj0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jehkEqbEduiL77U_PmnmA" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehkUqbEduiL77U_PmnmA" guid="_8jehkUqbEduiL77U_PmnmA" anchor="_8jehk0qbEduiL77U_PmnmA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehkkqbEduiL77U_PmnmA" guid="_8jehkkqbEduiL77U_PmnmA"/>
+ </contained>
+ <anchorage xmi:id="_8jehk0qbEduiL77U_PmnmA" guid="_8jehk0qbEduiL77U_PmnmA" graphEdge="_8jehkUqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehlEqbEduiL77U_PmnmA" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehlUqbEduiL77U_PmnmA" guid="_8jehlUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehlkqbEduiL77U_PmnmA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehoEqbEduiL77U_PmnmA" guid="_8jehoEqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehoUqbEduiL77U_PmnmA" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehokqbEduiL77U_PmnmA" guid="_8jehokqbEduiL77U_PmnmA" anchor="_8jeho0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeho0qbEduiL77U_PmnmA" guid="_8jeho0qbEduiL77U_PmnmA" graphEdge="_8jehokqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehpEqbEduiL77U_PmnmA" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehpUqbEduiL77U_PmnmA" guid="_8jehpUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehpkqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jehp0qbEduiL77U_PmnmA" guid="_8jehp0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jehqEqbEduiL77U_PmnmA" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jehqUqbEduiL77U_PmnmA" guid="_8jehqUqbEduiL77U_PmnmA" anchor="_8jehq0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jehqkqbEduiL77U_PmnmA" guid="_8jehqkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jehq0qbEduiL77U_PmnmA" guid="_8jehq0qbEduiL77U_PmnmA" graphEdge="_8jehqUqbEduiL77U_PmnmA">
+ <position xmi:id="_8jehrEqbEduiL77U_PmnmA" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jehrUqbEduiL77U_PmnmA" guid="_8jehrUqbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jehrkqbEduiL77U_PmnmA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jeiDEqbEduiL77U_PmnmA" guid="_8jeiDEqbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiDUqbEduiL77U_PmnmA" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jeiDkqbEduiL77U_PmnmA" guid="_8jeiDkqbEduiL77U_PmnmA" anchor="_8jeiEUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeiD0qbEduiL77U_PmnmA" guid="_8jeiD0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiEEqbEduiL77U_PmnmA" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_8jeiEUqbEduiL77U_PmnmA" guid="_8jeiEUqbEduiL77U_PmnmA" graphEdge="_8jeiDkqbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiEkqbEduiL77U_PmnmA" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jeiE0qbEduiL77U_PmnmA" guid="_8jeiE0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jeiFEqbEduiL77U_PmnmA" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8jeiHUqbEduiL77U_PmnmA" guid="_8jeiHUqbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiHkqbEduiL77U_PmnmA" x="156.0" y="145.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8jeiH0qbEduiL77U_PmnmA" guid="_8jeiH0qbEduiL77U_PmnmA" anchor="_8jeiIUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeiIEqbEduiL77U_PmnmA" guid="_8jeiIEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_8jeiIUqbEduiL77U_PmnmA" guid="_8jeiIUqbEduiL77U_PmnmA" graphEdge="_8jeiH0qbEduiL77U_PmnmA">
+ <position xmi:id="_8jeiIkqbEduiL77U_PmnmA" x="203.0" y="165.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8jeiI0qbEduiL77U_PmnmA" guid="_8jeiI0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_8jeiJEqbEduiL77U_PmnmA" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQZ8E9IEdudU75l2xOQTw" guid="_nEQZ8E9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ8U9IEdudU75l2xOQTw" x="334.0" y="79.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQZ8k9IEdudU75l2xOQTw" guid="_nEQZ8k9IEdudU75l2xOQTw" anchor="_nEQZ9E9IEdudU75l2xOQTw _nEQaaE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQZ809IEdudU75l2xOQTw" guid="_nEQZ809IEdudU75l2xOQTw" graphEdge="_nEQaM09IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQZ9E9IEdudU75l2xOQTw" guid="_nEQZ9E9IEdudU75l2xOQTw" graphEdge="_nEQZ8k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ9U9IEdudU75l2xOQTw" x="488.0" y="118.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQZ9k9IEdudU75l2xOQTw" guid="_nEQZ9k9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-k0bOtQEdqc1LGhiSPqRg"/>
+ </semanticModel>
+ <size xmi:id="_nEQZ909IEdudU75l2xOQTw" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQZ-E9IEdudU75l2xOQTw" guid="_nEQZ-E9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ-U9IEdudU75l2xOQTw" x="213.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQZ-k9IEdudU75l2xOQTw" guid="_nEQZ-k9IEdudU75l2xOQTw" anchor="_nEQZ-09IEdudU75l2xOQTw _nEQaWE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQZ-09IEdudU75l2xOQTw" guid="_nEQZ-09IEdudU75l2xOQTw" graphEdge="_nEQZ-k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQZ_E9IEdudU75l2xOQTw" x="45.0" y="30.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQZ_U9IEdudU75l2xOQTw" guid="_nEQZ_U9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQZ_k9IEdudU75l2xOQTw" width="141.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQZ_09IEdudU75l2xOQTw" guid="_nEQZ_09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaAE9IEdudU75l2xOQTw" x="485.0" y="153.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaAU9IEdudU75l2xOQTw" guid="_nEQaAU9IEdudU75l2xOQTw" anchor="_nEQaA09IEdudU75l2xOQTw _nEQaCk9IEdudU75l2xOQTw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaAk9IEdudU75l2xOQTw" guid="_nEQaAk9IEdudU75l2xOQTw"/>
+ </contained>
+ <anchorage xmi:id="_nEQaA09IEdudU75l2xOQTw" guid="_nEQaA09IEdudU75l2xOQTw" graphEdge="_nEQaAU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaBE9IEdudU75l2xOQTw" x="49.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaBU9IEdudU75l2xOQTw" guid="_nEQaBU9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaBk9IEdudU75l2xOQTw" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaB09IEdudU75l2xOQTw" guid="_nEQaB09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaCE9IEdudU75l2xOQTw" x="245.0" y="215.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaCU9IEdudU75l2xOQTw" guid="_nEQaCU9IEdudU75l2xOQTw" anchor="_nEQaDE9IEdudU75l2xOQTw _nEQaZk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaCk9IEdudU75l2xOQTw" guid="_nEQaCk9IEdudU75l2xOQTw" graphEdge="_nEQaAU9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaC09IEdudU75l2xOQTw" guid="_nEQaC09IEdudU75l2xOQTw" graphEdge="_nEQaMk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaDE9IEdudU75l2xOQTw" guid="_nEQaDE9IEdudU75l2xOQTw" graphEdge="_nEQaCU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaDU9IEdudU75l2xOQTw" x="568.0" y="250.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaDk9IEdudU75l2xOQTw" guid="_nEQaDk9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-3IretQEdqc1LGhiSPqRg"/>
+ </semanticModel>
+ <size xmi:id="_nEQaD09IEdudU75l2xOQTw" width="96.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaEE9IEdudU75l2xOQTw" guid="_nEQaEE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaEU9IEdudU75l2xOQTw" x="634.0" y="165.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaEk9IEdudU75l2xOQTw" guid="_nEQaEk9IEdudU75l2xOQTw" anchor="_nEQaE09IEdudU75l2xOQTw _nEQaWk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaE09IEdudU75l2xOQTw" guid="_nEQaE09IEdudU75l2xOQTw" graphEdge="_nEQaEk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaFE9IEdudU75l2xOQTw" x="40.0" y="27.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaFU9IEdudU75l2xOQTw" guid="_nEQaFU9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaFk9IEdudU75l2xOQTw" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaF09IEdudU75l2xOQTw" guid="_nEQaF09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaGE9IEdudU75l2xOQTw" x="382.0" y="236.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaGU9IEdudU75l2xOQTw" guid="_nEQaGU9IEdudU75l2xOQTw" anchor="_nEQaG09IEdudU75l2xOQTw _nEQaak9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaGk9IEdudU75l2xOQTw" guid="_nEQaGk9IEdudU75l2xOQTw" graphEdge="_nEQaNE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaG09IEdudU75l2xOQTw" guid="_nEQaG09IEdudU75l2xOQTw" graphEdge="_nEQaGU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaHE9IEdudU75l2xOQTw" x="544.0" y="272.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaHU9IEdudU75l2xOQTw" guid="_nEQaHU9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaHk9IEdudU75l2xOQTw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaH09IEdudU75l2xOQTw" guid="_nEQaH09IEdudU75l2xOQTw" briefDescription="_y-k0N-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaIE9IEdudU75l2xOQTw" x="306.0" y="10.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaIU9IEdudU75l2xOQTw" guid="_nEQaIU9IEdudU75l2xOQTw" anchor="_nEQaIk9IEdudU75l2xOQTw _nEQaOU9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaIk9IEdudU75l2xOQTw" guid="_nEQaIk9IEdudU75l2xOQTw" graphEdge="_nEQaIU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaI09IEdudU75l2xOQTw" x="10.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQaJE9IEdudU75l2xOQTw" guid="_nEQaJE9IEdudU75l2xOQTw" typeInfo="start node"/>
+ <size xmi:id="_nEQaJU9IEdudU75l2xOQTw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaJk9IEdudU75l2xOQTw" guid="_nEQaJk9IEdudU75l2xOQTw" briefDescription="_y-k0O-tQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaJ09IEdudU75l2xOQTw" x="298.0" y="354.0"/>
+ <anchorage xmi:id="_nEQaKE9IEdudU75l2xOQTw" guid="_nEQaKE9IEdudU75l2xOQTw" graphEdge="_nEQaV09IEdudU75l2xOQTw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQaKU9IEdudU75l2xOQTw" guid="_nEQaKU9IEdudU75l2xOQTw" typeInfo="end node"/>
+ <size xmi:id="_nEQaKk9IEdudU75l2xOQTw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaK09IEdudU75l2xOQTw" guid="_nEQaK09IEdudU75l2xOQTw" briefDescription="_y-k0GutQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaLE9IEdudU75l2xOQTw" x="42.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaLU9IEdudU75l2xOQTw" guid="_nEQaLU9IEdudU75l2xOQTw" anchor="_nEQaO09IEdudU75l2xOQTw _nEQae09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaLk9IEdudU75l2xOQTw" guid="_nEQaLk9IEdudU75l2xOQTw" anchor="_nEQaPU9IEdudU75l2xOQTw _nEQahE9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaL09IEdudU75l2xOQTw" guid="_nEQaL09IEdudU75l2xOQTw" anchor="_nEQaP09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaME9IEdudU75l2xOQTw" guid="_nEQaME9IEdudU75l2xOQTw" anchor="_nEQaQU9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaMU9IEdudU75l2xOQTw" guid="_nEQaMU9IEdudU75l2xOQTw" anchor="_nEQaQ09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaMk9IEdudU75l2xOQTw" guid="_nEQaMk9IEdudU75l2xOQTw" anchor="_nEQaRU9IEdudU75l2xOQTw _nEQaC09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaM09IEdudU75l2xOQTw" guid="_nEQaM09IEdudU75l2xOQTw" anchor="_nEQaR09IEdudU75l2xOQTw _nEQZ809IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaNE9IEdudU75l2xOQTw" guid="_nEQaNE9IEdudU75l2xOQTw" anchor="_nEQaSU9IEdudU75l2xOQTw _nEQaGk9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaNU9IEdudU75l2xOQTw" guid="_nEQaNU9IEdudU75l2xOQTw" anchor="_nEQaS09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaNk9IEdudU75l2xOQTw" guid="_nEQaNk9IEdudU75l2xOQTw" anchor="_nEQaTU9IEdudU75l2xOQTw _nEQajU9IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaN09IEdudU75l2xOQTw" guid="_nEQaN09IEdudU75l2xOQTw" anchor="_nEQaT09IEdudU75l2xOQTw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaOE9IEdudU75l2xOQTw" guid="_nEQaOE9IEdudU75l2xOQTw" anchor="_nEQaUU9IEdudU75l2xOQTw _nEQalU9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaOU9IEdudU75l2xOQTw" guid="_nEQaOU9IEdudU75l2xOQTw" graphEdge="_nEQaIU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaOk9IEdudU75l2xOQTw" x="273.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaO09IEdudU75l2xOQTw" guid="_nEQaO09IEdudU75l2xOQTw" graphEdge="_nEQaLU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaPE9IEdudU75l2xOQTw" x="477.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaPU9IEdudU75l2xOQTw" guid="_nEQaPU9IEdudU75l2xOQTw" graphEdge="_nEQaLk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaPk9IEdudU75l2xOQTw" x="162.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaP09IEdudU75l2xOQTw" guid="_nEQaP09IEdudU75l2xOQTw" graphEdge="_nEQaL09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaQE9IEdudU75l2xOQTw" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaQU9IEdudU75l2xOQTw" guid="_nEQaQU9IEdudU75l2xOQTw" graphEdge="_nEQaME9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaQk9IEdudU75l2xOQTw" x="101.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaQ09IEdudU75l2xOQTw" guid="_nEQaQ09IEdudU75l2xOQTw" graphEdge="_nEQaMU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaRE9IEdudU75l2xOQTw" x="175.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaRU9IEdudU75l2xOQTw" guid="_nEQaRU9IEdudU75l2xOQTw" graphEdge="_nEQaMk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaRk9IEdudU75l2xOQTw" x="251.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaR09IEdudU75l2xOQTw" guid="_nEQaR09IEdudU75l2xOQTw" graphEdge="_nEQaM09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaSE9IEdudU75l2xOQTw" x="333.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaSU9IEdudU75l2xOQTw" guid="_nEQaSU9IEdudU75l2xOQTw" graphEdge="_nEQaNE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaSk9IEdudU75l2xOQTw" x="393.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaS09IEdudU75l2xOQTw" guid="_nEQaS09IEdudU75l2xOQTw" graphEdge="_nEQaNU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaTE9IEdudU75l2xOQTw" x="407.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaTU9IEdudU75l2xOQTw" guid="_nEQaTU9IEdudU75l2xOQTw" graphEdge="_nEQaNk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaTk9IEdudU75l2xOQTw" x="59.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaT09IEdudU75l2xOQTw" guid="_nEQaT09IEdudU75l2xOQTw" graphEdge="_nEQaN09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaUE9IEdudU75l2xOQTw" x="159.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaUU9IEdudU75l2xOQTw" guid="_nEQaUU9IEdudU75l2xOQTw" graphEdge="_nEQaOE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaUk9IEdudU75l2xOQTw" x="151.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQaU09IEdudU75l2xOQTw" guid="_nEQaU09IEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nEQaVE9IEdudU75l2xOQTw" width="523.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaVU9IEdudU75l2xOQTw" guid="_nEQaVU9IEdudU75l2xOQTw" briefDescription="_y-k0XOtQEdqc1LGhiSPqRg">
+ <position xmi:id="_nEQaVk9IEdudU75l2xOQTw" x="47.0" y="313.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaV09IEdudU75l2xOQTw" guid="_nEQaV09IEdudU75l2xOQTw" anchor="_nEQabE9IEdudU75l2xOQTw _nEQaKE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQaWE9IEdudU75l2xOQTw" guid="_nEQaWE9IEdudU75l2xOQTw" graphEdge="_nEQZ-k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaWU9IEdudU75l2xOQTw" x="148.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaWk9IEdudU75l2xOQTw" guid="_nEQaWk9IEdudU75l2xOQTw" graphEdge="_nEQaEk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaW09IEdudU75l2xOQTw" x="542.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaXE9IEdudU75l2xOQTw" guid="_nEQaXE9IEdudU75l2xOQTw" graphEdge="_nEQaek9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaXU9IEdudU75l2xOQTw" x="472.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaXk9IEdudU75l2xOQTw" guid="_nEQaXk9IEdudU75l2xOQTw" graphEdge="_nEQag09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaX09IEdudU75l2xOQTw" x="151.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaYE9IEdudU75l2xOQTw" guid="_nEQaYE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaYU9IEdudU75l2xOQTw" x="16.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaYk9IEdudU75l2xOQTw" guid="_nEQaYk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaY09IEdudU75l2xOQTw" x="95.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaZE9IEdudU75l2xOQTw" guid="_nEQaZE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaZU9IEdudU75l2xOQTw" x="170.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaZk9IEdudU75l2xOQTw" guid="_nEQaZk9IEdudU75l2xOQTw" graphEdge="_nEQaCU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaZ09IEdudU75l2xOQTw" x="246.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaaE9IEdudU75l2xOQTw" guid="_nEQaaE9IEdudU75l2xOQTw" graphEdge="_nEQZ8k9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaaU9IEdudU75l2xOQTw" x="328.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQaak9IEdudU75l2xOQTw" guid="_nEQaak9IEdudU75l2xOQTw" graphEdge="_nEQaGU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaa09IEdudU75l2xOQTw" x="387.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQabE9IEdudU75l2xOQTw" guid="_nEQabE9IEdudU75l2xOQTw" graphEdge="_nEQaV09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQabU9IEdudU75l2xOQTw" x="262.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQabk9IEdudU75l2xOQTw" guid="_nEQabk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQab09IEdudU75l2xOQTw" x="403.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQacE9IEdudU75l2xOQTw" guid="_nEQacE9IEdudU75l2xOQTw" graphEdge="_nEQajE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQacU9IEdudU75l2xOQTw" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQack9IEdudU75l2xOQTw" guid="_nEQack9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQac09IEdudU75l2xOQTw" x="154.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQadE9IEdudU75l2xOQTw" guid="_nEQadE9IEdudU75l2xOQTw" graphEdge="_nEQalE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQadU9IEdudU75l2xOQTw" x="146.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nEQadk9IEdudU75l2xOQTw" guid="_nEQadk9IEdudU75l2xOQTw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nEQad09IEdudU75l2xOQTw" width="509.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaeE9IEdudU75l2xOQTw" guid="_nEQaeE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaeU9IEdudU75l2xOQTw" x="477.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQaek9IEdudU75l2xOQTw" guid="_nEQaek9IEdudU75l2xOQTw" anchor="_nEQafU9IEdudU75l2xOQTw _nEQaXE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQae09IEdudU75l2xOQTw" guid="_nEQae09IEdudU75l2xOQTw" graphEdge="_nEQaLU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQafE9IEdudU75l2xOQTw" x="38.0" y="-91.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQafU9IEdudU75l2xOQTw" guid="_nEQafU9IEdudU75l2xOQTw" graphEdge="_nEQaek9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQafk9IEdudU75l2xOQTw" x="-28.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaf09IEdudU75l2xOQTw" guid="_nEQaf09IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y_PjTOtQEdqc1LGhiSPqRg"/>
+ </semanticModel>
+ <size xmi:id="_nEQagE9IEdudU75l2xOQTw" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQagU9IEdudU75l2xOQTw" guid="_nEQagU9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQagk9IEdudU75l2xOQTw" x="232.0" y="148.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQag09IEdudU75l2xOQTw" guid="_nEQag09IEdudU75l2xOQTw" anchor="_nEQahk9IEdudU75l2xOQTw _nEQaXk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQahE9IEdudU75l2xOQTw" guid="_nEQahE9IEdudU75l2xOQTw" graphEdge="_nEQaLk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQahU9IEdudU75l2xOQTw" x="156.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_nEQahk9IEdudU75l2xOQTw" guid="_nEQahk9IEdudU75l2xOQTw" graphEdge="_nEQag09IEdudU75l2xOQTw">
+ <position xmi:id="_nEQah09IEdudU75l2xOQTw" x="281.0" y="178.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQaiE9IEdudU75l2xOQTw" guid="_nEQaiE9IEdudU75l2xOQTw"/>
+ <size xmi:id="_nEQaiU9IEdudU75l2xOQTw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQaik9IEdudU75l2xOQTw" guid="_nEQaik9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQai09IEdudU75l2xOQTw" x="48.0" y="77.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQajE9IEdudU75l2xOQTw" guid="_nEQajE9IEdudU75l2xOQTw" anchor="_nEQajk9IEdudU75l2xOQTw _nEQacE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQajU9IEdudU75l2xOQTw" guid="_nEQajU9IEdudU75l2xOQTw" graphEdge="_nEQaNk9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQajk9IEdudU75l2xOQTw" guid="_nEQajk9IEdudU75l2xOQTw" graphEdge="_nEQajE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQaj09IEdudU75l2xOQTw" x="101.0" y="93.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQakE9IEdudU75l2xOQTw" guid="_nEQakE9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_eE5nEUbpEduLBN1xMBngqw"/>
+ </semanticModel>
+ <size xmi:id="_nEQakU9IEdudU75l2xOQTw" width="107.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nEQakk9IEdudU75l2xOQTw" guid="_nEQakk9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQak09IEdudU75l2xOQTw" x="144.0" y="158.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nEQalE9IEdudU75l2xOQTw" guid="_nEQalE9IEdudU75l2xOQTw" anchor="_nEQalk9IEdudU75l2xOQTw _nEQadE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQalU9IEdudU75l2xOQTw" guid="_nEQalU9IEdudU75l2xOQTw" graphEdge="_nEQaOE9IEdudU75l2xOQTw"/>
+ <anchorage xmi:id="_nEQalk9IEdudU75l2xOQTw" guid="_nEQalk9IEdudU75l2xOQTw" graphEdge="_nEQalE9IEdudU75l2xOQTw">
+ <position xmi:id="_nEQal09IEdudU75l2xOQTw" x="193.0" y="179.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_nEQamE9IEdudU75l2xOQTw" guid="_nEQamE9IEdudU75l2xOQTw">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_MWFjoU9HEdudU75l2xOQTw"/>
+ </semanticModel>
+ <size xmi:id="_nEQamU9IEdudU75l2xOQTw" width="98.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_3CqrdxOKEduCNqgZdt_OaA" guid="_3CqrdxOKEduCNqgZdt_OaA" presentation="Workflow" element="_3CqrAROKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_467NIROKEduCNqgZdt_OaA" name="transition_phase_iteration" guid="_467NIROKEduCNqgZdt_OaA">
+ <processElements xsi:type="org.eclipse.epf.uma:Activity" xmi:id="_467NIhOKEduCNqgZdt_OaA" name="transition_phase_iteration" guid="_467NIhOKEduCNqgZdt_OaA" presentationName="Transition Iteration [1..n]" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" isRepeatable="true" linkToPredecessor="_9abksBOSEduCNqgZdt_OaA" variabilityType="extends">
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0rQRgMlgEdmt3adZL5Dmdw"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#__ca5UBOMEduCNqgZdt_OaA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9abksBOSEduCNqgZdt_OaA" guid="_9abksBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_31E_YBOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_467NIxOKEduCNqgZdt_OaA" guid="_467NIxOKEduCNqgZdt_OaA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="__rUnY0btEduTiINs4_IZ_Q" guid="__rUnY0btEduTiINs4_IZ_Q">
+ <position xmi:id="__rUnZEbtEduTiINs4_IZ_Q" x="18.0" y="301.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__rUnZUbtEduTiINs4_IZ_Q" guid="__rUnZUbtEduTiINs4_IZ_Q" anchor="__rUnaEbtEduTiINs4_IZ_Q"/>
+ <anchorage xmi:id="__rUnZkbtEduTiINs4_IZ_Q" guid="__rUnZkbtEduTiINs4_IZ_Q">
+ <position xmi:id="__rUnZ0btEduTiINs4_IZ_Q" x="66.0" y="-25.0"/>
+ </anchorage>
+ <anchorage xmi:id="__rUnaEbtEduTiINs4_IZ_Q" guid="__rUnaEbtEduTiINs4_IZ_Q" graphEdge="__rUnZUbtEduTiINs4_IZ_Q">
+ <position xmi:id="__rUnaUbtEduTiINs4_IZ_Q" x="69.0" y="28.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="__rUnakbtEduTiINs4_IZ_Q" guid="__rUnakbtEduTiINs4_IZ_Q"/>
+ <size xmi:id="__rUna0btEduTiINs4_IZ_Q" width="144.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafYEqbEduiL77U_PmnmA" guid="_9zafYEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafYUqbEduiL77U_PmnmA" x="205.0" y="96.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafYkqbEduiL77U_PmnmA" guid="_9zafYkqbEduiL77U_PmnmA" anchor="_9zafZUqbEduiL77U_PmnmA _9zafpkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafY0qbEduiL77U_PmnmA" guid="_9zafY0qbEduiL77U_PmnmA" graphEdge="_9zafkkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafZEqbEduiL77U_PmnmA" x="38.0" y="-15.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafZUqbEduiL77U_PmnmA" guid="_9zafZUqbEduiL77U_PmnmA" graphEdge="_9zafYkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafZkqbEduiL77U_PmnmA" x="38.0" y="31.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafZ0qbEduiL77U_PmnmA" guid="_9zafZ0qbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0q33AclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_9zafaEqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafaUqbEduiL77U_PmnmA" guid="_9zafaUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafakqbEduiL77U_PmnmA" x="226.0" y="170.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafa0qbEduiL77U_PmnmA" guid="_9zafa0qbEduiL77U_PmnmA" anchor="_9zafbUqbEduiL77U_PmnmA _9zafdEqbEduiL77U_PmnmA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafbEqbEduiL77U_PmnmA" guid="_9zafbEqbEduiL77U_PmnmA"/>
+ </contained>
+ <anchorage xmi:id="_9zafbUqbEduiL77U_PmnmA" guid="_9zafbUqbEduiL77U_PmnmA" graphEdge="_9zafa0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafbkqbEduiL77U_PmnmA" x="119.0" y="22.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafb0qbEduiL77U_PmnmA" guid="_9zafb0qbEduiL77U_PmnmA"/>
+ <size xmi:id="_9zafcEqbEduiL77U_PmnmA" width="246.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafcUqbEduiL77U_PmnmA" guid="_9zafcUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafckqbEduiL77U_PmnmA" x="113.0" y="168.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafc0qbEduiL77U_PmnmA" guid="_9zafc0qbEduiL77U_PmnmA" anchor="_9zafdkqbEduiL77U_PmnmA _9zafrkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafdEqbEduiL77U_PmnmA" guid="_9zafdEqbEduiL77U_PmnmA" graphEdge="_9zafa0qbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafdUqbEduiL77U_PmnmA" guid="_9zafdUqbEduiL77U_PmnmA" graphEdge="_9zaflUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafdkqbEduiL77U_PmnmA" guid="_9zafdkqbEduiL77U_PmnmA" graphEdge="_9zafc0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafd0qbEduiL77U_PmnmA" x="484.0" y="257.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafeEqbEduiL77U_PmnmA" guid="_9zafeEqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwslgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_9zafeUqbEduiL77U_PmnmA" width="80.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafekqbEduiL77U_PmnmA" guid="_9zafekqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafe0qbEduiL77U_PmnmA" x="360.0" y="135.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaffEqbEduiL77U_PmnmA" guid="_9zaffEqbEduiL77U_PmnmA" anchor="_9zaff0qbEduiL77U_PmnmA _9zafqkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zaffUqbEduiL77U_PmnmA" guid="_9zaffUqbEduiL77U_PmnmA" graphEdge="_9zafk0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zaffkqbEduiL77U_PmnmA" x="36.0" y="-101.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zaff0qbEduiL77U_PmnmA" guid="_9zaff0qbEduiL77U_PmnmA" graphEdge="_9zaffEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafgEqbEduiL77U_PmnmA" x="37.0" y="25.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafgUqbEduiL77U_PmnmA" guid="_9zafgUqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qxwYclgEdmt3adZL5Dmdw"/>
+ </semanticModel>
+ <size xmi:id="_9zafgkqbEduiL77U_PmnmA" width="84.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafg0qbEduiL77U_PmnmA" guid="_9zafg0qbEduiL77U_PmnmA" briefDescription="__-SZwNIYEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafhEqbEduiL77U_PmnmA" x="77.0" y="8.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafhUqbEduiL77U_PmnmA" guid="_9zafhUqbEduiL77U_PmnmA" anchor="_9zafhkqbEduiL77U_PmnmA _9zaflkqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafhkqbEduiL77U_PmnmA" guid="_9zafhkqbEduiL77U_PmnmA" graphEdge="_9zafhUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafh0qbEduiL77U_PmnmA" x="7.0" y="10.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafiEqbEduiL77U_PmnmA" guid="_9zafiEqbEduiL77U_PmnmA" typeInfo="start node"/>
+ <size xmi:id="_9zafiUqbEduiL77U_PmnmA" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafikqbEduiL77U_PmnmA" guid="_9zafikqbEduiL77U_PmnmA" briefDescription="_ATOvANIZEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafi0qbEduiL77U_PmnmA" x="72.0" y="301.0"/>
+ <anchorage xmi:id="_9zafjEqbEduiL77U_PmnmA" guid="_9zafjEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafjUqbEduiL77U_PmnmA" guid="_9zafjUqbEduiL77U_PmnmA" graphEdge="_9zafpUqbEduiL77U_PmnmA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafjkqbEduiL77U_PmnmA" guid="_9zafjkqbEduiL77U_PmnmA" typeInfo="end node"/>
+ <size xmi:id="_9zafj0qbEduiL77U_PmnmA" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafkEqbEduiL77U_PmnmA" guid="_9zafkEqbEduiL77U_PmnmA" briefDescription="_AyNxENIZEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafkUqbEduiL77U_PmnmA" x="20.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafkkqbEduiL77U_PmnmA" guid="_9zafkkqbEduiL77U_PmnmA" anchor="_9zafmEqbEduiL77U_PmnmA _9zafY0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafk0qbEduiL77U_PmnmA" guid="_9zafk0qbEduiL77U_PmnmA" anchor="_9zafmkqbEduiL77U_PmnmA _9zaffUqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaflEqbEduiL77U_PmnmA" guid="_9zaflEqbEduiL77U_PmnmA" anchor="_9zafnEqbEduiL77U_PmnmA _9zaft0qbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaflUqbEduiL77U_PmnmA" guid="_9zaflUqbEduiL77U_PmnmA" anchor="_9zafnkqbEduiL77U_PmnmA _9zafdUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zaflkqbEduiL77U_PmnmA" guid="_9zaflkqbEduiL77U_PmnmA" graphEdge="_9zafhUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafl0qbEduiL77U_PmnmA" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafmEqbEduiL77U_PmnmA" guid="_9zafmEqbEduiL77U_PmnmA" graphEdge="_9zafkkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafmUqbEduiL77U_PmnmA" x="227.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafmkqbEduiL77U_PmnmA" guid="_9zafmkqbEduiL77U_PmnmA" graphEdge="_9zafk0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafm0qbEduiL77U_PmnmA" x="382.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafnEqbEduiL77U_PmnmA" guid="_9zafnEqbEduiL77U_PmnmA" graphEdge="_9zaflEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafnUqbEduiL77U_PmnmA" x="49.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafnkqbEduiL77U_PmnmA" guid="_9zafnkqbEduiL77U_PmnmA" graphEdge="_9zaflUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafn0qbEduiL77U_PmnmA" x="133.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafoEqbEduiL77U_PmnmA" guid="_9zafoEqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_9zafoUqbEduiL77U_PmnmA" width="431.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zafokqbEduiL77U_PmnmA" guid="_9zafokqbEduiL77U_PmnmA" briefDescription="_BocOcNIZEdm9Cql_SeWu_A">
+ <position xmi:id="_9zafo0qbEduiL77U_PmnmA" x="19.0" y="253.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafpEqbEduiL77U_PmnmA" guid="_9zafpEqbEduiL77U_PmnmA" anchor="_9zafqEqbEduiL77U_PmnmA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zafpUqbEduiL77U_PmnmA" guid="_9zafpUqbEduiL77U_PmnmA" anchor="_9zafsEqbEduiL77U_PmnmA _9zafjUqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafpkqbEduiL77U_PmnmA" guid="_9zafpkqbEduiL77U_PmnmA" graphEdge="_9zafYkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafp0qbEduiL77U_PmnmA" x="227.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafqEqbEduiL77U_PmnmA" guid="_9zafqEqbEduiL77U_PmnmA" graphEdge="_9zafpEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafqUqbEduiL77U_PmnmA" x="72.0" y="8.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafqkqbEduiL77U_PmnmA" guid="_9zafqkqbEduiL77U_PmnmA" graphEdge="_9zaffEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafq0qbEduiL77U_PmnmA" x="383.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafrEqbEduiL77U_PmnmA" guid="_9zafrEqbEduiL77U_PmnmA" graphEdge="_9zaftkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafrUqbEduiL77U_PmnmA" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafrkqbEduiL77U_PmnmA" guid="_9zafrkqbEduiL77U_PmnmA" graphEdge="_9zafc0qbEduiL77U_PmnmA">
+ <position xmi:id="_9zafr0qbEduiL77U_PmnmA" x="133.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_9zafsEqbEduiL77U_PmnmA" guid="_9zafsEqbEduiL77U_PmnmA" graphEdge="_9zafpUqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafsUqbEduiL77U_PmnmA" x="65.0" y="5.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9zafskqbEduiL77U_PmnmA" guid="_9zafskqbEduiL77U_PmnmA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_9zafs0qbEduiL77U_PmnmA" width="442.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9zaftEqbEduiL77U_PmnmA" guid="_9zaftEqbEduiL77U_PmnmA">
+ <position xmi:id="_9zaftUqbEduiL77U_PmnmA" x="24.0" y="97.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9zaftkqbEduiL77U_PmnmA" guid="_9zaftkqbEduiL77U_PmnmA" anchor="_9zafuEqbEduiL77U_PmnmA _9zafrEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zaft0qbEduiL77U_PmnmA" guid="_9zaft0qbEduiL77U_PmnmA" graphEdge="_9zaflEqbEduiL77U_PmnmA"/>
+ <anchorage xmi:id="_9zafuEqbEduiL77U_PmnmA" guid="_9zafuEqbEduiL77U_PmnmA" graphEdge="_9zaftkqbEduiL77U_PmnmA">
+ <position xmi:id="_9zafuUqbEduiL77U_PmnmA" x="320.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9zafukqbEduiL77U_PmnmA" guid="_9zafukqbEduiL77U_PmnmA">
+ <element xsi:type="org.eclipse.epf.uma:Activity" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0DMlYPinEdmugcVr9AdHjQ"/>
+ </semanticModel>
+ <size xmi:id="_9zafu0qbEduiL77U_PmnmA" width="90.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_467NSROKEduCNqgZdt_OaA" guid="_467NSROKEduCNqgZdt_OaA" presentation="Workflow" element="_467NIhOKEduCNqgZdt_OaA"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_y1uwgBOKEduCNqgZdt_OaA" name="lifecycle_objectives" guid="_y1uwgBOKEduCNqgZdt_OaA" briefDescription="The end of the Inception phase is the first major project milestone, the Lifecycle Objectives Milestone." presentationName="Lifecycle Objectives Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_8Kfm0BOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-qk_QXyoSxOb2C-boCISB5g" href="uma://_mtb-4PL5Edm6Nvont3uinw#-qk_QXyoSxOb2C-boCISB5g"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_16nd0BOKEduCNqgZdt_OaA" name="lifecycle_architecture" guid="_16nd0BOKEduCNqgZdt_OaA" briefDescription="At the end of the Elaboration phase is the second important project milestone, the Lifecycle Architecture Milestone." presentationName="Lifecycle Architecture Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_8s37IBOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-3Ul1iAI1nkD0C5AsRtjHFA" href="uma://_mtb-4PL5Edm6Nvont3uinw#-3Ul1iAI1nkD0C5AsRtjHFA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_31E_YBOKEduCNqgZdt_OaA" name="initial_operational_capability" guid="_31E_YBOKEduCNqgZdt_OaA" briefDescription="The end of Construction phase is the third important project milestone, the Initial Operational Capability Milestone." presentationName="Initial Operational Capability Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_9L0g8BOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-Q37Qy6ke_PQDK4jr1EIdcA" href="uma://_mtb-4PL5Edm6Nvont3uinw#-Q37Qy6ke_PQDK4jr1EIdcA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:Milestone" xmi:id="_5v0NwBOKEduCNqgZdt_OaA" name="product_release" guid="_5v0NwBOKEduCNqgZdt_OaA" briefDescription="The end of the Transition phase is the fourth important project milestone, the Product Release Milestone, which is the result of the customer reviewing and accepting the project deliverables." presentationName="Product Release Milestone" superActivities="_0uyGoMlgEdmt3adZL5Dmdw" linkToPredecessor="_9toNgBOSEduCNqgZdt_OaA">
+ <presentation xmi:id="-Gt2aCyZVy4q1BvcJRM2E-A" href="uma://_mtb-4PL5Edm6Nvont3uinw#-Gt2aCyZVy4q1BvcJRM2E-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_8Kfm0BOSEduCNqgZdt_OaA" guid="_8Kfm0BOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_xupMvxOKEduCNqgZdt_OaA"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_8s37IBOSEduCNqgZdt_OaA" guid="_8s37IBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_0Spa4BOKEduCNqgZdt_OaA"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9L0g8BOSEduCNqgZdt_OaA" guid="_9L0g8BOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_3CqrAROKEduCNqgZdt_OaA"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9toNgBOSEduCNqgZdt_OaA" guid="_9toNgBOSEduCNqgZdt_OaA" linkType="finishToFinish" pred="_467NIhOKEduCNqgZdt_OaA"/>
+ <diagrams xmi:id="_PrVJgFYzEdqI9sTOt2pjHw" guid="_PrVJgFYzEdqI9sTOt2pjHw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJgVYzEdqI9sTOt2pjHw" guid="_PrVJgVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJglYzEdqI9sTOt2pjHw" x="10.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJg1YzEdqI9sTOt2pjHw" guid="_PrVJg1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJhFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJhVYzEdqI9sTOt2pjHw" guid="_PrVJhVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJhlYzEdqI9sTOt2pjHw" x="183.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJh1YzEdqI9sTOt2pjHw" guid="_PrVJh1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJiFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJiVYzEdqI9sTOt2pjHw" guid="_PrVJiVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJilYzEdqI9sTOt2pjHw" x="366.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJi1YzEdqI9sTOt2pjHw" guid="_PrVJi1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJjFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_PrVJjVYzEdqI9sTOt2pjHw" guid="_PrVJjVYzEdqI9sTOt2pjHw">
+ <position xmi:id="_PrVJjlYzEdqI9sTOt2pjHw" x="557.0" y="10.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJj1YzEdqI9sTOt2pjHw" guid="_PrVJj1YzEdqI9sTOt2pjHw"/>
+ <size xmi:id="_PrVJkFYzEdqI9sTOt2pjHw" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0MMA_EdqSgKaj2SZBmg" guid="_HZM0MMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0McA_EdqSgKaj2SZBmg" x="-63.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KUNMwcA_EdqSgKaj2SZBmg" guid="_KUNMwcA_EdqSgKaj2SZBmg" anchor="_KUNMwMA_EdqSgKaj2SZBmg _KUNMwsA_EdqSgKaj2SZBmg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_KVQVoMA_EdqSgKaj2SZBmg" guid="_KVQVoMA_EdqSgKaj2SZBmg"/>
+ </contained>
+ <anchorage xmi:id="_KGW-AsA_EdqSgKaj2SZBmg" guid="_KGW-AsA_EdqSgKaj2SZBmg" graphEdge="_KGW-AcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_KUNMwMA_EdqSgKaj2SZBmg" guid="_KUNMwMA_EdqSgKaj2SZBmg" graphEdge="_KUNMwcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_KUNMw8A_EdqSgKaj2SZBmg" x="184.0" y="77.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0MsA_EdqSgKaj2SZBmg" guid="_HZM0MsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0M8A_EdqSgKaj2SZBmg" width="43.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0NMA_EdqSgKaj2SZBmg" guid="_HZM0NMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0NcA_EdqSgKaj2SZBmg" x="20.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KiJiIcA_EdqSgKaj2SZBmg" guid="_KiJiIcA_EdqSgKaj2SZBmg" anchor="_KiJiIMA_EdqSgKaj2SZBmg _KiJiIsA_EdqSgKaj2SZBmg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_KjGkYMA_EdqSgKaj2SZBmg" guid="_KjGkYMA_EdqSgKaj2SZBmg"/>
+ </contained>
+ <anchorage xmi:id="_KUNMwsA_EdqSgKaj2SZBmg" guid="_KUNMwsA_EdqSgKaj2SZBmg" graphEdge="_KUNMwcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_KiJiIMA_EdqSgKaj2SZBmg" guid="_KiJiIMA_EdqSgKaj2SZBmg" graphEdge="_KiJiIcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_KiJiI8A_EdqSgKaj2SZBmg" x="274.0" y="77.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0NsA_EdqSgKaj2SZBmg" guid="_HZM0NsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0N8A_EdqSgKaj2SZBmg" width="53.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0OMA_EdqSgKaj2SZBmg" guid="_HZM0OMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0OcA_EdqSgKaj2SZBmg" x="113.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Kw2sgcA_EdqSgKaj2SZBmg" guid="_Kw2sgcA_EdqSgKaj2SZBmg" anchor="_Kw2sgMA_EdqSgKaj2SZBmg _Kw2sgsA_EdqSgKaj2SZBmg">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_Kx51YMA_EdqSgKaj2SZBmg" guid="_Kx51YMA_EdqSgKaj2SZBmg"/>
+ </contained>
+ <anchorage xmi:id="_KiJiIsA_EdqSgKaj2SZBmg" guid="_KiJiIsA_EdqSgKaj2SZBmg" graphEdge="_KiJiIcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_Kw2sgMA_EdqSgKaj2SZBmg" guid="_Kw2sgMA_EdqSgKaj2SZBmg" graphEdge="_Kw2sgcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_Kw2sg8A_EdqSgKaj2SZBmg" x="378.0" y="82.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0OsA_EdqSgKaj2SZBmg" guid="_HZM0OsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0O8A_EdqSgKaj2SZBmg" width="61.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HZM0PMA_EdqSgKaj2SZBmg" guid="_HZM0PMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_HZM0PcA_EdqSgKaj2SZBmg" x="214.0" y="9.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_K-5IgcA_EdqSgKaj2SZBmg" guid="_K-5IgcA_EdqSgKaj2SZBmg" anchor="_K-5IgMA_EdqSgKaj2SZBmg _K-5IgsA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_Kw2sgsA_EdqSgKaj2SZBmg" guid="_Kw2sgsA_EdqSgKaj2SZBmg" graphEdge="_Kw2sgcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_K-5IgMA_EdqSgKaj2SZBmg" guid="_K-5IgMA_EdqSgKaj2SZBmg" graphEdge="_K-5IgcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_K-5Ig8A_EdqSgKaj2SZBmg" x="463.0" y="83.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_HZM0PsA_EdqSgKaj2SZBmg" guid="_HZM0PsA_EdqSgKaj2SZBmg"/>
+ <size xmi:id="_HZM0P8A_EdqSgKaj2SZBmg" width="47.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JS-ZQMA_EdqSgKaj2SZBmg" guid="_JS-ZQMA_EdqSgKaj2SZBmg">
+ <position xmi:id="_JS-ZQcA_EdqSgKaj2SZBmg" x="568.0" y="177.0"/>
+ <anchorage xmi:id="_K-5IgsA_EdqSgKaj2SZBmg" guid="_K-5IgsA_EdqSgKaj2SZBmg" graphEdge="_K-5IgcA_EdqSgKaj2SZBmg"/>
+ <anchorage xmi:id="_Amoa8hOTEduCNqgZdt_OaA" guid="_Amoa8hOTEduCNqgZdt_OaA" graphEdge="_Amoa8ROTEduCNqgZdt_OaA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JS-ZQsA_EdqSgKaj2SZBmg" guid="_JS-ZQsA_EdqSgKaj2SZBmg" typeInfo="end node"/>
+ <size xmi:id="_JS-ZQ8A_EdqSgKaj2SZBmg" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JrCT8MA_EdqSgKaj2SZBmg" guid="_JrCT8MA_EdqSgKaj2SZBmg">
+ <position xmi:id="_JrCT8cA_EdqSgKaj2SZBmg" x="-73.0" y="52.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KGW-AcA_EdqSgKaj2SZBmg" guid="_KGW-AcA_EdqSgKaj2SZBmg" anchor="_KGW-AMA_EdqSgKaj2SZBmg _KGW-AsA_EdqSgKaj2SZBmg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_73xfIROSEduCNqgZdt_OaA" guid="_73xfIROSEduCNqgZdt_OaA" anchor="_73xfIBOSEduCNqgZdt_OaA _73xfIhOSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_KGW-AMA_EdqSgKaj2SZBmg" guid="_KGW-AMA_EdqSgKaj2SZBmg" graphEdge="_KGW-AcA_EdqSgKaj2SZBmg">
+ <position xmi:id="_KGW-A8A_EdqSgKaj2SZBmg" x="128.0" y="84.0"/>
+ </anchorage>
+ <anchorage xmi:id="_73xfIBOSEduCNqgZdt_OaA" guid="_73xfIBOSEduCNqgZdt_OaA" graphEdge="_73xfIROSEduCNqgZdt_OaA">
+ <position xmi:id="_73xfIxOSEduCNqgZdt_OaA" x="21.0" y="65.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JrCT8sA_EdqSgKaj2SZBmg" guid="_JrCT8sA_EdqSgKaj2SZBmg" typeInfo="start node"/>
+ <size xmi:id="_JrCT88A_EdqSgKaj2SZBmg" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz8BOLEduCNqgZdt_OaA" guid="_OWWz8BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz8ROLEduCNqgZdt_OaA" x="-20.0" y="32.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8IfbsROSEduCNqgZdt_OaA" guid="_8IfbsROSEduCNqgZdt_OaA" anchor="_8IfbsBOSEduCNqgZdt_OaA _8IfbshOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8Kfm0ROSEduCNqgZdt_OaA" guid="_8Kfm0ROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_73xfIhOSEduCNqgZdt_OaA" guid="_73xfIhOSEduCNqgZdt_OaA" graphEdge="_73xfIROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_8IfbsBOSEduCNqgZdt_OaA" guid="_8IfbsBOSEduCNqgZdt_OaA" graphEdge="_8IfbsROSEduCNqgZdt_OaA">
+ <position xmi:id="_8IfbsxOSEduCNqgZdt_OaA" x="117.0" y="64.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz8hOLEduCNqgZdt_OaA" guid="_OWWz8hOLEduCNqgZdt_OaA" element="_xupMvxOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz8xOLEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz9BOLEduCNqgZdt_OaA" guid="_OWWz9BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz9ROLEduCNqgZdt_OaA" x="-16.0" y="157.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZY-cROSEduCNqgZdt_OaA" guid="_8ZY-cROSEduCNqgZdt_OaA" anchor="_8ZY-cBOSEduCNqgZdt_OaA _8ZY-chOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8bl94BOSEduCNqgZdt_OaA" guid="_8bl94BOSEduCNqgZdt_OaA"/>
+ <waypoints xmi:id="_ZRybwBjmEduxUfEVCtmW4Q" x="123.0" y="142.0"/>
+ </contained>
+ <anchorage xmi:id="_8IfbshOSEduCNqgZdt_OaA" guid="_8IfbshOSEduCNqgZdt_OaA" graphEdge="_8IfbsROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_8ZY-cBOSEduCNqgZdt_OaA" guid="_8ZY-cBOSEduCNqgZdt_OaA" graphEdge="_8ZY-cROSEduCNqgZdt_OaA">
+ <position xmi:id="_8ZY-cxOSEduCNqgZdt_OaA" x="158.0" y="132.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz9hOLEduCNqgZdt_OaA" guid="_OWWz9hOLEduCNqgZdt_OaA" element="_y1uwgBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz9xOLEduCNqgZdt_OaA" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz-BOLEduCNqgZdt_OaA" guid="_OWWz-BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz-ROLEduCNqgZdt_OaA" x="125.0" y="32.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8qxpYROSEduCNqgZdt_OaA" guid="_8qxpYROSEduCNqgZdt_OaA" anchor="_8qxpYBOSEduCNqgZdt_OaA _8qxpYhOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8s37IROSEduCNqgZdt_OaA" guid="_8s37IROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_8ZY-chOSEduCNqgZdt_OaA" guid="_8ZY-chOSEduCNqgZdt_OaA" graphEdge="_8ZY-cROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_8qxpYBOSEduCNqgZdt_OaA" guid="_8qxpYBOSEduCNqgZdt_OaA" graphEdge="_8qxpYROSEduCNqgZdt_OaA">
+ <position xmi:id="_8qxpYxOSEduCNqgZdt_OaA" x="264.0" y="66.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz-hOLEduCNqgZdt_OaA" guid="_OWWz-hOLEduCNqgZdt_OaA" element="_0Spa4BOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz-xOLEduCNqgZdt_OaA" width="109.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWWz_BOLEduCNqgZdt_OaA" guid="_OWWz_BOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWWz_ROLEduCNqgZdt_OaA" x="130.0" y="158.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_86VvYROSEduCNqgZdt_OaA" guid="_86VvYROSEduCNqgZdt_OaA" anchor="_86VvYBOSEduCNqgZdt_OaA _86VvYhOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_88coMROSEduCNqgZdt_OaA" guid="_88coMROSEduCNqgZdt_OaA"/>
+ <waypoints xmi:id="_Z_czABjmEduxUfEVCtmW4Q" x="286.0" y="144.0"/>
+ </contained>
+ <anchorage xmi:id="_8qxpYhOSEduCNqgZdt_OaA" guid="_8qxpYhOSEduCNqgZdt_OaA" graphEdge="_8qxpYROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_86VvYBOSEduCNqgZdt_OaA" guid="_86VvYBOSEduCNqgZdt_OaA" graphEdge="_86VvYROSEduCNqgZdt_OaA">
+ <position xmi:id="_86VvYxOSEduCNqgZdt_OaA" x="339.0" y="132.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWWz_hOLEduCNqgZdt_OaA" guid="_OWWz_hOLEduCNqgZdt_OaA" element="_16nd0BOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWWz_xOLEduCNqgZdt_OaA" width="99.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0ABOLEduCNqgZdt_OaA" guid="_OWW0ABOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0AROLEduCNqgZdt_OaA" x="285.0" y="31.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9JiB8ROSEduCNqgZdt_OaA" guid="_9JiB8ROSEduCNqgZdt_OaA" anchor="_9JiB8BOSEduCNqgZdt_OaA _9JiB8hOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9L0g8ROSEduCNqgZdt_OaA" guid="_9L0g8ROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_86VvYhOSEduCNqgZdt_OaA" guid="_86VvYhOSEduCNqgZdt_OaA" graphEdge="_86VvYROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9JiB8BOSEduCNqgZdt_OaA" guid="_9JiB8BOSEduCNqgZdt_OaA" graphEdge="_9JiB8ROSEduCNqgZdt_OaA">
+ <position xmi:id="_9JiB8xOSEduCNqgZdt_OaA" x="429.0" y="68.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0AhOLEduCNqgZdt_OaA" guid="_OWW0AhOLEduCNqgZdt_OaA" element="_3CqrAROKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0AxOLEduCNqgZdt_OaA" width="117.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0BBOLEduCNqgZdt_OaA" guid="_OWW0BBOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0BROLEduCNqgZdt_OaA" x="300.0" y="154.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9YVS8ROSEduCNqgZdt_OaA" guid="_9YVS8ROSEduCNqgZdt_OaA" anchor="_9YVS8BOSEduCNqgZdt_OaA _9YVS8hOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9abksROSEduCNqgZdt_OaA" guid="_9abksROSEduCNqgZdt_OaA"/>
+ <waypoints xmi:id="_agGpABjmEduxUfEVCtmW4Q" x="446.0" y="135.0"/>
+ </contained>
+ <anchorage xmi:id="_9JiB8hOSEduCNqgZdt_OaA" guid="_9JiB8hOSEduCNqgZdt_OaA" graphEdge="_9JiB8ROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9YVS8BOSEduCNqgZdt_OaA" guid="_9YVS8BOSEduCNqgZdt_OaA" graphEdge="_9YVS8ROSEduCNqgZdt_OaA">
+ <position xmi:id="_9YVS8xOSEduCNqgZdt_OaA" x="502.0" y="132.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0BhOLEduCNqgZdt_OaA" guid="_OWW0BhOLEduCNqgZdt_OaA" element="_31E_YBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0BxOLEduCNqgZdt_OaA" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0CBOLEduCNqgZdt_OaA" guid="_OWW0CBOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0CROLEduCNqgZdt_OaA" x="438.0" y="30.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9rh7wROSEduCNqgZdt_OaA" guid="_9rh7wROSEduCNqgZdt_OaA" anchor="_9rh7wBOSEduCNqgZdt_OaA _9rh7whOSEduCNqgZdt_OaA">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9toNgROSEduCNqgZdt_OaA" guid="_9toNgROSEduCNqgZdt_OaA"/>
+ </contained>
+ <anchorage xmi:id="_9YVS8hOSEduCNqgZdt_OaA" guid="_9YVS8hOSEduCNqgZdt_OaA" graphEdge="_9YVS8ROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9rh7wBOSEduCNqgZdt_OaA" guid="_9rh7wBOSEduCNqgZdt_OaA" graphEdge="_9rh7wROSEduCNqgZdt_OaA">
+ <position xmi:id="_9rh7wxOSEduCNqgZdt_OaA" x="578.0" y="68.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0ChOLEduCNqgZdt_OaA" guid="_OWW0ChOLEduCNqgZdt_OaA" element="_467NIhOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0CxOLEduCNqgZdt_OaA" width="103.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_OWW0DBOLEduCNqgZdt_OaA" guid="_OWW0DBOLEduCNqgZdt_OaA">
+ <position xmi:id="_OWW0DROLEduCNqgZdt_OaA" x="456.0" y="152.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Amoa8ROTEduCNqgZdt_OaA" guid="_Amoa8ROTEduCNqgZdt_OaA" anchor="_Amoa8BOTEduCNqgZdt_OaA _Amoa8hOTEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_9rh7whOSEduCNqgZdt_OaA" guid="_9rh7whOSEduCNqgZdt_OaA" graphEdge="_9rh7wROSEduCNqgZdt_OaA"/>
+ <anchorage xmi:id="_Amoa8BOTEduCNqgZdt_OaA" guid="_Amoa8BOTEduCNqgZdt_OaA" graphEdge="_Amoa8ROTEduCNqgZdt_OaA">
+ <position xmi:id="_Amoa8xOTEduCNqgZdt_OaA" x="661.0" y="136.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_OWW0DhOLEduCNqgZdt_OaA" guid="_OWW0DhOLEduCNqgZdt_OaA" element="_5v0NwBOKEduCNqgZdt_OaA"/>
+ <size xmi:id="_OWW0DxOLEduCNqgZdt_OaA" width="67.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_eqypIBjYEduxUfEVCtmW4Q" name="Add Free Text" guid="_eqypIBjYEduxUfEVCtmW4Q">
+ <property xmi:id="_eqypIRjYEduxUfEVCtmW4Q" guid="_eqypIRjYEduxUfEVCtmW4Q" key="free text" value="[last iteration in Inception]"/>
+ <position xmi:id="_eqypIhjYEduxUfEVCtmW4Q" x="33.0" y="108.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_eqypIxjYEduxUfEVCtmW4Q" guid="_eqypIxjYEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_eqypJBjYEduxUfEVCtmW4Q" width="66.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_EXh7QBjZEduxUfEVCtmW4Q" name="Add Free Text" guid="_EXh7QBjZEduxUfEVCtmW4Q">
+ <property xmi:id="_EXh7QRjZEduxUfEVCtmW4Q" guid="_EXh7QRjZEduxUfEVCtmW4Q" key="free text" value="[last iteration in Elaboration]"/>
+ <position xmi:id="_EXh7QhjZEduxUfEVCtmW4Q" x="182.0" y="104.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_EXh7QxjZEduxUfEVCtmW4Q" guid="_EXh7QxjZEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_EXh7RBjZEduxUfEVCtmW4Q" width="71.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_d66ZcBjaEduxUfEVCtmW4Q" name="Add Free Text" guid="_d66ZcBjaEduxUfEVCtmW4Q">
+ <property xmi:id="_d66ZcRjaEduxUfEVCtmW4Q" guid="_d66ZcRjaEduxUfEVCtmW4Q" key="free text" value="[last iteration in Construction]"/>
+ <position xmi:id="_d66ZchjaEduxUfEVCtmW4Q" x="349.0" y="102.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_d66ZcxjaEduxUfEVCtmW4Q" guid="_d66ZcxjaEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_d66ZdBjaEduxUfEVCtmW4Q" width="77.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_5bCFkBjlEduxUfEVCtmW4Q" name="Add Free Text" guid="_5bCFkBjlEduxUfEVCtmW4Q">
+ <property xmi:id="_5bCFkRjlEduxUfEVCtmW4Q" guid="_5bCFkRjlEduxUfEVCtmW4Q" key="free text" value="[last iteration in Transition]"/>
+ <position xmi:id="_5bCFkhjlEduxUfEVCtmW4Q" x="491.0" y="101.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_5bCFkxjlEduxUfEVCtmW4Q" guid="_5bCFkxjlEduxUfEVCtmW4Q" typeInfo="free text"/>
+ <size xmi:id="_5bCFlBjlEduxUfEVCtmW4Q" width="69.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_PrVJkVYzEdqI9sTOt2pjHw" guid="_PrVJkVYzEdqI9sTOt2pjHw" presentation="Workflow" element="_0uyGoMlgEdmt3adZL5Dmdw"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:DeliveryProcess" xmi:id="_0uyGoMlgEdmt3adZL5Dmdw" name="openup_basic_process" guid="_0uyGoMlgEdmt3adZL5Dmdw" briefDescription="This delivery process defines a software development process that supports the core principles of OpenUP. It is designed to support small co-located teams, consisting of 3 to 6 team members, working on a project that will last between 3 and 6 months." presentationName="OpenUP/Basic Lifecycle" isPlanned="false" breakdownElements="_xupMvxOKEduCNqgZdt_OaA _y1uwgBOKEduCNqgZdt_OaA _0Spa4BOKEduCNqgZdt_OaA _16nd0BOKEduCNqgZdt_OaA _3CqrAROKEduCNqgZdt_OaA _31E_YBOKEduCNqgZdt_OaA _467NIhOKEduCNqgZdt_OaA _5v0NwBOKEduCNqgZdt_OaA">
+ <ownedRules xmi:id="_u_X-YOETEdqMu-vDNOTdSg" name="diagram" guid="_u_X-YOETEdqMu-vDNOTdSg" body="ad_image_uri=_Pt_fYBjoEduxUfEVCtmW4Q|publish_ad_image=true|add_image_uri=|publish_add_image=false|wpd_image_uri=|publish_wpd_image=false"/>
+ <presentation xmi:id="_mtb-4PL5Edm6Nvont3uinw" href="uma://_mtb-4PL5Edm6Nvont3uinw#_mtb-4PL5Edm6Nvont3uinw"/>
+ <supportingMaterials href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_Pt_fYBjoEduxUfEVCtmW4Q"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_48EKsBOMEduCNqgZdt_OaA"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_2plxwBOMEduCNqgZdt_OaA"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#_0hmKgBOMEduCNqgZdt_OaA"/>
+ <concepts href="uma://_0TLvwMlgEdmt3adZL5Dmdw#__ca5UBOMEduCNqgZdt_OaA"/>
+ <includesPatterns href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0o3r4slgEdmt3adZL5Dmdw"/>
+ <includesPatterns href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0sTaYMlgEdmt3adZL5Dmdw"/>
+ <includesPatterns href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0rQRgMlgEdmt3adZL5Dmdw"/>
+ <includesPatterns href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-3IrutQEdqc1LGhiSPqRg"/>
+ <defaultContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ <validContext href="uma://_y62TUKVPEdmMZJIzZ1W7Pw#_0u-T4clgEdmt3adZL5Dmdw"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplinegroupings/openup_basic_disciplines.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplinegroupings/openup_basic_disciplines.xmi
new file mode 100644
index 0000000..309f2b0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplinegroupings/openup_basic_disciplines.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="_AYGfoP1VEdmek8CQTQgrOQ" name="openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ" guid="_AYGfoP1VEdmek8CQTQgrOQ" changeDate="2006-10-09T16:19:05.242-0700">
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html" guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>, organized by <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/discipline,_yGUuidnmEdmO6L4XMImrsA.html" guid="_yGUuidnmEdmO6L4XMImrsA">disciplines</a>. You can see the&nbsp;tasks that have been included,&nbsp;and visit
+ each&nbsp;task page to see its definition and relationships to other elements.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/analysis_and_design.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/analysis_and_design.xmi
new file mode 100644
index 0000000..08dd4d0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/analysis_and_design.xmi
@@ -0,0 +1,40 @@
+<?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" epf:version="1.0.0" xmi:id="_Bbq2MLv-EdmmUvZAZjqE3g" name="architecture,_0TX9AMlgEdmt3adZL5Dmdw" guid="_Bbq2MLv-EdmmUvZAZjqE3g" changeDate="2007-01-27T09:43:38.921-0800" version="1.0.0">
+ <mainDescription><p>
+ The purposes of Analysis &amp; Design are:
+</p>
+<ul>
+ <li>
+ To transform the requirements into a design of the system-to-be.
+ </li>
+ <li>
+ To evolve a robust architecture for the system.
+ </li>
+ <li>
+ To adapt the design to match the implementation environment.
+ </li>
+</ul>
+<p>
+ The Analysis &amp; Design discipline is related to other disciplines, as follows:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline provides the primary input for Analysis and Design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/implementation,_0TeDoMlgEdmt3adZL5Dmdw.html" guid="_0TeDoMlgEdmt3adZL5Dmdw">Implementation</a> discipline implements the design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a> discipline tests system designed during Analysis and Design.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project, and each iteration.
+ </li>
+</ul></mainDescription>
+ <keyConsiderations><p>
+ Creating and applying architectural mechanisms is essential for creating a robust architecture. See more on
+ architectural mechanisms at <a class="elementLink"
+ href="./../../openup_basic/customcategories/architectural_mechanisms,_2l8U4K4sEdudp4CB-AFxtw.html"
+ guid="_2l8U4K4sEdudp4CB-AFxtw">Architectural Mechanisms</a>.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/config_and_change_management.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/config_and_change_management.xmi
new file mode 100644
index 0000000..3e26139
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/config_and_change_management.xmi
@@ -0,0 +1,50 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_H9TXMLv-EdmmUvZAZjqE3g" name="change_management,_0TwXgMlgEdmt3adZL5Dmdw" guid="_H9TXMLv-EdmmUvZAZjqE3g" changeDate="2006-09-28T10:05:40.519-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Maintain a consistent set of work products as they evolve.
+ </li>
+ <li>
+ Maintain consistent builds of the software.
+ </li>
+ <li>
+ Provide an efficient means to adapt to changes and issues and re-plan work accordingly.
+ </li>
+ <li>
+ Provide data for measuring progress.
+ </li>
+</ul>
+<p>
+ In many organizations, the term "configuration management" implies all of these things.
+</p>
+<p>
+ Within the context of this process, configuration management refers to the ability to maintain&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/termdefinitions/version,_eX8K8ElyEducWJcS4yanqg.html" guid="_eX8K8ElyEducWJcS4yanqg">version</a>s of artifacts and consistent&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/termdefinitions/configuration,__Cw30ElxEducWJcS4yanqg.html" guid="__Cw30ElxEducWJcS4yanqg">configuration</a>s of artifacts, addressing the first two objectives listed above.
+ Change Management refers to the process of managing changes to configuration controlled artifacts, addressing the
+ latter two objectives listed above.
+</p>
+<p>
+ Although it is important to keep up to date versions and configurations of all work product, the primary work products
+ of concern&nbsp;are the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Artifact: Implementation</a>&nbsp;and&nbsp;the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Artifact: Build</a>.
+</p>
+<p>
+ Changes are managed via the <a class="elementLinkWithType" href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a>&nbsp;and subsequent prioritization and disposition of change requests via the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.
+</p>
+<p>
+ This discipline spans the entire lifecycle. Every other discipline relies upon the configuration and change management
+ discipline to maintain a consistent, up to date, set of work products and to prioritize and track changes to those work
+ products throughout the lifecycle.
+</p>
+<p>
+ Configuration and change management is done by everyone on the development team. Because of the importance and
+ pervasiveness of this discipline, configuration and change management guidance is associated with tasks and work
+ products in all other disciplines.
+</p></mainDescription>
+ <keyConsiderations><p>
+ It is assumed that the project has some form of configuration management system, such as CVS, to maintain version and
+ configuration information and enable collaborative development of the system. Without this, all but the most trivial of
+ development will be virtually impossible.
+</p></keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/implementation.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/implementation.xmi
new file mode 100644
index 0000000..a210cad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/implementation.xmi
@@ -0,0 +1,45 @@
+<?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" epf:version="1.0.0" xmi:id="_D5dHQLv-EdmmUvZAZjqE3g" name="development,_0TeDoMlgEdmt3adZL5Dmdw" guid="_D5dHQLv-EdmmUvZAZjqE3g" changeDate="2006-09-29T13:39:25.971-0400" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Incrementally build the system.
+ </li>
+ <li>
+ Verify that the technical units used to build the system work as specified.
+ </li>
+</ul>
+<p>
+ With each iteration, the tasks in this discipline will evolve an ever more capable and ever more stable <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>.
+</p>
+<p>
+ When working on the system, the <a class="elementLink" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a>&nbsp;will use the architecture and also be constrained by the
+ architecture.
+</p>
+<p>
+ This&nbsp;discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;discipline defines&nbsp;what will be implemented.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis & Design</a>&nbsp;discipline organizes and constrains the
+ implementation.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a>&nbsp;discipline validates that system&nbsp;built meets
+ the&nbsp;requirements.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration & Change Management</a>&nbsp;discipline provides the mechanisms to
+ manage changes to the system built.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a>&nbsp;discipline plans what functionality will be implemented
+ in each iteration.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/project_management.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/project_management.xmi
new file mode 100644
index 0000000..90833d3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/project_management.xmi
@@ -0,0 +1,67 @@
+<?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" epf:version="1.0.0" xmi:id="_GybfgLv-EdmmUvZAZjqE3g" name="project_management,_0TqQ4MlgEdmt3adZL5Dmdw" guid="_GybfgLv-EdmmUvZAZjqE3g" changeDate="2006-09-28T15:15:05.712-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Keep the team focused on continually delivering tested software product for stakeholder evaluation
+ </li>
+ <li>
+ Help prioritize the sequence of work
+ </li>
+ <li>
+ Help create an effective working environment to maximize team productivity
+ </li>
+ <li>
+ Keep stakeholders and the team informed on project progress
+ </li>
+ <li>
+ Provide a framework to manage project risk and continually adapt to change
+ </li>
+</ul>
+<p>
+ Project management acts as a bridge between the stakeholders and the development team. It is important that project
+ management activities add value to creating a high performance work environment where
+</p>
+<ul>
+ <li>
+ Stakeholders have confidence in the team’s ability to successfully deliver value and understand the capabilities
+ and tradeoffs of the technical platform
+ </li>
+ <li>
+ Project team members understand stakeholder intentions and confirm that understanding by continually producing a
+ working software product for evaluation
+ </li>
+</ul>
+<p>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> works with <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> to create a coarse-grained <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Project Plan</a> based on the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>
+ for the project. This project plan describes the lengths and objectives of the four <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html" guid="__7xOEC7aEdqHMdmRzC0-2g">Phases</a> and the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Iterations</a> within each phase.
+</p>
+<p>
+ At the beginning of each iteration, the project manager works with stakeholders and the development team to prioritize
+ requirements, change requests, and defects in the <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Item List</a> and allocate them to the upcoming iteration.
+</p>
+<p>
+ The project manager then works with the development team to create a fine-grained <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> based on the objectives in the project plan and the work items
+ assigned to the iteration. Team members volunteer to collaborate on allocated work items and provide the project
+ manager with tasks and time estimates to deliver those work items.
+</p>
+<p>
+ The team demonstrates they understand stakeholder intentions throughout each iteration by building a working software
+ product that is demonstrated to stakeholders to affirm understanding and elicit feedback. At the end of each iteration,
+ the evaluation of the final <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>
+ must include test results and should be captured in a <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a> and communicated to all stakeholders and team members.
+</p>
+<p>
+ The development team demonstrates continual progress to stakeholders by reporting closed-out work items in each
+ iteration through the <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/reports/project_burndown,_ePrt8Dj3EduxovfWMDsntw.html" guid="_ePrt8Dj3EduxovfWMDsntw">Project Burndown</a>. The team can use <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Iteration Burndown</a> to demonstrate progress during an iteration.
+</p>
+<p>
+ Project management needs to consider the uncertainties facing the project (i.e. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Risks</a>) and pro-actively work with stakeholders and the team to continually adapt to
+ changes in business needs, system requirements, and technical capabilities.
+</p>
+<p>
+ Project Management is an umbrella discipline which has impact and is impacted by all other disciplines.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/requirements.xmi
new file mode 100644
index 0000000..ea1719b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/requirements.xmi
@@ -0,0 +1,63 @@
+<?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" epf:version="1.0.0" xmi:id="__rFCULv9EdmmUvZAZjqE3g" name="requirements,_0TR2ZMlgEdmt3adZL5Dmdw" guid="__rFCULv9EdmmUvZAZjqE3g" changeDate="2006-09-20T13:00:00.125-0400">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Understand the problem to be solved
+ </li>
+ <li>
+ Understand stakeholder needs (what users want)&nbsp;
+ </li>
+ <li>
+ Define the requirements for the solution (what the system must do)
+ </li>
+ <li>
+ Define the boundaries (scope) of the system
+ </li>
+ <li>
+ Identify external interfaces for the system
+ </li>
+ <li>
+ Identify technical constraints on the solution
+ </li>
+ <li>
+ Provide the basis for planning iterations
+ </li>
+ <li>
+ Provide the initial basis for estimating cost and schedule
+ </li>
+</ul>
+<p>
+ To achieve these goals, it is important to understand the definition and scope of the problem&nbsp;that we are trying
+ to solve.&nbsp; <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>&nbsp;are identified and the problem to be solved is defined.
+</p>
+<p>
+ Having agreed on the problem to be solved, the <a class="elementLink" href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;for the system are elicited, organized, analyzed, validated and
+ specified.
+</p>
+<p>
+ Throughout the lifecycle, changes to the requirements are managed.
+</p>
+<p>
+ The Requirements discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis & Design</a>&nbsp;discipline gets its primary input from the
+ Requirements discipline
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/test,_0TkKQMlgEdmt3adZL5Dmdw.html" guid="_0TkKQMlgEdmt3adZL5Dmdw">Test</a>&nbsp;discipline validates the system against the requirements
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration & Change Management</a>&nbsp;discipline provides the mechanisms to
+ manage changes to the requirements
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a>&nbsp;discipline plans the project and assigns
+ requirements&nbsp;to each iteration by analyzing the prioritized requirements and assigning work.&nbsp;
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/test.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/test.xmi
new file mode 100644
index 0000000..830f69f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/disciplines/test.xmi
@@ -0,0 +1,64 @@
+<?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" epf:version="1.0.0" xmi:id="_FuQswLv-EdmmUvZAZjqE3g" name="test,_0TkKQMlgEdmt3adZL5Dmdw" guid="_FuQswLv-EdmmUvZAZjqE3g" changeDate="2006-09-29T09:24:16.091-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Find and document defects.
+ </li>
+ <li>
+ Validate and prove the assumptions made in design and requirement specifications through concrete demonstration.
+ </li>
+ <li>
+ Validate that the software product works as designed.
+ </li>
+ <li>
+ Validate that the requirements are implemented appropriately.
+ </li>
+</ul>
+<p>
+ A good test effort is based on the philosophy of test early and test often. In addition, it is driven by questions such
+ as:
+</p>
+<ul>
+ <li>
+ How could this software break?
+ </li>
+ <li>
+ In what possible situations could this software fail to work predictably?
+ </li>
+</ul>
+<p>
+ Testing challenges the assumptions, risks, and uncertainty inherent in the work of other disciplines, and addresses
+ those concerns using concrete demonstration and impartial evaluation.
+</p>
+<p>
+ The Test discipline is related to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/requirements,_0TR2ZMlgEdmt3adZL5Dmdw.html" guid="_0TR2ZMlgEdmt3adZL5Dmdw">Requirements</a> discipline captures requirements for the software product, which is
+ one of the primary inputs for identifying what tests to perform.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/analysis_and_design,_0TX9AMlgEdmt3adZL5Dmdw.html" guid="_0TX9AMlgEdmt3adZL5Dmdw">Analysis and Design</a> discipline determines the appropriate design for the
+ software product, which is another important input for identifying what tests to perform.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/implementation,_0TeDoMlgEdmt3adZL5Dmdw.html" guid="_0TeDoMlgEdmt3adZL5Dmdw">Implementation</a> discipline produces builds of the software product that are
+ validated by the Test discipline. Within an iteration, multiple builds will be tested - typically one per test
+ cycle.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/project_management,_0TqQ4MlgEdmt3adZL5Dmdw.html" guid="_0TqQ4MlgEdmt3adZL5Dmdw">Project Management</a> discipline plans the project and the necessary work in each
+ iteration. Described in an Iteration Plan, this artifact is an important input used when you define the correct
+ evaluation mission for the test effort.
+ </li>
+ <li>
+ The <a class="elementLinkWithUserText" href="./../../openup_basic/disciplines/config_and_change_management,_0TwXgMlgEdmt3adZL5Dmdw.html" guid="_0TwXgMlgEdmt3adZL5Dmdw">Configuration and Change Management</a> discipline controls changes within the
+ project. The test effort verifies that each change has been completed appropriately. Test assets are kept
+ under&nbsp;configuration management.<br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/architecture.xmi
new file mode 100644
index 0000000..1bbb12a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/architecture.xmi
@@ -0,0 +1,2 @@
+<?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="-9qPK9k01PN_COE9YPXpw8Q" name="architecture,_xITr8MWXEdqWePvIjHInwg" guid="-9qPK9k01PN_COE9YPXpw8Q" changeDate="2006-04-06T11:51:46.047-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/change_management.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/change_management.xmi
new file mode 100644
index 0000000..e144c6a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/change_management.xmi
@@ -0,0 +1,2 @@
+<?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="-X9nP8esP9nWMvx1wmMaJAA" name="new_domain,_vUzp0MWeEdqiT9CqkRksWQ" guid="-X9nP8esP9nWMvx1wmMaJAA" changeDate="2006-04-06T11:54:47.268-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/development.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/development.xmi
new file mode 100644
index 0000000..fc45528
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/development.xmi
@@ -0,0 +1,2 @@
+<?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="-xO3vqWsd3W98UXFsyp-wGA" name="new_domain,_A9k3UMWfEdqiT9CqkRksWQ" guid="-xO3vqWsd3W98UXFsyp-wGA" changeDate="2006-04-06T11:56:28.463-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/openup_basic_wp.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/openup_basic_wp.xmi
new file mode 100644
index 0000000..dff2db6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/openup_basic_wp.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-15BvSftWbF7VdZ_W8YycBQ" name="openup_basic_domains,_s4Z9AMWXEdqWePvIjHInwg" guid="-15BvSftWbF7VdZ_W8YycBQ" changeDate="2006-10-09T16:14:59.437-0700">
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/work_product,_H4JXwB_SEdq6CKKKq4D7YA.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>, organized by <a class="elementLinkWithUserText" href="./../../base_concepts/guidances/termdefinitions/domain,_yHEVYdnmEdmO6L4XMImrsA.html" guid="_yHEVYdnmEdmO6L4XMImrsA">domains</a>. You can see the work products that have been included, and visit each work
+ product page to see its definition and relationships to other elements.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/project_management.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/project_management.xmi
new file mode 100644
index 0000000..0104954
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/project_management.xmi
@@ -0,0 +1,2 @@
+<?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="-N4r_U0LZhZ_K-8gfHON9BA" name="new_domain,_QxjGYMWfEdqiT9CqkRksWQ" guid="-N4r_U0LZhZ_K-8gfHON9BA" changeDate="2006-04-06T11:58:20.214-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/requirements.xmi
new file mode 100644
index 0000000..05c8de8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/requirements.xmi
@@ -0,0 +1,2 @@
+<?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="-d5O4LFNaAs4YRDxfxH3CRw" name="new_domain,_allMQMWfEdqiT9CqkRksWQ" guid="-d5O4LFNaAs4YRDxfxH3CRw" changeDate="2006-04-06T11:59:52.857-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/test.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/test.xmi
new file mode 100644
index 0000000..9e1cc97
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/domains/test.xmi
@@ -0,0 +1,2 @@
+<?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="-Mxgu9hq0upbMqZlq1xBFYw" name="new_domain,_ou4CMMWfEdqiT9CqkRksWQ" guid="-Mxgu9hq0upbMqZlq1xBFYw" changeDate="2006-04-06T12:00:58.171-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/actor.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/actor.xmi
new file mode 100644
index 0000000..aad7465
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/actor.xmi
@@ -0,0 +1,30 @@
+<?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="_KEldgMM1EdmSIPI87WLu3g" name="actor,_0VrDEMlgEdmt3adZL5Dmdw" guid="_KEldgMM1EdmSIPI87WLu3g" changeDate="2005-07-07T13:18:05.934-0700">
+ <sections xmi:id="_ytiigAYQEdubLa3RRn5f4A" name="Have you found all the actors" guid="_ytiigAYQEdubLa3RRn5f4A">
+ <sectionDescription>Have you accounted for all roles in the systems environment?&nbsp; See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for some questions that may help
+identify actors.</sectionDescription>
+ </sections>
+ <sections xmi:id="_AcjQMAYREdubLa3RRn5f4A" name="Is each actor involved with at least one use case" guid="_AcjQMAYREdubLa3RRn5f4A">
+ <sectionDescription>If you cannot identify a use case associated with a given actor perhaps the actor should be removed, or perhaps you are
+missing a use case.</sectionDescription>
+ </sections>
+ <sections xmi:id="_P3mo8AYREdubLa3RRn5f4A" name="Can you identify at least two people, or external systems, that would play the role of a particular actor" guid="_P3mo8AYREdubLa3RRn5f4A">
+ <sectionDescription>If you cannot, check if the role that the actor represents is part of another actor.&nbsp; If that is the case, you should
+merge the actors.</sectionDescription>
+ </sections>
+ <sections xmi:id="_b640oAYREdubLa3RRn5f4A" name="Will a particular actor use the system in several completely different ways" guid="_b640oAYREdubLa3RRn5f4A">
+ <sectionDescription><p>
+ If true, you should probably have more than one actor.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_iOHtQAYREdubLa3RRn5f4A" name="Does the actor have several completely different purposes for using the system" guid="_iOHtQAYREdubLa3RRn5f4A">
+ <sectionDescription>If true, there may be more than one actor.</sectionDescription>
+ </sections>
+ <sections xmi:id="_ptfB0AYREdubLa3RRn5f4A" name="Have you considered maintenance and administrative roles" guid="_ptfB0AYREdubLa3RRn5f4A">
+ <sectionDescription>It is common to focus on the daily users of the system, and forget about administrative and maintenance roles such as
+setting up user accounts, managing access rights, performing backups, etc.&nbsp; Ensure you have captured these actors.</sectionDescription>
+ </sections>
+ <sections xmi:id="_2i_UoAYREdubLa3RRn5f4A" name="Does each actor have a clear description of its role" guid="_2i_UoAYREdubLa3RRn5f4A">
+ <sectionDescription>Each actor should have a short description of the role and the main goal the actor has in using the system.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/architecture.xmi
new file mode 100644
index 0000000..c894e97
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/architecture.xmi
@@ -0,0 +1,141 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_17Ve8Nd6EdmIm-bsRSNCgw" name="architecture,_17PYUNd6EdmIm-bsRSNCgw" guid="_17Ve8Nd6EdmIm-bsRSNCgw" authors="Chris Doyle, Mark Dickson" changeDate="2007-03-03T09:34:09.111-0800" changeDescription="(Mark Dickson) formatted & applied changes from Chris Doyle |Major re-|Major re-write in line with Supporting Requirements checklist" version="1.3">
+ <mainDescription><p>
+ The items in this checklist represent good practices for creating and communicating a robust architecture. It may not
+ be possible to address every item, and some items may only be able to be addressed to a limited extent. In these cases,
+ be sure that there are good reasons for only partially addressing an item, or not addressing an item at all.
+</p>
+<p>
+ Architecture can be performed every day. Use this checklist regularly to ensure the results are robust, consistent, and
+ understandable. Make the architecture good enough for the specific goals being addressed by using this checklist to
+ identify areas that have been skipped, ignored, or not sufficiently addressed.
+</p></mainDescription>
+ <sections xmi:id="_LqpmkCALEduY2JH31Kkn-A" name="Is the overall structure of the architecture clear?" guid="_LqpmkCALEduY2JH31Kkn-A">
+ <sectionDescription><ul>
+ <li>
+ Are the key abstractions adequately defined?
+ </li>
+ <li>
+ Have&nbsp;necessary&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s been identified and described?
+ </li>
+ <li>
+ Does the architecture divide the system’s responsibilities into well-defined subsystems with well-defined
+ interfaces?
+ </li>
+ <li>
+ Does the packaging approach reduce complexity and improve understanding?
+ </li>
+ <li>
+ Is subsystem and package partitioning and layering logically consistent?
+ </li>
+ <li>
+ Are packages defined to be highly cohesive within the package, while the packages themselves are loosely coupled?
+ </li>
+ <li>
+ Are all of the subsystem components for the iteration identified?
+ </li>
+ <li>
+ Do the dependencies between subsystems and packages correspond to dependency relationships between the contained
+ classes?
+ </li>
+ <li>
+ Do the classes in a subsystem support the services identified for the subsystem?
+ </li>
+ <li>
+ Are the number and types of components reasonable?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_pWBfQMm9EduiAPR4gd-qxA" name="Have the supporting requirements been adequately addressed?" guid="_pWBfQMm9EduiAPR4gd-qxA">
+ <sectionDescription><ul>
+ <li>
+ Does the architecture adequately address&nbsp;the global Functional requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Usability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Reliability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Performance requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the&nbsp;Supportability requirements?
+ </li>
+ <li>
+ Does the architecture adequately address&nbsp;the other needs identified in the&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_PHv_kCALEduY2JH31Kkn-A" name="Can the architecture be delivered by the team?" guid="_PHv_kCALEduY2JH31Kkn-A">
+ <sectionDescription><ul>
+ <li>
+ Does the component architecture provide a suitable basis for organizing the development teams?
+ </li>
+ <li>
+ Does each team have the skills required to implement their allocated components?
+ </li>
+ <li>
+ Are responsibilities divided well between teams?
+ </li>
+ <li>
+ Do all team members share the same understanding of the architecture as the one presented by the architect?
+ </li>
+ <li>
+ Can team members understand enough from the architecture to successfully design and code their allocated
+ components?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_A8m2YMm7EduiAPR4gd-qxA" name="Is architecture showing appropriate stability?" guid="_A8m2YMm7EduiAPR4gd-qxA">
+ <sectionDescription><ul>
+ <li>
+ If in Inception, is&nbsp;a candidate&nbsp;architecture emerging?
+ </li>
+ <li>
+ If in Elaboration, is the architecture beginning to stabilize?
+ </li>
+ <li>
+ If in Construction, is the architecture generally stable?
+ </li>
+ <li>
+ If in Transition, is the architecture very stable?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_aOKkwMm8EduiAPR4gd-qxA" name="In general, does the architecture seem sensible?" guid="_aOKkwMm8EduiAPR4gd-qxA">
+ <sectionDescription><ul class="noindent">
+ <li>
+ Is the&nbsp;architecture&nbsp;at an appropriate level of detail, given the objectives?
+ </li>
+ <li>
+ Are concepts&nbsp;handled in the simplest way possible?
+ </li>
+ <li>
+ Can the&nbsp;architecture easily evolve,&nbsp;so that&nbsp;expected changes can be easily accommodated?
+ </li>
+ <li>
+ At the same time, has the&nbsp;architecture been overly structured to handle unlikely change at the expense of
+ simplicity and comprehensibility? (Hint: "Yes" to this question is not good).
+ </li>
+ <li>
+ Are the key assumptions and decisions that the&nbsp;architecture is based on documented and visible to reviewers
+ and consumers of the architecture?
+ </li>
+ <li>
+ Is the architecture description current?
+ </li>
+ <li>
+ Have the design guidelines been followed?
+ </li>
+ <li>
+ Are all technical risks either mitigated or addressed in a contingency plan?
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/design.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/design.xmi
new file mode 100644
index 0000000..4b511b6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/design.xmi
@@ -0,0 +1,131 @@
+<?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" epf:version="1.0.0" xmi:id="_YIYIYMM1EdmSIPI87WLu3g" name="design,_0XSzsMlgEdmt3adZL5Dmdw" guid="_YIYIYMM1EdmSIPI87WLu3g" changeDate="2006-09-15T15:28:43.942-0400" version="1.0.0">
+ <mainDescription><p>
+ The items in this checklist represent good practices for creating and communicating a robust design. Try to address
+ every item to the greatest extent possible to create the best design. It may not be possible to address every item, and
+ some items may only be able to be addressed to a limited extent. In these cases, be sure that there are good reasons
+ for only partially addressing an item, or not addressing an item at all.
+</p>
+<p>
+ Design can be performed every day. Use this checklist regularly to assure the design is robust, consistent, and
+ understandable. Make the design good enough for the specific goals being addressed by using this checklist to identify
+ areas that have been skipped, ignored, or not sufficiently addressed.
+</p></mainDescription>
+ <sections xmi:id="_cKSvsD6SEduAL-bCqar_dg" name="General" guid="_cKSvsD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Do separate design elements have low coupling? Does each design element have high internal cohesion?
+</p>
+<p>
+ Does the design reflect the architectural objectives of the system?
+</p>
+<p>
+ Can the system be implemented from the information in the design? Has sufficient detail been included?
+</p>
+<p>
+ Is the design consistent? Does any part of the design contradict another part of it in such a way that puts the project
+ at risk?
+</p>
+<p>
+ Is the design able to accommodate future changes?
+</p>
+<p>
+ Is the design appropriate to the experience level of other team members and stakeholders, neither too simple nor too
+ advanced?
+</p>
+<p>
+ Is the design written in such a way, and is it structured well enough, so it can be maintained easily?
+</p>
+<p>
+ Does the design constrain the implementation only as much as is necessary?
+</p>
+<p>
+ Does the design describe all the behavior of the system for the requirements that are currently being addressed?
+</p>
+<p>
+ Can all parts of the design be traced back to the requirements? Can the requirements (for the current iteration) be
+ traced to design elements?
+</p>
+<p>
+ Is there an unambiguous place or places&nbsp;in the design where each behavior exists?
+</p>
+<p>
+ Are the use case flows that are currently being addressed described in the design?
+</p>
+<p>
+ Are&nbsp;complex flows outside the Basic Flow&nbsp;addressed, including exceptional cases?
+</p>
+<p>
+ Has the behavior described in the requirements that are currently being addressed&nbsp;been distributed to the correct
+ design elements?
+</p>
+<p>
+ Does the design provide enough information for test design? For example, are the collaborations between design elements
+ clear enough to create integration tests?
+</p>
+<p>
+ Have redundant areas of the design been removed so the Implementation does not contain redundant code?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="__4O2AD6WEduAL-bCqar_dg" name="Organization and Clarity" guid="__4O2AD6WEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Does the design describe the system at the appropriate level of abstraction, given the objectives? This usually means
+ the system is described at a number of different levels of&nbsp;abstraction and perspectives.
+</p>
+<p>
+ Does the design use common vocabulary and terms from the business and technical domains?
+</p>
+<p>
+ Does the design describe the behavior of the elements unambiguously to the extent that developer tests can be created
+ toverify the implementation?
+</p>
+<p>
+ Are the design's constructs, vocabulary, and semantics appropriate to the problem being solved? This usually means the
+ customer's vocabulary is used, and elements of the design are referenced in a consistent manner.
+</p>
+<p>
+ Is the design organized in a way that team members can easily find the information they're looking for?
+</p>
+Is the notation used to&nbsp;describe the design&nbsp;used consistently?<br />
+<p>
+ Is the design organized in a way that helps team members modify it without contending for the same part of the design?
+ That is, can mulitple people work on the design in parallel?
+</p>
+<p>
+ Are the names of elements within the design consistent and easy to interpret?
+</p>
+<p>
+ Does each design element represent a clearly defined abstraction?
+</p>
+<p>
+ Is the design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to
+ implementers?
+</p>
+<p>
+ Is the design clear enough and contain enough detail so it can be implemented?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_dahBcD6SEduAL-bCqar_dg" name="Architecture" guid="_dahBcD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Is the architecture clearly called out in the design ? Can team members and stakeholders clearly identify the portion
+ of the design that is the architecture?
+</p>
+<p>
+ Are architectural mechanisms (patterns) clearly defined in the design so they're reusable and understandable?
+</p>
+<p>
+ Are architectural mechanisms used appropriately? Are they applied in all applicable circumstances?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_kWnQ4D6SEduAL-bCqar_dg" name="Subsystems" guid="_kWnQ4D6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the&nbsp;only
+ way to access the behavior of elements inside the subsystem?
+</p>
+<p>
+ Is the interface for each subsystem clearly defined in the design?
+</p>
+<p>
+ Are the subsystem dependencies documented?&nbsp;
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/design_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/design_vm.xmi
new file mode 100644
index 0000000..838d45e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/design_vm.xmi
@@ -0,0 +1,114 @@
+<?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" epf:version="1.0.0" xmi:id="-HQSI39vBrjpmQL1qHYOJtA" name="new_checklist,_nnSXcD6SEduAL-bCqar_dg" guid="-HQSI39vBrjpmQL1qHYOJtA" version="1.0.0">
+ <sections xmi:id="_sG8ZoD6SEduAL-bCqar_dg" name="Packages and Organization" guid="_sG8ZoD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Is the package partitioning logical and consistent? Does it make sense to team members and stakeholders?
+</p>
+<p>
+ Do package names accurately describe the contents of the package and the role they play in the architecture? Do they
+ follow naming conventions?
+</p>
+<p>
+ Do public packages and interfaces provide a logically cohesive set of services?
+</p>
+<p>
+ Are all the contents of a package listed? Are the classes within a package cohesive?
+</p>
+<p>
+ Do package dependencies correspond to the dependencies of the contained classes?
+</p>
+<p>
+ Are there packages or classes within a package that can be separated into and independent or sub-package?<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_tx6tsD6SEduAL-bCqar_dg" name="Views" guid="_tx6tsD6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Does each diagram help the designer reason about the design, or communicate key design decisions to the team?
+</p>
+<p>
+ Are the relationships between diagrams clear when several diagrams are used to describe behavior?
+</p>
+<p>
+ Is it easy to navigate between related diagrams?
+</p>
+<p>
+ Does each diagram focus on a relevant perspective? For instance, does a set of diagrams show a single class and its
+ direct relationships, rather than using&nbsp;one or two diagrams to show all classes?
+</p>
+<p>
+ Is each diagram complete and minimal? Does it show everything relevant to that view and nothing more?
+</p>
+<p>
+ Are the diagrams tidy and easy to interpret, with a minimum of clutter?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_yeFh4D6SEduAL-bCqar_dg" name="UML" guid="_yeFh4D6SEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Does the visual model conform to UML standards so all stakeholders can understand the model over time? See the&nbsp;<a href="http://www.uml.org/" target="_blank">OMG UML Resource Page</a>&nbsp;for more information.
+</p>
+<p>
+ Does the visual model conform to project or organization specific modeling standards?
+</p>
+Is the visual model internally consistent? For instance, if an object diagram shows a relationship between objects, does a
+corresponding relationship exist between the appropriate classes?<br />
+<p>
+ Does the name of each class clearly reflect the role it plays?
+</p>
+<p>
+ Does each class offer the required behavior?
+</p>
+<p>
+ Is there at least one&nbsp;realization association defined for each interface? The realization may represent a 3rd
+ party implementation of the subsystem.
+</p>
+<p>
+ Are&nbsp;there dependency associations from each subsystem to the interfaces it uses?
+</p>
+<p>
+ Is each operation in a subsystem interface described in a sequence diagram? Or at least mapped directly to an operation
+ in a class?
+</p>
+<p>
+ Does each class represent a single well defined abstraction?
+</p>
+<p>
+ Are generalization relationships used only to inherit definitions, not behavior (implementation)? In other words, is
+ behavior shared through the use of association, aggregation and containment relationships instead of generalization?
+</p>
+<p>
+ Are parent classes in generalization relationships abstract? Are the "leaf" classes in a generalization hierarchy the
+ only concrete classes?
+</p>
+<p>
+ Are stereotypes used consistently and meaningfully?
+</p>
+<p>
+ Do&nbsp;statecharts exist for classes with complex or restrictive state changes?
+</p>
+<p>
+ Do relationships have descriptive role or association names (one or the other but not both), and&nbsp;correct
+ multiplicities?
+</p>
+<p>
+ Are relationships between classes unidirectional whenever possible?<br />
+ &nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_IsDY4D6TEduAL-bCqar_dg" name="Non-UML Visual Modeling" guid="_IsDY4D6TEduAL-bCqar_dg">
+ <sectionDescription><p>
+ Are the semantics of the visual modeling language clearly defined, documented, and accessible to team members? The
+ semantics should be meaninful to the users of the model.
+</p>
+<p>
+ Can the semantics of the modeling language be understood over time? Is the language documented well enough so that team
+ members can understand the model long after design decisions have taken place?
+</p>
+<p>
+ Are team members and stakeholders trained in the modeling language being used?
+</p>
+<p>
+ Does the visual model conform to the semantics of the visual modeling language? In other words, are the meanings
+ of&nbsp;the symbols in the diagrams&nbsp;consistent across the model and diagrams?&nbsp;
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/good_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/good_requirements.xmi
new file mode 100644
index 0000000..915dac0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/good_requirements.xmi
@@ -0,0 +1,79 @@
+<?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" epf:version="1.0.0" xmi:id="-2o1pXjHpSEPN_rohLce5jA" name="good_requirements_1,_jxn9EO0HEdqHTdbLTmC5IQ" guid="-2o1pXjHpSEPN_rohLce5jA" authors="Chris Sibbald" changeDate="2006-04-10T11:07:04.339-0400" changeDescription="Added checklist for good requirements in accordance with Feb. 23, 2006 minutes of RM SIG." version="0.1">
+ <sections xmi:id="_jxuDsu0HEdqHTdbLTmC5IQ" name="Is the requirement correct?" guid="_jxuDsu0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Does the requirement specify a true need, desire, or obligation?
+</p>
+<p>
+ Have you identified the "root cause" for the requirement?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDs-0HEdqHTdbLTmC5IQ" name="Is the requirement complete?" guid="_jxuDs-0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement stated as a complete sentence?
+</p>
+<p>
+ Is the requirement stated entirely in one place, in a manner that does not force the reader to look at additional
+ information to understand the requirement?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDse0HEdqHTdbLTmC5IQ" name="Is the requirement clear?" guid="_jxuDse0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement unambiguous and not confusing?
+</p>
+<p>
+ Does everyone agree on the meaning of the requirement?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDt-0HEdqHTdbLTmC5IQ" name="Is the requirement consistent" guid="_jxuDt-0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement in conflict with other requirements?
+</p>
+<p>
+ Is the terminology used consistent with other requirements and glossary terms?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDte0HEdqHTdbLTmC5IQ" name="Is the requirement verifiable?" guid="_jxuDte0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Can we determine whether the system satisfies the requirement?
+</p>
+<p>
+ Is it possible to define a clear, unambiguous&nbsp;pass/fail criterion?
+</p>
+<p>
+ Is it possible to determine if the requirement has been met via inspection, analysis, demonstration or test?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDtu0HEdqHTdbLTmC5IQ" name="Is the requirement traceable?" guid="_jxuDtu0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Is the requirement uniquely identified so it can be unambiguously referenced?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDtO0HEdqHTdbLTmC5IQ" name="Is the requirement feasible?" guid="_jxuDtO0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Can the requirement be satisfied within cost and on schedule?
+</p>
+<p>
+ Is the requirement technically feasible with current technology?
+</p>
+<p>
+ Is the requirement physically achievable?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jxuDsO0HEdqHTdbLTmC5IQ" name="Is the requirement design independent?" guid="_jxuDsO0HEdqHTdbLTmC5IQ">
+ <sectionDescription><p>
+ Are all requirements that impose constraints on the design, limiting design options,&nbsp;justified?
+</p>
+<p>
+ Is the requirement stated in such that there is more than one way that it can be satisfied?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_gRb_IJEvEdui_vx06Mo1eg" name="Is the requirement atomic?" guid="_gRb_IJEvEdui_vx06Mo1eg">
+ <sectionDescription><p>
+ Does the requirement statement define exactly one requirement?
+</p>
+<p>
+ Is the requirement statement free of conjunctions (and, or, but) that may indicate multiple requirements?
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/risk_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/risk_list.xmi
new file mode 100644
index 0000000..c8e1473
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/risk_list.xmi
@@ -0,0 +1,36 @@
+<?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="-gqNN4DnROmJpgKtrdguhpg" name="new_checklist,_7BZa0DIdEduDTv4Y1akVTA" guid="-gqNN4DnROmJpgKtrdguhpg" changeDate="2006-08-22T13:38:14.915-0700">
+ <sections xmi:id="_qO41ADIfEduDTv4Y1akVTA" name="Have all potential risks to the project been identified" guid="_qO41ADIfEduDTv4Y1akVTA">
+ <sectionDescription>Have you identified anything that can be on the path to the project success? List all potential risks, giving a description
+and type (direct or indirect). See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <sections xmi:id="_5RiSkDe2EduD7J48kKN20g" name="Are risks described without ambiguity" guid="_5RiSkDe2EduD7J48kKN20g">
+ <sectionDescription>Make sure you capture and describe risks in a clear, concise and unambiguous way. Also follow these rules when describing
+mitigation strategies for risks. This will avoid unnecessary work and - more importantly -&nbsp;that a risks are
+effectively identified and managed.</sectionDescription>
+ </sections>
+ <sections xmi:id="_2rpQoDIfEduDTv4Y1akVTA" name="What is the probability of happening and impact of each risk" guid="_2rpQoDIfEduDTv4Y1akVTA">
+ <sectionDescription>Determine&nbsp;the probability of the risk happening and its impact on the project. This gives you the order of magnitude
+of risks (probability x impact), allowing you to address the high magnitude risks early in the project. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <sections xmi:id="_x-gbwDe0EduD7J48kKN20g" name="Have the risks been properly prioritized and sorted" guid="_x-gbwDe0EduD7J48kKN20g">
+ <sectionDescription>The risk list is a prioritized list with the highest risk at the top and the rest in descending order.&nbsp; They should be
+sorted according to their magnitude of risk.</sectionDescription>
+ </sections>
+ <sections xmi:id="_hSFaYDe3EduD7J48kKN20g" name="Are there interdependencies between risks" guid="_hSFaYDe3EduD7J48kKN20g">
+ <sectionDescription><p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Make sure you establish interdependencies between risks as
+ appropriate. For example, the consequence of a risk happening may raise the probability of another risk happening, or
+ raise the impact that other risk brings to the project. If risks depend on each other, you may need to
+ mitigate&nbsp;all interdependent risks&nbsp;at the same time, or revisit the risk list to update the magnitude of
+ dependent risks.</span>
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_LATHgDIeEduDTv4Y1akVTA" name="Is there a mitigation strategy for each risk" guid="_LATHgDIeEduDTv4Y1akVTA">
+ <sectionDescription><p>
+ Propose a mitigation strategy for each identified risk. You can either transfer the risk, avoid it, accept it or
+ mitigate it (by minimizing the probability&nbsp;of happening or impact&nbsp;that the risk brings to the project). See
+ <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/risk_management,_VNxL4ACsEdu8m4dIntu6jA.html" guid="_VNxL4ACsEdu8m4dIntu6jA">Concept: Risk Management</a> for more information.
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/supporting_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/supporting_requirements.xmi
new file mode 100644
index 0000000..fdd61b1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/supporting_requirements.xmi
@@ -0,0 +1,98 @@
+<?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" epf:version="1.0.0" xmi:id="-kw2vYHKDkWv2tZrDMrBPNA" name="new_checklist,_Vael8CGMEdu3VKXZx45D3A" guid="-kw2vYHKDkWv2tZrDMrBPNA" version="1.0.0">
+ <sections xmi:id="_kTZiACGMEdu3VKXZx45D3A" name="Have global Functional requirements that will be implemented in the next iteration been captured and validated?" guid="_kTZiACGMEdu3VKXZx45D3A">
+ <sectionDescription><ul>
+ <li>
+ Are functional requirements that affect multiple Use Cases identified? For example, all Use Cases may be subject to
+ access control, audit trail, general responses to abnormal situations (overflow, communication facilities, error
+ handling and recovery) and so on.
+ </li>
+ <li>
+ For each of these requirements, are they behavioral and better captured in a common Use Case?
+ </li>
+ <li>
+ For each of these functions, is it clear how input and shared data generate output and shared data?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_-eJXoCGMEdu5QMD9IAHRNg" name="Have Usability requirements that will be implemented in the next iteration been captured and validated?" guid="_-eJXoCGMEdu5QMD9IAHRNg">
+ <sectionDescription><ul>
+ <li>
+ Have the efficiency and usability factors of user tasks been considered?&nbsp;
+ </li>
+ <li>
+ Are the requirements specified in a way that is verifiable, including metrics and target values?
+ </li>
+ <li>
+ Have&nbsp;novice as well as expert users been considered?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_QCbtwCGNEdubdKsr57an1g" name="Have Reliability requirements that will be implemented in the next iteration been captured and validated?" guid="_QCbtwCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Have reliability requirements been specified as measurable requirements or prioritized design goals?
+ </li>
+ <li>
+ Is error checking and recovery required?
+ </li>
+ <li>
+ Are undesired events considered and their required responses specified?
+ </li>
+ <li>
+ Are initial or special states considered (such as cold starts or abnormal termination)?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_e3pOgCGNEdubdKsr57an1g" name="Have Performance requirements that will be implemented in the next iteration been captured and validated?" guid="_e3pOgCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Have the resource and performance margin requirements been stated (speed, response time, recovery time of various
+ software functions)?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_l8CeUCGNEdubdKsr57an1g" name="Have Supportability requirements that will be implemented in the next iteration been captured and validated?" guid="_l8CeUCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Are there any requirements that will enhance the supportability or maintainability of the system being built?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_wIttsCGNEdubdKsr57an1g" name="Have Constraints that must be considered in the next iteration been captured and validated?" guid="_wIttsCGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Are there any required standards in effect, implementation language, policies for database integrity, resource
+ limits, operating environment(s), etc.?
+ </li>
+ <li>
+ Has the use of inherited design or code or pre-selected tools been specified?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_5j6c0CGNEdubdKsr57an1g" name="Have External Interfaces that must be considered in the next iteration been identified?" guid="_5j6c0CGNEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Is it clear how the software interacts with people, the system's hardware, other hardware, and other software?
+ </li>
+ <li>
+ Have all critical data elements that cross system boundaries been identified for those scenarios that will be
+ implemented in the next iteration?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_H052MCGOEdubdKsr57an1g" name="Have Business Rules that will be implemented in the next iteration been captured and validated?" guid="_H052MCGOEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Are the rules relevant to the use cases identified (data validation rules, formulas, flow decisions)?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_NBM78CGOEdubdKsr57an1g" name="Have applicable Standards and Regulatory Compliance requirements that must be considered in the next iteration been identified?" guid="_NBM78CGOEdubdKsr57an1g">
+ <sectionDescription><ul>
+ <li>
+ Have all requirements derived from existing standard and regulations been specified?
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/test_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/test_case.xmi
new file mode 100644
index 0000000..eca756f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/test_case.xmi
@@ -0,0 +1,53 @@
+<?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" epf:version="1.0.0" xmi:id="_kwHAgMPbEdmbOvqy4O0adg" name="test_case,_0Zxf8MlgEdmt3adZL5Dmdw" guid="_kwHAgMPbEdmbOvqy4O0adg" changeDate="2005-07-07T16:45:15.861-0400" version="1.0.0">
+ <sections xmi:id="_yXujsLcOEduFFo_97woSMw" name="General" guid="_yXujsLcOEduFFo_97woSMw">
+ <sectionDescription><ul>
+ <li>
+ Does the Test Case identify the requirement it evaluates?&nbsp; This linking might be informal through a naming
+ convention or formalized through a requirements traceability matrix.
+ </li>
+ <li>
+ Does the Test Case reference the preconditions and postconditions that apply to it?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_Hv2n0BBbEduXULqRagzBHA" name="Name" guid="_Hv2n0BBbEduXULqRagzBHA">
+ <sectionDescription><ul>
+ <li>
+ Is the&nbsp;Test Case name unique?
+ </li>
+ <li>
+ Does&nbsp;the name express a test condition or&nbsp;an expected result?
+ </li>
+ <li>
+ Is&nbsp;it unambiguous to a stakeholder?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_3i-gkLcOEduFFo_97woSMw" name="Brief Description" guid="_3i-gkLcOEduFFo_97woSMw">
+ <sectionDescription><ul class="noindent">
+ <li>
+ Is the logical test condition clearly identified in the description?
+ </li>
+ <li>
+ Does the description clearly&nbsp;state the expected result?
+ </li>
+ <li>
+ Is the expected result stated as a concrete&nbsp;outcome?
+ </li>
+ <li>
+ Can a casual reader distinguish this Test Case from a similar one?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_4uresLcOEduFFo_97woSMw" name="Test Data Needs" guid="_4uresLcOEduFFo_97woSMw">
+ <sectionDescription><ul>
+ <li>
+ Does the Test Case note the kinds of test data required to implement a detailed Test Script?
+ </li>
+ <li>
+ Are&nbsp;the test data type, uniqueness, and quality sufficiently explained?
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/test_script.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/test_script.xmi
new file mode 100644
index 0000000..f051632
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/test_script.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="_4LuPMMPcEdmbOvqy4O0adg" name="test_script,_0Z9tMMlgEdmt3adZL5Dmdw" guid="_4LuPMMPcEdmbOvqy4O0adg" changeDate="2005-07-26T16:21:21.082-0400" version="1.0.0">
+ <sections xmi:id="_DiPTsE_cEduqM_QlWBlZ_g" name="Does the test script conform to the related test case" guid="_DiPTsE_cEduqM_QlWBlZ_g">
+ <sectionDescription>Ensure that the test script conforms to the specification established in the test case if one is associated with the test
+script.&nbsp; The test case captures the intent of the test; the test script must conform to this intent.</sectionDescription>
+ </sections>
+ <sections xmi:id="_KS930Bg9EduxCP6DVVLxsA" name="Is the test script testable" guid="_KS930Bg9EduxCP6DVVLxsA"/>
+ <sections xmi:id="_H-q58Bg9EduxCP6DVVLxsA" name="Is the test script reusable" guid="_H-q58Bg9EduxCP6DVVLxsA">
+ <sectionDescription>Ensure that your test scripts can be reused by designing your test scripts to maximize reuse.&nbsp; Promoting reuse takes
+different forms depending on whether you are generating, programming, or recording test scripts.</sectionDescription>
+ </sections>
+ <sections xmi:id="_5_92wE_cEduqM_QlWBlZ_g" name="Is the test script prescriptive and unambiguous" guid="_5_92wE_cEduqM_QlWBlZ_g">
+ <sectionDescription>Ensure that the test script represents clear instructions on how the test must be run and how the results should be
+analyzed.&nbsp; While non-automated tests can be written in such a way that the tester can have leeway in how the test is
+precisely run, there is no room for creativity in how the test results are to be analyzed for success or failure.</sectionDescription>
+ </sections>
+ <sections xmi:id="_La5wQBg9EduxCP6DVVLxsA" name="Is the test script named consistently with your other test work products" guid="_La5wQBg9EduxCP6DVVLxsA">
+ <sectionDescription>Ensure that the naming of your test scripts is consistent with other test-related work products.&nbsp; For example, if you
+are creating test classes for each of your test cases, ensure that the naming represents this relationship.&nbsp;
+Alternatively, if you are building test scripts inside of a library, use a consistent naming convention to reflect the
+library or libraries.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Ng5zcBg9EduxCP6DVVLxsA" name="Does your test script provide test coverage" guid="_Ng5zcBg9EduxCP6DVVLxsA">
+ <sectionDescription>Ensure that your test scripts provide test coverage consistent with the system under test.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/uc_model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/uc_model.xmi
new file mode 100644
index 0000000..050988c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/uc_model.xmi
@@ -0,0 +1,92 @@
+<?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" epf:version="1.0.0" xmi:id="_MqODAMM1EdmSIPI87WLu3g" name="uc_model,_0U6OEMlgEdmt3adZL5Dmdw" guid="_MqODAMM1EdmSIPI87WLu3g" changeDate="2005-07-07T14:50:06.005-0400" version="1.0.0">
+ <sections xmi:id="_rLdVMAeREduWycDgioo5rg" name="Is it easy to understand what the system does by reviewing the model?" guid="_rLdVMAeREduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ The Use-Case Survey provides a clear, concise overview of the purpose and functionality of the system.
+ </li>
+ <li>
+ There are no long chains of include relationships, such as when an included use case&nbsp;includes other use
+ cases.&nbsp; These can obscure comprehensibility.
+ </li>
+ <li>
+ Included use cases should not make assumptions about use cases that include them.
+ </li>
+ <li>
+ If several use cases contain similar&nbsp;sub-flows investigate if&nbsp;factoring this&nbsp;common behavior into an
+ included use case will simplify the model.&nbsp;
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="__kgR8AeREduWycDgioo5rg" name="Have all use cases been identified?" guid="__kgR8AeREduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ The use cases identified collectively account for all required behavior of the system.
+ </li>
+ <li>
+ All features identified in the Vision document for this iteration have been addressed by at least one use case.
+ </li>
+ <li>
+ All non-functional requirements that must be satisfied by a specific use case have been captured in that use case
+ </li>
+ <li>
+ The use-case model contains no superfluous behavior (gold-platting).
+ </li>
+ <li>
+ Each concrete use case must be associated with at least one actor.
+ </li>
+ <li>
+ Every actor should be associated with at least on use case.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_fknU0Jz1EduBcbjYtLtItQ" name="Is the model consistent?" guid="_fknU0Jz1EduBcbjYtLtItQ">
+ <sectionDescription><ul>
+ <li>
+ Under the same conditions, and with the same input, the system behavior should be consistent.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_KowpkAeSEduWycDgioo5rg" name="Are all relationships between use cases required?" guid="_KowpkAeSEduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ Each included use case should make the model easier to understand, implement and maintain.
+ </li>
+ <li>
+ Each concrete use case (i.e. not an included use case) should be independent of other use cases.
+ </li>
+</ul>
+<p>
+ <br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_jyHeMAeTEduWycDgioo5rg" name="Are use-case packages used appropriately?" guid="_jyHeMAeTEduWycDgioo5rg">
+ <sectionDescription><ul>
+ <li>
+ Cross-package dependencies have been reduced or eliminated to prevent model ownership conflicts
+ </li>
+ <li>
+ Packaging is intuitive and makes the model easier to understand and implement
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_i-S-ADeKEdu6VLD0YaVLog" name="Do all model elements have appropriate names?" guid="_i-S-ADeKEdu6VLD0YaVLog">
+ <sectionDescription><ul>
+ <li>
+ No two use cases can have the same name.
+ </li>
+ <li>
+ Each actor has a name that effectively describes the role.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_IYRUkJz2EduBcbjYtLtItQ" name="Are individual use cases properly specified?" guid="_IYRUkJz2EduBcbjYtLtItQ">
+ <sectionDescription><ul>
+ <li>
+ Review the quality of each&nbsp;use case specification using the <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html"
+ guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>.
+ </li>
+</ul></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/use_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/use_case.xmi
new file mode 100644
index 0000000..f14699e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/use_case.xmi
@@ -0,0 +1,111 @@
+<?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" epf:version="1.0.0" xmi:id="-T2IeqdOunweffIDgL-aM0w" name="use_case,_0Vk8cMlgEdmt3adZL5Dmdw" guid="-T2IeqdOunweffIDgL-aM0w" authors="Paul Bramble" changeDate="2006-05-01T13:13:56.264-0400" version="0.1">
+ <copyrightStatement href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uuunoPsDEdmyhNQr5STrZQ"/>
+ <sections xmi:id="_663wMNk1Edq2Q8qZoWbvGA" name="Is the use-case name meaningful and un-ambiguous?" guid="_663wMNk1Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ Does the use case have a unique name?
+</p>
+<p>
+ Is the name a verb + noun phrase (for example, Withdraw Cash)?
+</p>
+<p>
+ Does the name accurately&nbsp;summarize the&nbsp;main goal&nbsp;of the use case?
+</p>
+<p>
+ Is the name "actor independent"?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_ZTA8QJznEduBcbjYtLtItQ" name="Does the brief description clearly describe the primary goal of the use case?" guid="_ZTA8QJznEduBcbjYtLtItQ">
+ <sectionDescription><p>
+ Is it clear from the brief description what the main purpose of the use case is?
+</p>
+<p>
+ Is the "observable result of value" obvious?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_4wJRgJznEduBcbjYtLtItQ" name="Are associated actors and information exchanged clearly defined?" guid="_4wJRgJznEduBcbjYtLtItQ">
+ <sectionDescription><p>
+ Is the use case associated with one or more actors?
+</p>
+<p>
+ Is the primary, or initiating actor, defined?
+</p>
+<p>
+ Is it clear who wishes to perform the use case?
+</p>
+<p>
+ Is all information exchanged between the actor(s) and the system clearly specified?
+</p>
+<p>
+ If a "time" actor is used, are you sure you did not miss an important actor and associated use cases (such as
+ administrative or maintenance personnel that define schedule events)?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Qys_INk2Edq2Q8qZoWbvGA" name="Are the pre-conditions specified?" guid="_Qys_INk2Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ Does each pre-condition represent a tangible&nbsp;state&nbsp;of&nbsp;the system (for example, the Withdraw Cash use
+ case for an automated teller machine has a precondition that the user has an account)?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_q3qV0Nk2Edq2Q8qZoWbvGA" name="Are the Basic Flow and Alternate Flows complete, correct and consistent?" guid="_q3qV0Nk2Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ Is it clear how the use case is started?
+</p>
+<p>
+ Is the triggering event clearly described?
+</p>
+<p>
+ Does the flow have a definite ending?
+</p>
+<p>
+ Does&nbsp;each step in the scenario contain&nbsp;the same level of abstraction?&nbsp;&nbsp;
+</p>
+<p>
+ Does each step in the scenario describe something that can actually happen and that the system can reasonably detect?
+</p>
+<p>
+ Does each step make&nbsp;progress towards the goal?
+</p>
+<p>
+ Are there any missing steps? Is it clear how to go from one step to the next? Does the sequence of communication
+ between the actors and the use case conform to the user's expectations?
+</p>
+<p>
+ Does each step describe how the step helps the actor achieve their goal?
+</p>
+<p>
+ Is each step technology independent? Is it free of technical details, and design decisions?
+</p>
+<p>
+ Are the steps correctly numbered?
+</p>
+<p>
+ For each alternate flow is the condition(s) for initiation of the flow clearly defined?
+</p>
+<p>
+ For each alternate flow is it clear how the use case ends or where in the basic flow that the use case resumes?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_dnLXMNk2Edq2Q8qZoWbvGA" name="Are the post-conditions specified?" guid="_dnLXMNk2Edq2Q8qZoWbvGA">
+ <sectionDescription><p>
+ If "Minimal Guarantees" are present, do they always happen when the use case completes, regardless of success? (A
+ Minimal Guarantee represents&nbsp;a condition&nbsp;that will be true when the use case ends, regardless of how it
+ terminates.)
+</p>
+<p>
+ If "Success Guarantees" are present, do they always happen when the use case completes successfully? (A Success
+ Guarantee represents a condition that will be true when the use case ends successfully, regardless of which path it
+ takes.)
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_vkbMAJzrEduBcbjYtLtItQ" name="Are applicable non-functional requirements captured?" guid="_vkbMAJzrEduBcbjYtLtItQ">
+ <sectionDescription><p>
+ Are non-functional requirements (such as performance criteria) that are&nbsp;applicable to the&nbsp;use case captured
+ in the use case?
+</p>
+<p>
+ Are these non-functional requirements applicable to many use cases?&nbsp; It they are, consider capturing them in the
+ supporting requirements specification to simplify maintenance.
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/vision.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/vision.xmi
new file mode 100644
index 0000000..fe57d55
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/checklists/vision.xmi
@@ -0,0 +1,48 @@
+<?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" epf:version="1.0.0" xmi:id="_qktWQMM0EdmSIPI87WLu3g" name="vision,_0WoFUMlgEdmt3adZL5Dmdw" guid="_qktWQMM0EdmSIPI87WLu3g" changeDate="2005-07-07T16:30:32.042-0400" version="1.0.0">
+ <sections xmi:id="_VwoioAeiEduWycDgioo5rg" name="Have you fully explored what the problem behind the problem is?" guid="_VwoioAeiEduWycDgioo5rg">
+ <sectionDescription><p>
+ Make sure that you have found the root cause of the Stakeholder's problem or need. Often, Stakeholders define solutions
+ rather than stating the problem that they are experiencing or the pain they are experiencing. Subsequently, they may
+ not have identified the problem correctly or the correct solution for it.
+</p>
+<p>
+ For example, "We can't support customers who want to buy online" is better than "We need an on-line purchasing system".
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_dBs8gAeiEduWycDgioo5rg" name="Is the problem statement correctly formulated?" guid="_dBs8gAeiEduWycDgioo5rg">
+ <sectionDescription>Make sure that you have agreement on the problem to be solved.</sectionDescription>
+ </sections>
+ <sections xmi:id="_jGUxYAeiEduWycDgioo5rg" name="Is the list of Stakeholders complete and correct?" guid="_jGUxYAeiEduWycDgioo5rg">
+ <sectionDescription>Make sure you didn't miss any Stakeholders. If you did, you probably do not yet have all of the perspectives that you need
+to consider.</sectionDescription>
+ </sections>
+ <sections xmi:id="_s-be8AeiEduWycDgioo5rg" name="Does everyone agree on the definition of the system boundaries?" guid="_s-be8AeiEduWycDgioo5rg">
+ <sectionDescription>Define what is <strong>in</strong> and what is <strong>out</strong> of system boundaries. This is a critical step in
+defining the scope of work.</sectionDescription>
+ </sections>
+ <sections xmi:id="_z1uG4AeiEduWycDgioo5rg" name="Have you sufficiently explored constraints to put on the system?" guid="_z1uG4AeiEduWycDgioo5rg">
+ <sectionDescription>Don't forget about the non-functional requirements and constraints. These are often the largest cost of development.</sectionDescription>
+ </sections>
+ <sections xmi:id="_7KzeEAeiEduWycDgioo5rg" name="Have you covered all kinds of constraints, including political, economic, and environmental?" guid="_7KzeEAeiEduWycDgioo5rg">
+ <sectionDescription><p>
+ These non-technical constraints often lead to problems later.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_DymaUAejEduWycDgioo5rg" name="Have all key features of the system been identified and defined?" guid="_DymaUAejEduWycDgioo5rg">
+ <sectionDescription>Do a completeness check, comparing the features with the problem statement, to make sure that you didn't miss a critical
+feature.</sectionDescription>
+ </sections>
+ <sections xmi:id="_LRX5AAejEduWycDgioo5rg" name="Will the features solve the problems that are identified?" guid="_LRX5AAejEduWycDgioo5rg">
+ <sectionDescription>Are all the features really necessary?&nbsp; Perhaps you can reduce the scope.</sectionDescription>
+ </sections>
+ <sections xmi:id="_UGRdIAejEduWycDgioo5rg" name="Are the features consistent with constraints that you've identified?" guid="_UGRdIAejEduWycDgioo5rg">
+ <sectionDescription><p>
+ Check that conflicting requirements do not exist. If you find conflicts, resolve them now.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_5y4uAAhUEduRe8TeoBmuGg" name="Can someone who is not familiar with the project understand what you hope the project will achieve by reading the Vision document?" guid="_5y4uAAhUEduRe8TeoBmuGg">
+ <sectionDescription>The purpose of the Vision document is to describe the objectives of the project in terms that non-technical people, who are
+not closely involved with the project, can understand.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/actor.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/actor.xmi
new file mode 100644
index 0000000..7226c65
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/actor.xmi
@@ -0,0 +1,53 @@
+<?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" epf:version="1.0.0" xmi:id="-aN0zy068ovKHgmkkoYqoYQ" name=",_zGqO0MDpEduTGJ8i4u8TMw" guid="-aN0zy068ovKHgmkkoYqoYQ" changeDate="2007-02-20T08:56:57.450-0500">
+ <mainDescription><p>
+ To fully understand the system's purpose, you must know who the system is for, that is: Who will use the system? The
+ answer to this question is: the Actors.
+</p>
+<p>
+ An Actor is a role that a person or external system plays&nbsp;when interacting with the system.&nbsp; Instances of an
+ Actor can be an individual or an external system, however each Actor&nbsp;provides a
+ unique&nbsp;and&nbsp;important&nbsp;perspective on the system that is shared by every instance of the Actor.
+</p>
+<p>
+ This difference between an actor and an instance of an actor is illustrated below.&nbsp;&nbsp;Figure 1 shows a case in
+ which Ivar and Mark are operators of a recycling machine. When they are using the machine in this capacity, each is
+ represented by an instance of the actor called Operator that expects certain functionality of the system (Print Daily
+ Reports in this example).
+</p>
+<p>
+ <img height="322" alt="" src="./resources/md_acto2.gif" width="396" />&nbsp;
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <strong>Figure 1:&nbsp;Example Actor with multiple instances</strong>&nbsp;
+ </p>
+</blockquote>
+<p>
+ Conversely, the same user can act as several actors (that is, the same person can take on different roles). In Figure
+ 2, Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the Depot-Handling
+ System as an ordinary Depot Staff member. Each of these actors expects different functionality of the system.
+</p>
+<p>
+ <img height="139" alt="" src="./resources/md_acto3.gif" width="367" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <strong>Figure 2: Example of user playing different roles</strong><br />
+ </p>
+</blockquote>
+<p>
+ Actors help you to identify external interfaces and to determine the scope the system (what is in the system, vs. what
+ is outside the system boundary).&nbsp; Each&nbsp;Actor has associated use cases which describe what that
+ particular&nbsp;actor expects of the system.&nbsp; It will be very difficult, if not impossible,&nbsp;to assess the
+ completeness of the set of Use Cases without the context provided by the associated Actors. Furthermore, missing an
+ actor may result in&nbsp;missing important stakeholder perspectives, resulting&nbsp;in a solution that does not meet
+ all&nbsp;stakeholder needs.
+</p>
+<p>
+ Hence, identifying the Actors for the system&nbsp;should be done early in the lifecycle.&nbsp;&nbsp;Actors are
+ captured, including their names, brief descriptions, and relationships to use cases,&nbsp;in the <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/uc_model,_W2SgEDR5EdutE_HNDTJk5Q.html"
+ guid="_W2SgEDR5EdutE_HNDTJk5Q">Artifact: Use-Case Model</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/analysis_mechanism.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/analysis_mechanism.xmi
new file mode 100644
index 0000000..2abecc4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/analysis_mechanism.xmi
@@ -0,0 +1,74 @@
+<?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" epf:version="1.0.0" xmi:id="_S8KCcMP2EdmWKcx6ixEiwg" name="analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw" guid="_S8KCcMP2EdmWKcx6ixEiwg" changeDate="2007-02-26T13:44:38.859+0000" version="1.0.0">
+ <mainDescription><p>
+ An Analysis Mechanism is a conceptual representation of an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. Over time, Analysis Mechanisms are refined into <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s&nbsp;and, later, into <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/implementation_mechanism,_0LcUkA4LEduibvKwrGxWxA.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>s.
+</p>
+<p>
+ Analysis Mechanisms&nbsp;allow the developer to focus on understanding the requirements without getting distracted by
+ the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people
+ can better comprehend the problem.
+</p>
+<p>
+ Analysis Mechanisms are described in simple terms:
+</p>
+<ul>
+ <li>
+ <strong>Name:</strong> Identifies the mechanism.
+ </li>
+ <li>
+ <strong>Basic attributes:</strong> Define the requirements of the mechanism.
+ </li>
+</ul>
+<p>
+ You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as
+ you proceed.
+</p>
+<p>
+ In the top-down mode, experience guides the <a class="elementLink"
+ href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a>, who knows that certain problems are present in the domain and will
+ require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms
+ during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The
+ common aspect of all of these is that each is a general capability of a broad class of systems, and each provides
+ functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support
+ capabilities required in the basic functional requirements of the system, regardless of the platform that it is
+ deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different
+ ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may
+ also be more than one way of implementing each design mechanism.
+</p>
+<p>
+ The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the <a
+ class="elementLink" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> sees, perhaps faintly at first, a common theme emerging from a set of
+ solutions to various problems. For example: There is a need to provide a way for elements in different threads to
+ synchronize their clocks, and there is a need for a common way of allocating resources. <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>, which simplify the language of analysis, emerge from these
+ patterns.
+</p>
+<p>
+ Identifying an Analysis Mechanism means that you identify a common, perhaps implicit&nbsp;subproblem, and you give it a
+ name. Initially, the name might be all that exists. For example, the system will require a persistence
+ mechanism.&nbsp;Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
+ which do not deliver application functionality directly, but exist only to support it. Very often these support classes
+ are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
+ application-level classes.
+</p>
+<p>
+ If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be
+ instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis
+ Mechanism produced this way will be abstract, and it will require further refinement throughout design and
+ implementation work.
+</p>
+<p>
+ You can see examples of how Architectural Mechanisms can be represented in <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/example_analysis_mechanisms_descr,_4k_HsA4LEduibvKwrGxWxA.html"
+ guid="_4k_HsA4LEduibvKwrGxWxA">Example Analysis Mechanism Descriptions</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/arch_mech.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/arch_mech.xmi
new file mode 100644
index 0000000..17a9f77
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/arch_mech.xmi
@@ -0,0 +1,105 @@
+<?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" epf:version="1.0.0" xmi:id="-SJrpVySJ2npYs8NwGvnHjw" name="arch_mech,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson" changeDate="2007-02-26T13:36:32.171+0000" changeDescription="Simplified text explaining mechanism concept" version="1.0.0">
+ <mainDescription><p>
+ Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements.&nbsp;When fully described,
+ Architectural Mechanisms show patterns of structure and behavior in the software. They&nbsp;form the basis
+ of&nbsp;common software&nbsp;that will be&nbsp;consistently applied&nbsp;across the product being developed. They also
+ form the basis for standardizing the way that the software works; therefore, they are an important element of the
+ overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing
+ software components can be leveraged to provide the required behaviour; or whether new software should be bought or
+ built.
+</p>
+<p>
+ The key point to take on board when discussing architecture mechanisms is that the defining them is all about making
+ choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about
+ producing detailed design or software. This is a common misunderstanding. The creation of detailed design
+ and&nbsp;software that&nbsp;shows&nbsp;*how* specific mechanisms&nbsp;are satisfied&nbsp;is&nbsp;a development task.
+</p>
+<p>
+ The value in defining architecture mechanisms is that it
+</p>
+<ol>
+ <li>
+ explicitly calls out&nbsp;aspects of the solution mechanics that are common across the system. This aids planning.
+ </li>
+ <li>
+ puts down markers for the developers to build those aspects of the system once and then re-use them. This reduces
+ the workload.
+ </li>
+ <li>
+ promotes the development of a consistent set of services. This makes the system easier to maintain.
+ </li>
+</ol>
+<p>
+ An&nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&nbsp;These
+ categories&nbsp;reflect the state of the architectural mechanism over time. The state changes as successive levels of
+ detail are uncovered during the refinement of architecturally significant requirements into working software. The
+ categories are summarized in the table that follows.
+</p>
+<strong>States of an Architectural Mechanism</strong>
+<table style="WIDTH: 806px; HEIGHT: 228px" cellspacing="0" cellpadding="2" width="806"
+summary="Types of Architectural Mechanism" border="1">
+ <tbody valign="top">
+ <tr>
+ <th scope="col">
+ State
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Analysis
+ </td>
+ <td>
+ A conceptual solution to a common technical problem. For example,&nbsp;persistence is an abstract solution
+ to the common requirement to store data. The purpose of this category is simply to identify the need for an
+ Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Design
+ </td>
+ <td>
+ A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this
+ category is to enable initial design specifications to be produced and to guide precise product or
+ technology selection.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Implementation
+ </td>
+ <td>
+ <p>
+ A further refinement of a Design Mechanism into a&nbsp;specific technology or product that implements
+ the required Architectural Mechanism. For example, MySQL, as a database product, implements the
+ Analysis Mechanism <strong>Persistence</strong> and Design Mechanism <strong>RDBMS.</strong>
+ </p>
+ <p>
+ This essentially represents the point at which the decision is made to re-use, buy or build specific
+ software to provide the services defined by the mechanism.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<p>
+ Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
+ mechanisms.&nbsp;These are synonyms and merely represent the architecture mechanisms in different states of
+ development. The transition from one state to another&nbsp;can often be obvious or intuitive. Therefore, it can be
+ achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The
+ following diagram illustrates the transition of Architectural Mechanisms from one state to another.
+</p>
+<p>
+ <strong>State Machine for Architectural Mechanisms</strong>
+</p>
+<p>
+ <img style="WIDTH: 876px; HEIGHT: 115px" height="113" alt="Architectural Mechanism States"
+ src="./resources/ArchMechanismsStatemachine.JPG" width="600" />&nbsp;<br />
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/architecturally_significant_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/architecturally_significant_requirements.xmi
new file mode 100644
index 0000000..d50e0fd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/architecturally_significant_requirements.xmi
@@ -0,0 +1,22 @@
+<?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="-EytH4BCNGiHF6pZrp8ISCw" name="new_concept,_eFElAOK2EdqHEo0wLIc5jg" guid="-EytH4BCNGiHF6pZrp8ISCw" authors="Mark Dickson" changeDate="2006-07-07T04:53:04.786-0700" changeDescription="First Draft" version="1.0">
+ <mainDescription><p> Not all requirements have equal significance in the architecture.&nbsp;Some
+ play an important role in determining the architecture of the
+ system, but others do not. </p>
+<p> Deciding whether a specific requirement is architecturally significant is
+ often a matter of judgment. Typically, these are requirements that are
+ technically challenging, technically constraining, or central to the
+ system's purpose. </p>
+<p> These are good examples of Architecturally Significant Requirements:</p>
+
+<ul>
+ <li> The system must record every modification to customer records for audit
+ purposes.</li>
+ <li> The system must respond within 5 seconds.</li>
+ <li> The system must&nbsp;deploy on Microsoft Windows XP and Linux. </li>
+ <li> The system must encrypt all network traffic.</li>
+ <li> The ATM system must dispense cash on&nbsp;demand&nbsp;to validated account
+ holders with sufficient cleared funds.</li>
+</ul>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/business_pattern.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/business_pattern.xmi
new file mode 100644
index 0000000..05323f8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/business_pattern.xmi
@@ -0,0 +1,22 @@
+<?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="-Of51hmgdsO_U2-pnbJ67Cg" name="new_concept,_RoSdMBWYEduCK502eDgjUQ" guid="-Of51hmgdsO_U2-pnbJ67Cg" changeDate="2006-07-21T11:59:56.413-0700">
+ <mainDescription><p> Business Patterns are a form of Design Pattern&nbsp;(see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>) and are the business-domain
+ counterpart of <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/architecture_mechanism,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>. Just as
+ similar problems in the technical domain may be solved by using Architecture
+ Mechanisms, similar problems in the business domain can be solved by using Business
+ Patterns. </p>
+<p> Business Patterns are often found in COTS products. For example, packaged
+ applications that support Enterprise Resource Planning or Customer Relationship
+ Management ship with functionality to support a variety of generic business
+ processes. Similarly, it is frequently possible to identify related or similar
+ behavior in the Use Case&nbsp;Scenarios&nbsp;and thereby derive generic designs
+ that you can use in the design of the system. These elements of generic behavior
+ can be&nbsp;expressed as Design&nbsp;Patterns and applied to the system design.
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/change_requests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/change_requests.xmi
new file mode 100644
index 0000000..7185661
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/change_requests.xmi
@@ -0,0 +1,15 @@
+<?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" epf:version="1.0.0" xmi:id="-BsXK3ZGMm-mUT0KnkdoYBg" name="change_requests,_6jdvECb3Edqh1LYUOGRh2A" guid="-BsXK3ZGMm-mUT0KnkdoYBg" changeDate="2007-02-22T15:13:54.919-0500">
+ <mainDescription><p>
+ A change request represents any request to change a work product. This includes items commonly called defect reports,
+ enhancement requests, requirements change request, implementation requests, and stakeholder requests.
+</p>
+<p>
+ In this process, change request are captured in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/work_items_list,_7vEXEMA4EdqSgKaj2SZBmg.html"
+ guid="_7vEXEMA4EdqSgKaj2SZBmg">Guideline: Work Items List</a>&nbsp;for more information on the recommended
+ attributes&nbsp;of change requests.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/coding_standard.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/coding_standard.xmi
new file mode 100644
index 0000000..37fa9f7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/coding_standard.xmi
@@ -0,0 +1,25 @@
+<?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" epf:version="1.0.0" xmi:id="-vlYpfwIYlF_ZCk5s4Dsqdg" name="new_concept,_0lnRMMqOEduwrYVlQ9zp3w" guid="-vlYpfwIYlF_ZCk5s4Dsqdg" changeDate="2007-03-04T15:29:08.886-0500">
+ <mainDescription><p>
+ Using a coding standard is a software development practice that has been widely accepted in the industry. The need for
+ this practice takes on added importance in&nbsp;a highly collaborative environment. The team should have a standard way
+ of naming and formatting things so they can understand the code quickly and know where to look at all times.
+</p>
+<p>
+ Ideally, the coding standard should be the result of team consensus. In some cases, decisions will be arbitrary (like
+ how much to indent). Each item in the standard should support one or more goals, improved communication being one of
+ the most critical goals. Once the team agrees on a standard, all members of the teams are expected to follow it. With
+ time, the team will use and modify the standard to develop a style that is well adapted to their environment.
+</p>
+<p>
+ Benefits
+</p>
+<ul>
+ <li>
+ Improved communication: increases the ability to read each other's code.
+ </li>
+ <li>
+ Refactoring support: provides consistently shaped code.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/component.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/component.xmi
new file mode 100644
index 0000000..767b163
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/component.xmi
@@ -0,0 +1,99 @@
+<?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" epf:version="1.0.0" xmi:id="_TZiasMM1EdmSIPI87WLu3g" name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2007-01-23T11:49:37.968+0000" version="1.0.0">
+ <mainDescription><p align="left">
+ The software industry and literature use the term <strong>componen</strong>t to refer to many different things. It is
+ often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote
+ specific characteristics that enable replacement and assembly in larger systems.
+</p>
+<p align="left">
+ Here. we use <em>component</em> to mean <strong>an encapsulated part of a system</strong> that is, ideally, a
+ nontrivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of
+ well-defined architecture. This includes two types of components:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Design component.</strong> A significant encapsulated part of the design that includes design
+ subsystems and, sometimes, significant design classes and design packages.
+ </p>
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Implementation component.</strong> A significant encapsulated part of the implementation, generally
+ code that implements a design component.
+ </p>
+ </div>
+ </li>
+</ul>
+<p align="left">
+ Ideally, the design reflects the implementation; therefore, you can simply refer to <em>components</em>, with each
+ component having a design and an implementation.
+</p>
+<h4 align="left">
+ Component replaceability
+</h4>
+<p align="left">
+ In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
+ interfaces that hide an underlying implementation.
+</p>
+<p align="left">
+ There are other, stronger, kinds of replaceability: .
+</p>
+<div align="left">
+ <ul>
+ <li>
+ <p>
+ <strong>Source file replaceability:</strong> If two classes are implemented in a single source code file,
+ then those classes cannot usually be separately versioned and controlled. However, if a set of files fully
+ implements a single component (and no other component), then the component source files are replaceable.
+ This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
+ source file.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Deployment replaceability:</strong> If two classes are deployed in a single executable file, then
+ each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
+ components to be replaceable during deployment, which allows new versions of the component to be deployed
+ without having to rebuild the other components. This usually means that there is one file or one set of
+ files that deploy the component, and no other component.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Run-time replaceability:</strong> If a component can be redeployed into a running system, then it
+ is referred to as <em>run-time replaceable</em>. This enables you to upgrade software without loss of
+ availability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Location transparency:</strong> Components with network-addressable interfaces are referred to as
+ having <em>location transparency</em>. This allows components to be relocated to other servers or to be
+ replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of
+ components are often referred to as <em>distributed</em> or <em>distributable</em> components.
+ </p>
+ </li>
+ </ul>
+</div>
+<h4 align="left">
+ Component instantiation
+</h4>
+<p align="left">
+ A component may or may not be directly instantiated at run time.
+</p>
+<p align="left">
+ An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
+ component itself does not appear in the implementation; it merely serves as a design that an implementation must
+ follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
+ provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
+</p>
+<p align="left">
+ A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
+ object, which means that a design component has a corresponding construct in the implementation language; therefore, it
+ can be referenced explicitly.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/component_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/component_vm.xmi
new file mode 100644
index 0000000..250a29a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/component_vm.xmi
@@ -0,0 +1,119 @@
+<?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" epf:version="1.0.0" xmi:id="-zfl87vJBFdinDB02ArLXOQ" name="new_concept,_HZGFsKrPEdu6T6WyNqBzqQ" guid="-zfl87vJBFdinDB02ArLXOQ" changeDate="2007-01-23T11:48:34.453+0000">
+ <mainDescription><p align="left">
+ The Unified Modeling Language [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">UML05</a>] defines <em>component</em> as follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p>
+ A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment. A component defines its behavior in terms of provided and required interfaces. As such, a
+ component serves as a type, whose conformance is defined by these provided and required interfaces
+ (encompassing both their static as well as dynamic semantics). (See <strong>UML representation</strong> at the
+ end of this section for definitions from earlier versions of UML.)
+ </p>
+ <p>
+ A <em>component</em> is defined as a subtype of structured class. Therefore, a component has attributes and
+ operations, is able to participate in associations and generalizations, and has internal structure and ports.
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ A number of UML standard stereotypes exist that apply to components, including &lt;&lt;subsystem&gt;&gt; to model
+ large-scale components, and &lt;&lt;specification&gt;&gt; and &lt;&lt;realization&gt;&gt; to model components with
+ distinct specification and realization definitions, where one specification may have multiple realizations.
+</p>
+<p align="left">
+ Here, we use&nbsp;the term <em>component&nbsp;</em>in a&nbsp;broader way than the UML definition. Rather than defining
+ components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
+ as desirable characteristics of components. See the section on Component Replaceability.
+</p>
+<h4 align="left">
+ Modeling of components
+</h4>
+<p align="left">
+ The UML component is a modeling construct that provides the following capabilities:
+</p>
+<div align="left">
+ <ul>
+ <li>
+ Group classes to define a larger granularity part of a system
+ </li>
+ <li>
+ Separate the visible interfaces from internal implementation
+ </li>
+ <li>
+ Execute instances run-time
+ </li>
+ </ul>
+</div>
+<p align="left">
+ A component includes <strong>provided</strong> and <strong>required</strong> interfaces that form the basis for wiring
+ components together. A <strong>provided interface</strong> is one that is either implemented directly by the component
+ or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A
+ <strong>required interface</strong> is designated by a usage dependency of the component or one of its realizing
+ classes or subcomponents, or it is the type of a required port.
+</p>
+<p align="left">
+ A component has an external view (or <em>black box</em> view) through its publicly visible properties and operations
+ .Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component
+ itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls
+ explicit. The wiring between components in a system or other context can be structurally defined by using dependencies
+ between component interfaces (typically on component diagrams).
+</p>
+<p align="left">
+ Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in
+ composite structures to specify the role or instance-level collaboration between components. That is the component's
+ internal view (or <em>white-box</em> view) through its private properties and realizing classes or subcomponents. This
+ view shows how the external behavior is realized internally. The mapping between external and internal views is by
+ dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.
+</p>
+<p align="left">
+ The recommendation is to&nbsp;use components as the representation for design subsystems.
+</p>
+<h4 align="left">
+ UML representation
+</h4>
+<p align="left">
+ The definition of <em>component</em> with the UML has changed over time with the release of different versions. The
+ version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the
+ definitions from 1.3 to 2.0 are provided here.
+</p>
+<p align="left">
+ UML 2.0 defined <em>component</em> as the following:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p align="left">
+ ...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment.
+ </p>
+ <p align="left">
+ A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a
+ type whose conformance is defined by these provided and required interfaces (encompassing both their static as
+ well as dynamic semantics).
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ UML 1.5 defined <em>component</em> as the following:
+</p>
+<blockquote>
+ <blockquote>
+ <div align="left">
+ A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of
+ interfaces. A component is typically specified by one or more classes or subcomponents that reside on it and
+ may be implemented by one or more artifacts (e.g., binary, executable, or script files).
+ </div>
+ <div align="left">
+ <p>
+ In UML 1.3 and earlier versions of the UML, the component notation was used to represent files in the
+ implementation. Files are no longer considered components by the latest UML definitions. However, many
+ tools and UML profiles still use the component notation to represent files.
+ </p>
+ </div>
+ </blockquote>
+</blockquote></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/construction_phase.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/construction_phase.xmi
new file mode 100644
index 0000000..931d9cc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/construction_phase.xmi
@@ -0,0 +1,89 @@
+<?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" epf:version="1.0.0" xmi:id="-bbpT_BdDRrv6waNI365Qhg" name=",_48EKsBOMEduCNqgZdt_OaA" guid="-bbpT_BdDRrv6waNI365Qhg" changeDate="2006-09-29T13:10:26.950-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose in this phase is to complete the development of the system based upon the baselined architecture.
+</p>
+<p>
+ There are objectives for the Construction phase that help us to&nbsp;have cost-efficient development of a complete
+ product - an operational version of your system - that can be deployed&nbsp;in the user community&nbsp;<a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ Iteratively develop a complete product that is ready to transition to its user community. Describe remaining
+ requirements, fill in design details, complete the implementation and test the software. Release the first
+ operational version (beta) of the system and determine if users are ready for the application to be deployed.
+ </li>
+ <li>
+ Minimize development costs and achieve some degree of parallelism. Optimize resources and leverage development
+ parallelism between developers or teams of developers, by for example, assigning components that can be developed
+ independently of one another.
+ </li>
+</ol>
+<p>
+ The following table summarizes the&nbsp;Construction phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <br />
+ <strong>Construction phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Iteratively develop a complete product that is ready to transition to the user community<br />
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/manage_requirements,_eE5nEUbpEduLBN1xMBngqw.html" guid="_eE5nEUbpEduLBN1xMBngqw">Manage Requirements</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/develop_solution,_MWFjoU9HEdudU75l2xOQTw.html" guid="_MWFjoU9HEdudU75l2xOQTw">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/validate_build,_y-3IretQEdqc1LGhiSPqRg.html" guid="_y-3IretQEdqc1LGhiSPqRg">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Minimize development costs and achieve some degree of parallelism<br />
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/develop_solution,_MWFjoU9HEdudU75l2xOQTw.html" guid="_MWFjoU9HEdudU75l2xOQTw">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/capabilitypatterns/validate_build,_y-3IretQEdqc1LGhiSPqRg.html" guid="_y-3IretQEdqc1LGhiSPqRg">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of
+ projects:
+</p>
+<ul>
+ <li>
+ Simple project: One iteration to build the product (to a beta release)
+ </li>
+ <li>
+ More substantial project: One iteration to expose a partial system and one to mature it to beta testing
+ </li>
+ <li>
+ Large project: Three or more iterations, given the size of the project (number of requirements to implement for a
+ beta release)
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/continuous_integration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/continuous_integration.xmi
new file mode 100644
index 0000000..5415cc9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/continuous_integration.xmi
@@ -0,0 +1,35 @@
+<?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="-dhAMzNZNWufBnW0fPYQtBA" name="continuous_integration,_NApSVdtxEdq7ovUqqSoGBQ" guid="-dhAMzNZNWufBnW0fPYQtBA" changeDate="2006-08-21T14:39:56.533-0400">
+ <mainDescription><p>
+ Continuous integration is an implementation practice where team members compile and test (integrate) their work
+ frequently (at least daily). Integration errors should be detected as quickly as possible, either from compiler errors
+ or errors reported by&nbsp;the test suite. Ideally the integration is done automatically when an updated version of
+ source code is checked into&nbsp;the configuration management system.
+</p>
+<p>
+ Benefits:
+</p>
+<ol>
+ <li>
+ Improved error detection.&nbsp; Continuous integration enables you to detect and address errors early, often
+ minutes after they’ve been injected into the product.&nbsp; Note that you still need a good test suite.
+ </li>
+ <li>
+ Improved system integration.&nbsp; By integrating continuously throughout your project you know that you can
+ actually build it, thereby mitigating integration surprises at the end of the lifecycle.
+ </li>
+ <li>
+ Reduced technical risk.&nbsp; You always have an up-to-date system against which to test.
+ </li>
+ <li>
+ Reduced management risk.&nbsp; By continuously integrating your system you know exactly how much functionality that
+ you’ve built to date, improving your ability to predict when and if you’re actually going to be able to deliver the
+ necessary functionality.
+ </li>
+ <li>
+ Improved collaboration.&nbsp; Continuous integration enables team members to work together safely.&nbsp; They know
+ that they can make a change to their code, integrate the system, and determine very quickly whether or not their
+ change worked.<br />
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_balance.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_balance.xmi
new file mode 100644
index 0000000..34eab13
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_balance.xmi
@@ -0,0 +1,152 @@
+<?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" epf:version="1.0.0" xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" name="core_principle_balance,_ssG6MMvpEdqukPpotm3DYg" guid="-I4IbR1GW6IFBCdq9SiMUsw" changeDate="2006-09-27T16:34:53.658-0700" changeDescription="Removed metaphoric photo Removed open_up from page name." version="0.02">
+ <mainDescription><h3 style="MARGIN: 12pt 0in 3pt">
+ Introduction
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ Systems are rarely all things to all people. Often, attempts to make them so are wasteful and result in bloated
+ systems.
+</p>
+<p>
+ Therefore, project participants and stakeholders must collaborate to develop a solution that maximizes stakeholder
+ benefits and complies with constraints placed on the project. Achieving balance is a dynamic process because as both
+ the stakeholders and project participants learn more about the system, their priorities and constraints change.
+</p>
+<p>
+ To be successful, stakeholders and the project participants must converge on a clear understanding and agreement of
+ these three factors:
+</p>
+<ul>
+ <li>
+ Problem to be solved
+ </li>
+ <li>
+ Constraints places on the development team (cost, schedule, resources, regulations)
+ </li>
+ <li>
+ Constraints placed on the solution
+ </li>
+</ul>
+<p>
+ Collectively, these three items represent the requirements for the development of the system. The challenge for all
+ project participants is creating a solution that maximizes value delivered to the stakeholders, subject to the
+ constraints. Balance is about making the critical cost-benefit trade-offs between desired features and the subsequent
+ design decisions that define the a<span>rchitecture of the system.</span>
+</p>
+<p>
+ Discovering the balance point is challenging, elusive, and ongoing, because the balance point is dynamic. As the system
+ evolves, stakeholder needs change, new opportunities appear, risks are resolved, new risks appear, and the development
+ team discovers new realities about the system. Change happens throughout the development cycle. Therefore, stakeholders
+ and developers must be prepared to re-evaluate commitments, reset expectations, and adjust plans accordingly as the
+ system evolves.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Know your audience
+</h4>
+<p>
+ You cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want.
+</p>
+<p>
+ Therefore, know your stakeholders. Better yet, work closely with them to ensure that you know their needs. Start by
+ identifying all stakeholders, and then maintain open and frequent communication and collaboration between them and the
+ development team.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Separate the problem from the solution
+</h4>
+<p>
+ Too often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve
+ problems, not how to define problems, so that's easier. However, this limits our understanding of the problem, imposes
+ artificial constraints,&nbsp;and makes it difficult to balance trade-offs, or to even know what the trade-offs are.
+</p>
+<p>
+ Therefore, make sure that you understand the problem before you define the solution. By clearly separating the problem
+ (what the customer needs) from the solution (what the system must do), it is easier to maintain the proper focus and
+ easier to accommodate alternate ways of solving the problem.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Create a shared understanding of the domain
+</h4>
+<p>
+ Domain experts often have limited technical expertise; developers, architects and testers often have limited domain
+ expertise; and reviewers and other stakeholders often have limited time to commit to the project and learn the problem
+ domain. As a result, people often have an inconsistent or poor understanding of the problem domain, which causes
+ communication problems and increases the likelihood of delivering poor value to the stakeholders.
+</p>
+<p>
+ Therefore, enhance and share all parties’ understandings of the domain. A concise and shared understanding of the
+ problem domain enhances communication and project effectiveness. Start by defining the problem in the Vision document.
+ As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent
+ shared use of the language of the domain.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Use scenarios and use cases to capture requirements
+</h4>
+<p>
+ Many companies still document requirements as a list of declarative statements, which are sometimes called the ”shall
+ statements.” These lists are often difficult for stakeholders to understand, because they require the end user to read
+ through and mentally translate the list into a visualization of how the requirements will interact with the system. .
+</p>
+<p>
+ Therefore, use scenarios and use cases to capture functional requirements in a form that is easy for stakeholders to
+ understand. Nonfunctional requirements, such as performance, stability, or usability requirements, are important and
+ can be documented in the Supporting Requirements, using traditional techniques.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Establish and maintain agreement on priorities
+</h4>
+<p>
+ Making poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that are
+ never used, or identifying problems late in the project that result in delays and even project failure.
+</p>
+<p>
+ Therefore, prioritize requirements for implementation by regularly working with the stakeholders during product
+ evolution. Make choices that deliver value and reduce risks, while building a system that can evolve.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Make the trade-offs to maximize value
+</h4>
+<p>
+ Cost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the
+ system to the stakeholder, while architecture establishes the cost. The cost of a benefit may influence the
+ stakeholder's perceived value of the benefit.
+</p>
+<p>
+ Therefore, work with the stakeholders and developers to prioritize requirements and develop candidate architectures to
+ implement those solutions. Use the candidate architectures to evaluate the cost of the benefits. Candidate solutions
+ are considered at a high level when determining architectural feasibility. Different architectural perspectives can
+ result in different assessment of cost versus benefit. The&nbsp;candidate architecture&nbsp;that provides the most
+ coverage at the lowest cost is selected for further development.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Manage scope
+</h4>
+<p>
+ Change is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change will
+ result in a bloated, deficient system and unmet stakeholder needs.
+</p>
+<p>
+ Therefore, manage change while maintaining the agreements with the stakeholders. Modern processes always manage change,
+ continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making
+ trade-offs, and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned throughout
+ the development lifecycle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Know when to stop
+</h4>
+<p>
+ Over-engineering a system not only wastes resources but also leads to an overly complex system.
+</p>
+<p>
+ Therefore, stop developing the system when the desired quality is achieved. Remember that “Quality is conformance to
+ the requirements” <a href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[CRO79]</a>. This is what gives a sense of closure to the practice. Separate the problem
+ from the solution, ensuring that the solution does, indeed, solve the problem. After the critical requirements are
+ implemented and validated, the system is ready for stakeholder acceptance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_collaborate.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_collaborate.xmi
new file mode 100644
index 0000000..1432696
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_collaborate.xmi
@@ -0,0 +1,142 @@
+<?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" epf:version="1.0.0" xmi:id="-IXfkG-XfnoEo0xgux482Kw" name="core_principle_collaborate,_KkTIsMp7EdqC_NfSivunjA" guid="-IXfkG-XfnoEo0xgux482Kw" authors="Steve Adolph" changeDate="2006-09-27T16:35:17.403-0700" changeDescription="Initial Version |Removed metaphoric photo. Removed "Don't go dark" collaborative practice.|Removed metaphoric photo. Removed "Don't go dark" collaborative practice. Removed open_up from page name.|Added "organize around the architecture practice"" version="0.03">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Software is created by people with different interests and skills who must work together to create software
+ effectively.
+</p>
+<p>
+ Therefore, develop practices that foster a healthy team environment. A healthy team environment enables effective
+ collaboration, which aligns the interests of project participants (development team, quality assurance, product
+ stakeholders, customers) and helps project participants develop a shared understanding of the project.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Maintain a common understanding
+</h4>
+<p>
+ Project participants require a common understanding of a project to cooperate effectively. Otherwise, disorder sets in,
+ because the team members cannot align their understanding and interests and will work with different purposes.
+</p>
+<p>
+ Be proactive communicating and sharing information with project participants and do not assume that everyone will just
+ find what they need to know or that each person has the same understanding of the project as everyone else. Use work
+ products, such as the Vision, Work Items List, and Requirements to align the understanding between the stakeholders and
+ developers. Use the architecture to focus and align the interests of the developers. At the end of each iteration, get
+ agreement on whether the iteration goals have been reached, and, if not, what actions must be taken.
+</p>
+<h4 style="MARGIN: auto 0in">
+ Foster a high-trust environment
+</h4>
+<p>
+ People who do not feel safe will not communicate their ideas, take the initiative, or admit their ignorance. In these
+ low-trust work environments, activities must be laboriously planned in detailed, carefully supervised, and extensively
+ audited. A team working in a low-trust environment may not be able to keep up with rapid change.
+</p>
+<p>
+ Therefore, take actions that foster a high-trust environment:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Manage by intent.</strong> Create an environment where teams manage themselves, and managers serve as
+ mentors to teams to help them complete their objectives.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Tear down the walls.</strong> Work to remove both the physical and mental barriers that inhibit
+ development of a common understanding among project participants.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Walk a mile (or 1.6 kilometers) in someone else's shoes.</strong> Respect and try to understand the
+ perspectives of others before criticizing their ideas or responding to their criticism.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Respond to conversations with relevance.</strong> People, especially technical workers, often respond
+ with argument or disagreement, which leads to rivalry and the establishment of a pecking order in which only a
+ few people contribute to the discussion. Develop and encourage behavior that values curiosity and relevance
+ over argument and disagreement.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Always look to yourself first for the source of communication problems.</strong> Understand that
+ everyone has a perspective that is largely invisible to the individual (although it is often obvious to
+ everyone else). Develop the habit of identifying the assumptions and prejudices within yourself that lead to
+ argument or lack of communication. Learn to overcome these in the moment of the conversation. This takes
+ practice. There are times when others may be intractable, but often the problem can be addressed by wrestling
+ with your own perspective.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand the constraints of the workplace culture.</strong> Some organizations operate in a way that
+ allows people to admit mistakes, ask questions, and experiment. Some organizations limit these expressions, but
+ they may change, with time and effort. Some organizations have no tolerance for error, and workers put
+ themselves in danger by admitting mistakes or experimenting. Understand your environment and protect yourself
+ accordingly. Understand that low-trust organizations have more problems in achieving their goals and provide a
+ less satisfying environment.
+ </p>
+ </li>
+</ul>
+<h4 style="MARGIN: auto 0in">
+ Share responsibility
+</h4>
+<p>
+ There may be disadvantages for individuals when they work alone. Communication with the team can become sporadic, and
+ then stop. People may get into trouble and not ask for help, or not realize that the team is in trouble and needs their
+ help. Their understanding of the project may become misaligned with the rest of the team. In the worse situations,
+ trust breaks down as individuals see the team working at different purposes to their interests.
+</p>
+<p>
+ Therefore, while individuals have primary responsibility for their work products, responsibility for work products is
+ shared. Nothing is someone else's responsibility. This may mean either taking up slack and working with someone who is
+ lagging for some reason or asking for help. Experienced staff should be extra-vigilant and watch over less-experienced
+ staff, encouraging them to ask for help if necessary.
+</p>
+<h4 style="MARGIN: auto 0in">
+ Learn continuously
+</h4>
+<p>
+ Not only is software development a fast-developing field where technical skills rapidly become obsolete, it is also an
+ empirical process, where software is developed in a manner that sometimes resembles trial and error. Furthermore,
+ software is developed by teams of people who must work together to achieve results.
+</p>
+<p>
+ Therefore, continuously develop both your technical and interpersonal skills. Learn from the examples of your
+ colleagues. Take the opportunity to be both a student of your colleagues, as well as a teacher to them. Always increase
+ your personal ability to overcome your own antagonism toward other team members.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt">
+ Organize around the architecture
+</h4>
+<br />
+<p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ As projects grow in size, communication between team members becomes increasingly complex.<span style="mso-spacerun: yes">&nbsp;</span>While all team members understand the overall system, they can focus primarily
+ on the one or more subsystems they are responsible for. Organizing around the architecture also helps with
+ communication by providing the team with a common vocabulary and shared mental model of the system<strong>.</strong>
+ Communication between team members becomes increasingly complex. Therefore, organize the team around the architecture
+ and the vocabulary and shared mental model of the system. However, be watchful that individuals and teams organized
+ this way do not form a so-called <em>silo mentality</em>, where they focus strictly on their subsystems and become
+ ignorant of the other subsystems.
+</p>
+<p>
+ An architecture that reflects the organization’s structure is not evidence that the team has successfully organized
+ around the architecture. If organizations and teams are not organized around the architecture, then the architecture
+ will naturally conform to the organization, as a result of political and cultural influences. In the end, the
+ architecture and the organization will almost always be a reflection of each other. The goal is to guide team
+ organization from the needs of the architecture as much as possible.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_evolve.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_evolve.xmi
new file mode 100644
index 0000000..f24f88c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_evolve.xmi
@@ -0,0 +1,133 @@
+<?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" epf:version="1.0.0" xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" name="core_principle_evolve,_GXiogMvoEdqukPpotm3DYg" guid="-aMD1wQVJLzzlMARfHBdOBQ" changeDate="2006-09-27T16:35:31.654-0700" changeDescription="removed OpenUP from page name." version="0.02">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ It is usually not possible to know all stakeholders' needs, be aware of all project risks, comprehend all project
+ technologies, or know how to work with your colleagues. Even if it were possible to know all of these things, they are
+ likely to change over the life of the project. Therefore, divide the project into short, time-boxed iterations to
+ demonstrate incremental value and to get early and continuous feedback.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p>
+ The intention behind this principle is to continuously get feedback and to improve both the product and the process of
+ the project team. When you provide structure and create a mindset for continuous feedback and improvement, changes are
+ accommodated more easily, feedback is captured early and often, high-priority risks are confronted early in the
+ project. By constantly identifying and attacking risks, there is more confidence in project progress and quality.
+</p>
+<p>
+ Not only does the product evolve, but the team also finds better ways to work together and get involved with
+ stakeholders.<span style="mso-spacerun: yes">&nbsp;</span> The process followed by the team can be adjusted accordingly
+ to leverage lessons learned and adjust project pace and needs.
+</p>
+<h3 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Practices
+</h3>
+<p style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ The next sections describe the practices associated with this principle.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Develop your project in iterations
+</h4>
+<p>
+ Developing a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new
+ knowledge. Worse, it can delay the discovery and mitigation of risks, because development efforts are scheduled later
+ in the lifecycle.
+</p>
+<p>
+ Therefore, divide your project into a series of time-boxed iterations, and plan your project iteratively. This
+ iterative strategy enables you to incrementally deliver capabilities (such as an executable, usable subset of
+ implemented and tested requirements) that can be assessed by stakeholders at the end of each iteration. This provides
+ rapid and timely feedback loops so that issues can be addressed and improvements made at a lower cost. Also, this is
+ accomplished while you still have sufficient budget and time left to do so, and you have not gone so far ahead that
+ major rework is required. Iterative development enables teams to continuously improve software throughout the
+ development <a href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">lifecycle</a>.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Focus iterations on meeting the next management milestone
+</h4>
+<p>
+ Without a focus to bring closure to important project issues, such as stakeholder concurrence regarding scope and
+ proving the proposed architecture, a project can appear to make progress while risks and unresolved issues pile up.
+</p>
+<p>
+ Therefore, divide the project into phases (such as Inception, Elaboration, Construction, and Transition), with each
+ phase having a clearly visible management milestone. The focus of each iteration within a phase is on achieving that
+ milestone. <span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Manage risks
+</h4>
+<p>
+ Deferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such
+ procrastination may lead to investing in the wrong technologies, a bad design, or a set of requirements that may not
+ address stakeholder needs.
+</p>
+<p>
+ Therefore, attack <a href="./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a> early, or they will attack you. Continuously identify and prioritize risks,
+ and then devise strategies to mitigate them. Determine the focus of iterations based on risks. For example,
+ architecturally significant risks should be addressed early in the project, no later than the end of Elaboration phase,
+ when the architecture has been proven and baselined.
+</p>
+<p>
+ At the beginning of each iteration, the entire team should consider what risks they are facing, and update the risk
+ list. Make it each team member’s and stakeholder’s responsibility to have the courage to speak up and openly discuss
+ risks, as well as to have the courage not to criticize the people who do speak up, even though the risk may point to a
+ flaw in their area of responsibility. For each risk, articulate a plan for tracking and mitigating the risk.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Embrace and manage change
+</h4>
+<p>
+ Change is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will
+ result in a bloated, deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a
+ change is made, the more the change is likely to cost.
+</p>
+<p>
+ Therefore, both embrace and manage change. Embracing change helps you to build a system that addresses stakeholder
+ needs, and managing change allows you to reduce costs and improve predictability of those changes. Changes made early
+ in the project can usually be made with limited cost. As you progress in your project, changes can become increasingly
+ costly.
+</p>
+<p>
+ To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware
+ of the impact that those changes have on the project cost and schedule. Understand the impact of a change in the
+ current phase, and isolate team members from disruptive changes during the current iteration. Change requests are
+ reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration.
+</p>
+<p>
+ If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Measure progress objectively
+</h4>
+<p>
+ If you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding.
+ Uncertainty and change make a software project’s progress difficult to measure objectively, and people have a most
+ amazing ability to believe all is well in the face of catastrophe.
+</p>
+<p>
+ Therefore, get a clear picture of project status by objectively measuring progress. The best measure of progress is the
+ delivery of working software, which is something that you do by taking an evolutionary approach.<span style="mso-spacerun: yes">&nbsp;</span>You can also define a set of objective <a href="./../../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html" guid="_0mYYkMlgEdmt3adZL5Dmdw">metrics</a> to collect during an iteration (for example, requirements that were
+ implemented and validated, number of defects issued compared with number fixed) and review them as part of the <a href="./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw"><span style="COLOR: windowtext">iteration assessment</span></a>. Do not rely on single metrics. Rather, use a combination of
+ metrics and look for trends.
+</p>
+<h4 style="MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify" align="justify">
+ Continuously re-evaluate what you do
+</h4>
+<p>
+ People make mistakes during a project. If we chose to hide those mistakes, then we risk repeating the same mistakes. In
+ addition, such repressed social dynamic issues can poison the team.
+</p>
+<p>
+ Therefore, on a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team
+ to&nbsp;track status and identify risks and issues. This can be done daily when the team gathers to share the status of
+ individual responsibilities and identify and address issues. At the end of iterations, <a href="./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html" guid="_0l53cMlgEdmt3adZL5Dmdw"><span style="COLOR: windowtext">assess the status</span></a> of what has been done and look for areas of improvement that can
+ be addressed in the next iteration. Have a retrospective review at the end of the project and capture lessons learned
+ to run future projects in a more efficient way.
+</p>
+<p>
+ If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads
+ to improved project results.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_focus.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_focus.xmi
new file mode 100644
index 0000000..5209806
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_focus.xmi
@@ -0,0 +1,93 @@
+<?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" epf:version="1.0.0" xmi:id="-HTMJFV29MTZkKWqnIo01Gg" name="core_principle_focus,_9gocwMvoEdqukPpotm3DYg" guid="-HTMJFV29MTZkKWqnIo01Gg" authors="Steve Adolph" changeDate="2006-09-27T16:35:45.896-0700" changeDescription="Added first draft of content." version="0.02">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
+ proves difficult to evolve, reuse, or integrate without substantial rework. It is also difficult to organize the team
+ or communicate ideas without the common technical focus that the architecture provides.
+</p>
+<p>
+ Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
+ essential technical decisions through the growing architecture.
+</p>
+<h3>
+ Practices
+</h3>
+<p>
+ The next sections describe the practices associated with this principle.
+</p>
+<h4>
+ Create the architecture for what you know today
+</h4>
+<p>
+ As Albert Einstein said, make everything as simple as possible but no simpler. Software projects are
+ resource-constrained, and the desire of developers to create elegant solutions may lead to a system of greater
+ complexity than the stakeholder requires. Efforts to future-proof a system in a turbulent or uncertain environment will
+ likely lead to code bloat , thus increasing overall cost with little actual benefit to show for it.
+</p>
+<p>
+ Therefore, create architectures that address the stakeholder’s real needs, and provide appropriate flexibility and
+ speed for the requirements as they are known today. Avoid the desire, no matter how well intentioned, to speculate on
+ future requirements and thereby over-engineer the architecture: if you have the skill to architect something today,
+ then clearly you must also have the skill to architect it tomorrow when you actually need to.
+</p>
+<h4>
+ Cope with complexity by raising the level of abstraction
+</h4>
+<p>
+ Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it becomes
+ difficult for the team to develop a common understanding of the system, because it is hard to see the bigger picture.
+</p>
+<p>
+ Therefore, use models to raise the level of abstraction to focus on important high-level issues, such as relationships
+ and patterns, rather than getting bogged down in details. Modeling raises the level of abstraction and allows the
+ system to be more easily understood from different perspectives.
+</p>
+<h4>
+ Let the problem drive the solution
+</h4>
+<p>
+ The architecture may become difficult to maintain and adapt to new stakeholder needs when technology, rather than the
+ problem, drives the solution.
+</p>
+<p>
+ Therefore, let the needs of the stakeholders guide the architecture, instead.
+</p>
+<h4>
+ Organize the architecture into loosely coupled, highly cohesive components
+</h4>
+<p>
+ Tight coupling between components makes a system fragile and difficult to understand. Software is expensive to create,
+ so if existing components can be reused, that may reduce effort required to create a system.
+</p>
+<p>
+ Therefore, organize the architecture of the system into components that to maximize cohesion and minimize coupling.
+ This improves comprehension, increases flexibility, and increases opportunities for re-use.
+</p>
+<h4>
+ Reuse existing assets
+</h4>
+<p>
+ It is wasteful to build what you can simply reuse, download, or even buy.
+</p>
+<p>
+ Therefore, make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those
+ assets do not exactly meet their needs or those assets are of poor quality. Be prepared to balance the savings you can
+ realize using an existing asset, even if the asset requires distorting the architecture or relaxing a constraint.
+</p>
+<h4>
+ Leverage the architecture as a collaborative tool
+</h4>
+<p>
+ Lack of a common understanding by developers about a system leads to indecision and contrary opinions among developers
+ and can quickly paralyze the project. Developers may have different mental models of the system and work at cross
+ purposes to each other.
+</p>
+<p>
+ Therefore, create and evolve the system architecture with the intention of using it to align the developer’s competing
+ mental models of the system. A good architecture facilitates collaboration by providing a common vocabulary for all
+ discussions regarding the system under development.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/design_mechanism.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/design_mechanism.xmi
new file mode 100644
index 0000000..3d12365
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/design_mechanism.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="-EG22TRyJ5TDKW6U88AXfhw" name="design_mechanism,_hNXugOUuEdqGCpzGJ4tJOw" guid="-EG22TRyJ5TDKW6U88AXfhw" changeDate="2007-02-26T13:41:09.500+0000" version="1.0.0">
+ <mainDescription><p align="left">
+ A Design Mechanism is a concrete representation of an&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. It is refined from an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>&nbsp;and is further refined into an <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/implementation_mechanism,_0LcUkA4LEduibvKwrGxWxA.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>&nbsp;as the design becomes more detailed.
+</p>
+<p align="left">
+ Design Mechanisms can be&nbsp;represented as specific design patterns and frameworks&nbsp;in the <a class="elementLink"
+ href="./../../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. They are used&nbsp;to guide development&nbsp;(see <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Using Patterns</a>). Design Mechanisms should still be relatively independent of
+ implementation but provide enough detailed information for implementation choices to be made and software to be
+ developed with confidence.
+</p>
+<p align="left">
+ See <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/example_design_mechanisms,_4k_Hsg4LEduibvKwrGxWxA.html"
+ guid="_4k_Hsg4LEduibvKwrGxWxA">Example: Design Mechanisms</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/developer_testing.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/developer_testing.xmi
new file mode 100644
index 0000000..aac8804
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/developer_testing.xmi
@@ -0,0 +1,121 @@
+<?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" epf:version="1.0.0" xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q" name="new_concept,_aFeZgJquEdukqcRKZBQN9w" guid="-Ff1JwbrGt1laexkOB6ZM1Q" changeDate="2007-01-03T17:00:23.980-0500" version="1.0.0">
+ <mainDescription><p>
+ Developer testing is the act of regression testing source code by developers.&nbsp; This is sometimes called "unit
+ regression testing" but many developer tests go beyond unit testing to address integration testing instead.
+</p>
+<h3>
+ Testing Philosophies
+</h3>
+<p>
+ Here are some important philosophies with regard to developer&nbsp;testing:
+</p>
+<ol>
+ <li>
+ The goal is to find defects. Successful tests find bugs, but correcting the bugs&nbsp;falls into other areas.
+ </li>
+ <li>
+ Test&nbsp;early and often. The cost of change rises exponentially the longer it takes to find and then remove a
+ defect. The implication is that you want to test as early as possible (the earliest you could possibly test is
+ first, see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw.html"
+ guid="_0Y6kUMlgEdmt3adZL5Dmdw">Concept: Test-first Design</a>).
+ </li>
+ <li>
+ Testing builds confidence. Many people fear making a change to their code because they are afraid that they will
+ break it, but with a full test suite in place if you do break something you know you will detect it and then fix
+ it.
+ </li>
+ <li>
+ One test is worth a thousand opinions. You can&nbsp;say that your application works, but until you show the test
+ results&nbsp;you might&nbsp;not be believed.
+ </li>
+ <li>
+ Test to the risk. The riskier something is, the more it needs to be reviewed and tested. In other words you should
+ invest significant effort testing in the algorithm for estimating radiation doses but nowhere near as much effort
+ testing the "change font size" function of the same application.
+ </li>
+ <li>
+ You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of
+ this guidance is testing code.
+ </li>
+</ol>
+<h3>
+ Qualities of a Good Developer Test
+</h3>
+These are the qualities of&nbsp;a good developer test:
+<ul class="noindent">
+ <li>
+ It runs fast.&nbsp;It has&nbsp;short setup, run time, and clean-up.
+ </li>
+ <li>
+ It runs in isolation. You should be able to reorder your tests.
+ </li>
+ <li>
+ It is understandable. Good tests have consistent and informative names and use data that makes them easy to read
+ and to understand.
+ </li>
+ <li>
+ It uses real data. E.g. Use copies of production data when appropriate, but remember that you'll also have to
+ create some specific "artificial" test data as well.
+ </li>
+ <li>
+ It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and
+ one only issue.
+ </li>
+</ul>
+<h3>
+ Approaches for Test Setup
+</h3>
+<p>
+ To successfully run a test, the system must be in a known state.&nbsp; To do this you will need objects or components
+ in memory, rows in your database, etc.&nbsp;that you will test against.&nbsp; The easiest approach is to hardcode the
+ required data and the setup code within the test itself.&nbsp; The primary advantage&nbsp;is that all the information
+ that you need about the test is in one place and that the test is potentially self-sufficient.
+</p>
+<p>
+ Another approach is to define an external data set which&nbsp;is loaded into memory or into&nbsp;the database at the
+ beginning of&nbsp;the test run.&nbsp; There are several advantages to this approach:
+</p>
+<ul>
+ <li>
+ It decouples the test data from the test.&nbsp;
+ </li>
+ <li>
+ More than one test&nbsp;can use the same data set.&nbsp;
+ </li>
+ <li>
+ It is easy to modify and/or multiply the test data.&nbsp;
+ </li>
+</ul>
+<p>
+ There are some disadvantages to this approach:
+</p>
+<ul>
+ <li>
+ Increased complexity for maintaining the external data
+ </li>
+ <li>
+ Potential coupling between test cases.&nbsp; When&nbsp;they share a common test data bed it becomes very easy to
+ write tests&nbsp;that depend on other tests running first, thereby coupling them together.<br />
+ </li>
+</ul>
+<h3>
+ Coding for Testability
+</h3>
+<p>
+ Add&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/termdefinitions/code_instrumentation,_JiqnEJt1EdutoZjlV3a4Lg.html"
+ guid="_JiqnEJt1EdutoZjlV3a4Lg">Code Instrumentation</a> for testing and debugging.&nbsp; Pay special attention to the
+ implementation of the observation/control points, such as critical functions or&nbsp;objects,&nbsp;as these aspects
+ might need special support that has to be implemented in the component under test.
+</p>
+<h3>
+ Reviewing Tests
+</h3>
+<p>
+ If a test will be long-lived, ask a person with less inside knowledge of the component to run it and check if there is
+ enough support information. Review it with other people within the development team and other interested parties as
+ needed.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/elaboration_phase.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/elaboration_phase.xmi
new file mode 100644
index 0000000..1b63e2c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/elaboration_phase.xmi
@@ -0,0 +1,107 @@
+<?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" epf:version="1.0.0" xmi:id="-F-eWIBzxEXE1jygbN3nrrQ" name=",_2plxwBOMEduCNqgZdt_OaA" guid="-F-eWIBzxEXE1jygbN3nrrQ" changeDate="2006-09-27T16:28:27.954-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose of this phase is to establish the baseline of the architecture of the system and provide a stable basis for
+ the bulk of the&nbsp;development effort in the next phase.
+</p>
+<p>
+ There are objectives for the Elaboration phase that help you address risks associated with requirements, architecture,
+ costs, and schedule <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Get a more detailed understanding of the requirements.</strong> Having a good understanding of the
+ majority of requirements allows you to create a more detailed plan and to get buy-in from stakeholders. Be sure
+ to gain an in-depth understanding of the most critical requirements to be validated by&nbsp;the architecture.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design, implement, validate, and establish the baseline for the architecture.</strong> Design,
+ implement, and test a skeleton structure of the system. Although the functionality is not complete yet, most of
+ the interfaces between the building blocks are implemented and tested. This is referred to <strong>an
+ executable architecture</strong>.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Mitigate essential risks, and produce accurate schedule and cost estimates.</strong> Many technical
+ risks are addressed as a result of detailing the requirements and of designing, implementing, and testing the
+ architecture. Refine and detail the high-level project plan.
+ </p>
+ </li>
+</ul>
+<p>
+ The following table summarizes the&nbsp;Elaboration phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <strong>Elaboration phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Get a more detailed understanding of the requirements
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0ruyoclgEdmt3adZL5Dmdw.html" guid="_0ruyoclgEdmt3adZL5Dmdw">Manage Requirements</a> <br />
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Design, implement, validate, and baseline an architecture
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <a class="elementLinkWithUserText" href="./../../../define_architecture,_0rcewclgEdmt3adZL5Dmdw.html" guid="_0rcewclgEdmt3adZL5Dmdw">Define the Architecture</a><br />
+ <a class="elementLinkWithUserText" href="./../../../develop_requirement_within_context,_WrXvwPinEdmugcVr9AdHjQ.html" guid="_WrXvwPinEdmugcVr9AdHjQ">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0rilYclgEdmt3adZL5Dmdw.html" guid="_0rilYclgEdmt3adZL5Dmdw">Validate Build</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Mitigate essential risks, and produce accurate schedule and cost estimates
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a> <br />
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ The number of iterations in the Elaboration phase is dependent on, but not limited to, factors such as green-field
+ development versus maintenance cycle, unprecedented system versus well-known technology and architecture, and so on.
+</p>
+<p>
+ Typically, on the first iteration, you should design, implement, and test a small number of critical scenarios to
+ identify what type of architecture and architectural mechanisms you need, so you can mitigate the most crucial risks.
+ You also detail high-risk requirements that have to be addressed early in the project. You test enough to validate that
+ the architectural risks are mitigated.
+</p>
+<p>
+ On the following iterations, you fix whatever was not right from the previous iteration. You design, implement, and
+ test the remaining architecturally significant scenarios, ensuring that you check all major areas of the system
+ (architectural coverage), so potential hidden risks arise as early as possible. <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>
+</p>
+<p>
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/entity_control_boundary_pattern.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/entity_control_boundary_pattern.xmi
new file mode 100644
index 0000000..2fcf31d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/entity_control_boundary_pattern.xmi
@@ -0,0 +1,180 @@
+<?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" epf:version="1.0.0" xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" name="finding_analysis_classes,_uF-QYEAhEdq_UJTvM1DM2Q" guid="-awaQ_2dwhGyKRoVKQ-esPQ" changeDate="2006-09-28T10:02:50.694-0700">
+ <mainDescription><p>
+ When identifying the elements for some scenario of system behavior, you can align each participating element with one
+ of three key perspectives: Entity, Control, or Boundary.
+</p>
+<p>
+ This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>] among other places), but the Entity Control Boundary pattern is not solely
+ appropriate for dealing with user interfaces and it gives the controller a slightly different role to play.
+</p>
+<h5>
+ ECB&nbsp;Pattern Example
+</h5>
+<p>
+ &nbsp;<img height="233" alt="" src="./resources/EBCDiagram.JPG" width="493" />
+</p>
+<h3>
+ Entity Elements
+</h3>
+<p>
+ An entity is a long-lived, passive element that is responsible for some meaningful chunk of information. This is not to
+ say that entities are "data" while other&nbsp;design elements&nbsp;are "function". Entities perform behavior organized
+ around some cohesive amount of data.
+</p>
+<p>
+ An example entity for a customer service application would be a Customer entity that manages all information about a
+ customer.&nbsp; A design element for&nbsp;this entity would include data on the customer, behavior to manage the data,
+ behavior to validate customer information&nbsp;and perform other business calculations such as "is this customer
+ allowed to purchase product X?"
+</p>
+<p>
+ The identification of the entities as part of this pattern can be done many times at different levels of abstraction
+ from the code, at different levels of granularity in size, and from the perspectives of different contexts.&nbsp; For
+ example you could do an analysis pass on a scenario of creating a marketing campaign and identify the customer element
+ with various customer data elements such as name and address plus various required behaviors such as the management of
+ the name and address data and the ability to&nbsp;rate the customer based on some algorithm&nbsp;(such an application
+ of this pattern would be abstract from code, coarse-grained, and have no specific context).&nbsp; Later you could do a
+ pass on the same scenario applying an architectural mechanism for database access that breaks the address out into its
+ own element, moves the responsibility for storing and retrieving customers to a new control element, and identifies
+ some specific database decisions&nbsp;such as&nbsp;the usage of primary keys in the entities (such an application of
+ this pattern would be closer to the code, finer-grained, and aligned with a database&nbsp;context).
+</p>
+<h3>
+ Control Elements
+</h3>
+<p>
+ A control element manages the flow of interaction of the scenario. A control element could manage the end-to-end
+ behavior of a scenario or it could manage the interactions between a subset of the elements.&nbsp; Behavior and
+ business rules relating to the information relevant to the scenario should be assigned to the entities; the control
+ elements are just responsible for the flow of the scenario.
+</p>
+<p>
+ An example&nbsp;control element&nbsp;for a customer service application would be CreateMarketingCapmpaign.&nbsp; This
+ design element would&nbsp;be responsive to certain front-end boundary elements and would collaborate with other
+ entities, control&nbsp;elements, and back-end boundary elements to support the creation of a marketing campaign.
+</p>
+<p>
+ As with the entity example above, there might be many passes over the identification of control elements.&nbsp; A first
+ pass might be an analysis pass that identifies one control element for a&nbsp;scenario with behavior to make sure the
+ design can support the flow of events, a&nbsp;subsequent pass might find controllers to manage reusable collaborations
+ of low level elements that will map to a specific code&nbsp;unit to be written.
+</p>
+<h3>
+ Boundary Elements
+</h3>
+<p>
+ A boundary element lies on the periphery of a system or subsystem, but within it. For any scenario being considered
+ either across the whole system or within some subsystem, some boundary elements will be "front-end" elements that
+ accept input from outside the area under design and other elements will be "back-end" managing communication to
+ supporting elements outside the system or subsystem.
+</p>
+<p>
+ Two example boundary elements for a customer service application might be a front-end MarketingCampaignForm and a
+ back-end BugdetSystem element.&nbsp; The MarketingCampaignForm would manage the exchange of information between a user
+ and the system and the BugdetSystem would manage the exchange of information between the system and an external system
+ that manages budgets.
+</p>
+<p>
+ An analysis pass could identify one boundary element for each external relevant to a scenario; subsequently these could
+ be broken down into multiple boundary elements or&nbsp;small communities made up of collaborating&nbsp;elements&nbsp;of
+ all three stereotypes.
+</p>
+<h3>
+ Walking the Scenario
+</h3>
+<p>
+ One can walk through a scenario initiated by something outside the bounds of the system or subsystem being designed and
+ distribute the responsibility to perform behavior supporting the scenario to the elements identified of each
+ type.&nbsp; The appropriate design element responsible for each action in the scenario will be as described in the
+ definition of each of the element types described above.
+</p>
+<p>
+ In addition to identifying the behavior necessary to perform the scenario, the initiation of this behavior from design
+ element to design element&nbsp;identifies the necessary relationships.&nbsp; There are certain
+ appropriate&nbsp;relations between the participating elements.&nbsp;&nbsp;An element can communicate to other elements
+ of the same kind.&nbsp; Control&nbsp;elements can communicate with each of the other two kinds, but entities and
+ boundary elements should not directly communicate.&nbsp;
+</p>
+<p>
+ The table below shows appropriate links between design elements.
+</p>
+<table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ <center>
+ Entity
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Boundary
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Control
+ </center>
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ Entity
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Boundary
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Control
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ By&nbsp;applying this pattern, a robust design can be put together that identifies the elements, behavior, and
+ relationships&nbsp;necessary to support&nbsp;a scenario.&nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation 2.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation 2.xmi
new file mode 100644
index 0000000..9980637
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation 2.xmi
@@ -0,0 +1,76 @@
+<?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" epf:version="1.0.0" xmi:id="-9gUpkUYqONF3x8UWwAO_zw" name="failure_analysis_rpt_creation,_0jhR0MlgEdmt3adZL5Dmdw" guid="-9gUpkUYqONF3x8UWwAO_zw" changeDate="2006-09-29T13:52:52.340-0700" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ During testing, you will encounter failures related to the execution of your tests in different forms, such as code
+ defects, user errors, program malfunctions, and general problems. This&nbsp;concept discusses some ways to conduct
+ failure analysis and then to report your findings.
+</p>
+<h3>
+ Failure Analysis
+</h3>
+<p>
+ After you have run your tests, it is good practice to identify inputs for review of the results of the testing effort.
+ Some likely sources are defects that occurred during the execution of test scripts, change request metrics, and test
+ log details.
+</p>
+<p>
+ Running test scripts results in errors of different kinds such as uncovered defects, unexpected behavior, or general
+ failure of the test script to run properly. When you run test scripts, one of the most important things to do is to
+ identify causes and effects of failure. It is important to differentiate failures in the system under test&nbsp;from
+ those related to the tests themselves.
+</p>
+<p>
+ Change request metrics are useful in analyzing and correcting failures in the testing. Select metrics that will
+ facilitate creation of incident reports from a collection of change requests.
+</p>
+<p>
+ Change request metrics that you may find useful in your failure analysis include:
+</p>
+<ul>
+ <li>
+ test coverage
+ </li>
+ <li>
+ priority
+ </li>
+ <li>
+ impact
+ </li>
+ <li>
+ defect trends
+ </li>
+ <li>
+ density
+ </li>
+</ul>
+<p>
+ Finally, one of the most critical sources of your failure analysis is the test log. Start by gathering the test log's
+ output during the implementation and execution of the tests. Relevant logs might come from many sources; they might be
+ captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines your
+ team has developed, output from the target test items themselves, and recorded manually be the tester. Gather all of
+ the available test log sources and examine their content. Check that all the scheduled testing executed to completion,
+ and that all the needed tests&nbsp;have been scheduled.
+</p>
+<h3>
+ Self-Documenting Tests
+</h3>
+<p>
+ For automated tests it is a best practice for the test itself to examine the results and clearly report itself as
+ passing or failing. This provides the most efficient way to run tests such that whole suites of tests can be run with
+ each test in turn determining whether it has passed or failed without the need for human intervention. When authoring
+ self-documenting tests, take extra care to ensure that the analysis of the results considers all possibilities.
+</p>
+<h3>
+ Recording Your Findings
+</h3>
+<p>
+ Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
+ your findings in a report. There are several factors that go into deciding whether to record your failure analysis in a
+ report. Some of the key factors include: level of testing formality, complexity of the testing effort, and the need to
+ communicate the testing results to the entire development team. In less formal environments, it may be sufficient to
+ record your failure analysis in&nbsp;a test evaluation summary.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation.xmi
new file mode 100644
index 0000000..b084730
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/failure_analysis_rpt_creation.xmi
@@ -0,0 +1,49 @@
+<?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" epf:version="1.0.0" xmi:id="_qS8JcMM3EdmSIPI87WLu3g" name="failure_analisys_rpt_creation,_0jhR0MlgEdmt3adZL5Dmdw" guid="_qS8JcMM3EdmSIPI87WLu3g" changeDate="2006-09-20T15:57:59.790-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ During testing, you will encounter failures related to the execution of your tests&nbsp;in different&nbsp;forms, such
+ as, code defects, user errors, program malfunctions, and general problems.&nbsp;This concept page describes some ways
+ to conduct failure analysis and then to report your findings.
+</p>
+<h3>
+ Failure Analysis
+</h3>
+<p>
+ After you have run your tests, it is good practice to identify inputs for review of the results of the testing
+ effort.&nbsp;Some likely sources are defects that occured during the execution of test scripts, change request metrics,
+ and&nbsp;test log details.
+</p>
+<p>
+ Running test scripts may results in errors of different kinds such as uncovered defects, unexpected behavior, or
+ general failure of the test script to run properly.&nbsp;When you run test scripts, one of the most important things to
+ do is to identify causes and effects of failure.&nbsp;It is important to differentiate failures in the system under
+ test as well as those related to the tests themselves.
+</p>
+<p>
+ Change request metrics are useful in analyzing and correcting failures in the testing.&nbsp;Select metrics that will
+ facilitate creation of incident reports from a collection of change requests.&nbsp;Change request metrics that you may
+ find useful in your failure analysis include: test coverage, priority, impact, defect trends and density.
+</p>
+<p>
+ Finally, one of the most critical sources of your failure analysis is the test log.&nbsp;Start by gathering the test
+ logs output during the implementation and execution of the tests. Relevant logs might come from many sources - they
+ might be captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines
+ your team has developed, output from the target-of-test items themselves, and recorded manually by the tester. Gather
+ all of the available test log sources and examine their content. Check that all the scheduled testing executed to
+ completion, and that all the tests that should have been scheduled actually were.
+</p>
+<h3>
+ Recording Your Findings
+</h3>
+<p>
+ Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
+ your findings in a report.&nbsp;There are several factors that go into deciding whether to record your failure analysis
+ in a report.&nbsp;Some of the key factors include:&nbsp;level of testing formality, complexity of the testing effort,
+ and the need to communicate the testing results to the entire development team.&nbsp;In less formal environments, it
+ may be sufficient to record your failure analysis in the form of a change request.&nbsp;In this case, it is convenient
+ to be able to cull relevant failure analysis information of change requests and put this into&nbsp;a report format.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/implementation_mechanism.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/implementation_mechanism.xmi
new file mode 100644
index 0000000..ff10d5e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/implementation_mechanism.xmi
@@ -0,0 +1,40 @@
+<?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" epf:version="1.0.0" xmi:id="-Rex8oOBv985RruZNrCW0rg" name="implementation_mechanisms,_3ANskOK5EdqHEo0wLIc5jg" guid="-Rex8oOBv985RruZNrCW0rg" changeDate="2006-09-25T21:09:13.255+0100" version="1.0.0">
+ <mainDescription><p>
+ An Implementation Mechanism is a refinement of a corresponding Design Mechanism that uses, for example, a particular
+ programming language and other implementation technology (such as a particular vendor's middleware product). An
+ Implementation Mechanism may instantiate one or more idioms or implementation patterns.
+</p>
+<p>
+ Review these points when you are considering Implementation Mechanisms:
+</p>
+<ul>
+ <li>
+ <p>
+ <b>Determine the ranges of characteristics.</b> Take the characteristics that you identified for the Design
+ Mechanisms into consideration to determine reasonable, economical, or feasible ranges of values to use in the
+ Implementation Mechanism candidate.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Consider the cost of purchased components</b>. For Implementation Mechanism candidates, consider the cost of
+ licensing, the maturity of the product, your history or relationship with the vendor, support, and so forth in
+ addition to purely technical criteria.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Conduct a search for the right components, or build the components.</b> You will often find that there is no
+ apparently suitable Implementation Mechanism for a particular Design Mechanism. This will either trigger a
+ search for the right product or make the need for in-house development apparent. You may also find that some
+ Implementation Mechanisms are not used at all.<br />
+ <br />
+ The choice of Implementation Mechanisms is based not only on a good match for the technical characteristics,
+ but also on the non-technical characteristics, such as cost. Some of the choices may be provisional. Almost all
+ have some risks attached to them. Performance, robustness, and scalability are nearly always concerns and must
+ be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype.
+ </p>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/inception_phase.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/inception_phase.xmi
new file mode 100644
index 0000000..ed97ba6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/inception_phase.xmi
@@ -0,0 +1,110 @@
+<?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" epf:version="1.0.0" xmi:id="-GRJW_KNOJoEQF3r6lmBrEw" name=",_0hmKgBOMEduCNqgZdt_OaA" guid="-GRJW_KNOJoEQF3r6lmBrEw" changeDate="2006-11-06T11:29:38.552-0800" version="1.0.0">
+ <mainDescription><p>
+ The purpose&nbsp;in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the
+ project.
+</p>
+<p>
+ There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the
+ intended solution <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Understand what to build.</strong> Determine the <a class="elementLinkWithUserText" href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>, the scope of the system, and its boundaries. Identify who is
+ interested in this system and why (see <a class="elementLinkWithUserText" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Identify key system functionality.</strong> Decide which requirements are most critical.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Determine at least one possible solution.</strong> Identify at least one candidate architecture and its
+ feasibility.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand</strong> the cost, schedule, and risks associated with the project.
+ </p>
+ </li>
+</ol>
+<p>
+ The following table summarizes the&nbsp;Inception phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <strong>Inception phase objectives and activities</strong>
+</p>
+<table cellspacing="1" cellpadding="0" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ <b>Phase objectives</b>
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <b>Activities that address objectives</b>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Understand what to build
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0okw8clgEdmt3adZL5Dmdw.html" guid="_0okw8clgEdmt3adZL5Dmdw">Manage Requirements</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Identify key system functionality
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../initiate_project,_0oSdE8lgEdmt3adZL5Dmdw.html" guid="_0oSdE8lgEdmt3adZL5Dmdw">Initiate Project</a><br />
+ <a class="elementLinkWithUserText" href="./../../../manage_requirements,_0okw8clgEdmt3adZL5Dmdw.html" guid="_0okw8clgEdmt3adZL5Dmdw">Manage Requirements</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Determine at least one possible solution
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../determine_architectural_feasibility,_0oreoclgEdmt3adZL5Dmdw.html" guid="_0oreoclgEdmt3adZL5Dmdw">Determine Architectural Feasibility</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="295">
+ Understand the cost, schedule, and risks associated with the project
+ </td>
+ <td class="Normal" valign="top" width="295">
+ <a class="elementLinkWithUserText" href="./../../../initiate_project,_0oSdE8lgEdmt3adZL5Dmdw.html" guid="_0oSdE8lgEdmt3adZL5Dmdw">Initiate Project</a><br />
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<h4>
+ Key considerations
+</h4>
+<p>
+ Projects may have one or more iterations in the Inception phase. Among reasons for multiple iterations in Inception,
+ you find:
+</p>
+<ul>
+ <li>
+ Project is large, and it is&nbsp;hard to define its scope.
+ </li>
+ <li>
+ Unprecedented system.
+ </li>
+ <li>
+ Too many stakeholders with competing needs and complex relationships.
+ </li>
+ <li>
+ Major technical risks demand the creation of a prototype or proof of concept.
+ </li>
+</ul>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/iteration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/iteration.xmi
new file mode 100644
index 0000000..0d4baa0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/iteration.xmi
@@ -0,0 +1,73 @@
+<?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" epf:version="1.0.0" xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" name="new_concept,_lam4ADkBEduxovfWMDsntw" guid="-vi8wxwxVZLY0SMPFxZjD7A" changeDate="2006-10-31T13:46:17.066-0800">
+ <mainDescription><H3>What is an Iteration </H3>
+<P>An iteration is a set period of time within a project in which you produce a stable, executable version of the product, together with any other supporting documentation, install scripts, or similar, necessary to use this release. The executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, get feedback on how they are doing so that they can improve their understanding of what needs to be done, and how to do it, Each iteration builds upon the results of previous iteration, and will produce a product increment one step closer to the final product. Iterations are timeboxed, meaning the schedule for an iteration should be regarded as fixed, and the scope of the iteration's content actively managed to meet that schedule. </P>
+<P>At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates. </P>
+<P>Iterative development is very disciplined: the iteration length is fixed; the objectives of iterations are carefully planned; the evaluation criteria are established when each iteration is planned; and the tasks and responsibilities of participants are well defined. Additionally, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this too is done in a structured fashion. </P>
+<P>Each iteration should address the most critical risks, and implement the highest-priority Work Items. This ensures that each iteration adds maximum stakeholder value, while reducing uncertainty. Iterative development is typically combined with frequent or continuous integration: as unit-tested components become available, they are integrated, then a build is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the iteration proceeds, towards the goals set when the iteration was planned. Regular builds, such as daily or more frequent builds, let you break down the integration and test issues and spread them across the development cycle. These issues have often been the downfall of large projects because all problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team. </P>
+<H3>What Problem Do Iterations Address? </H3>
+<P>Today’s software applications are too complex to allow you to sequentially define the requirements, come up with an architecture and design, do an implementation, carry out testing, and get it all right. Whether you use waterfall or iterative development approaches, your initial requirements, architecture, design, and code will be suboptimal. With waterfall development, you typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is too costly to make them. By contrast, dividing the project into a series of time-boxed iterations allows you to deliver capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely feedback loops enabling issues to be addressed and improvements made at a lower cost while budget and time still allow, and before the project has gone so far ahead that major rework is required. </P>
+<H3>Iteration Length </H3>
+<P>Iterations are typically 4 weeks long, although some teams will work with iterations as short as a week or as long as six weeks. For factors driving iteration length, see Table X. </P>
+<P><STRONG><EM>Table X. Factors Impacting Iteration Length.</EM></STRONG><BR>&nbsp;<BR></P>
+<TABLE style="WIDTH: 547px; HEIGHT: 356px" cellSpacing=2 cellPadding=2 width=547 border=1>
+<TBODY>
+<TR>
+<TH scope=col>Factors leading to reduced iteration length&nbsp; </TH>
+<TH scope=col>Factors leading to increased iteration length </TH></TR>
+<TR>
+<TD>Small teams&nbsp; </TD>
+<TD>Large teams </TD></TR>
+<TR>
+<TD>Collocated teams&nbsp; </TD>
+<TD>Distributed teams </TD></TR>
+<TR>
+<TD>Strong configuration management system&nbsp; </TD>
+<TD>Poor configuration management system </TD></TR>
+<TR>
+<TD>Dedicated, full-time resources </TD>
+<TD>Matrixed or part-time resources </TD></TR>
+<TR>
+<TD>Automated testing </TD>
+<TD>Lack of automated testing </TD></TR>
+<TR>
+<TD>Integrated tool environment&nbsp; </TD>
+<TD>Absence of good automation and tool integration </TD></TR>
+<TR>
+<TD>Team experienced with iterative development </TD>
+<TD>Team inexperienced with iterative development </TD></TR>
+<TR>
+<TD>Fast decision making </TD>
+<TD>Policies and bureaucracy preventing fast decision making </TD></TR>
+<TR>
+<TD>Unclear requirements </TD>
+<TD>Well-understood requirements </TD></TR>
+<TR>
+<TD>Unclear or brittle architecture </TD>
+<TD>Well-defined and stable architecture </TD></TR>
+<TR>
+<TD>New and poorly understood technology </TD>
+<TD>Well-understood technology </TD></TR></TBODY></TABLE><BR><BR>
+<H3>Why Iterate? </H3>
+<P>The iterative approach has proven itself superior to the waterfall approach for a number of reasons: </P>
+<UL>
+<LI>You are more likely to build an application that addresses user needs. Early specification of requirements often leads to unused features. The Standish Group has researched thousands of application development projects and has found that more than 45 percent of features are never used, while another 19 percent are used rarely&nbsp; (see Figure 2.3). In other words, typically more than half of the development effort is wasted on developing nonessential capabilities. To avoid this problem, you need to involve the customer in the development project and use an iterative approach that allows you to implement and validate the capabilities deemed most essential in each iteration. This approach allows not only early validation of key capabilities but also addition of new capabilities late in the project.
+<LI>Integration is not one “big bang” at the end of a project. Leaving integration to the end results in time- and budget-consuming rework. To avoid this, an iterative approach breaks a project down into smaller iterations, each evolving executable code that is continuously integrated to enable rapid feedback and minimize later revision.
+<LI>Risks are usually discovered or addressed during early iterations. With the iterative approach, risks are more likely to be identified and addressed in early iterations. As an example, if there is a risk that a stakeholder will not be happy with the functionality you are developing, iterative development will encourage you to&nbsp; implement the most essential capabilities partially and demonstrate them to key stakeholders to make sure that you are on the right track.
+<LI>Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all lifecycle activities, from requirements capture and test definition to development, implementation, and testing. Consequently, they can make sure they have the tools, skills, organizational structure, and so on to work effectively.
+<LI>Management has a way of making tactical changes to the product. Management can make changes to the product along the way—to compete with other new products, for example. Iterative development allows you to evolve partial implementations of the end product quickly and use these for quick release of a reduced-scope product to counter a competitor's move.
+<LI>Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in iterations than to recognize them at the beginning. Discussions and reviews of the design in early iterations allow team members to spot potential opportunities for reuse and then develop a mature common code for these opportunities in subsequent iterations.
+<LI>Defects can be found and corrected over several iterations. This capability results in a robust architecture and a high-quality application. Flaws are detected in early iterations, rather than during a massive testing phase at the end. Performance bottlenecks are discovered while they can still be addressed instead of creating panic on the eve of delivery.
+<LI>Project personnel are better used. Many organizations match their use of a waterfall approach with a pipeline organization: the analysts send the completed requirements to designers, who send a completed design to programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of errors and misunderstandings and make people feel less responsible for the final product. An iterative process encourages widening the scope of expertise of the team members, allowing them to play many roles and thus enabling a project manager to make better use of the available staff and simultaneously remove problematic handoffs.
+<LI>Team members learn along the way. The project members have several opportunities within a development cycle to learn from their mistakes and improve their skills from one iteration to another. More training opportunities can be discovered as a result of assessing the earlier iterations.
+<LI>The development process itself is improved and refined along the way. The end of iteration assessment not only looks at the project status from a product or scheduling perspective but also analyzes what can be improved in the next iteration in both the organization and the process.&nbsp; One technique for doing so is to hold a retrospective. </LI></UL><BR><SPAN class=E1><SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; mso-fareast-language: JA; mso-bidi-language: AR-SA"><?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><STRONG><IMG height=307 alt="45 percent of featues implemented are never ever used" src="./resources/iteration_1.GIF" width=489></STRONG></v:shapetype></SPAN></SPAN><BR>&nbsp;
+<P><STRONG><EM>Figure 2.3. Most Features Implemented Are Never or Rarely Used.<BR></EM></STRONG><EM>An amazing 45 percent of features implemented are never used, while another 19 percent are used only rarely. If features never used were not implemented in the first place, development time would be cut in about half. Further, since productivity is typically measured in the form of lines of code or functionality delivered, this improvement would not register as a productivity increase using standard productivity measures.<BR></EM>&nbsp; </P>
+<H3>Iteration and Phases </H3>
+<P>The purpose of iterations is to produce an executable which can be assessed so you can get feedback and make course corrections. This executable brings you one step closer to the final product. Phases provide a focus for a team on meeting a certain management objective. OpenUP has four phases, each ending with answering a specific question: </P>
+<UL>
+<LI><STRONG>Inception</STRONG>—Do we agree on the problem we are trying to solve?
+<LI><STRONG>Elaboration</STRONG>—Do we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?
+<LI><STRONG>Construction</STRONG>—Do we agree that we have a system that addresses key stakeholder needs?
+<LI><STRONG>Transition</STRONG>—Do we agree that we can release the system and end the project? </LI></UL>
+<P>Within each phase, you may have one or several iterations, where the iterations aim at producing the results required to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and test some key aspects of the system so that we understand what architecture we need, what Commercial Off-The-Shelf (COTS) components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These needs will steer how we prioritize what is to be done in an Elaboration iteration. </P></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/metrics.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/metrics.xmi
new file mode 100644
index 0000000..223c64a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/metrics.xmi
@@ -0,0 +1,86 @@
+<?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="_7ygXoMM3EdmSIPI87WLu3g" name="metrics,_0mYYkMlgEdmt3adZL5Dmdw" guid="_7ygXoMM3EdmSIPI87WLu3g" changeDate="2006-08-29T17:19:12.494-0700">
+ <mainDescription><h3>
+ What is a Metric?
+</h3>
+<p>
+ We distinguish between measure and metric.&nbsp; To clarify, let’s start by defining what is meant by measure and by
+ metric.
+</p>
+<ul>
+ <li>
+ <strong>Measure</strong>:&nbsp;a raw data item that is directly measured and that will be used to calculate a
+ metric.&nbsp;
+ </li>
+ <li>
+ <strong>Metric</strong>:&nbsp;an interpretation of a measure or a set of measures that you use to guide your
+ project.
+ </li>
+</ul>
+<p>
+ For example, recording how many test cases have passed and how many have failed are <strong>measures</strong>.
+ Interpreting what level of quality this indicates and how it reflects the team's progress within the current iteration
+ is a <strong>metric</strong>.
+</p>
+<h3>
+ Why Measure?
+</h3>
+<p>
+ Measurements will mainly help you to:
+</p>
+<ul>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Communicate effectively</strong>. Measurement supports effective communication among team members and
+ project stakeholders.&nbsp;
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Identify and correct problems early</strong>. Measurement enables you to identify and manage potential
+ problems early in the development lifecycle.&nbsp;
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Make informed trade-offs</strong>. Measurement helps assess objectively the impact of decisions,
+ helping managers to make trade-off decisions to best meet project goals.&nbsp;&nbsp;
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em" align="left">
+ <strong>Tune estimations</strong>. Recording schedule, progress, and expenditures for projects will help team
+ members to make more reliable estimations in the future.
+ </div>
+ </li>
+</ul>
+<h3 align="left">
+ Potential Challenges
+</h3>
+<p align="left">
+ There are several dangers when it comes to metrics:
+</p>
+<div style="margin-left: 2em">
+ <ul>
+ <li>
+ <div align="left">
+ They can be too costly.&nbsp;The benefit provided by the metric must exceed the cost of collecting
+ it.&nbsp;Keep your measurements simple and easy to collect.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ They’re a poor substitute for communication.&nbsp;The best way to determine the current status of a project
+ is to ask the people involved, not to look at a report summarizing key metrics.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ They can be misleading.&nbsp; No metric or collection of metrics is perfect.&nbsp;Furthermore, the
+ measurements upon which they are based can be manipulated by the people capturing them.&nbsp;Don’t rely
+ simply upon metrics to manage a project.<br />
+ </div>
+ </li>
+ </ul>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/milestones.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/milestones.xmi
new file mode 100644
index 0000000..8e119ee
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/milestones.xmi
@@ -0,0 +1,50 @@
+<?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" epf:version="1.0.0" xmi:id="-DG8mYMnTGosWIxjPQFUoTA" name="milestones,_HNxbwMBJEdqSgKaj2SZBmg" guid="-DG8mYMnTGosWIxjPQFUoTA" changeDate="2006-10-31T12:53:11.446-0800">
+ <mainDescription><p>
+ Milestones are&nbsp;the point at which an iteration or phase formally ends.
+</p>
+<p>
+ From a&nbsp;development perspective, each iteration provides an increment of functionality to the product. Thus, the
+ end of each iteration corresponds to a checkpoint where the project team demonstrates to stakeholders that the
+ objectives for that iteration have been met.
+</p>
+<p>
+ However, there are four major milestones that provide evaluation criteria at the end of each phase. From a management
+ perspective, the software lifecycle&nbsp;is decomposed over time into four sequential phases, each concluded by a major
+ milestone [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BOE95</a>].
+</p>
+<p class="banner" align="center">
+ <img height="156" alt="Click on text for more information about phases and milestones" src="./resources/co_phas1.gif" width="406" border="0" />
+</p>
+<p class="picturetext" align="center">
+ The phases and milestones of a project
+</p>
+<p>
+ Each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed to
+ determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to
+ the next phase.
+</p>
+<p>
+ At the end of the <strong>Inception</strong> phase is the first major project milestone or <strong>Lifecycle Objectives
+ Milestone</strong>. At this point, you examine the cost versus benefits of the project, and decide either to proceed
+ with the project or to cancel it.
+</p>
+<p>
+ At the end of the <strong>Elaboration</strong> phase is the second important project milestone, the <strong>Lifecycle
+ Architecture Milestone</strong>. At this point, a baseline of requirements is agreed to, you examine the detailed
+ system objectives and scope, the choice of architecture, and the resolution of the major risks.
+</p>
+<p>
+ At the end of the <strong>Construction</strong> phase is the third important project milestone, the <strong>Initial
+ Operational Capability Milestone</strong>. At this point, the product is ready to be handed over to the transition
+ team. All functionality has been developed and all alpha testing (if any) has been completed. In addition to the
+ software, a user manual has been developed, and there is a description of the current release. The product is ready for
+ beta testing.
+</p>
+<p>
+ At the end of the <strong>Transition</strong> phase is the fourth important project milestone, the <strong>Product
+ Release Milestone</strong>. At this point, you decide if the objectives were met, and if you should start another
+ development cycle. The Product Release Milestone is the result of the customer reviewing and accepting the project
+ deliverables.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/pattern.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/pattern.xmi
new file mode 100644
index 0000000..35b7540
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/pattern.xmi
@@ -0,0 +1,288 @@
+<?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" epf:version="1.0.0" xmi:id="_QvmkAMM1EdmSIPI87WLu3g" name="patterns,_0YJvUMlgEdmt3adZL5Dmdw" guid="_QvmkAMM1EdmSIPI87WLu3g" changeDate="2007-02-26T09:45:45.531+0000" version="1.0.0">
+ <mainDescription><h4>
+ Origins
+</h4>
+<p>
+ The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
+ written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
+ books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE79</a>] have had the greatest impact on the software community and the adoption of
+ software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
+ capture of software design expertise in a form that can then be reapplied in recurring situations.
+</p>
+<h4>
+ A definition of patterns
+</h4>
+<p>
+ Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]:
+</p>
+<blockquote>
+ <p>
+ "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
+ and classes, when to apply the solution, and the consequences of applying the solution."
+ </p>
+</blockquote>
+<p>
+ This definition often serves only as a starting point, however. A richer definition, based on Alexander’s work, is
+ offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
+ among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
+ configuration that allows these forces to resolve themselves.
+</p>
+<h4>
+ Describing patterns
+</h4>
+<p>
+ It is commonplace to describe patterns&nbsp;using the&nbsp;format made popular by Erich Gamma and his three colleagues
+ [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
+ description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
+ object-oriented design patterns:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
+ abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
+ of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
+ address?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Also known as:</strong> Other names for the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
+ the problem.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
+ applicable.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Structure:</strong> A graphical representation of the classes in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Collaborations:</strong> How participants collaborate to fulfil their responsibilities.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation:</strong> Guidance on the implementation of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Sample code:</strong> Code fragments that illustrate the pattern’s implementation.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Known uses:</strong> Where to find real-world examples of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
+ </p>
+ </li>
+</ul>
+<p>
+ Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
+ modification, to address other software patterns. A more general keyword format for software patterns based on
+ Alexander’s principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
+</p>
+<h4>
+ Pattern catalogs
+</h4>
+<p>
+ To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
+ the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] uses three classifiers: granularity, functionality, and structured
+ principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
+ classifies patterns into three levels of abstraction:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
+ scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
+ pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
+ are described by design patterns. The GoF pattern is an example of a design pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
+ </p>
+ </li>
+</ul>
+<p>
+ Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
+</p>
+<ul>
+ <li>
+ Structure
+ </li>
+ <li>
+ Distributed systems
+ </li>
+ <li>
+ Interactive systems
+ </li>
+ <li>
+ Adaptable systems
+ </li>
+</ul>
+<p>
+ The following table shows the categorization of their architectural patterns.
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1"
+valign="top">
+ <caption>
+ <strong>Categories for Architectural Patterns<br />
+ </strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ <div align="center">
+ <strong>Category</strong>
+ </div>
+ </th>
+ <th scope="col">
+ <div align="center">
+ <strong>Pattern</strong>
+ </div>
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Structure
+ </td>
+ <td>
+ <p>
+ Layers<br />
+ Pipes and filters<br />
+ Blackboard
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Distributed systems
+ </td>
+ <td>
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Interactive systems
+ </td>
+ <td>
+ Model view controller<br />
+ Presentation abstraction control
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p>
+ Adaptable systems
+ </p>
+ </td>
+ <td>
+ <p>
+ Reflection<br />
+ Micro kernel
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
+</p>
+<ul>
+ <li>
+ Creational
+ </li>
+ <li>
+ Structural
+ </li>
+ <li>
+ Behavioral
+ </li>
+</ul>
+<h4>
+ Pattern languages
+</h4>
+<p>
+ In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
+ The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
+ allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
+ buildings. Alexander explains that when using a pattern language:
+</p>
+<blockquote>
+ <p>
+ We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
+ always from the ones that create structure to the ones which then embellish those structures, and then to those
+ that embellish the embellishments.
+ </p>
+</blockquote>
+<p>
+ In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
+ initial context, would always lead to good design.&nbsp; Alexander&nbsp;states:
+</p>
+<blockquote>
+ <p>
+ Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of
+ arrangement, but shows us how to construct arrangements — as many as we want — which satisfies the rules.
+ </p>
+</blockquote>
+<p>
+ In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
+ The sequential application of patterns finds application in software design processes, both waterfall and iterative,
+ that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
+ a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
+ application of patterns, rather than a generative pattern language.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/refactoring.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/refactoring.xmi
new file mode 100644
index 0000000..ae3e83c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/refactoring.xmi
@@ -0,0 +1,44 @@
+<?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="-fj_9xjbrpaYNSETyCz5yJg" name="refactoring,_Poc7IPDzEdqYgerqi84oCA" guid="-fj_9xjbrpaYNSETyCz5yJg" changeDate="2006-08-21T14:03:50.568-0700">
+ <mainDescription><p>
+ Refactoring is a disciplined way to restructure code&nbsp;when small changes are made to&nbsp;the code to improve its
+ design.&nbsp; An important aspect of a refactoring is that it improves the design while not changing the semantics
+ of&nbsp;the design; a refactoring neither adds nor removes functionality.
+</p>
+<p>
+ Refactoring enables you to evolve&nbsp;the code slowly over time, to take an iterative and incremental approach to
+ implementation.
+</p>
+<p>
+ These are the types of refactoring:
+</p>
+<ol>
+ <li>
+ Code refactoring.&nbsp; Often referred to simply as refactoring, this is the refactoring of programming source
+ code.&nbsp; Examples of code refactorings include Rename Method, Encapsulate Field, Extract Class, Introduce
+ Assertion, and Pushdown Method.
+ </li>
+ <li>
+ Database refactoring.&nbsp; A database refactoring is a simple change to a database schema that improves its design
+ while retaining both its behavioral and informational semantics.&nbsp; Examples of database refactorings include
+ Rename Column, Split Table, Move Method to Database, Replace LOB with Table, Introduce Column Constraint, and Use
+ Official Data Source.
+ </li>
+ <li>
+ User interface (UI) refactoring.&nbsp; A UI refactoring is a simple change to the UI which retains its
+ semantics.&nbsp; Examples of UI refactorings include Align Entry Fields, Apply Common Button Size, Apply Common
+ Font, Indicate Format, Reword in Active Voice, and Increase Color Contrast.
+ </li>
+</ol>
+<p>
+ These are suggested resources:
+</p>
+<ul>
+ <li>
+ <a href="http://www.refactoring.com" target="_blank" >http://www.refactoring.com</a>
+ </li>
+ <li>
+ <a href="http://www.agiledata.org/essays/databaseRefactoring.html" >http://www.agiledata.org/essays/databaseRefactoring.html</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/requirement_attributes.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/requirement_attributes.xmi
new file mode 100644
index 0000000..a9ed8f5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/requirement_attributes.xmi
@@ -0,0 +1,67 @@
+<?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" epf:version="1.0.0" xmi:id="-fCBrf_5JlrmuKgyrCaKGOA" name="requirement_attributes_1,_VQ268O0KEdqHTdbLTmC5IQ" guid="-fCBrf_5JlrmuKgyrCaKGOA" authors="Chris Sibbald" changeDate="2006-09-20T14:41:34.651-0400" version="0.2">
+ <mainDescription><p>
+ Attributes are a very important source of requirements information. Just as every person has attributes (age, hair
+ color, gender), each requirement has a source, a relative importance, and time it was created. Attributes do more than
+ simply clarify a&nbsp;requirement.&nbsp; If created properly, they can yield significant information about the state of
+ the system. Just as you can run a database query to find all men with brown hair over age 30, given our human example,
+ you can run queries on the status of requirements to find&nbsp;all high-priority requirements from the customer in the
+ last 30 days. <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</p>
+<h4>
+ Examples of attributes
+</h4>
+<p>
+ Listed below is a partial list of some common attributes and a brief description of their meaning. Some attributes are
+ best described as a number, date, Boolean (true or false) or a text field for entering free format comments. Other
+ attributes can be expressed as lists. For instance, priority type is a list of high, medium, and low; Weekday is a list
+ which includes Monday, Tuesday, and so on.
+</p>
+<p>
+ <em>Source</em> - Person, document or other origin of a given requirement.&nbsp; This is&nbsp;useful&nbsp;for
+ determining whom to call for questions or for grouping&nbsp;requirements according to the person making the demands.
+</p>
+<p>
+ <em>Priority</em> - Statement of relative importance of the requirement, either to the system (mandatory, critical,
+ optional) or to other requirements (high, medium, low). It is good to track the mandatory or high-priority
+ items&nbsp;as an indication of how well the system will meet the greatest needs or for compliance-related metrics.
+</p>
+<p>
+ <em>Assigned to</em> - Who in the organization is responsible for making sure the requirement is met (person's name or
+ organizational name).
+</p>
+<p>
+ <em>Comments</em> - Reviewer's or writer's comments on a requirement.
+</p>
+<p>
+ <em>Difficulty</em> - An indication of the level of effort needed or how hard it will be to implement the requirement
+ (high, medium, low).
+</p>
+<p>
+ <em>Status</em> - Degree of completeness (completed, partial, not started).
+</p>
+<p>
+ <em>Risk</em> - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium,
+ low or the integers one through ten.
+</p>
+<p>
+ <em>Due By</em> - Date the requirement must be provided.
+</p>
+<p>
+ <em>Method of verification</em> - Qualification type to be used to verify that a requirement has been met: analysis,
+ demonstration, inspection, test, and walkthrough.
+</p>
+<p>
+ <em>Level of Test</em> - Describes the verification lifecycle stage at which the requirement is determined to be met:
+ unit test, component, system or product.
+</p>
+<p>
+ <em>Subsystem Allocation</em> - Name of system or subsystem a requirement is to be assigned to (for instance, flight
+ control module, wing assembly, passenger cabin).
+</p>
+<p>
+ <em>Test Number</em> - Identification of a specific test or other method of verification.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/requirements.xmi
new file mode 100644
index 0000000..e49ae58
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/requirements.xmi
@@ -0,0 +1,70 @@
+<?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" epf:version="1.0.0" xmi:id="_eUfzwMMyEdmdo9HxCRR_Gw" name="requirements,_0Wh-sMlgEdmt3adZL5Dmdw" guid="_eUfzwMMyEdmdo9HxCRR_Gw" changeDate="2006-12-21T11:21:47.640-0500" version="1.0.0">
+ <mainDescription><p>
+ Requirements are the project team's to-do list.
+</p>
+<p align="left">
+ Requirements define what is needed and focus the project team. They are the primary method used to communicate the
+ goals of the project to everyone on the team.
+</p>
+<div class="O" v:shape="_x0000_s1026">
+ <div style="mso-line-spacing: '100 30 0'">
+ Requirements define:
+ </div>
+</div>
+<ul>
+ <li>
+ What the&nbsp;stakeholders&nbsp;need; and
+ </li>
+ <li>
+ What the system must include to satisfy the stakeholder needs.
+ </li>
+</ul>
+<p align="left">
+ Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning
+ work, verifying and validating the system (acceptance), and managing the scope of the project.
+</p>
+<p align="left">
+ Requirements may take different forms, including Use Cases and Scenarios, unstructured text, structured text, or a
+ combination, and they may be stated at different levels of granularity. At the highest level of granularity,&nbsp;<a
+ class="elementLink" href="./../../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">Feature</a>s define the services that the system must provide to solve the customer's
+ problem. These are captured as structured or unstructured text in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>. At the next level of granularity, Use Cases define the
+ functionality that the system must provide to&nbsp;deliver the required features. These are captured&nbsp;as Use Cases
+ (see <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>)&nbsp;that describe the sequence of actions performed by the
+ system to yield an observable result of value.
+</p>
+<p>
+ A system must perform according to the behavior that Use Cases specify. However, there are system requirements that do
+ not represent a specific behavior:
+</p>
+<ul>
+ <li>
+ Legal and regulatory requirements, as well as application standards
+ </li>
+ <li>
+ Quality attributes of the system to be built, including usability, reliability, performance, and supportability
+ requirements
+ </li>
+ <li>
+ Interface requirements to be able to communicate with external systems
+ </li>
+ <li>
+ Design constraints, such as those for operating systems and environments and for compatibility with other software
+ </li>
+</ul>
+<p>
+ These quality requirements are often referred to as <strong>non-functional</strong> requirements.
+</p>
+<p>
+ Quality requirements that apply to the system as a whole are captured as structured text in <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>.&nbsp; Quality requirements that are closely
+ associated with a particular Use Case are often captured in the Use Case itself to simplify review, understanding, and
+ maintenance.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF
new file mode 100644
index 0000000..c3428b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ATMUCdiagram.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG
new file mode 100644
index 0000000..a1b1f17
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ArchMechanismsStatemachine.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/EBCDiagram.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/EBCDiagram.JPG
new file mode 100644
index 0000000..67970fe
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/EBCDiagram.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/co_phas1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/co_phas1.gif
new file mode 100644
index 0000000..919e282
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/co_phas1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/extend1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/extend1.gif
new file mode 100644
index 0000000..586ded0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/extend1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/im_uc.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/im_uc.gif
new file mode 100644
index 0000000..f271c09
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/im_uc.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/include1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/include1.gif
new file mode 100644
index 0000000..aa80996
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/include1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/iteration_1.GIF b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/iteration_1.GIF
new file mode 100644
index 0000000..1f1a19b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/iteration_1.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_actg2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_actg2.gif
new file mode 100644
index 0000000..547c9ae
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_actg2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_acto2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_acto2.gif
new file mode 100644
index 0000000..29ede3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_acto2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_acto3.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_acto3.gif
new file mode 100644
index 0000000..43fbf21
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_acto3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_ucmo2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_ucmo2.gif
new file mode 100644
index 0000000..19e278e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/md_ucmo2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/testFirstDesign.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/testFirstDesign.jpg
new file mode 100644
index 0000000..6da383c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/testFirstDesign.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucgen1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucgen1.gif
new file mode 100644
index 0000000..cd77583
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucgen1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucmex3.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucmex3.gif
new file mode 100644
index 0000000..137ba23
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucmex3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucprepst.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucprepst.gif
new file mode 100644
index 0000000..5f9e869
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucprepst.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucstrct.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucstrct.gif
new file mode 100644
index 0000000..4458bcb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/ucstrct.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/visual.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/visual.gif
new file mode 100644
index 0000000..6f4674c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/resources/visual.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/risk.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/risk.xmi
new file mode 100644
index 0000000..4db93e7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/risk.xmi
@@ -0,0 +1,96 @@
+<?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" epf:version="1.0.0" xmi:id="_u6enMMM1EdmSIPI87WLu3g" name="risk,_0bsLgMlgEdmt3adZL5Dmdw" guid="_u6enMMM1EdmSIPI87WLu3g" changeDate="2006-10-31T11:18:15.095-0800">
+ <mainDescription><h3>
+ What is a Risk?
+</h3>
+<p>
+ Many decisions are driven by risk mitigation&nbsp;in well managed projects. You are trying to mitigate or tackle the
+ most critical risks as early as possible in the project. In order to achieve this you need to get a good grip on the
+ risks the project is faced with, and have clear strategies on how to mitigate or deal with them.
+</p>
+<p>
+ In everyday life a risk is an exposure to loss or injury; a factor, thing, element, or course involving uncertain
+ danger.&nbsp;Similarly, in&nbsp;software development a risk is something that can compromise the success of a project.
+ Examples of potential sources of risk in software development are listed below (see [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>] for more details):
+</p>
+<ul>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Design
+ </li>
+ <li>
+ Development process
+ </li>
+ <li>
+ Work environment
+ </li>
+ <li>
+ Resources
+ </li>
+ <li>
+ Contract
+ </li>
+ <li>
+ Project interdependencies
+ </li>
+ <li>
+ etc.
+ </li>
+</ul>
+<p>
+ Risks can be seen as opportunities. If there are benefits associated to an opportunity, then certain degrees of risk
+ must be taken&nbsp;for a&nbsp;project to be&nbsp;successful [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>].
+</p>
+<h3>
+ Risk Attributes
+</h3>
+<p>
+ You can record as much information as you like or need about your risks, you will find below a list of common risk
+ attributes.
+</p>
+<ul>
+ <li>
+ <strong>Risk Description:</strong> A description of the risk detailing the impact for the project if this risk
+ becomes a problem (i.e. it becomes a reality).
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Type:</strong> Used to classify the risk as:
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <strong>Direct risk</strong>: a risk that the project has a large degree of control over.
+ </li>
+ <li>
+ <strong>Indirect risk</strong>: a risk with little or no project control.
+ </li>
+ </ul>
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Probability</strong> (of occurence): how many chances do we have that this risk will become
+ a&nbsp;problem or an issue, This is usually represented as a scale of values (for example: High, Medium, Low).
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Impact</strong> (level): if this risk become an problem what will be the impact&nbsp;on
+ the&nbsp;project. This is not the actual description of the impact but the level of impact. As the risk
+ probability, it is usually represented as a scale.&nbsp;This&nbsp;attribute is&nbsp;also sometimes called the
+ <strong>severity</strong> of the risk.
+ </li>
+</ul>
+<ul>
+ <li>
+ <strong>Risk Magnitude</strong>: To be able to rank and to define which ones need to be mitigate first,&nbsp;the
+ <strong>Risk Probability&nbsp;</strong> and <strong>Risk Impact</strong> attributes are often combined in a
+ single&nbsp;<strong>Risk</strong> <strong>Magnitude</strong> indicator represented as a scale similar to the
+ combined attributes.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/risk_management.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/risk_management.xmi
new file mode 100644
index 0000000..d4431be
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/risk_management.xmi
@@ -0,0 +1,83 @@
+<?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" epf:version="1.0.0" xmi:id="-HhGIkAPjHSIxnPzI3cyDnQ" name="new_concept,_VNxL4ACsEdu8m4dIntu6jA" guid="-HhGIkAPjHSIxnPzI3cyDnQ" changeDate="2006-10-31T11:44:13.295-0800">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Every project contains some measure of uncertainty. The role of <strong>Risk Management</strong> is to deal with this
+ uncertainty to try to understand its&nbsp;potential influence on the project. Project risks may be seen as threats or
+ opportunities. The former means the risk should be mitigated (see risk management strategies below) where the latter
+ means that&nbsp;taking a&nbsp;calculated risk may bring, for example, competitive advantage for a product or
+ organization [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>].
+</p>
+<p>
+ Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. A
+ common mistake is to identify risks only at the beginning of the project and then only track the status of these
+ initial risks. The risk list should be revisited weekly, or as a minimum once per iteration, to add any newly
+ discovered risk.
+</p>
+<h3>
+ Risks Prioritization
+</h3>
+<p>
+ A good approach for prioritizing risks is to have an attribute called risk magnitude, a combination of the risk
+ probability and the risk impact. Each iteration provides a chance&nbsp;for better understanding of stakeholder needs,
+ the team capabilities, the technology at hand, and so on. Capture, quantify&nbsp;and prioritize risks as they arise.
+ High magnitude risks are&nbsp;attacked first, thus&nbsp;improving the chances of project success and minimizing
+ uncertainty. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/templates/risk_list,_MIUO0C8FEduzydamRseoUw.html" guid="_MIUO0C8FEduzydamRseoUw">Template: Risk List</a>&nbsp;for more information.
+</p>
+<h3>
+ Risk Management Strategies
+</h3>
+<p>
+ Once you have chosen a set of risks to focus on, choose a mitigation strategy, as described below. Then, identify and
+ assign tasks to apply the strategy to the given risk. Follow up regularly on risk-mitigation actions. Try another
+ strategy if your chosen strategy does not reduce the magnitude of a risk.
+</p>
+<p>
+ Common mitigation strategies are:
+</p>
+<ul>
+ <li>
+ Risk avoidance: reorganize the project so that it cannot be affected by that risk.
+ <ul>
+ <li>
+ For example: you need to use a new framework. A risk avoidance strategy could be to drop this new framework
+ and using another one that is already understood by the team.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk transfer: reorganize the project so that someone or something else bears the risk.
+ <ul>
+ <li>
+ For example: the application you are developing needs to communicate with a legacy system. A risk transfer
+ strategy&nbsp;would make the legacy support team responsible of providing the APIs to access the legacy
+ system.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk mitigation: define a mitigation plan to&nbsp;reduce the probability or the impact of the risk.
+ <ul>
+ <li>
+ For example: you need to use a new middleware. A risk mitigation strategy could be to build a prototype
+ using this new middleware to validate that&nbsp;it will provide the features you need for your
+ application.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ Risk acceptance: decide to live with the risk, and define a contingency plan.
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ For example: your integrator is the only one who knows how to integrate the different components of your
+ application. A contingency plan could be to identify a resource on another project that you could bring on
+ if your integrator is sick, leaves the company, etc.
+ </li>
+ </ul>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/software_architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/software_architecture.xmi
new file mode 100644
index 0000000..873ede0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/software_architecture.xmi
@@ -0,0 +1,210 @@
+<?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" epf:version="1.0.0" xmi:id="-UQ_e8kozIP11Xu008RJd-A" name="new_concept,__O7tAMVvEduLYZUGfgZrkQ" guid="-UQ_e8kozIP11Xu008RJd-A" changeDate="2007-02-26T09:06:26.812+0000">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially
+ with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line
+ between design and architecture-architecture is one aspect of design that concentrates on some specific features.
+</p>
+<p>
+ In An Introduction to Software Architecture, David Garlan and Mary Shaw suggest that software architecture is a level
+ of design concerned with issues: "Beyond the algorithms and data structures of the computation; designing and
+ specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization
+ and global control structure; protocols for communication, synchronization, and data access; assignment of
+ functionality to design elements; physical distribution; composition of design elements; scaling and performance; and
+ selection among design alternatives." <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[GAR93]</a>
+</p>
+<p>
+ But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the
+ highest-level concept of a system in its environment" <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[IEP1471]</a>. It also encompasses the "fit" with system integrity, with economical
+ constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into
+ consideration the system as a whole in its user environment and its development environment - an outward focus.
+</p>
+<p>
+ In OpenUP, the architecture of a software system (at a given point) is the organization or structure of the system's
+ significant components interacting through interfaces, with components composed of successively smaller components and
+ interfaces.
+</p>
+<h3>
+ Architecture Description
+</h3>
+<p>
+ To speak and reason about software architecture, you must first define an architectural representation, a way of
+ describing important aspects of an architecture. In OpenUP, this description is captured in the <a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
+</p>
+<h3>
+ Architectural Views
+</h3>
+<p>
+ We have chosen to represent software architecture in multiple architectural views. Each architectural view addresses
+ some specific set of concerns, specific to stakeholders in the development process: users, designers, managers, system
+ engineers, maintainers, and so on.
+</p>
+<p>
+ The views capture the major structural design decisions by showing how the software architecture is decomposed into
+ components, and how components are connected by connectors to produce useful forms <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the Requirements, functional, and
+ supplementary, and other constraints. But these choices in turn put further constraints on the requirements and on
+ future design decisions at a lower level.
+</p>
+<h3>
+ Architectural Focus
+</h3>
+<p>
+ Although the views above could represent the whole design of a system, the architecture concerns itself only with some
+ specific aspects:
+</p>
+<ul>
+ <li>
+ The structure of the model - the organizational patterns, for example, Layering.
+ </li>
+ <li>
+ The essential elements - critical use cases, main classes, common mechanisms, and so on, as opposed to all the
+ elements present in the model.
+ </li>
+ <li>
+ A few key scenarios showing the main control flows throughout the system.
+ </li>
+ <li>
+ The services, to capture modularity, optional features, product-line aspects.
+ </li>
+</ul>
+<p>
+ In essence, architectural views are abstractions, or simplifications, of the entire design, in which important
+ characteristics are made more visible by leaving details aside. These characteristics are important when reasoning
+ about:
+</p>
+<ul>
+ <li>
+ System evolution-going to the next development cycle.
+ </li>
+ <li>
+ Reuse of the architecture, or parts of it, in the context of a product line.
+ </li>
+ <li>
+ Assessment of supplementary qualities, such as performance, availability, portability, and safety.
+ </li>
+ <li>
+ Assignment of development work to teams or subcontractors.
+ </li>
+ <li>
+ Decisions about including off-the-shelf components.
+ </li>
+ <li>
+ Insertion in a wider system.&nbsp;
+ </li>
+</ul>
+<h3>
+ Architectural Patterns
+</h3>
+<p>
+ Architectural patterns are ready-made forms that solve recurring architectural problems. An architectural framework or
+ an architectural infrastructure (middleware) is a set of components on which you can build a certain kind of
+ architecture. Many of the major architectural difficulties should be resolved in the framework or in the
+ infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.
+</p>
+<h4>
+ Examples of Architectural Patterns
+</h4>
+<p>
+ <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> groups architectural patterns according to the characteristics of the
+ systems in which they are most applicable, with one category dealing with more general structuring issues. The table
+ shows the categories presented in <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> and the patterns they contain.
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th id="col1" width="50%">
+ Category
+ </th>
+ <th id="col2" width="50%">
+ Pattern
+ </th>
+ </tr>
+ <tr>
+ <th id="row2" align="left" headers="col1" width="50%" rowspan="3">
+ Structure
+ </th>
+ <td headers="row2 col2" width="50%">
+ Layers
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Pipes and Filters
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Blackboard
+ </td>
+ </tr>
+ <tr>
+ <th id="row3" align="left" headers="col1" width="50%">
+ Distributed Systems
+ </th>
+ <td headers="row3 col2" width="50%">
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <th id="row4" align="left" headers="col1" width="50%" rowspan="2">
+ Interactive Systems
+ </th>
+ <td headers="row4 col2" width="50%">
+ Model-View-Controller
+ </td>
+ </tr>
+ <tr>
+ <td headers="row4 col2" width="50%">
+ Presentation-Abstraction-Control
+ </td>
+ </tr>
+ <tr>
+ <th id="row5" align="left" headers="col1" width="50%" rowspan="2">
+ Adaptable Systems
+ </th>
+ <td headers="row5 col2" width="50%">
+ Reflection
+ </td>
+ </tr>
+ <tr>
+ <td headers="row5 col2" width="50%">
+ Microkernel
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ Refer to <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> for a complete description of these patterns.
+</p>
+<h3>
+ <a id="Architectural Style" name="Architectural Style">Architectural Style</a>
+</h3>
+<p>
+ A software architecture, or only an architectural view, may have an attribute called <b>architectural style</b>, which
+ reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The
+ style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building
+ blocks.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/supporting_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/supporting_requirements.xmi
new file mode 100644
index 0000000..4530903
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/supporting_requirements.xmi
@@ -0,0 +1,101 @@
+<?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" epf:version="1.0.0" xmi:id="-3SXuKijeVOZalgLPgWRyFA" name="supporting_requirements_1,_VXZ5wO0IEdqHTdbLTmC5IQ" guid="-3SXuKijeVOZalgLPgWRyFA" authors="Chris Sibbald" changeDate="2006-12-21T12:31:36.206-0500" version="0.2">
+ <mainDescription><h3>
+ Definition
+</h3>
+<p>
+ Supporting requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
+ usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral
+ requirements artifacts such as use-cases.
+</p>
+<h3>
+ Supporting Requirements Categories
+</h3>
+<p>
+ Supporting requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability, Performance,
+ Supportability + constraints). Constraints&nbsp;include design, implementation, interfaces, physical constraints, and
+ business rules. A description of each of these types of requirements follows.
+</p>
+<p>
+ Supporting requirements and Use Cases, together, define the requirements of the system. These requirements support the
+ features listed in the Vision statement. Each requirement should&nbsp;support at least one feature, and each feature
+ should be supported by at least one to requirement.
+</p>
+<p>
+ In general, <strong>functional</strong> requirements describe behavior and are captured in&nbsp;Use Cases (see&nbsp;<a
+ class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>). <strong>Non-functional</strong> requirements are captured in
+ the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. However, nonfunctional requirements that are
+ closely associated with a particular Use Case are often captured within the Use Case itself to simplify communication
+ and maintenance.&nbsp; Similarly, there are global, or system-wide, functional requirements that are often captured
+ among the supporting requirements for the same reasons.&nbsp;
+</p>
+<h4>
+ Functional requirements
+</h4>
+<p>
+ Functionality requirements include all the overarching, system wide functional requirements. These functional
+ requirements represent the main system features that are familiar within the business domain or technically oriented
+ requirements such as auditing, licensing, localization, mail, online help, printing, reporting, security, system
+ management, or workflow.
+</p>
+<h4>
+ Usability requirements
+</h4>
+<p>
+ Usability requirements include requirements based on human factors and user interface issues such as accessibility,
+ interface aesthetics, and consistency within the user interface.
+</p>
+<h4>
+ Reliability requirements
+</h4>
+<p>
+ Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or
+ recoverability of the system from shut-down failure.
+</p>
+<h4>
+ Performance requirements
+</h4>
+<p>
+ Performance requirements address concerns such as throughput of information through the system, system response time
+ and resource usage.
+</p>
+<h4>
+ Supportability requirements
+</h4>
+<p>
+ Supportability requirements include requirements such as compatibility and the abilities to test, adapt, maintain,
+ configure, install, scale, localize, and so on.
+</p>
+<h4>
+ + Constraints
+</h4>
+<p>
+ The <strong>+</strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,
+ interfaces, physical constraints, and business rules:
+</p>
+<ul>
+ <li>
+ <strong>Design constraints</strong> limit the design and state requirements on the approach that should be taken in
+ developing the system.
+ </li>
+ <li>
+ <strong>Implementation constraints</strong> put limits on coding or construction (required standards, languages,
+ tools, or platform)
+ </li>
+ <li>
+ <strong>Interface constraints</strong> are requirements to interact with external systems, describing protocols or
+ the nature of the information that is passed across that interface.
+ </li>
+ <li>
+ <strong>Physical constraints</strong> affect the hardware or packaging housing the system (shape, size, and
+ weight).
+ </li>
+ <li>
+ <strong>Business rules</strong> are policies or decisions that govern how the business operates. They may constrain
+ the steps described in the Use Case flow.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/test_first_design.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/test_first_design.xmi
new file mode 100644
index 0000000..c5df2b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/test_first_design.xmi
@@ -0,0 +1,83 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_Hg5UUMPbEdmbOvqy4O0adg" name="test_first_design,_0Y6kUMlgEdmt3adZL5Dmdw" guid="_Hg5UUMPbEdmbOvqy4O0adg" changeDate="2006-08-15T17:49:28.248-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ With Test-First Design (TFD) you do detailed design in a just-in-time (JIT) manner&nbsp;via writing a single test
+ before writing just enough production code to fulfill that test.&nbsp; When you have new functionality to add to your
+ system, perform the following steps:
+</p>
+<ol>
+ <li>
+ <strong>Quickly add a test</strong>.&nbsp; You need just enough code to fail.&nbsp;
+ </li>
+ <li>
+ <strong>Run your tests</strong>.&nbsp; You will&nbsp;typically run the complete test suite, although for sake of
+ speed you may decide to run only a subset.&nbsp; The goal is&nbsp;to ensure that the new test does in fact
+ fail.&nbsp;
+ </li>
+ <li>
+ <strong>Update your production code</strong>.&nbsp;&nbsp;The goal is to add just enough functionality so that
+ your&nbsp;code&nbsp;passes the new test.&nbsp;
+ </li>
+ <li>
+ <strong>Run your test suite&nbsp;again</strong>.&nbsp; If they tests fail you need to update your functional code
+ and retest.&nbsp; Once the tests pass, start over.&nbsp;
+ </li>
+</ol>
+<br />
+<p>
+ <img height="600" alt="Test First Design Flow" src="./resources/testFirstDesign.jpg" width="294" />&nbsp;
+</p>
+<h4>
+ Why TFD?
+</h4>
+<p>
+ A significant advantage of TFD is that it enables you to take small steps when writing software, which is not only
+ safer it is also far more productive than writing code&nbsp;in large steps.<span style="mso-spacerun: yes">&nbsp;</span> For example, assume you add some new functional code, compile, and test
+ it.<span style="mso-spacerun: yes">&nbsp;</span> Chances are pretty good that your tests will be broken by defects that
+ exist in the new code.<span style="mso-spacerun: yes">&nbsp;</span> It is much easier to find, and then fix, those
+ defects if you've written five new lines of code than in fifty lines. The implication is that the faster your compiler
+ and regression test suite, the more attractive it is to proceed in smaller and smaller steps.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p>
+ There are three other common testing strategies (in order of effectiveness).
+</p>
+<ol>
+ <li>
+ <strong>Write&nbsp;several tests first</strong>.&nbsp; This is a variant of TFD where you write more than one test
+ before writing just enough production code to fulfill those tests.&nbsp; The advantage is that you don't need to
+ build your system as often,&nbsp;potentially saving time.&nbsp; It&nbsp;has the disadvantage that you will write
+ more&nbsp;production code at once, increasing the difficulty of finding any new bugs that you do introduce.
+ </li>
+ <li>
+ <strong>Test after the fact</strong>.&nbsp; With this approach you write some production code then you write enough
+ testing code to validate it.&nbsp; This has the advantage that you're at least still validating the code but has
+ the disadvantage that you lose the design benefit inherent in writing the testing code first.
+ </li>
+ <li>
+ <strong>Don't test at all</strong>.&nbsp; This is a really bad idea.
+ </li>
+</ol>
+<br />
+<h3>
+ Good Things to Know
+</h3>
+<p>
+ 1. An underlying assumption of TDD is that you have a unit-testing framework available to you.<span style="mso-spacerun: yes">&nbsp;</span> Agile software developers often use the xUnit family of open source tools, such
+ as <a href="http://www.junit.org/" ><strong>JUnit</strong></a> or <a href="http://www.vbunit.org/" ><strong>VBUnit</strong></a>, although commercial tools are
+ also viable options.<span style="mso-spacerun: yes">&nbsp;&nbsp;</span><span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p>
+ 2. Test-Driven Design (TDD) = TFD + <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>
+</p>
+<p>
+ 3. TFD/TDD is commonly used with object-oriented business code, although you can also take this approach with
+ procedural code, user-interface code, and your database code if you choose to.
+</p>
+<p>
+ 4. A more thorough discussion of TFD and TDD is presented at <a href="http://www.agiledata.org/essays/tdd.html" target="_blank" >Introduction to Test Driven Development (TDD)</a>.
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/test_ideas.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/test_ideas.xmi
new file mode 100644
index 0000000..e63ea87
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/test_ideas.xmi
@@ -0,0 +1,37 @@
+<?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="_uqL2gMM3EdmSIPI87WLu3g" name="test_ideas,_0jnYcMlgEdmt3adZL5Dmdw" guid="_uqL2gMM3EdmSIPI87WLu3g" changeDate="2006-07-20T15:10:39.401-0700">
+ <mainDescription><p>
+ <strong>Test Ideas List</strong> - A list of brief statements identifying tests that are potentially useful to conduct.
+</p>
+<p>
+ <strong>Test Ideas Catalog</strong> - A catalog of common faults and mistakes done when developing software.
+</p>
+<ul>
+ <li>
+ Test Ideas will describe any of the elements of an executable test.&nbsp;
+ </li>
+ <li>
+ Test ideas ensure the important ideas are not forgotten and are detailed later in test cases.&nbsp;&nbsp;
+ </li>
+ <li>
+ Test Ideas are to be captured at a less-specific level in an intermediate form.
+ </li>
+ <li>
+ Test ideas are more reviewable and understandable then complete tests.&nbsp; Making the reasoning behind the test
+ idea clearer.&nbsp;
+ </li>
+ <li>
+ Test ideas support more powerful test, by not constraining the tester.&nbsp; Making it easier to create tests that
+ validate more then just the defined requirements.
+ </li>
+ <li>
+ Test Ideas are often based on explicit and implicit fault modules, to include but not limited to Booleans,
+ boundaries and method calls.&nbsp; Test Ideas Lists will contain test ideas from many faults models derived for one
+ or many work products.
+ </li>
+</ul>
+<p>
+ Creating test ideas before testing for review and inspection of design work products assists in discovering design or
+ analysis errors.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/traceability.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/traceability.xmi
new file mode 100644
index 0000000..d4ec53b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/traceability.xmi
@@ -0,0 +1,62 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-TksCtMgc0b4QqzwzniGvIw" name="traceability_1,_eYtQQO0KEdqHTdbLTmC5IQ" guid="-TksCtMgc0b4QqzwzniGvIw" authors="Chris Sibbald" changeDate="2006-05-01T15:37:44.378-0700" changeDescription="Added concept in accordance with Feb 23, 2006 minutes of RM SIG meeting." version="0.1">
+ <mainDescription><p align="left"> Traceability is about understanding how high-level requirements
+ (objectives, goals, aims, aspirations, expectations, needs) are transformed
+ into low-level requirements, how they are implemented, and how they are verified.
+</p>
+<p>
+ Using traceability can provide the following benefits <a class="elementlinkwithusertext"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html#HUL05"
+ guid="_9ToeIB83Edqsvps02rpOOg">[HUL05]</a>:
+</p>
+<ul>
+
+ <li> <strong>Greater confidence in meeting objectives </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Establishing traceability engenders greater reflection on how objectives
+ are satisfied.&nbsp; Traceability permits coverage analysis to ensure that
+ everything you have done everything that you agreed to do and only what you
+ agreed to do.</p>
+</blockquote>
+<ul>
+
+ <li> <strong>Ability to assess the impact of change </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p> Traceability permits various forms of impact analysis that can be used to
+ assess the impact of a proposed change on the cost, schedule, and technical
+ aspects of the project.</p>
+</blockquote>
+<ul>
+
+ <li><strong> Improved accountability </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Traceability provides great clarity about how work contributes to the
+ whole. </p>
+</blockquote>
+<ul>
+ <li><strong> Ability to track progress </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> It is notoriously difficult to measure progress when all that you are doing
+ is creating and revising artifacts. Traceability processes allow precise measures
+ of progress, such as: Is there a design artifact for each requirement? Is
+ there a test case for each requirement?. </p>
+</blockquote>
+<ul>
+
+ <li><strong> Ability to balance cost against benefit </strong></li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+
+ <p> Relating product components to the requirements allows you to compare benefits
+ to costs. </p>
+</blockquote>
+<br dir="ltr" />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/transition_phase.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/transition_phase.xmi
new file mode 100644
index 0000000..f3da272
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/transition_phase.xmi
@@ -0,0 +1,97 @@
+<?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" epf:version="1.0.0" xmi:id="-FrUmsKsGW4bnNmb9uaNOkg" name=",__ca5UBOMEduCNqgZdt_OaA" guid="-FrUmsKsGW4bnNmb9uaNOkg" changeDate="2006-09-27T16:29:45.049-0700" version="1.0.0">
+ <mainDescription><p>
+ The purpose in this phase is to ensure that the software is ready for delivery to users.
+</p>
+<p>
+ There are objectives for the Transition phase that help you to&nbsp;fine-tune functionality, performance, and overall
+ quality of the beta product from the end of&nbsp;the previous phase <a class="elementlinkwithusertext" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Beta test to validate that user expectations are met.</strong> This typically requires some fine-tuning
+ activities, such as bug-fixing and making enhancements for performance and usability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Achieve stakeholder concurrence that deployment is complete.</strong> This may involve various levels
+ of tests for product acceptance, including formal and informal tests and beta tests.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Improve future project performance through lessons learned.</strong> Document lessons learned and
+ improve the process and tool environment for the project.
+ </p>
+ </li>
+</ol>
+<p>
+ The following table summarizes the&nbsp;Transition phase objectives and&nbsp;what activities address each objective:
+</p>
+<p align="center">
+ <strong>Transition phase objectives and activities</strong>
+</p>
+<table cellspacing="0" cellpadding="0" width="648" align="center" border="1">
+ <tbody>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ <p style="TEXT-ALIGN: justify">
+ <b>Phase objectives</b>
+ </p>
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <p style="TEXT-ALIGN: justify">
+ <b>Activities that address objectives</b>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300" height="62">
+ Beta test to validate that user expectations are met
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../ongoing_tasks,_0qxwYclgEdmt3adZL5Dmdw.html" guid="_0qxwYclgEdmt3adZL5Dmdw">Ongoing Tasks</a><br />
+ <a class="elementLinkWithUserText" href="./../../../develop_requirement_within_context,_0DMlYPinEdmugcVr9AdHjQ.html" guid="_0DMlYPinEdmugcVr9AdHjQ">Develop Solution (for requirement)(within context)</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0qrpwslgEdmt3adZL5Dmdw.html" guid="_0qrpwslgEdmt3adZL5Dmdw">Validate Build</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Achieve stakeholder concurrence that deployment is complete
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a><br />
+ <a class="elementLinkWithUserText" href="./../../../validate_build,_0qrpwslgEdmt3adZL5Dmdw.html" guid="_0qrpwslgEdmt3adZL5Dmdw">Validate Build</a>
+ </td>
+ </tr>
+ <tr>
+ <td class="Normal" valign="top" width="300">
+ Improve future project performance through lessons learned
+ </td>
+ <td class="Normal" valign="top" width="348">
+ <a class="elementLinkWithUserText" href="./../../../manage_iteration,_0rWYIslgEdmt3adZL5Dmdw.html" guid="_0rWYIslgEdmt3adZL5Dmdw">Manage Iteration</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<h4>
+ <br />
+ Key considerations<br />
+</h4>
+<p>
+ The Transition phase can include running old and new systems in parallel, migrating data, training users, and adjusting
+ business processes.
+</p>
+<p>
+ The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily
+ minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to
+ make the business transition from using the old system to using the new system.
+</p>
+<p>
+ When the Transition phase objectives are met, the project is in position to be closed.&nbsp;For some products, the end
+ of the current project lifecycle may coincide with the beginning of the next lifecycle, leading to the next generation
+ of the same product.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/types_of_test.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/types_of_test.xmi
new file mode 100644
index 0000000..9fab0f1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/types_of_test.xmi
@@ -0,0 +1,148 @@
+<?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" epf:version="1.0.0" xmi:id="_y-_PIMPdEdmbOvqy4O0adg" name="types_of_test,_0aJ6cMlgEdmt3adZL5Dmdw" guid="_y-_PIMPdEdmbOvqy4O0adg" changeDate="2006-09-20T15:37:14.071-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ There is much more to testing computer software than simply evaluating the functions, interface, and response-time
+ characteristics of a target-of-test.&nbsp;Additional tests must focus on characteristics and attributes, such as the
+ target-of-test.
+</p>
+<ul>
+ <li>
+ integrity (resistance to failure)
+ </li>
+ <li>
+ ability to be installed and executed on different platforms
+ </li>
+ <li>
+ ability to handle many requests simultaneously
+ </li>
+</ul>
+<p>
+ To achieve this, many different types of tests are implemented and executed.&nbsp;Each test type has a specific
+ objective and support technique.&nbsp;Each technique focuses on testing one or more characteristics or attributes of
+ the target-of-test.
+</p>
+<p>
+ The following sections list the types of test based on the most obvious <strong>quality dimensions</strong> they
+ address.
+</p>
+<h3>
+ Quality Dimension: Functionality
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Function test:</strong>&nbsp;Tests focused on validating the target-of-test functions as intended, providing
+ the required services, methods, or use cases. This test is implemented and executed against different targets-of-test,
+ including units, integrated units, applications, and systems.
+</p>
+<p>
+ <strong>Security test:</strong>&nbsp;Tests focused on ensuring the target-of-test data (or systems) are accessible only
+ to those actors for which they are intended. This test is implemented and executed on various targets-of-test.
+</p>
+<p>
+ <strong>Volume test:</strong>&nbsp;Tests focused on verifying the target-of-test's ability to handle large amounts of
+ data, either as input and output or resident within the database.&nbsp;Volume testing includes test strategies such as
+ creating queries that would return the entire contents of the database, or that would have so many restrictions that no
+ data is returned, or where the data entry has the maximum amount of data for each field.
+</p>
+<h3>
+ Quality Dimension:&nbsp;Usability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Usability test:</strong>&nbsp;Tests that focus on:
+</p>
+<ul>
+ <li>
+ human factors
+ </li>
+ <li>
+ esthetics
+ </li>
+ <li>
+ consistency in the user interface
+ </li>
+ <li>
+ online and context-sensitive help
+ </li>
+ <li>
+ wizards and agents
+ </li>
+ <li>
+ user documentation
+ </li>
+ <li>
+ training materials
+ </li>
+</ul>
+<p>
+ <strong>Integrity test:</strong>&nbsp;Tests that focus on assessing the target-of-test's robustness (resistance to
+ failure), and technical compliance to language, syntax, and resource usage.&nbsp;This test is implemented and executed
+ against different targets-of-tests, including units and integrated units.
+</p>
+<p>
+ <strong>Structure test</strong>: Tests that focus on assessing the target-of-test's adherence to its design and
+ formation.&nbsp;Typically, this test is done for Web-enabled applications ensuring that all links are connected,
+ appropriate content is displayed, and no content is orphaned.
+</p>
+<h3>
+ Quality Dimension: Reliability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Stress test:</strong>&nbsp; A type of reliability test that focuses on evaluating how the system responds under
+ abnormal conditions.&nbsp;Stresses on the system could include extreme workloads, insufficient memory, unavailable
+ services and hardware, or limited shared resources.&nbsp;These tests are often performed to gain a better understanding
+ of how and in what areas the system will break, so that contingency plans and upgrade maintenance can be planned and
+ budgeted for well in advance.
+</p>
+<p>
+ <strong>Benchmark test:</strong>&nbsp; A type of performance test that compares the performance of a new or unknown
+ target-of-test to a known reference-workload and system.
+</p>
+<p>
+ <strong>Contention test:</strong>&nbsp; Tests focused on validating the target-of-test's ability to acceptably handle
+ multiple actor demands on the same resource (data records, memory, and so on).
+</p>
+<h3>
+ Quality Dimension: Performance
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Load test:</strong>&nbsp; A type of performance test used to validate and assess acceptability of the
+ operational limits of a system under varying workloads while the system-under-test remains constant.&nbsp;In some
+ variants, the workload remains constant and the configuration of the system-under-test is varied.&nbsp; Measurements
+ are usually taken based on the workload throughout and in-line transaction response time.&nbsp;The variations in
+ workload usually include emulation of average and peak workloads that occur within normal operational tolerances.
+</p>
+<p>
+ <strong>Performance profile:</strong> A test in which the target-of-test's timing profile is monitored, including
+ execution flow, data access, function and system calls to identify and address both performance bottlenecks and
+ inefficient processes.
+</p>
+<p>
+ <strong>Configuration test:</strong>&nbsp; Tests focused on ensuring the target-of-test functions as intended on
+ different hardware and software configurations.&nbsp;This test might also be implemented as a system performance test.
+</p>
+<h3>
+ Quality Dimension: Supportability
+</h3>
+<h4>
+ Types of Test
+</h4>
+<p>
+ <strong>Installation test:</strong>&nbsp; Tests focused on ensuring the target-of-test installs as intended on
+ different hardware and software configurations, and under different conditions (such as insufficient disk space or
+ power interruptions).&nbsp;This test is implemented and executed against applications and systems.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/use_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/use_case.xmi
new file mode 100644
index 0000000..96484ff
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/use_case.xmi
@@ -0,0 +1,828 @@
+<?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" epf:version="1.0.0" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2006-11-03T12:00:52.609-0500">
+ <mainDescription><h3>
+ <a id="Definitions" name="Definitions">Definitions</a>
+</h3>
+<h4>
+ Use Case
+</h4>
+<p>
+ A use case instance defines a sequence of actions performed by the system that yields an observable result of value to
+ a particular actor. There are several key words in this definition:
+</p>
+<ul>
+ <li>
+ <b>"use case instance"</b> The sequence referred to in the definition is actually a specific flow of events through
+ the system, or an instance. Many flows of events are possible, and many may be very similar. To make a use-case
+ understandable, you should group similar flows of events into one use case. Therefore, identifying and describing a
+ use case really means identifying and describing a group of related flows of events.
+ </li>
+ <li>
+ <strong>"actions"</strong> An action is a computational or algorithmic procedure. It is invoked either when the
+ actor provides a signal to the system or when the system gets a time event. An action may imply signal
+ transmissions to either the invoking actor or other actors. An action is atomic, which means it is performed either
+ entirely or not at all.
+ </li>
+ <li>
+ <b>"performed by the system"</b> This means that the system provides the use case. An actor communicates with a
+ use-case instance of the system.
+ </li>
+ <li>
+ <b>"an observable result of value"</b> You can put a value on a successfully performed use case. A use case should
+ make sure that an actor can perform a task that has an identifiable value. This is very important in determining
+ the correct level or granularity for a use case. <em>Correct level</em> refers to achieving use cases that are not
+ too small.&nbsp;&nbsp;
+ </li>
+ <li>
+ <b>"a&nbsp;particular actor"</b> The actor is key to finding the correct use case, especially because the actor
+ helps you avoid use cases that are too large. As an example, consider a visual modeling tool. There are really two
+ actors&nbsp;in this application: a developer, who develops systems using the tool as support; and a system
+ administrator, who manages the tool. Each of these actors has his own demands on the system, and will therefore
+ require his own set of use cases.
+ </li>
+</ul>
+<p>
+ The functionality of a system is defined by different use cases, each of which represents a specific goal (observable
+ result of value) for a particular actor. The description of a use case defines what happens in the system when the use
+ case is performed.
+</p>
+<p class="picturecenter" align="center">
+ <img height="173" alt="Diagram described in caption." src="./resources/im_uc.gif" width="325" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="picturetext">
+ Figure 1: ATM use case example.
+ </p>
+ </blockquote>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p>
+ In an automated teller machine the client can, for instance, withdraw money from an account, transfer money to an
+ account, or check the balance of an account. These correspond to specific goals that the actor has in using the system.
+</p>
+<p>
+ Each use case has a task of its own to perform. The collected use cases constitute all the possible ways of using the
+ system. You should be able to&nbsp;determine the goal&nbsp;of a use-case task simply by observing its name.&nbsp;&nbsp;
+</p>
+<h4>
+ <a id="A Use-Case has Many Possible Instances" name="A Use-Case has Many Possible Instances">Use-Case</a>
+ Instance&nbsp;
+</h4>
+<p>
+ A use-case can follow an almost unlimited, but enumerable, number of paths. These paths represent the choices open to
+ the use-case in the description of its flow of events. The path chosen depends on events. Types of events include:
+</p>
+<ul>
+ <li>
+ <strong>Input from an actor&nbsp;</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ For example, an actor can decide, from several options, what to do next. In the use case Recycle Items in the
+ Recycling-Machine System the Customer always has two options: insert another deposit item or get the
+ receipt&nbsp;for returned items.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>A check of values or types of an internal object or attribute</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ For example, the flow of events may differ if a value is greater or less than a certain value.&nbsp;In the use case
+ Withdraw Money in an automated teller machine system, the flow of events will differ if the Client asks for more
+ money than he has in his account. In that situation, the use-case instance follows a&nbsp;different path.
+ </p>
+</blockquote>
+<h4>
+ Scenario
+</h4>
+<p>
+ A scenario is a specific sequence of actions that illustrates a behavior.&nbsp; A scenario may be used to illustrate a
+ use-case instance and to specify test cases.
+</p>
+<h4>
+ Use-Case Realization
+</h4>
+<p>
+ A use case describes what happens in the system when an actor interacts with the system. The use case does not define
+ how the system&nbsp;performs its tasks, in terms of collaborating objects. This is left for the use-case realizations
+ to show.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In the telephone example, the use case would indicate (among other things) that the system issues a signal when the
+ actor lifts the receiver,&nbsp; and that the system then receives digits, finds the receiving party, rings his
+ telephone, connects the call, transmits speech, and so on.
+ </p>
+</blockquote>
+<p>
+ In a running&nbsp;system, an instance of a use case does not correspond to any particular object in the implementation
+ model (for example, an instance of a class in the code). Instead, it corresponds to a specific flow of events that is
+ invoked by an actor and&nbsp;performed as a sequence of events among a set of objects. In other words, instances of use
+ cases correspond to communicating instances of implemented objects. We call this the <strong>realization of the use
+ case</strong>. Often, the same objects participate in realizations of more than one use case. For example, both the use
+ cases Deposit and Withdrawal in a banking system may use a certain account object in their realization. This does not
+ mean that the two use cases communicate, but only that they use the same object in their realization.
+</p>
+<p>
+ You can&nbsp;think of&nbsp;a flow of events as consisting of several subflows that,&nbsp;taken together, yield the
+ total flow of events. You can reuse the description of a subflow in other flows of events for other use cases. Subflows
+ in the description of one use case's flow of events may be common to those of other use cases. In the design you should
+ have the same objects perform this common behavior for all the relevant use cases. That is, only one set of objects
+ should perform this behavior no matter which use case is running.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In an automated teller machine system, the initial subflow is the same in the flow of events of the use cases
+ Withdraw Money and Check Balance. The flow of events of both use cases start by checking the identity of the card
+ and the client's personal access code.
+ </p>
+</blockquote>
+<h3>
+ Properties of Use Cases
+</h3>
+<h4>
+ <a id="Name" name="Name">Name</a>
+</h4>
+<p>
+ Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have
+ to be several words to be understood. Note: No two use cases can have the same name.
+</p>
+<blockquote>
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ These are examples of variations of the name for the use case Recycle Items in the Recycling Machine example:
+ </p>
+ <ul>
+ <li>
+ Return Deposit Items
+ </li>
+ <li>
+ Deposit Items
+ </li>
+ </ul>
+</blockquote>
+<h4>
+ <a id="Brief Description" name="Brief Description">Brief Description</a>
+</h4>
+<p>
+ The brief description of the use case should reflect its purpose. As you write the description, refer to the actors
+ involved in the use case and the glossary.&nbsp;If you need to, define new concepts.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ Following are sample brief descriptions of the use cases Recycle Items and Add New Bottle Type in the
+ Recycling-Machine system.
+ </p>
+ <p class="example">
+ <b>Recycle Items</b>: The user uses this machine to automatically have all the return items (bottles, cans, and
+ crates) counted, and receives a receipt. The receipt is to be cashed at a cash register (another machine).
+ </p>
+ <p class="example">
+ <b>Add New Bottle Type</b>: The manager can add options for the user to return new kinds of bottles can be added to
+ the machine by starting it in <em>learning</em> mode and inserting 5 samples, just&nbsp;as when the customers
+ return items. The machine can measure the bottles and learns to identify them. The manager specifies the refund
+ value for the new bottle type.
+ </p>
+</blockquote>
+<h4>
+ Flow of Events
+</h4>
+<h5>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of
+ Events - Contents</a>
+</h5>
+<p>
+ The f<b>low of events</b> of a use case contains the most important information derived from use-case modeling work. It
+ should describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow
+ of events should represent <em>what</em> the system does, not <em>how</em> the system is design to perform the required
+ behavior.
+</p>
+<p>
+ Follow these guidelines for the contents of the flow of events:
+</p>
+<ul>
+ <li>
+ Describe how the use case starts and ends.
+ </li>
+ <li>
+ Describe what data is exchanged between the actor and the use case.
+ </li>
+ <li>
+ Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system.
+ For example, it is often good to use a limited set of web-specific terminology when it is known beforehand that the
+ application is going to be web-based. Otherwise, your run the risk that the use-case text is being perceived as too
+ abstract. Words to include in your terminology could be "navigate", "browse", "hyperlink" "page", "submit", and
+ "browser". However, it is not advisable to include references to "frames" or "web pages" in such a way that you are
+ making assumptions about the boundaries between them; this is a critical design decision.&nbsp;
+ </li>
+ <li>
+ Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
+ ... ".
+ </li>
+ <li>
+ Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
+ system.
+ </li>
+ <li>
+ Avoid vague terminology.
+ </li>
+ <li>
+ Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
+ test cases.
+ </li>
+</ul>
+<p>
+ If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
+ that&nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary.
+</p>
+<h5>
+ <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a>
+</h5>
+<p>
+ The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><b>alternative flows of
+ events</b>. The basic flow of events should cover what "normally" happens when the use case is performed. The
+ alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and
+ also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow
+ of events, some of which will return to the basic flow of events and some of which will end the execution of the use
+ case.
+</p>
+<p align="center">
+ <img height="212" alt="Diagram described in caption." src="./resources/ucstrct.gif" width="231" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="picturetext">
+ Figure 2: Typical structure of a use case flow of events
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p class="picturetext">
+ The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
+ relation to the normal. Some alternative paths return to the basic flow of events, whereas,&nbsp;others end the use
+ case.
+</p>
+<p>
+ Both the basic and alternative flows should be further structured into steps or subflows. In doing this, your main goal
+ should be readability of the text (see the <em>Flow of Events - Style</em> section, which follows). A&nbsp;guideline is
+ that a subflow should be a segment of behavior within the use case that has a clear purpose, and is "atomic" in the
+ sense that you do either all or none of the actions described. You may need to have several levels of subflows,
+ but&nbsp;avoid that if you can,&nbsp;since it makes the text more complex and harder to understand.
+</p>
+<p>
+ The nature of this type of written text, structured into consecutive subsections,&nbsp;implies to the reader that there
+ is a sequence between the subflows. To avoid misunderstandings, you should always point out whether the order of the
+ subflows is fixed or not. Considerations of this kind are often related to factors such as:
+</p>
+<ul>
+ <li>
+ <strong>Business rules</strong>. For example, the user has to be authorized before the system can make certain data
+ available.
+ </li>
+ <li>
+ <strong>User-interface design.</strong> For example, the system should not enforce a certain sequence of behavior
+ that may be intuitive to some but not to other users.
+ </li>
+</ul>
+<p>
+ To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
+ detour to the basic flow of events:
+</p>
+<ul>
+ <li>
+ Where the alternative flow can be inserted in the basic flow of events.
+ </li>
+ <li>
+ The condition that needs to be fulfilled for the alternative behavior to start.
+ </li>
+ <li>
+ How and where the basic flow of events is resumed, or how the use case ends.
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
+ </p>
+ <p class="example">
+ 2.1. Bottle Stuck
+ </p>
+ <p class="example">
+ If in section 1.5, Insert Deposit Items, a bottle gets stuck in the gate, the sensors around the gate and the
+ measuring gate will detect this problem. The conveyer belt is stopped and the machine issues an alarm to call for
+ the operator. The machine will wait for the operator to indicate that the problem has been fixed. The machine then
+ continues in section 1.9 of the basic flow.
+ </p>
+</blockquote>
+<p dir="ltr">
+ In the example above, the alternative flow of events is inserted at a specific location in the basic flow of events.
+ There are also alternative flow of events that can be inserted at more than one location, some can even be inserted at
+ any location in the basic flow of events.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ This is an alternative subflow in the use case Return Items in the Recycling-Machine System.
+ </p>
+ <p>
+ 2.2. Front Panel is Removed
+ </p>
+ <p class="example">
+ If somebody removes the front panel to the Recycling machine, the can compression is deactivated. It will not be
+ possible to start the can compression with the front panel off. The removal will also activate an
+ alarm&nbsp;for&nbsp;operator attention. When the front panel is closed again, the machine resumes operation from
+ the point where it stopped in&nbsp;the basic flow of events.
+ </p>
+</blockquote>
+<p>
+ It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
+ section (using some informal "if-then-else" construct). This should be avoided. Too many alternatives will make the
+ normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
+ text more pseudo-code like and harder to read.
+</p>
+<p>
+ In general, extracting parts of the flow of events and describing these parts separately, can increase the readability
+ of the basic flow of events and improve the structure of the use case and the use-case model. You can model extracted
+ parts as the situation requires:
+</p>
+<ul>
+ <li>
+ An <strong>alternative</strong> flow of events within the base use case if it is a simple variant, option, or
+ exception to the basic flow of events.
+ </li>
+ <li>
+ As an <strong>explicit</strong> inclusion in the base use case, if it is something that you wish to encapsulate so
+ that it can be reused by other use cases.
+ </li>
+ <li>
+ As an <strong>implicit</strong> inclusion in the base use case, if the basic flow of events of the base use case is
+ complete, that is, has a defined beginning and end. The nature of the extending flow should be such that you prefer
+ to conceal it in the description of the base use case to render it less complex.
+ </li>
+ <li>
+ A <strong>subflow</strong> in the basic flow of events, possibly as another option, if none of the above
+ alternatives applies. For example, in a Maintain Employee Information use case, there may be separate subflows for
+ adding, deleting and modifying employee information.
+ </li>
+</ul>
+<h5>
+ <a id="Flow of Events - Style" name="Flow of Events - Style">Flow of Events - Style</a>
+</h5>
+<p>
+ You can describe use cases in many styles. As an example we show the basic flow of events of the use case Administer
+ Order described in three different styles, varying primarily in how formal they are.
+</p>
+<p>
+ The first style, shown in Example 1, is the recommended one, because it is easy to understand, and the order in which
+ things happen is clearly evident. The text is divided into numbered and named subsections. Numbers are there to make it
+ easy to refer to a subsection. Names of subsections will let the reader get a quick overview of the flow of events by
+ browsing through the text reading only the headers.
+</p>
+<p>
+ In Example 2, the description of the flow of events fails to clarify the order in which things happen. If you write in
+ this style, you and others might miss important things that concern the system.
+</p>
+<p>
+ Example 3 below shows a yet another style, which can be useful if you find it difficult to express the sequence of
+ events clearly. This pseudo-code style is more precise, but the text is hard to read and absorb for a non-technical
+ person, especially if you want to grasp the flow of events quickly.
+</p>
+<p>
+ Finally,&nbsp;Example 4&nbsp;provides an example of a complete description of a use case flow of events.&nbsp;
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 1:" name="Example 1:"><strong>Example 1:</strong></a> <strong>Recommended style for describing a use
+ case</strong>
+ </p>
+ <p>
+ In this style, the text is easy to read and the flow of events is easy to follow.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <b>1.1. Start of Use Case</b>
+ <p>
+ This use case starts when the actor Operator tells the system to create a measurement order. The
+ system will then retrieve all Network Element actors, their measurement objects and corresponding
+ measurement functions that are available to this particular Operator. Available Network Elements
+ are those that are in operation, and that the Operator has the authority to access. The
+ availability of measurement functions depends on what has been set up for a particular type of
+ measurement object.
+ </p>
+ <p>
+ <b>1.2. Configure Measurement Order</b>
+ </p>
+ <p>
+ The system allows the actor Operator to select which Network Elements to measure and then shows
+ which measurement objects are available for the selected Network Elements. The system allows the
+ Operator to select from the measurement objects, and then select which measurement functions to set
+ up for each measurement object.
+ </p>
+ <p>
+ The system allows the Operator to enter a textual comment on the measurement order.
+ </p>
+ <p>
+ The Operator tells the system to complete the measurement order. The system will respond by
+ generating a unique name for the measurement order and setting up default values for when, how
+ often, and for how long the measurement should be made. The default values are unique to each
+ Operator. The system then allows the Operator to edit these default values.
+ </p>
+ <p>
+ <b>1.3. Initialize Order</b>
+ </p>
+ <p>
+ The Operator tells the system to initialize the measurement order. The system will then record the
+ identity of the creating Operator, the date of creation, and the "Scheduled" status of the
+ measurement order.
+ </p>
+ <p>
+ <b>1.4. Use Case Ends</b>
+ </p>
+ <p>
+ The system confirms initialization of the measurement order to the Operator, and the measurement
+ order is made available for other actors to view.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<div align="center">
+ <br />
+</div>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 2:" name="Example 2:"><strong>Example 2:</strong></a> <strong>Alternative way of describing a use
+ case</strong>
+ </p>
+ <p>
+ This style is readable, but there is no clear flow of events.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ Orderers can create Orders to collect measurement data from the Network Elements.
+ <p>
+ The system will assign the Order a unique name as well as default values that indicate the length
+ and time of the measurement and also how often it is to be repeated. The Orderer will be able to
+ edit these values.
+ </p>
+ <p>
+ The Orderer must further specify which measurement function, network element and measurements
+ objects are applicable. The Orderer can also add a personal comment to the order.
+ </p>
+ <p>
+ When the necessary information had been defined, a new Order is created and initialized with the
+ defined attributes, the name of the creator, and the date of creation. The status of the order will
+ be set to "scheduled". (Possible values for the status are: Scheduled, Executing, Completed,
+ Canceled, and Erroneous.)
+ </p>
+ <p>
+ The user interface is then notified that a new Order has been created and receives a reference to
+ the new Order so that it can be displayed.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <a id="Example 3:" name="Example 3:"><strong>Example 3:</strong></a> <strong>Another way of describing a use
+ case</strong>
+ </p>
+ <p>
+ Here the writer has chosen a formal style using pseudocode. This style makes it hard to quickly grasp the process
+ steps, but can be useful if the flow of events is difficult to capture precisely.
+ </p>
+</blockquote>
+<div align="center">
+ <table style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid" cellspacing="0" bordercolordark="#808080" cellpadding="4" width="50%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+<pre>
+<font size="2"><small>'Administrate order' (User identity)
+REPEAT
+ &lt;='Show administer order menu'
+ IF (=&gt; 'Creating an Order' (Measurement function, network element, measurement object)) THEN
+ The system finds a unique name, default values for when and how long the measurement should be executed.
+ &lt;= 'Show order' (Default attributes)
+ REPEAT
+ IF (=&gt; 'Edit order' (Attribute to change, New value of attribute)) THEN
+ &lt;= 'Update screen' (New attributes)
+ ELSIF (=&gt; 'Save order' (Order identity, Attributes)) THEN
+ The order is created and initialized in the system with
+ the defined attributes, the name of the creator,
+ date of creation and the status 'scheduled'.
+ &lt;= 'New order created' (The order)
+ ENDIF
+ UNTIL (=&gt; 'Quit')
+ ENDIF
+UNTIL 'Quit administer order'</small>
+</font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<h5>
+ <a id="Example 3:" name="Example 3:">Example 4:</a>&nbsp;Complete description fo the flow of events&nbsp;
+</h5>
+<p>
+ The complete description of the flow of events of the use case Administer Order, including its alternative flows, could
+ look like the example that follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ <b>1.&nbsp;BASIC FLOW&nbsp;OF EVENTS</b>&nbsp;
+ </p>
+ <p>
+ <b>1.1. Start use case</b>
+ </p>
+ <p>
+ This use case starts when the actor Operator tells the system to create a measurement order. The system will then
+ retrieve all Network Element actors, their measurement objects and corresponding measurement functions that are
+ available to this particular Operator. Available Network Elements are those that are in operation, and that the
+ Operator has the authority to access. The availability of measurement functions depends on what has been set up for
+ a particular type of measurement object.
+ </p>
+ <p>
+ <b>1.2. Configure measurement order</b>
+ </p>
+ <p>
+ The system allows the actor Operator to select which Network Elements to measure and then shows which measurement
+ objects are available for the selected Network Elements. The system allows the Operator to select from these
+ measurement objects, and then select which measurement functions to set up for each measurement object.
+ </p>
+ <p>
+ The system allows the Operator to enter a textual comment on the measurement order.
+ </p>
+ <p>
+ The Operator tells the system to complete the measurement order. The system will respond by generating a unique
+ name for the measurement order and setting up default values for when, how often, and for how long the measurement
+ should be made. The default values are unique to each Operator. The system then allows the Operator to edit these
+ default values.
+ </p>
+ <p>
+ <b>1.3. Initialize order</b>
+ </p>
+ <p>
+ The Operator tells the system to initialize the measurement order. The system will then record the identity of the
+ creating Operator, the date of creation, and the "Scheduled" status of the measurement order.
+ </p>
+ <p>
+ <b>1.4. End use case</b>
+ </p>
+ <p>
+ The system confirms initialization of the measurement order to the Operator, and the measurement order is made
+ available for other actors to view.
+ </p>
+ <p>
+ <b>2.&nbsp;ALTERNATIVE FLOW OF EVENTS</b>&nbsp;
+ </p>
+ <p>
+ <b>2.1. No network elements available</b>
+ </p>
+ <p>
+ If in 1.1, Start use case, it turns out that no Network Elements are available to measure for this Operator, the
+ system will inform the Operator. The use case then ends.
+ </p>
+ <p>
+ <b>2.2. No measurement functions available</b>
+ </p>
+ <p>
+ If in 1.2, Configure measurement order, no measurement functions are available for the selected Network Elements,
+ the system will inform the Operator and allow the Operator to select other Network elements.
+ </p>
+ <p>
+ <b>2.3. Cancel measurement order</b>
+ </p>
+ <p>
+ The system will allow the Operator to cancel all actions at any point during the execution of the use case. The
+ system will then return to the state it was in before the use case was started, and end the use case.
+ </p>
+</blockquote>
+<h4>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Special Requirements" name="Special Requirements">Special
+ Requirements</a>
+</h4>
+<p>
+ In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by
+ the flow of events. These are non-functional requirements that will influence the design model. See also the discussion
+ on non-functional requirements in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>. You could organize these requirements in categories such as
+ Usability, Reliability, Performance, and Substitutability, but normally there are so few of them that such grouping is
+ not particularly value-adding.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Example
+ </h5>
+ <p class="example">
+ In the Recycling-Machine System, a special requirement of the Return Deposit Items use case could be:
+ </p>
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="example">
+ The machine has to be able to recognize deposit items with a reliability of more than 95 percent.
+ </p>
+ </blockquote>
+</blockquote>
+<h4>
+ <a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
+</h4>
+<p>
+ A <strong>precondition</strong> is the state of the system and its surroundings that is required before the use case
+ can be started.&nbsp;Post-Conditions are&nbsp;the states the system can be in after the use case has ended. It can
+ be&nbsp;helpful to use the&nbsp;concepts of <b>precondition</b> and <b>post-condition</b> to clarify how the flow of
+ events starts and ends. However, only use them only if the audience for the description of the use case agrees that it
+ is helpful.
+</p>
+<p align="center">
+ <img height="278" alt="Diagram described in caption." src="./resources/ucprepst.gif" width="344" />
+</p>
+<br class="picturetext" />
+<br />
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Figure 3: Illustration of preconditions and resulting post-conditions
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p>
+ Consider the following when specifying preconditions and post-conditions:
+</p>
+<ul>
+ <li>
+ The states described by pre- or post-conditions should be states that the user can observe. "The user has logged on
+ to the system" or "The user has opened the document" are examples of observable states.
+ </li>
+ <li>
+ A precondition is a constraint on when a use case can start. It is not the event that starts the use case.
+ </li>
+ <li>
+ A precondition for a use case is not a precondition for only one subflow, although you can define preconditions and
+ post-conditions at the subflow level.
+ </li>
+ <li>
+ A post-condition for a use case should be true regardless of which alternative flows were executed; it should not
+ be true only for the main flow. If something could fail, you would cover that in the post-condition by saying "The
+ action is completed, or if something failed, the action is not performed", rather than just "The action is
+ completed".
+ </li>
+ <li>
+ When you use post-conditions together with <em>extend</em> relationships, you should take care that the extending
+ use case does not introduce a subflow that violates the post-condition in the base use case.
+ </li>
+ <li>
+ Post-conditions can be a powerful tool for describing use cases. You first define what the use case is supposed to
+ achieve, which is the post-condition. You can then describe the necessary flow of events, or how to reach this
+ condition.
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ Examples
+ </p>
+ <p class="example">
+ <strong>A precondition for the use case Cash Withdrawal in the ATM machine:</strong> The customer has a personally
+ issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
+ </p>
+ <p class="example">
+ <strong>A pos-tcondition for the use case Cash Withdrawal in the ATM machine:</strong> At the end of the use case,
+ all account and transaction logs are balanced, communication with the banking system is reinitialized and the card
+ is returned to the customer.
+ </p>
+</blockquote>
+<h4>
+ <a id="Extension Points" name="Extension Points">Extension Points</a>
+</h4>
+<p>
+ An <b>extension point</b> opens up the use case to the possibility of an extension. It has a name and a list of
+ references to one or more locations within the flow of events of the use case. An extension point may reference a
+ single location between two behavior steps within the use case. It may also reference a set of discrete locations.
+</p>
+<p>
+ Using&nbsp;named extension points will help you separate the specification of the behavior of the extending use case
+ from the internal details of the base use case. The base use case can be modified or rearranged, as long as the names
+ of the extension points remain the same, it will not affect the extending use case. At the same time, you are not
+ complicating the text describing the flow of events of the base use case with details of where behavior might be
+ extended into it.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="exampleheading">
+ <strong>Example</strong>
+ </p>
+ <p class="example">
+ In a phone system, the use case Place Call can be extended by the abstract use case Show Caller Identity. This is
+ an optional service, often referred to as "Caller ID", that may or may not have been requested by the receiving
+ party. A description of the extension point in the use case Place Call could look like the following:
+ </p>
+ <p class="example">
+ <b>Name</b>: Show Identity
+ </p>
+ <p class="example">
+ <b>Location</b>: After section 1.9 Ring Receiving Party's Telephone.
+ </p>
+</blockquote>
+<h3>
+ Specifying Use Cases
+</h3>
+<h4>
+ <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a>
+</h4>
+<p>
+ See the&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for guidance on finding Actors
+ and Use Cases.
+</p>
+<h4>
+ <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a>
+</h4>
+<p>
+ See the <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance on evolving use cases.
+</p>
+<h4>
+ Level of detail necessary in use cases&nbsp;
+</h4>
+<p>
+ There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
+ of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
+ disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
+ the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
+ of some data from the system.
+</p>
+<p>
+ For more information on possible formats and level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
+</p>
+<h4>
+ <a id="XE_use_case__scope_of_a_use_case" name="XE_use_case__scope_of_a_use_case"></a><a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a>
+</h4>
+<p>
+ It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
+ use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
+ machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
+ exchange this receipt for money.
+</p>
+<p>
+ Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
+ There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
+ with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
+ complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
+ case of use, a use case.
+</p>
+<p>
+ Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
+ together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
+ larger systems.
+</p>
+<h3>
+ <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Use-Case Diagrams" name="Use-Case Diagrams">Use-Case Diagrams</a>
+</h3>
+<p>
+ You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual
+ cases, more than one diagram). This is useful if the use case is involved with many actors, or has relationships to
+ many other use cases. A diagram of this kind is of "local" character, since it shows the use-case model from the
+ perspective of one use case only and is not intended to explain any general facts about the whole use-case model. Refer
+ to&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/use_case_model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/use_case_model.xmi
new file mode 100644
index 0000000..b7da59b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/use_case_model.xmi
@@ -0,0 +1,169 @@
+<?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" epf:version="1.0.0" xmi:id="-yEWkrWZ3VUcjZPhq6bvScg" name="new_concept,_2jyfUAhVEduRe8TeoBmuGg" guid="-yEWkrWZ3VUcjZPhq6bvScg" changeDate="2007-02-27T14:29:36.889-0500" version="1.0.0">
+ <mainDescription><h3>
+ Explanation
+</h3>
+<p>
+ A use-case model is a model of how different types of users interact with the system to solve a problem.&nbsp; As such,
+ it describes the goals of the users, the interactions between the users and the system, and the required behavior of
+ the system in satisfying these goals.
+</p>
+<p>
+ A use-case model consists of a number of model elements.&nbsp; The most important model elements are: use cases, actors
+ and the relationships between them.
+</p>
+<p>
+ A use-case diagram is used to graphically depict a subset of the model to simplify communications.&nbsp; There will
+ typically be several use-case diagrams associated with a given model, each showing a subset of the model elements
+ relevant for a particular purpose.&nbsp; The same model element may be shown on several use-case diagrams, but each
+ instance must be consistent.&nbsp; If tools are used to maintain the use-case model, this consistency constraint is
+ automated so that any changes to the model element (changing the name for example) will be automatically reflected on
+ every use-case diagram that shows that element.
+</p>
+<p>
+ The use-case model may contain packages that are used to structure the model to simplify analysis, communications,
+ navigation, development, maintenance and planning.
+</p>
+<p>
+ Much of the use-case model is in fact textual, with the text captured in the&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/templates/uc_specification,_0cpNwMlgEdmt3adZL5Dmdw.html"
+ guid="_0cpNwMlgEdmt3adZL5Dmdw">Use-Case Specification</a>s that are associated with each use-case model
+ element.&nbsp;These specifications describe the flow of events of the use case.
+</p>
+<p>
+ The use-case model serves as a unifying thread throughout system development. It is used as the primary specification
+ of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning,
+ as the basis of defining test cases and as the basis for user documentation&nbsp;&nbsp;
+</p>
+<h3>
+ Basic model elements
+</h3>
+<p>
+ The use-case model contains, as a minimum, the following basic model elements.
+</p>
+<h4>
+ Actor
+</h4>
+<p>
+ A model element representing&nbsp;each actor. Properties include the actors name and brief description. See&nbsp;<a
+ class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Concept: Actor</a> for more information.
+</p>
+<h4>
+ Use Case
+</h4>
+<p>
+ A model element representing&nbsp;each use case. Properties include the use case name and use case specification. See
+ <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a> for more information.
+</p>
+<h4>
+ Associations
+</h4>
+<p>
+ Associations are used to describe the relationships between actors and the use cases they participate in. This
+ relationship is commonly known as a “communicates-association”.
+</p>
+<h3>
+ Advanced model elements
+</h3>
+<p>
+ The use-case model may also contain the following advanced model elements.
+</p>
+<h4>
+ Subject
+</h4>
+<p>
+ A model element that represents the boundary of the system of interest.&nbsp;&nbsp;
+</p>
+<h4>
+ Use-Case Package
+</h4>
+<p>
+ A model element used to structure the use case model to simplify analysis, communications, navigation, and
+ planning.&nbsp; If there are many use cases or actors, you can use use-case packages to further structure the use-case
+ model in much the same manner you use folders or directories to structure the information on your hard-disk.
+</p>
+<p>
+ You can partition a use-case model into use-case packages for several reasons, including:
+</p>
+<ul>
+ <li>
+ To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning.
+ </li>
+ <li>
+ To support parallel development by dividing the problem into bite-sized pieces.
+ </li>
+ <li>
+ To simplify communication with different stakeholders by creating packages for containing use cases and actors
+ relevant to a particular stakeholder.
+ </li>
+</ul>
+<h4>
+ Generalizations
+</h4>
+<p>
+ A relationship&nbsp;between actors to support re-use of common properties.
+</p>
+<h4>
+ Dependencies
+</h4>
+<p>
+ A number of dependency types between use cases are defined in UML. In particular, &lt;&lt;extend&gt;&gt; and
+ &lt;&lt;include&gt;&gt;.
+</p>
+<p>
+ &lt;&lt;extend&gt;&gt; is used to include optional behavior from an extending use case in an extended use case.
+</p>
+<p>
+ &lt;&lt;include&gt;&gt; is used to include common behavior from an included use case into a base use case in order to
+ support re-use of common behavior.
+</p>
+<p>
+ The latter is the most widely used dependency and is useful for:
+</p>
+<ul>
+ <li>
+ Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of
+ the use case to simplify communications.
+ </li>
+ <li>
+ Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and
+ ensure consistency.
+ </li>
+</ul>
+<h3>
+ Example Use-Case Diagram
+</h3>
+<p>
+ Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
+</p>
+<p>
+ &nbsp;<img height="410" alt="Figure 1: ATM Use-Case Diagram" src="./resources/ATMUCdiagram.GIF" width="565" />
+</p>
+<p>
+ Figure 1: ATM Use-Case Diagram
+</p>
+<p>
+ This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use
+ cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three &lt;&lt;includes&gt;&gt;
+ dependencies, and the associations between the performing actors and the use cases.
+</p>
+<p>
+ The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to
+ the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use
+ cases &lt;&lt;include&gt;&gt;. The base use cases are independent of the method used for identification, and it is
+ therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter
+ whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on
+ the result of Validate Customer.
+</p>
+<p>
+ Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions
+ of each actor, descriptions of each use case, and use-case specifications for each use case.&nbsp; For a more complete
+ example of this use case model see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/examples/uc_model_evolve,_t4QdAMNqEdu2IdAIaWZyAw.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Example: Evolution of the Use-Case Model</a>.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/visual_modeling.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/visual_modeling.xmi
new file mode 100644
index 0000000..f8da80f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/visual_modeling.xmi
@@ -0,0 +1,147 @@
+<?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" epf:version="1.0.0" xmi:id="_SB1n8MM1EdmSIPI87WLu3g" name="visual_modeling,_0XY6UMlgEdmt3adZL5Dmdw" guid="_SB1n8MM1EdmSIPI87WLu3g" changeDate="2007-03-03T12:12:42.271-0500" version="1.0.0">
+ <mainDescription><p align="center">
+ <img height="229" alt="visual modelling" src="./resources/visual.gif" width="447" />
+</p>
+<p align="center">
+ Visual modeling raises the level of abstraction
+</p>
+<p>
+ Visual modeling is the use of semantically rich, graphical and textual design notations to capture software designs. A
+ notation, such as UML, allows the level of abstraction to be raised, while maintaining rigorous syntax and semantics.
+ In this way, it improves communication in the team as the design is formed and reviewed, allowing the reader to reason
+ about the design, and it provides an unambiguous basis for implementation.
+</p>
+<h3>
+ How visual models help
+</h3>
+<p>
+ A model is a simplified view of a system. It shows the essentials of the system from a particular perspective and hides
+ the nonessential details. Visual models help you:
+</p>
+<ul>
+ <li>
+ Increase understanding of complex systems
+ </li>
+ <li>
+ Explore and compare design alternatives at a low cost
+ </li>
+ <li>
+ Form a foundation for implementation
+ </li>
+ <li>
+ Capture requirements precisely
+ </li>
+ <li>
+ Communicate decisions unambiguously
+ </li>
+</ul>
+<h4>
+ Increase understanding of complex systems
+</h4>
+<p>
+ The importance of models increases as systems become more complex. For example, you can build a doghouse without
+ blueprints. However, as you progress to building houses and then to skyscrapers, your need for blueprints becomes
+ pronounced.
+</p>
+<p>
+ Similarly, a small application built by one person in a few days may be easily understood in its entirety. However, an
+ e-commerce system with tens of thousands of source lines of code (SLOCs) or an air traffic control system with hundreds
+ of thousands of SLOCs can no longer be easily understood by one person. Constructing models allows a developer to focus
+ on the big picture, understand how components interact, and identify fatal flaws.&nbsp;
+</p>
+<p>
+ Among the various types of models are these examples:
+</p>
+<ul>
+ <li>
+ Use cases to specify behavior unambiguously
+ </li>
+ <li>
+ Class diagrams and data model diagrams to capture design
+ </li>
+ <li>
+ State transition diagrams to model dynamic behavior
+ </li>
+</ul>
+<p>
+ Modeling is important because it helps the team visualize, construct, and document the structure and behavior of the
+ system without getting lost in complexity.
+</p>
+<h4>
+ Explore and compare design alternatives at a low cost
+</h4>
+<p>
+ You can create and modify simple models inexpensively to explore design alternatives. Innovative ideas can be captured
+ and reviewed by other developers before investing in costly code development. When coupled with iterative development,
+ visual modeling helps developers assess design changes and communicate these changes to the entire development team.
+</p>
+<h4>
+ Form a foundation for implementation
+</h4>
+<p>
+ Today, many projects employ object-oriented programming languages to build reusable, change-tolerant, and stable
+ systems. To get these benefits, it is even more important to use object technology in design.
+</p>
+<p>
+ The creation of visual models, whether on paper; around a whiteboard; or in a modeling tool, can help a team to gain
+ agreement on key aspects of the system before investing time in proving their ideas with code. Having a shared model of
+ the system promotes collaboration within the team, encouraging everyone to work towards the same goal.
+</p>
+<p>
+ With the support of appropriate tools, you can use a design model to generate an initial code for implementation. This
+ is referred to as <strong>forward engineering</strong> or <strong>code generation</strong>. You can also enhance design
+ models to include enough information to build the system.
+</p>
+<p>
+ <strong>Reverse engineering</strong> may also be applied to generate design models from existing implementations. You
+ can use this method to evaluate existing implementations.
+</p>
+<p>
+ <strong>Round-trip engineering</strong> combines both forward and reverse engineering techniques to ensure consistent
+ design and code. Combined with an iterative process and the right tools, round-trip engineering allows you to
+ synchronize the design and code during each iteration.
+</p>
+<h4>
+ Capture requirements precisely
+</h4>
+<p>
+ Before building a system, it's critical to capture the requirements. Specifying the requirements using a precise and
+ unambiguous model helps to ensure that all stakeholders can understand and agree on the requirements.
+</p>
+<p>
+ A model that separates the external behavior of the system from the implementation of it helps you focus on the
+ intended use of the system, without getting bogged down in implementation details.
+</p>
+<h4>
+ Communicate decisions unambiguously
+</h4>
+<p>
+ The Unified Modeling Language (UML) is&nbsp;a consistent notation that can be applied for system engineering, as well
+ as for business engineering. According to these excerpts from the UML specification, a standard notation:
+</p>
+<ul>
+ <li>
+ <p>
+ Serves as a language for communicating decisions that are not obvious or cannot be inferred from the code
+ itself.
+ </p>
+ </li>
+ <li>
+ <p>
+ Provides semantics that are rich enough to capture all important strategic and tactical decisions.
+ </p>
+ </li>
+ <li>
+ <p>
+ Offers a form concrete enough for humans to reason [about] and for tools to manipulate.
+ </p>
+ </li>
+</ul>
+<p>
+ UML represents the convergence of the best practice in software modeling throughout the object-technology industry. For
+ more information on the UML, see <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[UML05]</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/workspace.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/workspace.xmi
new file mode 100644
index 0000000..7cb5972
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/workspace.xmi
@@ -0,0 +1,50 @@
+<?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" epf:version="1.0.0" xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" name="workspace,_0cEmAMlgEdmt3adZL5Dmdw" guid="_Dfmk8MPiEdmbOvqy4O0adg" changeDate="2006-09-21T15:22:51.449-0400" version="1.0.0">
+ <mainDescription><p align="left">
+ On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
+ conflicts.
+</p>
+<p align="left">
+ A better approach is for each developer to have a reasonably private area for the development and testing of their work
+ products. This workspace should be insulated&nbsp;so that destabilizing or conflicting changes made by others do not
+ interfere with&nbsp;progress. However, it should&nbsp;not be isolated to the extent that&nbsp;the developer's work is
+ unavailable to the team.
+</p>
+<p align="left">
+ In addition, insulated&nbsp;workspaces can be created for each test phase, such as integration testing and system
+ testing. This approach to workspaces provides several benefits <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[WIB04]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ Developers can develop, test, and debug software changes without being affected by others team
+ members'&nbsp;changes until they are ready. When ready, developers can update their insulated environments to
+ test the latest changes from other developers.
+ </p>
+ </li>
+ <li>
+ <p>
+ With separate workspaces for integration and system testing, a team could use a methodology that ensures
+ changes have passed integration testing before other developers get them, thereby minimizing the time spent
+ solving integration problems.&nbsp; For example, if two team members check in incompatible changes without
+ realizing it, and both changes are immediately available to everyone on the team, all team members&nbsp;might
+ waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
+ being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
+ team.
+ </p>
+ </li>
+ <li>
+ <p>
+ By setting up an integration area to collect and build the latest changes, the team can integrate early and
+ often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
+ </p>
+ </li>
+ <li>
+ <p>
+ The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
+ contains only configurations that have passed integration testing. This lets you control the content of the
+ release while still enabling developers to continue working.
+ </p>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/iteration_plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/iteration_plan.xmi
new file mode 100644
index 0000000..7df5eb3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/iteration_plan.xmi
@@ -0,0 +1,4 @@
+<?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="-nDr0XNiUWBo6VS1YS6KAqA" name=",_TuNhIEE4EdulKujnGUuxbg" guid="-nDr0XNiUWBo6VS1YS6KAqA" changeDate="2006-09-10T22:11:20.945-0400">
+ <mainDescription><a href="./resources/ex_iteration_plan.doc" target="_blank">ex_iteration_plan.doc</a></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/project_plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/project_plan.xmi
new file mode 100644
index 0000000..f85df31
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/project_plan.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-IdlCQXdDNYGrGJU4TBwvCA" name="new_example,_Nzv5kDoAEdusGsHODb-STA" guid="-IdlCQXdDNYGrGJU4TBwvCA" changeDate="2006-09-27T17:07:10.301-0400">
+ <mainDescription><p>
+ This example is the actual project plan used for the development of OpenUP/Basic.
+</p>
+<p>
+ <a href="./resources/project_plan.doc" target="_blank">project_plan.doc</a>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ATM UC Model Elaboration.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ATM UC Model Elaboration.doc
new file mode 100644
index 0000000..c1c6442
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ATM UC Model Elaboration.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ATM UC Model Inception.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ATM UC Model Inception.doc
new file mode 100644
index 0000000..d6cb7d3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ATM UC Model Inception.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Deposit Funds Outline.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Deposit Funds Outline.doc
new file mode 100644
index 0000000..69abe36
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Deposit Funds Outline.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Transfer Funds Outline.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Transfer Funds Outline.doc
new file mode 100644
index 0000000..e1e26f6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Transfer Funds Outline.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Use Case Spec - Validate User.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Use Case Spec - Validate User.doc
new file mode 100644
index 0000000..3c4ec9e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Use Case Spec - Validate User.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Use Case Spec - Withdraw Cash.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Use Case Spec - Withdraw Cash.doc
new file mode 100644
index 0000000..a2d147c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Use Case Spec - Withdraw Cash.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Withdraw Cash Outline.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Withdraw Cash Outline.doc
new file mode 100644
index 0000000..bd23ee1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/Withdraw Cash Outline.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ex_iteration_plan.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ex_iteration_plan.doc
new file mode 100644
index 0000000..5802f01
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ex_iteration_plan.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ex_work_items_list.xls b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ex_work_items_list.xls
new file mode 100644
index 0000000..234f2a5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/ex_work_items_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/project_plan.doc b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/project_plan.doc
new file mode 100644
index 0000000..5b4a2f6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/resources/project_plan.doc
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/uc_model_evolve.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/uc_model_evolve.xmi
new file mode 100644
index 0000000..9ac0951
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/uc_model_evolve.xmi
@@ -0,0 +1,116 @@
+<?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" epf:version="1.0.0" xmi:id="-JviMIao63C7w9C8W6iPJrw" name="new_example,_t4QdAMNqEdu2IdAIaWZyAw" guid="-JviMIao63C7w9C8W6iPJrw" authors="Chris Sibbald" changeDate="2007-02-23T13:23:26.346-0500">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ This example illustrates how the use-case model and associated use-case specification will evolve during the
+ lifecycle.&nbsp; It shows the state of the use case model at two points in the lifecycle: early inception and towards
+ the end of elaboration.&nbsp; The purpose is to illustrate how one would&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find and Outline Requirements</a> and&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/tasks/detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw.html"
+ guid="_0e1mIMlgEdmt3adZL5Dmdw">Detail Requirements</a> so as to maximize stakeholder value and minimize risk early in
+ the project as well as to minimize re-work later.
+</p>
+<p>
+ The example uses an Automated Teller Machine as the example system because it is familiar to most people.&nbsp; This
+ familiarity&nbsp;simplifies understanding the principles without&nbsp;getting lost in domain specific terminology.
+</p>
+<h4>
+ Early Inception
+</h4>
+<p>
+ Assume you have just started on the project as the Analyst.&nbsp; You have identified the key stakeholders and met with
+ them to discuss their needs.&nbsp; During your meetings, you identified a number of key actors,&nbsp;use cases and
+ supporting requirements for the ATM system.&nbsp; You captured the use cases and actors, with names and brief
+ descriptions only, in the use-case model.&nbsp; An example of this work is given in the document <a
+ href="./resources/ATM%20UC%20Model%20Inception.doc" target="_blank">ATM UC Model Inception.doc</a>.
+</p>
+<p>
+ Prior to committing significant time to detailing these use cases now, you recognize that a “breadth before depth”
+ approach can save you valuable time and permit you to identify the highest value and/or highest risk items so you can
+ concentrate on those first.
+</p>
+<p>
+ You hold a brainstorming session with the stakeholders and outline the basic flow of each of the main use cases.&nbsp;
+ As you are working through, you may identify some additional alternative flows.&nbsp; Fight the urge to “dive-in” to
+ the details on these alternative flows at this point, simply list them and come back later when you have a better
+ understanding of the “big picture”.
+</p>
+<p>
+ Examples of the notes you took during this exercise are attached below.&nbsp;(Note the choice of font is intentional to
+ illustrate that these are notes, not formal documents).
+</p>
+<p>
+ <a href="./resources/Withdraw%20Cash%20Outline.doc" target="_blank">Withdraw Cash Outline.doc</a>
+</p>
+<p>
+ <a href="./resources/Deposit%20Funds%20Outline.doc" target="_blank">Deposit Funds Outline.doc</a>
+</p>
+<p>
+ <a href="./resources/Transfer%20Funds%20Outline.doc" target="_blank">Transfer Funds Outline.doc</a>
+</p>
+<p>
+ Reviewing your notes, you recognize that there is some behavior that is common to most of the use cases, namely the
+ steps required to validate the Bank Customer.&nbsp; Factoring this behavior out into an &lt;&lt;included&gt;&gt; use
+ case will simplify communications, iteration planning,&nbsp;and maintenance.
+</p>
+<p>
+ You update the use case model accordingly: <a href="./resources/ATM%20UC%20Model%20Elaboration.doc" target="_blank">ATM
+ UC Model Elaboration.doc</a>.
+</p>
+<h4>
+ Elaboration
+</h4>
+<p>
+ With a better understanding of the system, you can now prioritize your effort to maximize value and minimize
+ risk.&nbsp; You start by detailing the common behavior captured in the use case: Validate User.&nbsp; This use case
+ captures key architectural requirements that will exercise a significant portion of the system (communications with the
+ Bank, card reader interface, etc.).&nbsp; Implementing this one key scenario will go a long way to reducing risk.
+</p>
+<p>
+ An example of the Validate User Specification is given below:<br />
+ <br />
+ <a href="./resources/Use%20Case%20Spec%20-%20Validate%20User.doc" target="_blank">Use Case Spec - Validate
+ User.doc</a>
+</p>
+<p>
+ Note that there may still be some un-answered questions, but that’s OK.&nbsp; Capture these directly in the use-case
+ specification and get them answered (see Section 5.6 of the Validate User UC Specification, above for an example).
+</p>
+<p>
+ Continuing with another architecturally significant thread, you detail the basic flow and some key alternate flows of
+ the use case: Withdraw Cash.&nbsp; You know that if the team can implement this, much of the other functionality will
+ be low risk.
+</p>
+<p>
+ An example of the Withdraw Cash Specification is given below:
+</p>
+<p>
+ <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use Case Spec - Withdraw Cash.doc</a>
+</p>
+<h3>
+ Summary
+</h3>
+<p>
+ By following a breadth before depth approach to outlining and detailing use cases one can make better decisions on
+ priorities.&nbsp; Start by identifying actors.&nbsp; Then for each actor, ask “What is the main purpose this actor
+ would like to use the system?”.&nbsp; This will lead to the identification of the use cases.&nbsp; Capture the actors
+ and use cases in the use-case model along with a brief description.
+</p>
+<p>
+ Prioritize the use cases, and then draft the main scenario or basic flow.&nbsp; As you are working through this you may
+ identify alternate flows (what can go wrong, what options are available, etc.).&nbsp; Capture these, along with a brief
+ description.
+</p>
+<p>
+ Review the use-case model and reprioritize and assess risk.&nbsp; For the high priority (based on value to the
+ stakeholders) and/or high risk use cases detail the main scenario and the critical alternate flows.
+</p>
+<p>
+ If you follow this approach, you will increase the likelihood of delivering value early, minimizing risk, and
+ minimizing re-work.<br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/use_case_spec.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/use_case_spec.xmi
new file mode 100644
index 0000000..79349e1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/use_case_spec.xmi
@@ -0,0 +1,18 @@
+<?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" epf:version="1.0.0" xmi:id="-qq-9Brh5oa6H3lsdp-m8mQ" name=",_JLOiIMNvEdu2IdAIaWZyAw" guid="-qq-9Brh5oa6H3lsdp-m8mQ" changeDate="2007-02-23T13:55:56.270-0500">
+ <mainDescription><p>
+ The attached document provides an example of a use-case specification for an Automated Teller Machine (ATM).&nbsp; The
+ ATM was selected as an example system since it is familiar to most people.&nbsp; This familiarity&nbsp;simplifies
+ understanding the principles without&nbsp;getting lost in domain specific terminology.
+</p>
+<p>
+ Example use-case specification: <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use
+ Case Spec - Withdraw Cash.doc</a>
+</p>
+<p>
+ A companion example, <a class="elementLink"
+ href="./../../../openup_basic/guidances/examples/uc_model_evolve,_t4QdAMNqEdu2IdAIaWZyAw.html"
+ guid="_t4QdAMNqEdu2IdAIaWZyAw">Evolution of the Use-Case Model</a>, shows how the use-case model as a whole evolves
+ over time.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/work_items_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/work_items_list.xmi
new file mode 100644
index 0000000..ac2595e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/work_items_list.xmi
@@ -0,0 +1,4 @@
+<?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="-qunTPN3vqTIGpELwajXpLA" name="work_items_list,_nHomIDgzEdu4E8ZdmlYjtA" guid="-qunTPN3vqTIGpELwajXpLA" changeDate="2006-08-31T10:50:15.463-0400">
+ <mainDescription><a href="./resources/ex_work_items_list.xls" target="_blank">ex_work_items_list.xls</a></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/abstract_away_complexity.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/abstract_away_complexity.xmi
new file mode 100644
index 0000000..77c1c83
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/abstract_away_complexity.xmi
@@ -0,0 +1,50 @@
+<?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" epf:version="1.0.0" xmi:id="-X7QSjItNBz7w8603yBCv0Q" name="abstract_away_complexity,_we3F4ACpEdu8m4dIntu6jA" guid="-X7QSjItNBz7w8603yBCv0Q" changeDate="2007-02-07T16:14:04.351-0800" version="1.0.0">
+ <mainDescription><p>
+ Software&nbsp;development is a pursuit characterized by complexity. This can take many forms, such as accommodating
+ complex requirements, technology, or team dynamics. Elevating the level of abstraction helps you manage this complexity
+ and make measurable progress, despite the inherent difficulty of the task.
+</p>
+<p>
+ Suggestions for several strategies that help abstract away complexity follow.
+</p>
+<h4>
+ Leverage patterns
+</h4>
+<p>
+ Patterns help you take advantage of proven techniques for solving common problems. You can benefit from the experience
+ of seasoned practitioners and avoid "re-inventing the wheel," as the saying goes. The use of patterns is a crucial
+ aspect of an architecture-centric approach to development, because it helps reduce the novelty and diversity of a
+ solution, thus improves quality.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/pattern,_0YJvUMlgEdmt3adZL5Dmdw.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
+</p>
+<h4>
+ Design the architecture with components and services
+</h4>
+<p>
+ This strategy helps manage software complexity through&nbsp;partitioning&nbsp;a system into a set of loosely coupled
+ and highly cohesive subsystems. The benefits of this approach include the ability to organize the team around a set of
+ smaller, more manageable objectives, and the ability to substitute parts of the system without disturbing the overall
+ cohesion of the system. Exposing services encourages re-use by making the functionality of the system easier to
+ comprehend. Focusing on services makes it possible to understand what the system does from a technical perspective
+ without necessarily having to understand the details of how the system works.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/component,_0YP18MlgEdmt3adZL5Dmdw.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>&nbsp;for more information.
+</p>
+<h4>
+ Actively promote reuse
+</h4>
+<p>
+ Incorporating existing software into an overall architecture helps reduce cost and improve quality by reusing proven
+ working software, rather than developing from scratch. It also helps reduce the burden of maintenance by eliminating
+ duplication in the software. Although often difficult to manage, a project or enterprise can reap significant benefits
+ from a well-executed re-use strategy.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/abstract_away_complexity_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/abstract_away_complexity_vm.xmi
new file mode 100644
index 0000000..567f111
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/abstract_away_complexity_vm.xmi
@@ -0,0 +1,48 @@
+<?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" epf:version="1.0.0" xmi:id="-OcMsciNn-UtD9fTHj26LGA" name="new_guideline,_34jWsLcIEduRNaXpzCOLXQ" guid="-OcMsciNn-UtD9fTHj26LGA" changeDate="2007-02-07T16:14:24.390-0800">
+ <mainDescription><h4>
+ Model key perspectives
+</h4>
+<p>
+ Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
+ illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
+ software. The Unified Modeling Language (UML) provides an industry-standard approach to software modeling.
+</p>
+<p>
+ When applying this strategy, you can use various techniques:
+</p>
+<ul>
+ <li>
+ <strong>Identify the key perspectives:</strong> Focus on modeling the things that count. Few (if any) projects
+ benefit from modeling the entire design to a great level of detail. Make sure that you understand why you are
+ modeling something and who will benefit.
+ </li>
+ <li>
+ <strong>Communicate key architectural perspectives:</strong> Even if you choose to model very little&nbsp;of your
+ design, it is often advantageous to produce diagrams that communicate the key architectural aspects of the system.
+ Conveying the "big picture" to the rest of the team helps them understand the overall approach and develop cohesive
+ software.&nbsp;
+ </li>
+ <li>
+ <strong>Sketch the design:</strong> Not all models need to be detailed completely and presented in a software
+ modeling tool. It is often perfectly acceptable (if not desirable) to produce hand-drawn sketches on paper or on a
+ whiteboard when you are exploring and communicating the architecture and design with your team. You can use a
+ digital camera or an electronic whiteboard to capture these diagrams and share them. For many small projects, this
+ is often all you need. See <a href="http://www.agilemodeling.com/">http://www.agilemodeling.com/</a> for more
+ information.
+ </li>
+ <li>
+ <strong>Use a modeling tool as needed</strong>:&nbsp;If the team members are changing models throughout the
+ project, sharing patterns/structure, debugging design, describing behavior, etc., then static photos or paper will
+ become difficult to work with. The team may want to capture design in a software modeling tool. Other than
+ communicating the design to the team, another benefit of a such a tool is the&nbsp;generation of structural code
+ from the models. Many software development tools allow you to view the code as models, making it easier to
+ comprehend static and dynamic aspects of a complex code base.
+ </li>
+ <li>
+ <strong>Agree on a standard notation:</strong> In a team environment, it is important that others can understand
+ your diagrams without much explanation. Choosing a standard notation enables others to quickly comprehend your
+ diagrams without ambiguity. The Unified Modeling Language is an example of a widely understood notation.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/agile_and_unified.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/agile_and_unified.xmi
new file mode 100644
index 0000000..d9d3b48
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/agile_and_unified.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-l-ZsqrXu2nmVE1giLpI6iw" name=",_qg1IAK__EduMeuOwJ2MpeQ" guid="-l-ZsqrXu2nmVE1giLpI6iw">
+ <mainDescription>Describe differences between unified processes and Agile methods<br />
+Describe how OpenUP is a Unified Process that incorporates some Agile<br />
+methods that have proven effective<br />
+Describe what Agile elements are incorporated into OpenUP</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/agile_estimation.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/agile_estimation.xmi
new file mode 100644
index 0000000..6ee7358
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/agile_estimation.xmi
@@ -0,0 +1,131 @@
+<?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" epf:version="1.0.0" xmi:id="_CYRMgBEdEdqY7JB6N6CW2w" name="agile_estimation,_CGHskBEdEdqY7JB6N6CW2w" guid="_CYRMgBEdEdqY7JB6N6CW2w" changeDate="2006-10-31T14:31:48.634-0800">
+ <mainDescription><h3>
+ Agile Estimation
+</h3>
+<p>
+ There are three main concepts you need to understand to do agile estimation:
+</p>
+<ul>
+ <li>
+ <strong>Estimation of Size</strong> gives you a high-level estimate for the work item, typically measured using a
+ neutral unit such as points
+ </li>
+ <li>
+ <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
+ </li>
+ <li>
+ <strong>Estimation of Effort</strong> translates the size (measured in points) to a detailed estimate of effort
+ typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take
+ the team member(s) assigned to the work item to do the work.
+ </li>
+</ul>
+<h4>
+ Estimation of Size
+</h4>
+<p>
+ Agile estimation of size is typically done using a relative measure called <strong>points</strong>.&nbsp; You decide
+ how big a point is, and based on that size, you determine how many points each work item is. To make estimation go
+ fast, you want to use only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65
+ points. To get started, look at 10 or so representative work items, give the smallest the size of one point, and then
+ go through all other work items and give them a relative point estimate based on that point. Note that points are used
+ for high-level estimates, so do not spend too much time on any one item. This is especially true for work items of
+ lower priority, since you would then waste effort on things that are unlikely to be addressed within the current
+ iteration.
+</p>
+<p>
+ A key benefit of points is that they are neutral and relative. Let’s say that Ann is 3 times more productive than Jack.
+ If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,
+ they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours,
+ while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do
+ it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use
+ Velocity to determine how much ‘size’, or how many points, the team can take on within an iteration.
+</p>
+<p>
+ One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the
+ same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project.
+ You&nbsp;want to make sure that the entire team is involved in assessing size, or at least that the same people are
+ involved in all your size estimates, to ensure consistency within your project. We will see how the concept of velocity
+ will fix also this discrepancy in a point meaning different things to different project teams.
+</p>
+<p>
+ You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
+</p>
+<h4>
+ Velocity
+</h4>
+<p>
+ Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an
+ iteration for a certain team and project. As an example, a team may plan for taking on 20 points in the first
+ iteration. At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence
+ 14. For the next iteration, they may plan for fewer points, let’s say 18 points, since they think they can do a little
+ better than in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.
+</p>
+<p>
+ You should expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and
+ points are not always identical in terms of effort. Some team members are more effective than others, and some problems
+ end up being harder than others. Also, changes to the team structure, learning new skills, changes to the tool
+ environment, better teaming, or more overhead with meetings or tasks external to the project will all impact velocity.
+ In general, velocity typically increases during tha project as the team builds skills and becomes more cohesive.
+</p>
+<p>
+ Velocity compensates for differences between teams in terms of how big a point is. Let’s assume that project team Alpha
+ and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team
+ Alpha, however, assesses all work items as being worth 3 times as many points. Team Alpha assesses work item A, B, C,
+ and D to correspond to 30 points, and team Beta estimates the same work items to correspond to 10 points. Both teams
+ deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and team Beta a velocity of
+ 10. It may sound as if team Alpha is more effective, but let’s look at what happens when they plan the next iteration.
+ They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and team Beta as normal has
+ estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many points as indicated by
+ their velocity, they can both take on all of E-H. The end result is that it does not matter how big a point is, as long
+ as you are consistent within your team.
+</p>
+<p>
+ Velocity also averages out the efficiency of different team members. Let’s look at an example; Let’s assume that Ann
+ always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3
+ points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may
+ not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since
+ the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.
+ As you switch team members, or as team members become more or less efficient, your velocity will change, and you can
+ hence take on more or less points. This does however not require you to change the estimate of the size. The size is
+ still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand
+ for that iteration.
+</p>
+<h4>
+ Estimation of Effort
+</h4>
+<p>
+ As you plan an iteration, you will take on a work item, such as detail, design, implement and test a scenario, which
+ may be sized to 5 points. Typically you at this time break down this still reasonably big work item into a number of
+ smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and Testing Server portion,
+ and Implementing and Testing Client portion of the scenario. You would now do a detailed estimate of the actual effort,
+ measured in hours or days, associated with each of those 4 tasks. This estimate should be done by the person assigned
+ to do the task. In this case you may assign the following actual estimates (with person responsible within
+ parenthesis):
+</p>
+<ul>
+ <li>
+ Detailing scenario (Ann): 4 hours
+ </li>
+ <li>
+ Designing scenario (Ann and Jack):&nbsp; 6 hours
+ </li>
+ <li>
+ Implementing and Testing Server portion of scenario (Jack): 22 hours&nbsp;
+ </li>
+ <li>
+ Implementing and Testing Client portion of scenario (Ann): 12 hours
+ </li>
+ <li>
+ <strong>Total Effort Estimate for Scenario:</strong> 44 hours
+ </li>
+</ul>
+<p>
+ If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no
+ point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,
+ you have to do some level of analysis and design of the work item before you can come up with a reasonable estimate.
+ Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to
+ re-estimate the effort required to complete the task, so we have a realistic view of progress within an
+ iteration.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/analyze_arch_reqs.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/analyze_arch_reqs.xmi
new file mode 100644
index 0000000..3bf77a8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/analyze_arch_reqs.xmi
@@ -0,0 +1,204 @@
+<?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" epf:version="1.0.0" xmi:id="-YeVRerdEixh4HgHOuw2KRQ" name="analyze_arch_reqs,_42UD4A3tEduibvKwrGxWxA" guid="-YeVRerdEixh4HgHOuw2KRQ" changeDate="2007-02-26T11:12:32.578+0000" version="1.0.0">
+ <mainDescription><h4>
+ Identify architectural goals
+</h4>
+<p>
+ Architectural goals provide the motivation and rationale&nbsp;for decisions. These goals are&nbsp;often driven
+ by&nbsp;the software requirements, particularly in&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>, because they are not always&nbsp;obvious from&nbsp;the use
+ cases alone [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALL02</a>].
+</p>
+<p>
+ Architectural goals define how the system needs to respond to change over time. Consider these questions when writing
+ your goals:
+</p>
+<ul>
+ <li>
+ What is the expected lifespan of the system?
+ </li>
+ <li>
+ Will the system need to respond to technological changes over that time, such as new versions of middleware or
+ other products?
+ </li>
+ <li>
+ How&nbsp;frequently is&nbsp;the system&nbsp;expected to adapt to change?
+ </li>
+ <li>
+ What changes can we anticipate in the future, and how can we make them easier to accommodate?
+ </li>
+</ul>
+<p>
+ These considerations will have a significant effect on the structure of the system.
+</p>
+<h4>
+ Identify architectural constraints
+</h4>
+<p>
+ Ginformation about the existing&nbsp;environment and identify any constraints in the solution. This will ease
+ integration with the environment; and m ay reduce risk, cost and duplication of solution elements.
+</p>
+<p>
+ Architectural constraints can arise from various factors:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Network topology
+ </li>
+ <li>
+ Use of a given database vendor or an existing database
+ </li>
+ <li>
+ Web environment (server configurations, firewall, DMZs, and so forth)
+ </li>
+ <li>
+ Servers (hardware model, operating system)
+ </li>
+ <li>
+ Use of third-party software or a particular technology
+ </li>
+ <li>
+ Compliance with existing standards
+ </li>
+ </ul>
+</div>
+<p>
+ For example, if the company uses only one type of database, you will probably try to use it as much as possible to
+ leverage&nbsp;the existing database administration skills, rather than introducing a new one.
+</p>
+<p>
+ These architectural constraints, combined with the requirements, help you define&nbsp;an appropriate&nbsp;candidate for
+ the system architecture.
+</p>
+<h4>
+ Survey, assess, and select from available assets
+</h4>
+<p>
+ To assess and select assets to reuse on your project, you need to understand the requirements of the system's
+ environment. You also need to understand the scope and general functionality of the system that the Stakeholders
+ require. There are several types of assets to consider, including (but not limited to): reference architectures;
+ frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&nbsp;repositories (internal or
+ external to your organization) and industry literature to identify assets or similar projects.
+</p>
+<p>
+ You need to assess whether available assets contribute to solving the key challenges of the current project and whether
+ they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
+ between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
+ asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
+ tradeoffs in adopting it are, in terms of cost, risk, and functionality.
+</p>
+<p>
+ Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
+</p>
+<h4>
+ Define approach for structuring the system
+</h4>
+<p>
+ Structuring your system helps you manage its complexity by using the well-known "divide and conquer" strategy. By
+ breaking the process into smaller and more manageable pieces, you make development easier.
+</p>
+<p>
+ Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems. Each
+ layer groups similar classes or components, which communicate insofar as possible only with adjacent layers.&nbsp; See
+ <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.html"
+ guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a> for more information.
+</p>
+<p>
+ You do not define which layers contain which classes or components. Instead, you define how many layers you will need
+ and which kinds of layers you will use. For example, if you are developing a new middleware system, you probably do not
+ need a business layer. Later, during&nbsp;design activities, you decide which classes and components will populate
+ these layers.
+</p>
+<h4>
+ Define approach for deploying the system
+</h4>
+<p>
+ Develop a high level overview of how the software is deployed. For example, determine if the system needs to be
+ accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to
+ consider are:
+</p>
+<ul>
+ <li>
+ users at geographical locations
+ </li>
+ <li>
+ organization of business data
+ </li>
+ <li>
+ service level requirements
+ </li>
+ <li>
+ constraints (such as requirements to interface with legacy systems)
+ </li>
+</ul>
+<p>
+ Validate that the deployment overview supports users (especially those users at remote locations if this is required)
+ performing typical&nbsp;usage scenarios&nbsp;while satisfying nonfunctional requirements and constraints. Validate that
+ the nodes and connections are adequate to support the interactions between components on different nodes, and between
+ components and their stored data.
+</p>
+<h4>
+ Identify key abstractions
+</h4>
+<p>
+ Requirements and analysis tasks usually uncover key concepts that the system must be able to handle. These concepts
+ manifest in design as key abstractions.&nbsp;The <a class="elementLink"
+ href="./../../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> and <a class="elementLink"
+ href="./../../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html"
+ guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> work products are good sources for key abstractions. These abstractions are
+ often easily identified because they represent things that are significant to the business. For example, Customer and
+ Account are typical key abstractions in the banking business.
+</p>
+<p>
+ The abstractions that&nbsp;are identified at this point will also probably change and evolve during the course of the
+ project. The purpose of this step is not to identify&nbsp;the complete&nbsp;set of classes and relationships that will
+ survive throughout design.&nbsp;Rather, it is&nbsp;to identify the&nbsp;important&nbsp;concepts that the system must
+ handle. The value in calling them out arly in the project is that everyone on the team understands the importance of
+ these&nbsp;concepts and develops&nbsp;coherant software to handle them consistently.
+</p>
+<p>
+ Don't spend too much time describing&nbsp;abstractions in detail at this initial stage, because there is a risk that
+ spending too much time will result in identifying classes and relationships that the solution does not actually need.
+ When&nbsp;identifying&nbsp;key abstractions, it can be useful to also define any obvious relationships that exist
+ between them.&nbsp;These can be captured in a table or&nbsp;in diagrams (in a tool or whiteboard), and create a short
+ description for each abstraction.&nbsp;In general, it is not worth agonizing over defining a highly detailed set of
+ relationships at this early stage in design. The relationships will become more concrete and detailed later and
+ will&nbsp;probably modify&nbsp;these early&nbsp;assumptions.
+</p>
+<h4>
+ Identify&nbsp;architecture mechanisms
+</h4>
+<p>
+ See&nbsp;<a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>.
+</p>
+<h4>
+ Capture architectural decisions
+</h4>
+<p>
+ It is often useful to record key architectural decisions and working assumptions on an architectural overview diagram
+ to make it easier to communicate the architecture to the project team and stakeholders.&nbsp;This information should be
+ part of the description of the architecture, but it can vary in format to suit the needs of the project.&nbsp;For
+ example, on an agile and low-ceremony project the overview diagram can be an informal picture story board or a graph
+ with icons on either a whiteboard or a drawing tool. The illustration needs to show the nature of the proposed
+ solution, convey the governing ideas, and represent the major building blocks.
+</p>
+<p>
+ Architecture decisions should be captured in the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture</a>.
+</p>
+<p>
+ If a more complex system is required, then the architecture can be represented as a more comprehensive set
+ of&nbsp;views that describe the architecture from a number of viewpoints. See <a class="elementLink"
+ href="./../../../openup_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html"
+ guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>&nbsp;for more information.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.xmi
new file mode 100644
index 0000000..c3f2ad4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/analyze_arch_reqs_vm.xmi
@@ -0,0 +1,21 @@
+<?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" epf:version="1.0.0" xmi:id="-I-2SvZtjELUYDQO0jvdxEA" name="new_guideline,_SYDjUMUKEdu5GrwIlTJV7g" guid="-I-2SvZtjELUYDQO0jvdxEA" changeDate="2007-02-25T20:57:17.640+0000">
+ <mainDescription><h4>
+ Capture architectural decisions (Visual Modeling)
+</h4>
+<p>
+ You will find it useful to develop these three Unified Modeling Language (UML) diagrams at this stage:
+</p>
+<ul>
+ <li>
+ <strong>Layer map</strong> (represented as a class diagram using packages) that describes the upper-level layers of
+ the architecture
+ </li>
+ <li>
+ <strong>Draft deployment diagram</strong> that outlines the&nbsp;expected network topology
+ </li>
+ <li>
+ <strong>Simple class diagram</strong> that shows the key abstractions and any obvious relationships among them
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/architectural_view.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/architectural_view.xmi
new file mode 100644
index 0000000..c2b230f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/architectural_view.xmi
@@ -0,0 +1,58 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-cnGBBA4NXmhTIjHjlHx4Mw" name=",_T9nygClEEduLGM8dfVsrKg" guid="-cnGBBA4NXmhTIjHjlHx4Mw" changeDate="2006-08-22T11:29:43.831-0700" version="1.0.0">
+ <mainDescription><p> As an Architect, you may want to consider the following views (not all views
+ are relevant to all systems or all the Stakeholders). This set of views is known
+ as the 4+1 Views of Software Architecture</strong> [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">KRU95</a>]..
+</p>
+<p>
+ <img height="254" alt="4+1 Views of Software Architecture" src="./resources/4plus1_2.jpg" width="405" />
+</p>
+<ul>
+ <li>
+ <p> Use-case view:</strong> Describes functionality of the system,
+ its external interfaces, and its principal users. The use-case view&nbsp;contains
+ the <a class="elementLink" href="./../../../openup_basic/workproducts/uc_model,_0UCrZclgEdmt3adZL5Dmdw.html" guid="_0UCrZclgEdmt3adZL5Dmdw">Use-Case
+ Model</a>. This view is mandatory when using the 4+1 Views, because all
+ elements of the architecture should be derived from requirements. </p>
+ </li>
+ <li>
+ <p> Logical view: </strong>Describes how the system is structured
+ in terms of units of implementation. The elements are packages, classes,
+ and interfaces. The relationship between elements shows dependencies, interface
+ realizations, part-whole relationships, and so forth. Note: </strong>This
+ view is mandatory when using the 4+1 Views of Software Architecture. </p>
+ </li>
+ <li>
+ <p>Implementation view: </strong>Describes how development artifacts
+ are organized in the file system. The elements are files and directories
+ (any configuration items). This includes development artifacts and deployment
+ artifacts. This view is optional when using the 4+1 Views. </p>
+ </li>
+ <li>
+ <p>Process view: </strong>Describes how the run-time system is structured
+ as a set of elements that have run-time behavior and interactions. Run-time
+ structure often bears little resemblance to the code structure. It consists
+ of rapidly changing networks of communication objects. The elements are
+ components that have run-time presence (processes, threads, Enterprise JavaBeans&#8482;
+ (EJB&#8482;), servlets, DLLs, and so on), data stores, and complex connectors,
+ such as queues. Interaction between elements varies, based on technology.
+ This view is useful for thinking </strong>about
+ run-time system quality attributes, such as performance and reliability.
+ This view is optional when using the 4+1 Views. </p>
+ </li>
+ <li>
+ <p> Deployment views: </strong>Describe how the system is mapped to
+ the hardware. This view is optional when using the 4+1 Views. </p>
+ </li>
+</ul>
+<p>In addition, you may wish to represent the following, </p>
+<ul>
+ <li>
+ <p> Data view:</strong> A specialization of the logical view. Use
+ this view if persistence is a significant aspect of the system, and the
+ translation from the design model to the data model is not done automatically
+ by the persistence mechanism. </p>
+ </li>
+</ul>
+<p><br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi
new file mode 100644
index 0000000..a30712d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/assign_changes_to_iteration.xmi
@@ -0,0 +1,27 @@
+<?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" epf:version="1.0.0" xmi:id="-bUmvEAAtFf6B0aUCux8k9Q" name="changes_at_iter_bound,__yQQ4L6REdqti4GwqTkbsQ" guid="-bUmvEAAtFf6B0aUCux8k9Q" changeDate="2006-09-22T10:37:52.530-0700">
+ <mainDescription><p>
+ Most iterative software development processes recommend that changes not be introduced during an iteration. The main
+ idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.
+</p>
+<p>
+ To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not
+ assigned for implementation until a future iteration via the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>.
+</p>
+<p>
+ Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change
+ requests.
+</p>
+<p>
+ Consider the following when choosing the future iteration where the change request will be addressed:
+</p>
+<ul>
+ <li>
+ Group similar change requests in the same iteration. For example multiple change requests focused on the same
+ functionality or that are dependent on each other.
+ </li>
+ <li>
+ Assign change requests that mitigate high risks to the earliest iteration possible.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/continuous_integration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/continuous_integration.xmi
new file mode 100644
index 0000000..06d443d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/continuous_integration.xmi
@@ -0,0 +1,32 @@
+<?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="-DlaqJu4sEqMPk84qhJ6IEA" name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" changeDate="2006-05-31T15:26:30.329-0700">
+ <mainDescription><p>
+ [ Don't forget to talk about running developer tests. ]
+</p>
+<p>
+ [Content below taken from step “Accept Integrated Elements and Promote Build" in the Task “Integrate and Create
+ Build"... this Main Description needs to be cleaned up ]
+</p>
+<p>
+ Depending on the complexity and number of&nbsp;components to be integrated, it is often more efficient to produce the
+ target build in a number of steps, adding more&nbsp;components with each step, and producing a series of intermediate
+ 'mini' builds - thus, each build planned for an iteration may, in turn, have its own sequence of transient intermediate
+ builds. These are subjected to a minimal integration test&nbsp;to ensure that what is added is compatible with what
+ already exists in the system integration workspace. It should be easier to isolate and diagnose problems using this
+ approach.&nbsp;
+</p>
+<p>
+ Delivered&nbsp;components are accepted&nbsp;incrementally into the system integration workspace,&nbsp;having any merge
+ conflicts being resolved.&nbsp;It is recommended that this&nbsp;is done in a bottom-up approach with respect to the
+ layered structure, making sure that the versions of the&nbsp;components are consistent, taking imports into
+ consideration. The increment of&nbsp;components is compiled and linked into an intermediate build, which is then
+ provided to the tester to execute a minimal system integration test.
+</p>
+<p>
+ <font size="1"><img height="172" alt="" src="./resources/ac_intsy.gif" width="501" /></font>
+</p>
+<p>
+ This diagram shows a build produced in three increments. Some&nbsp;components are only needed as stubs, to make it
+ possible to compile and link the other components, and provide the essential minimal run-time behavior.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/data_modeling.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/data_modeling.xmi
new file mode 100644
index 0000000..448d846
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/data_modeling.xmi
@@ -0,0 +1,173 @@
+<?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" epf:version="1.0.0" xmi:id="-XMbxFU8M85cRlf3C4iwAGw" name="new_guideline,_ienXEEyAEdu-df7p0PuRvQ" guid="-XMbxFU8M85cRlf3C4iwAGw" authors="Scott Ambler" changeDate="2006-12-01T13:53:01.285-0800" version="1.0.0">
+ <mainDescription><h3>
+ Overview
+</h3>
+Physical data models (PDMs) are used to design the structure of a persistent data store. Typically a PDM is created for a
+single data store, although sometimes a PDM will cover several related data stores (this is particularly true when the data
+storage mechanism is file based). The assumption in this guideline is that you are modeling the schema of a single
+relational database.
+<h3>
+ The Data Model in OpenUP
+</h3>
+The PDM is part of the Work Product: Design. It’s described as different views or perspectives of a portion of the design.
+<h3>
+ Data Model Types
+</h3>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Traditionally, there are three types of data models:
+</p>
+<ol>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ Conceptual. A conceptual model, also referred to as a domain model, depicts the critical business entities and
+ the relationships between them.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ Logical. A logical data model (LDM) adds detail, in particular data attributes and more entities. LDMs will
+ optionally indicate candidate keys (one or more attributes of an entity which uniquely identify it) of an
+ entity. LDMs describe how the design of the system handles the data that will be actually maintained in the
+ PDM.
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-RIGHT: 0px">
+ <p>
+ Physical. A PDM depicts the table structure (in the case of a relational database design), the
+ relationships between the tables, and the primary and foreign keys implemented by the tables. PDMs
+ potentially indicate views, stored procedures, and other database elements.
+ </p>
+ </div>
+ </li>
+</ol>
+<p>
+ For systems built using object and/or component-based technology, the LDM is usually not created in favor of a class
+ model.
+</p>
+<h4 style="MARGIN-RIGHT: 0px">
+ Physical Data Modeling
+</h4>
+<p>
+ The PDM consists of the detailed database table designs and their relationships. The tables in the PDM have
+ well-defined columns, as well as keys and indexes as needed. The tables might also have triggers defined as necessary
+ to support the database functionality and referential integrity of the system. In addition to the tables, stored
+ procedures have been created, documented, and associated with the database in which the stored procedure will reside.
+</p>
+<p>
+ The diagram below shows an example of some of the elements of a PDM. A UML-based notation is used, although other
+ notations such as “crow's feet” or Information Engineering (IE) are also common. This example model is a part of the
+ PDM of a fictional order entry system. It depicts three tables (Order, OrderItem, and Item), three stored procedures
+ (GetOrders, GetTotalBusiness, and TestDatabase), and a trigger on Order named deleteOrderItems. The figure also depicts
+ the columns of each table, the primary key for each table, and any foreign keys to other tables.
+</p>
+<p>
+ <strong>Example Physical Data Model</strong>
+</p>
+<p>
+ &nbsp;<img height="309" alt="" src="./resources/PDMSample.JPG" width="597" />
+</p>
+<p>
+ An existing database can be reverse-engineered to populate the PDM if the team has access to a tool that can transform
+ a database into a model.
+</p>
+<h3>
+ How to Model Database Schemas
+</h3>
+<p>
+ Perform the following in an iterative manner:
+</p>
+<ol>
+ <li>
+ Identify tables. A table is similar conceptually to object-orientation’s concept of a class – a table contains a
+ collection of rows of data whereas a class defines a collection of objects. A table could contain rows representing
+ people, places, things, events, or concepts. Examples of tables include Customer, Order, and OrderItem.
+ </li>
+ <li>
+ Identify columns. Each table has one or more columns. A column stores a single data attribute for each row. For
+ example, the Customer table may have columns such as First Name and Surname. A column has a single data type, such
+ as INT, DATETIME, or VARCHAR.
+ </li>
+ <li>
+ Follow accepted modeling conventions. Your organization should have standards and guidelines applicable to data
+ modeling, in particular naming conventions,&nbsp;that you should follow.
+ </li>
+ <li>
+ Identify relationships between tables. In the real world entities have relationships with other entities. For
+ example, customers PLACE orders, customers LIVE AT addresses, and line items ARE PART OF orders. These
+ relationships will exist between the rows of data stored in the corresponding tables.
+ </li>
+ <li>
+ Assign keys. A key is one or more columns that uniquely identify a row in a table. A primary key is the preferred
+ key for a table. For example, the Customer table may have two potential keys, CustomerID and SocialSecurityNumber.
+ You could choose to use CustomerID as the primary key, thereby making SocialSecurityNumber a secondary key. Foreign
+ keys are used to maintain relationships between rows.
+ </li>
+ <li>
+ Normalize to reduce data redundancy. Data normalization is a process in which columns within a PDM are organized to
+ increase the cohesion of tables. In other words, the goal of data normalization is to reduce and even eliminate
+ data redundancy, an important consideration for application developers because it is incredibly difficult to store
+ objects in a relational database that maintains the same information in several places.
+ </li>
+ <li>
+ De-normalize to improve performance. Normalized data schemas, when put into production, often suffer from
+ performance problems. An important part of data modeling is to de-normalize portions of&nbsp;the data schema, to
+ increase data redundancy by storing the same information in several places or manners, to improve database access
+ times.
+ </li>
+</ol>
+<h3>
+ Data Modeling Throughout the Lifecycle
+</h3>
+<h4>
+ Inception Phase
+</h4>
+<p>
+ During the Inception phase the goal is to identify high-level requirements for the system so that the scope may be
+ identified and project funding obtained. Little, if any, data modeling is performed at this point although some
+ conceptual modeling may occur. Detailed data models are usually not needed at this point.
+</p>
+<h4>
+ Elaboration Phase
+</h4>
+<p>
+ The goal of the Elaboration phase is to eliminate technical risk and to produce a stable (baselined) architecture for
+ the system. One of several architectural issues that is likely to arise is data architecture. To support this effort,
+ you will need to model the major database structures (tables, indexes, and primary and foreign key columns) and then
+ create the database schema from the model (ideally it would be generated from a modeling tool).
+</p>
+<p>
+ Additionally, representative data volumes may be loaded into the database to support performance testing. Based on the
+ results of performance testing, the PDM might need to be adjusted with optimization techniques, including but not
+ limited to de-normalizing, optimizing physical storage attributes, or distribution and indexing.
+</p>
+<h4>
+ Construction Phase
+</h4>
+<p>
+ During the Construction phase the goal is to build a working system that is ready to be released. During each
+ iteration&nbsp;the&nbsp;design, implementation, and tests are fleshed out to implement that iteration's requirements.
+ In other words development artifacts, including your data-oriented artifacts, evolve over time. To support data model
+ changes you may discover the need to refactor your existing database schema.
+</p>
+<h4>
+ Transition Phase
+</h4>
+<p>
+ The PDM is maintained during the Transition phase in response to approved change requests. You should keep the PDM
+ synchronized with the database as the application goes through final acceptance test and is deployed into production.
+</p>
+<h3>
+ Round-trip Engineering Considerations
+</h3>
+<p>
+ If a development team is using modern visual modeling tools that have the ability to convert classes to tables (and
+ vice versa) or has the ability to reverse and forward engineer databases, then the team needs to establish guidelines
+ for managing the transformation and engineering processes. The development team must define the points in the
+ development of the application (build-and-release cycle) at which it will be appropriate to perform the class-to-table
+ transformations and to forward-engineer the database. Once the initial database is created, the development team must
+ define guidelines for the team to manage the synchronization of the PDM and database as the design and code of the
+ system evolve throughout the project.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/design.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/design.xmi
new file mode 100644
index 0000000..d1039cc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/design.xmi
@@ -0,0 +1,218 @@
+<?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="_Qo7pYMM3EdmSIPI87WLu3g" name="design,_0X3bcMlgEdmt3adZL5Dmdw" guid="_Qo7pYMM3EdmSIPI87WLu3g" changeDate="2006-09-09T09:28:07.410-0400">
+ <mainDescription><p>
+ The design represents the behavior and structure of the system at various levels of abstraction – most notably not
+ solely at the code level of abstraction.&nbsp; This will help the designer reason&nbsp;about the quality, structure,
+ and behavior&nbsp;of the design.
+</p>
+<h3>
+ Multiple Passes
+</h3>
+<p>
+ The design will be revisited many times throughout the iterative lifecycle and even within an iteration.&nbsp;
+</p>
+<p>
+ Each time some design activity is being performed, it will be performed with some specific goal.&nbsp; The goal might
+ be to identify a notional set of participants in a collaboration that can be exercised to realize the behavior required
+ (an analysis pass).&nbsp; The goal might be in the identification of some coarse-grained elements that are required to
+ act out some scenario (an architectural pass).&nbsp; Then a pass might be done within one of those components to
+ identify the elements within that will collaborate together to perform the behavior required (a more detailed design
+ pass).
+</p>
+<p>
+ Design might be performed in a particular context such as database context, user-interface context, or perhaps the
+ context of how some existing library will be applied.&nbsp; In these cases the design steps will be performed just to
+ make and communicate decisions regarding that context.
+</p>
+<p>
+ Avoid analysis paralysis.&nbsp; Avoid refining, extending, and improving the design beyond a minimal version that
+ suffices to cover the needs of the requirements within the architecture.&nbsp; Design should be done in small chunks,
+ proven via implementation, improved via refactoring, and integrated into the baseline to provide value to the
+ stakeholders.
+</p>
+<h3>
+ Identification of&nbsp;Elements
+</h3>
+<p>
+ Identify the&nbsp;elements based on needs of the requirements.
+</p>
+<p>
+ The identification of elements can stem from a static perspective of walking through the requirements and identifying
+ elements clearly called out, a form of domain modeling.&nbsp; It can pull in other elements identified as being in the
+ application domain or deemed necessary from examining the requirements for the portion of the system being
+ designed.&nbsp; This can also pull from key abstractions identified while defining the architecture.
+</p>
+<p>
+ The identification of&nbsp;elements&nbsp;should&nbsp;apply a dynamic perspective&nbsp;by&nbsp;walking through scenarios
+ of usage of the system (or subsystem) identifying elements needed to support&nbsp;the behavior.&nbsp; That behavior
+ might be a scenario of usage from an external user perspective or, while designing a subsystem, a responsibility
+ assigned to the subsystem that has complex algorithmic behavior. Consider applying the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;to identify the elements necessary to support
+ the scenario or apply other patterns identified in the architecture that specify the elements that will be used to
+ support specific aspects of the scenario.
+</p>
+<p>
+ If the system being designed is a real-time system, include elements representing events and signals that allow us to
+ describe the asynchronous triggers of behavior to which the system must respond.&nbsp; Events are specifications of
+ interesting occurrences in time and space that usually (if they are noteworthy) require some response from the
+ system.&nbsp; Signals represent asynchronous mechanisms used to communicate certain types of events within the system.
+</p>
+<p>
+ If there are existing&nbsp;elements from previous passes over the design or from selected frameworks or other reusable
+ elements, those should be reused whenever possible.
+</p>
+<p>
+ Having identified the elements, each should be given a meaningful name.&nbsp; Each element should also have a
+ description so that the team members that work together to refine the design and implement from&nbsp;the
+ design&nbsp;will understand the role the&nbsp;element will play.
+</p>
+<p>
+ Based on the above, this identification of&nbsp;elements&nbsp;could be applied a number of times in designing just one
+ part of the system.&nbsp; While there is no&nbsp;one correct&nbsp;strategy for multiple passes, they could be done at a
+ coarse-grained level and then a fine-grained level or at an analysis (abstract) level and then a design level.
+</p>
+<h3>
+ Behavior&nbsp;of&nbsp;Elements
+</h3>
+<p>
+ To&nbsp;identify the behavior&nbsp;of the elements, walk through scenarios assigning behavior to the appropriate
+ collaborating participant.&nbsp; If a particular usage of the system or subsystem can have&nbsp;multiple possible
+ outcomes or variant sequences, cover enough scenarios to ensure that the design is robust enough to support the
+ necessary possibilities.
+</p>
+<p>
+ When assigning behavior to elements, consider applying the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;or other patterns identified in the
+ architecture.
+</p>
+<p>
+ Behavior can be&nbsp;represented as&nbsp;a simple statement of responsibility or it can be a detailed operation
+ specification.&nbsp; Use the appropriate level of detail to communicate important design decisions while&nbsp;giving
+ the freedom to make appropriate implementation decisions as those tasks ensue.
+</p>
+<p>
+ Behavior must be understood as a responsibility on an element, and as an interaction between two&nbsp;elements in the
+ context of some broader behavior of the system or subsystem.&nbsp; The latter part of this will lead the developer to
+ identify relationships needed between the elements.
+</p>
+<p>
+ Avoid too much&nbsp;identification of behavior solely from the perspective of domain modeling.&nbsp; Only include
+ behavior that is really needed, behavior identified by walking through required scenarios of system usage.
+</p>
+<h3>
+ Design&nbsp;Element Relationships
+</h3>
+<p>
+ The relationships between the&nbsp;elements necessary for the behavior must be designed.&nbsp; This can simply be the
+ identification of&nbsp;the ability&nbsp;to traverse from one&nbsp;element to another or a need to manage an association
+ between the elements.
+</p>
+<p>
+ More detailed design can be performed on the relationships as appropriate.&nbsp; This can include optionality,
+ multiplicity, whether the relationship is a simple dependency or managed association, etc. These decisions that drive
+ implementation details are best made at the design level when it is&nbsp;easier to see how all the pieces fit
+ together.&nbsp;
+</p>
+<p>
+ As with the behavior discussion above, avoid defining too many relationships based on relationships in the application
+ domain.&nbsp; Only include the relationships that are really needed based on the requirements.&nbsp; On the other hand,
+ a combination of requirements knowledge and domain knowledge can lead to some detailed decisions on the relationships
+ such as optionality and multiplicity.
+</p>
+<h3>
+ Refine Design
+</h3>
+<p>
+ Having identified a design&nbsp;including a set of collaborating&nbsp;elements with the behavior and relationships
+ robust enough to handle the requirements under consideration, the design can be improved and transformed into an
+ implementable system through refinement.
+</p>
+<p>
+ The visibility of each operation should be selected to be as&nbsp;restrictive as possible.&nbsp; Based on walking
+ through the scenario it should be clear which operations must be&nbsp;available to other elements in the design and
+ which can be considered private behavior inside the element that has the operation.&nbsp; Minimizing the number of
+ public operations creates a more maintainable and understandable design.
+</p>
+<p>
+ With respect to parameters, the return value, and&nbsp;a description of how it will go about performing the behavior,
+ operations can be detailed at a lower level that drives the actual implementation or that detail might be left to
+ be&nbsp;handled when writing the code.
+</p>
+<p>
+ Data attributes can be identified based on information needed to support behavior or based on additional requirements
+ such as information to be presented to the user or transmitted to another system.&nbsp; Avoid indiscriminate domain
+ analysis; there might be a great deal of data in the domain that is not needed to support the requirements.&nbsp; Data
+ attributes can simply be identified or they can be designed in detail with attribute types, initial values, and
+ constraints. Decide on the visibility of the data attribute; operations to access and update the data can be added or
+ deferred to implementation.
+</p>
+<p>
+ Generalization&nbsp;and interfaces can be applied to simplify or otherwise improve the design.&nbsp; Ensure that the
+ usage of these techniques actually improves the design rather than muddling it with complexity.&nbsp; For example,
+ common behavior can be factored into a parent class via generalization or out to a helper class via delegation; the
+ latter solution can be more understandable and maintainable as generalization is an inflexible relationship.
+</p>
+<p>
+ The refinement of any portion of the design could include another pass through the design process.&nbsp; One might find
+ that what was initially identified as a single behavior on an&nbsp;element&nbsp;warrants a detailed walkthrough of the
+ collaborating&nbsp;elements to realize that behavior.
+</p>
+<p>
+ When updating an existing design <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ –</span> especially one that has had portions already implemented <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: Batang; mso-bidi-font-family: Arial; mso-ansi-language: EN-US; mso-fareast-language: KO; mso-bidi-language: AR-SA">
+ –</span> apply <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> to ensure that the improved design continues to perform as expected.
+</p>
+<h4>
+ Organization of&nbsp;Elements (package-level)
+</h4>
+<p>
+ In a design of any notable size, the&nbsp;elements must be organized into packages.&nbsp; Assign the&nbsp;elements to
+ existing or new packages and ensure that the visibility relationships between the packages support
+ the&nbsp;navigability required between the elements.&nbsp; Decide whether each element should be visible to elements
+ outside its package.
+</p>
+<p>
+ When structuring the design into packages, consider <a class="elementLink" href="./../../../openup_basic/guidances/guidelines/layering,_0gpkAMlgEdmt3adZL5Dmdw.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Layering</a>&nbsp;and other patterns.&nbsp; Though all design work must conform to
+ existing architectural decisions, the allocation of&nbsp;elements to packages and possible updates to package
+ visibility is an area of&nbsp;significant architectural concern.&nbsp; The developer should collaborate with the
+ architect to ensure that package-level decisions are in accordance with the rest of the architecture.
+</p>
+<p>
+ This guideline first talks about the identification and design of the&nbsp;elements and then about organizing
+ the&nbsp;elements into packages.&nbsp; This is not a strict order of events.&nbsp; There is nothing wrong with
+ identifying a package structure for the system and then populating that structure with identified&nbsp;elements&nbsp;as
+ long as the actual&nbsp;elements identified are allowed to influence the resulting package structure.
+</p>
+<h3>
+ Reviewing the Design
+</h3>
+<p>
+ Design is best done collaboratively as it is a problem-solving activity with a range parts and perspectives.&nbsp;
+ There should be a constant level of review to ensure that the decisions make sense within the area being designed and
+ in the design of the system overall.&nbsp; There also might be occasions where the review of some area of design is
+ reviewed by a set of interested or knowledgeable parties such as the architect who will verify that the design conforms
+ to some architectural decision or a developer&nbsp;who will be expected to implement the design.&nbsp;
+</p>
+<p>
+ The design should be examined to ensure that it follows heuristics of quality design such as loose coupling and high
+ cohesion.&nbsp; Responsibilities should be appropriately&nbsp;distributed to elements such that there are no elements
+ with too much responsibility and no elements are left without any responsibilities.&nbsp; The design should be able to
+ clearly&nbsp;communicate the design decisions while not delving into concerns best dealt with during implementation of
+ code.
+</p>
+<p>
+ Ensure the design follows any project-specific guidelines and conforms to the architecture.
+</p>
+<p>
+ Modifications to the design to improve it based on issues identified in reviewing it should apply <a class="elementLink" href="./../../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> to ensure that the design and any existing implementation of the design
+ continues to fulfill its responsibilities.
+</p>
+<h3>
+ Relationship of Design to Architecture
+</h3>
+<p>
+ This guideline remarks on conforming to the architecture in various ways; it is written as though one is designing
+ within a pre-existing architecture.&nbsp; Though projects will often have pre-existing architectures available, a
+ particular architecture is the result of design activities.&nbsp; Therefore, in addition to discussing conformance to
+ some existing architecture, one must also consider the creation of the architecture and updates and improvements to the
+ architecture based on the work of design.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/design_components.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/design_components.xmi
new file mode 100644
index 0000000..7fb5834
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/design_components.xmi
@@ -0,0 +1,4 @@
+<?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="-6ep_EyK3ZO6vRGWtAqoJ-A" name="design_components,_CFAswNbzEdqu5o2S60g5LA" guid="-6ep_EyK3ZO6vRGWtAqoJ-A" changeDate="2006-04-28T13:31:47.784-0700">
+ <mainDescription>&nbsp;</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/designing_visually.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/designing_visually.xmi
new file mode 100644
index 0000000..ae797b0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/designing_visually.xmi
@@ -0,0 +1,189 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-1xE2ZW3MjNAJ7jkaZNbkww" name="visual_modeling,_1fM3AC9_EduW5uTjiIcspQ" guid="-1xE2ZW3MjNAJ7jkaZNbkww" changeDate="2006-11-21T11:21:26.464-0800" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Using visual modeling techniques to design software can help break down complex problems into a series of smaller,
+ easier to manage tasks. Sharing pictures rather than written documents or source code also helps the understanding and
+ communication of difficult concepts. Adopting standard modeling notations such as the UML increases this capability by
+ helping to make diagrams precise and unambiguous.
+</p>
+<p>
+ The degree of formality used when producing and disseminating models should vary according to your needs. Small,
+ collaborative teams modeling around whiteboards and capturing the results on a sheet of paper or with digital cameras
+ can yield good results. This can also help the team focus on producing software with the help of models; rather than
+ becoming sidetracked into over-engineering both the models and the solution. Modeling tools provide additional value to
+ projects, especially for more complex systems. Their specifics of use are outside the scope of this guideline, however.
+</p>
+<p>
+ This guideline does not describe a formal sequential progression through prescriptive design steps. Whether some or all
+ of these techniques are needed, or how long is spent on them will vary depending on real-world issues such as the
+ complexity of the requirements; the experience of the designer; and the way the team works.
+</p>
+<p>
+ This guideline uses a simplified scenario (Login) to help keep the focus on understanding the techniques rather than
+ the specific requirements. In the real-world, it is doubtful that much time would be spent modeling a simple problem.
+ Here is the use case diagram, for reference;
+</p>
+<p>
+ <img height="142" alt="User Login Use Case Model" src="./resources/UserLoginUCM.JPG" width="472" />
+</p>
+<h3>
+ Identify elements
+</h3>
+<p>
+ Render the identified design elements as classes in a UML diagram.&nbsp; Apply appropriate stereotypes and optionally
+ render the class using an icon specific to the stereotype to characterize the intent of the class in the design.&nbsp;
+ Name and briefly describe the classes in a few sentences. Do not spend too much time working on associations, as these
+ will be developed through working on collaborations in the next step.
+</p>
+<p>
+ Classes can be drawn as a basic UML rectangle or with a specific symbol associated with a particular stereotype.
+</p>
+<p>
+ The resulting class diagram should be conceptually similar to this one:
+</p>
+<p>
+ <img height="228" alt="Identify Elements - Initial Class Model" src="./resources/IdentifyElementsBCE.JPG" width="290" />
+</p>
+<p>
+ For this example, the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> has been used to derive two classes (LoginUI and
+ LoginController). In addition, two design elements already identified in the architecture (SecuritySystemInterface and
+ User) have also been incorporated.
+</p>
+<h3>
+ Determine how elements collaborate to realize the scenario.
+</h3>
+<p>
+ When determining collaboration, two kinds of diagrams are useful.
+</p>
+<ul>
+ <li>
+ A dynamic object diagram, showing how the design elements collaborate to realize the requirements.
+ </li>
+ <li>
+ A static class diagram, showing the classes involved in realizing the requirements.
+ </li>
+</ul>
+<p>
+ Remember to also update any other impacted diagrams as appropriate, based on modifications or additions to the design.
+</p>
+<p>
+ Create a number of dynamic object diagrams that walk through how a set of objects collaborate to perform the behavior
+ of the scenarios.&nbsp; Even if just one scenario is being designed, this might take multiple diagrams to render it in
+ smaller, understandable chunks or from multiple contexts.
+</p>
+<p>
+ <img style="WIDTH: 776px; HEIGHT: 355px" height="355" alt="User Login Sequence Diagram" src="./resources/UserLoginSeq.JPG" width="776" />
+</p>
+<p>
+ The above sequence diagram shows the user credentials being passed through to the security system for authentication.
+ Steps in the use case scenario are transformed into messages between the participating objects. The messages in this
+ example are not yet fully formed (there are no parameters or return values), so they are prefixed with “//” to show
+ that more work is needed.&nbsp; A sequence diagram was used in this example, but a communication diagram could have
+ been used.
+</p>
+<p>
+ It&nbsp;can be&nbsp;useful to create one or more static class diagrams that show the classes in the design that support
+ the realization.&nbsp; These class diagrams are often called View of Participating Classes diagrams, they provide a
+ focused view on the overall design by only showing the classes, relationships, operations, and attributes relevant to
+ the collaboration.
+</p>
+<p>
+ <img height="469" alt="Login VOPC" src="./resources/login_vopc.jpg" width="448" />
+</p>
+<p>
+ This diagram shows the operations and relationships that were identified by drawing the sequence diagram. The
+ relationships in this example&nbsp;have not been refined yet, so they are just shown as simple associations. Remember
+ to examine the diagram to verify that the design can support the behavior in the sequence diagram.
+</p>
+<p>
+ Working at this level of detail in the model during the early stages of design can be helpful. It keeps the diagrams
+ relatively simple and easy to understand. It makes them easier to draw in a workshop and easier to change during
+ discussion. It is often easier to add the detail once there is agreement on the fundamentals.
+</p>
+<h3>
+ Refine design decisions
+</h3>
+<p>
+ Once the fundamentals of the design are relatively stable, you can begin to add detail to the design. Some of this can
+ be performed in code or in the model. If modeling is chosen, then refine attributes, responsibilities and
+ relationships.
+</p>
+<h4>
+ Describe responsibilities
+</h4>
+<p>
+ Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to other
+ objects. Each class will typically have several responsibilities; each responsibility will evolve into one or more
+ operations during design.
+</p>
+<p>
+ Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has
+ to support. Document a responsibility by giving it a name, and optionally a brief description (what it does).
+</p>
+<p>
+ These operations can be left as self-evident from their context, they can be given textual descriptions of the
+ algorithm required to perform the behavior, or they could spawn off another whole pass of this technique where a set of
+ classes that collaborate together to perform the internals of the operation are identified, etc.
+</p>
+<h4>
+ Describe attributes and associations
+</h4>
+<p>
+ A class may have to store simple data information, like: string, integer, and the like. For such simple type of
+ information, attributes are defined for classes. For a more complex or "behavioral” attribute, consider creating an
+ extra class and establish an association to it.
+</p>
+<p>
+ To perform their responsibilities, classes may depend on other classes to supply needed behavior. These other classes
+ might be ones already identified in this design session, they might be existing classes pulled from the architecture,
+ or the need for new classes might be conceived. Associations in a class diagram can be used to represent inter-class
+ relationships.
+</p>
+<p>
+ <img height="439" alt="Login VOPC (Refined)" src="./resources/login_vopc_refined.jpg" width="557" />
+</p>
+<p>
+ This diagram shows a number of refinements. The LoginUI class has been replaced by LoginForm. The User class has been
+ renamed UserCredentials and is created by the LoginForm class rather than LoginController. It is then used as a
+ parameter for subsequent messages rather than passing the individual attributes. The SecuritySystemInterface class has
+ been refined into two elements, ISystemSecurity, which provides a simple façade for interaction with the rests of the
+ design; and SecuritySystemProxy, which handles interaction with the external security system.
+</p>
+<h3>
+ Design internals
+</h3>
+<p>
+ The classes in the design are likely to need to be distributed amongst different packages and subsystems or components.
+</p>
+<p>
+ <img height="304" alt="User Login - Design Packages" src="./resources/dv_Packaging.JPG" width="571" />
+</p>
+<p>
+ In this example, the LoginForm, LoginController and UserCredentials elements have been placed in a package called
+ LocalSecurity. The SecuritySystemProxy is a part of a subsystem called SecuritySystemAdapter which realizes the
+ ISecuritySystem interface. The SecuritySystemAdapter wraps the legacy SecuritySystem, expressed here as a component
+ offering a validateUser interface.
+</p>
+<p>
+ Each of these packaged elements can be distributed amongst the team for further development work.
+</p>
+<h3>
+ Conclusion
+</h3>
+<p>
+ This guideline walked through the techniques in a concrete manner started with a scenario of a use case through to
+ distributing the classes identified into a set of packages. This example demonstrates a technique for designing
+ visually, but it should be considered as just one conceptual pass of design.&nbsp; One could as easily apply this
+ technique when defining the internals of how the SecuritySystemProxy class will collaborate with a set of classes to
+ validate the credentials.
+</p>
+<p>
+ When applying this guideline, work in small chunks and keep in mind the goal of delivering software to the users that
+ provides value. To deliver high-quality software requires consideration of how the pieces will work together to deliver
+ that value. But as soon as key decisions have been made and the decisions have been communicated to the appropriate
+ team members, the team should move on to implementing the source code to verify the design and deliver the value.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.xmi
new file mode 100644
index 0000000..c896cda
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/detail_ucs_and_scenarios.xmi
@@ -0,0 +1,183 @@
+<?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" epf:version="1.0.0" xmi:id="-78ko4CuOJERKJF9ZvwMUBQ" name="detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q" guid="-78ko4CuOJERKJF9ZvwMUBQ" changeDate="2007-01-05T13:31:41.729-0500" version="1.0.0">
+ <mainDescription><h4>
+ Most efficient way to write use cases
+</h4>
+<p>
+ Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we
+ learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in
+ others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary work
+ and rewriting.
+</p>
+<p>
+ An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an
+ effective way to write use cases. This breadth-first approach involves two aspects: writing the set of use cases and
+ writing individual use cases.
+</p>
+<p>
+ <strong>Writing sets of use cases:</strong> Use cases exist in sets, and the relationships between the various use
+ cases and Actors&nbsp;are important. As you learn more about the Actors, you also learn more about the system's
+ boundaries and transactions. Likewise, as you learn more about the system's transactions, you learn more about its
+ Actors. Therefore, it is more efficient to write several use cases simultaneously than to write them sequentially. This
+ way, you can identify and understand the effects of the various use cases upon each other as you write them, rather
+ than as afterthoughts that require rewriting or elimination of previous work.
+</p>
+<p>
+ <strong>Writing individual use cases.</strong> Similarly, it makes sense to write each individual use case iteratively.
+ Starting with the main scenario, you can then identify various alternative and error flows that the use case might
+ follow, then evaluate, rearrange or eliminate them, and then add the details of the surviving scenarios.
+</p>
+<p>
+ The level of detail that you capture depends on a number of factors. See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html"
+ guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a> for guidance on selecting the correct format for your
+ use cases.
+</p>
+<h4>
+ Detail the flow of events of the main scenario
+</h4>
+<p>
+ As a starting point, use the step-by-step description of the main scenario that you created during <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>. Then, gradually add details to this scenario,
+ describing <strong>what</strong> the use case does, <strong>not how</strong> to solve problems internal to the system.
+</p>
+<p>
+ A flow of events description explores:
+</p>
+<ul>
+ <li>
+ How and when the use case starts
+ </li>
+ <li>
+ When the use case interacts with the Actors, and what data they exchange
+ </li>
+ <li>
+ When the use case uses data stored in the system or stores data in the system
+ </li>
+ <li>
+ How and when the use case ends
+ </li>
+</ul>
+<p>
+ It does not describe:
+</p>
+<ul>
+ <li>
+ The GUI
+ </li>
+ <li>
+ Technical details of hardware or software
+ </li>
+ <li>
+ Design issues
+ </li>
+</ul>
+<h4>
+ Identify alternate flows
+</h4>
+<p>
+ A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to
+ specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways
+ that the system provides a behavior, or it may describe failure or exception cases.
+</p>
+<p>
+ As you detail the main scenario, identify alternate flows by asking these questions:
+</p>
+<ul>
+ <li>
+ Are there different options available, depending on input from the Actor? (for example, if the Actor enters an
+ invalid PIN number while accessing an ATM)
+ </li>
+ <li>
+ What business rules may come into play? (for instance, the Actor requests more money from the ATM than is available
+ in her account)
+ </li>
+ <li>
+ What could go wrong? (such as no network connection available when required to perform a transaction)
+ </li>
+</ul>
+<p>
+ It is best to develop these scenarios iteratively, as well. Begin by identifying them. Examine each possible scenario
+ to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios.
+ Eliminate redundant or unnecessary scenarios, and then start elaborating on the more important ones.
+</p>
+<h4>
+ Structure the use case
+</h4>
+<p>
+ It is useful to structure the use case according to scenarios. This helps both to simplify communication and
+ maintenance and to permit the use cases to be implemented iteratively.
+</p>
+<p>
+ In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios
+ themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress.
+ Unless a sub-flow involves only a minor part of the complete flow of events (which can be described in the body of the
+ text), it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Sub-flows
+ that should be in a separate section include these examples:
+</p>
+<ul>
+ <li>
+ Sub-flows that occupy a large segment of a given flow of events.
+ </li>
+ <li>
+ Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more
+ clearly.
+ </li>
+ <li>
+ Any sub-flow that can be executed at several intervals in the same flow of events.
+ </li>
+</ul>
+<p>
+ For more information, see the "Flow of Events - Structure"&nbsp;section in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<h4>
+ Describe special requirements
+</h4>
+<p>
+ You should also capture any requirements that are related to the use case, but are not taken into consideration in the
+ flow of events of the use case. Such requirements are likely to be nonfunctional.
+</p>
+<p>
+ Typically, nonfunctional requirements that refer to a specific use case are captured in the special requirements
+ section of the use case. For more information, see the "Special Requirements" section in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p>
+<p>
+ If there are nonfunctional requirements that apply to more than one use case, capture these in the <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>. For more information on supporting requirements
+ see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html"
+ guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.<br />
+</p>
+<h4>
+ Describe preconditions and postconditions
+</h4>
+<p>
+ A <strong>precondition</strong> on a use case explains the state that the system must be in for the use case to be able
+ to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that
+ may already have taken place.
+</p>
+<p>
+ A <strong>postcondition</strong> on a use case lists possible states that the system can be in at the end of the use
+ case execution. The system must be in one of those states. A postcondition also states actions that the system performs
+ at the end of the use case, regardless of what occurred in the use case. Post-Conditions may be categorized as Minimal
+ Guarantees&nbsp;or Success Guarantees.&nbsp; A Minimal Guarantee represents a condition that will be true when the use
+ case ends, regardless of how it terminates.&nbsp; A Success Guarantee represents a condition that will be true when the
+ use case ends successfully, regardless of which path it took.
+</p>
+<p>
+ Neither preconditions nor postconditions should be used to create a sequence of use cases. As a general rule, there
+ should never be a case where you have to first perform one use case and then another to have a meaningful flow of
+ events. If that is the case, correct the problem by reviewing the use cases.&nbsp;For more information, see the
+ "Preconditions" and "Postconditions" sections in <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case,_KudM0NcJEdqz_d2XWoVt6Q.html"
+ guid="_KudM0NcJEdqz_d2XWoVt6Q">Concept: Use Case</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/develop_architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/develop_architecture.xmi
new file mode 100644
index 0000000..8fe9c7c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/develop_architecture.xmi
@@ -0,0 +1,195 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-t7mQSRPYITkMoYRVNz7jQg" name="develop_architecture,_mDf2EBapEduSTJywppIxVQ" guid="-t7mQSRPYITkMoYRVNz7jQg" changeDate="2007-02-26T03:44:53.453-0800" version="1.0.0">
+ <mainDescription><h4>
+ Identify architectural priorities
+</h4>
+<p>
+ Architecture&nbsp;priorities&nbsp;can take the form of&nbsp;one or more <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s brought into scope by association to the scenarios
+ prioritized for the current iteration. Other drivers may also be apparent. For example, it may be necessary to move
+ certain aspects of the architecture from prototypical to production quality implementation; or explore certain aspects
+ of the architecture to inform future iterations.
+</p>
+<p>
+ The architectural&nbsp;priorities are often&nbsp;driven by&nbsp;the development of software that implements an&nbsp;<a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>.&nbsp;It is important to specify the qualities of these
+ mechasnisms precisely and this may lead you to supplement the usage scenarios with quality attributes. As more than one
+ usage scenario may plkace demands on the same mechanisms, it may be helpful to consolidate these into quality
+ scenarios.
+</p>
+<p>
+ For example, if you want a system to be secure, specify the types of threats. Quality scenarios are one way to express
+ desired qualities in collaboration with the system stakeholders [<a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">KAZ04</a>]. Walk through things that could happen to the system and How it would
+ respond. <strong>Use-case scenarios</strong> focus on run-time behavior where the stakeholder is the user.
+ <strong>Quality scenarios</strong> encompass other interactions with the system as well, such as system maintenance
+ staff modifying the system.
+</p>
+<p>
+ Several scenarios may be devised for each quality attribute (such as usability, reliability, performance,
+ or&nbsp;security). For instance, security scenarios for denial of service and unauthorized access. A good scenario
+ makes clear what the stimulus is, what causes it, and what responses are appropriate.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ During peak operation, an unauthorized intruder tries to download prohibited data through the system
+ administrator’s interface. The system detects the attempt, blocks access, and notifies the supervisor within 15
+ seconds.
+ </p>
+</blockquote>
+<p>
+ After you have collected the scenarios, you need to establish priorities for them. Use scenarios to realize
+ requirements, so that their mapping onto the architecture, their impact, and their interactions can be understood.
+</p>
+<h4>
+ Refine &nbsp;the architecture mechanisms
+</h4>
+<p>
+ Consider each high-priority quality scenario, and map each of these onto the architecture mechanisms. Refine the
+ mechanisms to identify the specific technology&nbsp;to be used&nbsp;to handle each mechanism in scope. For example, for
+ the Persistence mechasnism, it may be appropriate to&nbsp;use a relational database management system such as
+ MySQL.&nbsp;Consider the selection of technology in the context of the requirements and constraints.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a> for more information.
+</p>
+<h4>
+ Identify Business Patterns
+</h4>
+<p>
+ The&nbsp;architecture of&nbsp;a software system can often be characterised by a small number of essential scenarios.
+ For example, for an on-line book store describing the way the software handles the scenarios for ordering a book and
+ checking out the shopping cart are often enough to communicate the essence of the architecture. Such business patterns
+ also provide a useful blueprint for similar functionality throughout the system.
+</p>
+<h4>
+ Identify reuse opportunities
+</h4>
+<p>
+ After looking for similar behavior and returned values, then look for similarity of parameters. If their
+ interfaces&nbsp;are not an exact match for the component interfaces being proposed, you can modify the
+ proposed&nbsp;signatures to increase the degree of reuse. Some design mechanisms, such as performance or security
+ requirements, may disqualify a component from reuse even when there is&nbsp;a perfect match between operation
+ signatures.
+</p>
+<p align="left">
+ A common set of components may exist that provides many of the <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/arch_mech,_mzxI0A4LEduibvKwrGxWxA.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> that you need&nbsp;for the new system. These components may
+ be available either because they were developed or purchased previously for&nbsp;similar systems. Given their
+ suitability and compatibility within the software architecture, there may be a need to reverse-engineer these
+ components to represent them in a design model and reuse them in a project.
+</p>
+<p align="left">
+ Similar thinking applies to&nbsp;existing databases. Part of the information to be used by the application under
+ development may already reside in a database. You may be able to get the classes that represent the database structures
+ that hold this information by reverse-engineering the database.
+</p>
+<h4 align="left">
+ Identify architecturally significant design elements
+</h4>
+<p align="left">
+ Consider&nbsp;each high-priority&nbsp;scenario in scope. Walk through the actions that the&nbsp;scenario initiates and
+ highlight the areas of the architecture that participate in realizing, or implementing, the requirements.
+</p>
+<p>
+ Identifying components will help hide the complexity of the system and help you work at a higher level. Components need
+ to be internally cohesive and to provide external services through a limited interface. Component identification can
+ be&nbsp;based on architectural layers, deployment choices, or key abstractions. Ask yourself these questions:
+</p>
+<ul>
+ <li>
+ What is logically or functionally related (same use case or service, for example)?
+ </li>
+ <li>
+ What entities provide services to multiple others?
+ </li>
+ <li>
+ What entities depend on each other? Strongly or weakly?
+ </li>
+ <li>
+ What entities should you be able to exchange independently from others?
+ </li>
+ <li>
+ What will run on the same processor or network node?
+ </li>
+ <li>
+ What parts are constrained by similar performance requirements?
+ </li>
+</ul>
+<p>
+ Each component includes entities from the problem domain, control classes that coordinate complex tasks within
+ components, and interfaces that handle communication with the environment. The interface for each instantiated element
+ is identified. At this point, interfaces do not need to be as detailed as a signature, but they do need to document
+ what the elements need, what they can use, and what they can depend on.
+</p>
+<p>
+ Identified patterns define the types of elements, but not a specific number. Apply the chosen patterns to define a new
+ set of elements that conform to the patterns. Functionality will be allocated to the instantiated elements.
+</p>
+<h4>
+ Define development and test architectures
+</h4>
+<p>
+ The development and test architectures may be different from the target production implementation.
+</p>
+<ul>
+ <li>
+ Additional software may need to be developed to support testing.
+ </li>
+ <li>
+ Alternative deployment configurations may need to be defined in response to constraints on development hardware.
+ </li>
+ <li>
+ Multiple environments may be required to support different categories of tests.
+ </li>
+</ul>
+<p>
+ In each case, you need to specify the architecture. Also, be sure to consider the impact on the quality of the overall
+ architecture.
+</p>
+<h4>
+ Validate the architecture
+</h4>
+<p>
+ The surest way to validate the architecture is through software. The software developed up to the end of the
+ Elbaoration Phase is largely aiming to validate the architecture, to the point where it can be baselined, thereby
+ providing some level of stability during the Construction phase.
+</p>
+<p>
+ It can also be useful to perform simple validation by walking through the main design concepts and models, perhaps
+ around a whiteboard or through other collaborative techniques. This can help refine thinking but will not act as a
+ subsitute for building some software.
+</p>
+<h4>
+ Communicate decisions
+</h4>
+<p>
+ You can document and communicate your decisions as many ways as you wish:
+</p>
+<ul>
+ <li>
+ Publication of&nbsp;reference source code.
+ </li>
+ <li>
+ Publication of&nbsp;reference models.
+ </li>
+ <li>
+ Publication of&nbsp;software architecture documentation.
+ </li>
+ <li>
+ Formal&nbsp;presentations of the material.
+ </li>
+ <li>
+ Informal walkthroughs of the architecture
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/effective_req_reviews.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/effective_req_reviews.xmi
new file mode 100644
index 0000000..0b3184e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/effective_req_reviews.xmi
@@ -0,0 +1,103 @@
+<?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" epf:version="1.0.0" xmi:id="-pNA0DbSdSoUqnjQIiOeHcQ" name="achieving_concurrence,_E-dPIL-GEdqb7N6KIeDL8Q" guid="-pNA0DbSdSoUqnjQIiOeHcQ" changeDate="2006-09-22T09:09:40.793-0400" version="1.0.0">
+ <mainDescription><p>
+ The cost of correcting errors increases exponentially throughout the development lifecycle <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[BOE88]</a>. Therefore, it is important to discover problems early enough to solve them
+ quickly and inexpensively.
+</p>
+<p>
+ Requirements reviews are intended to discover problems with the <a class="elementLink" href="./../../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;before you spend significant time and work in implementing the
+ wrong thing. This is not to say that you must have a complete set of requirements before implementation, but be sure to
+ review, internally and with stakeholders, those that are selected for implementation in the early iterations and those
+ that will have a broad impact on the system (often called <a class="elementLink" href="./../../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>) to ensure everyone's concurrence before
+ investing significant effort in implementation.
+</p>
+<h4>
+ Informal reviews
+</h4>
+<p>
+ Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a
+ prototype.
+</p>
+<p>
+ These informal reviews are excellent for getting the structure of the requirements correct and removing obvious
+ mistakes. By keeping the review team small, it is easier to make rapid progress. However, informal reviews can miss
+ important perspectives&nbsp;of&nbsp;critical stakeholders.
+</p>
+<h4>
+ Formal reviews
+</h4>
+<p>
+ Requirement reviews can be formal meetings. Start with careful preparation, so that you receive and organize comments
+ before the meeting. The meeting itself should produce decisions on all review items. After the meeting, you must pursue
+ the review actions to completion. If these actions involve a substantial amount of work or require a change to an
+ artifact that is under configuration control, consider submitting <a class="elementLink" href="./../../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a> to prioritize and track the work. See&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Task: Request Change</a>&nbsp;and the associated&nbsp;<a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">Guideline: Change Requests</a>&nbsp;for more information on change requests.
+</p>
+<p>
+ Formal reviews are more wide-ranging and expensive. They provide for more balanced reviews from multiple
+ perspectives.&nbsp; However, formal reviews involve more people, which makes them more difficult to coordinate (thus
+ the need for formality) and expensive in terms of work hours.
+</p>
+<h4>
+ Two-tier reviews
+</h4>
+<p>
+ One technique to get the best of both worlds is to use staged, or "two-tier", reviews&nbsp;<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO03]</a>. The&nbsp;first tier is informal and performed by a smaller team, possibly
+ many times. The second&nbsp;tier is more formal and performed by the complete group, perhaps only once.
+</p>
+<p>
+ <strong>First-tier review:</strong> The authors of the requirements and the development team&nbsp;review the
+ requirements during the first-tier reviews to ensure that they are&nbsp;unambiguous, complete&nbsp;and
+ consistent.&nbsp; It is important to include testers and developers to ensure that the requirements are verifiable and
+ feasible.&nbsp;These reviews&nbsp;determine whether the requirements are ready for the larger community to
+ review.&nbsp; First-tier reviews may be informal, formal, or a combination of the two.
+</p>
+<p>
+ <strong>Second-tier review:</strong> Involve the larger group during the higher-tier review to get more minds working
+ on the problem and to achieve concurrence that the requirements are suitable for implementation and validation.&nbsp;
+ It is best to have one formal requirement review at the Lifecycle Objective (LCO) milestone and, optionally, one at the
+ Lifecycle Architecture (LCA) milestone if significant changes have occurred that introduce unacceptable risk.
+</p>
+<p>
+ At both stages, these two resources will be helpful: <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/good_requirements,_jxn9EO0HEdqHTdbLTmC5IQ.html" guid="_jxn9EO0HEdqHTdbLTmC5IQ">Checklist: Qualities of Good Requirements</a>&nbsp;and <a class="elementLinkWithType" href="./../../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html" guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>
+</p>
+<p>
+ Tiered reviews offer several benefits:
+</p>
+<ol>
+ <li>
+ Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on
+ functionality
+ </li>
+ <li>
+ Provide a professional look to the requirements, presenting both the requirements and their authors in the best
+ possible light
+ </li>
+ <li>
+ Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or
+ diminished effectiveness from overload and stress
+ </li>
+ <li>
+ Provide the best opportunity for full, effective reviews.
+ </li>
+</ol>
+<h4>
+ Golden rules of reviewing
+</h4>
+<p>
+ Follow these golden&nbsp;rules of reviewing <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>:
+</p>
+<ol>
+ <li>
+ <strong>Encourage criticism:</strong> Remember that people are improving the requirements, not criticizing you.
+ Even the harshest criticism often contains a grain of truth. Adopt the attitude that every suggestion is a gift.
+ </li>
+ <li>
+ <strong>Choose your best reviewers:</strong> A few specific people make the best reviewers, time and again.
+ Cultivate them.
+ </li>
+ <li>
+ <strong>Allow adequate time:</strong> It's not over until you have agreed upon and made the corrections.<br />
+ &nbsp;
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.xmi
new file mode 100644
index 0000000..4d99645
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_analysis_mechanisms_descr.xmi
@@ -0,0 +1,59 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-CJ--jlBqXi3FzdOM_dw5_w" name="new_guideline,_V4qNUAn_Edu0OeEVPFogVA" guid="-CJ--jlBqXi3FzdOM_dw5_w" changeDate="2006-07-10T15:10:58.826-0700">
+ <mainDescription><p> The following shows how to capture information for <a class="elementLinkWithType"
+ href="file:///c|/documents%20and%20settings/rbalduino/my%20documents/tng/beacon/copyedit/structure_for_importing/openup_basic/openup_basic/guidances/concepts/analysis_mechanism,_0gvqomlgedmt3adzl5dmdw.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Concept: Analysis Mechanism</a>. </p>
+<h3> Persistence </h3>
+<p>For all classes with instances that may become persistent, you need to identify:
+
+<ul>
+ <li>
+ <p><b>Granularity</b><strong>:</strong> What is the range of size of the objects
+ to keep persistent?</p>
+ </li>
+ <li>
+ <p><b>Volume</b><strong>: </strong>How many objects (number) do you need to
+ keep persistent?</p>
+ </li>
+ <li>
+ <p><b>Duration</b><strong>:</strong> How long does the object typically need
+ to be kept?</p>
+ </li>
+ <li>
+ <p><b>Retrieval mechanism</b><strong>: </strong>How is a given object uniquely
+ identified and retrieved? </p>
+ </li>
+ <li>
+ <p><b>Update frequency</b><strong>: </strong>Are the objects more or less
+ constant? Are they permanently updated? </p>
+ </li>
+ <li>
+ <p><b>Reliability</b><strong>: </strong>Do the objects need to survive a crash
+ of the process, the processor, or the whole system? </li>
+</ul>
+<h3>Communication </h3>
+<p>For all model elements that need
+ to communicate with components or services that are running in other processes
+ or threads, you need to identify </p>
+<ul>
+ <li>
+ <p><b>Latency</b><strong>: </strong>How
+ fast must processes communicate with another? </p>
+ </li>
+ <li>
+ <p><b>Synchronicity</b><strong>:
+ </strong>Asynchronous communication. </p>
+ </li>
+ <li>
+ <p><b>Size of message</b><strong>:
+ </strong>A spectrum might be more appropriate than a single number. </p>
+ </li>
+ <li>
+ <p><strong>Protocol:</strong> Flow control, buffering,
+ and so on.</p>
+ </li>
+</ul>
+<p> Notice that there is no design-level
+ information or specification here. Instead, this is more about collating and
+ refining architecturally significant requirements. </p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_architectural_mechanisms.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_architectural_mechanisms.xmi
new file mode 100644
index 0000000..a4b9f99
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_architectural_mechanisms.xmi
@@ -0,0 +1,258 @@
+<?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" epf:version="1.0.0" xmi:id="-FqP5LgLVrlhvFC_eeYd_vA" name="example_architectural_mechanisms,_4k_HsQ4LEduibvKwrGxWxA" guid="-FqP5LgLVrlhvFC_eeYd_vA" changeDate="2006-09-19T13:56:22.466-0700">
+ <mainDescription><p>
+ Here are some examples of commonly encountered architectural mechanisms.<br />
+ <br />
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Example Architectural Mechanisms" border="1" valign="top">
+ <caption>
+ <strong>Example Architectural Mechanisms</strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ Architectural Mechanism
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Availability
+ </td>
+ <td>
+ The percentage of time that the system must be available for use, including planned outages.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Archiving
+ </td>
+ <td>
+ Provides a means to move data from active storage when it has reached a specific state.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Auditing
+ </td>
+ <td>
+ Provides audit trails of system execution.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Communication
+ </td>
+ <td>
+ A mechanism for handling inter-process communication.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Debugging
+ </td>
+ <td>
+ Provides elements to support application debugging.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Disaster Recovery
+ </td>
+ <td>
+ Provides facilities to recover systems, application, data and networks.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Error Management
+ </td>
+ <td>
+ Allows errors to be detected, propagated, and reported.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Event Management
+ </td>
+ <td>
+ Supports the use of asynchronous events within a system.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Graphics
+ </td>
+ <td>
+ Supports user interface services, such as 3D rendering.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Information Exchange
+ </td>
+ <td>
+ Supports information interchange accross technical and organisational boundaries, with appropriate semantic
+ and format translations.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Licensing
+ </td>
+ <td>
+ Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as
+ part of authorising corporate bodies.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Localisation / Internationalisation
+ </td>
+ <td>
+ Provides facilities for supporting multiple human languages and rendering the language preffered by the
+ user.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mail
+ </td>
+ <td>
+ Services that allow applications to send and receive electronic mail.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mega-data
+ </td>
+ <td>
+ Support for handling very large amounts of data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Memory Management
+ </td>
+ <td>
+ Services for abstracting how memory is allocated and freed.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Meta-data
+ </td>
+ <td>
+ Supports the runtime introspection of components and data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Online help
+ </td>
+ <td>
+ Provides online help capability
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Persistence
+ </td>
+ <td>
+ Services to&nbsp;handle&nbsp;the reading and&nbsp;writing of&nbsp;stored&nbsp;data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Printing
+ </td>
+ <td>
+ Provides facilities for interfacing with printers.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Process Management
+ </td>
+ <td>
+ Provides support for the management of processes and threads.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Reporting
+ </td>
+ <td>
+ Provides flexible reporting facilities
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Resource Management
+ </td>
+ <td>
+ Provides support for the management of expensive resources, such as database connections.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Scheduling
+ </td>
+ <td>
+ Provides the ability to execute tasks at a specified time.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Security
+ </td>
+ <td>
+ Provides services to protect access to certain resources or information.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ System Management
+ </td>
+ <td>
+ Services that facilitate management of applications in an operational environment.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Time
+ </td>
+ <td>
+ Services to synchronise time on a network, and to translate times into different time zones.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Transaction Management
+ </td>
+ <td>
+ A mechanism for handling ACID transactions.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Workflow
+ </td>
+ <td>
+ Support for the movement of documents and other items of work, typically through an organisation.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<br />
+<br />
+<br />
+
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_design_mechanisms.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_design_mechanisms.xmi
new file mode 100644
index 0000000..fcbf77f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/example_design_mechanisms.xmi
@@ -0,0 +1,268 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-mAo18f36rZ1R98kpZX7HMw" name="new_guideline,_K32gYAoBEdu0OeEVPFogVA" guid="-mAo18f36rZ1R98kpZX7HMw" changeDate="2006-07-10T15:11:18.051-0700" version="1.0.0">
+ <mainDescription><h3> Design
+ Mechanism Characteristics and Mapping</h3>
+<p> Consider the analysis mechanism for <strong>persistence</strong>. </p>
+<ul>
+ <li> There might be a need for many (2,000) small objects (200 bytes each) to
+ be stored for a few seconds, with no need for them to
+ survive thereafter. </li>
+ <li> There might be a need for several <strong></strong>very large <strong></strong>
+ objects to be stored permanently on disk for several months, never updated,
+ but with sophisticated means of retrieval. </li>
+</ul>
+<p> These objects require different support
+ for persistency. The best option depends on the characteristics
+ of the design mechanism:</p>
+<ul>
+
+ <li> <b>In-memory storag</b><strong>e: </strong>For up to 1 Mb total (size x
+ volume); very fast access for read, write, update. </li>
+ <li> <b>Flash card</b><strong>:</strong> For up to 8 Mb; slow update and write
+ access; moderate read access. </li>
+ <li> <b>Binary file</b><strong>:</strong> For 100 Kb to 200 Mb; slow update;
+ slow read-and-write access. </li>
+ <li> <b>Database management system (DBMS)</b><strong>: </strong>For 100 Kb and
+ upward (essentially no upper limit); even slower update and read-and-write
+ access. </li>
+</ul>
+<p> Note that these speeds are rated as slow only as compared
+ to in-memory storage. Obviously, in some environments, caching can improve
+ apparent access times. (See Figure 1.)</p>
+<blockquote>
+
+ <p align="center"> <img height="221" title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" alt="Mapping Analyis Mechanisms to Design Mechanisms and Classes" src="./resources/co_dmec1.gif"
+ width="372" /> </p>
+</blockquote>
+<div align="center">
+ <p><strong>Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes</strong></p>
+ <h3 align="left">Mapping Design Mechanisms to Implementation Mechanisms </h3>
+ <p align="left"> The <b>persistence</b> design mechanisms can be mapped to implementation
+ mechanisms as Figure 2 shows: </p>
+ <p align="center"> <img height="216" title="Figure 2. How persistence design mechanism map to implementation mechanism" alt="How persistence design mechanism map to implementation mechanism" src="./resources/co_dmec2.gif" width="325" /></p>
+ <p align="center"><strong>Figure 2. How persistence design
+ mechanism map to implementation mechanism</strong> </p>
+ <p align="left">A possible mapping between analysis mechanisms and design mechanisms.
+ Dotted arrows mean "is specialized by," implying that the characteristics
+ of the design mechanisms are inherited from the analysis mechanisms but that
+ they will be specialized and refined. </p>
+ <p align="left"> After you have finished optimizing the mechanisms, the following
+ mappings exist (see Figure 3): </p>
+ <blockquote>
+ <p align="center"> <img height="110" title="Figure 3. Mapping structure after optimizing the mechanisms" alt="Illustration of mapping structure after optimizing the mechanisms" src="./resources/co_dmec3.gif" width="418" />
+ </p>
+ <p align="center" class="picturetext"><strong>Figure 3. Mapping structure
+ after optimizing the mechanisms </strong></p>
+ <p align="left" class="picturetext">The design decisions for a client class
+ in terms of mappings between mechanisms. The Flight
+ class needs two forms of persistency<strong>:</strong> <strong>in-memory
+ storage</strong>, implemented by a predefined
+ library routine, and <strong>a database,</strong> implemented with an off-the-shelf
+ ObjectStorage product. </p>
+ </blockquote>
+ <p align="left"> The map must be navigable in both directions to make it easy
+ to determine client classes when changing implementation mechanisms. </p>
+ <h4 align="left">Refining
+ the mapping between design and implementation mechanisms </h4>
+</div>
+<p> Initially, the mapping between design mechanisms and implementation mechanisms
+ is likely to be less than optimal, but it will get the project running, identify
+ unforeseen risks, and trigger further investigations and evaluations. As the
+ project continues and you gain more knowledge, you will need to refine the mapping.
+</p>
+<p> Proceed iteratively to refine the mapping between design and implementation
+ mechanisms. Eliminate <strong></strong>redundant
+ paths, working both top-down and bottom-up. </p>
+<p> <b>Working top-down: </b>When working top-down (from top to bottom), new and
+ refined use-case realizations will put new requirements on the necessary design
+ mechanisms through the analysis mechanisms that you need. These new requirements
+ might uncover additional characteristics of a design mechanism, forcing a split
+ between mechanisms. A compromise between the system's complexity and its performance
+ is also necessary: </p>
+<ul>
+ <li>
+ Too many different design mechanisms make the system too complex.
+ </li>
+ <li> Too few design mechanisms can create performance problems for implementation
+ mechanisms that stretch the limits of the reasonable ranges of the values
+ of their characteristics. </li>
+</ul>
+<p> <b>Working bottom-up: </b>When working bottom-up (from bottom to top) and
+ investigating the available implementation mechanisms, you might find products
+ that satisfy several design mechanisms at once, but force some adaptation or
+ repartitioning of your design mechanisms. You want to minimize the number of
+ implementation mechanisms you use, but too few of them can also lead to performance
+ problems. </p>
+<p> After you decide to use a DBMS to store class A objects, you might be tempted
+ to use it to store all objects in the system. This could be very inefficient
+ or very cumbersome. Not all objects that require persistency need to be stored
+ in the DBMS. Some objects may be persistent, but one application may access
+ them frequently, while other applications access them only infrequently. A hybrid
+ strategy, in which the object is read from the DBMS into memory and periodically
+ synchronized, may be the best approach. </p>
+<blockquote>
+ <p class="example"> <b>Example</b> </p>
+ <p class="example"> A flight can be stored both in memory for fast access and
+ in a DBMS for long-term persistency. However, this triggers a need for a mechanism
+ to synchronize both. </p>
+</blockquote>
+<p> It is not uncommon to have more than one design mechanism associated with
+ a client class as a compromise between different characteristics. </p>
+<p> Because implementation mechanisms often come in bundles in off-the-shelf components
+ (operating systems and middleware products), some optimization based on cost,
+ impedance mismatch, or uniformity of style needs to occur. Also, mechanisms
+ are often interdependent, which makes clear separation of services into design
+ mechanisms difficult. </p>
+<blockquote>
+ <p class="example"> <b>Examples</b> </p>
+ <ul>
+ <li> The notification mechanism can be based on the inter-process communication
+ mechanism. </li>
+ <li> The error reporting mechanism can be based on the persistency mechanism.
+ </li>
+ </ul>
+</blockquote>
+<p> Refinement continues over the whole Elaboration phase, and is always a compromise
+ between: </p>
+<ul>
+
+ <li> An exact fit with the requirements of the clients of the design mechanism,
+ in terms of the expected characteristics. </li>
+ <li>
+ The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
+ </li>
+</ul>
+<p> The overall goal is always to have a simple, clean set of mechanisms that
+ give conceptual integrity, simplicity, and elegance to a large system. </p>
+<h3> Describing Design Mechanisms </h3>
+<p>
+ As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
+ architectural or design patterns (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
+ guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>).
+</p>
+<blockquote>
+ <p> <strong>Example: A persistence mechanism </strong></p>
+ <p> This example uses an instance of a pattern for RDBMS-based persistency drawn
+ from <strong></strong><a
+ href="http://java.sun.com/products/jdbc/index.html" target="_blank" ><u>Java&#8482;
+ Database Connectivity (JDBC)</u></a>. Although we present the design here,
+ JDBC supplies actual code for some of the classes. Therefore, it is a short
+ step from what is presented here to an implementation mechanism. </p>
+</blockquote>
+<p> Figure 4, titled <strong> JDBC: Static view,</strong> shows the classes (actually,
+ the classifier roles) in the collaboration. <strong></strong></p>
+<p align="center"> <img height="382" title="Figure 4. JDBC: Static View" alt="Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. " src="./resources/jdbc1.gif" width="571" /></p>
+<p align="center"> <strong>Figure 4. JDBC: Static view </strong></p>
+<p align="left"> The yellow classes are the ones that were supplied. The others,
+ in tan (myDBClass and so on),
+ were bound by the designer to create the mechanism. </p>
+<p align="left"> In a Java database class, a client will work with a <b>DBClass</b>
+ to read and write persistent data. The DBClass is responsible for accessing the JDBC database, using the <b>DriverManager</b>
+ class. Once a database <b>connection</b> is open, the DBClass can then create SQL statements that will be sent to the underlying RDBMS
+ and executed using the <b>Statement</b> class. The Statement class is what communicates with the database. The result of the SQL query
+ is returned in a <b>ResultSet</b> object.<span style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p align="left"> The <b>DBClass</b> is responsible for making another class instance
+ persistent. It understands the OO-to-RDBMS mapping and can interface with the
+ RDBMS. The DBClass flattens the
+ object, writes it to the RDBMS, and then reads the object data from the RDBMS
+ and builds the object. Every class that is persistent has a corresponding DBClass.&nbsp;
+</p>
+<p align="left"> The <b>PersistentClassList</b> is used to return a set of persistent
+ objects as a result of a database query, for example: DBClass.read().
+</p>
+<p align="left"> A series of dynamic views follow, in Figures 5 thorough 9, to
+ show how the mechanism actually works. <strong></strong></p>
+<p align="center"> <img height="146" title="Figure 5. JDBC: Initialize" alt="Diagram of JDBC: Initialize" src="./resources/jdbc2.gif" width="285" />
+</p>
+<p align="center"> <b>Figure5. JDBC: Initialize</b> </p>
+<p>
+ Initialization must occur before any persistent class can be accessed.
+</p>
+<p> To initialize the connection to the database, the DBClass
+ must load the appropriate driver by calling the DriverManager
+ getConnection() operation with a URL, user, and password. </p>
+<p> The operation getConnection()
+ attempts to establish a connection to the given database URL. The driver manager
+ attempts to select an appropriate driver from the set of registered JDBC drivers.
+</p>
+<blockquote>
+ <p> <strong>Parameters</strong></p>
+ <blockquote>
+ <p> <b>URL</b><strong>: </strong>A database URL in the form jdbc:subprotocol:subname.
+ This URL is used to locate the actual database server and is not Web-related,
+ in this instance. </p>
+ <p> <b>user</b><strong>: </strong>The database user who is making the connection.</p>
+ <p> <b>pass</b><strong>:</strong> The user's password </p>
+ </blockquote>
+ <p> <strong>Returns</strong></p>
+ <blockquote>
+ <p> A connection to the URL.</p>
+ </blockquote>
+</blockquote>
+<p align="center"> <img height="253" title="Figure 6. JDBC: Create" alt="Diagram of JDBC: Crreate" src="./resources/jdbc3.gif" width="478" />
+</p>
+<p align="center"> <b>Figure 6. JDBC: Create</b> </p>
+<p align="left"> To create a new class, the persistency client asks the DBClass
+ to create the new class. The DBClass
+ creates a new instance of PersistentClass with default values. The DBClass
+ then creates a new Statement using the Connection class createStatement()
+ operation. The Statement runs,
+ and the data is added to the database.</p>
+<p align="center"> <img height="352" title="Figure 7. JDBC: Read" alt="Diagram of JDBC: Read" src="./resources/jdbc4.gif" width="600" />
+</p>
+<p align="center"> <b>Figure 7. JDBC: Read</b> </p>
+<p> To read a persistent class, the persistency client asks the DBClass
+ to read. The DBClass creates
+ a new Statement using the Connection class createStatement() operation. The Statement is executed, and the
+ data is returned in a ResultSet object. The DBClass then creates
+ a new instance of the PersistentClass and populates it with the retrieved data. The data is returned in a collection
+ object, an instance of the PersistentClassList class. </p>
+<p> <strong>Note: </strong></p>
+<p>The string passed to executeQuery()
+ is not necessarily exactly the same string as the one passed into the
+ read(). The DBClass
+ will build the SQL query to retrieve the persistent data from the database,
+ using the criteria passed into the .
+ This is because it is not useful for the client of the DBClass
+ to know the internal structure of the database to create a valid query. This
+ knowledge is encapsulated within DBClass.
+</p>
+<p align="center"> <img height="255" title="Figure 8. JDBC: Update" alt="Diagram of JDBC: Update" src="./resources/jdbc5.gif" width="473" />
+</p>
+<p align="center"> <b>Figure 8. JDBC: Update</b> </p>
+<p> To update a class, the persistency client asks the
+ DBClass to update. The DBClass
+ retrieves the data from the given PersistentClass object, and creates a new Statement
+ using the Connection class createStatement()
+ operation. Once the Statement
+ is built, the database is updated with the new data from the class. </p>
+<p> <strong>Remember: </strong>It is the job of the DBClass
+ to flatten the PersistentClass and
+ write it to the database. That is why it must be retrieved from the given PersistentClass
+ before creating the SQL Statement.
+</p>
+<p> <strong>Note: </strong></p>
+<p>In the above mechanism, the PersistentClass
+ must provide access routines for all persistent data so that
+ DBClass can access them. This provides external access to certain persistent
+ attributes that would have been private otherwise. This is a price you have
+ to pay to pull the persistence knowledge out of the class that encapsulates
+ the data.</p>
+<p align="center"> <img height="255" title="Figure 9. JDBC: Delete" alt="Diagram of JDBC: Delete" src="./resources/jdbc6.gif" width="473" />
+</p>
+<p align="center"> <b>Figure 9. JDBC: Delete</b></p>
+<p align="left"> To delete a class, the persistency client asks the DBClass to delete the PersistentClass.
+ The DBClass creates a new Statement using the Connection class createStatement()
+ operation. The Statement is
+ executed and the data is removed from the database. </p>
+<p align="left"> In the actual implementation of this design, you would make some
+ decisions about the mapping of DBClass
+ to the persistent classes, such as having one DBClass
+ per persistent class and allocating them to appropriate packages. These packages
+ will depend on<strong> </strong>the supplied java.sql file (see <a href="http://java.sun.com/products/jdbc/index.jsp">JDBC:
+ API Documentation</a>)<strong> </strong>package that contains the supporting
+ classes DriverManager, Connection, Statement,
+ and ResultSet. </p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.xmi
new file mode 100644
index 0000000..0b1b517
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs.xmi
@@ -0,0 +1,144 @@
+<?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" epf:version="1.0.0" xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" name="find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA" guid="-Rcm_MlViENAvFFyIe9V3dQ" changeDate="2006-10-23T13:31:13.565-0700" version="1.0.0">
+ <mainDescription><h4>
+ Finding actors
+</h4>
+<p>
+ Find the external entities with which the system under development must interact. Candidates include groups of users
+ who will require help from the system to perform their tasks and execute the system's primary or secondary functions,
+ as well as external hardware, software, and other systems.
+</p>
+<p>
+ Define each candidate actor by naming it and writing a brief description. Includes the actor's area of responsibility
+ and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not
+ have any goals.
+</p>
+<p>
+ These questions are useful in identifying actors:
+</p>
+<ul>
+ <li>
+ Who will supply, use, or remove information from the system?
+ </li>
+ <li>
+ Who will use the system?
+ </li>
+ <li>
+ Who is interested in a certain feature or service provided by the system?
+ </li>
+ <li>
+ Who will support and maintain the system?
+ </li>
+ <li>
+ What are the system's external resources?
+ </li>
+ <li>
+ What other systems will need to interact with the system under development?
+ </li>
+</ul>
+<p>
+ Review the list of stakeholders that you captured in the Vision statement. Not all stakeholders will be actors
+ (meaning, they will not all interact directly with the system under development), but this list of stakeholders is
+ useful for identifying candidates for actors.
+</p>
+<h4>
+ Finding use cases
+</h4>
+<p>
+ The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not,
+ ask:
+</p>
+<ul>
+ <li>
+ What are the goals that the actor will attempt to accomplish with the system?
+ </li>
+ <li>
+ What are the primary tasks that the actor wants the system to perform?
+ </li>
+ <li>
+ Will the actor create, store, change, remove, or read data in the system?
+ </li>
+ <li>
+ Will the actor need to inform the system about sudden external changes?
+ </li>
+ <li>
+ Does the actor need to be informed about certain occurrences, such as unavailability of a network resource,&nbsp;in
+ the system?
+ </li>
+ <li>
+ Will the actor perform a system startup or shutdown?
+ </li>
+</ul>
+<p>
+ Understanding how&nbsp;the target&nbsp;organization works and how this information system might be incorporated into
+ existing operations gives an idea of system's surroundings. That information may reveal other use case candidates.
+</p>
+<p>
+ Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case
+ does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case.
+</p>
+<h4>
+ Outlining Use Cases
+</h4>
+<p>
+ Without going into details, write a first draft of the flow of events of the use cases identified as being of high
+ priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step
+ description is a simple ordered list of interactions between the actor and the system. For example, the description of
+ the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this:
+</p>
+<ol>
+ <li>
+ The&nbsp;customer inserts a bank card.
+ </li>
+ <li>
+ The system validates the card and prompts the person to enter a personal identification number (PIN).
+ </li>
+ <li>
+ The customer&nbsp;enters a PIN.
+ </li>
+ <li>
+ The system validates the PIN and prompts the customer to select an action.
+ </li>
+ <li>
+ The customer selects Withdraw Cash.
+ </li>
+ <li>
+ The system prompts the customer to choose which account.
+ </li>
+ <li>
+ The customer selects the checking account.
+ </li>
+ <li>
+ The system prompts for an amount.
+ </li>
+ <li>
+ The customer enters the amount to withdraw.
+ </li>
+ <li>
+ The system validates the amount (assuming sufficient funds), and then issues cash and receipt.
+ </li>
+ <li>
+ The customer takes the cash and receipt, and then retrieves the bank card.
+ </li>
+ <li>
+ The use case ends.
+ </li>
+</ol>
+<p>
+ As you create this step-by-step description of the basic flow of events, you may discover alternative and exceptional
+ flows. For example, what happens if the customer enters an invalid PIN? Record the name and a brief description of each
+ alternate flow that you identified.
+</p>
+<h4>
+ Representing relationships between actors and use cases
+</h4>
+<p>
+ The relationship between actors and use cases should be captured, or documented&nbsp; There are several ways to do
+ this. If you are using a use-case model on the project, you can create use-case diagrams to show how&nbsp;actors and
+ use cases&nbsp;relate to each other.&nbsp; Refer to&nbsp;<a class="" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>&nbsp;for more information.
+</p>
+<p>
+ If you are not using a use-case model for the project, make sure that each use case identifies the associated primary
+ and secondary actors.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/implementation.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/implementation.xmi
new file mode 100644
index 0000000..098a2a5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/implementation.xmi
@@ -0,0 +1,79 @@
+<?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" epf:version="1.0.0" xmi:id="_4wqaMMPaEdmbOvqy4O0adg" name="implementation,_0Y0dsMlgEdmt3adZL5Dmdw" guid="_4wqaMMPaEdmbOvqy4O0adg" authors="Jim Ruehlin" changeDate="2006-12-01T16:13:39.278-0800" version="1.0">
+ <mainDescription><h5>
+ Code Reuse&nbsp;
+</h5>
+<p>
+ Code reuse and code generation tools produce more robust code and are preferable to writing code by hand. Existing code
+ has often already been tested and even deployed, making it more stable and well understood than new code. Source code
+ created from a code generation tool (such as a visual modeling tool) automates dreary coding tasks such as creating
+ getters and setters.
+</p>
+<p>
+ There are many places to harvest code for reuse:
+</p>
+<ul>
+ <li>
+ Internal (corporate) code libraries.
+ </li>
+ <li>
+ 3rd party libraries.
+ </li>
+ <li>
+ Built-in language libraries.
+ </li>
+ <li>
+ Code samples from tutuorials, examples, books, etc.
+ </li>
+ <li>
+ Local code guru or knowledgable colleague
+ </li>
+ <li>
+ Existing system code
+ </li>
+ <li>
+ Open source products (be sure to follow any licensing agreements)&nbsp;
+ </li>
+</ul>
+<h5>
+ Transforming the Design into the&nbsp;Implementation
+</h5>
+<p>
+ Transforming the design into code implements the system structure in the chosen source language. It also implements the
+ system behavior defined in the functional requirements. Implementing the system behavior means writing the code that
+ allows different parts of the application (classes or components) to collaborate in realizing the behavior of the
+ system.
+</p>
+<p>
+ There are various techniques for automatically transforming design to implementation. Here are some examples:
+</p>
+<ul>
+ <li>
+ Platform-specific visual models can be used to generate an initial code framework. This framework can be further
+ elaborated with additional code not specified in the design.<br />
+ </li>
+ <li>
+ Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and
+ behavior diagrams (such as state and activity diagram) can be used to generate executable code. These prototypes
+ can be further refined as needed.<br />
+ </li>
+ <li>
+ The design may be platform independent to varying degrees. Platform specific design models or even code can be
+ generated via transformations that apply various rules to map high level abstractions platform specific elements.
+ This is the focus of the Object Management Group (OMG) Model Driven Architecture (MDA) <a href="http://www.omg.org/" target="_blank">(http://www.omg.org</a>) initiative.<br />
+ </li>
+ <li>
+ Standard patterns can be applied to generate design and code elements from related design and implementation. For
+ example, a standard transformation pattern can be applied to a data table to create java classes to access the data
+ table. Another example is using an Eclipse Modeling Framework (<a href="http://www.eclipse.org/emf/" target="_blank">http://www.eclipse.org/emf/</a>) model to generate code for storing data that matches the model and
+ to generate a user interface implementation for populating data. A pattern or transformation engine can be used to
+ create the implementation, or the implementation can be done by hand. Pattern engines are easier and more reliable,
+ but hand-written code implementing a defined pattern will have fewer errors than hand-written code implementing a
+ novel or unique design.
+ </li>
+</ul>
+<p>
+ In all cases, however, some design abstraction (classes, components, etc)&nbsp;is detailed to become the
+ implementation.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/iteration_planning.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/iteration_planning.xmi
new file mode 100644
index 0000000..4c8c376
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/iteration_planning.xmi
@@ -0,0 +1,132 @@
+<?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" epf:version="1.0.0" xmi:id="_71hDkMPgEdmbOvqy4O0adg" name="iteration_plan,_0auiMMlgEdmt3adZL5Dmdw" guid="_71hDkMPgEdmbOvqy4O0adg" changeDate="2006-11-01T11:17:34.612-0800">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
+ iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
+ define how to assess that you accomplished what you set out to accomplish.
+</p>
+<p>
+ Iteration planning is ideally done with the entire team in a meeting, typically lasting a few hours, at the beginning
+ of an iteration. This ensures that the entire team understands what needs to be done, and they become committed to the
+ success of the team. In some cases, it is preferred to have a smaller subset of people, such as the Project Manager, an
+ Architect and an Analyst to meet in advance to prep the meeting with a draft iteration plan.
+</p>
+<h3>
+ Define High-Level Objectives
+</h3>
+<p>
+ A key aspect of an iteration is to focus the team on a short term deliverable of measurable value. Document 1-5
+ high-level objectives to make sure that you don't lose focus on what to accomplish during the iteration. Typically, the
+ project plan should outline one or several objectives for each iteration, and those objectives are used as a starting
+ point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
+</p>
+<p>
+ The objectives are usually based on the following factors:
+</p>
+<ul>
+ <li>
+ <strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
+ risks.
+ </li>
+ <li>
+ <strong>The time allocated to the iteration:</strong> Iterations are usually timeboxed, so the Project Manager must
+ ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the
+ iteration.
+ </li>
+ <li>
+ <strong>The highest priority features:</strong> requirements are prioritized to ensure that the critical features
+ of the application will be developed and tested early on.
+ </li>
+</ul>
+<h3>
+ Produce an Iteration Plan
+</h3>
+<p>
+ There is an Iteration Plan per iteration that should outline who will implement which Work Item in how long a time.
+ Since iterations are time-boxed, we need to understand how big our ‘box” is by assessing how many hours of actual work
+ can be taken on. Let’s assume that you have 6 team members, and you have 15 working days in your iteration, and you on
+ average can do 5 actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work. Note
+ that the average team member only performs 4-6 hours of actual project work per day, with the rest being consumed by
+ e-mails, meetings, and other overhead activities not directly related to the project.
+</p>
+<p>
+ The team should then revisit and update priorities for all the high-priority items in the Work Items List, to make sure
+ that an important Work Item is not missed that would otherwise fall just below the list of what can be taken on in this
+ iteration.
+</p>
+<p>
+ Pick the top-priority Work Item and see if it matches the objectives of the iteration. If it does, assess whether the
+ Work Item is too big to take on within an iteration. If it is too big, break it down into smaller Work Items. Once the
+ Work Item has been decomposed, the team determines whether to take on one or several child Work Items.
+</p>
+<p>
+ <em>Example: The team would like to take on Work Item “Develop Use Case A”, but it would take roughly 300 hours to
+ develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,
+ allowing them to take on other high-priority Work Items. They divide the Work Item into 5 smaller work items
+ representing different scenarios of use case A. The team decides to take on one out of the 5 identified scenarios in
+ this iteration.</em>
+</p>
+<p>
+ When a team has decided to take on a Work Item, it will assign the work to one or several team members. Ideally, this
+ is done by team members signing up to do the work, since this makes people motivated and committed to doing the job,
+ but based on culture, you may instead have the project manager assign the work.
+</p>
+<p>
+ The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
+ want to have each work assignment to be no more than 2 days of work. If the Work Item is too big, consider breaking it
+ down into smaller Work Items.
+</p>
+<p>
+ The team sums up the actual estimate for each Work Item they have committed to, and checks if they can commit to any
+ more work.
+</p>
+<p>
+ <em>Example: Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he
+ decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:</em>
+</p>
+<ul>
+ <li>
+ <em>Detail the requirements (Jack) —5 hours</em>
+ </li>
+ <li>
+ <em>Design the scenario (Jack, Ann, and David) —5 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the dB changes (Ann)—12 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the server portion (David)—16 hours</em>
+ </li>
+ <li>
+ <em>Implement and test the client portion (Jack)—12 hours</em>
+ </li>
+ <li>
+ <em>Total—50 hours</em>
+ </li>
+</ul>
+<p>
+ As Work Items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
+ understand what is involved, and whether other team member may be better suited to take on a subset of the task
+</p>
+<p>
+ The team now determines whether they are willing to take on another Work Item by comparing actual hours signed up for
+ to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence have another
+ 400 hours available
+</p>
+<h3>
+ Define Evaluation Criteria
+</h3>
+<p>
+ It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
+ the iteration. Obvious success criteria should be that you can test the functionality implemented, and that no or few
+ defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
+ meaningful feedback. Test objectives and test cases need to be clearly outlined.
+</p>
+<p>
+ There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
+ favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/layering.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/layering.xmi
new file mode 100644
index 0000000..868e012
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/layering.xmi
@@ -0,0 +1,218 @@
+<?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" epf:version="1.0.0" xmi:id="_lbGQwMM3EdmSIPI87WLu3g" name="layering,_0gpkAMlgEdmt3adZL5Dmdw" guid="_lbGQwMM3EdmSIPI87WLu3g" changeDate="2007-02-26T12:37:43.312+0000" version="1.0.0">
+ <mainDescription><p>
+ Layering logically partitions the subsystems into a number of sets, with certain rules regarding how relationships can
+ be formed between the layers. Layering provides a way to restrict inter-subsystem dependencies, with the result that
+ the system is more loosely coupled and, therefore, more easily maintained.
+</p>
+<p>
+ Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
+ than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
+ requirements. Removing layers is not always as easy and may introduce risks into the project.
+</p>
+<p>
+ The criteria for grouping subsystems follow a few patterns:
+</p>
+<ul>
+ <li>
+ <b>Visibility</b><strong>:</strong> Subsystems may depend only on subsystems in the same layer and the next-lower
+ layer.
+ </li>
+ <li>
+ <b>Volatility</b><strong>:</strong>
+ <ul>
+ <li>
+ <b>In the highest layers</b>, put elements that vary when user requirements change.
+ </li>
+ <li>
+ <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
+ language, operating system, database, and so forth).
+ </li>
+ <li>
+ <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
+ systems and implementation environments.
+ </li>
+ <li>
+ <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
+ model.
+ </li>
+ </ul>
+ </li>
+ <li>
+ <b>Generality</b><strong>:</strong> Abstract model elements tend to be placed lower in the model. If not
+ implementation-specific, they tend to gravitate toward the middle layers.
+ </li>
+ <li>
+ <b>Number of layers.</b> For a small system, three layers are sufficient. For a complex system, five to seven
+ layers are usually sufficient. For any degree of complexity, more than 10 layers should be viewed with suspicion
+ that increases with the number of layers. The table that follows gives you a few guidelines.
+ </li>
+</ul>
+<p align="center">
+ <strong>Guideline for number of layers according to number of classes</strong>
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="58%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th width="40%">
+ <p align="center" scope="col">
+ <b>Number of Classes</b>
+ </p>
+ </th>
+ <th width="60%">
+ <p align="center" scope="col">
+ <b>Number of Layers</b>
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 0 - 10
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ No layering needed
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 10 - 50
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 2 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 25 - 150
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 3 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ <tr>
+ <td width="40%">
+ <p align="center">
+ 100 - 1000
+ </p>
+ </td>
+ <td width="60%">
+ <blockquote>
+ <blockquote>
+ <p>
+ 4 layers
+ </p>
+ </blockquote>
+ </blockquote>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<p>
+ Failure to restrict dependencies according to Visibility criteria mentioned above can cause architectural degradation
+ and make the system difficult to extend and maintain.
+</p>
+<p>
+ Exceptions include cases where subsystems need direct access to lower-layer services. Make a decision about how to
+ handle primitive services that are needed throughout the system, such as printing, sending messages, and so forth.
+ There is little value in restricting messages to lower layers if the solution is to effectively implement call
+ pass-throughs in the intermediate layers.
+</p>
+<h4>
+ <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
+</h4>
+<p>
+ Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
+ partitioning present different issues to consider:
+</p>
+<p>
+ <b>User organization</b><strong>:</strong> Subsystems may be organized along lines that mirror the organization of
+ functionality in the business organization (partitioning occurs along departmental lines). This partitioning often
+ occurs early in the design because an existing enterprise model that is strongly partitioned according to the structure
+ of the organization. This pattern usually affects only the top few layers of application-specific services and often
+ disappears as the design evolves.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning along user-organization lines can be a good starting point for the model.
+ </p>
+ </li>
+ <li>
+ <p>
+ The structure of the user organization is not stable over a long period of time because business
+ reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
+ organization of the system should enable the system to evolve and be maintained independently of the
+ organization of the business that it supports.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Areas of competence and skills:</b> Subsystems may be organized to partition responsibilities for parts of the model
+ among different groups within the development organization. Typically, this occurs in the middle and lower layers of
+ the system, and reflects the need for specialization in skills during the development and support of an infrastructure
+ based on complex technology. Examples of such technologies include network and distribution management, database
+ management, communication management, and process control, among others. Partitioning along competence lines may also
+ occur in upper layers, where special competency in the problem domain is required to understand and support key
+ business functionality. Examples include telecommunication call management, securities trading, insurance claims
+ processing, and air traffic control, to name a few.
+</p>
+<p>
+ <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
+ so to speak, to reflect the distribution of functionality.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning to reflect distribution of functionality can help you visualize the network communication that
+ will occur as the system runs.
+ </p>
+ </li>
+ <li>
+ <p>
+ Partitioning to reflect distribution can also, however, make the system more difficult to change if the
+ deployment model changes significantly.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
+ develop or support, require additional partitioning according to security access privileges. Software that controls
+ access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
+ people with this background on the project is limited, the functionality requiring special clearance must be
+ partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
+ secrecy areas the only visible aspect of these subsystems.
+</p>
+<p>
+ <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
+ the system, should be organized into independent subsystems that are developed and delivered independently from the
+ mandatory functionality of the system.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/maintaining_automated_test_suite.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/maintaining_automated_test_suite.xmi
new file mode 100644
index 0000000..b8a19e1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/maintaining_automated_test_suite.xmi
@@ -0,0 +1,104 @@
+<?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" epf:version="1.0.0" xmi:id="_8ngBgMPdEdmbOvqy4O0adg" name="maintaining_automated_test_suite,_0kF5kMlgEdmt3adZL5Dmdw" guid="_8ngBgMPdEdmbOvqy4O0adg" changeDate="2006-09-26T11:31:15.615-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ At some point in your test effort, you may find it necessary to manage your test effort by creating test suites for
+ your test assets.&nbsp;Maintaining test suites can take many different forms. To facilitate your testing, you may want
+ to introduce some&nbsp;level of&nbsp;automation of your test suites.&nbsp;The fact that you've automated your test
+ suites does not necessarily make your testing easier however. It may actually increase the maintenance burden of your
+ suites.
+</p>
+<p>
+ This guideline introduces you to useful heuristics on how to facilitate the maintenance of your automated test suites.
+</p>
+<h4>
+ Plan your test&nbsp;suites
+</h4>
+<p>
+ Automating your testing without planning increases&nbsp;the chances that testing will be ineffective
+ and&nbsp;inefficient.&nbsp;Some level of planning should take place whether implicit or explicit.&nbsp;An essential
+ part of any test plan is the definition of a strategy for test automation.&nbsp;Use your plan to articulate to the
+ development team how you plan to maintain your test assets.&nbsp;In many cases, this is never done.&nbsp;The rest of
+ the development team may be unaware of how you intend to maintain your tests.&nbsp;It is also a good practice to get
+ the rest of the development team to understand that this maintenance can be a substantial part of the overall
+ development effort.&nbsp;Use your test tooling to capture this information and treat this plan just like you would
+ treat any other test asset in your test repository.
+</p>
+<h4>
+ Centrally locate your test assets
+</h4>
+<p>
+ To facilitate the maintenance of your automated test suites, locate your test assets in a repository that can be
+ accessed by the development team.&nbsp;Many test automation environments provide test management tools that make it
+ easier to organize and access your test assets by maintaining the test assets (test cases, test scripts, and test
+ suites) in a common repository.
+</p>
+<p>
+ In addition, some form of access control is enforced by the automation test tool.&nbsp;This eases the maintenance
+ burden by ensuring the integrity of your test suites.&nbsp;You may choose to grant stakeholders and managers read-only
+ access, whereas developers and testers at the practitioner level may have read/write access.
+</p>
+<h4>
+ Treat your test assets like any other software
+</h4>
+<p>
+ Software must be maintained.&nbsp;This also applies to the software in your test suites.&nbsp;Test cases and their
+ associated test scripts, whether recorded or programmed, should be maintained.&nbsp;And just as software has different
+ kinds of maintenance (e.g., corrective, preventative, or adaptive) so too do the assets in your automated test suites.
+ As you lifecycle your test suites, identify, if only informally,&nbsp;how&nbsp;you plan to disposition the test suite
+ corrective maintenance (e.g., syntactical errors in your scripts),&nbsp;preventative maintenance (e.g., where possible
+ to write generalized test scripts), and adaptive maintenance (e.g., how you&nbsp;can use your test tooling to re-assign
+ test&nbsp;assets within one suite to&nbsp;another suite or suites).&nbsp;This can be captured, as described in the
+ section <strong>Plan Your Test Suites</strong> above, in your test plan.
+</p>
+<h4>
+ Improve the testability of your test suites through collaboration with developers
+</h4>
+<p>
+ It's one thing to say that your test suites will need to be maintained due to changes in the application, changes in
+ the testing target, etc.&nbsp;It's quite another thing to actually determine whether a test suite needs to be
+ revamped&nbsp;and, if it does, what test assets within it need to be addressed.
+</p>
+<p>
+ One way to facilitate this is to use test suites as a way to communicate test decision to the developers.&nbsp;One way
+ to perform continuous perfective maintenance of test suites is to think of your test suites as assets that belong to
+ the development team rather than just the testers.&nbsp; You can perform a kind of perfective maintenance on test in
+ the following ways:
+</p>
+<ul>
+ <li>
+ use test suites to raise the level of abstraction
+ </li>
+ <li>
+ use test suites to provide focus for the developer
+ </li>
+ <li>
+ use test suites to articulate areas that the developers would like testers to focus on
+ </li>
+ <li>
+ make the construction and maintenance&nbsp;of test suites more efficient&nbsp;by understanding what area(s)
+ developers want to focus on
+ </li>
+ <li>
+ use test suites to clarify test targets with developers
+ </li>
+</ul>
+<h4>
+ Don't be afraid to clean up your suites
+</h4>
+<p>
+ Your test assets will evolve just as the application under test will.&nbsp;As requirements to the system change, the
+ application will change as well.&nbsp;To maintain your test suites, you should continually&nbsp;check whether test
+ assets are valid.&nbsp;If possible, validity checks should be performed after each new release of the software,
+ preferably more frequently.&nbsp;Keeping your test suites relevant is a full-time job.&nbsp;Assume that changes in the
+ software will lead to some degree of invalid tests within your test suites.&nbsp;Once these test assets have been
+ identified as invalid, get rid of them.&nbsp;This will make the maintenance burden much more tolerable.&nbsp;Some
+ automated test tooling environments make this task easier by providing ways to package outdated or invalid
+ tests.&nbsp;In some cases, you may not be absolutely sure whether you want to completely get rid of tests within your
+ test suite or even of getting rid of test suites altogether.&nbsp; To alleviate this burden, you can create packages
+ for obsolete tests or test suites and dispose of tests or test suites by putting them in packages labeled for this
+ purpose.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_and_openup_basic.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_and_openup_basic.xmi
new file mode 100644
index 0000000..b6fdfa3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_and_openup_basic.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-KCSbXYv5TALlL00zMMfgVw" name=",_v2l6gK_5EduMeuOwJ2MpeQ" guid="-KCSbXYv5TALlL00zMMfgVw">
+ <mainDescription><p>
+ What's the difference between OpenUP and OpenUP/Basic?
+</p>
+<p>
+ How does OpenUP relate to EPF?
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_architecture.xmi
new file mode 100644
index 0000000..b75d233
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_architecture.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-clUV9n59dDwg0e1VCcsB8Q" name=",_REqtUMEvEduwZvIr61GnNg" guid="-clUV9n59dDwg0e1VCcsB8Q" changeDate="2007-02-20T14:13:25.950-0800">
+ <mainDescription><p>
+ Describe how Elaboration deals with architecture (link to existing content).
+</p>
+<p>
+ The architecture artifacts are the work products that provide the most benefit in development in terms of understanding
+ and extending the system.
+</p>
+<p>
+ Explain how architecture reduces technical risk and the importance of doing so.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_iterations.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_iterations.xmi
new file mode 100644
index 0000000..eda90a9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_iterations.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-Mobjz86dw07NW5-IhtEoNA" name=",_U3VjIMEuEduwZvIr61GnNg" guid="-Mobjz86dw07NW5-IhtEoNA" changeDate="2007-02-20T14:09:51.021-0800">
+ <mainDescription>Describe the&nbsp;milestone of each phase (link to existing content). Explain that iterations are not homogeneous, but they
+all deliver stakeholder value. explain that that the focus on reducing risk and understanding the architecture in I &amp; E
+make C &amp; T more predictable.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_risk.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_risk.xmi
new file mode 100644
index 0000000..e11b673
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/openup_risk.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-_BjYXvrfe1HHL5Y_QBfh4Q" name=",_G08UgMEwEduwZvIr61GnNg" guid="-_BjYXvrfe1HHL5Y_QBfh4Q" changeDate="2007-02-20T14:22:16.653-0800">
+ <mainDescription><p>
+ Define risk (reference existing content).
+</p>
+<p>
+ Explain how addressing risk in early iterations reduces the uncertainty and unpredictabiliy in future iterations.
+ Describe the effect that identifying, tracking, and mitigating risk has on a project (better decisions, high comfort
+ level, more visibility into problems).
+</p>
+<p>
+ Reference definitions for risk and risk mitigation.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/programming_automated_tests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/programming_automated_tests.xmi
new file mode 100644
index 0000000..bbe0ae0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/programming_automated_tests.xmi
@@ -0,0 +1,73 @@
+<?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" epf:version="1.0.0" xmi:id="_vuwC4MPcEdmbOvqy4O0adg" name="programming_automated_tests,_0j5sUMlgEdmt3adZL5Dmdw" guid="_vuwC4MPcEdmbOvqy4O0adg" changeDate="2006-12-07T16:06:38.445-0500" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Although the programming of automated tests should contribute to the overall test effort, it usually does not make up
+ the entire test effort. In fact, test environments that are based on a complete automation approach end up spending
+ more time on test automation than on testing. Before you begin developing automated test scripts, consider first
+ whether it is more efficient to perform manual testing. Some aspects of an application are more efficiently tested
+ manually (for example, GUI testing versus data-drive testing). If you decide to program automated test scripts, examine
+ what aspects of your test scripting can be automated and begin designing your scripts.
+</p>
+<h3>
+ Design your automated tests
+</h3>
+<p>
+ Without some level of design of your automated tests, introducing automation into your testing effort can lead to more
+ problems than it solves. You should consider developing your automated tests according to a lifecycle with automation
+ test requirements, design, testing of the automation tests, and implementation of the automation tests. This approach
+ can be informal or formal depending on your project needs. By designing the programming of your automated tests, you
+ can avoid spending time programming the wrong tests, re-working programmed tests, deciphering different coding styles
+ in the programming of the tests, etc.
+</p>
+<h3>
+ Recorded versus programmed scripts
+</h3>
+<p>
+ Although there are clear benefits to recorded scripts (for example, ease of creation or ability for novice testers to
+ learn a scripting language), recorded scripts also present their own problems. The disadvantages of playback scripts
+ are well known. They are deceptively easy to create but very difficult to update. Problems with script reliability,
+ hard-coded data values, or changes to the application under test and the need to re-record are well-documented. On the
+ other hand, programming scripts can present difficulties of their own: they are difficult for the novice tester to
+ create, they can require substantial time and effort to develop, and they can be difficult to debug. Most test tooling
+ makes these issues less problematic by providing the tester script support functions, such as ways to establish target
+ of test lists, systematic ways to program verification point, point to datapools, build commands into the script (for
+ example, sleeper commands), comment the script, and document the script. Another major advantage, which is often
+ overlooked, of using testing tooling to mitigate these risks is the ability to add to an existing script in the form of
+ making corrections to an existing script, testing new features of a test target or application under test, or resuming
+ a recording after an interruption.
+</p>
+<h3>
+ Functional and performance test scripts
+</h3>
+<p>
+ When discussing automating test scripts, it is important to distinguish between functional and performance tests. Most
+ discussions of programming automated test scripts focus on testing the functionality of an application. This is not
+ inappropriate, since a lot of automated testing focuses on functional testing. Performance test scripting, however, has
+ its unique characteristics. Performance test automation provides you with the ability to programmatically set workloads
+ by adding user groups to test loads under group usage, setting think time behavior, running tests randomly or at set
+ rates, or setting the duration of a run. Performance test automation also allows you to create and maintain schedules
+ for your tests.
+</p>
+<h3>
+ Testing test scripts
+</h3>
+<p>
+ When testing your test scripts, keep in mind whether you are testing recorded or programmed test scripts. For recorded
+ scripts, much of the debugging of the script consists of errors that are introduced due to changes in the test target
+ or test environment. When you run a recorded test script, consider the test target of the script. Some test automation
+ tools capture this information as a part of the test script. Debugging a recorded script consists largely of
+ determining whether changes in the target have created error conditions in the script. In general, there are two main
+ categories to examine here: changes in the UI and test session sensitive data (for example, date stamped data). In most
+ cases, discrepancies between recording and playback cause errors in your recorded test scripts.
+</p>
+<p>
+ Testing programmed test scripts involves many of the same debugging techniques you would apply to debugging an
+ application. Consider both the flow control logic and the data aspects of your script. Automated testing tools provide
+ you with test script debugging IDEs as well as datapool management features that facilitate this type of testing.
+ During execution of test scripts, a test that uses a datapool can replace values in the programmed test with variable
+ test data that is stored in the datapool.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/promoting_builds.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/promoting_builds.xmi
new file mode 100644
index 0000000..6cfe19b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/promoting_builds.xmi
@@ -0,0 +1,87 @@
+<?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" epf:version="1.0.0" xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ" name="promoting_builds,_SM4YIL6dEdqti4GwqTkbsQ" guid="-zCM2ucJJxc_bQr_LoHlSaQ" changeDate="2007-02-26T13:49:04.018-0500" version="1.0.0">
+ <mainDescription><p>
+ During iterative software development the team will create numerous <a class="elementLink"
+ href="./../../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>s. A build is initiated by combining the work completed by one or more
+ developers and resolving any conflicts that are encountered. Ideally a build is then subjected to a battery of tests to
+ determine if it is of sufficient quality to move into production.
+</p>
+<p>
+ As a build progresses from development towards production it is beneficial to know two characteristics:
+</p>
+<p>
+ <strong>Build contents</strong> – identifying the elements and their versions
+</p>
+<ul>
+ <li>
+ What is in this build (completed work items)
+ </li>
+ <li>
+ What is partially in this build (work items that are partially complete)
+ </li>
+ <li>
+ What is not in this build (work items that are not reflected at all in this build)
+ </li>
+</ul>
+<p>
+ <strong>Verification Level</strong> – identifying what amount of testing that has been completed.&nbsp; For example,
+</p>
+<ul>
+ <li>
+ Unit Tested
+ </li>
+ <li>
+ Integration Tested
+ </li>
+ <li>
+ System Tested
+ </li>
+</ul>
+<p>
+ The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
+ the following steps:
+</p>
+<ul>
+ <li>
+ Changes are introduced into the system in the form of completed work items
+ </li>
+ <li>
+ A build is generated clearly identifying the&nbsp;changes
+ </li>
+ <li>
+ Testing is conducted
+ </li>
+ <li>
+ When testing is successful the changes are delivered to the next&nbsp;verification level
+ </li>
+</ul>
+<p>
+ Ultimately all required testing is complete and the a new system version is ready.
+</p>
+<p>
+ It can also be beneficial to isolate work being performed at the different stages using different <a
+ class="elementLink" href="./../../../openup_basic/guidances/concepts/workspace,_0cEmAMlgEdmt3adZL5Dmdw.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>s. This ensures that the effort of testing a build is applied to the
+ correct version and also allows developers to continue working on the next build while the previous build is being
+ tested.
+</p>
+<p>
+ A promotional lifecycle such as this offers three key benefits
+</p>
+<ol>
+ <li>
+ Reduces effort because there is no reason to execute the tests in the next stages until the build passes the
+ previous stage. For example you would not commit the resources to&nbsp;System Testing&nbsp;a build until it passes
+ integration tests.
+ </li>
+ <li>
+ Helps to ensure that a build which is moved into production has been subjected to the appropriate level of testing
+ first.
+ </li>
+ <li>
+ Simplifies debugging since developers can base their work on a proven build (Integration Tested build, for example)
+ in relative isolation from destabilizing changes from other developers
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
new file mode 100644
index 0000000..a7ff527
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
@@ -0,0 +1,43 @@
+<?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" epf:version="1.0.0" xmi:id="_iCwb8MM3EdmSIPI87WLu3g" name="repres_interfaces_to_ext_systems,_0gjdYMlgEdmt3adZL5Dmdw" guid="_iCwb8MM3EdmSIPI87WLu3g" changeDate="2007-02-26T12:05:55.921+0000" version="1.0.0">
+ <mainDescription><p>
+ Interfaces with external systems should be consistently handled throughout the system, so markers need to be identified
+ in the architecture to make sure that the team develop the coherant software. The architecture need not include a
+ specific, detailed design for each system interface. It is often enough to simply identify the existence of the
+ interfacre as a significant part of the architecture and create a subsystem to encapsulate the detail, so that it can
+ be developed later.
+</p>
+<p>
+ The <a class="elementLink"
+ href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides the basis for a useful technique to
+ support this.
+</p>
+<p>
+ If the system communicates with another system, define one or more boundary classes to describe the communication
+ protocol. An external system may be anything from software to hardware units that the current system will use, such as
+ printers, terminals, alarm devices, and sensors. In each case, a boundary class that mediates the communication with
+ the external system will be identified.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ An automated teller machine (ATM) must communicate with the ATM network to ascertain whether a customer's bank
+ number and PIN are correct, and whether the customer has sufficient funds to withdrawal the requested amount. The
+ ATM network is an external system (from the perspective of the ATM); therefore, you would use a
+ <strong>boundary</strong> class to represent it in a use-case analysis.
+ </p>
+</blockquote>
+<p>
+ If the interfaces with the system are simple and well-defined, a single class may be sufficient to represent the
+ external system. Often, however, these interfaces are too complex to be represented by using a single class; they often
+ require complex collaborations of many classes. Moreover, interfaces between systems are often highly reusable across
+ applications. As a result, in many cases, a subsystem models the system interfaces more appropriately.
+</p>
+<p>
+ The use of a subsystem allows the interface to the external system to be defined and stabilized, while leaving the
+ design details of the system interface hidden as the system evolves.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/req_gathering_techniques.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/req_gathering_techniques.xmi
new file mode 100644
index 0000000..fc6ae21
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/req_gathering_techniques.xmi
@@ -0,0 +1,347 @@
+<?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" epf:version="1.0.0" xmi:id="_On0agNSAEdmLhZ9H5Plxyw" name="req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw" guid="_On0agNSAEdmLhZ9H5Plxyw" changeDate="2006-09-22T10:27:44.597-0400">
+ <mainDescription><h3>
+ Sources of Requirements
+</h3>
+<p>
+ Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one
+ that&nbsp;takes few&nbsp;resources. Examples of sources of requirements include:
+</p>
+<ul>
+ <li>
+ Customers
+ </li>
+ <li>
+ Users
+ </li>
+ <li>
+ Administrators and maintenance&nbsp;staff
+ </li>
+ <li>
+ Partners
+ </li>
+ <li>
+ Domain Experts
+ </li>
+ <li>
+ Industry Analysts
+ </li>
+ <li>
+ Information about competitors&nbsp;
+ </li>
+</ul>
+<h3>
+ Requirements Gathering Techniques
+</h3>
+<p>
+ After you have identified these sources, there are a number of techniques that may be used to gather requirements. The
+ following will describe the various techniques, followed by a brief discussion of when to use each technique.
+</p>
+<p>
+ To get the requirements down on paper, you&nbsp;can to do one or more of the following:
+</p>
+<ul>
+ <li>
+ Conduct a brainstorming session
+ </li>
+ <li>
+ Interview users
+ </li>
+ <li>
+ Send questionnaires
+ </li>
+ <li>
+ Work in the target environment
+ </li>
+ <li>
+ Study analogous systems
+ </li>
+ <li>
+ Examine suggestions and problem reports
+ </li>
+ <li>
+ Talk to support teams
+ </li>
+ <li>
+ Study improvements made by users
+ </li>
+ <li>
+ Look at unintended uses
+ </li>
+ <li>
+ Conduct workshops
+ </li>
+ <li>
+ Demonstrate prototypes to stakeholders
+ </li>
+</ul>
+<p>
+ The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put
+ in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best
+ structure you can devise, but expect to keep on correcting it throughout the process.&nbsp; Success tips: Do it now,
+ keep it small, and correct it immediately.
+</p>
+<h4>
+ Conduct a brainstorming session
+</h4>
+<p>
+ Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of
+ discussion. After that, a facilitator leads the group in organizing and prioritizing the results.&nbsp; The following
+ basic rules for brainstorming&nbsp;ensures better results:
+</p>
+<ul>
+ <li>
+ Start out by clearly stating the objective of the brainstorming session.
+ </li>
+ <li>
+ Generate as may ideas as possible.
+ </li>
+ <li>
+ Let your imagination soar.
+ </li>
+ <li>
+ Do not allow criticism or debate while you are gathering information.
+ </li>
+ <li>
+ Once information is gathered,&nbsp;reshape and combine ideas.
+ </li>
+</ul>
+<h4>
+ Interview users
+</h4>
+<p>
+ Face-to-face contact with users through individual interviewing is the primary source of requirements and an important
+ way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can
+ conduct interviews many different ways. Develop a repertoire of styles to&nbsp;fit different situations. Unless you use
+ the system yourself, you will need to make an effort to understand and experience the user's problem to describe it
+ clearly and correctly.
+</p>
+<h4>
+ Send Questionnaires
+</h4>
+<p>
+ If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering
+ the problem behind the problem. Sometimes, though,&nbsp;face-to-face meetings with stakeholders are not feasible (when
+ developing products for the consumer market, for example). In those situations, consider using questionnaires.&nbsp;
+ Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to
+ complete it and return it to you.&nbsp; Success&nbsp;tips: Keep it short and given them a deadline.&nbsp;
+</p>
+<p>
+ This technique has the advantage of providing a lot of information for statistical analysis. However, the questions
+ must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.&nbsp;
+</p>
+<h4>
+ Work in the target environment
+</h4>
+<p>
+ Experience the work of the users for yourself. Working with users helps you understand problems that have resisted
+ previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as
+ interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the
+ desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other
+ areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just
+ sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they
+ would like to have to make the work easier.
+</p>
+<h4>
+ Study analogous systems
+</h4>
+<p>
+ The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and
+ systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the
+ wheel by looking at systems already on the market, whether they are systems installed at the user's site or products
+ made by rival organizations. Even if they are trying to solve slightly different problems, they often&nbsp;provide
+ valuable clues as to what you need to do.
+</p>
+<p>
+ Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these
+ suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements
+ directly this way. If not, capture and store suggestions for future use.
+</p>
+<p>
+ You can describe to users selected features of other products. Explain that the system is designed for&nbsp;another
+ purpose&nbsp;but contains an interesting feature, and you wonder it or something similar&nbsp;would help them.
+ Sometimes these systems are described in documents, such as a contract from another organization or a report written
+ for management. Often, these documents were never intended as formal requirements, and were written merely to
+ communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
+</p>
+<p>
+ Such a process might involve the following activities:
+</p>
+<ul>
+ <li>
+ Read the document from end to end (several times) to comprehend what the customer wants and what actually has been
+ written.
+ </li>
+ <li>
+ Classify all of the types of information in the document. (user, system requirements, design elements, plans,
+ background material, irrelevant detail)
+ </li>
+ <li>
+ Mark up the original text to separate out such requirements.
+ </li>
+ <li>
+ Find a good structure for each of the different types of information such as: a scenario for the user requirements,
+ functional breakdown for the system requirements, and architecture for the design.
+ </li>
+ <li>
+ Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions
+ with the users.
+ </li>
+ <li>
+ Create traceability links between these information elements to show the designers exactly what the users want.
+ </li>
+ <li>
+ Convince the customer to accept the new information as the basis for the contract.
+ </li>
+</ul>
+<h4>
+ Examine suggestions and problem reports
+</h4>
+<p>
+ Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at
+ suggestions and problems as first described. Most organizations have a form for reporting system problems or software
+ defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can
+ identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users'
+ actual needs.
+</p>
+<h4>
+ Talk to support teams
+</h4>
+<p>
+ Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do
+ the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff
+ and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training
+ team and installation teams about what users find to be&nbsp;difficult.
+</p>
+<h4>
+ Study improvements made by users
+</h4>
+<p>
+ This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or
+ related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why
+ did you add that? Their answers help you&nbsp;get to the heart of the actual requirement. This applies also to hardware
+ and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents
+ movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product,
+ which makes it&nbsp;a valid&nbsp;requirement for the new version.
+</p>
+<h4>
+ Look at unintended uses
+</h4>
+<p>
+ People often use things for purposes for which they were not designed.&nbsp; This is&nbsp;a good way to get new ideas
+ and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the
+ office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive
+ commercial products are now widely available for home use.
+</p>
+<h4>
+ Conduct workshops
+</h4>
+<p>
+ Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of
+ requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each
+ requirement, the document becomes much more useful and cost-effective.
+</p>
+<p>
+ Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You
+ are bringing the right collection of people together, and getting them to correct and improve on their requirements
+ document.
+</p>
+<p>
+ A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If
+ you can define the product right the first time and cut three months off the requirements gathering, the savings could
+ be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
+</p>
+<p>
+ Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should
+ be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that
+ people don't go home at night or go out separately. The example&nbsp;in Figure 1&nbsp;shows the logic of a requirements
+ workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques
+ such as brainstorming.
+</p>
+<p>
+ <img height="381" alt="" src="./resources/Workshop%20Activity%20Diagram.GIF" width="542" />
+</p>
+<p>
+ <strong>Figure 1: Conducting Workshops</strong>
+</p>
+<h4>
+ Demonstrate prototypes to stakeholders
+</h4>
+<p>
+ Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can
+ provoke&nbsp;them into giving good requirements information or changing their mind about existing requirements. The
+ techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of
+ presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might
+ be able to do. More requirements are likely to emerge when users see what you are suggesting.
+</p>
+<p>
+ A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a
+ vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that
+ there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here
+ for the unwary).
+</p>
+<p>
+ This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or
+ product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and
+ right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems
+ with the prototype! This is excellent,&nbsp;because each problem leads to a new requirement.
+</p>
+<h3>
+ Which Technique to Apply?
+</h3>
+<p>
+ Which technique to apply depends on a number of factors, such as:
+</p>
+<ul>
+ <li>
+ Availability and location of stakeholders
+ </li>
+ <li>
+ Development team knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the development process and methods
+ </li>
+</ul>
+<p>
+ If the stakeholders are not co-located or readily available, for example in the case of a product being developed for
+ mass market,&nbsp;techniques such as brainstorming, interviews and workshops that require face-to-face contact with the
+ stakeholders may be difficult or impossible.
+</p>
+<p>
+ If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the
+ techniques described, or combination of them, may be applied. In this case, the domain and development experience of
+ oth the stakeholders and the development team are critical factors in selecting the appropriate technique.
+</p>
+<p>
+ Figure 2, adapted from <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>, provides a framework for determining the appropriate techniques. It
+ defines four main categories of customer or user experience and development team experience: "Fuzzy problem",
+ "Selling/Teaching", "Catch up", and "Mature".
+</p>
+<p>
+ <img height="470" alt="" src="./resources/Which%20Req%20Gathering%20Technique.gif" width="514" />
+</p>
+<p>
+ <strong>Figure 2: Selection of Techniques</strong>
+</p>
+<p>
+ There is no "right answer", but these guidelines may help you decide which method to use:
+</p>
+<ul>
+ <li>
+ Catch-up: Interviews, work in target environment
+ </li>
+ <li>
+ Fuzzy: Brainstorming, workshops
+ </li>
+ <li>
+ Mature: Questionnaires, workshops, prototypes
+ </li>
+ <li>
+ Selling/Teaching: prototypes
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/requirement_pitfalls.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/requirement_pitfalls.xmi
new file mode 100644
index 0000000..8930001
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/requirement_pitfalls.xmi
@@ -0,0 +1,250 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-Q72-dNdHnZ93aRXAB_d34A" name="requirement_pitfalls_1,_1AOsMO0JEdqHTdbLTmC5IQ" guid="-Q72-dNdHnZ93aRXAB_d34A" authors="Chris Sibbald" changeDate="2006-09-27T10:14:43.487-0700" version="0.2">
+ <mainDescription><p>
+ Explanations and examples follow for each of the following common pitfalls to avoid, in defining and writing
+ requirements (for more information, see <a class="" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>):
+</p>
+<ul>
+ <li>
+ Avoid ambiguity.
+ </li>
+ <li>
+ Don't make multiple requirements.
+ </li>
+ <li>
+ Never use let-out or escape words.
+ </li>
+ <li>
+ Don't ramble.
+ </li>
+ <li>
+ Resist designing the system.
+ </li>
+ <li>
+ Avoid mixing different kinds of requirements.
+ </li>
+ <li>
+ Do not speculate.
+ </li>
+ <li>
+ Do not use vague, undefined terms.
+ </li>
+ <li>
+ Do not express possibilities.
+ </li>
+ <li>
+ Avoid wishful thinking.
+ </li>
+</ul>
+<h4>
+ Avoid ambiguity
+</h4>
+<p>
+ Avoidance of ambiguity is one of the subtlest and most difficult issues in writing requirements. Try to write as
+ clearly and explicitly as possible. Be specific. Remember, though, that if you carry this too far, the text becomes
+ dull and unreadable, which makes it difficult for other people to review. Although this guideline emphasizes
+ structured, written expression of requirements, informal text, diagrams, conversations, and phone calls are excellent
+ ways of removing ambiguity.
+</p>
+<p>
+ Some constructions (such as the use of or and unless in requirements) allow different groups of readers to understand
+ different things from the same wording. Developers could use this technique deliberately, so as to postpone, until too
+ late, any possibility of the customer's asking for what was truly wanted. This is dangerous and could easily backfire.
+</p>
+<p>
+ The only approach that works is for developers to make requirements as clear as possible, and for all stakeholders to
+ co-operate. In the long run, project success is in everybody's interest.
+</p>
+<p>
+ Dangerous ambiguities can be caused by the word <strong>or</strong> and also by many more-subtle errors.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The same subsystem shall also be able to generate a visible or audible caution/warning signal for the attention of
+ the co-pilot or navigator.</em>
+</p>
+<p>
+ Which subsystem? Is the signal to be visible, audible, or both? Is it both caution and warning, just caution, or just
+ warning? Is it for both the co-pilot and the navigator, or just one of them? If just one of them, which one and under
+ what conditions?
+</p>
+<h4>
+ Don't make multiple requirements
+</h4>
+<p>
+ Requirements which contain conjunctions (words that join independent clauses together) are dangerous. Problems arise
+ when readers try to figure out which part applies, especially if the different clauses seem to conflict, or if the
+ individual parts apply separately. Multiple requirements also make verification more complex.
+</p>
+<p>
+ Dangerous conjunctions include: and, or, but
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or
+ input data shall be saved.</em>
+</p>
+<p>
+ Should the battery low warning lamp light up when the voltage drops and the workspace is saved? Should the battery low
+ warning lamp light up and the workspace be saved when the voltage drops?
+</p>
+<h4>
+ Never use let-out or escape words
+</h4>
+<p>
+ Requirements that include options or exceptions are dangerous. They seem to ask for something definite, but at the last
+ moment they back down and allow for other options. Problems arise when the requirements are to be tested, and someone
+ has to decide what (if anything) could prove the requirement was met.
+</p>
+<p>
+ Dangerous words that imply exceptions include: if, when, but, except, unless, although.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is
+ deployed.</em>
+</p>
+<p>
+ <em>The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has
+ suppressed the alarm.</em>
+</p>
+<p>
+ The latter sentence is a truly dangerous requirement!
+</p>
+<h4>
+ Don't ramble
+</h4>
+<p>
+ Long rambling sentences, especially when combined with arcane language, references to unreachable documents, and other
+ defects of writing, quickly lead to confusion and error.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Provided that the designated input signals from the specified devices are received in the correct order where the
+ system is able to differentiate the designators, the output signal shall comply with the required framework of section
+ 3.1.5 to indicate the desired input state.</em>
+</p>
+<h4>
+ Resist designing the system
+</h4>
+<p>
+ Requirements should specify the design envelope without unnecessary constraints on a specific design. If we supply too
+ much detail we start to design the system. Going too far is tempting for designers, especially when they come to their
+ favorite bits.
+</p>
+<p>
+ Danger signs include names of components, materials, software objects/procedures, and database fields.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof
+ hardened rubber shield.</em>
+</p>
+<p>
+ Specifying design rather than actual need increases the cost of systems by placing needless constraints on development
+ and manufacture. Often knowing why is much better than knowing what.
+</p>
+<h4>
+ Avoid mixing different kinds of requirements
+</h4>
+<p>
+ The user requirements form a complete model of what users want. They need to be organized coherently to show gaps and
+ overlaps. The same applies to system requirements, which form a complete functional model of the proposed system. A
+ quick road to confusion is to mix up requirements for users, systems, and how the system should be designed, tested, or
+ installed.
+</p>
+<p>
+ Danger signs are any references to system, design, testing, or installation.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The user shall be able to view the currently selected channel number which shall be displayed in 14pt Swiss type on
+ an LCD panel tested to Federal Regulation Standard 567-89 and mounted with shockproof rubber washers.</em>
+</p>
+<h4>
+ Do not speculate
+</h4>
+<p>
+ Requirements are part of a contract between customer and developer. There is no room for wish lists, meaning general
+ terms about things that somebody probably wants.
+</p>
+<p>
+ Danger signs include vagueness about which type of user is speaking, and generalization such as: usually, generally,
+ often, normally, typically
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Users normally require early indication of intrusion into the system.</em>
+</p>
+<h4>
+ Do not use vague, undefined terms
+</h4>
+<p>
+ Many words used informally to indicate system quality are too vague for use in requirements. Vague terms include, among
+ others: user-friendly, versatile, flexible, approximately, as possible
+</p>
+<p>
+ Requirements using these terms are unverifiable because there is no definite test to show whether the system has the
+ indicated property.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The print dialog shall be versatile and user-friendly.</em>
+</p>
+<p>
+ <em>The OK status indicator lamp shall be illuminated as soon as possible after the system self-check is
+ completed.</em>
+</p>
+<h4>
+ Do not express possibilities
+</h4>
+<p>
+ Suggestions that are not explicitly stated as requirements are invariably ignored by developers.
+</p>
+<p>
+ "Possible options" are indicated with terms such as: may, might, should, ought, could, perhaps, probably
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed
+ building.</em>
+</p>
+<h4>
+ Avoid wishful thinking
+</h4>
+<p>
+ Engineering is a real-world activity. No system or component is perfect. Wishful thinking means asking for the
+ impossible.
+</p>
+<p>
+ Wishful-thinking terms include: reliable, safe, handle all unexpected failures, please all users, run on all platforms,
+ never fail, upgradeable to all future situations
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The gearbox shall be 100% safe in normal operation.</em>
+</p>
+<p>
+ <em>The network shall handle all unexpected errors without crashing.</em>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/4plus1_2.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/4plus1_2.jpg
new file mode 100644
index 0000000..24cfc97
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/4plus1_2.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG
new file mode 100644
index 0000000..903bdea
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/IdentifyElementsBCE.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/PDMSample.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/PDMSample.JPG
new file mode 100644
index 0000000..5ad1683
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/PDMSample.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG
new file mode 100644
index 0000000..0270965
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/UserLoginSeq.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG
new file mode 100644
index 0000000..6e965d1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/UserLoginUCM.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/WBR Fig 1.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/WBR Fig 1.JPG
new file mode 100644
index 0000000..45bf93e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/WBR Fig 1.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/WBR Fig 3.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/WBR Fig 3.JPG
new file mode 100644
index 0000000..b4e8d48
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/WBR Fig 3.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/Which Req Gathering Technique.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/Which Req Gathering Technique.gif
new file mode 100644
index 0000000..10b6366
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/Which Req Gathering Technique.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/Workshop Activity Diagram.GIF b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/Workshop Activity Diagram.GIF
new file mode 100644
index 0000000..228f102
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/Workshop Activity Diagram.GIF
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ac_intsy.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ac_intsy.gif
new file mode 100644
index 0000000..b4e468f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ac_intsy.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec1.gif
new file mode 100644
index 0000000..b076e0b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec2.gif
new file mode 100644
index 0000000..b8b7cd9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec3.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec3.gif
new file mode 100644
index 0000000..bfd2a4b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/co_dmec3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/compass.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/compass.gif
new file mode 100644
index 0000000..39f306a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/compass.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/compassL.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/compassL.gif
new file mode 100644
index 0000000..4117414
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/compassL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/dm_1.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/dm_1.jpg
new file mode 100644
index 0000000..7c443c4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/dm_1.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG
new file mode 100644
index 0000000..ae585d8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/dv_Packaging.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/icon_introL.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/icon_introL.gif
new file mode 100644
index 0000000..1826cbd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/icon_introL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc1.gif
new file mode 100644
index 0000000..1c2beb3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc2.gif
new file mode 100644
index 0000000..717c2b2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc3.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc3.gif
new file mode 100644
index 0000000..06f3a9d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc4.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc4.gif
new file mode 100644
index 0000000..cb79539
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc4.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc5.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc5.gif
new file mode 100644
index 0000000..8559e50
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc5.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc6.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc6.gif
new file mode 100644
index 0000000..13a7b72
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/jdbc6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/login_vopc.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/login_vopc.jpg
new file mode 100644
index 0000000..0d46428
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/login_vopc.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg
new file mode 100644
index 0000000..dafa9b7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/login_vopc_refined.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd02.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd02.gif
new file mode 100644
index 0000000..7cd32c8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd02.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd03.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd03.gif
new file mode 100644
index 0000000..f7bd16b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd03.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd05.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd05.gif
new file mode 100644
index 0000000..ccd95b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd05.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd06.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd06.gif
new file mode 100644
index 0000000..7a78158
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd06.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd08.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd08.gif
new file mode 100644
index 0000000..a32d7b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd08.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd09.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd09.gif
new file mode 100644
index 0000000..cab0b90
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd09.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd10.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd10.gif
new file mode 100644
index 0000000..d637473
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd10.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd11.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd11.gif
new file mode 100644
index 0000000..6e296de
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd11.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd12.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd12.gif
new file mode 100644
index 0000000..88d7fce
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd12.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd13.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd13.gif
new file mode 100644
index 0000000..9ce8e35
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd13.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd14.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd14.gif
new file mode 100644
index 0000000..db36d0c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd14.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd15.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd15.gif
new file mode 100644
index 0000000..33eb769
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd15.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd16.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd16.gif
new file mode 100644
index 0000000..8ca3f5d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd16.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd17.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd17.gif
new file mode 100644
index 0000000..76b321b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd17.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd18.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd18.gif
new file mode 100644
index 0000000..583cc54
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd18.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd19.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd19.gif
new file mode 100644
index 0000000..e7fc0b0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd19.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd20.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd20.gif
new file mode 100644
index 0000000..adc1a9a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd20.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd21.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd21.gif
new file mode 100644
index 0000000..83b2c2c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd21.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd22.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd22.gif
new file mode 100644
index 0000000..91e7c76
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_datamd22.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_ucmo6.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_ucmo6.gif
new file mode 100644
index 0000000..14a7376
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_ucmo6.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_ucre3.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_ucre3.gif
new file mode 100644
index 0000000..7f4cf27
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/md_ucre3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/mic.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/mic.gif
new file mode 100644
index 0000000..0b316db
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/mic.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ucmex2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ucmex2.gif
new file mode 100644
index 0000000..7f71f61
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ucmex2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ucrea1.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ucrea1.gif
new file mode 100644
index 0000000..78190a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/ucrea1.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wg_fish.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wg_fish.gif
new file mode 100644
index 0000000..d2103d6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wg_fish.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wg_paret.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wg_paret.gif
new file mode 100644
index 0000000..8332803
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wg_paret.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wil_overview.bmp b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wil_overview.bmp
new file mode 100644
index 0000000..920106d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/resources/wil_overview.bmp
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/self_organize_work_assignments.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/self_organize_work_assignments.xmi
new file mode 100644
index 0000000..4b8dce2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/self_organize_work_assignments.xmi
@@ -0,0 +1,100 @@
+<?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" epf:version="1.0.0" xmi:id="-e26WOHRbTVQrDssK5zijVA" name="self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA" guid="-e26WOHRbTVQrDssK5zijVA" changeDate="2007-01-05T09:07:49.299-0500" version="1.0.0">
+ <mainDescription><p>
+ A "self organizing team" has the authority to choose the work that it will perform and the responsibility to do that
+ work in the way that it chooses.&nbsp; Important aspects of a self organizing team&nbsp;are:
+</p>
+<ol>
+ <li>
+ The team selects its own work. At the beginning of an iteration the team collectively selects the <a class=""
+ href="./../../../openup_basic/guidances/termdefinitions/work_item,_jyVgcEvKEdunZcj9T5hrMQ.html"
+ guid="_jyVgcEvKEdunZcj9T5hrMQ">work item</a>s from the prioritized <a class=""
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>. Work selection is performed within given constraints, including
+ the priorities set by <a class="" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s, time (such as the length of the current <a class=""
+ href="./../../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html"
+ guid="_lam4ADkBEduxovfWMDsntw">Iteration</a>), the budget, and the skills of team members.
+ </li>
+ <li>
+ Individuals select their own work. Individuals are empowered to select their own work. Someone will choose to do
+ something because they are good at it and know that they can do the work effectively, because they want to gain
+ more experience at something and hope to improve their skill-set by working with someone with such experience, or
+ because they know that the work needs to be done and that it's their turn to do so. Although an individual fulfills
+ one or more roles on a project team that doesn't imply that the person is constrained to only doing specific types
+ of work.
+ </li>
+ <li>
+ The team determines how to perform the work. At the beginning of an iteration the team will hold an "all hands"
+ planning meeting where it determines the general strategy for doing the work and the tasks required to do so. More
+ detailed planning, if required, will be done on a just-in-time (JIT) basis by the individual(s) doing the work.
+ Note that the team is still constrained by your organization's standards, technical infrastructure, regulations,
+ and so on.
+ </li>
+ <li>
+ Everyone commits to the work. The team commits to accomplishing the work that it has agreed to do by the end of the
+ iteration. Individuals also commit to doing the work that they say they will do, although as the iteration
+ progresses various tasks may be renegotiated as required.
+ </li>
+ <li>
+ The team coordinates regularly. To ensure that the work is accomplished the team must coordinate its efforts
+ effectively. This is typically done through daily stand up meetings of the team and impromptu discussions between
+ individuals.
+ </li>
+</ol>
+<p>
+ This is a participatory approach to decision making where everyone has the opportunity to provide input and to listen
+ to the decision making process. The goal is to make decisions at the right place within the organizational structure,
+ empowering teams by giving them both the responsibility and the authority to get the job done. It improves motivation
+ amongst team members, and thereby their productivity, by giving them control over their work.
+</p>
+<h3>
+ Project Manager Responsibilities
+</h3>
+<p>
+ There is still work for the <a href="./../../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a> on self organizing teams. The project manager must still:
+</p>
+<ol>
+ <li>
+ Provide leadership. Team culture and project vision must be nurtured and evolved throughout the project, and
+ direction must be provided to the team.
+ </li>
+ <li>
+ Mediate disagreements. The manager must be prepared to step in and make a decision when other team members are
+ unable to come to a decision.
+ </li>
+ <li>
+ Ensure that team members grow their skill-set. From time to time the manager may need to motivate individuals to
+ take on new tasks that are outside their comfort zone or to work with others to help those people gain new skills.
+ </li>
+ <li>
+ Ensure that the team respects their limits. Self organizing teams have the authority to make decisions within the
+ scope of their responsibility, but that doesn't mean that they get to rethink everything that they feel like. For
+ example, the development team must still conform to the technical infrastructure and to the business strategy of
+ your organization: they likely don't have the authority to change these things even though they may not fully agree
+ with them. When an issue falls outside their scope of responsibility the team must either accept it or collaborate
+ with the people with the appropriate authority.
+ </li>
+ <li>
+ Summarize the project plan. External stakeholders, such as senior management or business representatives not
+ actively involved with the team, will want to know the current status of the project and the team's current plans.
+ The project manager may be required to summarize and communicate this information to those people.
+ </li>
+</ol>
+<h3>
+ What This Isn't
+</h3>
+<p>
+ The concept of self organizing teams often sounds like anarchy or non-management to traditional IT professionals, but
+ nothing could be further from the truth. Although self organization relies on team members being responsible and mature
+ it is tempered by the guiding hand of a good project manager. It is also tempered by organizational standards,
+ infrastructure, and external regulations. "Self organizing" doesn't mean that you have complete freedom to do what you
+ want.
+</p>
+<p>
+ Self organization isn't necessarily a consensus-based approach either; sometimes individuals will disagree with a
+ decision but will choose to go along with the will of the team. Nevertheless, consensus isn't ruled out by this
+ approach but it certainly isn't required.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/staffing_project.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/staffing_project.xmi
new file mode 100644
index 0000000..808d03a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/staffing_project.xmi
@@ -0,0 +1,63 @@
+<?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" epf:version="1.0.0" xmi:id="-HYO1lwAFOxlT7ncq8EjSng" name="new_guideline,_Jq64EJjsEduad8I_c-ogIA" guid="-HYO1lwAFOxlT7ncq8EjSng" changeDate="2007-01-31T13:46:21.802-0500" version="1.0.0">
+ <mainDescription><p>
+ Good software development teams are made up of a collection of people who collaborate effectively. How the project team
+ is staffed, by either adding or removing people, will greatly impact the team's productivity.
+</p>
+<p>
+ When staffing a development project, consider the following advice:
+</p>
+<ol>
+ <li>
+ Include people who fit into the existing team culture. Good teams don't just appear magically one day, but instead
+ are grown and nurtured over time. Invite people onto the team who will add value and furthermore who will not be
+ disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
+ team and they don't seem to be able to change.
+ </li>
+ <li>
+ People should want to be on the team. People are far more productive when they're working on a project that they
+ believe in and want to see succeed.
+ </li>
+ <li>
+ Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
+ specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas,
+ including both technical and domain areas. Generalizing specialists add value to the team because they have
+ specialized skills that you need while at the same time appreciate the full range of issues that a general
+ understanding of the software development process and the business domain offers.
+ </li>
+ <li>
+ Include stakeholders. Stakeholders, including business stakeholders such as end users and technical stakeholders
+ such as operations staff, can add significant value to your team. Instead of just interviewing them to gain
+ information from them, or asking them to review your work, why not include them as active participants on the team?
+ </li>
+ <li>
+ Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
+ particularly when they have specific skills and experience which existing team members do not have. It can often be
+ more effective to bring a specialist into the team for a short period of time to help with a specific task, such as
+ installation and setup of an application server, the development of an architectural spike, or simply taking part
+ in a review.
+ </li>
+ <li>
+ Give people opportunities to evolve their skills. At the beginning of a project the team may not have the full
+ range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
+ they are filling. This is a very common risk taken on by the majority of project teams for the simple reasons that
+ you often can't find the perfect combination of people and even if you could you still want to provide people with
+ opportunities to grow as professionals.
+ </li>
+ <li>
+ Remember Brook's Law. Adding people to a late project will only make it later [<a class=""
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BRO95</a>]. The corollary is that removing people from a late project may speed
+ things up [<a class=""
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
+ </li>
+</ol>
+<p>
+ Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
+ are available (although there's nothing stopping a specialist from becoming a generalizing specialist), perhaps there
+ aren't as many opportunities for people to try new things as they would like, or perhaps the stakeholders aren't
+ available to be active members of the team. The advice above is designed to lead to as high-performing a team as
+ possible, but even partial adherence to this guideline will improve the team.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi
new file mode 100644
index 0000000..9c34e29
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/submitting_change_requests.xmi
@@ -0,0 +1,65 @@
+<?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" epf:version="1.0.0" xmi:id="-w7sImtXWkf4HDXdUWjRsUg" name="new_guideline,_fnZj0NVXEdqy9sbRhejO5Q" guid="-w7sImtXWkf4HDXdUWjRsUg" authors="Chris Sibbald" changeDate="2007-02-26T13:52:05.226-0500" changeDescription="Moved content from previous concept:change request to this guideline and updated in accordance with discussion from April 18, 2006 telecon." version="0.2">
+ <mainDescription><h3>
+ Background
+</h3>
+<p>
+ Change requests typically have a lifecycle. They are raised,&nbsp;reviewed, accepted or rejected, implemented, verified
+ and closed. These states define the status of the change request at a particular point in time and represent critical
+ information for tracking progress. Other sets of states are possible.
+</p>
+<p>
+ During review of a change request, the goal&nbsp;is to assess the&nbsp;technical, cost, and schedule impact
+ of&nbsp;implementing the change.&nbsp; The technical impact&nbsp;assessment includes&nbsp;the determination of
+ which&nbsp;work products&nbsp;are affected and an estimate of the level of effort required to change and verify all
+ affected artifacts. This information becomes the basis of the cost and schedule impact assessments and, ultimately,
+ whether the change request will be accepted or rejected.
+</p>
+<p>
+ If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
+ manner as any other work item.
+</p>
+<p>
+ The&nbsp;current process uses the <a class="elementLinkWithType"
+ href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
+ using the attributes defined for that artifact.
+</p>
+<h3>
+ Submitting Change Requests
+</h3>
+<p>
+ When submitting a change request provide as much information as possible to enable a speedy review and
+ disposition.&nbsp; As a minimum, all change requests should include the following information:
+</p>
+<ul>
+ <li>
+ <strong>ID</strong> - a unique identifier for the change request to simplify tracking.&nbsp; If you are using some
+ form of change tracking tool the tool will assign a unique ID.
+ </li>
+ <li>
+ <strong>Brief Description</strong>&nbsp;- a name that summarizes the change request
+ </li>
+ <li>
+ <strong>Detailed Description</strong> - A detailed description of the change request.&nbsp; For a defect, if you
+ can provide information that will help reproduce the defect please do so.&nbsp; For an enhancement request, provide
+ a rationale for the request.
+ </li>
+ <li>
+ <strong>Affected Item</strong>&nbsp;- the affected artifact and version.
+ </li>
+ <li>
+ <strong>Severity</strong> - how severe is this issue (show stopper, nice to have, etc.).
+ </li>
+ <li>
+ <strong>Priority</strong> - how important it is this request in your opinion.
+ </li>
+</ul>
+<p>
+ Depending upon the system you are using, the names of these data elements may differ.&nbsp; However, this information
+ is required, in one form or another, to permit a speedy review and disposition of the change request.
+</p>
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/supporting_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/supporting_requirements.xmi
new file mode 100644
index 0000000..afd0639
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/supporting_requirements.xmi
@@ -0,0 +1,417 @@
+<?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" epf:version="1.0.0" xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" name="supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q" guid="-BdYFG4-dbPBGFzF9z6KGPA" changeDate="2006-12-21T12:43:46.709-0500" version="1.0.0">
+ <mainDescription><p>
+ There is a finite set of requirements to consider when it comes to gathering system-wide requirements, qualities, or
+ constraints. Many of them are unfamiliar to stakeholders; therefore, they may find it difficult to answer questions
+ related to topics such as availability, performance, scalability, or localization. You can use this guideline and the
+ associated checklist <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.html"
+ guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a>&nbsp;when speaking to stakeholders to ensure that
+ all topics are discussed. Make sure that stakeholders understand the costs of their selections and do not end up
+ wanting everything that is on the list.
+</p>
+<h3>
+ Functional
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Auditing:</strong> Is there a need to track who used the system and when they used it? State
+ requirements for providing audit trails when running the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Authentication:</strong> Will access to the system be controlled? State requirements for
+ authentication.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Licensing:</strong> Will the system or parts of the system be licensed? If open-source software has
+ been used in the system, have all open-source agreements been respected? State requirements for acquiring,
+ installing, tracking, and monitoring licenses.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Printing:</strong> Will printing capability be required? State requirements for printing.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Reporting:</strong> Is reporting capability required? State requirements for reporting.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Scheduling:</strong> Will certain system actions need to be scheduled? State requirements for
+ scheduling capability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Security:</strong> Will elements of the system or system data need to be secure? State requirements to
+ protect access to certain resources or information.
+ </p>
+ </li>
+</ul>
+<h3>
+ Usability
+</h3>
+<p>
+ Usability requirements are critical to the success of any system. Unfortunately, usability requirements are often the
+ most poorly specified requirements. Consider this common requirement: The system shall be easy to use. This doesn't
+ help much, because it cannot be verified.
+</p>
+<p>
+ While capturing usability requirements, it is a good idea to identify issues and concerns first, and then refine these
+ into verifiable requirements later (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>). According to a traditional definition,
+ usability consists of five factors:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Ease of learning:</strong> A user with a specified level of experience must be able to learn how to use
+ the system in a specified amount of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Task efficiency:</strong> A user should be able to complete a specified task in a specified time (or
+ number of mouse clicks).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Ease of remembering:</strong> A user should be able to remember how to accomplish specified tasks after
+ not using the system for a specified period of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understandability:</strong> A user must be able to understand system prompts and messages and what the
+ system does.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Subjective satisfaction:</strong> A specified percentage of the user community must express
+ satisfaction with using the system.
+ </p>
+ </li>
+</ul>
+<p>
+ You may want to use the following method to identify and specify usability requirements:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ol>
+ <li>
+ Identify the key usability issues by looking at critical tasks, user profiles, system goals, and previous
+ usability problems.
+ </li>
+ <li>
+ Choose the appropriate style to express the requirements:
+ <ul>
+ <li>
+ <strong>Performance style:</strong> Specify how fast users can learn various tasks and how fast they
+ can perform the tasks after training.
+ </li>
+ <li>
+ <strong>Defect style:</strong> Rather than measuring task times, identify usability defects and
+ specifies how frequently they may occur.
+ </li>
+ <li>
+ <strong>Guideline style:</strong> Specify the general appearance and response time of the user
+ interface by reference to an accepted and well-defined standard
+ </li>
+ </ul>
+ </li>
+ <li>
+ Write the actual requirements, including performance criteria (see <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>&nbsp;for more information).
+ </li>
+ </ol>
+</div>
+<h3>
+ Reliability
+</h3>
+<p>
+ Reliability includes the system's ability to continue running under stress and adverse conditions. In the case of an
+ application, reliability relates to the amount of time that the software is available and running as opposed to time
+ unavailable. Specify reliability acceptance levels, as well as how they will be measured and evaluated. Describe
+ reliability criteria in measurable terms. This is usually expressed as the allowable time between failures or the total
+ allowable failure rate. Other important reliability considerations include:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Accuracy:</strong> Specify requirements for the precision (resolution) and the accuracy (by some known
+ standard) that is required in any calculation performed or in system output.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Availability:</strong> Specify requirements for the percentage of time the system is available for use,
+ hours of use, maintenance access, and degraded-mode operations. Availability is typically specified in terms of
+ the Mean Time Between Failures (MTBF).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Recoverability:</strong> Specify requirements for recovery from failure. This is typically specified in
+ terms of the Mean Time to Repair (MTTR).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Frequency and severity of failures:</strong> Specify the maximum defect rate (typically expressed as
+ defects/KSLOC or defects/function-point) and severity of failures. Severity&nbsp;may be categorized in terms of
+ <strong>minor</strong>, <strong>significant</strong>, and <strong>critical</strong> defects. The requirements
+ must define each of these terms unambiguously. For example, a <strong>critical</strong> defect could be defined
+ as one that results in loss of data or complete inability to use certain functionality of the system.
+ </p>
+ </li>
+</ul>
+<h3>
+ Performance
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Response times:</strong> Specify the amount of time available for the system to complete specified
+ tasks and transactions (average, maximum). Use units of measurement. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ Any interface between a user and the system shall have a maximum response time of 2 seconds.
+ </li>
+ <li>
+ The product shall download the new status parameters within 5 minutes of a change.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Throughput:</strong> Specify the capacity of the system to support a given flow of information (for
+ example, transactions per second).<br />
+ </li>
+ <li>
+ <strong>Capacity:</strong> Specify on the volumes that the product must be able to deal with and the numbers of
+ data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
+ unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
+ (memory, disk, . . . ) or degradation modes (what is the acceptable mode of operation when the system has been
+ degraded in some manner) <em>Examples:</em>
+ <ul>
+ <li>
+ The product shall cater for 300 simultaneous users within the period from 9:00 AM to 11 AM.
+ </li>
+ <li>
+ Maximum loading at other periods will be 150.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Start-up:</strong> The time for the system to start up.<br />
+ </li>
+ <li>
+ <strong>Shut-down:</strong> The time for the system to shut down.
+ </li>
+</ul>
+<h3>
+ Supportability
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Adaptability:</strong> Are there any special requirements regarding adaptation of the software
+ (including upgrading)? List requirements for the ease with which the system is adapted to new environments.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Compatibility:</strong> Are there any requirements regarding this system and its compatibility with
+ previous versions of this system or legacy systems that provide the same capability?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Configurability:</strong> Will the product be configured after it has been deployed? In what way will
+ the system be configured?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Installation:</strong> State any special requirements regarding system installation
+ </p>
+ </li>
+ <li>
+ <strong>Level of Support:</strong> What is the level of support that the product requires? This is often done using
+ a Help desk. If there are to be people who provide support for the product, is that support considered part of what
+ you are providing to the customer? Are there any requirements for that support? You might also build support into
+ the product itself, in which case this is the place to write those requirements. Consider the level of support that
+ you anticipate providing and what forms it might take.<br />
+ </li>
+ <li>
+ <strong>Maintainability:</strong> Are there any special requirements regarding system maintenance? What are the
+ requirements for the intended release cycle for the product and the form that the release will take? Quantify the
+ time necessary to make specified changes to the product. There may also be special requirements for
+ maintainability, such as&nbsp;a requirement that&nbsp;the product must be able to be maintained by its end-users or
+ developers who are not your development team. This has an effect on the way that the product is developed, and
+ there may be additional requirements for documentation or training. Describe the type of maintenance and the amount
+ of effort required. <em>Examples:</em><br />
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ A new weather station must be able to be added to the system overnight.
+ </li>
+ <li>
+ The maintenance releases will be offered to end-users once a year.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Scalability:</strong> What volumes of users and data will the system support? This specifies the expected
+ increases in size that the product must be able to handle As businesses grow (or are expected to grow), the
+ software products must increase their capacities to cope with the new volumes. This may be expressed as a profile
+ over time.<br />
+ </li>
+ <li>
+ <strong>Testability:</strong> Are there any special requirements regarding the testability of the system?
+ </li>
+</ul>
+<h3>
+ Constraints (+)
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Design constraints:</strong> Are there any design decisions that have been mandated that the product
+ must adhered to?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Third-party components:</strong> Specify any mandated legacy, COTS, or open-source components to be
+ used with the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation languages:</strong> Specify requirements on the implementation languages to be used
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Platform support:</strong> Specify requirements on the platforms that the system will support
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Resource limits:</strong> Specify requirements on the use of system resources, such as memory and hard
+ disk space
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Physical Constraints:</strong> Specify requirements on the shape, size, and weight of the resulting
+ hardware to house the system
+ </p>
+ </li>
+</ul>
+<h3>
+ Interface Requirements (+)
+</h3>
+<p>
+ Describe both the user interface and interfaces with external systems.
+</p>
+<h4>
+ User interface
+</h4>
+<p>
+ Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
+ section is to state the requirements, but not to describe the user interface itself, because interface design may
+ overlap the requirements-gathering process. This is particularly true if you are using prototyping as part of your
+ requirements gathering process. As you develop prototypes, it is important to capture the requirements that relate to
+ the look and feel of the user interface. In other words, be sure that you understand your client’s intentions for the
+ product’s look and feel. Record these as requirements, rather than merely using a prototype for approval.
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Look and feel:</strong> A description of the aesthetic appearance and layout of the interface. Your
+ client may have given you particular demands, such as style, colors, degree of interaction, and so on. This
+ section captures the requirements for the interface, rather than the design for the interface. The motivation
+ is to capture the expectations, the constraints, and the client’s demands for the interface before designing
+ it. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ The product shall have the same layout as the district maps from the engineering department.
+ </li>
+ <li>
+ The product shall use the company color.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Layout and navigation requirements:</strong> Specify requirements on major screen areas and how they should
+ be grouped together.<br />
+ </li>
+ <li>
+ <strong>Consistency:</strong> Consistency in the user interface enables users to predict what will happen. This
+ section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
+ the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
+ and shapes, placements for entering / presenting data, terminology<br />
+ </li>
+ <li>
+ <strong>User personalization and customization requirements:</strong> Requirements on content that should
+ automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
+ content displayed or to personalize displayed content.
+ </li>
+</ul>
+<h4>
+ Interfaces to external systems or devices
+</h4>
+<ul>
+ <li>
+ <p>
+ <strong>Software interfaces:</strong> Are there any external systems with which this system must interface? Are
+ there any constraints on the nature of the interface between this system and any external system, such as the
+ format of data passed between these systems? Do they use any particular protocol? Describe software interfaces
+ with other components. These may be purchased components, components reused from another application, or
+ components being developed for subsystems outside of the scope of the system under consideration, but with
+ which this it must interact. For each system, consider both provided and required interfaces.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Hardware interfaces:</strong> Define any hardware interfaces that are to be supported by the software,
+ including logical structure, physical addresses, expected behavior, and so on.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Communications interfaces:</strong> Describe any communications interfaces to other systems or devices,
+ such as local area networks (LANs), remote serial devices, and so on.
+ </p>
+ </li>
+</ul>
+<h3>
+ Business Rules (+)
+</h3>
+<p>
+ Besides technical requirements, also consider the particular business domain in which the system needs to fit.
+</p>
+<p>
+ Business rules or policies that the system must conform to may constrain system functionality. Business rules are
+ referred to by system use cases and can be in the form of decision tables, computation rules, decision trees,
+ algorithms, and so forth. Describing the rules in the flows of the use cases usually clutters the use-case
+ specifications. Therefore, they are normally captured in separate artifacts or as annexes related to the use-case
+ specifications. In many cases, a business rule applies to more then one use case. Shared business rules should be
+ stored in a single repository, such as a supporting requirements document.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/test_ideas.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/test_ideas.xmi
new file mode 100644
index 0000000..6bf0b28
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/test_ideas.xmi
@@ -0,0 +1,144 @@
+<?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" epf:version="1.0.0" xmi:id="_y3rxsMM3EdmSIPI87WLu3g" name="test_ideas,_0jzlsMlgEdmt3adZL5Dmdw" guid="_y3rxsMM3EdmSIPI87WLu3g" changeDate="2006-09-29T09:37:59.292-0700" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Test ideas are used to generate tests.&nbsp;Test ideas can come from many different sources.&nbsp;In general, they can
+ be derived in different ways depending on the given development domain, the kind of application being developed, and
+ the sophistication of the testers.&nbsp;Although test ideas are derived in many different ways, there are some useful
+ categories for generating them.&nbsp;This guideline will describe some of these categories as well as some general
+ heuristics for creating good test ideas.
+</p>
+<h4>
+ Test Ideas and Functions
+</h4>
+<p>
+ Below are some test ideas to calculate the square root:
+</p>
+<ol>
+ <li>
+ A number that's barely less than zero as input
+ </li>
+ <li>
+ Zero as the input
+ </li>
+ <li>
+ Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
+ </li>
+ <li>
+ Print to a LaserJet IIIp
+ </li>
+ <li>
+ Test with database full
+ </li>
+</ol>
+<p>
+ The first&nbsp;3 test ideas validate input while the last 2 address environmental issues.&nbsp; Even though these
+ statements are very incomplete they ensure that an idea is not forgotten.
+</p>
+<h4>
+ Test Ideas and Boundaries
+</h4>
+<p>
+ Test ideas are often based on fault models.&nbsp; Consider boundaries. It's safe to assume the square root function can
+ be implemented something like this:<br />
+ double sqrt(double x) {<br />
+ &nbsp;&nbsp;&nbsp; if (x &lt; 0)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // signal error<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br />
+ It's also plausible that the &lt; will be incorrectly typed as &lt;=. People often make that kind of mistake, so it's
+ worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x&lt;=0)
+ and the correct expression (x&lt;0) will take the same branch of the if statement. Similarly, giving X the value -5
+ cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea.
+</p>
+<h4>
+ Test Idea and Methods
+</h4>
+<p>
+ Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
+ obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is
+ found.<br />
+ int Collection.find(String string, Boolean ignoreCase);
+</p>
+<p>
+ Here are some test ideas for this method, each of which could be implemented as a test.&nbsp;
+</p>
+<ol>
+ <li>
+ Match found in the first position
+ </li>
+ <li>
+ Match found in the last position
+ </li>
+ <li>
+ No match found
+ </li>
+ <li>
+ Two or more matches found in the collection
+ </li>
+ <li>
+ Case is ignored; match found, but it wouldn't match if case was obeyed
+ </li>
+ <li>
+ Case is obeyed; an exact match is found
+ </li>
+ <li>
+ Case is obeyed; a string that would have matched if case were ignored is skipped
+ </li>
+</ol>
+<p>
+ However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas
+ 2, 6, and 7:
+</p>
+<p>
+ <strong>Setup:</strong> Collection initialized to ["dawn", "Dawn"]<br />
+ <strong>Invocation:</strong> Collection.find("Dawn", false)<br />
+ <strong>Expected result:</strong> Return value is 1 (it would be 0 if "dawn" were not skipped)
+</p>
+<h4>
+ Test Idea Simplicity and Complexity
+</h4>
+<p>
+ Making test ideas nonspecific makes them easier to combine.<br />
+ Creating many several small tests that satisfy a few test ideas makes it simpler to:
+</p>
+<ul>
+ <li>
+ "Copy and Tweak" the tests to meet other test idea
+ </li>
+ <li>
+ Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if
+ the test covers 7 test ideas you will spend more time debugging the issue.&nbsp;
+ </li>
+</ul>
+<p>
+ If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote
+ the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the
+ chance the test will satisfy a test idea that you didn't know you needed.
+</p>
+<h4>
+ Complex Tests
+</h4>
+<p>
+ Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not
+ creating complex tests.
+</p>
+<ul>
+ <li>
+ Complex test are more difficult to debug because they usually cover multiple test ideas
+ </li>
+ <li>
+ Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.
+ </li>
+ <li>
+ Complex tests are more difficult to create.
+ </li>
+</ul>
+<p>
+ Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each
+ satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying
+ four.<br />
+ In practice, find a reasonable balance between complexity and simplicity.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/test_suite.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/test_suite.xmi
new file mode 100644
index 0000000..c0ce03e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/test_suite.xmi
@@ -0,0 +1,163 @@
+<?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" epf:version="1.0.0" xmi:id="_s60KoMM3EdmSIPI87WLu3g" name="test_suite,_0aDz0MlgEdmt3adZL5Dmdw" guid="_s60KoMM3EdmSIPI87WLu3g" changeDate="2006-09-29T12:48:57.425-0400" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The test suite provides a means of managing the complexity of the test implementation. Many system test efforts fail
+ because the team gets lost in the minutia of all of the detailed tests, and subsequently loses control of the test
+ effort. Similar to UML packages, test suites provide a hierarchy of encapsulating containers to help manage the test
+ implementation. They provide a means of managing the strategic aspects of the test effort by collecting tests together
+ in related groups that can be planned, managed, and assessed in a meaningful way.
+</p>
+<p>
+ The test suite represents a container for organizing arbitrary collections of related test scripts. This may be
+ realized (implemented) as one or more automated regression test suites, but the test suite can also be a work plan for
+ the implementation of a group of related manual test scripts. Note also that test suites can be nested hierarchically,
+ therefore one test suite may be enclosed within another.
+</p>
+<p>
+ Sometimes these groups of tests will relate directly to a subsystem or other system design element, but other times
+ they'll relate directly to things such as quality dimensions, core "mission critical" functions, requirements
+ compliance, standards adherence, and many others concerns that are organized based on requirements and therefore cut
+ across the internal system elements.
+</p>
+<p>
+ Consider creating test suites that arrange the available test scripts, in addition to other test suites, in many
+ different combinations: the more variations you have, the more you'll increase coverage and the potential for finding
+ errors. Give thought to a variety of test suites that will cover the breadth and depth of the target test items.
+ Remember the corresponding implication that a single test script (or test suite) may appear in many different test
+ suites.
+</p>
+<p>
+ Some test automation tools provide the ability to automatically generate or assemble test suites. There are also
+ implementation techniques that enable automated test suites to dynamically select all or part of their component test
+ scripts for each test cycle run.
+</p>
+<p>
+ Test suites can help you maintain your test assets and impose a level of organization that facilitates the entire
+ testing effort.&nbsp; Like physical objects, tests can break. It's not that they wear down, it's that something changed
+ in their environment. Perhaps they've been ported to a new operating system. Or, more likely, the code they exercise
+ has changed in a way that correctly causes the test to fail. Suppose you're working on version 2.0 of an e-banking
+ application. In version 1.0, this method was used to log in:
+</p>
+<p class="codeSample">
+ public boolean login (String username);
+</p>
+<p>
+ In version 2.0, the marketing department has realized that password protection might be a good idea. So the method is
+ changed to this:
+</p>
+<p class="codeSample">
+ public boolean login (String username, String password);
+</p>
+<p>
+ Any test that uses the first form of the login will fail. It won't even compile. In this example you could find that,
+ not many useful tests can be written that don't use login. You might be faced with hundreds or thousands of failing
+ tests.
+</p>
+<p>
+ These tests can be fixed by using a global search-and-replace tool that finds every instance of login(something) and
+ replaces it with login(something, "dummy password"). Then arrange for all the testing accounts to use that password,
+ and you're on your way.
+</p>
+<p>
+ Then, when marketing decides that passwords should not be allowed to contain spaces, you get to do it all over again.
+</p>
+<p>
+ This kind of thing is a wasteful burden, especially when, as is often the case, the test changes aren't so easily made.
+ There is a better way.
+</p>
+<p>
+ Suppose that the test scripts originally did not call the product's login method. Rather, they called a library method
+ that does whatever it takes to get the test logged in and ready to proceed. Initially, that method might look like
+ this:
+</p>
+<p class="codeSample">
+ public boolean testLogin (String username) {<br />
+ &nbsp; return product.login(username);<br />
+ }
+</p>
+<p>
+ When the version 2.0 change happens, the utility library is changed to match:
+</p>
+<p class="codeSample">
+ public Boolean testLogin (String username) {<br />
+ &nbsp; return product.login(username, "dummy password");<br />
+ }
+</p>
+<p>
+ Instead of a changing a thousand tests, you change one method.
+</p>
+<p>
+ Ideally, all the needed library methods would be available at the beginning of the testing effort. In practice, they
+ can't all be anticipated-you might not realize you need a testLogin utility method until the first time the product
+ login changes. So test utility methods are often "factored out" of existing tests as needed. It is very important that
+ you perform this ongoing test repair, even under schedule pressure. If you do not, you will waste much time dealing
+ with an ugly and un-maintainable test suite. You might well find yourself throwing it away, or being unable to write
+ the needed numbers of new tests because all your available testing time is spent maintaining old ones.
+</p>
+<p>
+ Note: the tests of the product's login method will still call it directly. If its behavior changes, some or all of
+ those tests will need to be updated. (If none of the login tests fail when its behavior changes, they're probably not
+ very good at detecting defects.)
+</p>
+<h3>
+ Abstraction helps manage complexity
+</h3>
+<p>
+ The previous example showed how tests can abstract away from the concrete application. Most likely you can do
+ considerably more abstraction. You might find that a number of tests begin with a common sequence of method calls: they
+ log in, set up some state, and navigate to the part of the application you're testing. Only then does each test do
+ something different. All this setup could-and should-be contained in a single method with an evocative name such as
+ readyAccountForWireTransfer. By doing that, you're saving considerable time when new tests of a particular type are
+ written, and you're also making the intent of each test much more understandable.
+</p>
+<p>
+ Understandable tests are important. A common problem with old test suites is that no one knows what the tests are doing
+ or why. When they break, the tendency is to fix them in the simplest possible way. That often results in tests that are
+ weaker at finding defects. They no longer test what they were originally intended to test.
+</p>
+<h3>
+ Throwing away tests
+</h3>
+<p>
+ Even with utility libraries, a test might periodically be broken by behavior changes that have nothing to do with what
+ it checks. Fixing the test doesn't stand much of a chance of finding a defect due to the change; it's something you do
+ to preserve the chance of the test finding some other defect someday. But the cost of such a series of fixes might
+ exceed the value of the tests hypothetically finding a defect. It might be better to simply throw the test away and
+ devote the effort to creating new tests with greater value.
+</p>
+<p>
+ Most people resist the notion of throwing away a test, at least until they're so overwhelmed by the maintenance burden
+ that they throw all the tests away. It is better to make the decision carefully and continuously, test by test, asking:
+</p>
+<ul>
+ <li>
+ How much work will it be to fix this test well, perhaps adding to the utility library?
+ </li>
+ <li>
+ How else might the time be used?
+ </li>
+ <li>
+ How likely is it that the test will find serious defects in the future? What's been the track record of it and
+ related tests?
+ </li>
+ <li>
+ How long will it be before the test breaks again?
+ </li>
+</ul>
+<p>
+ The answers to these questions will be rough estimates or even guesses. But asking them will yield better results than
+ simply having a policy of fixing all tests.
+</p>
+<p>
+ Another reason to throw away tests is that they are now redundant. For example, early in development, there might be a
+ multitude of simple tests of basic parse-tree construction methods (the LessOp constructor and the like). Later, during
+ the writing of the parser, there will be a number of parser tests. Since the parser uses the construction methods, the
+ parser tests will also indirectly test them. As code changes break the construction tests, it's reasonable to discard
+ some of them as being redundant. Of course, any new or changed construction behavior will need new tests. They might be
+ implemented directly (if they're hard to test thoroughly through the parser) or indirectly (if tests through the parser
+ are adequate and more maintainable).
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/types_of_developer_tests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/types_of_developer_tests.xmi
new file mode 100644
index 0000000..87d5be9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/types_of_developer_tests.xmi
@@ -0,0 +1,253 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-VGT8iHGtQSiOUGitq1qmow" name=",_eRutgC5QEduVhuZHT5jKZQ" guid="-VGT8iHGtQSiOUGitq1qmow" changeDate="2006-12-28T10:50:35.593-0800" version="1.0.0">
+ <mainDescription><p>
+ This guideline describes a number of types of tests. To perform these types of testing you need to define, and then
+ run, a series of tests against&nbsp;the source code. A developer test is a single test that needs to be performed.
+</p>
+<p>
+ It is valuable&nbsp;to augment automated tests with human readable test scripts in order to implement developer test
+ cases, scripts that include the information discussed below. A test script is the actual steps, sometimes either
+ written procedures to follow or the source code of a test. Developer test scripts are run against testing targets:
+ either one unit of source code, a more complex portion of your system (such as a component), or the entire system
+ itself to test&nbsp;some developer issue such as integration.
+</p>
+<h3>
+ Regression Testing
+</h3>
+<p>
+ Regression testing is the act of ensuring that changes to&nbsp;the code have not adversely affected existing
+ functionality. It is important to recognize that incremental development makes regression testing critical. Whenever
+ you release an application, you must ensure its previous functionality still works, and because you release
+ applications more often when taking the incremental approach, this means regression testing becomes that much more
+ important. Regression testing is the first thing you should be thinking about when testing for the following reasons:
+</p>
+<ol>
+ <li>
+ You want to be able to modify code and know that you can rerun your tests to see if you broke anything.
+ </li>
+ <li>
+ Existing users get very angry when things that previously worked don’t work anymore.
+ </li>
+</ol>
+<p>
+ Regression testing is fairly straightforward conceptually – you just need to run all of&nbsp;the previous test cases
+ against the new version of&nbsp;the code. Regression testing tools help immensely because they are designed with
+ regression testing in mind. However, there are potential challenges to regression testing:
+</p>
+<ul>
+ <li>
+ When you change your production, either to enhance it or to refactor it, you will need to rework existing test
+ cases coupled to that code.
+ </li>
+ <li>
+ If your updates affect only a component of the system, then potentially you only need to run the test cases that
+ affect this single component. Although this approach is a little risky because your changes may have had a greater
+ impact than you suspect, it does help to reduce both the time and cost of regression testing.
+ </li>
+ <li>
+ The more non-code artifacts that you decide to keep, the greater the effort to regression test your work and
+ therefore the greater the risk to your project because you are more likely to skimp on your testing efforts.
+ </li>
+</ul>
+<p>
+ Regression testing is critical to success as an agile developer. Many software developers use the xUnit family of open
+ source tools, such as <a href="http://www.junit.org/" target="_blank">JUnit</a> and <a href="http://www.vbunit.org/"
+ target="_blank">VBUnit</a>, to test their code. The advantage of these tools is that they implement a testing framework
+ with which you can regression test all of your source code. Commercial testing tools are also viable options.
+</p>
+<h3>
+ Traditional Code Testing Techniques
+</h3>
+<p>
+ Although object and procedural technologies are different, several important testing concepts from the procedural world
+ are valid regardless of the underlying technology. These traditional testing techniques are:
+</p>
+<ul>
+ <li>
+ Black-box testing
+ </li>
+ <li>
+ Clear-box testing
+ </li>
+ <li>
+ Boundary-value testing
+ </li>
+ <li>
+ Coverage/Path testing
+ </li>
+</ul>
+<h4>
+ Black-Box Testing
+</h4>
+<p>
+ Black-box testing, also called interface testing, is a technique in which you create test cases based only on the
+ expected functionality of a method, class, or application without any knowledge of its internal workings. One way to
+ define black-box testing is that given input A you should obtain expected results B.
+</p>
+<p>
+ The goal of black-box testing is to ensure the system can do what it should be able to do, but not how it does it. For
+ example, if you invoke differenceInDays(June 30 2006, July 3 2006) the expected result should be three. The creation of
+ black-box tests is often driven by the requirements for&nbsp;the system. The basic idea is&nbsp;to look at the user
+ requirement and ask what needs to be done to show that the user requirement is met.
+</p>
+<p>
+ The primary advantage of black-box testing is that it enables you to prove that your application fulfills the
+ requirements defined for it.&nbsp;&nbsp; The primary disadvantage is that it does not show that the internals
+ of&nbsp;the system work (hence the need for clear-box testing).
+</p>
+<h4>
+ Clear-Box Testing
+</h4>
+<p>
+ Clear-box testing, also called white-box testing, is based on the idea that&nbsp;the program code can drive the
+ development of test cases. The basic concept is you look at&nbsp;the code, and then create test cases that exercise it.
+ For example, assume you have access to the source code for differenceInDays(). When you look at it, you see an IF
+ statement determines whether the two dates are in the same year. If&nbsp;they are in the same year then&nbsp;a simple
+ strategy based on Julian dates is used; if not then a more complex&nbsp;strategy is used. This indicates that you need
+ at least one test that uses dates from the same year and one from different years. By looking at the code, you are able
+ to determine new test cases to exercise the different logic paths within it.
+</p>
+<p>
+ The primary advantage of this concept is that it motivates you to create tests that exercise specific lines of
+ code.&nbsp; The disadvantages are that it does not ensure that your code fulfils the actual requirements (hence the
+ need for black-box testing) and that your testing code becomes highly coupled to your application code.
+</p>
+<h4>
+ Boundary-Value Testing
+</h4>
+<p>
+ This is based on the knowledge that you need to test your code to ensure it can handle unusual and extreme situations.
+ For example, boundary-value test cases differenceInDays() would include passing it the same date, two wildly different
+ dates, one date on the last day of the year and the second on the first day of the following year, and one date on
+ February 29th of a leap year. The basic idea is you want to look for limits defined either by your business rules or by
+ common sense, and then create test cases to test attribute values in and around those values.
+</p>
+<p>
+ The primary advantage of boundary value testing is that it motivates you to confirm that your program code is able to
+ handle “unusual” or “extreme” cases.
+</p>
+<h4>
+ Coverage and Path Testing
+</h4>
+<p>
+ Two critical “traditional” concepts are coverage and path testing. Coverage testing is a technique in which you create
+ a series of test cases designed to test all the code paths in your code. In many ways, coverage testing is simply a
+ collection of clear-box test cases that together exercise every line of code in your application at least once. Path
+ testing is a superset of coverage testing that ensures not only have all lines of code been tested, but all paths of
+ logic have also been tested. The main difference occurs when you have a method with more than one set of case
+ statements or nested IF statements: to determine the number of test cases with coverage testing you would count the
+ maximum number of paths between the sets of case/nested IF statements and, with path testing, you would multiply the
+ number of logic paths.
+</p>
+<h4>
+ Unit and Integration Testing
+</h4>
+<p>
+ Unit testing is the testing of an item, such as an operation, in isolation. For example, the tests defined so far for
+ differenceInDays() are all unit tests. Integration testing, on the other hand, is the testing of a collection of items
+ to validate that they work together. In the case of the data library/class, do the various functions work together?
+ Perhaps the differenceInDays() function has a side effect that causes the dayOfWeek() function to fail if
+ differenceInDays() is called first. Integration testing looks for problems like this.
+</p>
+<h3>
+ Object-Oriented Testing Techniques
+</h3>
+<p>
+ When testing systems built using object technology it is important to understand that your source code is composed of
+ several constructs, including methods (operations), classes, and inheritance. Therefore you need testing techniques
+ that reflect the fact that you have these constructs. These techniques are:
+</p>
+<ul>
+ <li>
+ Method testing
+ </li>
+ <li>
+ Class testing
+ </li>
+ <li>
+ Class-integration testing
+ </li>
+ <li>
+ Inheritance-regression testing
+ </li>
+</ul>
+<h4>
+ Method Testing
+</h4>
+<p>
+ Method testing is the act of ensuring that your methods (operations) perform as defined. In procedural testing this
+ would have been called function/procedure testing. Issues to address via method testing include:
+</p>
+<ul>
+ <li>
+ Ensure that your getter/setter methods work as intended
+ </li>
+ <li>
+ Ensure that each method returns the proper values, including error messages and exceptions
+ </li>
+ <li>
+ Validate the parameters being passed to a method
+ </li>
+ <li>
+ Ensure that a method does what it should
+ </li>
+</ul>
+<p>
+ The advantage of method testing is that it ensures that methods work well in isolation but it does not help to find
+ unintended side effects.
+</p>
+<h4>
+ Class Testing
+</h4>
+<p>
+ The main purpose of class testing is to test classes in isolation, and it is effectively the combination of traditional
+ unit testing and integration testing. It is unit testing because you are testing the class and its instances as single
+ units in isolation, but it is also integration testing because you need to verify the methods and attributes of the
+ class work together. The one assumption you need to make while writing “class tests” is that all other classes in the
+ system work. Issues to address via class testing include:
+</p>
+<ul>
+ <li>
+ Validate that the attributes of an object are initialized properly
+ </li>
+ <li>
+ Validate the invariants of the class
+ </li>
+</ul>
+<p>
+ The primary advantages of class testing are that it validates that the operations and properties of a class work
+ together and that the class works in isolation. However, it does not guarantee that a class works well with the rest of
+ your system.
+</p>
+<h4>
+ Class-integration Testing
+</h4>
+<p>
+ Also known as component testing, this technique addresses the issue of whether the classes in your system, or a
+ component of your system, work together properly. The relationships between classes can be used to drive the
+ development of class integration test cases. Issues to address via class-integration testing include:
+</p>
+<ul>
+ <li>
+ Validate that objects do what other objects expect of them
+ </li>
+ <li>
+ Validate that return values are acted appropriately
+ </li>
+ <li>
+ Validate that exceptions/errors are processed appropriately
+ </li>
+</ul>
+<p>
+ The technique helps to validate that the various classes within a component, or a system, work together. However, it
+ can be difficult to define and develop the test cases to fully perform this level of testing.
+</p>
+<h4>
+ Inheritance-regression&nbsp;Testing
+</h4>
+This is the act of running of test cases defined for the superclasses on the instances of a subclass because errors have
+not been introduced by that new subclass. New methods are added and existing methods may be redefined by subclasses,
+methods which access and potentially change the value of the attributes defined in the superclass. It is possible that a
+subclass may change the value of the attributes in a way that was never intended in the superclass, or at least was never
+expected. The point is that you need to invoke the test suite of the superclass(es) when testing a subclass. <br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/uc_model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/uc_model.xmi
new file mode 100644
index 0000000..ecbc4c7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/uc_model.xmi
@@ -0,0 +1,291 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_AGvpcMM3EdmSIPI87WLu3g" name="uc_model,_0VAUsMlgEdmt3adZL5Dmdw" guid="_AGvpcMM3EdmSIPI87WLu3g" changeDate="2007-02-28T11:40:11.200-0800" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The key to successful iterative development is ensuring that the development team maximizes stakeholder value and
+ minimizes risk early in the lifecycle, while minimizing re-work later.&nbsp; This imposes some constraints on how we
+ develop the use-case model.
+</p>
+<p>
+ At one extreme is the classical waterfall approach, which attempts to&nbsp;detail all of the requirements prior to
+ design and implementation.&nbsp; This approach delays delivery of stakeholder value and risk reduction unnecessarily.
+</p>
+<p>
+ At the other extreme is&nbsp;beginning development prior to understanding what the system must do.&nbsp; This approach
+ results in significant, and costly, re-work later in the lifecycle.
+</p>
+<p>
+ A better approach is to detail only those requirements which will be the focus of development in the next iteration (or
+ two).&nbsp; Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract
+ understanding of the "big-picture".
+</p>
+<p>
+ The following discussion will outline the approach used to evolve the use-case model to achieve these goals.
+</p>
+<h3>
+ <a id="How the Use-Case Model Evolves" name="How the Use-Case Model Evolves">How the Use-Case Model Evolves</a>
+</h3>
+<p>
+ The recommended approach to evolving the use-case model takes a "breadth before depth" approach.&nbsp; In this
+ approach, one identifies the actors and use cases and outlines them quickly.&nbsp; Based on this knowledge, one can
+ then perform an initial assessment of risk and priorities and thus focus the effort of&nbsp;detailing&nbsp;the use
+ cases on the right areas.
+</p>
+<h4>
+ Inception
+</h4>
+<p>
+ The purpose of inception is to understand the scope of the system.&nbsp; We need to understand the main purpose of the
+ system, what is within the scope of the system, and what is external to the system.&nbsp; We should strive to list all
+ the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at
+ this time.&nbsp; Strive to&nbsp;identify by name&nbsp;~80% of the primary actors and use cases and provide a brief
+ description (one - three sentences) for each.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Identify Stakeholders
+ </h5>
+ <p>
+ Begin by listing all the external stakeholders for the system.&nbsp; These individuals will be the source of the
+ requirements.
+ </p>
+ <h5>
+ Identify Actors
+ </h5>
+ <p>
+ Name and describe the primary actors.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>.
+ </p>
+ <h5>
+ Identify Use Cases
+ </h5>
+ <p>
+ For each actor, ask "what does this actor want to accomplish with the system"?&nbsp; This will reveal the primary
+ use cases for the system.&nbsp; Name and describe each of these as you discover them.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the use case model to capture the actor and use case names and brief description.&nbsp; Capture the
+ relationship between the actors and use cases.
+ </p>
+ <h5>
+ Outline the Basic Flows
+ </h5>
+ <p>
+ For those use cases that are considered high priority by the stakeholders, or high risk by the development team,
+ capture a step-by-step description of the Basic Flow.&nbsp; Don't worry about structuring the flow at this
+ point.&nbsp; Focus on capturing the dialogue between the actor and the system and the key requirements for the
+ system.
+ </p>
+ <h5>
+ Identify Alternate Flows
+ </h5>
+ <p>
+ As you work through the Basic Flows, ask: "What can go wrong?"; "What options are available at this point?";
+ etc.&nbsp; These types of questions will reveal alternate flows.&nbsp; Capture these, giving each a name and brief
+ description.&nbsp; Fight the urge to detail these alternate flows at this time.
+ </p>
+ <h5>
+ Refactor the Use Case Model
+ </h5>
+ <p>
+ Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into
+ &lt;&lt;include&gt;&gt; use cases.&nbsp; Refactor the Use Case model accordingly.
+ </p>
+ <h5>
+ Prioritize Use Cases
+ </h5>
+ <p>
+ Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use
+ cases.&nbsp; This will be the primary input to iteration planning.
+ </p>
+</blockquote>
+<h4>
+ Elaboration
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of elaboration is to demonstrate the feasibilty of&nbsp;the solution prior to committing additional
+ resources.&nbsp; To be successful, one should demonstrate that stakeholder value can be delivered and that the risk
+ of continuing is acceptable.&nbsp; We should strive to detail and implement ~20% of the scenarios.&nbsp; These
+ scenarios should be selected to achieve good coverage of the architecture (for example, a vertical slice through
+ the architecture, touching as many&nbsp;components and interfaces as possible, is preferred to elaborating the GUI
+ only).
+ </p>
+ <h5>
+ Detail Basic Flow
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flow
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.&nbsp; Depending upon the
+ complexity of the system, you may want to introduce packages to group the use cases in a logical manner to simplify
+ communications, iteration planning, and parallel development.
+ </p>
+</blockquote>
+<h4>
+ Construction
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of construction is to incrementally deliver functionality (and value).&nbsp; Working from the iteration
+ plan, continue detailing the remaining requirements.&nbsp; Shoot for completion of ~90 - ~95% of use cases by the
+ end of construction.
+ </p>
+ <h5>
+ Detail Basic Flows
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flows
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.
+ </p>
+</blockquote>
+<h4>
+ Transition
+</h4>
+<p>
+ The purpose of transition is to make the system operational in its intended environment.&nbsp; Some requirements will
+ still be uncovered at this point, but if we have done things right they should not stress the design.&nbsp; The
+ remaining ~5% to ~10% of use cases should be detailed and implemented in this phase.
+</p>
+<h3>
+ <a id="Avoiding Functional Decomposition" name="Avoiding Functional Decomposition">Avoiding Functional
+ Decomposition</a>
+</h3>
+<p>
+ A common pitfall for those new to use-case models is to perform a&nbsp;functional decomposition of the system. This
+ results in many small "use cases", that on their own do not deliver the "observable result of value" to the
+ actor.&nbsp; To avoid this, watch for the following symptoms:
+</p>
+<ul>
+ <li>
+ <strong>Small</strong> use cases, meaning that the description of the flow of events is only one or a few
+ sentences.
+ </li>
+ <li>
+ <strong>Many</strong> use cases, meaning that the number of use cases is some multiple of a hundred, rather than a
+ multiple of ten.
+ </li>
+ <li>
+ Use-case names that are constructions such as "do this operation on this particular data" or "do this function with
+ this particular data". For example, "Enter Personal Identification Number in an ATM machine" should not be modeled
+ as a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a
+ complete flow of events that results in something of value to an actor.
+ </li>
+</ul>
+<p>
+ To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:
+</p>
+<ul>
+ <li>
+ What is the context of the system?
+ </li>
+ <li>
+ Why are you building this system?
+ </li>
+ <li>
+ What does the user want the system to do?
+ </li>
+ <li>
+ How&nbsp;do the users benefit from the system?
+ </li>
+</ul>
+<h3>
+ <a id="Structuring the Use-Case Model" name="Structuring the Use-Case Model">Structuring the Use-Case Model</a>
+</h3>
+<p>
+ There are three main reasons for structuring the use-case model:
+</p>
+<ul>
+ <li>
+ To make the use cases easier to understand.
+ </li>
+ <li>
+ To partition common behavior described within many use cases.
+ </li>
+ <li>
+ To make the use-case model easier to maintain.
+ </li>
+</ul>
+<p>
+ Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit
+ more about their behavior than a one-sentence description. You should at least have established a step-by-step outline
+ for the flow of events of the use case to make sure that your decisions are based on an accurate understanding of the
+ behavior.
+</p>
+<p>
+ There are several advanced modeling concepts available in the literature for&nbsp;structuring the use-case model,
+ however, following the principle of "keep-it-simple" only the most useful of these, namely the &lt;&lt;include&gt;&gt;
+ relationship is discussed in this process.&nbsp; This relationship permits one to factor out common behavior into a
+ separate use case that is "include" in other use cases.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>&nbsp;for more&nbsp;details.
+</p>
+<p>
+ Another aspect of&nbsp;structuring the use-case model for easier understanding is grouping the use cases into packages.
+ The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see
+ <a class="elementLinkWithType"
+ href="./../../../openup_basic/guidances/concepts/use_case_model,_2jyfUAhVEduRe8TeoBmuGg.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>.
+</p>
+<h3>
+ <a id="Use Cases Are Always Related to Actors" name="Use Cases Are Always Related to Actors">Relationship Between Use
+ Cases and Actors</a>
+</h3>
+<p>
+ Running each use case includes communication with one or more actors. A use-case instance is always started by an actor
+ asking the system to do something. This implies that every use case should have communicates-associations with actors.
+ The reason for this rule is to enforce that the system provides only the functionality that users need and nothing
+ else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the
+ requirements.
+</p>
+<p>
+ However, there are some exceptions to this rule:
+</p>
+<ul>
+ <li>
+ An&nbsp;"included" use case might not interact with an actor if the base use case does.
+ </li>
+ <li>
+ A use case may be initiated according to a schedule (for example, once a week or once a day), which means that the
+ system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated
+ by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have
+ any associations to actors. However, for clarity, you can use "time" as an actor to show how the use case is
+ initiated in your use-case diagrams. <strong>CAUTION:</strong> if you have a lot of "time" actors in your model,
+ challenge them.&nbsp; Perhaps you missed a real actor, such as an administrator responsible for scheduling reports,
+ etc.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/uc_realizations.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/uc_realizations.xmi
new file mode 100644
index 0000000..978f2d7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/uc_realizations.xmi
@@ -0,0 +1,86 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-CFYVionNDLkMw6SG6runQA" name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" changeDate="2006-09-26T15:24:33.595-0700" version="1.0.0">
+ <mainDescription><p>
+ A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
+ can take various forms. It may include, for example, a textual description (a document), class diagrams of
+ participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
+ the flow of interactions between class and subsystem instances.
+</p>
+<p>
+ The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
+ managed separately from their realizations. This is particularly important for larger projects, or families of systems
+ where the same use cases may be designed differently in different products within the product family. Consider the case
+ of a family of telephone switches which have many use cases in common, but which design and implement them differently
+ according to product positioning, performance and price.
+</p>
+<p>
+ For larger projects, separating the use case and its realization allows changes to the design of the use case without
+ affecting the baselined use case itself.
+</p>
+<p>
+ In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
+ (such as textual descriptions) that form part of the use-case realization.
+</p>
+<p>
+ UML diagrams that&nbsp;support use-case realizations can be produced in an analysis context, a&nbsp;design context, or
+ both, depending on the needs of the project. For each use case in the use-case model, there&nbsp;can be&nbsp;a use-case
+ realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
+ dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
+ inheritance, as well as a dependency.<br />
+</p>
+<p align="center">
+ <img height="109" alt="Use Case Realisations" src="./resources/ucrea1.gif" width="277" />
+</p>
+<p>
+ A use-case realization in the&nbsp;design can be traced to a use case in the use-case model.
+</p>
+<h4>
+ Class Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there may be one or more class diagrams depicting its participating classes. A class and
+ its objects often participate in several use-case realizations. It is important&nbsp;while designing to coordinate all
+ the requirements on a class and its objects that different use-case realizations may have. The figure below shows an
+ analysis&nbsp;class diagram for the realization of the Receive Deposit Item use case. Note the use of
+ boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Concept: Entity-Control-Boundary Pattern</a>).
+</p>
+<p align="center">
+ <img height="213" alt="Class diagram for the realization of Receive Deposit Item" src="./resources/md_ucre3.gif" width="328" />
+</p>
+<p align="center">
+ <strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
+</p>
+<h4>
+ Communication and Sequence Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there&nbsp;can be&nbsp;one or more interaction diagrams depicting its participating
+ objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
+ diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
+ of messages and are better when it is important to visualize the time ordering of messages, whereas communication
+ diagrams show the communication links between objects and are better for understanding all of the effects on a given
+ object and for algorithm design.
+</p>
+<p>
+ Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
+ responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
+ contain the following:
+</p>
+<ul>
+ <li>
+ Only the functionality actually used in support of a use case scenario.
+ </li>
+ <li>
+ Functionality that can be tested through an associated test case.
+ </li>
+ <li>
+ Functionality that is more easily traceable to requirements and changes.
+ </li>
+ <li>
+ Explicitly declared class dependencies that are easier to manage.
+ </li>
+</ul>
+<p>
+ These factors help improve the overall quality of the system.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/use_case_formats.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/use_case_formats.xmi
new file mode 100644
index 0000000..a4933b8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/use_case_formats.xmi
@@ -0,0 +1,330 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" name="new_guideline,_qq0GMAXkEduj_7BEUj1JfQ" guid="-pQrBSyxJHLLodLbS4R_Zdw" changeDate="2006-08-16T07:20:15.017-0700">
+ <mainDescription><h3> Use Case Formats </h3>
+<p> Use cases differ from project to project and person to person. A use case
+ that works in one situation may be totally unsuited for another. Different projects
+ have different needs. (See <a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[ADO04]</a>
+ for more information on use case formats.) </p>
+<p>Some need rigorous documentation, including <strong>high-ceremony use cases</strong>,
+ which are formal, highly structured use cases. If the writers used a template,
+ then they filled out all or almost all of its fields for each use case. High-ceremony
+ use cases are best suited for large, extremely complex, safety-critical systems,
+ such as flight control systems, telephone switches, and so forth. They are also
+ used in development cultures that have high documentation standards. </p>
+<p>Other projects may be more agile and less formal, benefiting from <strong>low-ceremony
+ use cases</strong>, which are informal, less rigidly structured use cases. If
+ the writers used a template, then they may have left many of the fields blank.
+ Low-ceremony use cases are best suited for smaller, less complex, less safety-critical
+ systems where most of the stakeholders have a strong background in the problem
+ domain. Sometimes, simple descriptions suffice, such as use case <strong>briefs</strong>.
+</p>
+<p> As <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline:
+ Detail Use Cases and Scenarios</a> explains, it makes sense to write use cases
+ iteratively. Starting with the basic details, you can then identify the various
+ alternative and error paths that the use case might follow so that you can evaluate,
+ rearrange, or eliminate them, and then elaborate or fill in the details of the
+ courses that you intended to use. You can then write the
+ use cases in<strong> </strong> one or more of
+ the following formats, progressively, until you
+ reach the one with the level of detail required for a specific project: </p>
+<ul>
+ <li><a id="Actor-Goal-List" name="Actor-Goal_List"><strong>Actor-Goal list</strong></a>:
+ A format for the overview</li>
+ <li> <a id="Briefs" name="Briefs"><strong>Briefs: </strong></a>A format for
+ writing summary use cases</li>
+ <li> <a id="Improvisational Score" name="Improvisational Score"><strong>Improvisational
+ score: </strong></a>A format for writing less formal, low-ceremony use cases</li>
+ <li> <a id="Symphonic Score" name="Symphonic Score"><strong>Symphonic score:
+ </strong></a>A format for writing more formal, high-ceremony use cases</li>
+</ul>
+<h4>Actor-Goal list </h4>
+<p> <strong>Context: </strong>You have identified your actors and are trying to
+ identify use cases. </p>
+<p> <strong>Problem:</strong> Developing a set of use cases in an ad hoc manner
+ can lead to unnecessary work, missing features, and feature creep. Weight
+ is one of the most important factors in space flight &#8212; so important that
+ the United States space agency, NASA, will not
+ allow anything on a spacecraft that isn’t absolutely critical to the flight.
+ If something literally isn’t worth its weight, then it doesn’t go. Likewise,
+ each use case adds cost to a system; therefore, you need to be sure to include
+ only those use cases that add some kind of value to your collection. </p>
+<p> <strong>Forces:<em> </em></strong></p>
+<ul>
+ <li>
+ <p><strong>Simply listing actors or listing goals is not informative enough,
+ but actors and goals together are informative.</strong> The classical approach
+ to writing use cases is to define a list of actors, then find use cases
+ for each. A variation on this theme is to itemize what the system must accomplish.
+ Yet, neither approach is adequate by itself. You need to know both who is
+ using the system and why they are using it. Otherwise, you introduce the
+ potential of either feature creep or missed features. At the least, a set
+ of use cases should describe this association. </p>
+ </li>
+ <li>
+ <p><strong> A quick overview of the entire project structure is sufficient
+ and necessary early in the use case development cycle.</strong> Ideally,
+ this overview should be as short as reasonably possible. It must contain
+ key information as to who requires each service and why they need it. Most
+ other information is not very useful at this stage of the project, because
+ it runs the risk of quickly becoming obsolete, as well as discouraging
+ out-of-the-box (innovative) thinking. An overview
+ helps the writers work through the entire set from a high-level view, expanding
+ some use cases, eliminating others, and combining still others into a more
+ logical grouping. </p>
+ </li>
+ <li>
+ <p><strong>You need to be able to expand each to a full use case on demand.
+ </strong>A <em>seedling</em><strong> </strong>use case forms the basis for
+ a full use case later in the iterative development cycle. Each seedling
+ use case needs to convey enough information so that someone, possibly other
+ than the outline writer, can easily go back and expand it into a more informative
+ use case. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Build an Actor-Goal list,
+ which is a list of actors and their goals that
+ gives you an overview of entire project needs.<strong></strong></p>
+<ul>
+ <li>
+ <p>Start by identifying the list of actors who will use the system, and then
+ identify at least one goal for each. Actors without goals indicate that
+ you haven’t adequately defined the system. The actor is beyond the system’s
+ scope, doesn’t belong in the system, or is part of another actor. </p>
+ </li>
+ <li>
+ <p>Likewise, leftover goals can indicate that the system is too complex and
+ you're trying to accomplish too much, or that you haven’t adequately defined
+ all of the necessary actors. Carefully evaluate the leftovers to see if
+ you are just overlooking some detail, or whether they don’t belong in the
+ system. </p>
+ </li>
+ <li>
+ <p>Remove unassociated actors and goals from the list. </p>
+ </li>
+</ul>
+<p> Sometimes, this list may provide enough information to serve as use cases
+ for very small, high-communicating, low-ceremony project teams. Usually, the
+ actor goal list is the first step of identifying use cases. </p>
+<h4>
+ Briefs
+</h4>
+<p> <strong>Context: </strong>You have written an Actor-Goal list that outlines
+ your use cases. </p>
+<p> <strong>Problem: </strong>Relying solely on an overview to capture the important
+ parts of a system’s behavior is dangerous, because it provides only high-level
+ information and can easily introduce ambiguity into a system. </p>
+<p> <strong>Forces: </strong></p>
+<ul>
+ <li>
+ <p><strong>Although valuable, an Actor-Goal list does not clearly describe
+ a system.</strong> Usually, an outline doesn’t provide enough precision
+ to avoid ambiguity, which can wreak havoc on a project by leading to unnecessary
+ or erroneous development. Yet, an outline is helpful, because you still
+ want an overview that you can easily scan. Unfortunately, with the passing
+ of time or sheer volume of work, it’s too easy to forget details
+ that were obvious to you earlier.</p>
+ </li>
+ <li>
+ <p><strong>Iterative use case development requires creating placeholders for
+ expansion.</strong> To develop use cases iteratively, you start with sparse
+ use cases, reorganize them, and flesh them out as the system takes shape.
+ Ideally, these placeholders should be clear enough to: 1) unambiguously
+ describe their role in the system, and 2) allow someone to expand the use
+ case, even if they were not involved in writing them originally. </p>
+ </li>
+ <li>
+ <p><strong>Because outlines are general by nature, do not spend a lot of time,
+ energy, or money writing them. </strong>Outlines provide an inexpensive
+ method of documenting complex ideas in a manner that is easy to follow,
+ and they provide a mechanism for people outside of a project to understand
+ the high-level concepts. While it may take
+ some effort to think things through, you don’t want to waste resources describing
+ your ideas. The system is still in a state of flux at this point, and it
+ is too early to spend much time documenting its shifting details. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Write two to four sentences per use case, capturing
+ key activities and key-extension handling. </p>
+<ul>
+ <li>
+ <p> Expand the Actor-Goal list into<strong> briefs</strong> by writing a two-
+ to four-sentence use cases for each entry in the list. </p>
+ </li>
+ <li>
+ <p>Briefly describe each use case’s main&nbsp;scenario and most important
+ extensions. </p>
+ </li>
+ <li>
+ <p> Include enough information to eliminate ambiguity for at least the main&nbsp;scenario
+ of the system. </p>
+ </li>
+</ul>
+<h4> Improvisational score</h4>
+<p> <strong>Context: </strong>You are operating in well-known domains or in situations
+ where writing high-ceremony use cases would require all of your allotted development
+ time. </p>
+<p> <strong>Problem:</strong> Writing formal, high-ceremony use cases when lesser
+ detail would suffice wastes time and resources. </p>
+<p> Jazz is considered to be “musician’s music,” and jazz players are usually
+ highly skilled. Many jazz musicians prefer to improvise in small, highly skilled
+ teams, such as jazz quartets. To improvise effectively, the musicians must have
+ a thorough understanding of the conventions that form the given musical style,
+ including chord sequences, rhythmic patterns, and melodies. These conventions
+ provide a basic framework for the musicians to interact as a team, while still
+ allowing room for spontaneous creativity. </p>
+<p> Likewise, use cases do not always need to be specified in excruciating detail.
+ A far-preferable strategy is simply to define the basic structure of what the
+ developers need to implement. The use cases act as placeholders that may be
+ elaborated later or simply improvised by the developer who implements the use
+ case. </p>
+<p> <strong>Forces:</strong></p>
+<ul>
+ <li>
+ <p><strong>Briefs do not provide enough information. </strong>While useful,
+ use-case briefs describe only the more significant parts of behavior. Often,
+ developers need more information, especially when working in unfamiliar
+ domains or in the heart of the system, where the actor has many choices
+ to make and many paths to follow. Briefs do not describe all of the important
+ events that can happen, nor do they describe the details that go into making
+ choices along the way. </p>
+ </li>
+ <li>
+ <p><strong>Fully elaborated use cases can be too expensive, time consuming,
+ long to write, and boring to read. </strong>It
+ takes a lot of time and effort to write a formal, fully descriptive set
+ of use cases. Maintaining this set takes even longer. Often, a collection
+ of use cases reaches the point of diminishing returns long before it is
+ completely written, much less formalized. Readers often prefer shorter,
+ simpler use cases over long, complicated ones, because overly detailed use
+ cases can be overwhelming and, frankly speaking, quite boring. </p>
+ </li>
+ <li>
+ <p><strong>Many groups communicate well enough to
+ resolve ambiguities on the fly. </strong>While briefs may be insufficient,
+ stakeholders don’t always need everything to be spelled out for them. Developers
+ are usually capable of asking questions and filling out the necessary detail
+ from their own domain knowledge. Many people can work with a fair level
+ of ambiguity, and most organizations possess what is often referred to as
+ their “core competencies.” Mature organizations with strong domain knowledge
+ can survive, and even thrive, using more informal, less precise use cases.
+ </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Specify the use cases at
+ a low level of precision, allowing the developers to fill in the missing details
+ as necessary. The level of precision required depends on the background experiences
+ of the development team. Skip the less meaningful fields on the template, and
+ write the Main Scenario section as a simple paragraph.
+ Describe key-extension handling in the next paragraph
+ or two. Be prepared to resolve ambiguities and expand detail on the fly throughout
+ the project. </p>
+<p> When you can rely upon open and frequent communication among the developers
+ and customer, write the use case with less detail and precision. The developers
+ can fill in the gaps by asking users or by using knowledge of the domain. However,
+ the developers need a thorough understanding of the business context to be able
+ to fill out the details themselves. Even the most knowledgeable developer will
+ still need access to the customers and users to get answers to questions and
+ clarify requirements. </p>
+<p> Ideally, the project will be structured to enable effective communication
+ between the customer and the developers. Typically, this will involve having
+ a small, co-located team, with the developers having easy access to the users
+ throughout the project. The risk of misunderstanding can be resolved by frequent
+ incremental delivery if the development organization
+ has a relatively low-ceremony culture. </p>
+<p> Jazz improvisation does not always work. It can become tedious and unpleasant
+ to listen to, even for the committed connoisseur.
+ For this reason, you also need feedback from the audience to determine the success
+ of the improvisations. Multi-level or two-tier reviews are critical to success
+ (see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline:
+ Effective Requirement Reviews</a>). </p>
+<p> Improvisation may not always be suitable for the organizational culture, a
+ full <strong>symphonic score</strong> may be preferable in large, high-ceremony
+ teams (see section that follows). For instance,
+ I once watched a conductor toss his baton away in disgust when a pianist improvised
+ to such an extent that the orchestra could not follow the score. If the organization
+ deems the risk of improvising to be unacceptably high, then you can specify
+ the use cases with a higher level of detail and precision. You could start with
+ a strategy of specifying low levels of detail and precision, and then adapt
+ as necessary. </p>
+<h4> Symphonic score </h4>
+<p> <strong>Context: </strong>Writing structure for high-ceremony situations,
+ such as when there are many developers or when development teams are geographically
+ dispersed. </p>
+<p> <strong>Problem: </strong>Writing low-ceremony use cases for high-ceremony
+ situations raises the risk of miscommunication to unacceptable levels. </p>
+<p> A conductor’s version of a symphonic score contains the music for the entire
+ orchestra, as well as any accompanying vocals. The parts to be performed by
+ different voices or instruments are written on a separate staff, with all of
+ the staves aligned, one above another. This score specifies each note and its
+ associated timing in precise detail, so that the orchestra can perform a symphony
+ as the composer intended. </p>
+<p> As with use cases, a score tells the musician what to play, not how to play
+ it. For most symphonies, the orchestra will not be able to meet the composer,
+ so instead, they must rely upon the director to interpret the
+ score and the composer's intentions. </p>
+<p> <strong>Forces: </strong></p>
+<ul>
+ <li>
+ <p><strong>Certain development situations and cultures require high degrees
+ of formality. </strong>Some organizations operate in a highly formal manner,
+ thus require a highly formal process. While this formality may not
+ be desirable, it is the company's way of doing business, so things need
+ to be done that way. Other organizations are highly formal because they
+ do highly complex, life-critical work, where even small failures could have
+ disastrous consequences. For instance, no one would feel comfortable flying
+ on an airliner with an off-the-shelf, one-size-fits-all flight management
+ system. </p>
+ </li>
+ <li>
+ <p><strong>The cost of repairing miscommunication
+ is high. </strong>It is easy to write vague, inadequate use cases full of
+ ambiguity. Use cases can be too brief and ambiguous, or contain domain-specific
+ details that may be beyond the understanding of many stakeholders. Either
+ way, they provide an opportunity for a misunderstanding that leads to an
+ incorrect implementation. The cost of correcting these mistakes depends
+ on when they are discovered. <em>Earlier</em> is cheaper than<em> later</em>,
+ especially when later means customers finding the problem in the delivered
+ product. To avoid miscommunication, aim to write use cases that are general
+ enough for all of the stakeholders to follow, yet precise enough for the
+ developers to use when building the system. </p>
+ </li>
+ <li>
+ <p><strong>Developers need detail for implementing steps, business rules,
+ data fields, and, especially, for handling extensions. </strong>No one has
+ developed a program that can take a set of use cases as input, and churn
+ out a completed system. Even the best-case tools seem to require human intervention
+ to flesh out details and resolve ambiguities. Similarly, developers who
+ do not understand the business context or lack domain expertise may not
+ be able to fully comprehend a product. In an ideal project, software developers
+ would have access to the domain experts to ask questions, so they could
+ fill in any areas that may have been missed (see<em> Improvisational score</em>,
+ previously). But often, they do not ask. Therefore, they misunderstand the
+ more complex or ambiguous use cases in the set. To develop a system correctly,
+ a team needs either access to domain experts or additional information that
+ describe the steps, business rules, data fields, and extension handling
+ that they are implementing. </p>
+ </li>
+</ul>
+<p> <strong>Solution: </strong>Specify your use cases with a high level of precision,
+ explicitly filling in all of the details in the use case template, while staying
+ technology-neutral. The level of precision required depends on the background
+ experiences of the development team. </p>
+<p> Intuition may tell you that if some detail is good, then more must be better.
+ However, be careful about falling into the trap of over-specifying details.
+ It’s naive to believe that everyone who reads your use cases will be able to
+ understand them. Different people may interpret the use cases differently. Prepare
+ for this eventuality in your process, and avoid the tendency to over-specify
+ your use cases. If you try to specify a use case in too much detail, you may
+ fall into the classic analysis paralysis trap. </p>
+<p> People are often tempted to address the communication problem by trying to
+ explain the business domain within the use cases. In a similar manner, they
+ include too much technical detail. Succumbing to these temptations by explaining
+ the business domain or including technical details is always a mistake, because
+ it complicates the process and obfuscates the requirements. The reader of the
+ use cases cannot distinguish the real requirements from the boring background
+ information, so will soon get distracted and lose interest. Instead, include
+ this information in an extra section. </p>
+<p> If you are handing over the requirements to a development team whose members
+ are unfamiliar with the domain, then you will need an alternative strategy for
+ teaching them the domain knowledge. </p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/using_patterns.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/using_patterns.xmi
new file mode 100644
index 0000000..986aaff
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/using_patterns.xmi
@@ -0,0 +1,37 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-U-5cLUk-mdaO518lh5CxTQ" name="using_patterns,_0cr7cACrEdu8m4dIntu6jA" guid="-U-5cLUk-mdaO518lh5CxTQ" changeDate="2006-09-21T15:38:16.868-0700" version="1.0.0">
+ <mainDescription><p>
+ In software design, it is primarily the development method and not the pattern and its pattern language that influences
+ the process of pattern selection and use. As discussed in <a class="elementLinkWithType" href="./../../../openup_basic/guidances/concepts/patterns,_0YJvUMlgEdmt3adZL5Dmdw.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Patterns</a>, Alexander developed the concept of generative pattern languages
+ to guide a designer’s application of individual patterns to the entire design. In software design, however, as
+ Alexander observed [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">OOP96</a>] there is little evidence of using generative pattern languages.
+</p>
+<p>
+ For iterative development methods, software patterns and pattern languages support the development method through their
+ ability to be applied incrementally, or by piecemeal growth, and by providing extensible structures. From an
+ architectural perspective, these two qualities allow software architecture to be designed and refactored incrementally,
+ thus so avoid the need for a so-called "big, up-front design."
+</p>
+<h4>
+ Piecemeal growth
+</h4>
+<p>
+ The term <strong>piecemeal growth</strong>, as it applies to patterns, originates in Alexander's work. It refers to a
+ top-down design process in which a design starts from a high-level structure that is embellished or refined through the
+ implementation of lower-level patterns. For software development, this corresponds to using hierarchies of
+ architectural and design patterns and idioms like those proposed by Buschmann et. al. [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>]. Using the idea of piecemeal growth, an architect can start with one or more
+ architectural patterns to provide an architectural vision for the design, and then progressively extend the design
+ using design patterns. For example, an interactive application may use the Model-View-Controller pattern as its
+ architectural vision, then during implementation the Command pattern may be selected to implement the Controller
+ component.
+</p>
+<h4>
+ Extensibility
+</h4>
+<p>
+ A key aspect of object oriented design patterns is their ability to support extension without causing the rewriting of
+ existing code. This feature allows a bottom up approach to the design process through code refactoring. When a problem
+ is encountered during coding such as duplicate code, the developer can weighed up various patterns and their tradeoffs
+ and select the appropriate solution in the context of the application.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/work_items_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/work_items_list.xmi
new file mode 100644
index 0000000..978108a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/work_items_list.xmi
@@ -0,0 +1,136 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-G1Oxlk6F0R09vClqy1EzOw" name="work_items_list,_7vEXEMA4EdqSgKaj2SZBmg" guid="-G1Oxlk6F0R09vClqy1EzOw" changeDate="2006-08-31T13:22:12.278-0700">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;captures all scheduled work to be done within the
+ project, as well as proposed work that may affect the product. Some of the Work Items may be implemented in this
+ project, some of them may be implemented in a future project, and some of them may never be implemented.
+</p>
+<p>
+ Some of the work items may still be poorly defined, representing a big chunk of work requiring potentially several
+ staff months of effort. As the priority of these work items increase, they are typically decomposed into smaller work
+ items that represent specific and well-defined tasks that may take hours or days to address. In other cases, specific
+ and well-defined work items are created directly, representing for example a defect to be addressed, see Figure 1.
+</p>
+<br />
+<img height="369" alt="work item list overview" src="./resources/wil_overview.bmp" width="600" /><br />
+<br />
+<p>
+ <strong><em>Figure 1. Work Items List provides one prioritized list of scheduled and proposed work.</em></strong>
+</p>
+<p>
+ A Work Item may represent work associated with a defect, enhancement request, use case, scenario, user story,
+ supporting requirement, or anything else that captures a potential requirement or improvement to your system. A Work
+ Item may reference any type of requirement, defect, enhancement request, or other useful information guiding you in
+ what needs to be done.
+</p>
+<p>
+ A big advantage with the <a class="elementLinkWithType" href="./../../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;is that it enables you to prioritize only one list
+ containing all the things that may need to be addressed, whether the work item represent a work related to a
+ requirement, enhancement, or defect. The one exception is that we separately prioritize the risk list.
+</p>
+<p>
+ Nothing in the project will get done if not represented or mapped to a Work Item. This means that all requirements,
+ defects and change requests have to at some stage be mapped to a work item. Also, a developer will not take on work
+ that is not represented in a Work Item. Only Work Items needs to be prioritized. This also means that tracking Work
+ Items are a primary means of understanding status of the project.
+</p>
+<p>
+ There are two major types of Work Items:
+</p>
+<ul>
+ <li>
+ <strong>Un-scheduled Work Items:</strong> These Work Items have not yet been assigned to an iteration, and there is
+ no detailed effort estimate for the Work Item yet.
+ </li>
+ <li>
+ <strong>Scheduled Work Items:</strong> These Work Items are assigned to an iteration, and typically have an
+ additional set of attributes filled in, such as detailed effort estimates.
+ </li>
+</ul>
+<h3>
+ Un-scheduled Work Items
+</h3>
+<p>
+ Most Work Items are initially un-scheduled, meaning that it has not yet been decided whether to do them, and when to do
+ them. Unscheduled Work Items should always represent something meaningful to deliver to stakeholders, such a scenario
+ to be detailed, designed, implemented and tested. You may consider capturing the following data for such Work Items:
+</p>
+<ul>
+ <li>
+ Name
+ </li>
+ <li>
+ Description
+ </li>
+ <li>
+ Priority
+ </li>
+ <li>
+ Size estimate, such as a point estimate, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+ </li>
+ <li>
+ State, such as New, Assigned, Resolved, Verified, Closed, see Work Items States below
+ </li>
+ <li>
+ Links to other reference material, such as requirements or detailed specifications of what needs to be done
+ </li>
+</ul>
+<h3>
+ Scheduled Work Items
+</h3>
+<p>
+ Once a Work Item has been assigned to an iteration, it becomes scheduled. Note that we only assign Work Items to the
+ current or next iteration. There is no point in assigning Work Items to a specific future iteration, since we cannot
+ predict what a meaningful schedule will be more than an iteration in advance, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/iteration_planning,_0auiMMlgEdmt3adZL5Dmdw.html" guid="_0auiMMlgEdmt3adZL5Dmdw">Guideline: Iteration Planning</a>.
+</p>
+<p>
+ The following additional attributes are useful for Scheduled Work Items:
+</p>
+<ul>
+ <li>
+ Target iteration
+ </li>
+ <li>
+ Responsible team member
+ </li>
+ <li>
+ Effort estimate left, such as actual hours of work, see <a class="elementLinkWithType" href="./../../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+ </li>
+ <li>
+ Hours worked
+ </li>
+</ul>
+<p>
+ This provides the information required to plan and manage an iteration. We can plan iterations by understanding effort
+ involved and we can do <a class="elementLinkWithType" href="./../../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> by tracking how much work is left.
+</p>
+<h3>
+ Work Items States
+</h3>
+<p>
+ We have found the following states to be useful to track Work Items:
+</p>
+<ul>
+ <li>
+ New: Work Item has been created, but not yet assigned to a team member.
+ </li>
+ <li>
+ Assigned: A team member has been identified as responsible for the Work Item.
+ </li>
+ <li>
+ Resolved: The team member responsible for the work items has implemented and tested the Work Item.
+ </li>
+ <li>
+ Verified: The Work Item has been independently tested.
+ </li>
+ <li>
+ Closed: The Work Item is no longer active.
+ </li>
+</ul>
+<p>
+ You may choose another set of states, based on your needs.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/writing_good_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/writing_good_requirements.xmi
new file mode 100644
index 0000000..6736533
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/guidelines/writing_good_requirements.xmi
@@ -0,0 +1,94 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-AJQLv2ldVv5KN9eUbdQe_g" name="new_guideline,_6jXzYNcKEdqz_d2XWoVt6Q" guid="-AJQLv2ldVv5KN9eUbdQe_g" changeDate="2006-05-01T15:33:21.329-0700" version="1.0.0">
+ <mainDescription><P>To write a good requirement,
+ you must write it<strong> </strong>as a complete sentence, with a subject
+ and a predicate (usually a verb). The subject&nbsp;is
+ an Actor, a stakeholder, the system under development, or a design entity that
+ is related to the requirement. The predicate specifies a condition, action,
+ or intended result that is done for, by, with, or to the subject.</P>
+<P>Consistent use of the verb <strong>to be </strong>solidifies
+ the link between the subject and the predicate.<strong>
+ </strong>Thus, you can analyze a requirement from
+ a grammatical point of view. </P>
+<P>Beware of lists, bullets, and words such as <strong>all</strong>, <strong>every</strong>and <strong>some</strong>. For example:<strong> </strong></P>
+<blockquote>
+ <p>The order entry clerk must<strong> </strong>be
+ able to complete 10 customer orders in less than two hours.</p>
+</blockquote>
+<P>This requirement has a subject (the order entry clerk, who<strong>
+ </strong>is an Actor), a specific and measurable
+ end state (10 customer orders completed), and a performance criterion
+ (in less than two hours).</P>
+<P>Follow these simple guidelines<strong> </strong>
+ in writing any requirement. For consistency, these examples
+ are all in the context of an aircraft. [[WAS: is used throughout.]] <a class=elementlinkwithusertext href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</P>
+<ul>
+ <li>Define one requirement at a time.
+ <blockquote>
+ <p>The pilot shall be able to control the aircraft's angle of climb with
+ one hand.</p>
+ </blockquote>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p> The pilot shall be able to feel the angle of climb from the climb control.</p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>Avoid conjunctions (and, or) that make multiple requirements. </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p>The navigator shall be able to view the aircraft's position relative to
+ the route's radio beacons. </p>
+ <p>The navigator shall be able to view the aircraft's position as
+ estimated by inertial guidance.</p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>Avoid let-out clauses or words that imply options
+ or exceptions (unless, except, if necessary, but). </li>
+ <blockquote>
+ <p>The design shall provide a rear-facing seat
+ for each cabin crew member.</p>
+ </blockquote>
+ <li>Use simple, direct sentences. </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>The pilot shall be able to see<strong> </strong>the
+ airspeed indicator.</p>
+ </blockquote>
+ <li>Use a limited (500-word) vocabulary, especially if your audience is international.
+ <blockquote>
+ <p>The airline shall be able to convert the
+ aircraft from business to holiday charter use in less than 12 hours </p>
+ </blockquote>
+ </li>
+ <blockquote>
+ <p><strong>Note: </strong>There is no need to use words such
+ as <strong> reconfigured. </strong></p>
+ </blockquote>
+ <li>Identify the type of user who needs each requirement.
+ </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>The navigator shall be able to...</p>
+ </blockquote>
+ <li>Focus on stating what result you will provide<strong>
+ </strong> for that type of user. </li>
+</ul>
+<ul>
+ <blockquote>
+ <p>...view storm clouds by radar...</p>
+ </blockquote>
+ <li>Define verifiable criteria
+ <blockquote>
+ <p> ...at least 100 miles ahead.</p>
+ </blockquote>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/iteration_burndown.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/iteration_burndown.xmi
new file mode 100644
index 0000000..158a166
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/iteration_burndown.xmi
@@ -0,0 +1,37 @@
+<?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" epf:version="1.0.0" xmi:id="-Aw8p59vJ9rWsOV82rljQiQ" name="iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA" guid="-Aw8p59vJ9rWsOV82rljQiQ" changeDate="2006-11-03T07:59:14.929-0800" version="1.0.0">
+ <mainDescription><p>
+ The iteration burndown is&nbsp;the primary tool for understanding the status of the current iteration. It shows the
+ trend for how much work is left to do within the iteration. This is accomplished by adding up the estimated effort left
+ for each of the work items to be addressed within the iteration, and showing how the estimated effort is changing over
+ the duration of the iteration. The iteration backlog should be updated frequently, preferably on a daily basis.
+</p>
+<p>
+ Factors that impact the team’s assessment of how much work remains include:
+</p>
+<ul>
+ <li>
+ Work that has been completed, which means there is less work remaining.
+ </li>
+ <li>
+ The developer responsible for a work item changes the assessment of effort required to complete the work item. This
+ should be expected, since we typically understand what it really takes to complete a task after we have done a
+ subset of the task.&nbsp;It's common for estimates of the work remaining to increase in the beginning of the
+ iteration, especially for inexperienced teams, since they often underestimate efforts. Expect estimates to continue
+ changing as teams become more experienced, but the modifications are as frequently upward as downward.
+ </li>
+ <li>
+ Estimated effort left can increase during the iteration as a result of the team learning more about what needs to
+ be done.
+ </li>
+</ul>
+<p>
+ Daily or frequent updates to the iteration burndown allows the team to react to changes. For example, cutting scope by
+ removing work items from the iteration, reducing the ambition level associated with a work item, or finding better ways
+ of approaching work items such as having an expert team member help out with difficult work items.
+</p>
+<p>
+ See <a href="./resources/ex_iteration_burndown.xls" target="_blank">ex_iteration_burndown.xls</a> for an example
+ iteration burndown report.<br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/project_burndown.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/project_burndown.xmi
new file mode 100644
index 0000000..ded8e71
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/project_burndown.xmi
@@ -0,0 +1,18 @@
+<?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" epf:version="1.0.0" xmi:id="-hrDndmFd0zexB0HNYX3gww" name="project_burndown,_ePrt8Dj3EduxovfWMDsntw" guid="-hrDndmFd0zexB0HNYX3gww" changeDate="2006-09-25T17:07:38.314-0700" version="1.0.0">
+ <mainDescription><p>
+ Project burndown is usually communicated in graphical form.&nbsp;Project burndown is very useful to quickly communicate
+ the overall project progress based on actual data and to diagnose a trend for the remainder of the project.&nbsp;
+</p>
+<p>
+ The project burndown chart consists of two perspectives, the horizontal axis showing the iterations and the vertical
+ axis indicating the remaining points from the work items list. Additionally the average burndown from previous
+ iterations is calculated and a trend for the remainder of the project diagnosed and forecasted.
+</p>
+<p>
+ Project burndown management is a enabling technique that allows direct linkage of iteration goals to work items. The
+ project manager will use the project burndown information for communicating progress and trend to senior management.
+</p>
+See <a href="./resources/ex_project_burndown.xls" target="_blank">ex_project_burndown.xls</a>&nbsp;for an example of
+project burndown.<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls
new file mode 100644
index 0000000..67cb1b6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/resources/ex_iteration_burndown.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/resources/ex_project_burndown.xls b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/resources/ex_project_burndown.xls
new file mode 100644
index 0000000..e63fef8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/reports/resources/ex_project_burndown.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/openup_basic_roadmap.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/openup_basic_roadmap.xmi
new file mode 100644
index 0000000..14d37ea
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/openup_basic_roadmap.xmi
@@ -0,0 +1,194 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-At_b3UIzbgdmtJsb2Ymfhg" name="new_roadmap,_vEruwN-rEdqiM_wFaqLjNg" guid="-At_b3UIzbgdmtJsb2Ymfhg" changeDate="2007-03-01T10:29:08.857-0800" version="1.0.0">
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ OpenUP/Basic is for small teams, working together in the same location. The team needs to engage in plenty of daily
+ face-to-face interaction. Team members include the stakeholders, developers, architects, project manager, and testers.
+ Team members engage in significant collaboration, making their own decisions as to what needs to be worked on, what the
+ priorities are, and how best to address stakeholder needs. The organization must support the team by allowing them this
+ responsibility.
+</p>
+<p>
+ Team members collaborate extensively. The presence of stakeholders as team members is critical to successfully
+ realizing OpenUP/Basic.
+</p>
+<p>
+ Team members participate in daily stand-up meetings to communicate status and issues. Problems are addressed outside of
+ the daily meetings.
+</p>
+<p>
+ OpenUP/Basic focuses on signficantly&nbsp;reducing risk early in the lifecycle. This requires regular risk review
+ meetings and rigorous implementation of mitigation strategies.
+</p>
+<p>
+ All work is listed, tracked, and assigned through the Work Item List. Team mebers use this single repository for all
+ tasks that need to be recorded and tracked. This includes all change requests, bugs, and stakeholder requests.
+</p>
+<p>
+ Use cases are used to elicit and describe requirements. Team members should develop skills at writing good use cases.
+ Stakeholders are responsbile for reviewing and certifying the requirements are correct. Use cases are developed
+ collaboratively.
+</p>
+<p>
+ Architecturally significant requirements must be identified and stabilized in Elaboration so a robust architecture can
+ be created that is the core of the system. An architecturally significant requirement change may arise later in
+ development that must be addressed, but the risk of this happening is significantly reduced in the Elaboration
+ iteration.
+</p>
+<p>
+ Testing is performed....
+</p>
+<p>
+ OpenUP/Basic doesn't include content for deployment, change management, or environment (such as customizing this
+ process or setting up development environments). OpenUP/Basic is focused on a singe team, and these areas are generally
+ addressed at an organizational or enterprise level. Look for extensions to OpenUP that address these wider areas.<br />
+</p>
+<p>
+ OpenUP/Basic is an iterative software development process that is minimal, complete, and extensible. It is governed by
+ four core <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html"
+ guid="_HEu9QBOHEduCNqgZdt_OaA">principles</a>:
+</p>
+<ul>
+ <li>
+ Balance competing priorities to maximize stakeholder value.
+ </li>
+ <li>
+ Collaborate to align interests and share understanding
+ </li>
+ <li>
+ Evolve to continuously obtain feedback and improve
+ </li>
+ <li>
+ Focus on articulating the architecture
+ </li>
+</ul>
+<p>
+ <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">Roles</a>&nbsp;perform <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/task,_x459ktnmEdmO6L4XMImrsA.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> that consume and produce <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/termdefinitions/artifact,_x7cUM9nmEdmO6L4XMImrsA.html"
+ guid="_x7cUM9nmEdmO6L4XMImrsA">artifacts</a>. OpenUP/Basic describes the minimal set of&nbsp;roles, tasks, and
+ artifacts&nbsp;involved in software development:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html"
+ guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html"
+ guid="__BZycP1UEdmek8CQTQgrOQ">Tasks</a> (organized by disciplines)
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html"
+ guid="_s4Z9AMWXEdqWePvIjHInwg">Artifacts</a> (organized by domains)&nbsp;
+ </li>
+</ul>
+<h3>
+ Software development&nbsp;lifecycle
+</h3>
+<p>
+ OpenUP/Basic is an iterative process&nbsp;distributed throughout&nbsp;four <a class="elementLinkWithUserText"
+ href="./../../../base_concepts/guidances/concepts/phase,__7xOEC7aEdqHMdmRzC0-2g.html"
+ guid="__7xOEC7aEdqHMdmRzC0-2g">phases</a>: Inception, Elaboration, Construction, and Transition. Each phase consists of
+ one or more iterations, where stable, working versions of the software are developed and released, with the completion
+ of each iteration representing a minor <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">milestone</a>&nbsp;for the project and contributing to the successful achievement of the
+ Phase's major milestone where phase objectives are met.
+</p>
+<p>
+ The following diagram depicts the OpenUP/Basic <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html"
+ guid="_0uyGoMlgEdmt3adZL5Dmdw">lifecycle</a>.
+</p>
+<p align="center">
+ <img height="192" alt="Figure 1: Diagram of the OpenUP/Basic Lifecycle" src="./resources/openup-basic_lifecycle.jpg"
+ width="667" usemap="#Map" border="0" />
+</p>
+<p align="center">
+ Figure 1: The OpenUP/Basic lifecycle
+</p>
+<map id="Map" name="Map">
+ <h4>
+ How&nbsp;to get started?
+ </h4>
+ <p>
+ The fourth OpenUP core principle, "Evolve to continuously obtain feedback and improve", suggests an iterative and
+ incremental approach to adopting OpenUP/Basic.
+ </p>
+ <ul>
+ <li>
+ Start with the core principles and understand the intentions behind OpenUP.
+ </li>
+ <li>
+ Then assess your existing process, and select one or two key areas that you would like to improve.
+ </li>
+ <li>
+ Begin using OpenUP/Basic to improve these areas first.
+ </li>
+ <li>
+ In later iterations or development cycles, make incremental improvements in other areas.
+ </li>
+ <li>
+ If you have little or no experience with unified processes or other iterative processes, use OpenUP/Basic in a
+ small pilot project, perhaps with only three to four people working for only two to three months.
+ </li>
+ </ul>
+ <p>
+ While OpenUP/Basic is a ready to use as-is, you may choose to extend the process or modify the work product
+ templates to suit your specific needs. For example:
+ </p>
+ <ul>
+ <li>
+ You may require more or less precision in your work products.
+ </li>
+ <li>
+ Your organization may have specific configuration management practices or safety protocols to include in your
+ process.
+ </li>
+ <li>
+ You may simply want to put your own corporate logo on the banner.
+ </li>
+ <li>
+ You may want to incorporate lessons learned from a retrospective review into OpenUP/Basic.
+ </li>
+ </ul>
+ <p>
+ Use EPF Composer to extend and tailor OpenUP/Basic. For more information about EPF composer, visit <a
+ href="http://www.eclipse.org/epf" target="_blank">www.eclipse.org/epf</a>.
+ </p>
+ <area shape="RECT" coords="116,7,175,25" alt="link to inception phase concept"
+ href="./../../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="255,11,327,27" alt="link to elaboration phase concept"
+ href="./../../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="395,11,476,27" alt="link to construction phase concept"
+ href="./../../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="554,10,619,27" alt="link to transition phase concept"
+ href="./../../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="39,98,100,162" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/inception_phase_iteration,_xupMvxOKEduCNqgZdt_OaA.html"
+ guid="_xupMvxOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="188,99,250,168" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="332,100,397,165" alt="link to construction phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="480,98,541,167" alt="link to transition phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/transition_phase_iteration,_467NIhOKEduCNqgZdt_OaA.html"
+ guid="_467NIhOKEduCNqgZdt_OaA" />
+</map></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/resources/OpenUp2_504.JPG b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/resources/OpenUp2_504.JPG
new file mode 100644
index 0000000..b21a8a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/resources/OpenUp2_504.JPG
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg
new file mode 100644
index 0000000..4719cad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/roadmaps/resources/openup-basic_lifecycle.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/about_openup_basic.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/about_openup_basic.xmi
new file mode 100644
index 0000000..23cb0fc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/about_openup_basic.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="-WFD3nKccpkueaG15cHT-fA" name="new_supporting_material,_8tSNMPGYEdqiDINUyockoA" guid="-WFD3nKccpkueaG15cHT-fA" changeDate="2006-09-27T16:25:47.645-0700" version="1.0.0">
+ <mainDescription><h3>
+ <a id="version" name="version">Version Information</a>
+</h3>
+<p>
+ OpenUP/Basic Plug-in Version 0.9<br />
+ Based on: Base Concepts Plug-in Version: 0.9
+</p>
+<h3>
+ Legal Statement
+</h3>
+<p class="node">
+ See <a href="./resources/copyrite.htm">Intellectual Property Notices</a>.
+</p>
+<h3>
+ Browser Support
+</h3>
+<p>
+ <b>Note 1:</b> OpenUP/Basic does not currently support Netscape Navigator 6.x.
+</p>
+<p>
+ <b>Note 2:</b> Some versions of Microsoft Internet Explorer 4.x and Netscape Navigator 4.x may not be able to display
+ all pages of OpenUP/Basic.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/copyright_oup.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/copyright_oup.xmi
new file mode 100644
index 0000000..381de26
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/copyright_oup.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-PZ0CqCcJHB-nbxs8fbP7bg" name="new_supporting_material,_cTs20KzREduOqvpk_MDLfQ" guid="-PZ0CqCcJHB-nbxs8fbP7bg" changeDate="2007-01-25T16:09:53.285-0800">
+ <mainDescription><p>
+ View copyright information here:&nbsp;<a class="elementLink"
+ href="./../../../openup_basic/guidances/supportingmaterials/openup_copyright,_UaGfECcTEduSX6N2jUafGA.html"
+ guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/delivery_process_graph.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/delivery_process_graph.xmi
new file mode 100644
index 0000000..13eac63
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/delivery_process_graph.xmi
@@ -0,0 +1,30 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-cy0DcnEk7uJJ1OOH3_E6rg" name="new_supporting_material,_Pt_fYBjoEduxUfEVCtmW4Q" guid="-cy0DcnEk7uJJ1OOH3_E6rg" changeDate="2006-07-21T11:39:59.312-0700">
+ <mainDescription><img height="192" alt="OpenUP/Basic Lifecycle" src="./resources/openup-basic_lifecycle.jpg" width="667" usemap="#Map"
+border="0" /> <map id="Map" name="Map">
+ <area shape="RECT" coords="116,7,175,25" alt="link to inception phase concept"
+ href="./../../../openup_basic/guidances/concepts/inception_phase,_0hmKgBOMEduCNqgZdt_OaA.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="255,11,327,27" alt="link to elaboration phase concept"
+ href="./../../../openup_basic/guidances/concepts/elaboration_phase,_2plxwBOMEduCNqgZdt_OaA.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="395,11,476,27" alt="link to construction phase concept"
+ href="./../../../openup_basic/guidances/concepts/construction_phase,_48EKsBOMEduCNqgZdt_OaA.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="554,10,619,27" alt="link to transition phase concept"
+ href="./../../../openup_basic/guidances/concepts/transition_phase,__ca5UBOMEduCNqgZdt_OaA.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="39,98,100,162" alt="link to inception phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/inception_phase_iteration,_xupMvxOKEduCNqgZdt_OaA.html"
+ guid="_xupMvxOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="188,99,250,168" alt="link to elaboration phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="332,100,397,165" alt="link to construction phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA" />
+ <area shape="RECT" coords="480,98,541,167" alt="link to transition phase iteration delivery process"
+ href="./../../../openup_basic/deliveryprocesses/transition_phase_iteration,_467NIhOKEduCNqgZdt_OaA.html"
+ guid="_467NIhOKEduCNqgZdt_OaA" />
+</map></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/openup_basic_home.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/openup_basic_home.xmi
new file mode 100644
index 0000000..3669540
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/openup_basic_home.xmi
@@ -0,0 +1,150 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-XR2Rbg25yN80p1exWC4MHg" name="intro_to_openup_basic,_i-BDsNogEdqfmNgIq7q3Xw" guid="-XR2Rbg25yN80p1exWC4MHg" changeDate="2006-09-29T10:56:32.453-0700" version="1.0.0">
+ <mainDescription><table>
+ <tbody>
+ <tr>
+ <td>
+ <table width="100%" border="0">
+ <tbody>
+ <tr>
+ <td width="58%">
+ <div align="center">
+ <table width="589" align="center" border="0">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <img height="48" alt="getting started" src="./resources/GetStarted_48.gif" width="48" usemap="#Map" border="0" />
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <img height="48" alt="core principles" src="./resources/CorePrinciples_48.gif" width="48" usemap="#Map2" border="0" />
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <img height="48" alt="roles" src="./resources/Roles_48.gif" width="48" usemap="#Map3" border="0" />
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <img height="48" alt="work products" src="./resources/WorkProducts_48.gif" width="48" usemap="#Map4" border="0" />
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <img height="48" alt="disciplines" src="./resources/Disciplines_48.gif" width="48" usemap="#Map5" border="0" />
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <img height="48" alt="lifecycle" src="./resources/LifeCycle_48.gif" width="48" usemap="#Map6" border="0" />
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/customcategories/getting_started,_cp6ycBOGEduCNqgZdt_OaA.html" guid="_cp6ycBOGEduCNqgZdt_OaA">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" guid="_HEu9QBOHEduCNqgZdt_OaA">Core Principles</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html" guid="_TZIJ0O8NEdmKSqa_gSYthg">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html" guid="_s4Z9AMWXEdqWePvIjHInwg">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html" guid="__BZycP1UEdmek8CQTQgrOQ">Disciplines</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText" href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">Lifecycle</a>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ &nbsp;
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <p>
+ OpenUP/Basic is organized into four major areas of content, Communication&nbsp;and Collaboration,
+ Intent, Solution, and Management, also known as sub-processes.
+ </p>
+ <br />
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ <img height="350" alt="Four major areas upon which the OpenUP/Basic content is organized" src="./resources/OpenUp1_350.jpg" width="350" usemap="#Map7" border="0" /> <map id="Map7" name="Map7">
+ <area shape="RECT" alt="Stakeholder" coords="144,5,207,62" href="./../../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ" />
+ <area shape="POLY" alt="Tester" coords="336,242,310,287,254,256,278,209" href="./../../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw" />
+ <area shape="RECT" alt="Developer" coords="148,282,201,347" href="./../../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmd" />
+ <area shape="POLY" alt="Architect" coords="66,199,14,232,40,283,96,249" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html" guid="_0X9iEMlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Project Manager" coords="11,118,68,146,99,91,50,52" href="./../../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw" />
+ <area shape="POLY" alt="Analyst" coords="258,99,312,66,338,114,284,145" href="./../../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw" />
+ <area shape="CIRCLE" alt="Communication and Collaboration" coords="176,176,47" href="./../../../openup_basic/customcategories/collab_commun_subprocess,_r8cVIEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Management" coords="85,219,70,163,115,89,169,72,169,117,124,144,120,197" href="./../../../openup_basic/customcategories/management_subprocess,_Aoz2gEmcEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Intent" coords="181,116,223,143,229,196,264,219,283,160,245,94,181,70" href="./../../../openup_basic/customcategories/intent_subprocess,_57_ZMEmbEdu0xduwSKie-w.html" />
+ <area shape="POLY" alt="Solution" coords="129,211,176,235,221,210,257,231,214,271,133,272,94,232" href="./../../../openup_basic/customcategories/solution_subprocess,_HEVvgEmcEdu0xduwSKie-w.html" />
+ </map><br />
+ &nbsp;
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="left">
+ OpenUP/Basic is an iterative software development process with the following characteristics:
+ </p>
+ <div align="left">
+ <ul>
+ <li>
+ <strong>Minimal:</strong> Only fundamental process content is included
+ </li>
+ <li>
+ <strong>Complete:</strong> It can be manifested as an entire process to build a system
+ </li>
+ <li>
+ <strong>Extensible:</strong> It can be used as a foundation&nbsp;to add or tailor process
+ content
+ </li>
+ </ul>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ <map id="Map" name="Map">
+ <area shape="RECT" coords="0,1,47,47" alt="Getting Started" href="./../../../openup_basic/customcategories/getting_started,_cp6ycBOGEduCNqgZdt_OaA.html" />
+ </map><map id="Map2" name="Map2">
+ <area shape="RECT" coords="0,0,48,47" alt="Core principles" href="./../../../openup_basic/customcategories/core_principles_cat,_HEu9QBOHEduCNqgZdt_OaA.html" />
+ </map><map id="Map3" name="Map3">
+ <area shape="RECT" coords="0,0,48,48" alt="Openup basic roles" href="./../../../openup_basic/rolesets/openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg.html" />
+ </map><map id="Map4" name="Map4">
+ <area shape="RECT" coords="0,1,48,48" alt="Openup basic work product" href="./../../../openup_basic/domains/openup_basic_wp,_s4Z9AMWXEdqWePvIjHInwg.html" />
+ </map><map id="Map5" name="Map5">
+ <area shape="RECT" coords="0,0,47,48" alt="Openup basic disciplines" href="./../../../openup_basic/disciplinegroupings/openup_basic_disciplines,__BZycP1UEdmek8CQTQgrOQ.html" />
+ </map><map id="Map6" name="Map6">
+ <area shape="RECT" coords="0,0,47,48" alt="Openup basic process" href="./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html" />
+ </map>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/openup_copyright.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/openup_copyright.xmi
new file mode 100644
index 0000000..ab6b7f0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/openup_copyright.xmi
@@ -0,0 +1,12 @@
+<?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" epf:version="1.0.0" xmi:id="-RNyaB6jxqoopm9fJU8k9vg" name="new_supporting_material,_UaGfECcTEduSX6N2jUafGA" guid="-RNyaB6jxqoopm9fJU8k9vg" changeDate="2007-01-31T19:45:05.478-0500" version="1.0.0">
+ <mainDescription><p>
+ Copyright &copy; 1987, 2006 IBM Corp. All Rights Reserved.<br />
+ Copyright &copy; 2006 Telelogic AB. All Rights Reserved.<br />
+ Copyright &copy; 2006 Armstrong Process Group, Inc. All Rights Reserved.<br />
+ Copyright &copy; 2006 Number Six Software, Inc. All Rights Reserved.<br />
+</p>
+<p>
+ And others. All rights reserved
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/references.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/references.xmi
new file mode 100644
index 0000000..1df18e0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/references.xmi
@@ -0,0 +1,213 @@
+<?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" epf:version="1.0.0" xmi:id="-aCI9T-9TIe8D35yXBU6qvg" name="references,_9ToeIB83Edqsvps02rpOOg" guid="-aCI9T-9TIe8D35yXBU6qvg" changeDate="2007-03-13T15:43:56.164-0700" version="1.0.0">
+ <mainDescription><TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ADO03</a> </TD>
+<TD colSpan=2>Adolph, Bramble, Cockburn, and Pols <EM>Patterns for Effective Use Cases</EM>, Addison Wesley, 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ADO04</a> </TD>
+<TD colSpan=2>Adolph, Bramble, Cockburn, and Pols <EM>Tutorial 17: Patterns for Writing Effective Use Cases</EM>, presented at the 19th Annual Conference on Object-Oriented Programming, Systems, Languages and Applications, 2004.</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALE77</a> </TD>
+<TD colSpan=2>Alexander, C. <EM>A Pattern Language</EM>, Oxford University Press, 1977 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALE79</a> </TD>
+<TD colSpan=2>Alexander, C., <EM>A Timeless Way of Building</EM>, Oxford University Press, 1979 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALL02</a> </TD>
+<TD colSpan=2>Allamaraju, S. <EM>Architecture Paradox</EM>, <a href="http://www.sei.cmu.edu/architecture/essays.html">http://www.sei.cmu.edu/architecture/essays.html</a>. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">ALU03</a> </TD>
+<TD colSpan=2>
+<P>Alur, D., Crupi, J., Malks, D., <EM>Core J2EE Patterns: Best Practices and Design Strategies</EM>, Prentice Hall/Sun Press, 2001.</P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P>AMB02</P>
+<P>AMB03</P>
+<P>AMB04</P>
+<P>AMB06</P>
+<P><a name="">BOE88</a> </P></TD>
+<TD colSpan=2>
+<P>Ambler, S.W. <EM>Agile Modeling: Effective Practices for Extreme Programming and Unified Process</EM>. Wiley Publishing, 2002.</P>
+<P>Ambler, S.W. <EM>Agile Database Techniques: Effective Strategies for the Agile Software Developer</EM>.&nbsp; Wiley Publishing, 2003.</P>
+<P>Ambler, S.W. <EM>The Object Primer 3rd Edition: Agile Model Driven Development with UML 2</EM>. Cambridge University Press, 2004.</P>
+<P>Ambler, S.W. and Sadalage, P.J. <EM>Refactoring Databases: Evolutionary Database Design</EM>.&nbsp; Addison Wesley, 2006.</P>
+<P>Boehm, B., Papaccio, C. <EM>Understanding and Controlling Software Cost</EM>, IEEE Trans. on Software Engineering, Oct. 1988. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BOE95</a> </TD>
+<TD colSpan=2>Boehm, B. <EM>Anchoring the Software Process</EM>, <a href="http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf">http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P>BRO95</P></TD>
+<TD colSpan=2>
+<P>Brooks, F.P <EM>The Mythical Man Month: Essays on Software Engineering, 20th Anniversary Edition</EM>.&nbsp;Addison Wesley Professional, 1995. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BOO05</a> </TD>
+<TD colSpan=2>Booch, G., Rumbaugh, J., Jacobson, I.<EM>The Unified Modeling Language User Guide</EM>, Addison-Wesley Professional, 2005</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">BUS96</a> </TD>
+<TD colSpan=2>Buschmann, F., Meunier, R., Rohnert, H.,Sommerlad, P., Stal, M., <EM>Pattern-Oriented Software Architecture -- A System of Patterns</EM>, Wiley, 1996. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">
+<P><a name="">COH05</a>&nbsp;</P>
+<P><a name="">COP95</a> </P></TD>
+<TD colSpan=2>
+<P>Cohn, M. <EM>Agile Estimation and Planning</EM>, Addison Wesley Longman, 2005 </P>Coplien, J., Schmidt, D., <EM>Pattern Languages of Program Design</EM>,Addison-Wesley Professional, 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">COP95</a> </TD>
+<TD colSpan=2>Coplien, J., Schmidt, D., <EM>Pattern Languages of Program Design</EM>,Addison-Wesley Professional, 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">CRO79</a> </TD>
+<TD colSpan=2>Crosby, Philip. <EM>Quality is Free: The Art of Making Quality Certain</EM>, McGraw-Hill, 1979. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAM95</a> </TD>
+<TD colSpan=2>Gamma, E., Helm, R., Johnson, R., Vlissides, J., <EM>Design Patterns: Elements of Reusable Object-Oriented Software</EM>, Addison-Wesley Professional; 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAB98</a> </TD>
+<TD colSpan=2>Gabriel, Richard P., <EM>Patterns of Software: Tales from the Software Community</EM>, Oxford University Press, 1998. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">GAR93</a> </TD>
+<TD colSpan=2>David Garlan and Mary Shaw. <EM>An Introduction to Software Architecture</EM>,&nbsp; SEI Technical Report CMU/SEI-94-TR-21.&nbsp; </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">HIC03</a> </TD>
+<TD colSpan=2>Hickey A., Davis, A. <EM>Elicitation Technique Selection: How Do the Experts Do It?</EM>, International Conference on Requirements Engineering (RE03), Los Alamitos, California: IEEE Computer Society Press, September 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">HUL05</a> </TD>
+<TD colSpan=2>Hull, E., Jackson, K. and&nbsp;Dick, J. <EM>Requirements Engineering</EM>, Second Edition. Springer, 2005. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">IEP1471</a> </TD>
+<TD colSpan=2>IEEE <EM>Recommended Practice for Architectural Description</EM>, IEEE Std P1471, 2000.</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KAZ00</a> </TD>
+<TD colSpan=2>Kazman, R., Carriere, S. J., Woods, S. G.&nbsp;<a href="http://www.sei.cmu.edu/staff/rkazman/annals-scenario.pdf">Toward a Discipline of Scenario-Based Architectural Engineering</a>,(Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) <a href="http://manta.cs.vt.edu./ase/">Annals of Software Engineering</a>, Vol. 9, 2000, 5-33. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KAZ04</a> </TD>
+<TD colSpan=2>Kazman, R., Kruchten, P., Nord, R., Tomayko, J.&nbsp;<EM>Integrating Software-Architecture-Centric Methods into the Rational Unified Process</EM>, CMU-SEI Technical Reports, 2004. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KRO03</a> </TD>
+<TD colSpan=2>Kroll, P. and&nbsp;Kruchten, P. <EM>The Rational Unified Process Made Easy</EM>, Addison Wesley, 2003. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%">KRO05 </TD>
+<TD colSpan=2>Kroll, P. and&nbsp;MacIsaac, B. <EM>Agility and Discipline Made Easy</EM>, Addison Wesley, 2005. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">KRU95</a> </TD>
+<TD colSpan=2>Kruchten, Phillipe B.,&nbsp; <EM>The 4+1 View Model of Architecture</EM>, IEEE Software, vol. 12, no. 6, pp 42-50, November 1995 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">MAR03</a>&nbsp;</TD>
+<TD colSpan=2>Marick, B., <EM>Exploration Through Example</EM>, <a href="http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1">http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1</a></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">NBG01</a> </TD>
+<TD colSpan=2>Eric J. Naiburg and Robert A. Maksimchuk. <EM>UML for Database Design</EM>, New York, NY: Addison Wesley, 2001</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">RUP06</a> </TD>
+<TD colSpan=2>IBM Rational 2006. <EM>The Rational Unified Process.</EM> </TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">A commercial methodology, also based on the Eclipse Process Framework, and advanced guidance on topics such as business modeling, portfolio management, asset-based development, real-time design, user experience, and so on. </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">OOP96</a> </TD>
+<TD colSpan=2>The 1996 ACM Conference on Object-Oriented Programs, Systems, Languages and Applications (OOPSLA), <EM>The Origins of Pattern Theory, the Future of the Theory, And The Generation of a Living World.</EM></TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">See <a href="http://www.patternlanguage.com/archive/ieee/ieeetext.htm" target="">http://www.patternlanguage.com/archive/ieee/ieeetext.htm</a></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">PW92</a> </TD>
+<TD colSpan=2>Dewayne E. Perry and Alexander L. Wolf. <EM>Foundations for the Study of Software Architecture</EM>. ACM SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992.</TD></TR>
+<TR>
+<TD vAlign=top width="12%"><a name="">SCH04</a> </TD>
+<TD colSpan=2>Schwaber, K. <EM>Agile Project Management with Scrum.</EM> Microsoft Press 2004. </TD></TR>
+<TR>
+<TD vAlign=top width="12%"></TD>
+<TD width="10%"></TD>
+<TD style="PADDING-BOTTOM: 10px" width="78%">
+<P>An excellent reference by one of the co-inventors of the Scrum project management method. </P></TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0 <table &gt;>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">SEI99</a> </TD>
+<TD colSpan=2>SEI, 1999. <EM>Software Risk Evaluation (SRE) Method Description, v2.0.</EM> <BR><a href="http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf#search=%22software%20risk%20evaluation%22">http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029-body.pdf#search=%22software%20risk%20evaluation%22</a> (Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.)</TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">TEL06</a> </TD>
+<TD colSpan=2>Telelogic, 2006. <EM>Get It Right the First Time: Writing Better Requirements.</EM> </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">THA00</a> </TD>
+<TD colSpan=2>Thayer, Richard H.&nbsp;and Dorfman, Merlin&nbsp;<EM>Software Requirements Engineering Second Edition</EM>, IEEE Computer Society, 2000 </TD></TR></TBODY></TABLE>
+<TABLE width="100%" summary="layout table" border=0>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">UML05</a> </TD>
+<TD colSpan=2>OMG, 2005. <EM>Unified Modeling Language 2.0: Superstructure.</EM> <BR><a href="http://www.omg.org/docs/formal/05-07-04.pdf" target="">http://www.omg.org/docs/formal/05-07-04.pdf</a>&nbsp;(Get <a href="http://www.adobe.com/products/acrobat/alternate.html" target="">Adobe reader</a>.) </TD></TR></TBODY>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">WIB04</a> </TD>
+<TD colSpan=2>Wiborg-Weber, D., Vignaud, J. L. <EM>A Framework for Managing Component Based Development</EM>, Telelogic Whitepaper, 2004 <BR><a href="http://www.telelogic.com/download/index.cfm?id=4423" target="">http://www.telelogic.com/download/index.cfm?id=4423</a></TD></TR></TBODY>
+<TBODY>
+<TR>
+<TD vAlign=top width="12%"><a name="">WIKP-MVC</a> </TD>
+<TD colSpan=2>Wikipedia <EM>Model-view-controller</EM> <BR><a href="http://en.wikipedia.org/wiki/Model-view-controller" target="">http://en.wikipedia.org/wiki/Model-view-controller</a> </TD></TR></TBODY></TABLE></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif
new file mode 100644
index 0000000..d1f6a31
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif
new file mode 100644
index 0000000..da5215c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/CorePrinciples_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif
new file mode 100644
index 0000000..36f36b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/Disciplines_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif
new file mode 100644
index 0000000..5839c94
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/GetStarted_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif
new file mode 100644
index 0000000..f7f4665
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/LifeCycle_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg
new file mode 100644
index 0000000..0bb0b38
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/OpenUp1_350.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif
new file mode 100644
index 0000000..3fb662d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/Roles_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif
new file mode 100644
index 0000000..9554964
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/WorkProducts_48.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/about.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/about.gif
new file mode 100644
index 0000000..1316610
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/about.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/copyrite.htm b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/copyrite.htm
new file mode 100644
index 0000000..51edd3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/copyrite.htm
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<title>IBM(R) Rational(R) Intellectual Property Notices and Other Licensing Requirements</title>
+</head>
+
+<body>
+NOTICES AND INFORMATION <br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+About This Content
+</p>
+<p>
+May 2, 2006
+</p>
+<p>
+License
+</p>
+<p>
+The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the Content.
+</p>
+<p>
+If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content. Check the Redistributors license that was provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in the Content and such source code may be obtained at http://www.eclipse.org.
+ <br>
+</BODY>
+</HTML>
\ No newline at end of file
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/icon_introL.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/icon_introL.gif
new file mode 100644
index 0000000..1826cbd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/icon_introL.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/mic.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/mic.gif
new file mode 100644
index 0000000..0b316db
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/mic.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.cdr b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.cdr
new file mode 100644
index 0000000..afb1e0e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.cdr
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg
new file mode 100644
index 0000000..4719cad
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/supportingmaterials/resources/openup-basic_lifecycle.jpg
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/architecture.xmi
new file mode 100644
index 0000000..09b74ee
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/architecture.xmi
@@ -0,0 +1,34 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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" epf:version="1.0.0" xmi:id="-1Lm8-0FY-QIC56u5t2SC9w" name=",__JXkoCk8EduLGM8dfVsrKg" guid="-1Lm8-0FY-QIC56u5t2SC9w" changeDate="2007-02-26T12:49:32.093+0000" version="1.0.0">
+ <mainDescription><p>
+ Here are some templates for representing the architecture. Architecture can be represented in a variety of ways,
+ according to the needs of the project team. See <a class="elementLink"
+ href="./../../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture</a>&nbsp;for more information.
+</p>
+<p>
+ Feel free to use one or more of these templates or create your own.
+</p>
+<p>
+ The <a class="elementLink" href="./../../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html"
+ guid="_0X9iEMlgEdmt3adZL5Dmdw">Architect</a> should decide what views are useful for describing the system under
+ consideration.&nbsp;
+</p>
+<p>
+ Consider one or more&nbsp;relevant views of the architecture and document each one using the provided template for the
+ architectural view. If needed, document information that applies to more than one view using the template provided for
+ the Software Architecture Document to get an integrated representation of the architecture instead of just snapshots
+ taken from different angles.
+</p>
+<p>
+ The structuring of the documents must support the needs of the intended audience. For example, instead of a document
+ for the implementation view developers may find more useful alternative forms for the project directory structure like
+ the template provided for the project startup kit.
+</p>
+<p>
+ Keep documentation up-to-date but to an essential minimum. When the architecture is under development, decisions are
+ reconsidered frequently so constant revision of the documentation is an unnecessary expense.&nbsp; Determine points in
+ the development lifecycle when documentation should be updated.
+</p></mainDescription>
+ <attachments>resources/sw_architecture_doc_tpl.dot|resources/project_startup_kit.zip|resources/sw_architecture_view_tpl.dot|resources/software_arch_document.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/iteration_plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/iteration_plan.xmi
new file mode 100644
index 0000000..18115b6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/iteration_plan.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_Z_bUIMM2EdmSIPI87WLu3g" name="iteration_plan,_0dBoQMlgEdmt3adZL5Dmdw" guid="_Z_bUIMM2EdmSIPI87WLu3g" changeDate="2006-05-08T16:49:33.210-0700">
+ <attachments>resources/iteration_plan.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/project_plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/project_plan.xmi
new file mode 100644
index 0000000..60e29a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/project_plan.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_XjOXcMM2EdmSIPI87WLu3g" name="project_plan,_0c7hoMlgEdmt3adZL5Dmdw" guid="_XjOXcMM2EdmSIPI87WLu3g" changeDate="2006-05-08T17:03:04.654-0700">
+ <attachments>resources/project_plan.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/iteration_plan.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/iteration_plan.dot
new file mode 100644
index 0000000..0c5aa32
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/iteration_plan.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/project_plan.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/project_plan.dot
new file mode 100644
index 0000000..7d0f02b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/project_plan.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/project_startup_kit.zip b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/project_startup_kit.zip
new file mode 100644
index 0000000..01f305a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/project_startup_kit.zip
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/risk_list.xls b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/risk_list.xls
new file mode 100644
index 0000000..e3970a2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/risk_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/software_arch_document.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/software_arch_document.dot
new file mode 100644
index 0000000..e13bc09
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/software_arch_document.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/status_assessment.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/status_assessment.dot
new file mode 100644
index 0000000..02c5cd1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/status_assessment.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/supporting_req.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/supporting_req.dot
new file mode 100644
index 0000000..9ee5649
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/supporting_req.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/supporting_req_spec.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/supporting_req_spec.dot
new file mode 100644
index 0000000..3baaa46
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/supporting_req_spec.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot
new file mode 100644
index 0000000..1839b44
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/sw_architecture_doc_tpl.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot
new file mode 100644
index 0000000..5a9581f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/sw_architecture_view_tpl.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/test_case.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/test_case.dot
new file mode 100644
index 0000000..2395e41
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/test_case.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/uc_specification.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/uc_specification.dot
new file mode 100644
index 0000000..fdcd90c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/uc_specification.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/vision.dot b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/vision.dot
new file mode 100644
index 0000000..9628c3b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/vision.dot
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/work_items_list.xls b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/work_items_list.xls
new file mode 100644
index 0000000..9f0b462
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/resources/work_items_list.xls
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/risk_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/risk_list.xmi
new file mode 100644
index 0000000..98595b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/risk_list.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="-OugFZJszm73z0_KSwRXZPw" name="new_template,_MIUO0C8FEduzydamRseoUw" guid="-OugFZJszm73z0_KSwRXZPw">
+ <attachments>resources/risk_list.xls</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/software_arch_document.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/software_arch_document.xmi
new file mode 100644
index 0000000..fd0456d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/software_arch_document.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_fJPGkMM2EdmSIPI87WLu3g" name="software_arch_document,_0dN1gMlgEdmt3adZL5Dmdw" guid="_fJPGkMM2EdmSIPI87WLu3g" changeDate="2006-05-09T10:50:14.957-0700">
+ <attachments>resources/software_arch_document.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/status_assessment.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/status_assessment.xmi
new file mode 100644
index 0000000..f6a3347
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/status_assessment.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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" epf:version="1.0.0" xmi:id="-2uQACndDBzBhJC1sCmk5UA" name="new_template,_1awLIEp2Edup0IY9DKDPkg" guid="-2uQACndDBzBhJC1sCmk5UA">
+ <attachments>resources/status_assessment.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/supporting_requirements_spec.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/supporting_requirements_spec.xmi
new file mode 100644
index 0000000..87f73c3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/supporting_requirements_spec.xmi
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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" epf:version="1.0.0" xmi:id="-FsyxZy4tyX8k5CxT5Jww_w" name="new_template,_ItYXcNa9Edqrw4BYKyYKiA" guid="-FsyxZy4tyX8k5CxT5Jww_w" authors="Ana Paula Valente Pereira (apereira@whatever.pt) and Chris Sibbald" changeDate="2006-08-17T12:24:20.463-0400" version="0.4">
+ <mainDescription>This template provides a starting point for capturing&nbsp;supporting requirement in a consistent manner and to provide a
+useful checklist when determining the types of requirements that may apply.&nbsp; It is not expected that one would
+complete&nbsp;every section of this template in all circumstances.&nbsp; Tailor as you see fit for your particular
+circumstances.</mainDescription>
+ <attachments>resources/supporting_req_spec.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/test_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/test_case.xmi
new file mode 100644
index 0000000..8aef710
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/test_case.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_j2pQ4MM2EdmSIPI87WLu3g" name="test_case,_0dT8IMlgEdmt3adZL5Dmdw" guid="_j2pQ4MM2EdmSIPI87WLu3g" changeDate="2006-05-09T10:58:06.425-0700">
+ <attachments>resources/test_case.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/uc_specification.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/uc_specification.xmi
new file mode 100644
index 0000000..4111542
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/uc_specification.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_OaB-UMM2EdmSIPI87WLu3g" name="uc_specification,_0cpNwMlgEdmt3adZL5Dmdw" guid="_OaB-UMM2EdmSIPI87WLu3g" changeDate="2006-05-09T11:32:09.165-0700">
+ <attachments>resources/uc_specification.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/vision.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/vision.xmi
new file mode 100644
index 0000000..52893af
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/vision.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="_LxX6AMM2EdmSIPI87WLu3g" name="vision,_0cW54MlgEdmt3adZL5Dmdw" guid="_LxX6AMM2EdmSIPI87WLu3g" changeDate="2006-05-09T11:32:25.328-0700">
+ <attachments>resources/vision.dot</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/work_items_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/work_items_list.xmi
new file mode 100644
index 0000000..6f10ead
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/templates/work_items_list.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:GuidanceDescription 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="-mPA7vone29k1OvF_1rACjg" name="work_items_list,_QwUJYDg0Edu4E8ZdmlYjtA" guid="-mPA7vone29k1OvF_1rACjg">
+ <attachments>resources/work_items_list.xls</attachments>
+</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/actor.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/actor.xmi
new file mode 100644
index 0000000..1d279b5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/actor.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-4RQJzq_1URTZ5FGCBKnTIw" name="new_term_definition,_ZsK30EvBEdunZcj9T5hrMQ" guid="-4RQJzq_1URTZ5FGCBKnTIw">
+ <mainDescription>Someone or something, outside the system that interacts with the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/agile.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/agile.xmi
new file mode 100644
index 0000000..f322be0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/agile.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-qZE4XgeMK93LmJMKuQWGFg" name=",_3PJ38EvqEdunZcj9T5hrMQ" guid="-qZE4XgeMK93LmJMKuQWGFg">
+ <mainDescription>A set of values and principles for software development that use lean production techniques to deliver value to
+stakeholders quickly and frequently.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/analyst.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/analyst.xmi
new file mode 100644
index 0000000..f869df1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/analyst.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-1RwpgmmY974S0YkxEOFDCw" name="new_term_definition,_GEAwAEvCEdunZcj9T5hrMQ" guid="-1RwpgmmY974S0YkxEOFDCw">
+ <mainDescription>Role representing customer and end-user concerns</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architect.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architect.xmi
new file mode 100644
index 0000000..79cb5b4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architect.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-2QB1bosN011CudkwZ0cn-g" name="architect,_wI3R4EvCEdunZcj9T5hrMQ" guid="-2QB1bosN011CudkwZ0cn-g">
+ <mainDescription>Role representing someone responsible for designing the software architecture, which includes making the key technical
+decisions that constrain the overall design and implementation of the project</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architectural_mechanism.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architectural_mechanism.xmi
new file mode 100644
index 0000000..85f412d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architectural_mechanism.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-Vvwb6EupIB9kfSQ_mhjURA" name="architectural_mechanism,_VHFGkEvCEdunZcj9T5hrMQ" guid="-Vvwb6EupIB9kfSQ_mhjURA" changeDate="2006-09-24T13:46:41.881+0100">
+ <mainDescription>Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of
+structure, patterns of behavior, or both.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architectural_view.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architectural_view.xmi
new file mode 100644
index 0000000..b9d86f9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architectural_view.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-0vih7gB84YYDheaH7jeYFQ" name="new_term_definition,_n7GmQEvCEdunZcj9T5hrMQ" guid="-0vih7gB84YYDheaH7jeYFQ">
+ <mainDescription>A view of the&nbsp; architecture from a given perspective.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architecture.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architecture.xmi
new file mode 100644
index 0000000..d0b3916
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/architecture.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-YMvJ5LwexkcVWWqLdm5-nQ" name=",_siyjEEvCEdunZcj9T5hrMQ" guid="-YMvJ5LwexkcVWWqLdm5-nQ">
+ <mainDescription>Describes the blueprint for software development, frequently represented using a number of architectural views. It also
+contains the rationale, assumptions, explanations and implications of the decisions that where made in forming the
+architecture as well as the global mapping between views</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/build.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/build.xmi
new file mode 100644
index 0000000..80026c2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/build.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-Wh-byAGHoy_gGry0Jq6VaA" name=",_Z-AukEvpEdunZcj9T5hrMQ" guid="-Wh-byAGHoy_gGry0Jq6VaA">
+ <mainDescription>An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the
+final product</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/business_rule.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/business_rule.xmi
new file mode 100644
index 0000000..59b25b9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/business_rule.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-COrjB4k8Qtf6ZpPEcBNwpw" name=",_NtGL0EvDEdunZcj9T5hrMQ" guid="-COrjB4k8Qtf6ZpPEcBNwpw">
+ <mainDescription>A declaration of policy or condition that must be satisfied by the system under consideration. For more information see
+Supporting Requirements</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/code_instrumentation.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/code_instrumentation.xmi
new file mode 100644
index 0000000..a05caf1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/code_instrumentation.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-RlYzPnl6Pig2H851hHebBA" name="new_term_definition,_JiqnEJt1EdutoZjlV3a4Lg" guid="-RlYzPnl6Pig2H851hHebBA" changeDate="2007-01-03T16:56:04.699-0500">
+ <mainDescription><p>
+ "Extra" statements added to source code for the purposes of testing, debugging, tuning,&nbsp;or tracing.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/component.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/component.xmi
new file mode 100644
index 0000000..d5bc074
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/component.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-BWZsh3vKrqSOzfkBJmDTLA" name=",_d82_AEvDEdunZcj9T5hrMQ" guid="-BWZsh3vKrqSOzfkBJmDTLA">
+ <mainDescription>A nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined
+architecture. A component conforms to and provides the realization of a set of interfaces</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/configuration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/configuration.xmi
new file mode 100644
index 0000000..59fada0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/configuration.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-VPoMu7qzVX9grE4-nB3kMw" name=",__Cw30ElxEducWJcS4yanqg" guid="-VPoMu7qzVX9grE4-nB3kMw" changeDate="2006-09-21T09:07:10.404-0400">
+ <mainDescription>The performance, functional, and physical attributes of an existing or planned product, or a combination of products.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/construction.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/construction.xmi
new file mode 100644
index 0000000..25c5fcd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/construction.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-5wJmUR0WqX7lCIxsyqFsdA" name=",_0sD60EvDEdunZcj9T5hrMQ" guid="-5wJmUR0WqX7lCIxsyqFsdA">
+ <mainDescription>The third phase of the OpenUP/ Basic project lifecycle, in which the software is brought from an executable architectural
+baseline to the point at which it is ready to be transitioned to the user community.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/developer.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/developer.xmi
new file mode 100644
index 0000000..aab29a6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/developer.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-802sCZ4lJcejyRbhLmkxkw" name=",_-61a8EvOEdunZcj9T5hrMQ" guid="-802sCZ4lJcejyRbhLmkxkw" changeDate="2006-09-24T15:17:35.993+0100">
+ <mainDescription>Role representing someone&nbsp; responsible for developing a part of the system, including designing it to fit into the
+architecture, and then implementing, unit-testing, and integrating the components that are part of the solution.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/effort.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/effort.xmi
new file mode 100644
index 0000000..697e5da
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/effort.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-WIgtkwJN71D51FdcQs-TzQ" name=",_nJSDwEvuEdunZcj9T5hrMQ" guid="-WIgtkwJN71D51FdcQs-TzQ">
+ <mainDescription><p>
+ Indicates how long it will take the team member(s) assigned to the work item to do the work. Typically uses the units
+ of Actual Days or Actual Hours
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/elaboration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/elaboration.xmi
new file mode 100644
index 0000000..d092b64
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/elaboration.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-0g2jTHQla8lbP6xGB3iGlg" name=",_8DkT4EvDEdunZcj9T5hrMQ" guid="-0g2jTHQla8lbP6xGB3iGlg">
+ <mainDescription>Second of four phases in the in the OpenUP/ Basic project lifecycle, when architecturally-significant risks are addressed</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/feature.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/feature.xmi
new file mode 100644
index 0000000..36260a0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/feature.xmi
@@ -0,0 +1,7 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-qpBnpWqiD7gjT08LjTMbsQ" name="new_term_definition,_PgYREAeYEduWycDgioo5rg" guid="-qpBnpWqiD7gjT08LjTMbsQ" changeDate="2006-06-29T10:56:21.941-0700">
+ <mainDescription>An externally observable service provided by the system that directly fulfills
+a <a class="elementLink"
+href="./../../../openup_basic/guidances/termdefinitions/stakeholder_need,_WUiFcAeYEduWycDgioo5rg.html"
+guid="_WUiFcAeYEduWycDgioo5rg">Stakeholder Need</a>&nbsp;.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/furps.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/furps.xmi
new file mode 100644
index 0000000..f1b2d1c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/furps.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-vq2pL6yQuqGhql9Wo_Av4w" name=",_ZH6M0EvEEdunZcj9T5hrMQ" guid="-vq2pL6yQuqGhql9Wo_Av4w" changeDate="2006-12-21T12:45:04.101-0500" version="1.0.0">
+ <mainDescription>Functional, usability, reliability, performance, supportability + others. This acronym represents categories that can be
+used in the definition of product requirements. For more information see Supporting Requirements</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/glossary.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/glossary.xmi
new file mode 100644
index 0000000..419199e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/glossary.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-05pn_DGdNui9qqwx46iKZQ" name=",_VhhDMEvrEdunZcj9T5hrMQ" guid="-05pn_DGdNui9qqwx46iKZQ" changeDate="2006-09-24T18:40:24.193+0100">
+ <mainDescription>An artifact in OpenUP that defines the vocabulary and other important terms that are part of a project and the problem
+domain.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/inception.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/inception.xmi
new file mode 100644
index 0000000..5d1838d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/inception.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-dhgOQQ4GsV0-dNJmTmF9GA" name=",_525A8EvDEdunZcj9T5hrMQ" guid="-dhgOQQ4GsV0-dNJmTmF9GA" changeDate="2006-09-24T14:05:23.073+0100">
+ <mainDescription>First of the four phases in the OpenUP/ Basic project lifecycle, it is about understanding the project scope and objectives
+and getting enough information to confirm that the project should proceed&nbsp; or not.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/ioc_milestone.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/ioc_milestone.xmi
new file mode 100644
index 0000000..4885640
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/ioc_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-gEgZg2UkFLjGeXkJLpAP6A" name=",_O7JBYEvFEdunZcj9T5hrMQ" guid="-gEgZg2UkFLjGeXkJLpAP6A" changeDate="2006-09-24T14:41:48.635+0100">
+ <mainDescription>At the end of Construction phase is the third important project milestone.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/iteration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/iteration.xmi
new file mode 100644
index 0000000..067dfeb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/iteration.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-_G0VvVOdMoajk615LwFtxg" name=",_ZBUnMEvFEdunZcj9T5hrMQ" guid="-_G0VvVOdMoajk615LwFtxg" changeDate="2006-09-24T14:23:38.618+0100">
+ <mainDescription>Short and time-boxed division of a project. Iterations allow to demonstrate incremental value and obtain early and
+continuous feedback</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/iteration_burndown.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/iteration_burndown.xmi
new file mode 100644
index 0000000..b4bfd3d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/iteration_burndown.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-3G3HV0opAmFWGxYgsD5AhA" name=",_8b20EEvvEdunZcj9T5hrMQ" guid="-3G3HV0opAmFWGxYgsD5AhA">
+ <mainDescription>A&nbsp;primary tool for understanding the status of an iteration. It shows the trend for how much work is left to do within
+that iteration.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/lca_milestone.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/lca_milestone.xmi
new file mode 100644
index 0000000..bfb482f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/lca_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-MllWL01NL93RTB7VsY69fw" name=",_NL4DMEvFEdunZcj9T5hrMQ" guid="-MllWL01NL93RTB7VsY69fw">
+ <mainDescription>At the end of the Elaboration phase is the second important project milestone</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/lco_milestone.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/lco_milestone.xmi
new file mode 100644
index 0000000..a6665d1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/lco_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-Rl8kaRW9Bxqdvq32kVCi7w" name=",_LGRBkEvFEdunZcj9T5hrMQ" guid="-Rl8kaRW9Bxqdvq32kVCi7w">
+ <mainDescription>At the end of the Inception phase is the first major project milestone</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/milestone.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/milestone.xmi
new file mode 100644
index 0000000..e042ec7
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/milestone.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-9fXEOvMc4t7y6s5GscBD1Q" name=",_ByXNcEvqEdunZcj9T5hrMQ" guid="-9fXEOvMc4t7y6s5GscBD1Q">
+ <mainDescription><p>
+ The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready
+ to move to the next iteration or phase.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/pattern.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/pattern.xmi
new file mode 100644
index 0000000..2a3b8bb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/pattern.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-VJBtRm2brEKpRlnLWNF8_g" name=",_ctrEgEvCEdunZcj9T5hrMQ" guid="-VJBtRm2brEKpRlnLWNF8_g">
+ <mainDescription>Generalized solutions that can be implemented and applied in a problem situation (a context)</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/point.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/point.xmi
new file mode 100644
index 0000000..7307076
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/point.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-oShmMITo9RIi1AzACWI9vw" name="new_term_definition,_MvOuAEvGEdunZcj9T5hrMQ" guid="-oShmMITo9RIi1AzACWI9vw" changeDate="2006-09-24T18:59:48.289+0100">
+ <mainDescription>A relative measure of size is typically used for Agile estimation</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/pr_milestone.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/pr_milestone.xmi
new file mode 100644
index 0000000..c27251f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/pr_milestone.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-JegYQHIteCRN0iV2EKMjSA" name=",_QuywUEvFEdunZcj9T5hrMQ" guid="-JegYQHIteCRN0iV2EKMjSA">
+ <mainDescription>At the end of the Transition phase is the last major project milestone</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/project_burndown.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/project_burndown.xmi
new file mode 100644
index 0000000..9919821
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/project_burndown.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-NNByAM5YsjCu39flaOSZtQ" name=",_eX0YsEvvEdunZcj9T5hrMQ" guid="-NNByAM5YsjCu39flaOSZtQ" changeDate="2006-09-24T19:09:54.521+0100">
+ <mainDescription>A chart consisting of two perspectives, the horizontal axis showing the iterations and the vertical axis indicating the
+remaining points from the work items list.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/requirement.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/requirement.xmi
new file mode 100644
index 0000000..9816094
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/requirement.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-0sCBiohjw_wBDKk0WEeDJQ" name="new_term_definition,_feKVQLULEdqI644ssJaKYg" guid="-0sCBiohjw_wBDKk0WEeDJQ" authors="Chris Sibbald" changeDate="2006-12-22T09:19:44.500-0500" changeDescription="Added term definition for "requirement"." version="0.2">
+ <mainDescription><ol>
+ <li>
+ A capability needed by the user to solve a problem [in order to] to achieve an objective
+ </li>
+ <li>
+ A capability that must be met or possessed by a system or system component to satisfy a contract, standard,
+ specification, or other formally imposed documentation <a class="elementLinkWithUserText"
+ href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[THA00]</a><br />
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/risk.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/risk.xmi
new file mode 100644
index 0000000..a17fd9d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/risk.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-hOtatvr8wIjqW8UD0MSGhQ" name="risk,_ii2LUEvGEdunZcj9T5hrMQ" guid="-hOtatvr8wIjqW8UD0MSGhQ" changeDate="2006-09-29T11:58:30.374-0700" version="1.0.0">
+ <mainDescription>A condition that can potentially affect, prevent, or limit a project's success. Project risks may be seen as threats or
+opportunities</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/scope.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/scope.xmi
new file mode 100644
index 0000000..e0d64c1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/scope.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-h1poMaxtQbmg6hD5772oVw" name=",_t7JOkEvtEdunZcj9T5hrMQ" guid="-h1poMaxtQbmg6hD5772oVw" changeDate="2006-09-24T19:22:03.239+0100">
+ <mainDescription>A description of the breadth of a system's behavior, specifying the boundaries of the problem domain or system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/stakeholder_need.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/stakeholder_need.xmi
new file mode 100644
index 0000000..17e35d8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/stakeholder_need.xmi
@@ -0,0 +1,5 @@
+<?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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-1pmL5bC27rtWB84PXAgq9Q" name="new_term_definition,_WUiFcAeYEduWycDgioo5rg" guid="-1pmL5bC27rtWB84PXAgq9Q">
+ <mainDescription>The business or operational problem (opportunity) that must be fulfilled to justify
+purchase or use of the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/supporting_requirement.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/supporting_requirement.xmi
new file mode 100644
index 0000000..900c071
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/supporting_requirement.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-ketzwgDgY82DMyfuHqu3Cw" name=",_U_olUEvDEdunZcj9T5hrMQ" guid="-ketzwgDgY82DMyfuHqu3Cw" changeDate="2006-12-21T12:32:14.441-0500" version="1.0.0">
+ <mainDescription>Supporting requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
+usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral requirements
+artifacts such as use-cases.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/test_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/test_case.xmi
new file mode 100644
index 0000000..df79e4e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/test_case.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-6oW2YOnoWq_xPpmoil91KA" name="test_case,_U4RYEEvOEdunZcj9T5hrMQ" guid="-6oW2YOnoWq_xPpmoil91KA">
+ <mainDescription><p>
+ The specification of a set of test inputs, execution conditions, and expected results, which need to be validated to
+ enable an assessment of some particular aspects of the system under test.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/tester.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/tester.xmi
new file mode 100644
index 0000000..6545a39
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/tester.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-prQBbamJ4CLPywfEbyaPaA" name=",_WB6rQEvPEdunZcj9T5hrMQ" guid="-prQBbamJ4CLPywfEbyaPaA" changeDate="2006-09-24T15:20:01.152+0100">
+ <mainDescription>Role representing someone&nbsp; responsible for the core activities of the test effort.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/transition.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/transition.xmi
new file mode 100644
index 0000000..72efd0e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/transition.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-yoFF90pq-_UV3fm-5oDenw" name=",_-5ms4EvDEdunZcj9T5hrMQ" guid="-yoFF90pq-_UV3fm-5oDenw">
+ <mainDescription>The fourth and last <span class="docEmphasis">phase</span> of the OpenUP/ Basic project lifecycle, which results in a final
+product <span class="docEmphasis">release</span>.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case.xmi
new file mode 100644
index 0000000..abccf68
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-HDfMzDXoilK-f2iNreHRVg" name=",_IHRO8EvHEdunZcj9T5hrMQ" guid="-HDfMzDXoilK-f2iNreHRVg">
+ <mainDescription>Captures requirements as&nbsp;a&nbsp; sequence of actions a system performs that yields an observable result of value to
+those interacting with the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case_model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case_model.xmi
new file mode 100644
index 0000000..7a15c6b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case_model.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-UTrE64wEDJIC1FRUomEYDg" name=",_k6B3kEvmEdunZcj9T5hrMQ" guid="-UTrE64wEDJIC1FRUomEYDg">
+ <mainDescription>A&nbsp;model of the system use cases and actors and the relationships between them</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case_scenario.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case_scenario.xmi
new file mode 100644
index 0000000..bffc82f
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/use_case_scenario.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-t3jNM5ZWkYtzB8A4Chz2Vw" name=",_oXmYMEvGEdunZcj9T5hrMQ" guid="-t3jNM5ZWkYtzB8A4Chz2Vw">
+ <mainDescription>Represents specific instances of the use case that correspond to specific inputs from the Actor or to specific conditions
+in the environment. Each scenario describes alternate ways that the system provides a behavior, or it may describe failure
+or exception cases</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/velocity.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/velocity.xmi
new file mode 100644
index 0000000..4f95433
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/velocity.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-mgWkuUy3q0zzFaxE7DY1ag" name=",_Nj2hsEvuEdunZcj9T5hrMQ" guid="-mgWkuUy3q0zzFaxE7DY1ag">
+ <mainDescription>A&nbsp;key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a
+certain team and project.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/version.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/version.xmi
new file mode 100644
index 0000000..cd92f6d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/version.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-4iL0UEFR2Fg7oWkh1TymIg" name=",_eX8K8ElyEducWJcS4yanqg" guid="-4iL0UEFR2Fg7oWkh1TymIg" changeDate="2006-09-21T09:10:30.780-0400">
+ <mainDescription>A variant of some artifact; later versions of an artifact typically expand upon earlier versions.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/vision.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/vision.xmi
new file mode 100644
index 0000000..d6e86e6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/vision.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-VMnkFJpPLdEDUpbz2QDgow" name=",_J_5kgEvHEdunZcj9T5hrMQ" guid="-VMnkFJpPLdEDUpbz2QDgow" changeDate="2006-09-24T14:21:36.312+0100">
+ <mainDescription>The user's or customer's view of the product to be developed, specified at the level of key stakeholder needs and features
+of the system.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/work_breakdown_structure.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/work_breakdown_structure.xmi
new file mode 100644
index 0000000..ea004fc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/work_breakdown_structure.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-KQTbqDSJXR8KLBxIgGVquA" name=",_RK9nwEvtEdunZcj9T5hrMQ" guid="-KQTbqDSJXR8KLBxIgGVquA">
+ <mainDescription>Breaks the project into individual units of work, or tasks, for which cost, milestones, and activities can be allocated and
+tracked.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/work_item.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/work_item.xmi
new file mode 100644
index 0000000..98f62dc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/termdefinitions/work_item.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-1Oc9t_TLaBgW_YLugZcq7w" name="work_item,_jyVgcEvKEdunZcj9T5hrMQ" guid="-1Oc9t_TLaBgW_YLugZcq7w" changeDate="2006-09-24T19:07:26.158+0100">
+ <mainDescription>Scheduled work to be done within the project</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/plugin.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/plugin.xmi
new file mode 100644
index 0000000..3e32e8c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/plugin.xmi
@@ -0,0 +1,1227 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_nHk9MPL5Edm6Nvont3uinw" guid="_nHk9MPL5Edm6Nvont3uinw">
+ <subManagers xmi:id="_nI06YvL5Edm6Nvont3uinw" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_nI06YvL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nJHOQPL5Edm6Nvont3uinw" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_nJHOQPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nJr2APL5Edm6Nvont3uinw" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_nJr2APL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nJx8oPL5Edm6Nvont3uinw" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_nJx8oPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nKQdwPL5Edm6Nvont3uinw" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_nKQdwPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nKu-4vL5Edm6Nvont3uinw" href="uma://_0sluQclgEdmt3adZL5Dmdw#_nKu-4vL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nK7zMvL5Edm6Nvont3uinw" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_nK7zMvL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nLga8vL5Edm6Nvont3uinw" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_nLga8vL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nMRP8PL5Edm6Nvont3uinw" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_nMRP8PL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nNCE8PL5Edm6Nvont3uinw" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_nNCE8PL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_nNtaYPL5Edm6Nvont3uinw" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_nNtaYPL5Edm6Nvont3uinw"/>
+ <subManagers xmi:id="_h7wUUPimEdmugcVr9AdHjQ" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h7wUUPimEdmugcVr9AdHjQ"/>
+ <subManagers xmi:id="_z-Z5MOtQEdqc1LGhiSPqRg" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_z-Z5MOtQEdqc1LGhiSPqRg"/>
+ <resourceDescriptors xmi:id="_mur8EPL5Edm6Nvont3uinw" id="__rFCULv9EdmmUvZAZjqE3g" uri="disciplines/requirements.xmi"/>
+ <resourceDescriptors xmi:id="_mur8EfL5Edm6Nvont3uinw" id="_Bbq2MLv-EdmmUvZAZjqE3g" uri="disciplines/analysis_and_design.xmi"/>
+ <resourceDescriptors xmi:id="_mur8EvL5Edm6Nvont3uinw" id="_D5dHQLv-EdmmUvZAZjqE3g" uri="disciplines/implementation.xmi"/>
+ <resourceDescriptors xmi:id="_mur8E_L5Edm6Nvont3uinw" id="_FuQswLv-EdmmUvZAZjqE3g" uri="disciplines/test.xmi"/>
+ <resourceDescriptors xmi:id="_mu-P8PL5Edm6Nvont3uinw" id="_GybfgLv-EdmmUvZAZjqE3g" uri="disciplines/project_management.xmi"/>
+ <resourceDescriptors xmi:id="_mvEWkPL5Edm6Nvont3uinw" id="_H9TXMLv-EdmmUvZAZjqE3g" uri="disciplines/config_and_change_management.xmi"/>
+ <resourceDescriptors xmi:id="_mvEWkfL5Edm6Nvont3uinw" id="_Tb5J8O8NEdmKSqa_gSYthg" uri="rolesets/openup_basic_roles.xmi"/>
+ <resourceDescriptors xmi:id="_mvWqcPL5Edm6Nvont3uinw" id="_cyZ5EMfLEdmg9p6Pf0sWyw" uri="customcategories/Custom%20Categories.xmi"/>
+ <resourceDescriptors xmi:id="_mvWqcfL5Edm6Nvont3uinw" id="_gXQCkO8MEdmKSqa_gSYthg" uri="customcategories/openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_mvcxFPL5Edm6Nvont3uinw" id="_EvRkgO8NEdmKSqa_gSYthg" uri="customcategories/view_building_blocks.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3sfL5Edm6Nvont3uinw" id="_tYiSIO8NEdmKSqa_gSYthg" uri="customcategories/disciplines.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3svL5Edm6Nvont3uinw" id="_5WkxcO8NEdmKSqa_gSYthg" uri="customcategories/openup_basic_work_products.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3s_L5Edm6Nvont3uinw" id="_-jHu0O8NEdmKSqa_gSYthg" uri="customcategories/by_domain.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3tPL5Edm6Nvont3uinw" id="__uYoEO8NEdmKSqa_gSYthg" uri="customcategories/by_type.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3tfL5Edm6Nvont3uinw" id="_zHZW9KYSEdmvhNXG0Oc2uA" uri="workproducts/uc_model_intent_req_ucm.xmi"/>
+ <resourceDescriptors xmi:id="_mvi3tvL5Edm6Nvont3uinw" id="_MqODAMM1EdmSIPI87WLu3g" uri="guidances/checklists/uc_model.xmi"/>
+ <resourceDescriptors xmi:id="_m9t2kPL5Edm6Nvont3uinw" id="_AGvpcMM3EdmSIPI87WLu3g" uri="guidances/guidelines/uc_model.xmi"/>
+ <resourceDescriptors xmi:id="_m-SeUPL5Edm6Nvont3uinw" id="_zHZW8qYSEdmvhNXG0Oc2uA" uri="workproducts/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_m-xmg_L5Edm6Nvont3uinw" id="_KEldgMM1EdmSIPI87WLu3g" uri="guidances/checklists/actor.xmi"/>
+ <resourceDescriptors xmi:id="_m-xmhPL5Edm6Nvont3uinw" id="_Nx8icKYdEdmvhNXG0Oc2uA" uri="roles/analyst.xmi"/>
+ <resourceDescriptors xmi:id="_m-xmhfL5Edm6Nvont3uinw" id="_zHTQUKYSEdmvhNXG0Oc2uA" uri="workproducts/vision.xmi"/>
+ <resourceDescriptors xmi:id="_m-3tIfL5Edm6Nvont3uinw" id="_eUfzwMMyEdmdo9HxCRR_Gw" uri="guidances/concepts/requirements.xmi"/>
+ <resourceDescriptors xmi:id="_m-3tIvL5Edm6Nvont3uinw" id="_qktWQMM0EdmSIPI87WLu3g" uri="guidances/checklists/vision.xmi"/>
+ <resourceDescriptors xmi:id="_m-3tI_L5Edm6Nvont3uinw" id="_zxB-QKYcEdmvhNXG0Oc2uA" uri="workproducts/design.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zwvL5Edm6Nvont3uinw" id="_H4gOYKYTEdmvhNXG0Oc2uA" uri="workproducts/architecture_notebook.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zw_L5Edm6Nvont3uinw" id="_YIYIYMM1EdmSIPI87WLu3g" uri="guidances/checklists/design.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zxPL5Edm6Nvont3uinw" id="_SB1n8MM1EdmSIPI87WLu3g" uri="guidances/concepts/visual_modeling.xmi"/>
+ <resourceDescriptors xmi:id="_m-9zx_L5Edm6Nvont3uinw" id="_Qo7pYMM3EdmSIPI87WLu3g" uri="guidances/guidelines/design.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6YPL5Edm6Nvont3uinw" id="_17Ve8Nd6EdmIm-bsRSNCgw" uri="guidances/checklists/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6YfL5Edm6Nvont3uinw" id="_Y6tLEKbXEdm9d-ircVOUCA" uri="roles/architect.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6YvL5Edm6Nvont3uinw" id="_NqL7MqeqEdmKDbQuyzCoqQ" uri="roles/developer.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6Y_L5Edm6Nvont3uinw" id="_QvmkAMM1EdmSIPI87WLu3g" uri="guidances/concepts/pattern.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6ZPL5Edm6Nvont3uinw" id="_TZiasMM1EdmSIPI87WLu3g" uri="guidances/concepts/component.xmi"/>
+ <resourceDescriptors xmi:id="_m_D6Z_L5Edm6Nvont3uinw" id="_6u9ZsKYcEdmvhNXG0Oc2uA" uri="workproducts/implementation.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBAPL5Edm6Nvont3uinw" id="_NqSB0KeqEdmKDbQuyzCoqQ" uri="workproducts/build.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBAfL5Edm6Nvont3uinw" id="_NqSB0qeqEdmKDbQuyzCoqQ" uri="workproducts/developer_test.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBAvL5Edm6Nvont3uinw" id="_4wqaMMPaEdmbOvqy4O0adg" uri="guidances/guidelines/implementation.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBA_L5Edm6Nvont3uinw" id="_Hg5UUMPbEdmbOvqy4O0adg" uri="guidances/concepts/test_first_design.xmi"/>
+ <resourceDescriptors xmi:id="_m_KBBvL5Edm6Nvont3uinw" id="_NqYIcKeqEdmKDbQuyzCoqQ" uri="roles/tester.xmi"/>
+ <resourceDescriptors xmi:id="_m_QHoPL5Edm6Nvont3uinw" id="_NqYIdKeqEdmKDbQuyzCoqQ" uri="workproducts/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_m_QHovL5Edm6Nvont3uinw" id="_NqYIcqeqEdmKDbQuyzCoqQ" uri="workproducts/test_script.xmi"/>
+ <resourceDescriptors xmi:id="_m_QHo_L5Edm6Nvont3uinw" id="_NqePEKeqEdmKDbQuyzCoqQ" uri="workproducts/test_log.xmi"/>
+ <resourceDescriptors xmi:id="_nC4qcPL5Edm6Nvont3uinw" id="_kwHAgMPbEdmbOvqy4O0adg" uri="guidances/checklists/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_nC-xEfL5Edm6Nvont3uinw" id="_4LuPMMPcEdmbOvqy4O0adg" uri="guidances/checklists/test_script.xmi"/>
+ <resourceDescriptors xmi:id="_nDE3sPL5Edm6Nvont3uinw" id="_y-_PIMPdEdmbOvqy4O0adg" uri="guidances/concepts/types_of_test.xmi"/>
+ <resourceDescriptors xmi:id="_nDK-UvL5Edm6Nvont3uinw" id="_BcBR8KX5EdmvhNXG0Oc2uA" uri="workproducts/iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDRE8vL5Edm6Nvont3uinw" id="_71hDkMPgEdmbOvqy4O0adg" uri="guidances/guidelines/iteration_planning.xmi"/>
+ <resourceDescriptors xmi:id="_nDRE8_L5Edm6Nvont3uinw" id="_Fdq-8KX4EdmvhNXG0Oc2uA" uri="roles/project_manager.xmi"/>
+ <resourceDescriptors xmi:id="_nDXLkPL5Edm6Nvont3uinw" id="_IbVp8KX4EdmvhNXG0Oc2uA" uri="workproducts/project_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDXLkfL5Edm6Nvont3uinw" id="_K-e8IKX4EdmvhNXG0Oc2uA" uri="workproducts/status_assessment.xmi"/>
+ <resourceDescriptors xmi:id="_nDjY0PL5Edm6Nvont3uinw" id="_u6enMMM1EdmSIPI87WLu3g" uri="guidances/concepts/risk.xmi"/>
+ <resourceDescriptors xmi:id="_nDqGgPL5Edm6Nvont3uinw" id="_Dfmk8MPiEdmbOvqy4O0adg" uri="guidances/concepts/workspace.xmi"/>
+ <resourceDescriptors xmi:id="_nDqGg_L5Edm6Nvont3uinw" id="_LxX6AMM2EdmSIPI87WLu3g" uri="guidances/templates/vision.xmi"/>
+ <resourceDescriptors xmi:id="_nDqGhPL5Edm6Nvont3uinw" id="_OaB-UMM2EdmSIPI87WLu3g" uri="guidances/templates/uc_specification.xmi"/>
+ <resourceDescriptors xmi:id="_nDwNIPL5Edm6Nvont3uinw" id="_XjOXcMM2EdmSIPI87WLu3g" uri="guidances/templates/project_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDwNIfL5Edm6Nvont3uinw" id="_Z_bUIMM2EdmSIPI87WLu3g" uri="guidances/templates/iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_nDwNI_L5Edm6Nvont3uinw" id="_fJPGkMM2EdmSIPI87WLu3g" uri="guidances/templates/software_arch_document.xmi"/>
+ <resourceDescriptors xmi:id="_nD2TwPL5Edm6Nvont3uinw" id="_j2pQ4MM2EdmSIPI87WLu3g" uri="guidances/templates/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_nD2Tw_L5Edm6Nvont3uinw" id="_NqqcUqeqEdmKDbQuyzCoqQ" uri="roles/any_role.xmi"/>
+ <resourceDescriptors xmi:id="_nEzWAfL5Edm6Nvont3uinw" id="_Nqwi8KeqEdmKDbQuyzCoqQ" uri="tasks/detail_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_nGJZ0PL5Edm6Nvont3uinw" id="_5rJ78Lj3Edmy88CC3LfB_w" uri="tasks/define_vision.xmi"/>
+ <resourceDescriptors xmi:id="_nGJZ0vL5Edm6Nvont3uinw" id="_NrC20qeqEdmKDbQuyzCoqQ" uri="tasks/design_solution.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgcPL5Edm6Nvont3uinw" id="_qDRSULBKEdm7Eph_l9Cn9w" uri="tasks/analyze_arch_reqs.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgcfL5Edm6Nvont3uinw" id="_rUis8LBKEdm7Eph_l9Cn9w" uri="tasks/develop_arch.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgcvL5Edm6Nvont3uinw" id="_S8KCcMP2EdmWKcx6ixEiwg" uri="guidances/concepts/analysis_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_nGPgdfL5Edm6Nvont3uinw" id="_d2aMwKrMEdmqUqi7YGiSxw" uri="tasks/implement_solution.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnEPL5Edm6Nvont3uinw" id="_dWPe8KrMEdmqUqi7YGiSxw" uri="tasks/impl_developer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnEfL5Edm6Nvont3uinw" id="_W6rc0Lv7EdmmUvZAZjqE3g" uri="tasks/run_developer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnFPL5Edm6Nvont3uinw" id="_NrVKsKeqEdmKDbQuyzCoqQ" uri="tasks/create_test_cases.xmi"/>
+ <resourceDescriptors xmi:id="_nGVnFfL5Edm6Nvont3uinw" id="_NrbRUKeqEdmKDbQuyzCoqQ" uri="tasks/implement_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGbtsPL5Edm6Nvont3uinw" id="_NrbRUqeqEdmKDbQuyzCoqQ" uri="tasks/run_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nGbtsfL5Edm6Nvont3uinw" id="_uqL2gMM3EdmSIPI87WLu3g" uri="guidances/concepts/test_ideas.xmi"/>
+ <resourceDescriptors xmi:id="_nGbttPL5Edm6Nvont3uinw" id="_Wk7noKe1EdmGSrcKGOYDGg" uri="tasks/plan_iteration.xmi"/>
+ <resourceDescriptors xmi:id="_nGh0UfL5Edm6Nvont3uinw" id="_fPbdIKe2Edmzde8VFK5bxg" uri="tasks/plan_the_project.xmi"/>
+ <resourceDescriptors xmi:id="_nGh0VfL5Edm6Nvont3uinw" id="_a3uz4LBYEdm7Eph_l9Cn9w" uri="tasks/assess_results.xmi"/>
+ <resourceDescriptors xmi:id="_nGn68PL5Edm6Nvont3uinw" id="_7ygXoMM3EdmSIPI87WLu3g" uri="guidances/concepts/metrics.xmi"/>
+ <resourceDescriptors xmi:id="_nGuBkPL5Edm6Nvont3uinw" id="_Nr0S4KeqEdmKDbQuyzCoqQ" uri="tasks/request_change.xmi"/>
+ <resourceDescriptors xmi:id="_nG6O0_L5Edm6Nvont3uinw" id="_0nJNkclgEdmt3adZL5Dmdw" uri="capabilitypatterns/manage_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVcfL5Edm6Nvont3uinw" id="_0nz79MlgEdmt3adZL5Dmdw" uri="capabilitypatterns/test/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVcvL5Edm6Nvont3uinw" id="_0oSdEclgEdmt3adZL5Dmdw" uri="capabilitypatterns/inception_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVc_L5Edm6Nvont3uinw" id="_0o9ygMlgEdmt3adZL5Dmdw" uri="capabilitypatterns/manage_requirements/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVdPL5Edm6Nvont3uinw" id="_0pJ_xclgEdmt3adZL5Dmdw" uri="capabilitypatterns/ongoing_tasks/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHAVdfL5Edm6Nvont3uinw" id="_0pWNAslgEdmt3adZL5Dmdw" uri="capabilitypatterns/initiate_project/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHGcEfL5Edm6Nvont3uinw" id="_0qrpwMlgEdmt3adZL5Dmdw" uri="capabilitypatterns/transition_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHGcEvL5Edm6Nvont3uinw" id="_0rWYIMlgEdmt3adZL5Dmdw" uri="capabilitypatterns/elaboration_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHGcFPL5Edm6Nvont3uinw" id="_0sluQclgEdmt3adZL5Dmdw" uri="capabilitypatterns/determine_architectural_feasibility/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHMisPL5Edm6Nvont3uinw" id="_0sx7iclgEdmt3adZL5Dmdw" uri="capabilitypatterns/define_architecture/model.xmi"/>
+ <resourceDescriptors xmi:id="_nHSpUPL5Edm6Nvont3uinw" id="_0uHYQclgEdmt3adZL5Dmdw" uri="deliveryprocesses/openup_basic_process/model.xmi"/>
+ <resourceDescriptors xmi:id="_nt4IMfL5Edm6Nvont3uinw" id="_s60KoMM3EdmSIPI87WLu3g" uri="guidances/guidelines/test_suite.xmi"/>
+ <resourceDescriptors xmi:id="_nuo9MPL5Edm6Nvont3uinw" id="_On0agNSAEdmLhZ9H5Plxyw" uri="guidances/guidelines/req_gathering_techniques.xmi"/>
+ <resourceDescriptors xmi:id="_nuo9MvL5Edm6Nvont3uinw" id="_iCwb8MM3EdmSIPI87WLu3g" uri="guidances/guidelines/repres_interfaces_to_ext_systems.xmi"/>
+ <resourceDescriptors xmi:id="_nuo9M_L5Edm6Nvont3uinw" id="_lbGQwMM3EdmSIPI87WLu3g" uri="guidances/guidelines/layering.xmi"/>
+ <resourceDescriptors xmi:id="_nu1KcPL5Edm6Nvont3uinw" id="_qS8JcMM3EdmSIPI87WLu3g" uri="guidances/guidelines/failure_analysis_rpt_creation.xmi"/>
+ <resourceDescriptors xmi:id="_nu7REPL5Edm6Nvont3uinw" id="_y3rxsMM3EdmSIPI87WLu3g" uri="guidances/guidelines/test_ideas.xmi"/>
+ <resourceDescriptors xmi:id="_nu7REfL5Edm6Nvont3uinw" id="_vuwC4MPcEdmbOvqy4O0adg" uri="guidances/guidelines/programming_automated_tests.xmi"/>
+ <resourceDescriptors xmi:id="_nu7REvL5Edm6Nvont3uinw" id="_8ngBgMPdEdmbOvqy4O0adg" uri="guidances/guidelines/maintaining_automated_test_suite.xmi"/>
+ <resourceDescriptors xmi:id="_QATTEPV_EdmdHa9MmVPgqQ" id="_P9iS8PV_EdmdHa9MmVPgqQ" uri="tasks/find_and_outline_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_h3jw0PimEdmugcVr9AdHjQ" id="_h2-iAPimEdmugcVr9AdHjQ" uri="capabilitypatterns/develop_solution/model.xmi"/>
+ <resourceDescriptors xmi:id="_AaS4AP1VEdmek8CQTQgrOQ" id="_AYGfoP1VEdmek8CQTQgrOQ" uri="disciplinegroupings/openup_basic_disciplines.xmi"/>
+ <resourceDescriptors xmi:id="_CY764BEdEdqY7JB6N6CW2w" id="_CYRMgBEdEdqY7JB6N6CW2w" uri="guidances/guidelines/agile_estimation.xmi"/>
+ <resourceDescriptors xmi:id="_g5NaAB85Edqsvps02rpOOg" id="-aCI9T-9TIe8D35yXBU6qvg" uri="guidances/supportingmaterials/references.xmi"/>
+ <resourceDescriptors xmi:id="_t_ZKUCbSEdqh1LYUOGRh2A" id="-buxz4BVToq97bSxaqyjySg" uri="workproducts/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_8UFwQCbYEdqh1LYUOGRh2A" id="-PbfqVxB_j9KN-Jx39_pEUA" uri="tasks/manage_iteration.xmi"/>
+ <resourceDescriptors xmi:id="_89PC0Cb3Edqh1LYUOGRh2A" id="-BsXK3ZGMm-mUT0KnkdoYBg" uri="guidances/concepts/change_requests.xmi"/>
+ <resourceDescriptors xmi:id="_jtUSACu-EdqSxKAVa9kmvA" id="-Rcm_MlViENAvFFyIe9V3dQ" uri="guidances/guidelines/find_and_outline_actors_and_ucs.xmi"/>
+ <resourceDescriptors xmi:id="_7ymQsCxSEdqjsdw1QLH_6Q" id="-78ko4CuOJERKJF9ZvwMUBQ" uri="guidances/guidelines/detail_ucs_and_scenarios.xmi"/>
+ <resourceDescriptors xmi:id="_8XiwQDz6Edq03rqPoNVoKg" id="-5S6ney_fFdEHm49XznPRiA" uri="workproducttypes/assessment.xmi"/>
+ <resourceDescriptors xmi:id="_DK-L4Dz7Edq03rqPoNVoKg" id="-Nl-rJ_6aaAG2jpJyGm_wcg" uri="workproducttypes/concept.xmi"/>
+ <resourceDescriptors xmi:id="_MQnhwTz7Edq03rqPoNVoKg" id="-CKZiRxRx_TZhMbquLd4Sqw" uri="workproducttypes/infrastructure.xmi"/>
+ <resourceDescriptors xmi:id="_Sxgb4Dz7Edq03rqPoNVoKg" id="-ARfZUsgYE1XrKQlDgr9mEQ" uri="workproducttypes/model.xmi"/>
+ <resourceDescriptors xmi:id="_Wp1YUDz7Edq03rqPoNVoKg" id="-cW3aVzDjHhqkVayoItUQqw" uri="workproducttypes/model_element.xmi"/>
+ <resourceDescriptors xmi:id="_hOtFQDz7Edq03rqPoNVoKg" id="-vpMAMS8Cz-z9DQQhxbjjLA" uri="workproducttypes/plan.xmi"/>
+ <resourceDescriptors xmi:id="_mDSOkDz7Edq03rqPoNVoKg" id="-DBPx56p4GCNFpRTT8uOmiQ" uri="workproducttypes/project_data.xmi"/>
+ <resourceDescriptors xmi:id="_tJVrQDz7Edq03rqPoNVoKg" id="-sIh01vzZACgxRrG_sv7DVw" uri="workproducttypes/solution.xmi"/>
+ <resourceDescriptors xmi:id="_69Xb0Dz7Edq03rqPoNVoKg" id="-C5ih3s1Vn_9qQbjm85-GYg" uri="workproducttypes/specification.xmi"/>
+ <resourceDescriptors xmi:id="_bL9KAL3vEdqLRJZPGVbHDA" id="-_BAmniONtHWbpHQH7znR3g" uri="tasks/design_solution_vm.xmi"/>
+ <resourceDescriptors xmi:id="_x-s5sMWdEdqiT9CqkRksWQ" id="-15BvSftWbF7VdZ_W8YycBQ" uri="domains/openup_basic_wp.xmi"/>
+ <resourceDescriptors xmi:id="_aIutoMWeEdqiT9CqkRksWQ" id="-9qPK9k01PN_COE9YPXpw8Q" uri="domains/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_2zkhcMWeEdqiT9CqkRksWQ" id="-X9nP8esP9nWMvx1wmMaJAA" uri="domains/change_management.xmi"/>
+ <resourceDescriptors xmi:id="_Lp3a4cWfEdqiT9CqkRksWQ" id="-xO3vqWsd3W98UXFsyp-wGA" uri="domains/development.xmi"/>
+ <resourceDescriptors xmi:id="_WlKDwcWfEdqiT9CqkRksWQ" id="-N4r_U0LZhZ_K-8gfHON9BA" uri="domains/project_management.xmi"/>
+ <resourceDescriptors xmi:id="_kGPDIcWfEdqiT9CqkRksWQ" id="-d5O4LFNaAs4YRDxfxH3CRw" uri="domains/requirements.xmi"/>
+ <resourceDescriptors xmi:id="_tTZ9UcWfEdqiT9CqkRksWQ" id="-Mxgu9hq0upbMqZlq1xBFYw" uri="domains/test.xmi"/>
+ <resourceDescriptors xmi:id="_jHV4oNVbEdqy9sbRhejO5Q" id="-w7sImtXWkf4HDXdUWjRsUg" uri="guidances/guidelines/submitting_change_requests.xmi"/>
+ <resourceDescriptors xmi:id="_FFod4NVuEdqWcvghdb0qxA" id="-bUmvEAAtFf6B0aUCux8k9Q" uri="guidances/guidelines/assign_changes_to_iteration.xmi"/>
+ <resourceDescriptors xmi:id="_BaPxINb2Edq_LtLvi4w2yw" id="-CFYVionNDLkMw6SG6runQA" uri="guidances/guidelines/uc_realizations.xmi"/>
+ <resourceDescriptors xmi:id="_Bab-YNb2Edq_LtLvi4w2yw" id="-6ep_EyK3ZO6vRGWtAqoJ-A" uri="guidances/guidelines/design_components.xmi"/>
+ <resourceDescriptors xmi:id="_2soicNb2Edq_LtLvi4w2yw" id="-_dNuyh-0q5vpCiIiLfbj6w" uri="workproducts/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_kIZk4bUNEdqI644ssJaKYg" id="-0sCBiohjw_wBDKk0WEeDJQ" uri="guidances/termdefinitions/requirement.xmi"/>
+ <resourceDescriptors xmi:id="_BW4HgNcLEdqz_d2XWoVt6Q" id="-AJQLv2ldVv5KN9eUbdQe_g" uri="guidances/guidelines/writing_good_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_V7RtwNcNEdqz_d2XWoVt6Q" id="-pNA0DbSdSoUqnjQIiOeHcQ" uri="guidances/guidelines/effective_req_reviews.xmi"/>
+ <resourceDescriptors xmi:id="_ffK0QMvoEdqukPpotm3DYg" id="-aMD1wQVJLzzlMARfHBdOBQ" uri="guidances/concepts/core_principle_evolve.xmi"/>
+ <resourceDescriptors xmi:id="_PUrQsMvqEdqukPpotm3DYg" id="-I4IbR1GW6IFBCdq9SiMUsw" uri="guidances/concepts/core_principle_balance.xmi"/>
+ <resourceDescriptors xmi:id="_VIeQwMvpEdqukPpotm3DYg" id="-HTMJFV29MTZkKWqnIo01Gg" uri="guidances/concepts/core_principle_focus.xmi"/>
+ <resourceDescriptors xmi:id="_aV48scp8EdqC_NfSivunjA" id="-IXfkG-XfnoEo0xgux482Kw" uri="guidances/concepts/core_principle_collaborate.xmi"/>
+ <resourceDescriptors xmi:id="_jkD6kNohEdqJa75enFTwVQ" id="-XR2Rbg25yN80p1exWC4MHg" uri="guidances/supportingmaterials/openup_basic_home.xmi"/>
+ <resourceDescriptors xmi:id="_mfuHQN-vEdqiM_wFaqLjNg" id="-At_b3UIzbgdmtJsb2Ymfhg" uri="guidances/roadmaps/openup_basic_roadmap.xmi"/>
+ <resourceDescriptors xmi:id="_z-TykOtQEdqc1LGhiSPqRg" id="_y-etQOtQEdqc1LGhiSPqRg" uri="capabilitypatterns/construction_phase_iteration/model.xmi"/>
+ <resourceDescriptors xmi:id="_VyNPIOz3Edq2wJOsmRwmhg" id="-iOn7_gfX_iELWRNGJ2JKPQ" uri="workproducts/glossary.xmi"/>
+ <resourceDescriptors xmi:id="_BaLJYNbaEdqrw4BYKyYKiA" id="-FsyxZy4tyX8k5CxT5Jww_w" uri="guidances/templates/supporting_requirements_spec.xmi"/>
+ <resourceDescriptors xmi:id="_lXzjoOz6Edq2wJOsmRwmhg" id="-BQLZ5GRUNrMdU6XeZAfe9Q" uri="guidances/concepts/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_0nV8oNk1Edq2Q8qZoWbvGA" id="-T2IeqdOunweffIDgL-aM0w" uri="guidances/checklists/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_kjwkoO0HEdqHTdbLTmC5IQ" id="-2o1pXjHpSEPN_rohLce5jA" uri="guidances/checklists/good_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_WES08O0IEdqHTdbLTmC5IQ" id="-3SXuKijeVOZalgLPgWRyFA" uri="guidances/concepts/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_1kU3wO0JEdqHTdbLTmC5IQ" id="-Q72-dNdHnZ93aRXAB_d34A" uri="guidances/guidelines/requirement_pitfalls.xmi"/>
+ <resourceDescriptors xmi:id="_V1DNIO0KEdqHTdbLTmC5IQ" id="-fCBrf_5JlrmuKgyrCaKGOA" uri="guidances/concepts/requirement_attributes.xmi"/>
+ <resourceDescriptors xmi:id="_e_SvIO0KEdqHTdbLTmC5IQ" id="-TksCtMgc0b4QqzwzniGvIw" uri="guidances/concepts/traceability.xmi"/>
+ <resourceDescriptors xmi:id="_gc724PDxEdqYgerqi84oCA" id="-awaQ_2dwhGyKRoVKQ-esPQ" uri="guidances/concepts/entity_control_boundary_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_B5BhQPD0EdqYgerqi84oCA" id="-dhAMzNZNWufBnW0fPYQtBA" uri="guidances/concepts/continuous_integration.xmi"/>
+ <resourceDescriptors xmi:id="_svkl0PD0EdqYgerqi84oCA" id="-DlaqJu4sEqMPk84qhJ6IEA" uri="guidances/guidelines/continuous_integration.xmi"/>
+ <resourceDescriptors xmi:id="_2buasPD3EdqYgerqi84oCA" id="-zCM2ucJJxc_bQr_LoHlSaQ" uri="guidances/guidelines/promoting_builds.xmi"/>
+ <resourceDescriptors xmi:id="_I6hwsPGaEdqiDINUyockoA" id="-WFD3nKccpkueaG15cHT-fA" uri="guidances/supportingmaterials/about_openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_Uf9gUPvuEdqf0-top1XJIg" id="-xbAirPdH1IOKcnklk8hdqw" uri="roles/developer_vm.xmi"/>
+ <resourceDescriptors xmi:id="_dEVfgACsEdu8m4dIntu6jA" id="-HhGIkAPjHSIxnPzI3cyDnQ" uri="guidances/concepts/risk_management.xmi"/>
+ <resourceDescriptors xmi:id="_ePUlgAFoEduDPKiaP0pu-Q" id="-Yt8TXGkE1rwydXR34apsrg" uri="tasks/find_and_outline_requirements_intent_req_ucm.xmi"/>
+ <resourceDescriptors xmi:id="__WjDgAXmEduZUPWQRyV4zQ" id="-pQrBSyxJHLLodLbS4R_Zdw" uri="guidances/guidelines/use_case_formats.xmi"/>
+ <resourceDescriptors xmi:id="_VbT-cAeYEduWycDgioo5rg" id="-qpBnpWqiD7gjT08LjTMbsQ" uri="guidances/termdefinitions/feature.xmi"/>
+ <resourceDescriptors xmi:id="_d1sJwQeYEduWycDgioo5rg" id="-1pmL5bC27rtWB84PXAgq9Q" uri="guidances/termdefinitions/stakeholder_need.xmi"/>
+ <resourceDescriptors xmi:id="_-KDQoAhWEduRe8TeoBmuGg" id="-yEWkrWZ3VUcjZPhq6bvScg" uri="guidances/concepts/use_case_model.xmi"/>
+ <resourceDescriptors xmi:id="_43csUA3tEduibvKwrGxWxA" id="-YeVRerdEixh4HgHOuw2KRQ" uri="guidances/guidelines/analyze_arch_reqs.xmi"/>
+ <resourceDescriptors xmi:id="_ovE-8A4LEduibvKwrGxWxA" id="-SJrpVySJ2npYs8NwGvnHjw" uri="guidances/concepts/arch_mech.xmi"/>
+ <resourceDescriptors xmi:id="_xCNSwA4LEduibvKwrGxWxA" id="-EG22TRyJ5TDKW6U88AXfhw" uri="guidances/concepts/design_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_0XXQsA4LEduibvKwrGxWxA" id="-Rex8oOBv985RruZNrCW0rg" uri="guidances/concepts/implementation_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_4mCQkA4LEduibvKwrGxWxA" id="-CJ--jlBqXi3FzdOM_dw5_w" uri="guidances/guidelines/example_analysis_mechanisms_descr.xmi"/>
+ <resourceDescriptors xmi:id="_4mIXMA4LEduibvKwrGxWxA" id="-FqP5LgLVrlhvFC_eeYd_vA" uri="guidances/guidelines/example_architectural_mechanisms.xmi"/>
+ <resourceDescriptors xmi:id="_4mOd0A4LEduibvKwrGxWxA" id="-mAo18f36rZ1R98kpZX7HMw" uri="guidances/guidelines/example_design_mechanisms.xmi"/>
+ <resourceDescriptors xmi:id="_HsocQA4MEduibvKwrGxWxA" id="-EytH4BCNGiHF6pZrp8ISCw" uri="guidances/concepts/architecturally_significant_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_NqskoBOHEduCNqgZdt_OaA" id="-Ss8EBFGKz6PI_08BAjuUwQ" uri="customcategories/core_principles_cat.xmi"/>
+ <resourceDescriptors xmi:id="_eMOOgBONEduCNqgZdt_OaA" id="-GRJW_KNOJoEQF3r6lmBrEw" uri="guidances/concepts/inception_phase.xmi"/>
+ <resourceDescriptors xmi:id="_CyjSMBOOEduCNqgZdt_OaA" id="-F-eWIBzxEXE1jygbN3nrrQ" uri="guidances/concepts/elaboration_phase.xmi"/>
+ <resourceDescriptors xmi:id="_esJPQBOOEduCNqgZdt_OaA" id="-bbpT_BdDRrv6waNI365Qhg" uri="guidances/concepts/construction_phase.xmi"/>
+ <resourceDescriptors xmi:id="_B2T28ROPEduCNqgZdt_OaA" id="-FrUmsKsGW4bnNmb9uaNOkg" uri="guidances/concepts/transition_phase.xmi"/>
+ <resourceDescriptors xmi:id="_Z7gJgBapEduSTJywppIxVQ" id="-Of51hmgdsO_U2-pnbJ67Cg" uri="guidances/concepts/business_pattern.xmi"/>
+ <resourceDescriptors xmi:id="_nrMMoBapEduSTJywppIxVQ" id="-t7mQSRPYITkMoYRVNz7jQg" uri="guidances/guidelines/develop_architecture.xmi"/>
+ <resourceDescriptors xmi:id="_XSM3sBjoEduxUfEVCtmW4Q" id="-cy0DcnEk7uJJ1OOH3_E6rg" uri="guidances/supportingmaterials/delivery_process_graph.xmi"/>
+ <resourceDescriptors xmi:id="_BQ2N8CF7Edu3VKXZx45D3A" id="-BdYFG4-dbPBGFzF9z6KGPA" uri="guidances/guidelines/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_pyUo0CGMEdu3VKXZx45D3A" id="-kw2vYHKDkWv2tZrDMrBPNA" uri="guidances/checklists/supporting_requirements.xmi"/>
+ <resourceDescriptors xmi:id="_lZIzECcTEduSX6N2jUafGA" id="-RNyaB6jxqoopm9fJU8k9vg" uri="guidances/supportingmaterials/openup_copyright.xmi"/>
+ <resourceDescriptors xmi:id="_XcJIYCdCEduIsqH1Q6ZuqA" id="-4VJ_0upihz-bR7VRlm63Vw" uri="workproducts/risk_list.xmi"/>
+ <resourceDescriptors xmi:id="_o3qSICdEEduIsqH1Q6ZuqA" id="-DG8mYMnTGosWIxjPQFUoTA" uri="guidances/concepts/milestones.xmi"/>
+ <resourceDescriptors xmi:id="_9JydECk9EduLGM8dfVsrKg" id="-1Lm8-0FY-QIC56u5t2SC9w" uri="guidances/templates/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_ZXEuAClFEduLGM8dfVsrKg" id="-cnGBBA4NXmhTIjHjlHx4Mw" uri="guidances/guidelines/architectural_view.xmi"/>
+ <resourceDescriptors xmi:id="_2hWugClTEduLGM8dfVsrKg" id="-U-5cLUk-mdaO518lh5CxTQ" uri="guidances/guidelines/using_patterns.xmi"/>
+ <resourceDescriptors xmi:id="_DLM38ColEduK2emCyq5fBw" id="-X7QSjItNBz7w8603yBCv0Q" uri="guidances/guidelines/abstract_away_complexity.xmi"/>
+ <resourceDescriptors xmi:id="_XQS1oC5REduVhuZHT5jKZQ" id="-VGT8iHGtQSiOUGitq1qmow" uri="guidances/guidelines/types_of_developer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_dWGwgC8FEduzydamRseoUw" id="-OugFZJszm73z0_KSwRXZPw" uri="guidances/templates/risk_list.xmi"/>
+ <resourceDescriptors xmi:id="_TVGdwDBGEduMqpUNhaTSRA" id="-1xE2ZW3MjNAJ7jkaZNbkww" uri="guidances/guidelines/designing_visually.xmi"/>
+ <resourceDescriptors xmi:id="_i5pNMDFYEduMqpUNhaTSRA" id="-fj_9xjbrpaYNSETyCz5yJg" uri="guidances/concepts/refactoring.xmi"/>
+ <resourceDescriptors xmi:id="_JNr6YDIeEduDTv4Y1akVTA" id="-gqNN4DnROmJpgKtrdguhpg" uri="guidances/checklists/risk_list.xmi"/>
+ <resourceDescriptors xmi:id="__Fy8ATIrEduDTv4Y1akVTA" id="-945-1xTnAeJZR0Z9oYMJDA" uri="customcategories/getting_started.xmi"/>
+ <resourceDescriptors xmi:id="__GLWgTIrEduDTv4Y1akVTA" id="-kiltuUhgu5dbjVjvA3l_kg" uri="customcategories/about.xmi"/>
+ <resourceDescriptors xmi:id="__GRdIDIrEduDTv4Y1akVTA" id="-8uqXjzIOnt6LVDae6Uv_0w" uri="customcategories/openup_basic_views.xmi"/>
+ <resourceDescriptors xmi:id="__GXjwDIrEduDTv4Y1akVTA" id="-nY50CawHefla4zauYddVfw" uri="customcategories/openup_basic_deprecated.xmi"/>
+ <resourceDescriptors xmi:id="_HJ9fYDIvEduDTv4Y1akVTA" id="-vErMTo5DGQ1v_3_GNsccNw" uri="workproducts/design_vm%202.xmi"/>
+ <resourceDescriptors xmi:id="__wASEDRZEdudA-StyUUwnw" id="-SUqkkwrs1D_5YXZls-3YBg" uri="workproducts/supporting_requirements_intent_req.xmi"/>
+ <resourceDescriptors xmi:id="_nxdG4DRcEduFvfVCXiK3AA" id="-JcGDIeBIMM099mbWX5fXbA" uri="workproducts/use_case_intent_req.xmi"/>
+ <resourceDescriptors xmi:id="_7WIYYDg2Edu4E8ZdmlYjtA" id="-G1Oxlk6F0R09vClqy1EzOw" uri="guidances/guidelines/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_gTd74Dj9EduxovfWMDsntw" id="-mPA7vone29k1OvF_1rACjg" uri="guidances/templates/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_HU76YDkAEduxovfWMDsntw" id="-qunTPN3vqTIGpELwajXpLA" uri="guidances/examples/work_items_list.xmi"/>
+ <resourceDescriptors xmi:id="_WrOAgDkDEduxovfWMDsntw" id="-vi8wxwxVZLY0SMPFxZjD7A" uri="guidances/concepts/iteration.xmi"/>
+ <resourceDescriptors xmi:id="_HhqNQDn8Edu_y4hBImiwwQ" id="-fDVhZTkf1TqDyExbI9DM-w" uri="workproducts/work_items_list_pm.xmi"/>
+ <resourceDescriptors xmi:id="_wpM84Dn9EduEpvsDmUyxqg" id="-b9hejTMj8E7U4g2v80xDjA" uri="workproducts/iteration_plan_pm.xmi"/>
+ <resourceDescriptors xmi:id="_UItQgDoAEdusGsHODb-STA" id="-IdlCQXdDNYGrGJU4TBwvCA" uri="guidances/examples/project_plan.xmi"/>
+ <resourceDescriptors xmi:id="_eSrjED6TEduAL-bCqar_dg" id="-HQSI39vBrjpmQL1qHYOJtA" uri="guidances/checklists/design_vm.xmi"/>
+ <resourceDescriptors xmi:id="_FG9cgEE7EdulKujnGUuxbg" id="-nDr0XNiUWBo6VS1YS6KAqA" uri="guidances/examples/iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_eRfk4EcmEdu6ianenth5PQ" id="-Aw8p59vJ9rWsOV82rljQiQ" uri="guidances/reports/iteration_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_NmdiMEf7EduISP1GQDlvVQ" id="-_mfd9ziTwQV_5LE80jJw4g" uri="tasks/detail_requirements_intent_req_ucm.xmi"/>
+ <resourceDescriptors xmi:id="_TrtRwElyEducWJcS4yanqg" id="-VPoMu7qzVX9grE4-nB3kMw" uri="guidances/termdefinitions/configuration.xmi"/>
+ <resourceDescriptors xmi:id="_jtrgkElyEducWJcS4yanqg" id="-4iL0UEFR2Fg7oWkh1TymIg" uri="guidances/termdefinitions/version.xmi"/>
+ <resourceDescriptors xmi:id="_xoyz8EmbEdu0xduwSKie-w" id="-1ZoXO1IRfkXUKej4bNv8cw" uri="customcategories/sub_processes.xmi"/>
+ <resourceDescriptors xmi:id="_3JNIgEmbEdu0xduwSKie-w" id="-NMF-a9hwKjzWNfHzzseDYQ" uri="customcategories/collab_commun_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_FMk8oEmcEdu0xduwSKie-w" id="-QRnsN2e6IQlSMaRts-wFNw" uri="customcategories/intent_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_FMrDQEmcEdu0xduwSKie-w" id="-q8ubSlQ5miYcY1JXdj1fbQ" uri="customcategories/management_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_Mjm0kEmcEdu0xduwSKie-w" id="-qwWeiX7WrSVHSluBe-J7yw" uri="customcategories/solution_subprocess.xmi"/>
+ <resourceDescriptors xmi:id="_1BKVgEptEduVV9JixWe5Rw" id="-hrDndmFd0zexB0HNYX3gww" uri="guidances/reports/project_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_Id32wEp3Edup0IY9DKDPkg" id="-2uQACndDBzBhJC1sCmk5UA" uri="guidances/templates/status_assessment.xmi"/>
+ <resourceDescriptors xmi:id="_09MY8EyFEdu-df7p0PuRvQ" id="-XMbxFU8M85cRlf3C4iwAGw" uri="guidances/guidelines/data_modeling.xmi"/>
+ <resourceDescriptors xmi:id="_DMZa8EvIEdunZcj9T5hrMQ" id="-0g2jTHQla8lbP6xGB3iGlg" uri="guidances/termdefinitions/elaboration.xmi"/>
+ <resourceDescriptors xmi:id="_5QECwEvJEdunZcj9T5hrMQ" id="-MllWL01NL93RTB7VsY69fw" uri="guidances/termdefinitions/lca_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_TsOyAEvqEdunZcj9T5hrMQ" id="-9fXEOvMc4t7y6s5GscBD1Q" uri="guidances/termdefinitions/milestone.xmi"/>
+ <resourceDescriptors xmi:id="_iZ-GsEvHEdunZcj9T5hrMQ" id="-_G0VvVOdMoajk615LwFtxg" uri="guidances/termdefinitions/iteration.xmi"/>
+ <resourceDescriptors xmi:id="_5KcVYUvpEdunZcj9T5hrMQ" id="-yoFF90pq-_UV3fm-5oDenw" uri="guidances/termdefinitions/transition.xmi"/>
+ <resourceDescriptors xmi:id="_tgigkEvJEdunZcj9T5hrMQ" id="-Rl8kaRW9Bxqdvq32kVCi7w" uri="guidances/termdefinitions/lco_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_4dN4QEvDEdunZcj9T5hrMQ" id="-5wJmUR0WqX7lCIxsyqFsdA" uri="guidances/termdefinitions/construction.xmi"/>
+ <resourceDescriptors xmi:id="_EAp3gEvKEdunZcj9T5hrMQ" id="-gEgZg2UkFLjGeXkJLpAP6A" uri="guidances/termdefinitions/ioc_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_Nh-cwEvKEdunZcj9T5hrMQ" id="-JegYQHIteCRN0iV2EKMjSA" uri="guidances/termdefinitions/pr_milestone.xmi"/>
+ <resourceDescriptors xmi:id="_5qob4EvqEdunZcj9T5hrMQ" id="-qZE4XgeMK93LmJMKuQWGFg" uri="guidances/termdefinitions/agile.xmi"/>
+ <resourceDescriptors xmi:id="_D7dnwEvFEdunZcj9T5hrMQ" id="-dhgOQQ4GsV0-dNJmTmF9GA" uri="guidances/termdefinitions/inception.xmi"/>
+ <resourceDescriptors xmi:id="_hQyYcEvEEdunZcj9T5hrMQ" id="-vq2pL6yQuqGhql9Wo_Av4w" uri="guidances/termdefinitions/furps.xmi"/>
+ <resourceDescriptors xmi:id="_TgQIUUvmEdunZcj9T5hrMQ" id="-t3jNM5ZWkYtzB8A4Chz2Vw" uri="guidances/termdefinitions/use_case_scenario.xmi"/>
+ <resourceDescriptors xmi:id="_uzNYoUvlEdunZcj9T5hrMQ" id="-HDfMzDXoilK-f2iNreHRVg" uri="guidances/termdefinitions/use_case.xmi"/>
+ <resourceDescriptors xmi:id="_gjU_EUvQEdunZcj9T5hrMQ" id="-ketzwgDgY82DMyfuHqu3Cw" uri="guidances/termdefinitions/supporting_requirement.xmi"/>
+ <resourceDescriptors xmi:id="_Oz_loEvHEdunZcj9T5hrMQ" id="-VMnkFJpPLdEDUpbz2QDgow" uri="guidances/termdefinitions/vision.xmi"/>
+ <resourceDescriptors xmi:id="_nzyS8UvmEdunZcj9T5hrMQ" id="-UTrE64wEDJIC1FRUomEYDg" uri="guidances/termdefinitions/use_case_model.xmi"/>
+ <resourceDescriptors xmi:id="_cuUoIEvrEdunZcj9T5hrMQ" id="-05pn_DGdNui9qqwx46iKZQ" uri="guidances/termdefinitions/glossary.xmi"/>
+ <resourceDescriptors xmi:id="_5LUmUUvBEdunZcj9T5hrMQ" id="-4RQJzq_1URTZ5FGCBKnTIw" uri="guidances/termdefinitions/actor.xmi"/>
+ <resourceDescriptors xmi:id="_R2ylEEvDEdunZcj9T5hrMQ" id="-COrjB4k8Qtf6ZpPEcBNwpw" uri="guidances/termdefinitions/business_rule.xmi"/>
+ <resourceDescriptors xmi:id="_MGOxIUvCEdunZcj9T5hrMQ" id="-1RwpgmmY974S0YkxEOFDCw" uri="guidances/termdefinitions/analyst.xmi"/>
+ <resourceDescriptors xmi:id="_KbS1UEvuEdunZcj9T5hrMQ" id="-oShmMITo9RIi1AzACWI9vw" uri="guidances/termdefinitions/point.xmi"/>
+ <resourceDescriptors xmi:id="_Kl_0AEvvEdunZcj9T5hrMQ" id="-1Oc9t_TLaBgW_YLugZcq7w" uri="guidances/termdefinitions/work_item.xmi"/>
+ <resourceDescriptors xmi:id="_VEO_YEvtEdunZcj9T5hrMQ" id="-KQTbqDSJXR8KLBxIgGVquA" uri="guidances/termdefinitions/work_breakdown_structure.xmi"/>
+ <resourceDescriptors xmi:id="_qjj5oEvrEdunZcj9T5hrMQ" id="-hOtatvr8wIjqW8UD0MSGhQ" uri="guidances/termdefinitions/risk.xmi"/>
+ <resourceDescriptors xmi:id="_gdtuMUvvEdunZcj9T5hrMQ" id="-NNByAM5YsjCu39flaOSZtQ" uri="guidances/termdefinitions/project_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_RJ6pcUvuEdunZcj9T5hrMQ" id="-mgWkuUy3q0zzFaxE7DY1ag" uri="guidances/termdefinitions/velocity.xmi"/>
+ <resourceDescriptors xmi:id="_98ybUUvvEdunZcj9T5hrMQ" id="-3G3HV0opAmFWGxYgsD5AhA" uri="guidances/termdefinitions/iteration_burndown.xmi"/>
+ <resourceDescriptors xmi:id="_RPuOIEv8EdunZcj9T5hrMQ" id="-h1poMaxtQbmg6hD5772oVw" uri="guidances/termdefinitions/scope.xmi"/>
+ <resourceDescriptors xmi:id="_wVAzgEvuEdunZcj9T5hrMQ" id="-WIgtkwJN71D51FdcQs-TzQ" uri="guidances/termdefinitions/effort.xmi"/>
+ <resourceDescriptors xmi:id="_zbijkEvCEdunZcj9T5hrMQ" id="-2QB1bosN011CudkwZ0cn-g" uri="guidances/termdefinitions/architect.xmi"/>
+ <resourceDescriptors xmi:id="_J9kvoUvPEdunZcj9T5hrMQ" id="-802sCZ4lJcejyRbhLmkxkw" uri="guidances/termdefinitions/developer.xmi"/>
+ <resourceDescriptors xmi:id="_n2PogUvPEdunZcj9T5hrMQ" id="-6oW2YOnoWq_xPpmoil91KA" uri="guidances/termdefinitions/test_case.xmi"/>
+ <resourceDescriptors xmi:id="_beLg0UvpEdunZcj9T5hrMQ" id="-Wh-byAGHoy_gGry0Jq6VaA" uri="guidances/termdefinitions/build.xmi"/>
+ <resourceDescriptors xmi:id="_WK10YUvoEdunZcj9T5hrMQ" id="-VJBtRm2brEKpRlnLWNF8_g" uri="guidances/termdefinitions/pattern.xmi"/>
+ <resourceDescriptors xmi:id="_a7dNEUvPEdunZcj9T5hrMQ" id="-prQBbamJ4CLPywfEbyaPaA" uri="guidances/termdefinitions/tester.xmi"/>
+ <resourceDescriptors xmi:id="_kGVesUvDEdunZcj9T5hrMQ" id="-BWZsh3vKrqSOzfkBJmDTLA" uri="guidances/termdefinitions/component.xmi"/>
+ <resourceDescriptors xmi:id="_HKvSQUvoEdunZcj9T5hrMQ" id="-YMvJ5LwexkcVWWqLdm5-nQ" uri="guidances/termdefinitions/architecture.xmi"/>
+ <resourceDescriptors xmi:id="_aenL8UvCEdunZcj9T5hrMQ" id="-Vvwb6EupIB9kfSQ_mhjURA" uri="guidances/termdefinitions/architectural_mechanism.xmi"/>
+ <resourceDescriptors xmi:id="_q-5HYUvCEdunZcj9T5hrMQ" id="-0vih7gB84YYDheaH7jeYFQ" uri="guidances/termdefinitions/architectural_view.xmi"/>
+ <resourceDescriptors xmi:id="_hwX4sE_8Edu-kbBL8pBzSQ" id="-9gUpkUYqONF3x8UWwAO_zw" uri="guidances/concepts/failure_analysis_rpt_creation%202.xmi"/>
+ <resourceDescriptors xmi:id="_jrhTMJjsEduad8I_c-ogIA" id="-HYO1lwAFOxlT7ncq8EjSng" uri="guidances/guidelines/staffing_project.xmi"/>
+ <resourceDescriptors xmi:id="_2IlrcJjsEduad8I_c-ogIA" id="-e26WOHRbTVQrDssK5zijVA" uri="guidances/guidelines/self_organize_work_assignments.xmi"/>
+ <resourceDescriptors xmi:id="_FnGbYJqvEdukqcRKZBQN9w" id="-Ff1JwbrGt1laexkOB6ZM1Q" uri="guidances/concepts/developer_testing.xmi"/>
+ <resourceDescriptors xmi:id="_NYFZcJt1EdutoZjlV3a4Lg" id="-RlYzPnl6Pig2H851hHebBA" uri="guidances/termdefinitions/code_instrumentation.xmi"/>
+ <resourceDescriptors xmi:id="_WFzxwKrPEdu6T6WyNqBzqQ" id="-zfl87vJBFdinDB02ArLXOQ" uri="guidances/concepts/component_vm.xmi"/>
+ <resourceDescriptors xmi:id="_lQP7EKzREduOqvpk_MDLfQ" id="-PZ0CqCcJHB-nbxs8fbP7bg" uri="guidances/supportingmaterials/copyright_oup.xmi"/>
+ <resourceDescriptors xmi:id="_ixQNMK__EduMeuOwJ2MpeQ" id="-KCSbXYv5TALlL00zMMfgVw" uri="guidances/guidelines/openup_and_openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_IQhrEbAAEduMeuOwJ2MpeQ" id="-l-ZsqrXu2nmVE1giLpI6iw" uri="guidances/guidelines/agile_and_unified.xmi"/>
+ <resourceDescriptors xmi:id="_VPIPILcJEduRNaXpzCOLXQ" id="-OcMsciNn-UtD9fTHj26LGA" uri="guidances/guidelines/abstract_away_complexity_vm.xmi"/>
+ <resourceDescriptors xmi:id="_BwXDIMDqEduTGJ8i4u8TMw" id="-aN0zy068ovKHgmkkoYqoYQ" uri="guidances/concepts/actor.xmi"/>
+ <resourceDescriptors xmi:id="_FdKesMEvEduwZvIr61GnNg" id="-Mobjz86dw07NW5-IhtEoNA" uri="guidances/guidelines/openup_iterations.xmi"/>
+ <resourceDescriptors xmi:id="_rKMEsMEvEduwZvIr61GnNg" id="-clUV9n59dDwg0e1VCcsB8Q" uri="guidances/guidelines/openup_architecture.xmi"/>
+ <resourceDescriptors xmi:id="_GU3Q0MExEduwZvIr61GnNg" id="-_BjYXvrfe1HHL5Y_QBfh4Q" uri="guidances/guidelines/openup_risk.xmi"/>
+ <resourceDescriptors xmi:id="_CPn-wMNrEdu2IdAIaWZyAw" id="-JviMIao63C7w9C8W6iPJrw" uri="guidances/examples/uc_model_evolve.xmi"/>
+ <resourceDescriptors xmi:id="_7KWL4MNvEdu2IdAIaWZyAw" id="-qq-9Brh5oa6H3lsdp-m8mQ" uri="guidances/examples/use_case_spec.xmi"/>
+ <resourceDescriptors xmi:id="_prz9sMUKEdu5GrwIlTJV7g" id="-I-2SvZtjELUYDQO0jvdxEA" uri="guidances/guidelines/analyze_arch_reqs_vm.xmi"/>
+ <resourceDescriptors xmi:id="_YI8eEMVxEduLYZUGfgZrkQ" id="-UQ_e8kozIP11Xu008RJd-A" uri="guidances/concepts/software_architecture.xmi"/>
+ <resourceDescriptors xmi:id="_Nm8sQMXwEduywMSzPTUUwA" id="-TfxeHO_AJxYCzXVva0kSzQ" uri="customcategories/introduction_to_openup_basic.xmi"/>
+ <resourceDescriptors xmi:id="_UDRPccXwEduywMSzPTUUwA" id="-I2j8LuHkworb0Y3EIlWfDQ" uri="customcategories/core_principles_category.xmi"/>
+ <resourceDescriptors xmi:id="__d1xocXxEduywMSzPTUUwA" id="-zy1Q3NXKXbiCP_zrjTxwaQ" uri="customcategories/getting_started_with_openup.xmi"/>
+ <resourceDescriptors xmi:id="_SEaRgMqPEduwrYVlQ9zp3w" id="-vlYpfwIYlF_ZCk5s4Dsqdg" uri="guidances/concepts/coding_standard.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_0TLvwMlgEdmt3adZL5Dmdw" name="openup_basic" guid="_0TLvwMlgEdmt3adZL5Dmdw" briefDescription="The OpenUP/Basic is an iterative software development process that is minimal, complete, and extensible." changeDate="2005-07-25T11:30:48.309-0700">
+ <copyrightStatement href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uuunoPsDEdmyhNQr5STrZQ"/>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2YMlgEdmt3adZL5Dmdw" name="Content" guid="_0TR2YMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2YclgEdmt3adZL5Dmdw" name="Categories" guid="_0TR2YclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2YslgEdmt3adZL5Dmdw" name="Domains" guid="_0TR2YslgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Domain" xmi:id="_s4Z9AMWXEdqWePvIjHInwg" name="openup_basic_wp" guid="_s4Z9AMWXEdqWePvIjHInwg" briefDescription="This is the list of domains in OpenUp/Basic providing organization of work products." presentationName="OpenUP/Basic Work Products">
+ <presentation xmi:id="-15BvSftWbF7VdZ_W8YycBQ" href="uma://-15BvSftWbF7VdZ_W8YycBQ#-15BvSftWbF7VdZ_W8YycBQ"/>
+ <subdomains xmi:id="_xITr8MWXEdqWePvIjHInwg" name="architecture" guid="_xITr8MWXEdqWePvIjHInwg" briefDescription="This is the list of work products related to architecture domain." presentationName="Architecture" workProducts="_0XAf0MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-9qPK9k01PN_COE9YPXpw8Q" href="uma://-9qPK9k01PN_COE9YPXpw8Q#-9qPK9k01PN_COE9YPXpw8Q"/>
+ </subdomains>
+ <subdomains xmi:id="_vUzp0MWeEdqiT9CqkRksWQ" name="change_management" guid="_vUzp0MWeEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to change management domain." presentationName="Change Management">
+ <presentation xmi:id="-X9nP8esP9nWMvx1wmMaJAA" href="uma://-X9nP8esP9nWMvx1wmMaJAA#-X9nP8esP9nWMvx1wmMaJAA"/>
+ </subdomains>
+ <subdomains xmi:id="_A9k3UMWfEdqiT9CqkRksWQ" name="development" guid="_A9k3UMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to development domain." presentationName="Development" workProducts="_ZTGAYL3uEdqLRJZPGVbHDA _0YuXEMlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw _0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-xO3vqWsd3W98UXFsyp-wGA" href="uma://-xO3vqWsd3W98UXFsyp-wGA#-xO3vqWsd3W98UXFsyp-wGA"/>
+ </subdomains>
+ <subdomains xmi:id="_QxjGYMWfEdqiT9CqkRksWQ" name="project_management" guid="_QxjGYMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to project management domain." presentationName="Project Management" workProducts="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _0bA2EMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA">
+ <presentation xmi:id="-N4r_U0LZhZ_K-8gfHON9BA" href="uma://-N4r_U0LZhZ_K-8gfHON9BA#-N4r_U0LZhZ_K-8gfHON9BA"/>
+ </subdomains>
+ <subdomains xmi:id="_allMQMWfEdqiT9CqkRksWQ" name="requirements" guid="_allMQMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to requirements domain." presentationName="Requirements" workProducts="_BVh9cL-CEdqb7N6KIeDL8Q _0WVxcMlgEdmt3adZL5Dmdw _0VGbUMlgEdmt3adZL5Dmdw _Wn7HcNcEEdqz_d2XWoVt6Q _W2SgEDR5EdutE_HNDTJk5Q">
+ <presentation xmi:id="-d5O4LFNaAs4YRDxfxH3CRw" href="uma://-d5O4LFNaAs4YRDxfxH3CRw#-d5O4LFNaAs4YRDxfxH3CRw"/>
+ </subdomains>
+ <subdomains xmi:id="_ou4CMMWfEdqiT9CqkRksWQ" name="test" guid="_ou4CMMWfEdqiT9CqkRksWQ" briefDescription="This is the list of work products related to test domain." presentationName="Test" workProducts="_0ZS-0MlgEdmt3adZL5Dmdw _0ZlSsMlgEdmt3adZL5Dmdw _0ZfMEMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-Mxgu9hq0upbMqZlq1xBFYw" href="uma://-Mxgu9hq0upbMqZlq1xBFYw#-Mxgu9hq0upbMqZlq1xBFYw"/>
+ </subdomains>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0TR2Y8lgEdmt3adZL5Dmdw" name="Disciplines" guid="_0TR2Y8lgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TR2ZMlgEdmt3adZL5Dmdw" name="requirements" guid="_0TR2ZMlgEdmt3adZL5Dmdw" briefDescription="This discipline defines the minimal tasks required to elicit, analyze, specify, validate and manage the requirements for the system to be developed." presentationName="Requirements" conceptsAndPapers="_VXZ5wO0IEdqHTdbLTmC5IQ _KudM0NcJEdqz_d2XWoVt6Q _VQ268O0KEdqHTdbLTmC5IQ _0Wh-sMlgEdmt3adZL5Dmdw _eYtQQO0KEdqHTdbLTmC5IQ _2jyfUAhVEduRe8TeoBmuGg _zGqO0MDpEduTGJ8i4u8TMw" checklists="_jxn9EO0HEdqHTdbLTmC5IQ _0WoFUMlgEdmt3adZL5Dmdw _0U6OEMlgEdmt3adZL5Dmdw _Vael8CGMEdu3VKXZx45D3A _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_4BJ_YCxSEdqjsdw1QLH_6Q _E-dPIL-GEdqb7N6KIeDL8Q _eyL0wCu-EdqSxKAVa9kmvA _OnoNQNSAEdmLhZ9H5Plxyw _1AOsMO0JEdqHTdbLTmC5IQ _wr24gNcGEdqz_d2XWoVt6Q _qq0GMAXkEduj_7BEUj1JfQ _6jXzYNcKEdqz_d2XWoVt6Q _0VAUsMlgEdmt3adZL5Dmdw" tasks="_0fOAoMlgEdmt3adZL5Dmdw _0e1mIMlgEdmt3adZL5Dmdw _P9cMUPV_EdmdHa9MmVPgqQ">
+ <presentation xmi:id="__rFCULv9EdmmUvZAZjqE3g" href="uma://__rFCULv9EdmmUvZAZjqE3g#__rFCULv9EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNA8lgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TX9AMlgEdmt3adZL5Dmdw" name="analysis_and_design" guid="_0TX9AMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to create a design from requirements that can be implemented by developers." presentationName="Analysis & Design" conceptsAndPapers="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _Z53x0BapEduSTJywppIxVQ _0YP18MlgEdmt3adZL5Dmdw _w2ACwA4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw _0XY6UMlgEdmt3adZL5Dmdw _uF-QYEAhEdq_UJTvM1DM2Q" checklists="_17PYUNd6EdmIm-bsRSNCgw _0XSzsMlgEdmt3adZL5Dmdw" guidelines="_we3F4ACpEdu8m4dIntu6jA _T9nygClEEduLGM8dfVsrKg _mDf2EBapEduSTJywppIxVQ _0gpkAMlgEdmt3adZL5Dmdw _0gjdYMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA _42UD4A3tEduibvKwrGxWxA _0X3bcMlgEdmt3adZL5Dmdw _ienXEEyAEdu-df7p0PuRvQ _CFAswNbzEdqu5o2S60g5LA _1fM3AC9_EduW5uTjiIcspQ _2uan8NbyEdqu5o2S60g5LA" tasks="_0f-1oMlgEdmt3adZL5Dmdw _0gRJgMlgEdmt3adZL5Dmdw _0fshwMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_Bbq2MLv-EdmmUvZAZjqE3g" href="uma://_Bbq2MLv-EdmmUvZAZjqE3g#_Bbq2MLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TeDoMlgEdmt3adZL5Dmdw" name="implementation" guid="_0TeDoMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to implement a technical solution that conforms to the design, works within the architecture and supports the requirements." presentationName="Implementation" conceptsAndPapers="_B3xkEPD0EdqYgerqi84oCA _aFeZgJquEdukqcRKZBQN9w _0Y6kUMlgEdmt3adZL5Dmdw _Poc7IPDzEdqYgerqi84oCA _0lnRMMqOEduwrYVlQ9zp3w" guidelines="_0Y0dsMlgEdmt3adZL5Dmdw _eRutgC5QEduVhuZHT5jKZQ _i8bUEL6cEdqti4GwqTkbsQ _SM4YIL6dEdqti4GwqTkbsQ" tasks="_0iL1EMlgEdmt3adZL5Dmdw _0hyzgMlgEdmt3adZL5Dmdw _0iYCUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_D5dHQLv-EdmmUvZAZjqE3g" href="uma://_D5dHQLv-EdmmUvZAZjqE3g#_D5dHQLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TkKQMlgEdmt3adZL5Dmdw" name="test" guid="_0TkKQMlgEdmt3adZL5Dmdw" briefDescription="This discipline defines the minimal set of tasks required to plan, implement, run and evaluate the testing of a system." presentationName="Test" conceptsAndPapers="_0jnYcMlgEdmt3adZL5Dmdw _0aJ6cMlgEdmt3adZL5Dmdw _0jhR0MlgEdmt3adZL5Dmdw" checklists="_0Zxf8MlgEdmt3adZL5Dmdw _0Z9tMMlgEdmt3adZL5Dmdw" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0jzlsMlgEdmt3adZL5Dmdw _0aDz0MlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw" tasks="_0iwc0clgEdmt3adZL5Dmdw _0jVEkMlgEdmt3adZL5Dmdw _0jO98MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_FuQswLv-EdmmUvZAZjqE3g" href="uma://_FuQswLv-EdmmUvZAZjqE3g#_FuQswLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ <referenceWorkflows href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TqQ4MlgEdmt3adZL5Dmdw" name="project_management" guid="_0TqQ4MlgEdmt3adZL5Dmdw" presentationName="Project Management" tasks="_0l53cMlgEdmt3adZL5Dmdw _0lC70MlgEdmt3adZL5Dmdw _0keUEMlgEdmt3adZL5Dmdw _8S2aICbYEdqh1LYUOGRh2A">
+ <presentation xmi:id="_GybfgLv-EdmmUvZAZjqE3g" href="uma://_GybfgLv-EdmmUvZAZjqE3g#_GybfgLv-EdmmUvZAZjqE3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_0TwXgMlgEdmt3adZL5Dmdw" name="config_and_change_management" guid="_0TwXgMlgEdmt3adZL5Dmdw" briefDescription="This discipline explains how to control changes to artifacts, ensuring a synchronized evolution of the set of Work Products composing a software system." presentationName="Configuration &amp; Change Management" conceptsAndPapers="_6jdvECb3Edqh1LYUOGRh2A _B3xkEPD0EdqYgerqi84oCA _0cEmAMlgEdmt3adZL5Dmdw" guidelines="_fnZj0NVXEdqy9sbRhejO5Q _i8bUEL6cEdqti4GwqTkbsQ _SM4YIL6dEdqti4GwqTkbsQ __yQQ4L6REdqti4GwqTkbsQ _7vEXEMA4EdqSgKaj2SZBmg" tasks="_0mwzEclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_H9TXMLv-EdmmUvZAZjqE3g" href="uma://_H9TXMLv-EdmmUvZAZjqE3g#_H9TXMLv-EdmmUvZAZjqE3g"/>
+ <referenceWorkflows href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:DisciplineGrouping" xmi:id="__BZycP1UEdmek8CQTQgrOQ" name="openup_basic_disciplines" guid="__BZycP1UEdmek8CQTQgrOQ" briefDescription="This is the list of disciplines in OpenUP/Basic providing organization of tasks." presentationName="OpenUP/Basic Disciplines" disciplines="_0TR2ZMlgEdmt3adZL5Dmdw _0TX9AMlgEdmt3adZL5Dmdw _0TeDoMlgEdmt3adZL5Dmdw _0TkKQMlgEdmt3adZL5Dmdw _0TqQ4MlgEdmt3adZL5Dmdw _0TwXgMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_AYGfoP1VEdmek8CQTQgrOQ" href="uma://_AYGfoP1VEdmek8CQTQgrOQ#_AYGfoP1VEdmek8CQTQgrOQ"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T2eIMlgEdmt3adZL5Dmdw" name="RoleSets" guid="_0T2eIMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_TZIJ0O8NEdmKSqa_gSYthg" name="openup_basic_roles" guid="_TZIJ0O8NEdmKSqa_gSYthg" briefDescription="This is the list of roles in OpenUP/Basic." presentationName="OpenUP/Basic Roles" roles="_0X9iEMlgEdmt3adZL5Dmdw _0a0o0MlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _0dsWoMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ">
+ <presentation xmi:id="_Tb5J8O8NEdmKSqa_gSYthg" href="uma://_Tb5J8O8NEdmKSqa_gSYthg#_Tb5J8O8NEdmKSqa_gSYthg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T2eIclgEdmt3adZL5Dmdw" name="WP Types" guid="_0T2eIclgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_2VBNIDz6Edq03rqPoNVoKg" name="assessment" guid="_2VBNIDz6Edq03rqPoNVoKg" briefDescription="These work products result from the analysis or evaluation of some particular aspect of the project, organization, business, or solution being developed. They are often used to determine the health of different aspects of the project or the organization." presentationName="Assessment" workProducts="_0bA2EMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-5S6ney_fFdEHm49XznPRiA" href="uma://-5S6ney_fFdEHm49XznPRiA#-5S6ney_fFdEHm49XznPRiA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_8XKVwDz6Edq03rqPoNVoKg" name="concept" guid="_8XKVwDz6Edq03rqPoNVoKg" briefDescription="These work products present an overview of key ideas or basic background information. They ensure that everyone on a project has a common understanding of these items." presentationName="Concept" workProducts="_0WVxcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-Nl-rJ_6aaAG2jpJyGm_wcg" href="uma://-Nl-rJ_6aaAG2jpJyGm_wcg#-Nl-rJ_6aaAG2jpJyGm_wcg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_EL6rgDz7Edq03rqPoNVoKg" name="infrastructure" guid="_EL6rgDz7Edq03rqPoNVoKg" briefDescription="These work products provide the required tools and technical environment to setup the required development infrastructure for a project." presentationName="Infrastructure">
+ <presentation xmi:id="-CKZiRxRx_TZhMbquLd4Sqw" href="uma://-CKZiRxRx_TZhMbquLd4Sqw#-CKZiRxRx_TZhMbquLd4Sqw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_MQbUgDz7Edq03rqPoNVoKg" name="model" guid="_MQbUgDz7Edq03rqPoNVoKg" briefDescription="These work products are a special kind of specification that are an abstract representation or simulation of a &quot;system&quot; that provides a complete description of the system from a particular perspective. Models are often used to gain a better understanding of how the system works or to document design decisions for the actual implementation. Models are often made up of several different kinds of parts, these parts are categorized as Model Elements." presentationName="Model" workProducts="_W2SgEDR5EdutE_HNDTJk5Q">
+ <presentation xmi:id="-ARfZUsgYE1XrKQlDgr9mEQ" href="uma://-ARfZUsgYE1XrKQlDgr9mEQ#-ARfZUsgYE1XrKQlDgr9mEQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_SxUOoDz7Edq03rqPoNVoKg" name="model_element" guid="_SxUOoDz7Edq03rqPoNVoKg" briefDescription="These work products are the individual parts that make-up a Model." presentationName="Model Element" workProducts="_0VGbUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-cW3aVzDjHhqkVayoItUQqw" href="uma://-cW3aVzDjHhqkVayoItUQqw#-cW3aVzDjHhqkVayoItUQqw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_ZR7b8Dz7Edq03rqPoNVoKg" name="plan" guid="_ZR7b8Dz7Edq03rqPoNVoKg" briefDescription="These work products provide a description of the means of achieving an objective. A successful project may include many different types of plans." presentationName="Plan" workProducts="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-vpMAMS8Cz-z9DQQhxbjjLA" href="uma://-vpMAMS8Cz-z9DQQhxbjjLA#-vpMAMS8Cz-z9DQQhxbjjLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_hOaxYDz7Edq03rqPoNVoKg" name="project_data" guid="_hOaxYDz7Edq03rqPoNVoKg" briefDescription="These work products identify the information that is used to manage the project. Collected information may either be kept as permanent records or used solely on an interim basis at a particular point in the project." presentationName="Project Data" workProducts="_rGNWsCbSEdqh1LYUOGRh2A _0ZlSsMlgEdmt3adZL5Dmdw _Ckay8Cc_EduIsqH1Q6ZuqA">
+ <presentation xmi:id="-DBPx56p4GCNFpRTT8uOmiQ" href="uma://-DBPx56p4GCNFpRTT8uOmiQ#-DBPx56p4GCNFpRTT8uOmiQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_mC_6sDz7Edq03rqPoNVoKg" name="solution" guid="_mC_6sDz7Edq03rqPoNVoKg" briefDescription="These work products consist of those that are part of the overall solution or product, or that contribute directly to it." presentationName="Solution" workProducts="_0YuXEMlgEdmt3adZL5Dmdw _0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw _0ZfMEMlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-sIh01vzZACgxRrG_sv7DVw" href="uma://-sIh01vzZACgxRrG_sv7DVw#-sIh01vzZACgxRrG_sv7DVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_tJJeADz7Edq03rqPoNVoKg" name="specification" guid="_tJJeADz7Edq03rqPoNVoKg" briefDescription="These work products define the interfaces between different parts of the project, especially between different domains. They define exactly what something is or what it must do. For example, the Architecture shows how system requirements are mapped into design." presentationName="Specification" workProducts="_0ZS-0MlgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q">
+ <presentation xmi:id="-C5ih3s1Vn_9qQbjm85-GYg" href="uma://-C5ih3s1Vn_9qQbjm85-GYg#-C5ih3s1Vn_9qQbjm85-GYg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T2eIslgEdmt3adZL5Dmdw" name="Tools" guid="_0T2eIslgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T8kwMlgEdmt3adZL5Dmdw" name="StandardCategories" guid="_0T8kwMlgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T8kwclgEdmt3adZL5Dmdw" name="CustomCategories" guid="_0T8kwclgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0T8kwslgEdmt3adZL5Dmdw" name="Hidden" guid="_0T8kwslgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_0T8kw8lgEdmt3adZL5Dmdw" name="Custom Categories" guid="_0T8kw8lgEdmt3adZL5Dmdw" categorizedElements="_NIIYMBOJEduCNqgZdt_OaA">
+ <presentation xmi:id="_cyZ5EMfLEdmg9p6Pf0sWyw" href="uma://_cyZ5EMfLEdmg9p6Pf0sWyw#_cyZ5EMfLEdmg9p6Pf0sWyw"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_cp6ycBOGEduCNqgZdt_OaA" name="getting_started" guid="_cp6ycBOGEduCNqgZdt_OaA" briefDescription="This area provides information useful for understanding how to deploy and adopt OpenUP/Basic." presentationName="Getting Started" shapeicon="openup_basic/customcategories/resources/icon_introL.gif" nodeicon="openup_basic/customcategories/resources/mic.gif" categorizedElements="_vEruwN-rEdqiM_wFaqLjNg _ClDF4BOHEduCNqgZdt_OaA _UaGfECcTEduSX6N2jUafGA"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_ClDF4BOHEduCNqgZdt_OaA" name="about" guid="_ClDF4BOHEduCNqgZdt_OaA" presentationName="About" shapeicon="openup_basic/customcategories/resources/processicon.gif" nodeicon="openup_basic/customcategories/resources/about.gif">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="#_8tSNMPGYEdqiDINUyockoA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uvje4D_fEdqDFvujd6NHiA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_HEu9QBOHEduCNqgZdt_OaA" name="core_principles_cat" guid="_HEu9QBOHEduCNqgZdt_OaA" briefDescription="Four core principles capture the general intentions behind this process and create the foundation for interpreting roles and work products and performing tasks." presentationName="Core Principles" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_ssG6MMvpEdqukPpotm3DYg _KkTIsMp7EdqC_NfSivunjA _9gocwMvoEdqukPpotm3DYg _GXiogMvoEdqukPpotm3DYg"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_NIIYMBOJEduCNqgZdt_OaA" name="openup_basic_views" guid="_NIIYMBOJEduCNqgZdt_OaA" presentationName="OpenUP/Basic Views" categorizedElements="_SEztkBOJEduCNqgZdt_OaA _2l8U4K4sEdudp4CB-AFxtw _RdM7MMXnEduywMSzPTUUwA">
+ <presentation xmi:id="-8uqXjzIOnt6LVDae6Uv_0w" href="uma://-8uqXjzIOnt6LVDae6Uv_0w#-8uqXjzIOnt6LVDae6Uv_0w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_SEztkBOJEduCNqgZdt_OaA" name="openup_basic_deprecated" guid="_SEztkBOJEduCNqgZdt_OaA" presentationName="OpenUP/Basic - deprecated">
+ <presentation xmi:id="-nY50CawHefla4zauYddVfw" href="uma://-nY50CawHefla4zauYddVfw#-nY50CawHefla4zauYddVfw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="#_i-BDsNogEdqfmNgIq7q3Xw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_cp6ycBOGEduCNqgZdt_OaA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_HEu9QBOHEduCNqgZdt_OaA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_V2BQkEmbEdu0xduwSKie-w"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:RoleSet" href="#_TZIJ0O8NEdmKSqa_gSYthg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_s4Z9AMWXEdqWePvIjHInwg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DisciplineGrouping" href="#__BZycP1UEdmek8CQTQgrOQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uyGoMlgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_V2BQkEmbEdu0xduwSKie-w" name="sub_processes" guid="_V2BQkEmbEdu0xduwSKie-w" briefDescription="OpenUP/Basic is organized into four major areas of content, also known as sub-processes." presentationName="Sub-processes" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_r8cVIEmbEdu0xduwSKie-w _57_ZMEmbEdu0xduwSKie-w _Aoz2gEmcEdu0xduwSKie-w _HEVvgEmcEdu0xduwSKie-w">
+ <presentation xmi:id="-1ZoXO1IRfkXUKej4bNv8cw" href="uma://-1ZoXO1IRfkXUKej4bNv8cw#-1ZoXO1IRfkXUKej4bNv8cw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_r8cVIEmbEdu0xduwSKie-w" name="collab_commun_subprocess" guid="_r8cVIEmbEdu0xduwSKie-w" briefDescription="This layer is the foundation for OpenUP, reflecting the collaborative nature of the process." presentationName="Communication and Collaboration" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_KkTIsMp7EdqC_NfSivunjA _TZIJ0O8NEdmKSqa_gSYthg">
+ <presentation xmi:id="-NMF-a9hwKjzWNfHzzseDYQ" href="uma://-NMF-a9hwKjzWNfHzzseDYQ#-NMF-a9hwKjzWNfHzzseDYQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_57_ZMEmbEdu0xduwSKie-w" name="intent_subprocess" guid="_57_ZMEmbEdu0xduwSKie-w" briefDescription="The intent sub-process deals with how to channel the intent of stakeholders to the rest of the development team, to ensure that validated builds with incremental capabilities reflect stakeholder intents." presentationName="Intent" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif">
+ <presentation xmi:id="-QRnsN2e6IQlSMaRts-wFNw" href="uma://-QRnsN2e6IQlSMaRts-wFNw#-QRnsN2e6IQlSMaRts-wFNw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_ssG6MMvpEdqukPpotm3DYg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TR2ZMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TwXgMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_allMQMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_vUzp0MWeEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygclgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_Aoz2gEmcEdu0xduwSKie-w" name="management_subprocess" guid="_Aoz2gEmcEdu0xduwSKie-w" briefDescription="The Management sub-process deals with management of the project, including project planning, iteration planning, day-to-day management of the work within the iteration, and iteration assessments." presentationName="Management" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif">
+ <presentation xmi:id="-q8ubSlQ5miYcY1JXdj1fbQ" href="uma://-q8ubSlQ5miYcY1JXdj1fbQ#-q8ubSlQ5miYcY1JXdj1fbQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_GXiogMvoEdqukPpotm3DYg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TqQ4MlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_QxjGYMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNA8lgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkslgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_HEVvgEmcEdu0xduwSKie-w" name="solution_subprocess" guid="_HEVvgEmcEdu0xduwSKie-w" briefDescription="The Solution sub-process describes all aspects of creating the architecture, designing, implementing, and testing the application." presentationName="Solution" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif">
+ <presentation xmi:id="-qwWeiX7WrSVHSluBe-J7yw" href="uma://-qwWeiX7WrSVHSluBe-J7yw#-qwWeiX7WrSVHSluBe-J7yw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_9gocwMvoEdqukPpotm3DYg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TX9AMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TeDoMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Discipline" href="#_0TkKQMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_xITr8MWXEdqWePvIjHInwg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_A9k3UMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_ou4CMMWfEdqiT9CqkRksWQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7islgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQslgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAfimEdmugcVr9AdHjQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CapabilityPattern" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79clgEdmt3adZL5Dmdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_2l8U4K4sEdudp4CB-AFxtw" name="architectural_mechanisms" guid="_2l8U4K4sEdudp4CB-AFxtw" briefDescription="Information about how to use use architectural mechansims to create a robust architecture." presentationName="Architectural Mechanisms" categorizedElements="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA _4k_HsA4LEduibvKwrGxWxA _4k_HsQ4LEduibvKwrGxWxA _4k_Hsg4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_RdM7MMXnEduywMSzPTUUwA" name="openup_basic_treebrowser" guid="_RdM7MMXnEduywMSzPTUUwA" presentationName="OpenUP/Basic">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_BTJ_YMXwEduywMSzPTUUwA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#__cft0MXxEduywMSzPTUUwA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DisciplineGrouping" href="#__BZycP1UEdmek8CQTQgrOQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Domain" href="#_s4Z9AMWXEdqWePvIjHInwg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:RoleSet" href="#_TZIJ0O8NEdmKSqa_gSYthg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uyGoMlgEdmt3adZL5Dmdw"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:CustomCategory" href="#_ClDF4BOHEduCNqgZdt_OaA"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="#_UaGfECcTEduSX6N2jUafGA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_BTJ_YMXwEduywMSzPTUUwA" name="introduction_to_openup_basic" guid="_BTJ_YMXwEduywMSzPTUUwA" presentationName="Introduction to OpenUP/Basic" shapeicon="openup_basic/customcategories/resources/icon_introL.gif" nodeicon="openup_basic/customcategories/resources/mic.gif" categorizedElements="_v2l6gK_5EduMeuOwJ2MpeQ _Nm5vUK__EduMeuOwJ2MpeQ _qg1IAK__EduMeuOwJ2MpeQ _UCOtoMXwEduywMSzPTUUwA _ZRHNUMXwEduywMSzPTUUwA">
+ <presentation xmi:id="-TfxeHO_AJxYCzXVva0kSzQ" href="uma://-TfxeHO_AJxYCzXVva0kSzQ#-TfxeHO_AJxYCzXVva0kSzQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_UCOtoMXwEduywMSzPTUUwA" name="core_principles_category" guid="_UCOtoMXwEduywMSzPTUUwA" briefDescription="Four core principles capture the general intentions behind this process and create the foundation for interpreting roles and work products and performing tasks." presentationName="Core Principles" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_ssG6MMvpEdqukPpotm3DYg _KkTIsMp7EdqC_NfSivunjA _9gocwMvoEdqukPpotm3DYg _GXiogMvoEdqukPpotm3DYg">
+ <presentation xmi:id="-I2j8LuHkworb0Y3EIlWfDQ" href="uma://-I2j8LuHkworb0Y3EIlWfDQ#-I2j8LuHkworb0Y3EIlWfDQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_ZRHNUMXwEduywMSzPTUUwA" name="fundamental_concepts" guid="_ZRHNUMXwEduywMSzPTUUwA" presentationName="OpenUP Fundamental Concepts" shapeicon="openup_basic/customcategories/resources/concept_dgm32.gif" nodeicon="openup_basic/customcategories/resources/concept_obj.gif" categorizedElements="_0hmKgBOMEduCNqgZdt_OaA _2plxwBOMEduCNqgZdt_OaA _48EKsBOMEduCNqgZdt_OaA __ca5UBOMEduCNqgZdt_OaA _lam4ADkBEduxovfWMDsntw _KudM0NcJEdqz_d2XWoVt6Q _0bsLgMlgEdmt3adZL5Dmdw __O7tAMVvEduLYZUGfgZrkQ"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="__cft0MXxEduywMSzPTUUwA" name="getting_started_with_openup" guid="__cft0MXxEduywMSzPTUUwA" briefDescription="This area provides information useful for understanding how to deploy and adopt OpenUP/Basic." presentationName="Getting Started" shapeicon="openup_basic/customcategories/resources/icon_introL.gif" nodeicon="openup_basic/customcategories/resources/mic.gif" categorizedElements="_vEruwN-rEdqiM_wFaqLjNg _omneEMX4EduywMSzPTUUwA _t9yXEMX4EduywMSzPTUUwA">
+ <presentation xmi:id="-zy1Q3NXKXbiCP_zrjTxwaQ" href="uma://-zy1Q3NXKXbiCP_zrjTxwaQ#-zy1Q3NXKXbiCP_zrjTxwaQ"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0UCrYMlgEdmt3adZL5Dmdw" name="CoreContent" guid="_0UCrYMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0UCrYclgEdmt3adZL5Dmdw" name="collaboration" guid="_0UCrYclgEdmt3adZL5Dmdw" briefDescription="Collaboration sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_OGGKkMpyEdqC_NfSivunjA" name="core_principles" guid="_OGGKkMpyEdqC_NfSivunjA">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_KkTIsMp7EdqC_NfSivunjA" name="core_principle_collaborate" guid="_KkTIsMp7EdqC_NfSivunjA" briefDescription="Develop collaborative practices that foster a healthy team environment. Good collaborative practices align the interests of project participants and help them develop a shared understanding of the project." presentationName="Collaborate to align interests and share understanding">
+ <presentation xmi:id="-IXfkG-XfnoEo0xgux482Kw" href="uma://-IXfkG-XfnoEo0xgux482Kw#-IXfkG-XfnoEo0xgux482Kw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_GXiogMvoEdqukPpotm3DYg" name="core_principle_evolve" guid="_GXiogMvoEdqukPpotm3DYg" briefDescription="Divide the project up into short, time-boxed iterations to demonstrate incremental value and obtain early and continuous feedback." presentationName="Evolve to continuously obtain feedback and improve">
+ <presentation xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" href="uma://-aMD1wQVJLzzlMARfHBdOBQ#-aMD1wQVJLzzlMARfHBdOBQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_9gocwMvoEdqukPpotm3DYg" name="core_principle_focus" guid="_9gocwMvoEdqukPpotm3DYg" briefDescription="Articulate essential technical decisions through a growing architecture." presentationName="Focus on articulating the architecture">
+ <presentation xmi:id="-HTMJFV29MTZkKWqnIo01Gg" href="uma://-HTMJFV29MTZkKWqnIo01Gg#-HTMJFV29MTZkKWqnIo01Gg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_ssG6MMvpEdqukPpotm3DYg" name="core_principle_balance" guid="_ssG6MMvpEdqukPpotm3DYg" briefDescription="Develop a solution that maximizes stakeholder benefits and complies with constraints placed on the project." presentationName="Balance competing priorities to maximize stakeholder value">
+ <presentation xmi:id="-I4IbR1GW6IFBCdq9SiMUsw" href="uma://-I4IbR1GW6IFBCdq9SiMUsw#-I4IbR1GW6IFBCdq9SiMUsw"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_L79ggDR5EdutE_HNDTJk5Q" name="uc_modeling" guid="_L79ggDR5EdutE_HNDTJk5Q" briefDescription="Elements specific to UC modeling.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_W2SgEDR5EdutE_HNDTJk5Q" name="uc_model" guid="_W2SgEDR5EdutE_HNDTJk5Q" presentationName="Use-Case Model"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0dsWoMlgEdmt3adZL5Dmdw" name="any_role" guid="_0dsWoMlgEdmt3adZL5Dmdw" briefDescription="Anyone on a team can fill this role of performing general tasks." presentationName="Any Role">
+ <presentation xmi:id="_NqqcUqeqEdmKDbQuyzCoqQ" href="uma://_NqqcUqeqEdmKDbQuyzCoqQ#_NqqcUqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_9ToeIB83Edqsvps02rpOOg" name="references" guid="_9ToeIB83Edqsvps02rpOOg" briefDescription="Additional references that may be useful, including books, method plug-ins, and commercial methodology products." presentationName="References">
+ <presentation xmi:id="-aCI9T-9TIe8D35yXBU6qvg" href="uma://-aCI9T-9TIe8D35yXBU6qvg#-aCI9T-9TIe8D35yXBU6qvg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_dTa6gMAYEdqX-s4mWhkyqQ" name="stakeholder" guid="_dTa6gMAYEdqX-s4mWhkyqQ" briefDescription="This role represents interest groups whose needs must be satisfied by the project. It is a role that may be played by anyone who is (or potentially will be) materially affected by the outcome of the project." presentationName="Stakeholder"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_i-BDsNogEdqfmNgIq7q3Xw" name="openup_basic_home" guid="_i-BDsNogEdqfmNgIq7q3Xw" presentationName="OpenUP/Basic" shapeicon="openup_basic/guidances/supportingmaterials/resources/icon_introL.gif" nodeicon="openup_basic/guidances/supportingmaterials/resources/mic.gif">
+ <presentation xmi:id="-XR2Rbg25yN80p1exWC4MHg" href="uma://-XR2Rbg25yN80p1exWC4MHg#-XR2Rbg25yN80p1exWC4MHg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Roadmap" xmi:id="_vEruwN-rEdqiM_wFaqLjNg" name="openup_basic_roadmap" guid="_vEruwN-rEdqiM_wFaqLjNg" briefDescription="This roadmap presents an overview of OpenUP/Basic, its purpose and lifecycle." presentationName="OpenUP/Basic Roadmap">
+ <presentation xmi:id="-At_b3UIzbgdmtJsb2Ymfhg" href="uma://-At_b3UIzbgdmtJsb2Ymfhg#-At_b3UIzbgdmtJsb2Ymfhg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_8tSNMPGYEdqiDINUyockoA" name="about_openup_basic" guid="_8tSNMPGYEdqiDINUyockoA" presentationName="About OpenUP/Basic" nodeicon="openup_basic/guidances/supportingmaterials/resources/about.gif">
+ <presentation xmi:id="-WFD3nKccpkueaG15cHT-fA" href="uma://-WFD3nKccpkueaG15cHT-fA#-WFD3nKccpkueaG15cHT-fA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_NOHy0BOGEduCNqgZdt_OaA" name="using_openup_basic" guid="_NOHy0BOGEduCNqgZdt_OaA" briefDescription="This guideline explains the various usage scenarios of this Web site." presentationName="Using OpenUP/Basic" shapeicon="openup_basic/guidances/guidelines/resources/compassL.gif" nodeicon="openup_basic/guidances/guidelines/resources/compass.gif"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0hmKgBOMEduCNqgZdt_OaA" name="inception_phase" guid="_0hmKgBOMEduCNqgZdt_OaA" briefDescription="First of the four phases in the project lifecycle, it is about understanding the project scope and objectives and getting enough information to confirm that the project should proceed - or convince you that it should not." presentationName="Inception Phase">
+ <presentation xmi:id="-GRJW_KNOJoEQF3r6lmBrEw" href="uma://-GRJW_KNOJoEQF3r6lmBrEw#-GRJW_KNOJoEQF3r6lmBrEw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2plxwBOMEduCNqgZdt_OaA" name="elaboration_phase" guid="_2plxwBOMEduCNqgZdt_OaA" briefDescription="Second of four phases in the project lifecycle, when architecturally significant risks are addressed." presentationName="Elaboration Phase">
+ <presentation xmi:id="-F-eWIBzxEXE1jygbN3nrrQ" href="uma://-F-eWIBzxEXE1jygbN3nrrQ#-F-eWIBzxEXE1jygbN3nrrQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_48EKsBOMEduCNqgZdt_OaA" name="construction_phase" guid="_48EKsBOMEduCNqgZdt_OaA" briefDescription="Third of the four phases in the project lifecycle, Construction focuses on design, implementation, and testing of functionalities to develop a complete system." presentationName="Construction Phase">
+ <presentation xmi:id="-bbpT_BdDRrv6waNI365Qhg" href="uma://-bbpT_BdDRrv6waNI365Qhg#-bbpT_BdDRrv6waNI365Qhg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="__ca5UBOMEduCNqgZdt_OaA" name="transition_phase" guid="__ca5UBOMEduCNqgZdt_OaA" briefDescription="Fourth and final phase in the project lifecycle." presentationName="Transition Phase">
+ <presentation xmi:id="-FrUmsKsGW4bnNmb9uaNOkg" href="uma://-FrUmsKsGW4bnNmb9uaNOkg#-FrUmsKsGW4bnNmb9uaNOkg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_Pt_fYBjoEduxUfEVCtmW4Q" name="delivery_process_graph" guid="_Pt_fYBjoEduxUfEVCtmW4Q" presentationName="Delivery Process Graph">
+ <presentation xmi:id="-cy0DcnEk7uJJ1OOH3_E6rg" href="uma://-cy0DcnEk7uJJ1OOH3_E6rg#-cy0DcnEk7uJJ1OOH3_E6rg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_UaGfECcTEduSX6N2jUafGA" name="openup_copyright" guid="_UaGfECcTEduSX6N2jUafGA" briefDescription="OpenUP Copyright Information" presentationName="OpenUP Copyright" shapeicon="openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif" nodeicon="openup_basic/guidances/supportingmaterials/resources/CRsym_obj.gif">
+ <presentation xmi:id="-RNyaB6jxqoopm9fJU8k9vg" href="uma://-RNyaB6jxqoopm9fJU8k9vg#-RNyaB6jxqoopm9fJU8k9vg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0VxJsMlgEdmt3adZL5Dmdw" name="analyst" guid="_0VxJsMlgEdmt3adZL5Dmdw" briefDescription="The person in this role represents customer and end-user concerns by gathering input from stakeholders to understand the problem to be solved and by capturing and setting priorities for requirements." presentationName="Analyst" responsibleFor="_0WVxcMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q _W2SgEDR5EdutE_HNDTJk5Q">
+ <presentation xmi:id="_Nx8icKYdEdmvhNXG0Oc2uA" href="uma://_Nx8icKYdEdmvhNXG0Oc2uA#_Nx8icKYdEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_BVh9cL-CEdqb7N6KIeDL8Q" name="supporting_requirements" guid="_BVh9cL-CEdqb7N6KIeDL8Q" briefDescription="This artifact captures system-wide requirements not captured in scenarios or use cases, including requirements on quality attributes and global functional requirements." presentationName="Supporting Requirements" conceptsAndPapers="_VXZ5wO0IEdqHTdbLTmC5IQ">
+ <presentation xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" href="uma://-_dNuyh-0q5vpCiIiLfbj6w#-_dNuyh-0q5vpCiIiLfbj6w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0VGbUMlgEdmt3adZL5Dmdw" name="use_case" guid="_0VGbUMlgEdmt3adZL5Dmdw" briefDescription="This artifact captures the sequence of actions a system performs that yields an observable result of value to those interacting with the system." presentationName="Use Case" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q">
+ <presentation xmi:id="_zHZW8qYSEdmvhNXG0Oc2uA" href="uma://_zHZW8qYSEdmvhNXG0Oc2uA#_zHZW8qYSEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0WVxcMlgEdmt3adZL5Dmdw" name="vision" guid="_0WVxcMlgEdmt3adZL5Dmdw" briefDescription="This artifact contains the definition of the stakeholders' view of the product to be developed, specified in terms of the stakeholders' key needs and features. It contains an outline of the envisioned core requirements for the system." presentationName="Vision" checklists="_0WoFUMlgEdmt3adZL5Dmdw _jxn9EO0HEdqHTdbLTmC5IQ">
+ <presentation xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" href="uma://_zHTQUKYSEdmvhNXG0Oc2uA#_zHTQUKYSEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_rGNWsCbSEdqh1LYUOGRh2A" name="work_items_list" guid="_rGNWsCbSEdqh1LYUOGRh2A" briefDescription="This artifact contains a list of all scheduled work to be done within the project, as well as proposed work that may affect the product in this or future projects. Each Work Item may contain references to information relevant to carry out the work described within the work item." presentationName="Work Items List" guidelines="_7vEXEMA4EdqSgKaj2SZBmg" templates="_QwUJYDg0Edu4E8ZdmlYjtA">
+ <presentation xmi:id="-buxz4BVToq97bSxaqyjySg" href="uma://-buxz4BVToq97bSxaqyjySg#-buxz4BVToq97bSxaqyjySg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0aQBEslgEdmt3adZL5Dmdw" name="iteration_plan" guid="_0aQBEslgEdmt3adZL5Dmdw" briefDescription="A fine-grained plan describing the objectives, work assignments, and evaluation criteria for the iteration." presentationName="Iteration Plan" conceptsAndPapers="_lam4ADkBEduxovfWMDsntw" templates="_0dBoQMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_BcBR8KX5EdmvhNXG0Oc2uA" href="uma://_BcBR8KX5EdmvhNXG0Oc2uA#_BcBR8KX5EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_7vEXEMA4EdqSgKaj2SZBmg" name="work_items_list" guid="_7vEXEMA4EdqSgKaj2SZBmg" briefDescription="This guideline explains the lifecycle of work items, and how the Work Items List is used." presentationName="Work Items List">
+ <presentation xmi:id="-G1Oxlk6F0R09vClqy1EzOw" href="uma://-G1Oxlk6F0R09vClqy1EzOw#-G1Oxlk6F0R09vClqy1EzOw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Wn7HcNcEEdqz_d2XWoVt6Q" name="glossary" guid="_Wn7HcNcEEdqz_d2XWoVt6Q" briefDescription="This artifact defines important terms used by the project. These terms are the basis for effective collaboration with the stakeholders and other team members." presentationName="Glossary">
+ <presentation xmi:id="-iOn7_gfX_iELWRNGJ2JKPQ" href="uma://-iOn7_gfX_iELWRNGJ2JKPQ#-iOn7_gfX_iELWRNGJ2JKPQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VXZ5wO0IEdqHTdbLTmC5IQ" name="supporting_requirements" guid="_VXZ5wO0IEdqHTdbLTmC5IQ" briefDescription="This concept describes the supporting requirements" presentationName="Supporting Requirements">
+ <presentation xmi:id="-3SXuKijeVOZalgLPgWRyFA" href="uma://-3SXuKijeVOZalgLPgWRyFA#-3SXuKijeVOZalgLPgWRyFA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_KudM0NcJEdqz_d2XWoVt6Q" name="use_case" guid="_KudM0NcJEdqz_d2XWoVt6Q" briefDescription="A use case describes what the system must do to provide value to the stakeholders." presentationName="Use Case" conceptsAndPapers="_zGqO0MDpEduTGJ8i4u8TMw">
+ <presentation xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" href="uma://-BQLZ5GRUNrMdU6XeZAfe9Q#-BQLZ5GRUNrMdU6XeZAfe9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_jxn9EO0HEdqHTdbLTmC5IQ" name="good_requirements" guid="_jxn9EO0HEdqHTdbLTmC5IQ" briefDescription="This checklist provides guidance on assessing the quality of requirements." presentationName="Qualities of Good Requirements">
+ <presentation xmi:id="-2o1pXjHpSEPN_rohLce5jA" href="uma://-2o1pXjHpSEPN_rohLce5jA#-2o1pXjHpSEPN_rohLce5jA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0WoFUMlgEdmt3adZL5Dmdw" name="vision" guid="_0WoFUMlgEdmt3adZL5Dmdw" briefDescription="This check list provides questions to verify that the Vision is described in a consistent and complete manner." presentationName="Vision">
+ <presentation xmi:id="_qktWQMM0EdmSIPI87WLu3g" href="uma://_qktWQMM0EdmSIPI87WLu3g#_qktWQMM0EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0VrDEMlgEdmt3adZL5Dmdw" name="actor" guid="_0VrDEMlgEdmt3adZL5Dmdw" briefDescription="This check list provides questions to help ensure that all actors, and only valid actors, have been identified and described correctly." presentationName="Actor">
+ <presentation xmi:id="_KEldgMM1EdmSIPI87WLu3g" href="uma://_KEldgMM1EdmSIPI87WLu3g#_KEldgMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0ZM4MclgEdmt3adZL5Dmdw" name="tester" guid="_0ZM4MclgEdmt3adZL5Dmdw" briefDescription="This role is responsible for the core activities of the test effort. Those activities include identifying, defining, implementing, and conducting the necessary tests, as well as logging the outcomes of the testing and analyzing the results." presentationName="Tester" responsibleFor="_0ZS-0MlgEdmt3adZL5Dmdw _0ZlSsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NqYIcKeqEdmKDbQuyzCoqQ" href="uma://_NqYIcKeqEdmKDbQuyzCoqQ#_NqYIcKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0ZS-0MlgEdmt3adZL5Dmdw" name="test_case" guid="_0ZS-0MlgEdmt3adZL5Dmdw" briefDescription="This artifact is the specification of a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a scenario." presentationName="Test Case" conceptsAndPapers="_0aJ6cMlgEdmt3adZL5Dmdw" checklists="_0Zxf8MlgEdmt3adZL5Dmdw" templates="_0dT8IMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NqYIdKeqEdmKDbQuyzCoqQ" href="uma://_NqYIdKeqEdmKDbQuyzCoqQ#_NqYIdKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0ZlSsMlgEdmt3adZL5Dmdw" name="test_log" guid="_0ZlSsMlgEdmt3adZL5Dmdw" briefDescription="This artifact collects raw output captured during a unique execution of one or more tests for a single test cycle run." presentationName="Test Log">
+ <presentation xmi:id="_NqePEKeqEdmKDbQuyzCoqQ" href="uma://_NqePEKeqEdmKDbQuyzCoqQ#_NqePEKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0Zxf8MlgEdmt3adZL5Dmdw" name="test_case" guid="_0Zxf8MlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that test cases are created in a consistent and complete manner." presentationName="Test Case">
+ <presentation xmi:id="_kwHAgMPbEdmbOvqy4O0adg" href="uma://_kwHAgMPbEdmbOvqy4O0adg#_kwHAgMPbEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0YDosMlgEdmt3adZL5Dmdw" name="developer" guid="_0YDosMlgEdmt3adZL5Dmdw" briefDescription="This role is responsible for developing a part of the system, including designing it to fit into the architecture, possibly prototyping the user-interface, and then implementing, unit-testing, and integrating the components that are part of the solution." presentationName="Developer">
+ <presentation xmi:id="_NqL7MqeqEdmKDbQuyzCoqQ" href="uma://_NqL7MqeqEdmKDbQuyzCoqQ#_NqL7MqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0X9iEMlgEdmt3adZL5Dmdw" name="architect" guid="_0X9iEMlgEdmt3adZL5Dmdw" briefDescription="This role is responsible for defining the software architecture, which includes making the key technical decisions that constrain the overall design and implementation of the project." presentationName="Architect" conceptsAndPapers="_9gocwMvoEdqukPpotm3DYg">
+ <presentation xmi:id="_Y6tLEKbXEdm9d-ircVOUCA" href="uma://_Y6tLEKbXEdm9d-ircVOUCA#_Y6tLEKbXEdm9d-ircVOUCA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_0a0o0MlgEdmt3adZL5Dmdw" name="project_manager" guid="_0a0o0MlgEdmt3adZL5Dmdw" briefDescription="Leads the planning of the project, coordinates interactions with the stakeholders, and keeps the project team focused on meeting the project objectives." presentationName="Project Manager" responsibleFor="_0aQBEslgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_Fdq-8KX4EdmvhNXG0Oc2uA" href="uma://_Fdq-8KX4EdmvhNXG0Oc2uA#_Fdq-8KX4EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_lam4ADkBEduxovfWMDsntw" name="iteration" guid="_lam4ADkBEduxovfWMDsntw" briefDescription="An iteration is a set period of time within a project in which you produce a stable, executable version of the product, together with any other supporting documentation, install scripts, or similar, necessary to use this release. Also referred to as a cycle or a timebox." presentationName="Iteration">
+ <presentation xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" href="uma://-vi8wxwxVZLY0SMPFxZjD7A#-vi8wxwxVZLY0SMPFxZjD7A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0bsLgMlgEdmt3adZL5Dmdw" name="risk" guid="_0bsLgMlgEdmt3adZL5Dmdw" briefDescription="A risk is whatever may stand in the way to success, and is currently unknown or uncertain. Usually, a risk is qualified by the probability of occurrence and the impact in the project, if it occurs." presentationName="Risk">
+ <presentation xmi:id="_u6enMMM1EdmSIPI87WLu3g" href="uma://_u6enMMM1EdmSIPI87WLu3g#_u6enMMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3PJ38EvqEdunZcj9T5hrMQ" name="agile" guid="_3PJ38EvqEdunZcj9T5hrMQ" presentationName="agile">
+ <presentation xmi:id="-qZE4XgeMK93LmJMKuQWGFg" href="uma://-qZE4XgeMK93LmJMKuQWGFg#-qZE4XgeMK93LmJMKuQWGFg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_0sD60EvDEdunZcj9T5hrMQ" name="construction" guid="_0sD60EvDEdunZcj9T5hrMQ" presentationName="Construction">
+ <presentation xmi:id="-5wJmUR0WqX7lCIxsyqFsdA" href="uma://-5wJmUR0WqX7lCIxsyqFsdA#-5wJmUR0WqX7lCIxsyqFsdA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_8DkT4EvDEdunZcj9T5hrMQ" name="elaboration" guid="_8DkT4EvDEdunZcj9T5hrMQ" presentationName="Elaboration">
+ <presentation xmi:id="-0g2jTHQla8lbP6xGB3iGlg" href="uma://-0g2jTHQla8lbP6xGB3iGlg#-0g2jTHQla8lbP6xGB3iGlg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_525A8EvDEdunZcj9T5hrMQ" name="inception" guid="_525A8EvDEdunZcj9T5hrMQ" presentationName="Inception">
+ <presentation xmi:id="-dhgOQQ4GsV0-dNJmTmF9GA" href="uma://-dhgOQQ4GsV0-dNJmTmF9GA#-dhgOQQ4GsV0-dNJmTmF9GA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_O7JBYEvFEdunZcj9T5hrMQ" name="ioc_milestone" guid="_O7JBYEvFEdunZcj9T5hrMQ" presentationName="Initial Operational Capability Milestone.">
+ <presentation xmi:id="-gEgZg2UkFLjGeXkJLpAP6A" href="uma://-gEgZg2UkFLjGeXkJLpAP6A#-gEgZg2UkFLjGeXkJLpAP6A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZBUnMEvFEdunZcj9T5hrMQ" name="iteration" guid="_ZBUnMEvFEdunZcj9T5hrMQ" presentationName="iteration">
+ <presentation xmi:id="-_G0VvVOdMoajk615LwFtxg" href="uma://-_G0VvVOdMoajk615LwFtxg#-_G0VvVOdMoajk615LwFtxg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_NL4DMEvFEdunZcj9T5hrMQ" name="lca_milestone" guid="_NL4DMEvFEdunZcj9T5hrMQ" presentationName="Lifecycle Architecture Milestone">
+ <presentation xmi:id="-MllWL01NL93RTB7VsY69fw" href="uma://-MllWL01NL93RTB7VsY69fw#-MllWL01NL93RTB7VsY69fw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_LGRBkEvFEdunZcj9T5hrMQ" name="lco_milestone" guid="_LGRBkEvFEdunZcj9T5hrMQ" presentationName="Lifecycle Objectives Milestone">
+ <presentation xmi:id="-Rl8kaRW9Bxqdvq32kVCi7w" href="uma://-Rl8kaRW9Bxqdvq32kVCi7w#-Rl8kaRW9Bxqdvq32kVCi7w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ByXNcEvqEdunZcj9T5hrMQ" name="milestone" guid="_ByXNcEvqEdunZcj9T5hrMQ" presentationName="milestone">
+ <presentation xmi:id="-9fXEOvMc4t7y6s5GscBD1Q" href="uma://-9fXEOvMc4t7y6s5GscBD1Q#-9fXEOvMc4t7y6s5GscBD1Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_QuywUEvFEdunZcj9T5hrMQ" name="pr_milestone" guid="_QuywUEvFEdunZcj9T5hrMQ" presentationName="Product Release Milestone">
+ <presentation xmi:id="-JegYQHIteCRN0iV2EKMjSA" href="uma://-JegYQHIteCRN0iV2EKMjSA#-JegYQHIteCRN0iV2EKMjSA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_-5ms4EvDEdunZcj9T5hrMQ" name="transition" guid="_-5ms4EvDEdunZcj9T5hrMQ" presentationName="Transition">
+ <presentation xmi:id="-yoFF90pq-_UV3fm-5oDenw" href="uma://-yoFF90pq-_UV3fm-5oDenw#-yoFF90pq-_UV3fm-5oDenw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_cTs20KzREduOqvpk_MDLfQ" name="copyright_oup" guid="_cTs20KzREduOqvpk_MDLfQ" variabilityType="contributes">
+ <presentation xmi:id="-PZ0CqCcJHB-nbxs8fbP7bg" href="uma://-PZ0CqCcJHB-nbxs8fbP7bg#-PZ0CqCcJHB-nbxs8fbP7bg"/>
+ <variabilityBasedOnElement xsi:type="org.eclipse.epf.uma:SupportingMaterial" href="uma://_WCUhAO8KEdmKSqa_gSYthg#_uuunoPsDEdmyhNQr5STrZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_v2l6gK_5EduMeuOwJ2MpeQ" name="openup_and_openup_basic" guid="_v2l6gK_5EduMeuOwJ2MpeQ" briefDescription="OpenUP is a family of open source process plug-ins. OpenUP/Basic is the core process in OpenUP and is geared towards a small, co-located team." presentationName="OpenUP and OpenUP/Basic" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif">
+ <presentation xmi:id="-KCSbXYv5TALlL00zMMfgVw" href="uma://-KCSbXYv5TALlL00zMMfgVw#-KCSbXYv5TALlL00zMMfgVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_Nm5vUK__EduMeuOwJ2MpeQ" name="minimal_complete_extensible" guid="_Nm5vUK__EduMeuOwJ2MpeQ" briefDescription="OpenUP/Basic is minimal, complete, and extensible. It's the minimum amount of process for a small team, it can be used as-is, and it can be extended and customized for specific purposes." presentationName="Minimal, Complete, and Extensible" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_qg1IAK__EduMeuOwJ2MpeQ" name="agile_and_unified" guid="_qg1IAK__EduMeuOwJ2MpeQ" briefDescription="OpenUP/Basic is a Unified process that incorporates proven agile techniques. The result is a robust, effective, and lightweight process structure." presentationName="Agile and Unified" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif">
+ <presentation xmi:id="-l-ZsqrXu2nmVE1giLpI6iw" href="uma://-l-ZsqrXu2nmVE1giLpI6iw#-l-ZsqrXu2nmVE1giLpI6iw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_zGqO0MDpEduTGJ8i4u8TMw" name="actor" guid="_zGqO0MDpEduTGJ8i4u8TMw" briefDescription="An Actor is a role that a person or external system plays when interacting with a system. Instances of an Actor can be an individual or an external system." presentationName="Actor" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q">
+ <presentation xmi:id="-aN0zy068ovKHgmkkoYqoYQ" href="uma://-aN0zy068ovKHgmkkoYqoYQ#-aN0zy068ovKHgmkkoYqoYQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_U3VjIMEuEduwZvIr61GnNg" name="openup_iterations" guid="_U3VjIMEuEduwZvIr61GnNg" briefDescription="The set of iterations in a phase address specific milestones that objectively track a project's progress. Each phase has its own milestone that reflects the emphasis of the phase." presentationName="The Benefit of OpenUP/Basic Iterations" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif" conceptsAndPapers="_48EKsBOMEduCNqgZdt_OaA _2plxwBOMEduCNqgZdt_OaA _0hmKgBOMEduCNqgZdt_OaA __ca5UBOMEduCNqgZdt_OaA _GXiogMvoEdqukPpotm3DYg _lam4ADkBEduxovfWMDsntw">
+ <presentation xmi:id="-Mobjz86dw07NW5-IhtEoNA" href="uma://-Mobjz86dw07NW5-IhtEoNA#-Mobjz86dw07NW5-IhtEoNA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_REqtUMEvEduwZvIr61GnNg" name="openup_architecture" guid="_REqtUMEvEduwZvIr61GnNg" briefDescription="The early iterations of OpenUP/Basic focus on addressing the requirements that will produce an executable architecture. Buiding and validating the architecture first significantly reduces the technical risk in a project." presentationName="The Importance of Architecture in OpenUP/Basic" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif" conceptsAndPapers="_9gocwMvoEdqukPpotm3DYg _2plxwBOMEduCNqgZdt_OaA _0bsLgMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-clUV9n59dDwg0e1VCcsB8Q" href="uma://-clUV9n59dDwg0e1VCcsB8Q#-clUV9n59dDwg0e1VCcsB8Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_G08UgMEwEduwZvIr61GnNg" name="openup_risk" guid="_G08UgMEwEduwZvIr61GnNg" briefDescription="Risk is a reflection of uncertainty in a project. Reducing uncertainty increases the predictability and possible of success." presentationName="OpenUP/Basic constantly identifies and removes risk from a project" shapeicon="openup_basic/guidances/guidelines/resources/icon_introL.gif" nodeicon="openup_basic/guidances/guidelines/resources/mic.gif" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-_BjYXvrfe1HHL5Y_QBfh4Q" href="uma://-_BjYXvrfe1HHL5Y_QBfh4Q#-_BjYXvrfe1HHL5Y_QBfh4Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_omneEMX4EduywMSzPTUUwA" name="resources_for_modifying_methods" guid="_omneEMX4EduywMSzPTUUwA" presentationName="Resources for Modifying Methods"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_t9yXEMX4EduywMSzPTUUwA" name="resources_for_contributing_to_openup" guid="_t9yXEMX4EduywMSzPTUUwA" presentationName="Resources for Contributing to OpenUP"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0cQzQMlgEdmt3adZL5Dmdw" name="templates" guid="_0cQzQMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0cW54MlgEdmt3adZL5Dmdw" name="vision" guid="_0cW54MlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing the Vision document." presentationName="Vision">
+ <presentation xmi:id="_LxX6AMM2EdmSIPI87WLu3g" href="uma://_LxX6AMM2EdmSIPI87WLu3g#_LxX6AMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0cpNwMlgEdmt3adZL5Dmdw" name="uc_specification" guid="_0cpNwMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing a use case specification." presentationName="Use-Case Specification">
+ <presentation xmi:id="_OaB-UMM2EdmSIPI87WLu3g" href="uma://_OaB-UMM2EdmSIPI87WLu3g#_OaB-UMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0c7hoMlgEdmt3adZL5Dmdw" name="project_plan" guid="_0c7hoMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template for representing the project plan." presentationName="Project Plan">
+ <presentation xmi:id="_XjOXcMM2EdmSIPI87WLu3g" href="uma://_XjOXcMM2EdmSIPI87WLu3g#_XjOXcMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0dBoQMlgEdmt3adZL5Dmdw" name="iteration_plan" guid="_0dBoQMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for an iteration plan." presentationName="Iteration Plan">
+ <presentation xmi:id="_Z_bUIMM2EdmSIPI87WLu3g" href="uma://_Z_bUIMM2EdmSIPI87WLu3g#_Z_bUIMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0dN1gMlgEdmt3adZL5Dmdw" name="software_arch_document" guid="_0dN1gMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing architecture." presentationName="Software Architecture Document">
+ <presentation xmi:id="_fJPGkMM2EdmSIPI87WLu3g" href="uma://_fJPGkMM2EdmSIPI87WLu3g#_fJPGkMM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_0dT8IMlgEdmt3adZL5Dmdw" name="test_case" guid="_0dT8IMlgEdmt3adZL5Dmdw" briefDescription="This is the informal template suggested for representing test cases." presentationName="Test Case">
+ <presentation xmi:id="_j2pQ4MM2EdmSIPI87WLu3g" href="uma://_j2pQ4MM2EdmSIPI87WLu3g#_j2pQ4MM2EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_ItYXcNa9Edqrw4BYKyYKiA" name="supporting_requirements_spec" guid="_ItYXcNa9Edqrw4BYKyYKiA" briefDescription="This is the template suggested for specifying requirements and constraints in accordance with the FURPS+ classification." presentationName="Supporting Requirements Specification">
+ <presentation xmi:id="-FsyxZy4tyX8k5CxT5Jww_w" href="uma://-FsyxZy4tyX8k5CxT5Jww_w#-FsyxZy4tyX8k5CxT5Jww_w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="__JXkoCk8EduLGM8dfVsrKg" name="architecture" guid="__JXkoCk8EduLGM8dfVsrKg" briefDescription="Templates for representing the architecture work product." presentationName="Architecture">
+ <presentation xmi:id="-1Lm8-0FY-QIC56u5t2SC9w" href="uma://-1Lm8-0FY-QIC56u5t2SC9w#-1Lm8-0FY-QIC56u5t2SC9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_MIUO0C8FEduzydamRseoUw" name="risk_list" guid="_MIUO0C8FEduzydamRseoUw" briefDescription="A list or table containing risk attributes. As it is usual to rank risks by priority, spreadsheets may be an alternative to capture risks" presentationName="Risk List">
+ <presentation xmi:id="-OugFZJszm73z0_KSwRXZPw" href="uma://-OugFZJszm73z0_KSwRXZPw#-OugFZJszm73z0_KSwRXZPw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_QwUJYDg0Edu4E8ZdmlYjtA" name="work_items_list" guid="_QwUJYDg0Edu4E8ZdmlYjtA" briefDescription="This is a spreadsheet suggested for representing a work items list. Alternative templates would be usage of a specific tool or database with similar information." presentationName="Work Items List">
+ <presentation xmi:id="-mPA7vone29k1OvF_1rACjg" href="uma://-mPA7vone29k1OvF_1rACjg#-mPA7vone29k1OvF_1rACjg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_1awLIEp2Edup0IY9DKDPkg" name="status_assessment" guid="_1awLIEp2Edup0IY9DKDPkg" briefDescription="This is the informal template suggested for capturing and communicating the results of iteration assessments." presentationName="Status Assessment">
+ <presentation xmi:id="-2uQACndDBzBhJC1sCmk5UA" href="uma://-2uQACndDBzBhJC1sCmk5UA#-2uQACndDBzBhJC1sCmk5UA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_3E1NwDPBEduyTOpiJx8z_g" name="intent" guid="_3E1NwDPBEduyTOpiJx8z_g" briefDescription="Intent sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0b4YwMlgEdmt3adZL5Dmdw" name="change_management" guid="_0b4YwMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0cEmAMlgEdmt3adZL5Dmdw" name="workspace" guid="_0cEmAMlgEdmt3adZL5Dmdw" briefDescription="Workspace refers to storage areas where developers can implement and test code in accordance with the project's adopted standards in relative isolation from other developers." presentationName="Workspace">
+ <presentation xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" href="uma://_Dfmk8MPiEdmbOvqy4O0adg#_Dfmk8MPiEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0mwzEclgEdmt3adZL5Dmdw" name="request_change" guid="_0mwzEclgEdmt3adZL5Dmdw" briefDescription="Capture and record change requests." presentationName="Request Change" conceptsAndPapers="_6jdvECb3Edqh1LYUOGRh2A" guidelines="_fnZj0NVXEdqy9sbRhejO5Q" performedBy="_0dsWoMlgEdmt3adZL5Dmdw" output="_rGNWsCbSEdqh1LYUOGRh2A" optionalInput="_rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_Nr0S4KeqEdmKDbQuyzCoqQ" href="uma://_Nr0S4KeqEdmKDbQuyzCoqQ#_Nr0S4KeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_6jdvECb3Edqh1LYUOGRh2A" name="change_requests" guid="_6jdvECb3Edqh1LYUOGRh2A" briefDescription="A change request is a general term for any request to change a work product." presentationName="Change Requests" guidelines="_7vEXEMA4EdqSgKaj2SZBmg">
+ <presentation xmi:id="-BsXK3ZGMm-mUT0KnkdoYBg" href="uma://-BsXK3ZGMm-mUT0KnkdoYBg#-BsXK3ZGMm-mUT0KnkdoYBg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_fnZj0NVXEdqy9sbRhejO5Q" name="submitting_change_requests" guid="_fnZj0NVXEdqy9sbRhejO5Q" briefDescription="This guideline describes the type of information that is typically captured on a change request. This information is used to prioritize and scope the work required to implement the change and to monitor progress." presentationName="Submitting Change Requests">
+ <presentation xmi:id="-w7sImtXWkf4HDXdUWjRsUg" href="uma://-w7sImtXWkf4HDXdUWjRsUg#-w7sImtXWkf4HDXdUWjRsUg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="__Cw30ElxEducWJcS4yanqg" name="configuration" guid="__Cw30ElxEducWJcS4yanqg" presentationName="configuration">
+ <presentation xmi:id="-VPoMu7qzVX9grE4-nB3kMw" href="uma://-VPoMu7qzVX9grE4-nB3kMw#-VPoMu7qzVX9grE4-nB3kMw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_eX8K8ElyEducWJcS4yanqg" name="version" guid="_eX8K8ElyEducWJcS4yanqg" presentationName="version">
+ <presentation xmi:id="-4iL0UEFR2Fg7oWkh1TymIg" href="uma://-4iL0UEFR2Fg7oWkh1TymIg#-4iL0UEFR2Fg7oWkh1TymIg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0UCrYslgEdmt3adZL5Dmdw" name="requirements" guid="_0UCrYslgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_FtSMYAFjEduDPKiaP0pu-Q" name="uc_modeling" guid="_FtSMYAFjEduDPKiaP0pu-Q" briefDescription="This package contains elements specific to Use-Case Modeling technique.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0UCrZclgEdmt3adZL5Dmdw" name="uc_model_intent_req_ucm" guid="_0UCrZclgEdmt3adZL5Dmdw" briefDescription="This artifact captures a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers." variabilityType="contributes" variabilityBasedOnElement="_W2SgEDR5EdutE_HNDTJk5Q" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg _zGqO0MDpEduTGJ8i4u8TMw _KudM0NcJEdqz_d2XWoVt6Q" checklists="_0U6OEMlgEdmt3adZL5Dmdw _0VrDEMlgEdmt3adZL5Dmdw _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_0VAUsMlgEdmt3adZL5Dmdw" examples="_t4QdAMNqEdu2IdAIaWZyAw">
+ <presentation xmi:id="_zHZW9KYSEdmvhNXG0Oc2uA" href="uma://_zHZW9KYSEdmvhNXG0Oc2uA#_zHZW9KYSEdmvhNXG0Oc2uA"/>
+ <containedArtifacts xmi:id="_SBnZ4AFlEduDPKiaP0pu-Q" name="use_case_intent_req_ucm" guid="_SBnZ4AFlEduDPKiaP0pu-Q" variabilityType="contributes" variabilityBasedOnElement="_0VGbUMlgEdmt3adZL5Dmdw" examples="_JLOiIMNvEdu2IdAIaWZyAw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_txpV0AFmEduDPKiaP0pu-Q" name="find_and_outline_requirements_intent_req_ucm" guid="_txpV0AFmEduDPKiaP0pu-Q" orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1150923424568"> <gUIDs>_ckG-cCY-EdqNHcQ-rAojXw</gUIDs> <gUIDs>_GAr3IOz3Edq2wJOsmRwmhg</gUIDs> <gUIDs>_fDbgkCY-EdqNHcQ-rAojXw</gUIDs> <gUIDs>_XRKgkAFoEduDPKiaP0pu-Q</gUIDs> <gUIDs>_0WhHsN-eEdqiM_wFaqLjNg</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " variabilityType="contributes" variabilityBasedOnElement="_P9cMUPV_EdmdHa9MmVPgqQ" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg" checklists="_0U6OEMlgEdmt3adZL5Dmdw" guidelines="_0VAUsMlgEdmt3adZL5Dmdw" output="_0UCrZclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-Yt8TXGkE1rwydXR34apsrg" href="uma://-Yt8TXGkE1rwydXR34apsrg#-Yt8TXGkE1rwydXR34apsrg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_7_3vEAFmEduDPKiaP0pu-Q" name="detail_requirements_intent_req_ucm" guid="_7_3vEAFmEduDPKiaP0pu-Q" orderingGuide="<?xml version="1.0" encoding="ASCII"?> <org.eclipse.epf.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1158683054424"> <gUIDs>_vWeHMCxSEdqjsdw1QLH_6Q</gUIDs> <gUIDs>_B47VwCxTEdqjsdw1QLH_6Q</gUIDs> <gUIDs>_2389cOz2Edq2wJOsmRwmhg</gUIDs> <gUIDs>_w2JYgEf6EduISP1GQDlvVQ</gUIDs> <gUIDs>_BYbboN-bEdqiM_wFaqLjNg</gUIDs> </orderInfos> </org.eclipse.epf.uma.edit.tng.util.model:OrderInfoCollection> " variabilityType="contributes" variabilityBasedOnElement="_0e1mIMlgEdmt3adZL5Dmdw" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg" mandatoryInput="_0UCrZclgEdmt3adZL5Dmdw" output="_0UCrZclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-_mfd9ziTwQV_5LE80jJw4g" href="uma://-_mfd9ziTwQV_5LE80jJw4g#-_mfd9ziTwQV_5LE80jJw4g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0U6OEMlgEdmt3adZL5Dmdw" name="uc_model" guid="_0U6OEMlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that the Use-Case Model is described in a consistent and complete manner." presentationName="Use-Case Model">
+ <presentation xmi:id="_MqODAMM1EdmSIPI87WLu3g" href="uma://_MqODAMM1EdmSIPI87WLu3g#_MqODAMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0VAUsMlgEdmt3adZL5Dmdw" name="uc_model" guid="_0VAUsMlgEdmt3adZL5Dmdw" briefDescription="This guideline describes how to develop and evolve the use-case model to capture the functional requirements for the system under development." presentationName="Use-Case Model" conceptsAndPapers="_2jyfUAhVEduRe8TeoBmuGg" guidelines="_eyL0wCu-EdqSxKAVa9kmvA _4BJ_YCxSEdqjsdw1QLH_6Q">
+ <presentation xmi:id="_AGvpcMM3EdmSIPI87WLu3g" href="uma://_AGvpcMM3EdmSIPI87WLu3g#_AGvpcMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_2jyfUAhVEduRe8TeoBmuGg" name="use_case_model" guid="_2jyfUAhVEduRe8TeoBmuGg" briefDescription="This artifact is a model of the system's intended functions and its surroundings, and serves as a contract between the customer and the project team." presentationName="Use-Case Model">
+ <presentation xmi:id="-yEWkrWZ3VUcjZPhq6bvScg" href="uma://-yEWkrWZ3VUcjZPhq6bvScg#-yEWkrWZ3VUcjZPhq6bvScg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_MO9vkDPKEdudA-StyUUwnw" name="analyst_intent_req_ucm" guid="_MO9vkDPKEdudA-StyUUwnw" variabilityType="contributes" variabilityBasedOnElement="_0VxJsMlgEdmt3adZL5Dmdw" responsibleFor="_0UCrZclgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0Wh-sMlgEdmt3adZL5Dmdw" name="requirements" guid="_0Wh-sMlgEdmt3adZL5Dmdw" briefDescription="This page provides an informal definition of a requirement and explains how the concept is related to the process." presentationName="Requirements">
+ <presentation xmi:id="_eUfzwMMyEdmdo9HxCRR_Gw" href="uma://_eUfzwMMyEdmdo9HxCRR_Gw#_eUfzwMMyEdmdo9HxCRR_Gw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0fOAoMlgEdmt3adZL5Dmdw" name="define_vision" guid="_0fOAoMlgEdmt3adZL5Dmdw" briefDescription="Define the vision for the future system. Describe the problem and features based on Stakeholder requests." orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1115151259496"> <gUIDs>_sa5F4LwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_tvzDULwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_vGg-oLwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_z7ZC4LwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_u0DWcKhXEdmsY5hhGsDstg</gUIDs> <gUIDs>_yl_-EKhXEdmsY5hhGsDstg</gUIDs> <gUIDs>_zQUfoKuHEdmhFZtkg1nakg</gUIDs> <gUIDs>_1LVn0LwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_2VixILwPEdm6DujQZORGLQ</gUIDs> <gUIDs>_yq-j4LwPEdm6DujQZORGLQ</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " presentationName="Define Vision" conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw" checklists="_0WoFUMlgEdmt3adZL5Dmdw" guidelines="_OnoNQNSAEdmLhZ9H5Plxyw _E-dPIL-GEdqb7N6KIeDL8Q" performedBy="_0VxJsMlgEdmt3adZL5Dmdw" output="_0WVxcMlgEdmt3adZL5Dmdw _Wn7HcNcEEdqz_d2XWoVt6Q _rGNWsCbSEdqh1LYUOGRh2A" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0a0o0MlgEdmt3adZL5Dmdw _0X9iEMlgEdmt3adZL5Dmdw" optionalInput="_0WVxcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_5rJ78Lj3Edmy88CC3LfB_w" href="uma://_5rJ78Lj3Edmy88CC3LfB_w#_5rJ78Lj3Edmy88CC3LfB_w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_P9cMUPV_EdmdHa9MmVPgqQ" name="find_and_outline_requirements" guid="_P9cMUPV_EdmdHa9MmVPgqQ" briefDescription="This task describes how to capture the requirements for the system." presentationName="Find and Outline Requirements" conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw _KudM0NcJEdqz_d2XWoVt6Q _VXZ5wO0IEdqHTdbLTmC5IQ _zGqO0MDpEduTGJ8i4u8TMw" checklists="_jxn9EO0HEdqHTdbLTmC5IQ _Vael8CGMEdu3VKXZx45D3A _0VrDEMlgEdmt3adZL5Dmdw _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_OnoNQNSAEdmLhZ9H5Plxyw _eyL0wCu-EdqSxKAVa9kmvA _wr24gNcGEdqz_d2XWoVt6Q _E-dPIL-GEdqb7N6KIeDL8Q _1AOsMO0JEdqHTdbLTmC5IQ _6jXzYNcKEdqz_d2XWoVt6Q" performedBy="_0VxJsMlgEdmt3adZL5Dmdw" mandatoryInput="_Wn7HcNcEEdqz_d2XWoVt6Q _0WVxcMlgEdmt3adZL5Dmdw" output="_rGNWsCbSEdqh1LYUOGRh2A _BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q _0VGbUMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0X9iEMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_P9iS8PV_EdmdHa9MmVPgqQ" href="uma://_P9iS8PV_EdmdHa9MmVPgqQ#_P9iS8PV_EdmdHa9MmVPgqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_OnoNQNSAEdmLhZ9H5Plxyw" name="req_gathering_techniques" guid="_OnoNQNSAEdmLhZ9H5Plxyw" briefDescription="This guideline describes various techniques for gathering requirements." presentationName="Requirements Gathering Techniques">
+ <presentation xmi:id="_On0agNSAEdmLhZ9H5Plxyw" href="uma://_On0agNSAEdmLhZ9H5Plxyw#_On0agNSAEdmLhZ9H5Plxyw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0e1mIMlgEdmt3adZL5Dmdw" name="detail_requirements" guid="_0e1mIMlgEdmt3adZL5Dmdw" briefDescription="This task describes how to detail one or more requirements for the system." orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1113334493908"> <gUIDs>_yqm4kKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_zg2kEKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_1GGDkKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_35vP4KuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_5mtIAKuJEdmhFZtkg1nakg</gUIDs> <gUIDs>_7g3HkKuJEdmhFZtkg1nakg</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " presentationName="Detail Requirements" conceptsAndPapers="_0Wh-sMlgEdmt3adZL5Dmdw _KudM0NcJEdqz_d2XWoVt6Q _VXZ5wO0IEdqHTdbLTmC5IQ _VQ268O0KEdqHTdbLTmC5IQ _eYtQQO0KEdqHTdbLTmC5IQ" checklists="_jxn9EO0HEdqHTdbLTmC5IQ _Vael8CGMEdu3VKXZx45D3A _0kNwINk1Edq2Q8qZoWbvGA" guidelines="_4BJ_YCxSEdqjsdw1QLH_6Q _E-dPIL-GEdqb7N6KIeDL8Q _1AOsMO0JEdqHTdbLTmC5IQ _6jXzYNcKEdqz_d2XWoVt6Q _qq0GMAXkEduj_7BEUj1JfQ" performedBy="_0VxJsMlgEdmt3adZL5Dmdw" mandatoryInput="_BVh9cL-CEdqb7N6KIeDL8Q _0WVxcMlgEdmt3adZL5Dmdw _Wn7HcNcEEdqz_d2XWoVt6Q _0VGbUMlgEdmt3adZL5Dmdw" output="_BVh9cL-CEdqb7N6KIeDL8Q _Wn7HcNcEEdqz_d2XWoVt6Q _0VGbUMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0X9iEMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_Nqwi8KeqEdmKDbQuyzCoqQ" href="uma://_Nqwi8KeqEdmKDbQuyzCoqQ#_Nqwi8KeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_eyL0wCu-EdqSxKAVa9kmvA" name="find_and_outline_actors_and_ucs" guid="_eyL0wCu-EdqSxKAVa9kmvA" briefDescription="This guideline describes how to find and outline actors and use cases." presentationName="Find and Outline Actors and Use Cases" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q _zGqO0MDpEduTGJ8i4u8TMw _2jyfUAhVEduRe8TeoBmuGg">
+ <presentation xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" href="uma://-Rcm_MlViENAvFFyIe9V3dQ#-Rcm_MlViENAvFFyIe9V3dQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4BJ_YCxSEdqjsdw1QLH_6Q" name="detail_ucs_and_scenarios" guid="_4BJ_YCxSEdqjsdw1QLH_6Q" briefDescription="This guideline provides help on detailing use cases and scenarios." presentationName="Detail Use Cases and Scenarios" conceptsAndPapers="_KudM0NcJEdqz_d2XWoVt6Q _VXZ5wO0IEdqHTdbLTmC5IQ" guidelines="_qq0GMAXkEduj_7BEUj1JfQ">
+ <presentation xmi:id="-78ko4CuOJERKJF9ZvwMUBQ" href="uma://-78ko4CuOJERKJF9ZvwMUBQ#-78ko4CuOJERKJF9ZvwMUBQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_E-dPIL-GEdqb7N6KIeDL8Q" name="effective_req_reviews" guid="_E-dPIL-GEdqb7N6KIeDL8Q" briefDescription="This guideline discusses how to conduct reviews with relevant stakeholders to ensure agreement, assess quality, and identify changes required." presentationName="Effective Requirement Reviews">
+ <presentation xmi:id="-pNA0DbSdSoUqnjQIiOeHcQ" href="uma://-pNA0DbSdSoUqnjQIiOeHcQ#-pNA0DbSdSoUqnjQIiOeHcQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_wr24gNcGEdqz_d2XWoVt6Q" name="supporting_requirements" guid="_wr24gNcGEdqz_d2XWoVt6Q" briefDescription="This guideline explains how to develop and use the supporting requirements specification." presentationName="Supporting Requirements">
+ <presentation xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" href="uma://-BdYFG4-dbPBGFzF9z6KGPA#-BdYFG4-dbPBGFzF9z6KGPA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_feKVQLULEdqI644ssJaKYg" name="requirement" guid="_feKVQLULEdqI644ssJaKYg" presentationName="Requirements">
+ <presentation xmi:id="-0sCBiohjw_wBDKk0WEeDJQ" href="uma://-0sCBiohjw_wBDKk0WEeDJQ#-0sCBiohjw_wBDKk0WEeDJQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_6jXzYNcKEdqz_d2XWoVt6Q" name="writing_good_requirements" guid="_6jXzYNcKEdqz_d2XWoVt6Q" briefDescription="This guideline describes ways of writing good requirements." presentationName="Writing Good Requirements">
+ <presentation xmi:id="-AJQLv2ldVv5KN9eUbdQe_g" href="uma://-AJQLv2ldVv5KN9eUbdQe_g#-AJQLv2ldVv5KN9eUbdQe_g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0kNwINk1Edq2Q8qZoWbvGA" name="use_case" guid="_0kNwINk1Edq2Q8qZoWbvGA" briefDescription="This checklist provides questions to verify that use cases are described in a consistent and complete manner." presentationName="Use Case" variabilityType="replaces" checklists="_jxn9EO0HEdqHTdbLTmC5IQ">
+ <presentation xmi:id="-T2IeqdOunweffIDgL-aM0w" href="uma://-T2IeqdOunweffIDgL-aM0w#-T2IeqdOunweffIDgL-aM0w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_1AOsMO0JEdqHTdbLTmC5IQ" name="requirement_pitfalls" guid="_1AOsMO0JEdqHTdbLTmC5IQ" briefDescription="This guideline describes common pitfalls to avoid in defining and writing requirements. In some cases these are the inverse of the guidelines for writing good requirements, however, by showing examples of what NOT to do makes the explanation of what TO DO clearer." presentationName="Requirement Pitfalls">
+ <presentation xmi:id="-Q72-dNdHnZ93aRXAB_d34A" href="uma://-Q72-dNdHnZ93aRXAB_d34A#-Q72-dNdHnZ93aRXAB_d34A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VQ268O0KEdqHTdbLTmC5IQ" name="requirement_attributes" guid="_VQ268O0KEdqHTdbLTmC5IQ" briefDescription="Requirements attributes capture additional information, such as risk, planned iteration, source of requirement, about each requirement. This additional information is used to manage the project." presentationName="Requirement Attributes">
+ <presentation xmi:id="-fCBrf_5JlrmuKgyrCaKGOA" href="uma://-fCBrf_5JlrmuKgyrCaKGOA#-fCBrf_5JlrmuKgyrCaKGOA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_eYtQQO0KEdqHTdbLTmC5IQ" name="traceability" guid="_eYtQQO0KEdqHTdbLTmC5IQ" briefDescription="Traceability is a term used to describe the establishment and maintenance of relationships between artifacts, such as a requirement and a design class or a requirement and a test case, so that you can track the completeness of work &lt;strong&gt; &lt;/strong&gt;and assess the impact of changes." presentationName="Traceability">
+ <presentation xmi:id="-TksCtMgc0b4QqzwzniGvIw" href="uma://-TksCtMgc0b4QqzwzniGvIw#-TksCtMgc0b4QqzwzniGvIw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_qq0GMAXkEduj_7BEUj1JfQ" name="use_case_formats" guid="_qq0GMAXkEduj_7BEUj1JfQ" briefDescription="This guideline describes different use case formats and associated levels of detail that you may want to use, depending upon the nature of the project." presentationName="Use Case Formats">
+ <presentation xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" href="uma://-pQrBSyxJHLLodLbS4R_Zdw#-pQrBSyxJHLLodLbS4R_Zdw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_PgYREAeYEduWycDgioo5rg" name="feature" guid="_PgYREAeYEduWycDgioo5rg" presentationName="Feature">
+ <presentation xmi:id="-qpBnpWqiD7gjT08LjTMbsQ" href="uma://-qpBnpWqiD7gjT08LjTMbsQ#-qpBnpWqiD7gjT08LjTMbsQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_WUiFcAeYEduWycDgioo5rg" name="stakeholder_need" guid="_WUiFcAeYEduWycDgioo5rg" presentationName="Stakeholder Need">
+ <presentation xmi:id="-1pmL5bC27rtWB84PXAgq9Q" href="uma://-1pmL5bC27rtWB84PXAgq9Q#-1pmL5bC27rtWB84PXAgq9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_Vael8CGMEdu3VKXZx45D3A" name="supporting_requirements" guid="_Vael8CGMEdu3VKXZx45D3A" briefDescription="This check list is used to verify that all types of supporting requirements are considered." presentationName="Supporting Requirements">
+ <presentation xmi:id="-kw2vYHKDkWv2tZrDMrBPNA" href="uma://-kw2vYHKDkWv2tZrDMrBPNA#-kw2vYHKDkWv2tZrDMrBPNA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_oclg0DRXEdudA-StyUUwnw" name="supporting_requirements_intent_req" guid="_oclg0DRXEdudA-StyUUwnw" variabilityType="contributes" variabilityBasedOnElement="_BVh9cL-CEdqb7N6KIeDL8Q" checklists="_Vael8CGMEdu3VKXZx45D3A _jxn9EO0HEdqHTdbLTmC5IQ" guidelines="_wr24gNcGEdqz_d2XWoVt6Q" templates="_ItYXcNa9Edqrw4BYKyYKiA">
+ <presentation xmi:id="-SUqkkwrs1D_5YXZls-3YBg" href="uma://-SUqkkwrs1D_5YXZls-3YBg#-SUqkkwrs1D_5YXZls-3YBg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_qis78DRbEduFvfVCXiK3AA" name="use_case_intent_req" guid="_qis78DRbEduFvfVCXiK3AA" variabilityType="contributes" variabilityBasedOnElement="_0VGbUMlgEdmt3adZL5Dmdw" checklists="_0kNwINk1Edq2Q8qZoWbvGA" templates="_0cpNwMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-JcGDIeBIMM099mbWX5fXbA" href="uma://-JcGDIeBIMM099mbWX5fXbA#-JcGDIeBIMM099mbWX5fXbA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_6OAFQDRdEduFvfVCXiK3AA" name="vision_intent_req" guid="_6OAFQDRdEduFvfVCXiK3AA" variabilityType="contributes" variabilityBasedOnElement="_0WVxcMlgEdmt3adZL5Dmdw" templates="_0cW54MlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_t4QdAMNqEdu2IdAIaWZyAw" name="uc_model_evolve" guid="_t4QdAMNqEdu2IdAIaWZyAw" briefDescription="This example illustrates how the use-case model evolves over time when using a &quot;breadth before depth&quot; approach to maximize value and minimize risk early in the lifecycle and to minimize re-work later." presentationName="Evolution of the Use-Case Model">
+ <presentation xmi:id="-JviMIao63C7w9C8W6iPJrw" href="uma://-JviMIao63C7w9C8W6iPJrw#-JviMIao63C7w9C8W6iPJrw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_JLOiIMNvEdu2IdAIaWZyAw" name="use_case_spec" guid="_JLOiIMNvEdu2IdAIaWZyAw" briefDescription="This is an example of a completed use-case specification for the Withdraw Cash use case for an Automated Teller Machine." presentationName="Use-Case Specification" examples="_t4QdAMNqEdu2IdAIaWZyAw">
+ <presentation xmi:id="-qq-9Brh5oa6H3lsdp-m8mQ" href="uma://-qq-9Brh5oa6H3lsdp-m8mQ#-qq-9Brh5oa6H3lsdp-m8mQ"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_IIPZQDRjEduU7vV49F9N0A" name="test" guid="_IIPZQDRjEduU7vV49F9N0A" briefDescription="Portion of testing discipline that relates to Intent.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0iwc0clgEdmt3adZL5Dmdw" name="create_test_cases" guid="_0iwc0clgEdmt3adZL5Dmdw" briefDescription="Develop the test cases and test data for the requirements to be tested." presentationName="Create Test Cases" conceptsAndPapers="_0jnYcMlgEdmt3adZL5Dmdw" performedBy="_0ZM4MclgEdmt3adZL5Dmdw" mandatoryInput="_0VGbUMlgEdmt3adZL5Dmdw" output="_0ZS-0MlgEdmt3adZL5Dmdw" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0YDosMlgEdmt3adZL5Dmdw" optionalInput="_0ZS-0MlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q">
+ <presentation xmi:id="_NrVKsKeqEdmKDbQuyzCoqQ" href="uma://_NrVKsKeqEdmKDbQuyzCoqQ#_NrVKsKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0jnYcMlgEdmt3adZL5Dmdw" name="test_ideas" guid="_0jnYcMlgEdmt3adZL5Dmdw" briefDescription="A list of test ideas sorted in decreasing order of importance and associated with specific testing strategies used to create executable tests." presentationName="Test Ideas">
+ <presentation xmi:id="_uqL2gMM3EdmSIPI87WLu3g" href="uma://_uqL2gMM3EdmSIPI87WLu3g#_uqL2gMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0aJ6cMlgEdmt3adZL5Dmdw" name="types_of_test" guid="_0aJ6cMlgEdmt3adZL5Dmdw" briefDescription="Testing is applied to different types of targets, in different stages or levels of work effort. This Concept introduces various types of test." presentationName="Types of Test">
+ <presentation xmi:id="_y-_PIMPdEdmbOvqy4O0adg" href="uma://_y-_PIMPdEdmbOvqy4O0adg#_y-_PIMPdEdmbOvqy4O0adg"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZsK30EvBEdunZcj9T5hrMQ" name="actor" guid="_ZsK30EvBEdunZcj9T5hrMQ" presentationName="actor">
+ <presentation xmi:id="-4RQJzq_1URTZ5FGCBKnTIw" href="uma://-4RQJzq_1URTZ5FGCBKnTIw#-4RQJzq_1URTZ5FGCBKnTIw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_GEAwAEvCEdunZcj9T5hrMQ" name="analyst" guid="_GEAwAEvCEdunZcj9T5hrMQ" presentationName="analyst">
+ <presentation xmi:id="-1RwpgmmY974S0YkxEOFDCw" href="uma://-1RwpgmmY974S0YkxEOFDCw#-1RwpgmmY974S0YkxEOFDCw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_NtGL0EvDEdunZcj9T5hrMQ" name="business_rule" guid="_NtGL0EvDEdunZcj9T5hrMQ" presentationName="business rule">
+ <presentation xmi:id="-COrjB4k8Qtf6ZpPEcBNwpw" href="uma://-COrjB4k8Qtf6ZpPEcBNwpw#-COrjB4k8Qtf6ZpPEcBNwpw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ZH6M0EvEEdunZcj9T5hrMQ" name="furps" guid="_ZH6M0EvEEdunZcj9T5hrMQ" presentationName="FURPS+">
+ <presentation xmi:id="-vq2pL6yQuqGhql9Wo_Av4w" href="uma://-vq2pL6yQuqGhql9Wo_Av4w#-vq2pL6yQuqGhql9Wo_Av4w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_VhhDMEvrEdunZcj9T5hrMQ" name="glossary" guid="_VhhDMEvrEdunZcj9T5hrMQ" presentationName="glossary">
+ <presentation xmi:id="-05pn_DGdNui9qqwx46iKZQ" href="uma://-05pn_DGdNui9qqwx46iKZQ#-05pn_DGdNui9qqwx46iKZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_U_olUEvDEdunZcj9T5hrMQ" name="supporting_requirement" guid="_U_olUEvDEdunZcj9T5hrMQ" presentationName="Supporting Requirements">
+ <presentation xmi:id="-ketzwgDgY82DMyfuHqu3Cw" href="uma://-ketzwgDgY82DMyfuHqu3Cw#-ketzwgDgY82DMyfuHqu3Cw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_IHRO8EvHEdunZcj9T5hrMQ" name="use_case" guid="_IHRO8EvHEdunZcj9T5hrMQ" presentationName="use case">
+ <presentation xmi:id="-HDfMzDXoilK-f2iNreHRVg" href="uma://-HDfMzDXoilK-f2iNreHRVg#-HDfMzDXoilK-f2iNreHRVg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_k6B3kEvmEdunZcj9T5hrMQ" name="use_case_model" guid="_k6B3kEvmEdunZcj9T5hrMQ" presentationName="use-case model">
+ <presentation xmi:id="-UTrE64wEDJIC1FRUomEYDg" href="uma://-UTrE64wEDJIC1FRUomEYDg#-UTrE64wEDJIC1FRUomEYDg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_oXmYMEvGEdunZcj9T5hrMQ" name="use_case_scenario" guid="_oXmYMEvGEdunZcj9T5hrMQ" presentationName="use-case scenario">
+ <presentation xmi:id="-t3jNM5ZWkYtzB8A4Chz2Vw" href="uma://-t3jNM5ZWkYtzB8A4Chz2Vw#-t3jNM5ZWkYtzB8A4Chz2Vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_J_5kgEvHEdunZcj9T5hrMQ" name="vision" guid="_J_5kgEvHEdunZcj9T5hrMQ" presentationName="vision">
+ <presentation xmi:id="-VMnkFJpPLdEDUpbz2QDgow" href="uma://-VMnkFJpPLdEDUpbz2QDgow#-VMnkFJpPLdEDUpbz2QDgow"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_kB42IDRiEduU7vV49F9N0A" name="solution" guid="_kB42IDRiEduU7vV49F9N0A" briefDescription="Solution sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0WuL8MlgEdmt3adZL5Dmdw" name="architecture" guid="_0WuL8MlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0WuL8clgEdmt3adZL5Dmdw" name="visual_modeling" guid="_0WuL8clgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0XY6UMlgEdmt3adZL5Dmdw" name="visual_modeling" guid="_0XY6UMlgEdmt3adZL5Dmdw" briefDescription="This concept introduces the use of semantically rich graphical and textual design notations to capture software designs." presentationName="Visual Modeling" guidelines="_we3F4ACpEdu8m4dIntu6jA">
+ <presentation xmi:id="_SB1n8MM1EdmSIPI87WLu3g" href="uma://_SB1n8MM1EdmSIPI87WLu3g#_SB1n8MM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_lRV2QEvkEduCAaECSrUMPQ" name="architecture_vm" guid="_lRV2QEvkEduCAaECSrUMPQ" variabilityType="contributes" variabilityBasedOnElement="_0XAf0MlgEdmt3adZL5Dmdw" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_HZGFsKrPEdu6T6WyNqBzqQ" name="component_vm" guid="_HZGFsKrPEdu6T6WyNqBzqQ" variabilityType="contributes" variabilityBasedOnElement="_0YP18MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-zfl87vJBFdinDB02ArLXOQ" href="uma://-zfl87vJBFdinDB02ArLXOQ#-zfl87vJBFdinDB02ArLXOQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_34jWsLcIEduRNaXpzCOLXQ" name="abstract_away_complexity_vm" guid="_34jWsLcIEduRNaXpzCOLXQ" variabilityType="contributes" variabilityBasedOnElement="_we3F4ACpEdu8m4dIntu6jA" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-OcMsciNn-UtD9fTHj26LGA" href="uma://-OcMsciNn-UtD9fTHj26LGA#-OcMsciNn-UtD9fTHj26LGA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_SYDjUMUKEdu5GrwIlTJV7g" name="analyze_arch_reqs_vm" guid="_SYDjUMUKEdu5GrwIlTJV7g" variabilityType="contributes" variabilityBasedOnElement="_42UD4A3tEduibvKwrGxWxA" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-I-2SvZtjELUYDQO0jvdxEA" href="uma://-I-2SvZtjELUYDQO0jvdxEA#-I-2SvZtjELUYDQO0jvdxEA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_douywISSEdu8NaFPL8nS_w" name="uc_modeling" guid="_douywISSEdu8NaFPL8nS_w">
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_YdaogAI9Edu5WetVoS7Gvw" name="analyze_arch_reqs_ucm" guid="_YdaogAI9Edu5WetVoS7Gvw" variabilityType="contributes" variabilityBasedOnElement="_0f-1oMlgEdmt3adZL5Dmdw" mandatoryInput="_W2SgEDR5EdutE_HNDTJk5Q"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_h15dULCxEdujaOuld2kPdg" name="deprecated" guid="_h15dULCxEdujaOuld2kPdg" briefDescription="This is a temporary content package to hold old copies of elements while they are refactored for release 1.0 It should be deleted before final release. This package should not be published.">
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0cr7cACrEdu8m4dIntu6jA" name="using_patterns" guid="_0cr7cACrEdu8m4dIntu6jA" briefDescription="This guidance discusses the practical application of patterns in a project." presentationName="Using Patterns">
+ <presentation xmi:id="-U-5cLUk-mdaO518lh5CxTQ" href="uma://-U-5cLUk-mdaO518lh5CxTQ#-U-5cLUk-mdaO518lh5CxTQ"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0YJvUMlgEdmt3adZL5Dmdw" name="pattern" guid="_0YJvUMlgEdmt3adZL5Dmdw" briefDescription="A generalized solution that can be implemented and applied in a problem situation (a context) and thereby eliminate one or more of the inherent problems." presentationName="Pattern">
+ <presentation xmi:id="_QvmkAMM1EdmSIPI87WLu3g" href="uma://_QvmkAMM1EdmSIPI87WLu3g#_QvmkAMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0YP18MlgEdmt3adZL5Dmdw" name="component" guid="_0YP18MlgEdmt3adZL5Dmdw" briefDescription="An encapsulated part of a system that is, ideally, a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of well-defined architecture." presentationName="Component">
+ <presentation xmi:id="_TZiasMM1EdmSIPI87WLu3g" href="uma://_TZiasMM1EdmSIPI87WLu3g#_TZiasMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0f-1oMlgEdmt3adZL5Dmdw" name="analyze_arch_reqs" guid="_0f-1oMlgEdmt3adZL5Dmdw" briefDescription="Analyze the architecturally significant requirements and define a candidate architecture for the system. Define the architectural patterns, key mechanisms, and where applicable, modeling conventions for the system." presentationName="Analyze the Architectural Requirements" conceptsAndPapers="_HrZGIA4MEduibvKwrGxWxA _mzxI0A4LEduibvKwrGxWxA __O7tAMVvEduLYZUGfgZrkQ" guidelines="_42UD4A3tEduibvKwrGxWxA _0gpkAMlgEdmt3adZL5Dmdw" performedBy="_0X9iEMlgEdmt3adZL5Dmdw" mandatoryInput="_Wn7HcNcEEdqz_d2XWoVt6Q _0WVxcMlgEdmt3adZL5Dmdw" output="_0XAf0MlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0a0o0MlgEdmt3adZL5Dmdw" optionalInput="_0WuL8slgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw _0VGbUMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q">
+ <presentation xmi:id="_qDRSULBKEdm7Eph_l9Cn9w" href="uma://_qDRSULBKEdm7Eph_l9Cn9w#_qDRSULBKEdm7Eph_l9Cn9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0gRJgMlgEdmt3adZL5Dmdw" name="develop_arch" guid="_0gRJgMlgEdmt3adZL5Dmdw" briefDescription="Make concrete decisions about the architecture to provide guidance and direction to the development work for the iteration." presentationName="Develop the Architecture" conceptsAndPapers="_Z53x0BapEduSTJywppIxVQ _w2ACwA4LEduibvKwrGxWxA _mzxI0A4LEduibvKwrGxWxA _HrZGIA4MEduibvKwrGxWxA __O7tAMVvEduLYZUGfgZrkQ" guidelines="_mDf2EBapEduSTJywppIxVQ" performedBy="_0X9iEMlgEdmt3adZL5Dmdw" mandatoryInput="_0WuL8slgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _0VGbUMlgEdmt3adZL5Dmdw _0WVxcMlgEdmt3adZL5Dmdw _0YuXEMlgEdmt3adZL5Dmdw" output="_0WuL8slgEdmt3adZL5Dmdw _0XAf0MlgEdmt3adZL5Dmdw" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0a0o0MlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_rUis8LBKEdm7Eph_l9Cn9w" href="uma://_rUis8LBKEdm7Eph_l9Cn9w#_rUis8LBKEdm7Eph_l9Cn9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0XAf0MlgEdmt3adZL5Dmdw" name="architecture_notebook" guid="_0XAf0MlgEdmt3adZL5Dmdw" briefDescription="The Architecture Notebook describes the blueprint for software development. It contains the rationale, assumptions, explanations and implications of the decisions that were made in forming the architecture." presentationName="Architecture Notebook" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw _0YP18MlgEdmt3adZL5Dmdw __O7tAMVvEduLYZUGfgZrkQ" checklists="_17PYUNd6EdmIm-bsRSNCgw" guidelines="_T9nygClEEduLGM8dfVsrKg _0gpkAMlgEdmt3adZL5Dmdw _0gjdYMlgEdmt3adZL5Dmdw _we3F4ACpEdu8m4dIntu6jA" templates="__JXkoCk8EduLGM8dfVsrKg">
+ <presentation xmi:id="_H4gOYKYTEdmvhNXG0Oc2uA" href="uma://_H4gOYKYTEdmvhNXG0Oc2uA#_H4gOYKYTEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0gvqoMlgEdmt3adZL5Dmdw" name="analysis_mechanism" guid="_0gvqoMlgEdmt3adZL5Dmdw" briefDescription="An Analysis Mechanism is a conceptual representation of an Architectural Mechanism." presentationName="Analysis Mechanism" conceptsAndPapers="_HrZGIA4MEduibvKwrGxWxA _mzxI0A4LEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA" guidelines="_4k_HsA4LEduibvKwrGxWxA _4k_HsQ4LEduibvKwrGxWxA">
+ <presentation xmi:id="_S8KCcMP2EdmWKcx6ixEiwg" href="uma://_S8KCcMP2EdmWKcx6ixEiwg#_S8KCcMP2EdmWKcx6ixEiwg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_17PYUNd6EdmIm-bsRSNCgw" name="architecture" guid="_17PYUNd6EdmIm-bsRSNCgw" briefDescription="This checklist provides questions to help in evaluating whether architectural decisions have been captured appropriately." presentationName="Architecture" conceptsAndPapers="_mzxI0A4LEduibvKwrGxWxA">
+ <presentation xmi:id="_17Ve8Nd6EdmIm-bsRSNCgw" href="uma://_17Ve8Nd6EdmIm-bsRSNCgw#_17Ve8Nd6EdmIm-bsRSNCgw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0gpkAMlgEdmt3adZL5Dmdw" name="layering" guid="_0gpkAMlgEdmt3adZL5Dmdw" briefDescription="Guidance on the possible ways for partitioning the system." presentationName="Layering" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw" guidelines="_0cr7cACrEdu8m4dIntu6jA">
+ <presentation xmi:id="_lbGQwMM3EdmSIPI87WLu3g" href="uma://_lbGQwMM3EdmSIPI87WLu3g#_lbGQwMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0gjdYMlgEdmt3adZL5Dmdw" name="repres_interfaces_to_ext_systems" guid="_0gjdYMlgEdmt3adZL5Dmdw" briefDescription="This guideline introduces system level interfaces." presentationName="Representing Interfaces to External Systems" conceptsAndPapers="_uF-QYEAhEdq_UJTvM1DM2Q">
+ <presentation xmi:id="_iCwb8MM3EdmSIPI87WLu3g" href="uma://_iCwb8MM3EdmSIPI87WLu3g#_iCwb8MM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_42UD4A3tEduibvKwrGxWxA" name="analyze_arch_reqs" guid="_42UD4A3tEduibvKwrGxWxA" briefDescription="This guideline provides additional information to support the analysis of architecturally significant requirements and the creation of an outline architecture." presentationName="Analyze the Architectural Requirements" guidelines="_0gpkAMlgEdmt3adZL5Dmdw _T9nygClEEduLGM8dfVsrKg">
+ <presentation xmi:id="-YeVRerdEixh4HgHOuw2KRQ" href="uma://-YeVRerdEixh4HgHOuw2KRQ#-YeVRerdEixh4HgHOuw2KRQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_mzxI0A4LEduibvKwrGxWxA" name="arch_mech" guid="_mzxI0A4LEduibvKwrGxWxA" briefDescription="Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity." presentationName="Architectural Mechanism" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw _0gvqoMlgEdmt3adZL5Dmdw _HrZGIA4MEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA" guidelines="_4k_HsA4LEduibvKwrGxWxA _4k_HsQ4LEduibvKwrGxWxA _4k_Hsg4LEduibvKwrGxWxA">
+ <presentation xmi:id="-SJrpVySJ2npYs8NwGvnHjw" href="uma://-SJrpVySJ2npYs8NwGvnHjw#-SJrpVySJ2npYs8NwGvnHjw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_w2ACwA4LEduibvKwrGxWxA" name="design_mechanism" guid="_w2ACwA4LEduibvKwrGxWxA" briefDescription="A Design Mechanism is a concrete representation of an Architectural Mechanism." presentationName="Design Mechanism" conceptsAndPapers="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _0LcUkA4LEduibvKwrGxWxA _0YJvUMlgEdmt3adZL5Dmdw" guidelines="_4k_Hsg4LEduibvKwrGxWxA _0cr7cACrEdu8m4dIntu6jA">
+ <presentation xmi:id="-EG22TRyJ5TDKW6U88AXfhw" href="uma://-EG22TRyJ5TDKW6U88AXfhw#-EG22TRyJ5TDKW6U88AXfhw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0LcUkA4LEduibvKwrGxWxA" name="implementation_mechanism" guid="_0LcUkA4LEduibvKwrGxWxA" briefDescription="A representation of an Architecture Mechanism that uses a specific programming language or product." presentationName="Implementation Mechanism" conceptsAndPapers="_0gvqoMlgEdmt3adZL5Dmdw _mzxI0A4LEduibvKwrGxWxA _w2ACwA4LEduibvKwrGxWxA" guidelines="_4k_Hsg4LEduibvKwrGxWxA">
+ <presentation xmi:id="-Rex8oOBv985RruZNrCW0rg" href="uma://-Rex8oOBv985RruZNrCW0rg#-Rex8oOBv985RruZNrCW0rg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4k_HsA4LEduibvKwrGxWxA" name="example_analysis_mechanisms_descr" guid="_4k_HsA4LEduibvKwrGxWxA" briefDescription="Examples showing how to describe Analysis Mechanisms" presentationName="Example Analysis Mechanism Descriptions">
+ <presentation xmi:id="-CJ--jlBqXi3FzdOM_dw5_w" href="uma://-CJ--jlBqXi3FzdOM_dw5_w#-CJ--jlBqXi3FzdOM_dw5_w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4k_HsQ4LEduibvKwrGxWxA" name="example_architectural_mechanisms" guid="_4k_HsQ4LEduibvKwrGxWxA" briefDescription="Commonly encountered architectural mechanisms" presentationName="Example Architectural Mechanisms">
+ <presentation xmi:id="-FqP5LgLVrlhvFC_eeYd_vA" href="uma://-FqP5LgLVrlhvFC_eeYd_vA#-FqP5LgLVrlhvFC_eeYd_vA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_4k_Hsg4LEduibvKwrGxWxA" name="example_design_mechanisms" guid="_4k_Hsg4LEduibvKwrGxWxA" briefDescription="Examples that show how to describe design mechanisms" presentationName="Example: Design Mechanisms">
+ <presentation xmi:id="-mAo18f36rZ1R98kpZX7HMw" href="uma://-mAo18f36rZ1R98kpZX7HMw#-mAo18f36rZ1R98kpZX7HMw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_HrZGIA4MEduibvKwrGxWxA" name="architecturally_significant_requirements" guid="_HrZGIA4MEduibvKwrGxWxA" briefDescription="Some requirements have a profound impact on the architecture of the solution and require special attention." presentationName="Architecturally Significant Requirements">
+ <presentation xmi:id="-EytH4BCNGiHF6pZrp8ISCw" href="uma://-EytH4BCNGiHF6pZrp8ISCw#-EytH4BCNGiHF6pZrp8ISCw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Z53x0BapEduSTJywppIxVQ" name="business_pattern" guid="_Z53x0BapEduSTJywppIxVQ" briefDescription="A re-usable portion of design that can be applied to multiple domain-specific activities." presentationName="Business Pattern" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw" guidelines="_0cr7cACrEdu8m4dIntu6jA">
+ <presentation xmi:id="-Of51hmgdsO_U2-pnbJ67Cg" href="uma://-Of51hmgdsO_U2-pnbJ67Cg#-Of51hmgdsO_U2-pnbJ67Cg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_mDf2EBapEduSTJywppIxVQ" name="develop_architecture" guid="_mDf2EBapEduSTJywppIxVQ" briefDescription="This guideline provides additional information to support the ongoing refinement and development of the architecture." presentationName="Develop the Architecture" conceptsAndPapers="_Z53x0BapEduSTJywppIxVQ" guidelines="_T9nygClEEduLGM8dfVsrKg">
+ <presentation xmi:id="-t7mQSRPYITkMoYRVNz7jQg" href="uma://-t7mQSRPYITkMoYRVNz7jQg#-t7mQSRPYITkMoYRVNz7jQg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_T9nygClEEduLGM8dfVsrKg" name="architectural_view" guid="_T9nygClEEduLGM8dfVsrKg" briefDescription="Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of the system." presentationName="Architectural View" guidelines="_0X3bcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-cnGBBA4NXmhTIjHjlHx4Mw" href="uma://-cnGBBA4NXmhTIjHjlHx4Mw#-cnGBBA4NXmhTIjHjlHx4Mw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_cH6f0DR7EduwLdLujGQAIQ" name="architect_sln" guid="_cH6f0DR7EduwLdLujGQAIQ" variabilityType="contributes" variabilityBasedOnElement="_0X9iEMlgEdmt3adZL5Dmdw" conceptsAndPapers="__O7tAMVvEduLYZUGfgZrkQ" responsibleFor="_0XAf0MlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_we3F4ACpEdu8m4dIntu6jA" name="abstract_away_complexity" guid="_we3F4ACpEdu8m4dIntu6jA" presentationName="Abstract Away Complexity" conceptsAndPapers="_0YJvUMlgEdmt3adZL5Dmdw _0YP18MlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-X7QSjItNBz7w8603yBCv0Q" href="uma://-X7QSjItNBz7w8603yBCv0Q#-X7QSjItNBz7w8603yBCv0Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="__O7tAMVvEduLYZUGfgZrkQ" name="software_architecture" guid="__O7tAMVvEduLYZUGfgZrkQ" briefDescription="The software architecture represents the structure or structures of the system, which consists of software components, the externally visible properties of those components, and the relationships among them." presentationName="Software Architecture">
+ <presentation xmi:id="-UQ_e8kozIP11Xu008RJd-A" href="uma://-UQ_e8kozIP11Xu008RJd-A#-UQ_e8kozIP11Xu008RJd-A"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0YcDMMlgEdmt3adZL5Dmdw" name="development" guid="_0YcDMMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_PGDx8PisEdmjyaJMRcPDWA" name="visual_modeling" guid="_PGDx8PisEdmjyaJMRcPDWA">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_ZTGAYL3uEdqLRJZPGVbHDA" name="design_vm" guid="_ZTGAYL3uEdqLRJZPGVbHDA" variabilityType="contributes" variabilityBasedOnElement="_0WuL8slgEdmt3adZL5Dmdw" conceptsAndPapers="_0XY6UMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_T8WvwL3vEdqLRJZPGVbHDA" name="design_solution_vm" guid="_T8WvwL3vEdqLRJZPGVbHDA" briefDescription="Render the design visually to aid in solving the problem and communicating the solution." orderingGuide="<?xml version="1.0" encoding="ASCII"?> <com.ibm.uma.edit.tng.util.model:OrderInfoCollection xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma.edit.tng.util.model="http:///com/ibm/uma/edit/tng/util/model.ecore"> <orderInfos name="sections" timestamp="1146255243164"> <gUIDs>_4Z7WYKuKEdmhFZtkg1nakg</gUIDs> <gUIDs>_YiTAIL3vEdqLRJZPGVbHDA</gUIDs> <gUIDs>_--6tYKuKEdmhFZtkg1nakg</gUIDs> <gUIDs>_RBAyANbzEdqu5o2S60g5LA</gUIDs> <gUIDs>_A_LU8KuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_ObN0cNbzEdqu5o2S60g5LA</gUIDs> <gUIDs>_ENwJwKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_Gyf-cKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_JrHKUKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_KNZYAKuLEdmhFZtkg1nakg</gUIDs> <gUIDs>_OGYbwKuLEdmhFZtkg1nakg</gUIDs> </orderInfos> </com.ibm.uma.edit.tng.util.model:OrderInfoCollection> " variabilityType="contributes" variabilityBasedOnElement="_0fshwMlgEdmt3adZL5Dmdw" guidelines="_2uan8NbyEdqu5o2S60g5LA _CFAswNbzEdqu5o2S60g5LA _1fM3AC9_EduW5uTjiIcspQ _ienXEEyAEdu-df7p0PuRvQ">
+ <presentation xmi:id="-_BAmniONtHWbpHQH7znR3g" href="uma://-_BAmniONtHWbpHQH7znR3g#-_BAmniONtHWbpHQH7znR3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_2uan8NbyEdqu5o2S60g5LA" name="uc_realizations" guid="_2uan8NbyEdqu5o2S60g5LA" briefDescription="A use-case realization represents how a use case will be implemented in terms of collaborating objects. This guideline describes its purpose and UML notation." presentationName="Use-Cases Realizations" conceptsAndPapers="_uF-QYEAhEdq_UJTvM1DM2Q">
+ <presentation xmi:id="-CFYVionNDLkMw6SG6runQA" href="uma://-CFYVionNDLkMw6SG6runQA#-CFYVionNDLkMw6SG6runQA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_CFAswNbzEdqu5o2S60g5LA" name="design_components" guid="_CFAswNbzEdqu5o2S60g5LA" briefDescription="This guideline describes how to visually represent design components." presentationName="Design Components Representation">
+ <presentation xmi:id="-6ep_EyK3ZO6vRGWtAqoJ-A" href="uma://-6ep_EyK3ZO6vRGWtAqoJ-A#-6ep_EyK3ZO6vRGWtAqoJ-A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_sypCEPvjEdqf0-top1XJIg" name="developer_vm" guid="_sypCEPvjEdqf0-top1XJIg" variabilityType="contributes" variabilityBasedOnElement="_BCtiMDR9EduwLdLujGQAIQ">
+ <presentation xmi:id="-xbAirPdH1IOKcnklk8hdqw" href="uma://-xbAirPdH1IOKcnklk8hdqw#-xbAirPdH1IOKcnklk8hdqw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_1fM3AC9_EduW5uTjiIcspQ" name="designing_visually" guid="_1fM3AC9_EduW5uTjiIcspQ" briefDescription="This guideline provides information on how to apply visual modeling to designing a system." presentationName="Designing Visually">
+ <presentation xmi:id="-1xE2ZW3MjNAJ7jkaZNbkww" href="uma://-1xE2ZW3MjNAJ7jkaZNbkww#-1xE2ZW3MjNAJ7jkaZNbkww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_nnSXcD6SEduAL-bCqar_dg" name="design_vm" guid="_nnSXcD6SEduAL-bCqar_dg" variabilityType="contributes" variabilityBasedOnElement="_0XSzsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-HQSI39vBrjpmQL1qHYOJtA" href="uma://-HQSI39vBrjpmQL1qHYOJtA#-HQSI39vBrjpmQL1qHYOJtA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_ienXEEyAEdu-df7p0PuRvQ" name="data_modeling" guid="_ienXEEyAEdu-df7p0PuRvQ" briefDescription="A physical data model (PDM) captures the design of a persistent data store such as a relational database or data file. Data modeling is the act of creating such a model." presentationName="Physical Data Modeling">
+ <presentation xmi:id="-XMbxFU8M85cRlf3C4iwAGw" href="uma://-XMbxFU8M85cRlf3C4iwAGw#-XMbxFU8M85cRlf3C4iwAGw"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YoQcMlgEdmt3adZL5Dmdw" name="implementation" guid="_0YoQcMlgEdmt3adZL5Dmdw" briefDescription="Software code files, data files, and supporting files such as online help files that represent the raw parts of a system that can be built." presentationName="Implementation" guidelines="_0Y0dsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_6u9ZsKYcEdmvhNXG0Oc2uA" href="uma://_6u9ZsKYcEdmvhNXG0Oc2uA#_6u9ZsKYcEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YuXEMlgEdmt3adZL5Dmdw" name="build" guid="_0YuXEMlgEdmt3adZL5Dmdw" briefDescription="An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product." presentationName="Build" conceptsAndPapers="_B3xkEPD0EdqYgerqi84oCA" guidelines="_SM4YIL6dEdqti4GwqTkbsQ _i8bUEL6cEdqti4GwqTkbsQ">
+ <presentation xmi:id="_NqSB0KeqEdmKDbQuyzCoqQ" href="uma://_NqSB0KeqEdmKDbQuyzCoqQ#_NqSB0KeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0YuXEclgEdmt3adZL5Dmdw" name="developer_test" guid="_0YuXEclgEdmt3adZL5Dmdw" briefDescription="The instructions that validate individual software components perform as specified." presentationName="Developer Test" conceptsAndPapers="_0Y6kUMlgEdmt3adZL5Dmdw" guidelines="_eRutgC5QEduVhuZHT5jKZQ">
+ <presentation xmi:id="_NqSB0qeqEdmKDbQuyzCoqQ" href="uma://_NqSB0qeqEdmKDbQuyzCoqQ#_NqSB0qeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0Y0dsMlgEdmt3adZL5Dmdw" name="implementation" guid="_0Y0dsMlgEdmt3adZL5Dmdw" briefDescription="This guideline describes the different types of elements in an implementation." presentationName="Implementation">
+ <presentation xmi:id="_4wqaMMPaEdmbOvqy4O0adg" href="uma://_4wqaMMPaEdmbOvqy4O0adg#_4wqaMMPaEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0Y6kUMlgEdmt3adZL5Dmdw" name="test_first_design" guid="_0Y6kUMlgEdmt3adZL5Dmdw" briefDescription="This concept explains how to bring test design chronologically in-line with software design." presentationName="Test-first Design">
+ <presentation xmi:id="_Hg5UUMPbEdmbOvqy4O0adg" href="uma://_Hg5UUMPbEdmbOvqy4O0adg#_Hg5UUMPbEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0hyzgMlgEdmt3adZL5Dmdw" name="implement_solution" guid="_0hyzgMlgEdmt3adZL5Dmdw" briefDescription="Implement source code to provide new functionality or fix defects." presentationName="Implement the Solution" conceptsAndPapers="_0Y6kUMlgEdmt3adZL5Dmdw _B3xkEPD0EdqYgerqi84oCA _Poc7IPDzEdqYgerqi84oCA" guidelines="_0Y0dsMlgEdmt3adZL5Dmdw _SM4YIL6dEdqti4GwqTkbsQ" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_0WuL8slgEdmt3adZL5Dmdw" output="_0YoQcMlgEdmt3adZL5Dmdw _0YuXEMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _0VGbUMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0YoQcMlgEdmt3adZL5Dmdw _BVh9cL-CEdqb7N6KIeDL8Q _0VGbUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_d2aMwKrMEdmqUqi7YGiSxw" href="uma://_d2aMwKrMEdmqUqi7YGiSxw#_d2aMwKrMEdmqUqi7YGiSxw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0iL1EMlgEdmt3adZL5Dmdw" name="impl_developer_tests" guid="_0iL1EMlgEdmt3adZL5Dmdw" briefDescription="Implement one or more tests that enable the validation of the individual software components through execution." presentationName="Implement Developer Tests" conceptsAndPapers="_0Y6kUMlgEdmt3adZL5Dmdw _aFeZgJquEdukqcRKZBQN9w" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_0YoQcMlgEdmt3adZL5Dmdw" output="_0YuXEclgEdmt3adZL5Dmdw" additionallyPerformedBy="_0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0WuL8slgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_dWPe8KrMEdmqUqi7YGiSxw" href="uma://_dWPe8KrMEdmqUqi7YGiSxw#_dWPe8KrMEdmqUqi7YGiSxw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0iYCUMlgEdmt3adZL5Dmdw" name="run_developer_tests" guid="_0iYCUMlgEdmt3adZL5Dmdw" briefDescription="Run tests of the individual software components to verify that their internal structures work as specified." presentationName="Run Developer Tests" conceptsAndPapers="_aFeZgJquEdukqcRKZBQN9w" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw" output="_0ZlSsMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_0ZM4MclgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_W6rc0Lv7EdmmUvZAZjqE3g" href="uma://_W6rc0Lv7EdmmUvZAZjqE3g#_W6rc0Lv7EdmmUvZAZjqE3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0WuL8slgEdmt3adZL5Dmdw" name="design" guid="_0WuL8slgEdmt3adZL5Dmdw" briefDescription="This artifact describes the realization of required system functionality in terms of components and serves as an abstraction of the source code." presentationName="Design" checklists="_0XSzsMlgEdmt3adZL5Dmdw" guidelines="_0X3bcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" href="uma://_zxB-QKYcEdmvhNXG0Oc2uA#_zxB-QKYcEdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0fshwMlgEdmt3adZL5Dmdw" name="design_solution" guid="_0fshwMlgEdmt3adZL5Dmdw" briefDescription="Identify the elements and devise the interactions, behavior, relations, and data necessary to realize some functionality." presentationName="Design the Solution" conceptsAndPapers="_uF-QYEAhEdq_UJTvM1DM2Q _mzxI0A4LEduibvKwrGxWxA" guidelines="_0X3bcMlgEdmt3adZL5Dmdw _0cr7cACrEdu8m4dIntu6jA" performedBy="_0YDosMlgEdmt3adZL5Dmdw" mandatoryInput="_BVh9cL-CEdqb7N6KIeDL8Q _0XAf0MlgEdmt3adZL5Dmdw _0VGbUMlgEdmt3adZL5Dmdw" output="_0WuL8slgEdmt3adZL5Dmdw" additionallyPerformedBy="_0X9iEMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0WuL8slgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NrC20qeqEdmKDbQuyzCoqQ" href="uma://_NrC20qeqEdmKDbQuyzCoqQ#_NrC20qeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0XSzsMlgEdmt3adZL5Dmdw" name="design" guid="_0XSzsMlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that the design is created in a consistent and complete manner." presentationName="Design">
+ <presentation xmi:id="_YIYIYMM1EdmSIPI87WLu3g" href="uma://_YIYIYMM1EdmSIPI87WLu3g#_YIYIYMM1EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0X3bcMlgEdmt3adZL5Dmdw" name="design" guid="_0X3bcMlgEdmt3adZL5Dmdw" briefDescription="This guideline gives additional information on how to design a portion of the system." presentationName="Design">
+ <presentation xmi:id="_Qo7pYMM3EdmSIPI87WLu3g" href="uma://_Qo7pYMM3EdmSIPI87WLu3g#_Qo7pYMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_i8bUEL6cEdqti4GwqTkbsQ" name="continuous_integration" guid="_i8bUEL6cEdqti4GwqTkbsQ" briefDescription="This guideline describes how to apply continuous integration to improve the integration of units into the code base." presentationName="Continuous Integration" conceptsAndPapers="_B3xkEPD0EdqYgerqi84oCA">
+ <presentation xmi:id="-DlaqJu4sEqMPk84qhJ6IEA" href="uma://-DlaqJu4sEqMPk84qhJ6IEA#-DlaqJu4sEqMPk84qhJ6IEA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_SM4YIL6dEdqti4GwqTkbsQ" name="promoting_builds" guid="_SM4YIL6dEdqti4GwqTkbsQ" briefDescription="This guideline describes how to migrate a build up through a set of tiers from a private development area to a release area." presentationName="Promoting Builds" conceptsAndPapers="_0cEmAMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ" href="uma://-zCM2ucJJxc_bQr_LoHlSaQ#-zCM2ucJJxc_bQr_LoHlSaQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_uF-QYEAhEdq_UJTvM1DM2Q" name="entity_control_boundary_pattern" guid="_uF-QYEAhEdq_UJTvM1DM2Q" briefDescription="This concept introduces a pattern that provides a starting point for the distribution of responsibilities to a set of interacting design elements based on three key perspectives in a collaboration." presentationName="Entity-Control-Boundary Pattern">
+ <presentation xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" href="uma://-awaQ_2dwhGyKRoVKQ-esPQ#-awaQ_2dwhGyKRoVKQ-esPQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_Poc7IPDzEdqYgerqi84oCA" name="refactoring" guid="_Poc7IPDzEdqYgerqi84oCA" briefDescription="This concept explains ways of improving the design of existing code in a way that does not alter its external behavior." presentationName="Refactoring">
+ <presentation xmi:id="-fj_9xjbrpaYNSETyCz5yJg" href="uma://-fj_9xjbrpaYNSETyCz5yJg#-fj_9xjbrpaYNSETyCz5yJg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_B3xkEPD0EdqYgerqi84oCA" name="continuous_integration" guid="_B3xkEPD0EdqYgerqi84oCA" briefDescription="This concept introduces the idea of creating regular (at least daily) integrations in order to reduce integration risks, find bugs earlier, and drive a collaborative work environment." presentationName="Continuous Integration" variabilityType="replaces">
+ <presentation xmi:id="-dhAMzNZNWufBnW0fPYQtBA" href="uma://-dhAMzNZNWufBnW0fPYQtBA#-dhAMzNZNWufBnW0fPYQtBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_eRutgC5QEduVhuZHT5jKZQ" name="types_of_developer_tests" guid="_eRutgC5QEduVhuZHT5jKZQ" briefDescription="This guideline describes various types of developer tests." presentationName="Types of Developer Tests">
+ <presentation xmi:id="-VGT8iHGtQSiOUGitq1qmow" href="uma://-VGT8iHGtQSiOUGitq1qmow#-VGT8iHGtQSiOUGitq1qmow"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_BCtiMDR9EduwLdLujGQAIQ" name="developer_sln" guid="_BCtiMDR9EduwLdLujGQAIQ" variabilityType="contributes" variabilityBasedOnElement="_0YDosMlgEdmt3adZL5Dmdw" responsibleFor="_0YuXEMlgEdmt3adZL5Dmdw _0WuL8slgEdmt3adZL5Dmdw _0YuXEclgEdmt3adZL5Dmdw _0YoQcMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_aFeZgJquEdukqcRKZBQN9w" name="developer_testing" guid="_aFeZgJquEdukqcRKZBQN9w" briefDescription="Developers regression test their code on a continuous basis to ensure that it works as expected." presentationName="Developer Testing">
+ <presentation xmi:id="-Ff1JwbrGt1laexkOB6ZM1Q" href="uma://-Ff1JwbrGt1laexkOB6ZM1Q#-Ff1JwbrGt1laexkOB6ZM1Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_JiqnEJt1EdutoZjlV3a4Lg" name="code_instrumentation" guid="_JiqnEJt1EdutoZjlV3a4Lg" presentationName="Code Instrumentation">
+ <presentation xmi:id="-RlYzPnl6Pig2H851hHebBA" href="uma://-RlYzPnl6Pig2H851hHebBA#-RlYzPnl6Pig2H851hHebBA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0lnRMMqOEduwrYVlQ9zp3w" name="coding_standard" guid="_0lnRMMqOEduwrYVlQ9zp3w" briefDescription="A standard describing various coding conventions used for consistent, quality, understandable implementation." presentationName="Coding Standard">
+ <presentation xmi:id="-vlYpfwIYlF_ZCk5s4Dsqdg" href="uma://-vlYpfwIYlF_ZCk5s4Dsqdg#-vlYpfwIYlF_ZCk5s4Dsqdg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0ZM4MMlgEdmt3adZL5Dmdw" name="test" guid="_0ZM4MMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0ZfMEMlgEdmt3adZL5Dmdw" name="test_script" guid="_0ZfMEMlgEdmt3adZL5Dmdw" briefDescription="This artifact contains the step-by-step instructions that realize a test, enabling its execution. These may take the form of either documented textual instructions that are executed manually or computer readable instructions that enable automated test execution." presentationName="Test Script" checklists="_0Z9tMMlgEdmt3adZL5Dmdw" guidelines="_0aDz0MlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NqYIcqeqEdmKDbQuyzCoqQ" href="uma://_NqYIcqeqEdmKDbQuyzCoqQ#_NqYIcqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0Z9tMMlgEdmt3adZL5Dmdw" name="test_script" guid="_0Z9tMMlgEdmt3adZL5Dmdw" briefDescription="This checklist provides questions to verify that tests are created in a consistent and complete manner." presentationName="Test Script">
+ <presentation xmi:id="_4LuPMMPcEdmbOvqy4O0adg" href="uma://_4LuPMMPcEdmbOvqy4O0adg#_4LuPMMPcEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0aDz0MlgEdmt3adZL5Dmdw" name="test_suite" guid="_0aDz0MlgEdmt3adZL5Dmdw" briefDescription="This guideline discusses how to maintain automated test suites." presentationName="Test Suite">
+ <presentation xmi:id="_s60KoMM3EdmSIPI87WLu3g" href="uma://_s60KoMM3EdmSIPI87WLu3g#_s60KoMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0jO98MlgEdmt3adZL5Dmdw" name="implement_tests" guid="_0jO98MlgEdmt3adZL5Dmdw" briefDescription="Implement one or more test artifacts to enable the validation of the software product through actually running the system. Combine tests to facilitate appropriate breadth and depth of test coverage." presentationName="Implement Tests" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw _0jzlsMlgEdmt3adZL5Dmdw" performedBy="_0ZM4MclgEdmt3adZL5Dmdw" mandatoryInput="_0ZS-0MlgEdmt3adZL5Dmdw" output="_0ZfMEMlgEdmt3adZL5Dmdw" optionalInput="_0ZfMEMlgEdmt3adZL5Dmdw _0YuXEMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_NrbRUKeqEdmKDbQuyzCoqQ" href="uma://_NrbRUKeqEdmKDbQuyzCoqQ#_NrbRUKeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0jVEkMlgEdmt3adZL5Dmdw" name="run_tests" guid="_0jVEkMlgEdmt3adZL5Dmdw" briefDescription="Run the appropriate collections of tests required to evaluate product quality. Capture test results that facilitate ongoing assessment of the product." presentationName="Run Tests" guidelines="_0kF5kMlgEdmt3adZL5Dmdw _0j5sUMlgEdmt3adZL5Dmdw" performedBy="_0ZM4MclgEdmt3adZL5Dmdw" mandatoryInput="_0YuXEMlgEdmt3adZL5Dmdw _0ZfMEMlgEdmt3adZL5Dmdw" output="_0ZlSsMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A">
+ <presentation xmi:id="_NrbRUqeqEdmKDbQuyzCoqQ" href="uma://_NrbRUqeqEdmKDbQuyzCoqQ#_NrbRUqeqEdmKDbQuyzCoqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0jhR0MlgEdmt3adZL5Dmdw" name="failure_analysis_rpt_creation" guid="_0jhR0MlgEdmt3adZL5Dmdw" briefDescription="This concept addresses how to conduct failure analysis based on the execution of tests. The result of this analysis can take the form of a failure analysis report." presentationName="Failure Analysis and Report Creation">
+ <presentation xmi:id="-9gUpkUYqONF3x8UWwAO_zw" href="uma://-9gUpkUYqONF3x8UWwAO_zw#-9gUpkUYqONF3x8UWwAO_zw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0kF5kMlgEdmt3adZL5Dmdw" name="maintaining_automated_test_suite" guid="_0kF5kMlgEdmt3adZL5Dmdw" briefDescription="This guideline explains ways to maintain automated test suites - collection of tests performed together for breadth and depth coverage." presentationName="Maintaining Automated Test Suite">
+ <presentation xmi:id="_8ngBgMPdEdmbOvqy4O0adg" href="uma://_8ngBgMPdEdmbOvqy4O0adg#_8ngBgMPdEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0j5sUMlgEdmt3adZL5Dmdw" name="programming_automated_tests" guid="_0j5sUMlgEdmt3adZL5Dmdw" briefDescription="This guideline discusses ways of structuring, recording, entering data, executing and handling errors in automated tests." presentationName="Programming Automated Tests">
+ <presentation xmi:id="_vuwC4MPcEdmbOvqy4O0adg" href="uma://_vuwC4MPcEdmbOvqy4O0adg#_vuwC4MPcEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0jzlsMlgEdmt3adZL5Dmdw" name="test_ideas" guid="_0jzlsMlgEdmt3adZL5Dmdw" briefDescription="This guideline identifies common faults and mistakes done when developing software. It shows how to create test ideas from method calls, and from boolean and relational expressions." presentationName="Test Ideas">
+ <presentation xmi:id="_y3rxsMM3EdmSIPI87WLu3g" href="uma://_y3rxsMM3EdmSIPI87WLu3g#_y3rxsMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_yDyI8DR1EdutE_HNDTJk5Q" name="tester_tst" guid="_yDyI8DR1EdutE_HNDTJk5Q" variabilityType="contributes" variabilityBasedOnElement="_0ZM4MclgEdmt3adZL5Dmdw" responsibleFor="_0ZfMEMlgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_wI3R4EvCEdunZcj9T5hrMQ" name="architect" guid="_wI3R4EvCEdunZcj9T5hrMQ" presentationName="architect">
+ <presentation xmi:id="-2QB1bosN011CudkwZ0cn-g" href="uma://-2QB1bosN011CudkwZ0cn-g#-2QB1bosN011CudkwZ0cn-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_VHFGkEvCEdunZcj9T5hrMQ" name="architectural_mechanism" guid="_VHFGkEvCEdunZcj9T5hrMQ" presentationName="architectural mechanisms">
+ <presentation xmi:id="-Vvwb6EupIB9kfSQ_mhjURA" href="uma://-Vvwb6EupIB9kfSQ_mhjURA#-Vvwb6EupIB9kfSQ_mhjURA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_n7GmQEvCEdunZcj9T5hrMQ" name="architectural_view" guid="_n7GmQEvCEdunZcj9T5hrMQ" presentationName="architectural view">
+ <presentation xmi:id="-0vih7gB84YYDheaH7jeYFQ" href="uma://-0vih7gB84YYDheaH7jeYFQ#-0vih7gB84YYDheaH7jeYFQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_siyjEEvCEdunZcj9T5hrMQ" name="architecture" guid="_siyjEEvCEdunZcj9T5hrMQ" presentationName="architecture">
+ <presentation xmi:id="-YMvJ5LwexkcVWWqLdm5-nQ" href="uma://-YMvJ5LwexkcVWWqLdm5-nQ#-YMvJ5LwexkcVWWqLdm5-nQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Z-AukEvpEdunZcj9T5hrMQ" name="build" guid="_Z-AukEvpEdunZcj9T5hrMQ" presentationName="build">
+ <presentation xmi:id="-Wh-byAGHoy_gGry0Jq6VaA" href="uma://-Wh-byAGHoy_gGry0Jq6VaA#-Wh-byAGHoy_gGry0Jq6VaA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_d82_AEvDEdunZcj9T5hrMQ" name="component" guid="_d82_AEvDEdunZcj9T5hrMQ" presentationName="component">
+ <presentation xmi:id="-BWZsh3vKrqSOzfkBJmDTLA" href="uma://-BWZsh3vKrqSOzfkBJmDTLA#-BWZsh3vKrqSOzfkBJmDTLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_-61a8EvOEdunZcj9T5hrMQ" name="developer" guid="_-61a8EvOEdunZcj9T5hrMQ" presentationName="developer">
+ <presentation xmi:id="-802sCZ4lJcejyRbhLmkxkw" href="uma://-802sCZ4lJcejyRbhLmkxkw#-802sCZ4lJcejyRbhLmkxkw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ctrEgEvCEdunZcj9T5hrMQ" name="pattern" guid="_ctrEgEvCEdunZcj9T5hrMQ" presentationName="pattern">
+ <presentation xmi:id="-VJBtRm2brEKpRlnLWNF8_g" href="uma://-VJBtRm2brEKpRlnLWNF8_g#-VJBtRm2brEKpRlnLWNF8_g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_U4RYEEvOEdunZcj9T5hrMQ" name="test_case" guid="_U4RYEEvOEdunZcj9T5hrMQ" presentationName="test case">
+ <presentation xmi:id="-6oW2YOnoWq_xPpmoil91KA" href="uma://-6oW2YOnoWq_xPpmoil91KA#-6oW2YOnoWq_xPpmoil91KA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_WB6rQEvPEdunZcj9T5hrMQ" name="tester" guid="_WB6rQEvPEdunZcj9T5hrMQ" presentationName="tester">
+ <presentation xmi:id="-prQBbamJ4CLPywfEbyaPaA" href="uma://-prQBbamJ4CLPywfEbyaPaA#-prQBbamJ4CLPywfEbyaPaA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_5la48DR2EdutE_HNDTJk5Q" name="management" guid="_5la48DR2EdutE_HNDTJk5Q" briefDescription="Management sub-process.">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_0aQBEMlgEdmt3adZL5Dmdw" name="project_management" guid="_0aQBEMlgEdmt3adZL5Dmdw">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0a6vcMlgEdmt3adZL5Dmdw" name="project_plan" guid="_0a6vcMlgEdmt3adZL5Dmdw" briefDescription="This artifact gathers all information required to manage the project. Its main part consists of a coarse-grained plan, containing project phases and milestones." presentationName="Project Plan" examples="_Nzv5kDoAEdusGsHODb-STA" reports="_ePrt8Dj3EduxovfWMDsntw" templates="_0c7hoMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_IbVp8KX4EdmvhNXG0Oc2uA" href="uma://_IbVp8KX4EdmvhNXG0Oc2uA#_IbVp8KX4EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_0bA2EMlgEdmt3adZL5Dmdw" name="status_assessment" guid="_0bA2EMlgEdmt3adZL5Dmdw" briefDescription="Capture and communicate results and actions from assessments. This is typically done at the end of each iteration." presentationName="Status Assessment" templates="_1awLIEp2Edup0IY9DKDPkg">
+ <presentation xmi:id="_K-e8IKX4EdmvhNXG0Oc2uA" href="uma://_K-e8IKX4EdmvhNXG0Oc2uA#_K-e8IKX4EdmvhNXG0Oc2uA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0lC70MlgEdmt3adZL5Dmdw" name="plan_the_project" guid="_0lC70MlgEdmt3adZL5Dmdw" briefDescription="Define a coarse-grained plan for the project." presentationName="Plan Project" conceptsAndPapers="_HNxbwMBJEdqSgKaj2SZBmg _VNxL4ACsEdu8m4dIntu6jA _lam4ADkBEduxovfWMDsntw" guidelines="_CGHskBEdEdqY7JB6N6CW2w _Jq64EJjsEduad8I_c-ogIA _rmBEkJjsEduad8I_c-ogIA" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0WVxcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" output="_0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA" additionallyPerformedBy="_0X9iEMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ _0YDosMlgEdmt3adZL5Dmdw" optionalInput="_0a6vcMlgEdmt3adZL5Dmdw _Ckay8Cc_EduIsqH1Q6ZuqA _0bA2EMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_fPbdIKe2Edmzde8VFK5bxg" href="uma://_fPbdIKe2Edmzde8VFK5bxg#_fPbdIKe2Edmzde8VFK5bxg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0l53cMlgEdmt3adZL5Dmdw" name="assess_results" guid="_0l53cMlgEdmt3adZL5Dmdw" briefDescription="Determine success or failure of the iteration. Apply the lessons learned to modify the project or improve the process." presentationName="Assess Results" conceptsAndPapers="_HNxbwMBJEdqSgKaj2SZBmg" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" output="_0bA2EMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _0a6vcMlgEdmt3adZL5Dmdw" additionallyPerformedBy="_dTa6gMAYEdqX-s4mWhkyqQ _0dsWoMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0X9iEMlgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw" optionalInput="_0bA2EMlgEdmt3adZL5Dmdw _0WVxcMlgEdmt3adZL5Dmdw _0ZlSsMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_a3uz4LBYEdm7Eph_l9Cn9w" href="uma://_a3uz4LBYEdm7Eph_l9Cn9w#_a3uz4LBYEdm7Eph_l9Cn9w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_0mYYkMlgEdmt3adZL5Dmdw" name="metrics" guid="_0mYYkMlgEdmt3adZL5Dmdw" briefDescription="A metric is the interpretation of a measurable attribute(s) of an entity." presentationName="Metrics">
+ <presentation xmi:id="_7ygXoMM3EdmSIPI87WLu3g" href="uma://_7ygXoMM3EdmSIPI87WLu3g#_7ygXoMM3EdmSIPI87WLu3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_CGHskBEdEdqY7JB6N6CW2w" name="agile_estimation" guid="_CGHskBEdEdqY7JB6N6CW2w" briefDescription="This guideline explains three key concepts, and their interrelationships, for doing agile estimation; estimation of size, velocity, and estimation of effort." presentationName="Agile Estimation">
+ <presentation xmi:id="_CYRMgBEdEdqY7JB6N6CW2w" href="uma://_CYRMgBEdEdqY7JB6N6CW2w#_CYRMgBEdEdqY7JB6N6CW2w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_8S2aICbYEdqh1LYUOGRh2A" name="manage_iteration" guid="_8S2aICbYEdqh1LYUOGRh2A" briefDescription="Assess project status and identify any blocking issues and/or opportunities. Identify and manage exceptions, problems and risks. Communicate project status." presentationName="Manage Iteration" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw _VNxL4ACsEdu8m4dIntu6jA _0mYYkMlgEdmt3adZL5Dmdw" guidelines="__yQQ4L6REdqti4GwqTkbsQ _rmBEkJjsEduad8I_c-ogIA" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA" output="_0aQBEslgEdmt3adZL5Dmdw _0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A _Ckay8Cc_EduIsqH1Q6ZuqA" additionallyPerformedBy="_0VxJsMlgEdmt3adZL5Dmdw _0X9iEMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _0dsWoMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ">
+ <presentation xmi:id="-PbfqVxB_j9KN-Jx39_pEUA" href="uma://-PbfqVxB_j9KN-Jx39_pEUA#-PbfqVxB_j9KN-Jx39_pEUA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_0keUEMlgEdmt3adZL5Dmdw" name="plan_iteration" guid="_0keUEMlgEdmt3adZL5Dmdw" briefDescription="Plan the scope and responsibilities for a single iteration." presentationName="Plan Iteration" conceptsAndPapers="_lam4ADkBEduxovfWMDsntw" guidelines="_0auiMMlgEdmt3adZL5Dmdw _CGHskBEdEdqY7JB6N6CW2w __yQQ4L6REdqti4GwqTkbsQ _7vEXEMA4EdqSgKaj2SZBmg _rmBEkJjsEduad8I_c-ogIA" performedBy="_0a0o0MlgEdmt3adZL5Dmdw" mandatoryInput="_0a6vcMlgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" output="_0aQBEslgEdmt3adZL5Dmdw _rGNWsCbSEdqh1LYUOGRh2A" additionallyPerformedBy="_0X9iEMlgEdmt3adZL5Dmdw _0VxJsMlgEdmt3adZL5Dmdw _0ZM4MclgEdmt3adZL5Dmdw _0YDosMlgEdmt3adZL5Dmdw _dTa6gMAYEdqX-s4mWhkyqQ" optionalInput="_0XAf0MlgEdmt3adZL5Dmdw _0WVxcMlgEdmt3adZL5Dmdw">
+ <presentation xmi:id="_Wk7noKe1EdmGSrcKGOYDGg" href="uma://_Wk7noKe1EdmGSrcKGOYDGg#_Wk7noKe1EdmGSrcKGOYDGg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_0auiMMlgEdmt3adZL5Dmdw" name="iteration_planning" guid="_0auiMMlgEdmt3adZL5Dmdw" briefDescription="The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the iteration and produce a sufficiently detailed plan outlining who needs to do what." presentationName="Iteration Planning">
+ <presentation xmi:id="_71hDkMPgEdmbOvqy4O0adg" href="uma://_71hDkMPgEdmbOvqy4O0adg#_71hDkMPgEdmbOvqy4O0adg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_HNxbwMBJEdqSgKaj2SZBmg" name="milestones" guid="_HNxbwMBJEdqSgKaj2SZBmg" briefDescription="The point at which an iteration or phase formally ends, thus providing a check-point for whether the project is ready to move to the next iteration or phase." presentationName="Milestones">
+ <presentation xmi:id="-DG8mYMnTGosWIxjPQFUoTA" href="uma://-DG8mYMnTGosWIxjPQFUoTA#-DG8mYMnTGosWIxjPQFUoTA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="__yQQ4L6REdqti4GwqTkbsQ" name="assign_changes_to_iteration" guid="__yQQ4L6REdqti4GwqTkbsQ" briefDescription="This guideline promotes the best practice of isolating team members from disruptive changes during the current iteration. Change requests are reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration." presentationName="Assign Changes to an Iteration">
+ <presentation xmi:id="-bUmvEAAtFf6B0aUCux8k9Q" href="uma://-bUmvEAAtFf6B0aUCux8k9Q#-bUmvEAAtFf6B0aUCux8k9Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_VNxL4ACsEdu8m4dIntu6jA" name="risk_management" guid="_VNxL4ACsEdu8m4dIntu6jA" briefDescription="This is a fundamental practice that project managers should consider in their projects. Identifying and minimizing risks early in the project lifecycle is key factor for project success." presentationName="Risk Management" conceptsAndPapers="_GXiogMvoEdqukPpotm3DYg">
+ <presentation xmi:id="-HhGIkAPjHSIxnPzI3cyDnQ" href="uma://-HhGIkAPjHSIxnPzI3cyDnQ#-HhGIkAPjHSIxnPzI3cyDnQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Ckay8Cc_EduIsqH1Q6ZuqA" name="risk_list" guid="_Ckay8Cc_EduIsqH1Q6ZuqA" briefDescription="This artifact is a sorted list of known and open risks to the project, sorted in order of importance and associated with specific mitigation or contingency actions." presentationName="Risk List" conceptsAndPapers="_0bsLgMlgEdmt3adZL5Dmdw _VNxL4ACsEdu8m4dIntu6jA" checklists="_7BZa0DIdEduDTv4Y1akVTA" templates="_MIUO0C8FEduzydamRseoUw">
+ <presentation xmi:id="-4VJ_0upihz-bR7VRlm63Vw" href="uma://-4VJ_0upihz-bR7VRlm63Vw#-4VJ_0upihz-bR7VRlm63Vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_7BZa0DIdEduDTv4Y1akVTA" name="risk_list" guid="_7BZa0DIdEduDTv4Y1akVTA" briefDescription="This checklist provides guidance on assessing that all possible risks have been considered in a project." presentationName="Risk List">
+ <presentation xmi:id="-gqNN4DnROmJpgKtrdguhpg" href="uma://-gqNN4DnROmJpgKtrdguhpg#-gqNN4DnROmJpgKtrdguhpg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_dkAtkDR_EdursMWmT1aZyw" name="project_manager_pm" guid="_dkAtkDR_EdursMWmT1aZyw" variabilityType="contributes" variabilityBasedOnElement="_0a0o0MlgEdmt3adZL5Dmdw" responsibleFor="_0a6vcMlgEdmt3adZL5Dmdw _Ckay8Cc_EduIsqH1Q6ZuqA _0bA2EMlgEdmt3adZL5Dmdw"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_nHomIDgzEdu4E8ZdmlYjtA" name="work_items_list" guid="_nHomIDgzEdu4E8ZdmlYjtA" briefDescription="This is an example of a partial Work Items List for a small team who just started to work on iteration 3." presentationName="Work Items List">
+ <presentation xmi:id="-qunTPN3vqTIGpELwajXpLA" href="uma://-qunTPN3vqTIGpELwajXpLA#-qunTPN3vqTIGpELwajXpLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_uAzgkDg3Edu4E8ZdmlYjtA" name="iteration_burndown" guid="_uAzgkDg3Edu4E8ZdmlYjtA" briefDescription="The iteration burndown shows the trend for how much work is left to do within that iteration." presentationName="Iteration Burndown">
+ <presentation xmi:id="-Aw8p59vJ9rWsOV82rljQiQ" href="uma://-Aw8p59vJ9rWsOV82rljQiQ#-Aw8p59vJ9rWsOV82rljQiQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_ePrt8Dj3EduxovfWMDsntw" name="project_burndown" guid="_ePrt8Dj3EduxovfWMDsntw" briefDescription="An effective way of communicating project progress." presentationName="Project Burndown">
+ <presentation xmi:id="-hrDndmFd0zexB0HNYX3gww" href="uma://-hrDndmFd0zexB0HNYX3gww#-hrDndmFd0zexB0HNYX3gww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_sNoQ0Dn6Edu_y4hBImiwwQ" name="work_items_list_pm" guid="_sNoQ0Dn6Edu_y4hBImiwwQ" variabilityType="contributes" variabilityBasedOnElement="_rGNWsCbSEdqh1LYUOGRh2A" guidelines="_CGHskBEdEdqY7JB6N6CW2w" examples="_nHomIDgzEdu4E8ZdmlYjtA" reports="_ePrt8Dj3EduxovfWMDsntw _uAzgkDg3Edu4E8ZdmlYjtA">
+ <presentation xmi:id="-fDVhZTkf1TqDyExbI9DM-w" href="uma://-fDVhZTkf1TqDyExbI9DM-w#-fDVhZTkf1TqDyExbI9DM-w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_xWdL0Dn6Edu_y4hBImiwwQ" name="iteration_plan_pm" guid="_xWdL0Dn6Edu_y4hBImiwwQ" variabilityType="contributes" variabilityBasedOnElement="_0aQBEslgEdmt3adZL5Dmdw" guidelines="_0auiMMlgEdmt3adZL5Dmdw" examples="_TuNhIEE4EdulKujnGUuxbg" reports="_uAzgkDg3Edu4E8ZdmlYjtA">
+ <presentation xmi:id="-b9hejTMj8E7U4g2v80xDjA" href="uma://-b9hejTMj8E7U4g2v80xDjA#-b9hejTMj8E7U4g2v80xDjA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_Nzv5kDoAEdusGsHODb-STA" name="project_plan" guid="_Nzv5kDoAEdusGsHODb-STA" briefDescription="This is an example of a project plan." presentationName="Project Plan">
+ <presentation xmi:id="-IdlCQXdDNYGrGJU4TBwvCA" href="uma://-IdlCQXdDNYGrGJU4TBwvCA#-IdlCQXdDNYGrGJU4TBwvCA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="_TuNhIEE4EdulKujnGUuxbg" name="iteration_plan" guid="_TuNhIEE4EdulKujnGUuxbg" briefDescription="This is an example of an iteration plan for iteration 5 for a small team. In this example, the team has chosen not to list work items in the iteration plan. Instead, the team will search the work items list for work items assigned to iteration 5. This is the preferred solution when work items are managed in a tool that provides basic search capabilities." presentationName="Iteration Plan">
+ <presentation xmi:id="-nDr0XNiUWBo6VS1YS6KAqA" href="uma://-nDr0XNiUWBo6VS1YS6KAqA#-nDr0XNiUWBo6VS1YS6KAqA"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_nJSDwEvuEdunZcj9T5hrMQ" name="effort" guid="_nJSDwEvuEdunZcj9T5hrMQ" presentationName="effort">
+ <presentation xmi:id="-WIgtkwJN71D51FdcQs-TzQ" href="uma://-WIgtkwJN71D51FdcQs-TzQ#-WIgtkwJN71D51FdcQs-TzQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_8b20EEvvEdunZcj9T5hrMQ" name="iteration_burndown" guid="_8b20EEvvEdunZcj9T5hrMQ" presentationName="iteration burndown">
+ <presentation xmi:id="-3G3HV0opAmFWGxYgsD5AhA" href="uma://-3G3HV0opAmFWGxYgsD5AhA#-3G3HV0opAmFWGxYgsD5AhA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_MvOuAEvGEdunZcj9T5hrMQ" name="point" guid="_MvOuAEvGEdunZcj9T5hrMQ" presentationName="point">
+ <presentation xmi:id="-oShmMITo9RIi1AzACWI9vw" href="uma://-oShmMITo9RIi1AzACWI9vw#-oShmMITo9RIi1AzACWI9vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_eX0YsEvvEdunZcj9T5hrMQ" name="project_burndown" guid="_eX0YsEvvEdunZcj9T5hrMQ" presentationName="project burndown">
+ <presentation xmi:id="-NNByAM5YsjCu39flaOSZtQ" href="uma://-NNByAM5YsjCu39flaOSZtQ#-NNByAM5YsjCu39flaOSZtQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_ii2LUEvGEdunZcj9T5hrMQ" name="risk" guid="_ii2LUEvGEdunZcj9T5hrMQ" presentationName="risk">
+ <presentation xmi:id="-hOtatvr8wIjqW8UD0MSGhQ" href="uma://-hOtatvr8wIjqW8UD0MSGhQ#-hOtatvr8wIjqW8UD0MSGhQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_t7JOkEvtEdunZcj9T5hrMQ" name="scope" guid="_t7JOkEvtEdunZcj9T5hrMQ" presentationName="scope">
+ <presentation xmi:id="-h1poMaxtQbmg6hD5772oVw" href="uma://-h1poMaxtQbmg6hD5772oVw#-h1poMaxtQbmg6hD5772oVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_Nj2hsEvuEdunZcj9T5hrMQ" name="velocity" guid="_Nj2hsEvuEdunZcj9T5hrMQ" presentationName="velocity">
+ <presentation xmi:id="-mgWkuUy3q0zzFaxE7DY1ag" href="uma://-mgWkuUy3q0zzFaxE7DY1ag#-mgWkuUy3q0zzFaxE7DY1ag"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_RK9nwEvtEdunZcj9T5hrMQ" name="work_breakdown_structure" guid="_RK9nwEvtEdunZcj9T5hrMQ" presentationName="work breakdown structure" guidelines="_rmBEkJjsEduad8I_c-ogIA">
+ <presentation xmi:id="-KQTbqDSJXR8KLBxIgGVquA" href="uma://-KQTbqDSJXR8KLBxIgGVquA#-KQTbqDSJXR8KLBxIgGVquA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_jyVgcEvKEdunZcj9T5hrMQ" name="work_item" guid="_jyVgcEvKEdunZcj9T5hrMQ" presentationName="work item" guidelines="_rmBEkJjsEduad8I_c-ogIA">
+ <presentation xmi:id="-1Oc9t_TLaBgW_YLugZcq7w" href="uma://-1Oc9t_TLaBgW_YLugZcq7w#-1Oc9t_TLaBgW_YLugZcq7w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_Jq64EJjsEduad8I_c-ogIA" name="staffing_project" guid="_Jq64EJjsEduad8I_c-ogIA" briefDescription="Advice for how to staff a software development project." presentationName="Staffing a Project">
+ <presentation xmi:id="-HYO1lwAFOxlT7ncq8EjSng" href="uma://-HYO1lwAFOxlT7ncq8EjSng#-HYO1lwAFOxlT7ncq8EjSng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="_rmBEkJjsEduad8I_c-ogIA" name="self_organize_work_assignments" guid="_rmBEkJjsEduad8I_c-ogIA" briefDescription="Agile software development teams organize the work that needs to be done together as a team." presentationName="Self Organize Work Assignments">
+ <presentation xmi:id="-e26WOHRbTVQrDssK5zijVA" href="uma://-e26WOHRbTVQrDssK5zijVA#-e26WOHRbTVQrDssK5zijVA"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0nJNkMlgEdmt3adZL5Dmdw" name="CapabilityPatterns" guid="_0nJNkMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_bxcS4B_REdq3EKSIdbj-MA" name="Phase Iteration Templates" guid="_bxcS4B_REdq3EKSIdbj-MA">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0rWYIMlgEdmt3adZL5Dmdw" href="uma://_0rWYIMlgEdmt3adZL5Dmdw#_0rWYIMlgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0oSdEclgEdmt3adZL5Dmdw" href="uma://_0oSdEclgEdmt3adZL5Dmdw#_0oSdEclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0qrpwMlgEdmt3adZL5Dmdw" href="uma://_0qrpwMlgEdmt3adZL5Dmdw#_0qrpwMlgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_y-etQOtQEdqc1LGhiSPqRg" href="uma://_y-etQOtQEdqc1LGhiSPqRg#_y-etQOtQEdqc1LGhiSPqRg"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mpl9kDbmEduMn613sF6-Uw" name="Sub-processes" guid="_mpl9kDbmEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_JEyxADboEduMn613sF6-Uw" name="Management" guid="_JEyxADboEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0pWNAslgEdmt3adZL5Dmdw" href="uma://_0pWNAslgEdmt3adZL5Dmdw#_0pWNAslgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0nJNkclgEdmt3adZL5Dmdw" href="uma://_0nJNkclgEdmt3adZL5Dmdw#_0nJNkclgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_TFSlkDboEduMn613sF6-Uw" name="Intent" guid="_TFSlkDboEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0pJ_xclgEdmt3adZL5Dmdw" href="uma://_0pJ_xclgEdmt3adZL5Dmdw#_0pJ_xclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0o9ygMlgEdmt3adZL5Dmdw" href="uma://_0o9ygMlgEdmt3adZL5Dmdw#_0o9ygMlgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_XzhPQDboEduMn613sF6-Uw" name="Solution" guid="_XzhPQDboEduMn613sF6-Uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0sx7iclgEdmt3adZL5Dmdw" href="uma://_0sx7iclgEdmt3adZL5Dmdw#_0sx7iclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0sluQclgEdmt3adZL5Dmdw" href="uma://_0sluQclgEdmt3adZL5Dmdw#_0sluQclgEdmt3adZL5Dmdw"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_h2-iAPimEdmugcVr9AdHjQ" href="uma://_h2-iAPimEdmugcVr9AdHjQ#_h2-iAPimEdmugcVr9AdHjQ"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0nz79MlgEdmt3adZL5Dmdw" href="uma://_0nz79MlgEdmt3adZL5Dmdw#_0nz79MlgEdmt3adZL5Dmdw"/>
+ </childPackages>
+ </childPackages>
+ </childPackages>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0uHYQMlgEdmt3adZL5Dmdw" name="DeliveryProcesses" guid="_0uHYQMlgEdmt3adZL5Dmdw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_0uHYQclgEdmt3adZL5Dmdw" href="uma://_0uHYQclgEdmt3adZL5Dmdw#_0uHYQclgEdmt3adZL5Dmdw"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_0u-T4MlgEdmt3adZL5Dmdw" name="ProcessContributions" guid="_0u-T4MlgEdmt3adZL5Dmdw"/>
+ <bases href="uma://_WCUhAO8KEdmKSqa_gSYthg#_WCUhAO8KEdmKSqa_gSYthg"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/resources/banner.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/resources/banner.gif
new file mode 100644
index 0000000..83300e8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/resources/banner.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/analyst.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/analyst.xmi
new file mode 100644
index 0000000..7ae122e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/analyst.xmi
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_Nx8icKYdEdmvhNXG0Oc2uA" name="analyst,_0VxJsMlgEdmt3adZL5Dmdw" guid="_Nx8icKYdEdmvhNXG0Oc2uA" changeDate="2007-01-05T09:44:25.904-0500" version="1.0.0">
+ <skills><p>
+ An analyst needs the following knowledge, skills, and abilities:
+</p>
+<ul>
+ <li>
+ Expertise in identifying and understanding problems and opportunities
+ </li>
+ <li>
+ Ability&nbsp;to articulate the needs that are associated with the key problem to be solved or opportunity to be
+ realized
+ </li>
+ <li>
+ Ability to collaborate effectively with the extended team through collaborative working sessions, workshops, JAD
+ sessions and other techniques.
+ </li>
+ <li>
+ Good communication skills, verbally and in writing
+ </li>
+ <li>
+ Knowledge of the business and technology domains or the ability to quickly absorb and understand such information
+ </li>
+</ul>
+<br /></skills>
+ <assignmentApproaches><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ On small, agile teams this role is often shared among several team members that also perform other roles.&nbsp; See
+ <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self Organize Work Assignments</a>&nbsp;and <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/staffing_project,_Jq64EJjsEduad8I_c-ogIA.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;for more information on this approach.
+ </li>
+ <li>
+ One (or more)&nbsp;team member(s) performs this role exclusively. This commonly adopted approach is suitable for
+ complex requirements that are difficult to gather.
+ </li>
+ <li>
+ One staff (or more) team member(s) performs both this role and the <a class="elementLink"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a>
+ role. This is a good option for smaller or resource<font color="#ff0000">-</font>constrained test teams.
+ </li>
+</ul></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/any_role.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/any_role.xmi
new file mode 100644
index 0000000..4a4e58e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/any_role.xmi
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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="_NqqcUqeqEdmKDbQuyzCoqQ" name="any_role,_0dsWoMlgEdmt3adZL5Dmdw" guid="_NqqcUqeqEdmKDbQuyzCoqQ" changeDate="2006-09-11T11:34:17.153-0700">
+ <mainDescription><p>
+ This role allows anyone on a team to perform general tasks:
+</p>
+<ul>
+ <li>
+ Access artifacts in the configuration control system for development and maintenance
+ </li>
+ <li>
+ Submit change requests for the project
+ </li>
+ <li>
+ Participate in assessments and reviews
+ </li>
+ <li>
+ Volunteer to work on a particular iteration
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/architect.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/architect.xmi
new file mode 100644
index 0000000..b5bc66d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/architect.xmi
@@ -0,0 +1,77 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_Y6tLEKbXEdm9d-ircVOUCA" name="architect,_0X9iEMlgEdmt3adZL5Dmdw" guid="_Y6tLEKbXEdm9d-ircVOUCA" changeDate="2007-03-02T10:46:47.447-0800" version="1.0.0">
+ <mainDescription><p>
+ This role leads or coordinates the technical design of the system and has overall responsibility for facilitating the
+ major technical decisions expressed as software architecture. This typically includes identifying and documenting the
+ architecturally significant aspects of the system as views that describe requirements, design, implementation, and
+ deployment.
+</p>
+<p>
+ This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various
+ stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and
+ followed.
+</p>
+<p>
+ This role is closely involved in organizing the team around the architecture by working closely with the&nbsp;<a
+ class="elementLink" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a>&nbsp;in staffing and planning the project.
+</p></mainDescription>
+ <keyConsiderations>This role&nbsp;places emphasis on the core principle <a class="elementLink"
+href="./../../openup_basic/guidances/concepts/core_principle_focus,_9gocwMvoEdqukPpotm3DYg.html"
+guid="_9gocwMvoEdqukPpotm3DYg">Focus on articulating the architecture</a>.</keyConsiderations>
+ <skills><p>
+ Architects must be well-rounded people with maturity, vision, and a depth of experience that allows for grasping issues
+ quickly and making educated, critical judgments in the absence of complete information. Specifically, the person must
+ possess this combination of qualifications:
+</p>
+<ul>
+ <li>
+ <b>Experience</b> <strong>in both problem and software engineering domains</strong>, with evidence of a thorough
+ understanding of the requirements to solve the problem and active participation in software development. If there
+ is a team, this experience can be represented by different team members, but at least one person must be able to
+ provide the overall vision for the project.
+ </li>
+ <li>
+ <b>Leadership ability</b> to motivate and maintain momentum for the technical effort across the various teams and
+ to make critical decisions under pressure, plus make those decisions stick. To be effective, this role must have
+ the authority to make technical decisions.
+ </li>
+ <li>
+ <b>Excellent communication</b> <strong>skills</strong> to earn trust, persuade, motivate, and mentor. This role
+ cannot lead by decree, but only by the consent of the rest of the project team. To be effective, this&nbsp;person
+ must earn the respect of the team members, the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html"
+ guid="_0a0o0MlgEdmt3adZL5Dmdw">Project Manager</a>, the customer, and the user community, as well as the management
+ team.
+ </li>
+ <li>
+ <b>Goal-oriented and proactive</b> <strong>orientation</strong> with a relentless focus on results.&nbsp;This
+ person is the technical driving force behind the project, not a visionary or dreamer. The career of a successful
+ architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can
+ focus on doing what needs to be done will be successful.
+ </li>
+</ul>
+<p>
+ From an expertise standpoint, this role also needs to show both design and implementation abilities. However, from the
+ design perspective, the effective architect typically exhibits these traits:
+</p>
+<ul>
+ <li>
+ Tends to be a generalist, rather than a specialist, who knows many technologies at a high level rather than a few
+ technologies at the detail level
+ </li>
+ <li>
+ Makes the broader technical decisions, thereby demonstrating broad knowledge and experience, as well as
+ communication and leadership skills
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ This person in this role should be engaged in the project from start to finish.
+</p>
+<p>
+ For smaller projects, a single person may act as both Architect and <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a>. However, it is better to have these roles performed by different people to ensure that the pressures one
+ role doesn't cause neglect of the other role.&nbsp;The Architect and Project Manager&nbsp;must work together closely.
+</p></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/developer.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/developer.xmi
new file mode 100644
index 0000000..b269533
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/developer.xmi
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_NqL7MqeqEdmKDbQuyzCoqQ" name="developer,_0YDosMlgEdmt3adZL5Dmdw" guid="_NqL7MqeqEdmKDbQuyzCoqQ" changeDate="2007-01-14T17:32:58.561-0500" version="1.0.0">
+ <skills><p>
+ This role needs the following knowledge, skills, and abilities:
+</p>
+<ul>
+ <li>
+ Define and create technical solutions in the project's technology
+ </li>
+ <li>
+ Understand and&nbsp;conform to the&nbsp;architecture
+ </li>
+ <li>
+ Identify and build developer tests that cover required behavior of the technical components
+ </li>
+ <li>
+ Communicate the design in a way that other team members understand
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ On small, agile teams this role is often shared among several team members that also perform other roles.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self Organize Work Assignments</a>&nbsp;and <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/staffing_project,_Jq64EJjsEduad8I_c-ogIA.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;for more information on this approach.
+</p>
+<p>
+ Even in the smallest team, multiple individuals should be working together to create the technical solution.
+</p>
+<p>
+ A person performing this role can have specialized skills in a particular technical area, but should also have a broad
+ understanding of all the technologies involved to be able to work with other technical team members.
+</p></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/developer_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/developer_vm.xmi
new file mode 100644
index 0000000..a7e0c5c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/developer_vm.xmi
@@ -0,0 +1,7 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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="-xbAirPdH1IOKcnklk8hdqw" name="new_role,_sypCEPvjEdqf0-top1XJIg" guid="-xbAirPdH1IOKcnklk8hdqw" changeDate="2006-09-11T11:34:39.535-0700">
+ <skills><p>
+ In addition, to create a visual model of the system, this role needs the ability to&nbsp;render the design in the
+ Unified Modeling Language (UML).
+</p></skills>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/project_manager.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/project_manager.xmi
new file mode 100644
index 0000000..998218c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/project_manager.xmi
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_Fdq-8KX4EdmvhNXG0Oc2uA" name="project_manager,_0a0o0MlgEdmt3adZL5Dmdw" guid="_Fdq-8KX4EdmvhNXG0Oc2uA" changeDate="2006-11-01T17:03:02.026-0800" version="1.0.0">
+ <mainDescription><p>
+ This role:
+</p>
+<ul>
+ <li>
+ Applies management knowledge, skills, tools and techniques to a broad range of tasks in order to deliver&nbsp;the
+ desired&nbsp;result for a particular project in a timely fashion.
+ </li>
+ <li>
+ Is accountable for the outcome of the project and the acceptance of the product by the customer.
+ </li>
+ <li>
+ Responsible for the evaluation of project's risks, and controling these risks through mitigation strategies.&nbsp;
+ </li>
+</ul></mainDescription>
+ <skills><p>
+ A person performing this role needs the following skills:
+</p>
+<ul>
+ <li>
+ Good in presentation, facilitation, communication, and negotiation.
+ </li>
+ <li>
+ Leadership and team building capabilities.
+ </li>
+ <li>
+ Thorough experience in the software development lifecycle to teach, guide and support other team members.
+ </li>
+ <li>
+ Proficient in conflict resolution and problem solving techniques.
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ This role is often played by a single person. This role is difficult to share with others, but might not consume all of
+ a person’s availability.
+</p>
+<br />
+<br /></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/tester.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/tester.xmi
new file mode 100644
index 0000000..8af4c86
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/roles/tester.xmi
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="_NqYIcKeqEdmKDbQuyzCoqQ" name="tester,_0ZM4MclgEdmt3adZL5Dmdw" guid="_NqYIcKeqEdmKDbQuyzCoqQ" changeDate="2006-09-26T13:51:28.608-0700" version="1.0.0">
+ <mainDescription><p>
+ This role is primarily responsible for the following&nbsp;tasks:
+</p>
+<ul>
+ <li>
+ Identify the tests&nbsp;that need to&nbsp;be performed
+ </li>
+ <li>
+ Identify the most appropriate implementation approach for a given test
+ </li>
+ <li>
+ Implement individual tests
+ </li>
+ <li>
+ Set up and execute the tests
+ </li>
+ <li>
+ Log outcomes and verify that the tests have been run
+ </li>
+ <li>
+ Analyze and recover from execution errors
+ </li>
+ <li>
+ Communicate test results to the team
+ </li>
+</ul></mainDescription>
+ <skills><p>
+ A person&nbsp;filling the&nbsp;this role should have the following skills:
+</p>
+<ul>
+ <li>
+ Knowledge of testing approaches and techniques
+ </li>
+ <li>
+ Diagnostic and problem-solving skills
+ </li>
+ <li>
+ Knowledge of the system or application being tested (desirable)
+ </li>
+ <li>
+ Knowledge of networking and system architecture (desirable)
+ </li>
+</ul>
+<p>
+ Where automated testing is required, consider requiring these additional qualifications:
+</p>
+<ul>
+ <li>
+ Training in the appropriate use of test automation tools
+ </li>
+ <li>
+ Experience using test automation tools
+ </li>
+ <li>
+ Programming skills
+ </li>
+ <li>
+ Debugging and diagnostic skills
+ </li>
+</ul>
+<p>
+ <strong>Note:</strong> Specific skill requirements vary depending on the type of testing that you are conducting. For
+ example, the skills needed to successfully use system load testing automation tools are different from those needed for
+ the automation of system functional testing.
+</p></skills>
+ <assignmentApproaches><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ Assign one or more testing staff members to perform this role. This is a fairly standard approach and is
+ particularly suitable for small teams, as well as for teams of any size where the team is made up of an experienced
+ group of testers of relatively equal skill levels.
+ </li>
+ <li>
+ Assign one or more testing staff members to perform only this role.&nbsp;This works well in large teams. It is also
+ useful to separate responsibilities when some of the testing staff has more test automation experience than other
+ team members.
+ </li>
+ <li>
+ Assign one or more team members that is already playing another role in the project to be responsible for the
+ testing of some part of the system’s capabilities.&nbsp;The team member will have to have the appropriate test
+ skills
+ </li>
+</ul></assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/rolesets/openup_basic_roles.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/rolesets/openup_basic_roles.xmi
new file mode 100644
index 0000000..4bd2350
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/rolesets/openup_basic_roles.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="_Tb5J8O8NEdmKSqa_gSYthg" name="openup_basic_roles,_TZIJ0O8NEdmKSqa_gSYthg" guid="_Tb5J8O8NEdmKSqa_gSYthg" changeDate="2007-02-27T13:09:15.904-0800" version="1.0.0">
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText"
+ href="./../../base_concepts/guidances/termdefinitions/role,_yUefQNnmEdmO6L4XMImrsA.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">roles</a>. You can see the roles that have been included, and visit each role page to
+ see its definition and relationships to other elements.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/analyze_arch_reqs.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/analyze_arch_reqs.xmi
new file mode 100644
index 0000000..55fbc36
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/analyze_arch_reqs.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_qDRSULBKEdm7Eph_l9Cn9w" name="analyze_architecture,_0f-1oMlgEdmt3adZL5Dmdw" guid="_qDRSULBKEdm7Eph_l9Cn9w" changeDate="2007-03-03T21:37:35.140+0000" version="1.0.0">
+ <mainDescription><p>
+ This task focuses on defining a candidate&nbsp;architecture&nbsp;that will guide&nbsp;the development, testing, and
+ operation of the system. It relies on gathering experience gained in similar systems or problem domains to constrain
+ and focus the architecture so that effort is not wasted in re-inventing architecture.
+</p>
+<p>
+ Capture architectural decisions in the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. Make sure that this is communicated across the team.
+</p></mainDescription>
+ <keyConsiderations><p>
+ This task&nbsp;is most beneficial when developing new and unprecedented systems. In systems where there is already a
+ well-defined architecture, this task might be omitted, or performed quickly as a&nbsp;review of the existing
+ architecture.
+</p>
+<p>
+ It is critical that this task is performed collaboratively with active involvement of other team members and project
+ stakeholders so that consensus and common understanding is reached. It is particularly vital for the architect to
+ involve the developer(s) throughout this task. The architecture effort&nbsp;is about providing leadership and
+ coordination of the technical work rather than putting in a solo performance.
+</p></keyConsiderations>
+ <sections xmi:id="_3nMQQA3rEduibvKwrGxWxA" name="Identify architectural goals" guid="_3nMQQA3rEduibvKwrGxWxA">
+ <sectionDescription><p>
+ Describe the goals of the architecture by examining the product <a class="elementLink"
+ href="./../../openup_basic/guidances/checklists/vision,_0WoFUMlgEdmt3adZL5Dmdw.html"
+ guid="_0WoFUMlgEdmt3adZL5Dmdw">Vision</a>&nbsp;and requirements, including architecturally significant requirements.
+ Also, talk to the project <a class="elementLink"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> and <a class="elementLink"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a>.
+ These goals will guide your&nbsp;approach to important architectural and design decisions.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_9o6Z4CSCEdqDjNgZyGMf5w" name="Identify architectural constraints" guid="_9o6Z4CSCEdqDjNgZyGMf5w">
+ <sectionDescription><p>
+ Understand&nbsp;any constraints (or opportunities) on the solution&nbsp;that are inherent in the existing environment
+ or organization. If available, examine the <a class="elementLink"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>&nbsp;for any constraints that have already been
+ identified.&nbsp;Discuss any critical time and resource constraints with the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a>, as these&nbsp;will also need to be taken into account when arriving at your decisions. Discuss potential
+ constraints with the tester such as hooks for tests, and to identify architectural areas that may be difficult to test.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_B899cMP2EdmWKcx6ixEiwg" name="Survey, assess, and select available assets" guid="_B899cMP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Establish the availability of any existing software assets as suitable candidates for re-use. Make sure you consult
+ with others who have knowledge of existing assets, particularly the&nbsp;<a class="elementLink"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html"
+ guid="_0YDosMlgEdmt3adZL5Dmdw">Developer</a>(s) and other&nbsp;people outside the project team (such as production
+ support teams) in order to form a balanced view of the suitability of existing assets for re-use. Identifying reusable
+ assets could be done as a team brainstorming session.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_FVrlsMP2EdmWKcx6ixEiwg" name="Define approach for structuring the system" guid="_FVrlsMP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Decide how to structure&nbsp;the software, both in logical and physical terms. As a minimum, decide on:
+</p>
+<ul>
+ <li>
+ How to partition the software when managing development
+ </li>
+ <li>
+ How the software will be composed at run time.
+ </li>
+</ul>
+<p>
+ For each software partition, briefly describe
+</p>
+<ul>
+ <li>
+ Their name and purpose.
+ </li>
+ <li>
+ Their relationships to other partitions.
+ </li>
+</ul>
+<p>
+ These decisions will form the basis for structuring the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;and the <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_tmvWwE5cEducxZ_XZXh-vw" name="Define approach for deploying the system" guid="_tmvWwE5cEducxZ_XZXh-vw">
+ <sectionDescription>Outline how the software will deploy over the nodes on the network. Work with stakeholders such as as network support and
+deployment&nbsp;teams to ensure that the proposed approach is a good fit for the wider technical environment.</sectionDescription>
+ </sections>
+ <sections xmi:id="_I32E4MP2EdmWKcx6ixEiwg" name="Identify key abstractions" guid="_I32E4MP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Identify the key abstractions that the system needs to handle. You can usually find these by looking for nouns that the
+ requirements emphasize or repeat, because they help identify what is important to the business. The <a
+ class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html"
+ guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> is particularly useful for this. Work with the analyst and stakeholder
+ here, as they will have knowledge and materials that are relevant to this step. Work with the developer to identify key
+ abstractions internal to the system.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_KBAsYMP2EdmWKcx6ixEiwg" name="Identify architectural mechanisms" guid="_KBAsYMP2EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Catalog the architectural mechanisms that are necessary to fulfil the requirements. At this stage, it only
+ necessary&nbsp;to capture&nbsp;a relatively small amount of detail for each mechanism. Discuss the requirements
+ (especially&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) that are being addressed by each&nbsp;mechanisms with the
+ analysts and stakeholders to make sure that the requirements are&nbsp;unambiguous and well understood.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xTdYACGAEdqk6N_Ot_YEvA" name="Capture architectural decisions" guid="_xTdYACGAEdqk6N_Ot_YEvA">
+ <sectionDescription><p>
+ Capture&nbsp;important decisions&nbsp;about the architecture for future reference. Consider using the templates
+ provided for the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>.
+</p></sectionDescription>
+ </sections>
+ <purpose>To provide sufficient guidance and direction for the team to be able to perform analysis and design&nbsp;in consistent and
+coherent ways.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/assess_results.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/assess_results.xmi
new file mode 100644
index 0000000..113f1eb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/assess_results.xmi
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_a3uz4LBYEdm7Eph_l9Cn9w" name="assess_results,_0l53cMlgEdmt3adZL5Dmdw" guid="_a3uz4LBYEdm7Eph_l9Cn9w" changeDate="2006-09-22T12:12:39.478-0700" version="1.0.0">
+ <sections xmi:id="_PABe4MQIEdmaiYJe8-Eaqg" name="Gather stakeholder feedback" guid="_PABe4MQIEdmaiYJe8-Eaqg">
+ <sectionDescription><p>
+ The team should demonstrate the product to customer, end-users, and other <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>s&nbsp;to collect their feedback, or better yet, have end users to use the product themselves. This
+ should be done throughout the iteration, or at least in a separate session towards the end of the iteration. Record
+ requested changes to the product in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;for later prioritization. Factor&nbsp;the feedback
+ into the&nbsp;overall iteration assessment.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_o28GgMMsEdmdo9HxCRR_Gw" name="Assess results" guid="_o28GgMMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ Towards the end of the iteration, the team should jointly assess whether the objectives and evaluation criteria
+ established in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a>&nbsp;were met, and whether the team adhered to the
+ iteration plan and completed all the planned work items. Below&nbsp;are some sample questions that the team can ask
+ themselves as a part of the assessment:
+</p>
+<ul>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
+ release meet performance and capacity goals?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Were risks reduced or eliminated? Can we identify new risks?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Were all planned work items addressed? What was the teams velocity relative to plan?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Did the end users provide favorable feedback on what we built in this iteration?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none">
+ Are changes to the project plan required?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ What portion of the current release will be baselined? What portion will need to be reworked?
+ </div>
+ </li>
+ <li>
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ Have there been external changes such as changes in the marketplace, in the user community, or in the
+ requirements?
+ </div>
+ </li>
+</ul>
+<p dir="ltr">
+ The assessments should be based on objective measures to the greatest extent possible. For example, to assess that a
+ given requirement is developed, the team should ensure that the corresponding test cases were successfully run against
+ it, rather than considering it done when the implementation is done.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_iL7cQEpqEdup0IY9DKDPkg" name="Perform a retrospective" guid="_iL7cQEpqEdup0IY9DKDPkg">
+ <sectionDescription><p>
+ Review the approach taken to development and team collaboration, the effectiveness of the development environment, the
+ suitability of the working environment, and other factors and discuss what things went well, what could have gone
+ better, and how things could be changed to deliver better results. Capture actions to be taken to improve the
+ development approach for next iteration in the <a class="elementLink" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_YdoAAM1DEdmLoKw_mVTvhQ" name="Refine project scope and duration" guid="_YdoAAM1DEdmLoKw_mVTvhQ">
+ <sectionDescription><p>
+ Depending on the results of the&nbsp;assessment and the stakeholders' feedback, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a>&nbsp;could need to revise the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>&nbsp;to adapt to those changes. If a change affects defined
+ project milestones, the project manager should consult with the stakeholders before committing to the changes.
+</p>
+<p>
+ Necessary changes can also encompass the need to acquire new resources, to absorb an unplanned effort increase, or to
+ implement a specific change request.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_wp2CIMMsEdmdo9HxCRR_Gw" name="Close-out phase" guid="_wp2CIMMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ This step is optional and must be performed only when the assessment period coincide with the end of a phase.
+</p>
+<p>
+ The end of&nbsp;a phase represents a point of synchronization of technical and management expectations and closure for
+ a project. In iterative development, it coincides&nbsp;with the end of an iteration. However, phase ends mark a point
+ when it is possible to consider re-scoping and even re-contracting a project. For example, the inception phase is
+ exploratory and may be appropriately performed under a time-and-materials contract or a cost-plus type of contract. The
+ elaboration phase could be done as a fixed-price contract or a cost-plus contract, depending on the extent to which the
+ development is unusual. By the construction and transition phases, enough is known about the system that fixed-price
+ contracts are more appealing to the acquirer and vendor.
+</p>
+<p>
+ The phase end is marked by a major milestone and a corresponding milestone review. The degree of formality of
+ these&nbsp;reviews depends on the project. The important thing is to take advantage&nbsp;of this milestone review to
+ achieve agreement among all stakeholders on the current state of the project. For more information, refer to <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Concept: Milestones</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_1YHH8DLqEdueZPye-FaNgA" name="Close-out project" guid="_1YHH8DLqEdueZPye-FaNgA">
+ <sectionDescription><p>
+ This step is optional and must be performed only when the assessment period coincide with the end of the project.
+</p>
+<p>
+ Involve the team and stakeholders in&nbsp;a final assessment for project acceptance which, if successful, marks the
+ point when the customer accepts ownership of the software product. Gather and record the lessons learned to be used in
+ future projects. Complete the close-out of the project by disposing of the remaining assets and reassigning the
+ remaining staff.
+</p></sectionDescription>
+ </sections>
+ <purpose>Capture and communicate whether the project is on track, requires corrective actions, and whether there are opportunities
+for improvement.<br /></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/create_test_cases.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/create_test_cases.xmi
new file mode 100644
index 0000000..59c2631
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/create_test_cases.xmi
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrVKsKeqEdmKDbQuyzCoqQ" name="create_test_cases,_0iwc0clgEdmt3adZL5Dmdw" guid="_NrVKsKeqEdmKDbQuyzCoqQ" changeDate="2007-02-07T15:38:57.234-0800" version="1.0.0">
+ <sections xmi:id="_IJFSsKuSEdmhFZtkg1nakg" name="Review the requirements to be tested" guid="_IJFSsKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Work with&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html"
+ guid="_0VxJsMlgEdmt3adZL5Dmdw">Role: Analyst</a> and <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Role:
+ Developer</a>&nbsp;to identify which use-case scenarios need new or additional test cases. Review the <a
+ class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a>&nbsp;to ensure you understand the scope of development for
+ the current iteration.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_aDe_ILGcEdubqf8m_Zrvvg" name="Identify relevant Test Cases" guid="_aDe_ILGcEdubqf8m_Zrvvg">
+ <sectionDescription><p>
+ Identify paths through the use-case scenario as unique test conditions.&nbsp; Consider alternative or exception paths
+ from both a positive and negative perspective.&nbsp;&nbsp;Review the test ideas list for patterns of test cases that
+ apply to the use-case scenario.
+</p>
+<p>
+ Discuss the requirement with the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role:
+ Stakeholder</a> to identify other conditions of satisfaction for the requirement.
+</p>
+<p>
+ List the test cases with a unique name that identifies the condition they evaluate or their expected result.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_LpbM8KuSEdmhFZtkg1nakg" name="Outline the Test Cases" guid="_LpbM8KuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ For each test case, write a brief description with an expected result.&nbsp; Ensure that a casual reader can clearly
+ understand the difference between test cases.&nbsp; Note the logical pre-conditions and post-conditions that apply to
+ each test case. Optionally, outline steps for the test case.
+</p>
+<p>
+ Verify that test cases meet the <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/checklists/test_case,_0Zxf8MlgEdmt3adZL5Dmdw.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>&nbsp;guidelines.
+</p>
+<p>
+ For more information on the test case, see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/templates/test_case,_0dT8IMlgEdmt3adZL5Dmdw.html"
+ guid="_0dT8IMlgEdmt3adZL5Dmdw">Template: Test Case</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_NK18YKuSEdmhFZtkg1nakg" name="Identify test data needs" guid="_NK18YKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Review each test case and note where data input or output might be required. Identify the type, quantity, and
+ uniqueness of the required data, and add these observations to the test case. Focus on articulating the data needed and
+ not on creating specific data.
+</p>
+<p>
+ For more information on test data selection, see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/checklists/test_case,_0Zxf8MlgEdmt3adZL5Dmdw.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Ok_mMKuSEdmhFZtkg1nakg" name="Share and evaluate the Test Cases" guid="_Ok_mMKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Walk through the test cases with the&nbsp;<a class="elementLinkWithType"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Role:
+ Analyst</a>&nbsp;and&nbsp;<a class="elementLinkWithType"
+ href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">Role:
+ Developer</a>&nbsp;responsible for the related&nbsp;use-case scenario.&nbsp;&nbsp;Ideally, the <a
+ class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>&nbsp;also participates.
+</p>
+<p>
+ Ask the participants to agree that if <em>these test cases pass</em>, they will consider these requirements
+ implemented.&nbsp; Elicit additional test ideas from the <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Role: Analyst</a>
+ and the <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html"
+ guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a> to ensure you understand the expected behavior of the use-case
+ scenario.
+</p>
+<p>
+ During the walkthrough, ensure that:
+</p>
+<ul>
+ <li>
+ The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+ guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>&nbsp;and <a class="elementLinkWithType"
+ href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html"
+ guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>&nbsp;planned for the current iteration have
+ test cases.
+ </li>
+ <li>
+ All the participants agree with the expected results of the test cases.
+ </li>
+ <li>
+ There are no&nbsp;<em>other</em> conditions of satisfaction for the requirement being tested, which indicates
+ either a missing test case or a missing requirement.
+ </li>
+</ul>
+<p>
+ Optionally, capture new patterns of test cases&nbsp;in&nbsp;the test ideas list (see <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/concepts/test_ideas_list,_0jnYcMlgEdmt3adZL5Dmdw.html"
+ guid="_0jnYcMlgEdmt3adZL5Dmdw">Concept: Test Ideas List</a>).
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ To achieve a shared understanding of the specific conditions that the solution must meet.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/define_vision.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/define_vision.xmi
new file mode 100644
index 0000000..d86d19e
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/define_vision.xmi
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_5rJ78Lj3Edmy88CC3LfB_w" name="define_vision,_0fOAoMlgEdmt3adZL5Dmdw" guid="_5rJ78Lj3Edmy88CC3LfB_w" changeDate="2007-02-28T06:02:00.035-0800" version="1.0.0">
+ <sections xmi:id="_tvzDULwPEdm6DujQZORGLQ" name="Identify Stakeholders" guid="_tvzDULwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Identify the decision-makers, customers, potential users, partners, domain experts, industry analysts and other
+ interested parties (see <a class="elementLinkWithType"
+ href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role:
+ Stakeholder</a>). Develop profiles of potential (or actual) users of the system that map to the roles of human actors
+ of the system that you are developing. Document the initial information on key users and their environment in the <a
+ class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_sa5F4LwPEdm6DujQZORGLQ" name="Gain agreement on the problem to be solved" guid="_sa5F4LwPEdm6DujQZORGLQ">
+ <sectionDescription>Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the stakeholders
+what they see as the problem. Then search for root causes, or the “problem behind the problem.”
+Use&nbsp;techniques&nbsp;like the ones&nbsp;described in&nbsp;<a class="elementlinkwithtype"
+href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html"
+guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>. Formulate the problem statement, and then
+fill in the corresponding section from <a class="elementlinkwithtype"
+href="./../../openup_basic/guidances/templates/vision,_0cW54MlgEdmt3adZL5Dmdw.html"
+guid="_0cW54MlgEdmt3adZL5Dmdw">Template: Vision</a>. The purpose of this is to help you distinguish solutions and answers
+from problems and questions.<br />
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_rliOAOz2Edq2wJOsmRwmhg" name="Capture a common vocabulary" guid="_rliOAOz2Edq2wJOsmRwmhg">
+ <sectionDescription>Every project has its own specialized terminology that everyone on the team must understand well to communicate effectively
+with stakeholders. Work with stakeholders to&nbsp;create a glossary that defines acronyms, abbreviations, and&nbsp;relevant
+business and technical terms. Work with stakeholder to continually expand and refine the&nbsp;glossary throughout the
+project life cycle.</sectionDescription>
+ </sections>
+ <sections xmi:id="_vGg-oLwPEdm6DujQZORGLQ" name="Gather stakeholder requests" guid="_vGg-oLwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Use the most appropriate method to gather information, such as the ones in <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html"
+ guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>. Each one is applicable in a particular
+ situation or to a certain type of stakeholder.
+</p>
+<p>
+ If you can meet stakeholders in person, then you can conduct an interview or a brainstorming session. This face to face
+ collaboration is extremely valuable and reduces the chances of the project team misunderstanding the needs of the
+ stakeholders.
+</p>
+<p>
+ Some requirements may already be documented in an existing Work Item List. This can often be used as a solid starting
+ position from which a full set of requirements can be created.
+</p>
+<p>
+ Any requirements gathered during this step should be captured in the Work Item List.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_z7ZC4LwPEdm6DujQZORGLQ" name="Define the system boundaries" guid="_z7ZC4LwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Find and define the line that divides the solution and the real world that surrounds the solution. Identify interfaces,
+ as well as input and output information exchanged with users, machines, or systems.
+</p>
+<p>
+ A Use Case Model is one technique that can prove useful in defining the system boundaries.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
+ guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_1LVn0LwPEdm6DujQZORGLQ" name="Identify constraints on the system" guid="_1LVn0LwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Consider the various sources of constraints that can impact the design or the project itself:
+</p>
+<ul>
+ <li>
+ Political
+ </li>
+ <li>
+ Economic (budget, licensing)
+ </li>
+ <li>
+ Environmental (regulatory constraints, legal, standards)
+ </li>
+ <li>
+ Technical (platforms, technology)
+ </li>
+ <li>
+ Feasibility (schedule, resources allocation, outsourcing)
+ </li>
+ <li>
+ System (solutions compatibility, support of operating systems and environments).
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_2VixILwPEdm6DujQZORGLQ" name="Define features of the system" guid="_2VixILwPEdm6DujQZORGLQ">
+ <sectionDescription><p>
+ Work with stakeholders to capture&nbsp;a list&nbsp;of&nbsp;<a class="elementlinkwithusertext"
+ href="./../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a> that stakeholders want in the system, briefly describing them and giving <a
+ class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/requirement_attributes,_VQ268O0KEdqHTdbLTmC5IQ.html"
+ guid="_VQ268O0KEdqHTdbLTmC5IQ">attributes</a> to help define their general status and priority in the project.
+</p>
+<p>
+ Update the <a class="elementLinkWithType"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;to capture the features identified&nbsp;and their
+ attributes.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_AhjmAL-GEdqb7N6KIeDL8Q" name="Achieve concurrence" guid="_AhjmAL-GEdqb7N6KIeDL8Q">
+ <sectionDescription>Conduct a review&nbsp;of the project vision with relevant Stakeholders and the development team to ensure agreement, assess
+quality, and identify required changes. See&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a> for more information.</sectionDescription>
+ </sections>
+ <purpose>The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to
+express and document their problems, needs, and potential features for the system to be, so the project team can better
+understand what has to be done.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/design_solution.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/design_solution.xmi
new file mode 100644
index 0000000..2a44af0
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/design_solution.xmi
@@ -0,0 +1,230 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrC20qeqEdmKDbQuyzCoqQ" name="design_solution,_0fshwMlgEdmt3adZL5Dmdw" guid="_NrC20qeqEdmKDbQuyzCoqQ" changeDate="2006-09-09T05:58:28.732-0700" version="1.0.0">
+ <mainDescription><p>
+ This task is about designing part of the system, not the whole system.&nbsp; It should be applied based upon some small
+ subset of requirements.&nbsp; The requirements driving the design could be scenario-based functional requirements,
+ non-functional requirements, or a combination.
+</p>
+<p>
+ This task can be applied in some specific context such as the database access elements required for some
+ scenario.&nbsp; In this case the task might be applied&nbsp;again later&nbsp;to deal with a different context on the
+ same requirements.&nbsp; Keep in mind that to actually build some functionality of value&nbsp;to the users, all
+ contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
+ will have to have been designed and implemented all its context such as user interface, business rules, database
+ access, etc.
+</p>
+<p>
+ If this task is being performed on an architecturally significant element the results of this design should be
+ referenced by the architecture.
+</p></mainDescription>
+ <keyConsiderations><P>Each step in this task can cause all previous steps to be revisited in light of new information and decisions.&nbsp; For example, while determining how elements collaborate&nbsp;you might find a gap in the requirements that causes you to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer could&nbsp;note that a reusable element being used doesn't work as expected and that could cause you to identify new elements to take its place.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
+<P>Consider the architecture while performing this task.&nbsp; All design work must be done while regarding the architecture within which the design exists.&nbsp; Furthermore, certain design elements will be deemed architecturally significant; those elements will require updates to the architecture. </P>
+<P>This task will be applied numerous times.&nbsp; Design is best performed in small chunks.</P>
+<P>Even when starting the design for a particular project it&nbsp;is expected that there will be existing frameworks and reusable elements.&nbsp; Every step of this task must give attention to the existing design and existing implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate while designing this portion of the solution. </P>
+<P>Apply patterns throughout this task.&nbsp; Patterns represent proven designs and their usage promotes quality and consistency across the design. </P></keyConsiderations>
+ <sections xmi:id="_4Z7WYKuKEdmhFZtkg1nakg" name="Understand requirement details" guid="_4Z7WYKuKEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Examine the relevant <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>&nbsp;to understand the scope of the design task and the
+ expectations on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
+ information.
+</p>
+<p>
+ If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might
+ not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the
+ requirements under consideration.
+</p>
+<p>
+ If the requirements are&nbsp;determined to be&nbsp;incomplete or incorrect, work with the analyst to get the
+ requirements improved and possibly submit a change request against the requirements.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Ci7aYFixEdusJoWkvSRO9Q" name="Understand the architecture" guid="_Ci7aYFixEdusJoWkvSRO9Q">
+ <sectionDescription><p>
+ Understand how the architecture applies to this part of the design, and how this design work fits with the rest of the
+ system. Incorporate any applicable interfaces, key abstractions, mechanisms and patterns into the design work. Discuss
+ possible refinements to the architecture and new areas of potential re-use with the architect.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_--6tYKuKEdmhFZtkg1nakg" name="Identify design elements" guid="_--6tYKuKEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Identify the elements that collaborate together to provide the required behavior.&nbsp; This can start with the key
+ abstractions identified in the architecture, domain analysis, and classical analysis&nbsp;of the requirements (noun
+ filtering) to derive the&nbsp;elements that would be required to fulfill them.
+</p>
+<p>
+ Identify elements in all perspectives being considered when performing this task.&nbsp; This could include identifying
+ user interface elements,&nbsp;control elements, data elements,&nbsp;and elements relating to interfacing to other
+ systems or devices.
+</p>
+<p>
+ Existing elements of the design should be examined to see if they should participate in the collaboration.&nbsp; It is
+ a mistake to create all new elements in each&nbsp;execution of this task.
+</p>
+<p>
+ This list of candidates must be expanded to include special-purpose participants that handle&nbsp;particular roles in
+ providing the required behavior such as transaction processing or adherence to some security specification.&nbsp; The
+ <a class="elementLink" href="./../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides a good start for identifying elements.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_A_LU8KuLEdmhFZtkg1nakg" name="Determine how elements collaborate to realize the scenario" guid="_A_LU8KuLEdmhFZtkg1nakg">
+ <sectionDescription>Walk through the scenario distributing responsibilities to the participating elements. These responsibilities can be simple
+statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc. This
+step is about ensuring that a quality model is being created that is robust enough to support the requirements.&nbsp;
+<p>
+ Identify the required relationships between the&nbsp;elements based on the walkthrough of the scenario examining how
+ the elements initiate each other's behavior. An element that requests behavior from another element is represented as a
+ relationship between those elements. As with the responsibilities, these relationships can just be defined at this
+ step.
+</p>
+<p>
+ Look to the architecture and previous design work to create a consistent collaboration. Use the Architect to explain
+ the details and motivations of the architecture. Look to reuse existing behavior and relations or to apply similar
+ structure to simplify the design of the overall system.
+</p>
+<p>
+ Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the
+ existing elements.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_ENwJwKuLEdmhFZtkg1nakg" name="Refine design decisions" guid="_ENwJwKuLEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
+ architecture.&nbsp; In this step the design can take into consideration the actual implementation language and other
+ technical decisions.&nbsp; Revisit the identification of the elements and the collaborations&nbsp;that realize the
+ scenarios if necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss
+ testability issues, such as&nbsp;design elements that are difficult to test or critical performance areas,&nbsp;with
+ the Tester and Architect.
+</p>
+<p>
+ In particular make decisions in regard to the considerations below:
+</p>
+<ul>
+ <li>
+ Specific details of relationships between the elements such as multiplicity and navigability
+ </li>
+ <li>
+ Operation detail such as parameters and return values
+ </li>
+ <li>
+ Existence and detail of data attributes necessary
+ </li>
+ <li>
+ Usage of inheritance and interfaces to improve the design
+ </li>
+</ul>
+<p>
+ Incorporate <a class="elementLink" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s from the architecture. Apply consistent structure of the elements
+ and organization of the behavior as in other areas of the design and use patterns identified in the architecture.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_KNZYAKuLEdmhFZtkg1nakg" name="Design internals (for large or complex elements)" guid="_KNZYAKuLEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Design large or complex elements or some complex internal behavior in more detail. &nbsp;
+</p>
+<p>
+ This might just involve devising an algorithm that&nbsp;could be performed to produce the desired behavior. Add
+ additional operations, attributes, and relationships to support the expectations of an element. Discuss testability
+ issues, such as&nbsp;design elements that are difficult to test or critical performance areas,&nbsp;with the Tester and
+ Architect.
+</p>
+<p>
+ The state of the&nbsp;element managed over the course of its lifetime&nbsp;can be designed to ensure proper behavior in
+ various usages.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_9LeFME42EdudDeUNeAxPCQ" name="Design the database schema" guid="_9LeFME42EdudDeUNeAxPCQ">
+ <sectionDescription><p>
+ If the system has persistent data, the design will need to address&nbsp;the database (or file) schema.&nbsp; For a
+ relational database schema, identify the following:
+</p>
+<ul>
+ <li>
+ The structure of tables and views
+ </li>
+ <li>
+ Relationships between&nbsp;tables
+ </li>
+ <li>
+ Triggers which enforce referential integrity
+ </li>
+ <li>
+ Constraints on columns
+ </li>
+ <li>
+ Default values for columns
+ </li>
+ <li>
+ Stored procedures and functions
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_mUVt8BfnEduD353bkQ4frw" name="Evaluate the design" guid="_mUVt8BfnEduD353bkQ4frw">
+ <sectionDescription><p>
+ Evaluate the object design for coupling, cohesion, and other quality design measurements.
+</p>
+<p>
+ Evaluate the database/file design for performance, referential integrity, and normalization.
+</p>
+<p>
+ Consider the design from various angles to ensure that it is a high-quality, communicable design.&nbsp; Work with other
+ technical team members; an independent party can provide a fresh perspective.&nbsp;Use the Tester and Architect to
+ provide perspectives on&nbsp;design quality and adherence to the architecture.&nbsp;However, when identifying potential
+ reviewers keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even
+ more value by actively participating in the design effort itself.
+</p>
+<p>
+ If design flaws are identified, improve the design.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_OGYbwKuLEdmhFZtkg1nakg" name="Communicate the design" guid="_OGYbwKuLEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Communicate&nbsp;the design to&nbsp;those who need to understand it. Though this is described here toward the end of
+ the task, communication should be going on throughout the steps. Working collaboratively is always better than
+ reviewing the work after it is complete.
+</p>
+<p>
+ Here are some ways to communicate&nbsp;the design:
+</p>
+<ul>
+ <li>
+ Formal models&nbsp;specified in UML .
+ </li>
+ <li>
+ Informal diagrams that render static structure and capture&nbsp;dynamic behavior.
+ </li>
+ <li>
+ Annotated code that communicates information about the static structure supplemented with textual descriptions of
+ dynamic behavior across code modules&nbsp;.
+ </li>
+ <li>
+ Physical data models to describe the database schema.
+ </li>
+</ul>
+<p>
+ Here are some examples of individuals&nbsp;who will need to understand the design:
+</p>
+<ul>
+ <li>
+ Developers&nbsp;who will implement a solution based on the design.
+ </li>
+ <li>
+ An&nbsp;architect who can review the design to ensure that it conforms to the architecture or who might examine the
+ design for opportunities to improve the architecture.
+ </li>
+ <li>
+ Other designers who can examine the design for applicability to other parts of the system.
+ </li>
+ <li>
+ Developers or other designers who will be working on other parts of the system that will&nbsp;depend on the
+ elements designed in this task.
+ </li>
+ <li>
+ Other reviewers&nbsp;who will review the design for quality and adherence to standards.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <purpose><p>
+ The purpose of&nbsp;this&nbsp;task&nbsp;is to describe the&nbsp;elements of the system so that they support the
+ required behavior, are of high quality, and fit within the architecture.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/design_solution_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/design_solution_vm.xmi
new file mode 100644
index 0000000..839d1cc
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/design_solution_vm.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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="-_BAmniONtHWbpHQH7znR3g" name=",_T8WvwL3vEdqLRJZPGVbHDA" guid="-_BAmniONtHWbpHQH7znR3g"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/detail_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/detail_requirements.xmi
new file mode 100644
index 0000000..2cf5df4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/detail_requirements.xmi
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_Nqwi8KeqEdmKDbQuyzCoqQ" name="detail_requirements,_0e1mIMlgEdmt3adZL5Dmdw" guid="_Nqwi8KeqEdmKDbQuyzCoqQ" changeDate="2006-09-29T15:31:25.226-0700" version="1.0.0">
+ <sections xmi:id="_vWeHMCxSEdqjsdw1QLH_6Q" name="Detail Use Cases and Scenarios" guid="_vWeHMCxSEdqjsdw1QLH_6Q">
+ <sectionDescription><p>
+ Some <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s and Scenarios may need to be described in more detail to validate our
+ understanding of the requirement and to permit software development to begin. This does not imply that all&nbsp;use
+ cases and scenarios&nbsp;will be detailed prior to commencing implementation.&nbsp;&nbsp;Work with stakeholders to
+ detail only those that are prioritized for implementation in the next iteration or two (see <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>), or those that are deemed architecturally significant
+ (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>.)
+</p>
+<p>
+ The level of detail captured will vary depending upon the needs of the project and the complexity of the use
+ case.&nbsp; For a discussion of the different levels of detail that may be applicable see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/use_case_formats,_qq0GMAXkEduj_7BEUj1JfQ.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
+</p>
+<p>
+ Capture the use case&nbsp;details in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>.&nbsp; For additional information on detailing use cases and scenarios, see&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.&nbsp; For assistance in assessing the
+ quality of your use cases see <a class="elementLinkWithType" href="./../../openup_basic/guidances/checklists/use_case,_0kNwINk1Edq2Q8qZoWbvGA.html" guid="_0kNwINk1Edq2Q8qZoWbvGA">Checklist: Use Case</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_B47VwCxTEdqjsdw1QLH_6Q" name="Detail supporting requirements" guid="_B47VwCxTEdqjsdw1QLH_6Q">
+ <sectionDescription><p>
+ Some&nbsp;<a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a> may need to be clarified or described in more detail, new
+ requirements&nbsp;may have been discovered as we detailed the use cases and scenarios, and new requirements may have
+ been submitted as <a class="elementLink" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html" guid="_6jdvECb3Edqh1LYUOGRh2A">Change Requests</a>.&nbsp;Work with stakeholders to capture, refine and validate those
+ requirements that will have an impact on near term work (see <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>) or are deemed architecturally significant (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/architecturally_significant_requirements,_HrZGIA4MEduibvKwrGxWxA.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>).
+</p>
+<p>
+ Capture these requirements in&nbsp;the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>.&nbsp; For additional guidance on detailing
+ supporting requirements see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q.html" guid="_wr24gNcGEdqz_d2XWoVt6Q">Guideline: Supporting Requirements</a>.&nbsp; For assistance in assessing the quality of
+ your supporting requirements see <a class="elementLinkWithType" href="./../../openup_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.html" guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a>.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_2389cOz2Edq2wJOsmRwmhg" name="Detail glossary terms" guid="_2389cOz2Edq2wJOsmRwmhg">
+ <sectionDescription>Review the use case&nbsp;flow of events. If information is exchanged, be specific about what is passed back and
+forth.&nbsp; Work with stakeholders to ensure that you define newly discovered domain terms, or ambiguous
+terms&nbsp;properly in the <a class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a>.
+If your understanding of the domain has improved,&nbsp;refine existing glossary terms.</sectionDescription>
+ </sections>
+ <sections xmi:id="_BYbboN-bEdqiM_wFaqLjNg" name="Achieve concurrence" guid="_BYbboN-bEdqiM_wFaqLjNg">
+ <sectionDescription>Conduct a review&nbsp;of the&nbsp;requirements (<a class="elementLinkWithType" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a> and <a class="elementLinkWithType" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements</a>)&nbsp;with relevant&nbsp;<a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a> and the development team to ensure consistency with the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>, assess quality, and identify required changes. See&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <purpose><p>
+ The purpose of this task is to describe one or more requirements&nbsp;in sufficient detail to validate understanding of
+ the requirement, to ensure concurrence with stakeholders expectations, and to permit software development&nbsp;to
+ begin.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/detail_requirements_intent_req_ucm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/detail_requirements_intent_req_ucm.xmi
new file mode 100644
index 0000000..0ecdb48
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/detail_requirements_intent_req_ucm.xmi
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-_mfd9ziTwQV_5LE80jJw4g" name="detail_requirements_ucm,_7_3vEAFmEduDPKiaP0pu-Q" guid="-_mfd9ziTwQV_5LE80jJw4g" version="1.0.0">
+ <sections xmi:id="_w2JYgEf6EduISP1GQDlvVQ" name="Update Use-Case Model" guid="_w2JYgEf6EduISP1GQDlvVQ">
+ <sectionDescription>Based on your work update the <a class="elementLink"
+href="./../../openup_basic/workproducts/uc_model,_W2SgEDR5EdutE_HNDTJk5Q.html" guid="_W2SgEDR5EdutE_HNDTJk5Q">Use-Case
+Model</a>.&nbsp; Add, remove or update&nbsp;<a class="elementLinkWithUserText"
+href="./../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a>
+and <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html"
+guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s as required.&nbsp; For more information on creating and structuring your use
+case model see <a class="elementLinkWithType"
+href="./../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html"
+guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>.&nbsp; For assistance in assessing the quality of your use
+case model see <a class="elementLinkWithType"
+href="./../../openup_basic/guidances/checklists/uc_model,_0U6OEMlgEdmt3adZL5Dmdw.html"
+guid="_0U6OEMlgEdmt3adZL5Dmdw">Checklist: Use-Case Model</a>.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/develop_arch.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/develop_arch.xmi
new file mode 100644
index 0000000..8ee19e1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/develop_arch.xmi
@@ -0,0 +1,139 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_rUis8LBKEdm7Eph_l9Cn9w" name="refine_architecture,_0gRJgMlgEdmt3adZL5Dmdw" guid="_rUis8LBKEdm7Eph_l9Cn9w" changeDate="2007-03-03T21:40:43.468+0000" version="1.0.0">
+ <mainDescription><p>
+ This task&nbsp;builds on&nbsp;the work&nbsp;performed during <a class="elementLink"
+ href="./../../openup_basic/tasks/analyze_arch_reqs,_0f-1oMlgEdmt3adZL5Dmdw.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Analyze
+ the Architectural Requirements</a>&nbsp;to produce a concrete approach for the main development work to follow.
+</p>
+<p>
+ The objective is to resolve the overarching issues which affect the design and development activity for the current
+ iteration. These are:
+</p>
+<ul>
+ <li>
+ To specify&nbsp;common mechanisms or patterns to be used.
+ </li>
+ <li>
+ To&nbsp;specify what use will be made of existing software assets and how they will integrate with the overall
+ solution.
+ </li>
+ <li>
+ To&nbsp;specify what new software needs to be developed.
+ </li>
+ <li>
+ To ensure that the appropriate hardware and software resources are&nbsp;specified to support the development and
+ testing of the solution.
+ </li>
+ <li>
+ To ensure that the architecture is useful to and used by the project team.
+ </li>
+</ul>
+<p>
+ The technical decisions&nbsp;taken as part of this task&nbsp;are concrete and unambiguous. Capture architectural
+ decisions in the <a class="elementLink"
+ href="./../../openup_basic/workproducts/architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>. Make sure that this is communicated across the team.
+</p>
+<p>
+ This task is applied iteratively; iterations after the first will need to take account of the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;and <a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>&nbsp;products that have been developed so far.
+</p></mainDescription>
+ <keyConsiderations><p>
+ The architect should perform this task&nbsp;through collaboration with the whole&nbsp;team to promote consensus and a
+ common understanding of the overall solution. The architect should be working to coordinate and guide the technical
+ activities of the team, rather than seeking to do all the work alone.&nbsp;The architect should place emphasis&nbsp;on
+ involving&nbsp;the developer(s) throughout this task.
+</p></keyConsiderations>
+ <sections xmi:id="_P28vkMP3EdmWKcx6ixEiwg" name="Identify architectural priorities" guid="_P28vkMP3EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Determine&nbsp;the&nbsp;priorities for this iteration of&nbsp;architecture work.&nbsp;Balance the objectives for the
+ current iteration against the overall project objectives, ensuring that the architecture can support current and future
+ needs.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_0qoQ8CikEduQBKSg5n118w" name="Refine architectural mechanisms" guid="_0qoQ8CikEduQBKSg5n118w">
+ <sectionDescription><p>
+ Refine&nbsp;each architectural mechanism into a <a class="elementLink"
+ href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a> by looking at the requirements in the context of the current
+ iteration. Include each architecturally significant&nbsp;scenario in scope. Look for commonality across scenarios and
+ propose common components and patterns for their solution. Work with the developers and analysts&nbsp;to gain consensus
+ on&nbsp;the architecture mechanisms.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_QtKuoCilEduQBKSg5n118w" name="Identify business patterns" guid="_QtKuoCilEduQBKSg5n118w">
+ <sectionDescription><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ The architecture of the system can often be best&nbsp;communicated by showing how it handles important areas business
+ behaviour.
+</p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ See <a class="elementLink" href="./../../openup_basic/guidances/concepts/business_pattern,_Z53x0BapEduSTJywppIxVQ.html"
+ guid="_Z53x0BapEduSTJywppIxVQ">Business Pattern</a>. Work with the stakeholders to assure the business patterns are
+ based on&nbsp;sound knowledge.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Vdln8MP3EdmWKcx6ixEiwg" name="Identify reuse opportunities" guid="_Vdln8MP3EdmWKcx6ixEiwg">
+ <sectionDescription><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Leverage reuse of existing components by evaluating their interfaces and the behavior that they provide. Reuse
+ components when their interfaces are similar or match the interfaces of components you would need to develop from
+ scratch. If not similar, modify the newly identified interfaces so you improve the fit with existing components
+ interfaces.
+</p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Work with developers to gain consensus on the suitability of using existing components.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_G_k1kBaqEduSTJywppIxVQ" name="Identify architecturally significant design elements" guid="_G_k1kBaqEduSTJywppIxVQ">
+ <sectionDescription><p align="left">
+ Refine the key abstractions to decide on the important design elements (such as classes and&nbsp;subsystems)&nbsp;that
+ make up the architecture, and provide at least a name and brief description for each. Add them to the <a
+ class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Gain consensus with the developers on architecturally significant design
+ choices.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xIIVkMUbEdu5GrwIlTJV7g" name="Map the software to the hardware" guid="_xIIVkMUbEdu5GrwIlTJV7g">
+ <sectionDescription>Map the architecturally significant design elements to the target deployment environment. Work with hardware and network
+specialists to ensure that the hardware is sufficient to meet the needs of the system; and that any new hardware is
+available in time.</sectionDescription>
+ </sections>
+ <sections xmi:id="_LsyLkBaqEduSTJywppIxVQ" name="Define development architecture and test architecture" guid="_LsyLkBaqEduSTJywppIxVQ">
+ <sectionDescription><p>
+ Ensure that the development and test architectures are defined.&nbsp;Note any architecturally significant differences
+ between these environments and work with the team to devise strategies to mitigate any risks these may introduce.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Zlw-QMP3EdmWKcx6ixEiwg" name="Validate the architecture" guid="_Zlw-QMP3EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Verify that the architecture decisions are appropriate for their purpose.&nbsp;
+</p>
+<p>
+ Development work should be performed to&nbsp;produce a&nbsp;<a class="elementLink"
+ href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>
+ that shows that the software architecture is viable. This should provide the definitive basis for validating the
+ suitability&nbsp;of the architecture.&nbsp;As the software&nbsp;should be developed iteratively, more than one
+ increment of the build may be required to prove the architecture.&nbsp;During the early stages of the project (up to
+ the end of <a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/elaboration_phase_iteration,_0Spa4BOKEduCNqgZdt_OaA.html"
+ guid="_0Spa4BOKEduCNqgZdt_OaA">Elaboration</a>), it may be&nbsp;acceptable for the software to have a incomplete or
+ prototypical feel, as it&nbsp;will be&nbsp;primarily concerned with baselining the architecture to provide a stable
+ foundation for the&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/deliveryprocesses/construction_phase_iteration,_3CqrAROKEduCNqgZdt_OaA.html"
+ guid="_3CqrAROKEduCNqgZdt_OaA">Construction</a> phase.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_aRCI0MP3EdmWKcx6ixEiwg" name="Communicate decisions" guid="_aRCI0MP3EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Ensure that those who need to act upon the architectural work&nbsp;understand&nbsp;it and are able to work with
+ it.&nbsp;Make sure that the description of the architecture clearly conveys not only the solution but also the
+ motivation and objectives related to the&nbsp;decisions that have been made in shaping the architecture. This will make
+ it easier for others to understand the architecture and to adapt it over time.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ Provide a skeletal design to enable more&nbsp;comprehensive design activities to be performed coherently by the team.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/find_and_outline_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/find_and_outline_requirements.xmi
new file mode 100644
index 0000000..79bd9e3
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/find_and_outline_requirements.xmi
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_P9iS8PV_EdmdHa9MmVPgqQ" name="find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ" guid="_P9iS8PV_EdmdHa9MmVPgqQ" changeDate="2006-09-29T15:32:02.476-0700" version="1.0.0">
+ <keyConsiderations>Close collaboration with stakeholders on this task is critical for the success of project.</keyConsiderations>
+ <sections xmi:id="_ckG-cCY-EdqNHcQ-rAojXw" name="Gather information" guid="_ckG-cCY-EdqNHcQ-rAojXw">
+ <sectionDescription><p>
+ Be prepared by gathering and reviewing information related to the problem domain, problem statement, business
+ environment and key stakeholders.&nbsp; Most of this information should be available in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>.&nbsp;&nbsp;You can use various techniques to make gathering
+ requirements easier. Face-to-face meetings with stakeholders is the most effective way to understand stakeholder needs
+ and to gather and validate requirements, but you&nbsp;must prepare in order for&nbsp;these meetings to run efficiently.
+ See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw.html" guid="_OnoNQNSAEdmLhZ9H5Plxyw">Guideline: Requirements Gathering Techniques</a>&nbsp;for more information.&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_GAr3IOz3Edq2wJOsmRwmhg" name="Identify and capture domain terms" guid="_GAr3IOz3Edq2wJOsmRwmhg">
+ <sectionDescription>Work closely with stakeholder to make sure that ambiguous or domain-specific terms are clearly defined in the&nbsp;<a class="elementLink" href="./../../openup_basic/workproducts/glossary,_Wn7HcNcEEdqz_d2XWoVt6Q.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a> and that you use these terms consistently.</sectionDescription>
+ </sections>
+ <sections xmi:id="_fDbgkCY-EdqNHcQ-rAojXw" name="Capture requirements" guid="_fDbgkCY-EdqNHcQ-rAojXw">
+ <sectionDescription>Identify the types of requirements relevant to your system (see <a class="elementlinkwithtype" href="./../../openup_basic/guidances/concepts/requirements,_0Wh-sMlgEdmt3adZL5Dmdw.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>).
+<p>
+ Work with stakeholders to identify and capture&nbsp;the actors and Use Cases. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html" guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for more information.
+</p>
+<p>
+ Work with stakeholders to identify and capture&nbsp;the other types of requirements relevant&nbsp;to your system. See
+ <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q.html" guid="_wr24gNcGEdqz_d2XWoVt6Q">Guideline: Supporting Requirements</a>&nbsp;for more information.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_0WhHsN-eEdqiM_wFaqLjNg" name="Achieve concurrence" guid="_0WhHsN-eEdqiM_wFaqLjNg">
+ <sectionDescription>Conduct a review&nbsp;of the&nbsp;requirements with relevant <a class="elementLinkWithUserText" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>
+and the development team to ensure consistency with the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>,
+assess quality, and identify any required changes. See&nbsp;&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/effective_req_reviews,_E-dPIL-GEdqb7N6KIeDL8Q.html" guid="_E-dPIL-GEdqb7N6KIeDL8Q">Guideline: Effective Requirement Reviews</a>&nbsp;for more information.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Mgb9IC4DEduBP8F-6-95NQ" name="Update the Work Items List" guid="_Mgb9IC4DEduBP8F-6-95NQ">
+ <sectionDescription>Capture references to the requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>, so that you can prioritize the work.</sectionDescription>
+ </sections>
+ <purpose>The purpose of this task is to understand Stakeholder requirements and communicate these to the development team.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.xmi
new file mode 100644
index 0000000..dc638ce
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/find_and_outline_requirements_intent_req_ucm.xmi
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-Yt8TXGkE1rwydXR34apsrg" name=",_txpV0AFmEduDPKiaP0pu-Q" guid="-Yt8TXGkE1rwydXR34apsrg" version="1.0.0">
+ <sections xmi:id="_XRKgkAFoEduDPKiaP0pu-Q" name="Capture Use Case and Actors in a Use-Case Model" guid="_XRKgkAFoEduDPKiaP0pu-Q">
+ <sectionDescription><p>
+ While capturing requirements, it may be useful to identify and capture the <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use
+ Case</a>s and&nbsp;<a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a>&nbsp;in a <a class="elementLinkWithUserText"
+ href="./../../openup_basic/workproducts/uc_model_intent_req_ucm,_0UCrZclgEdmt3adZL5Dmdw.html"
+ guid="_0UCrZclgEdmt3adZL5Dmdw">Use-Case Model</a>. That can help people better understand the proposed system
+ functionality and its&nbsp;surroundings. See <a class="elementLinkWithType"
+ href="./../../openup_basic/guidances/guidelines/find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Find and Outline Actors and Use Cases</a>&nbsp;for more details.
+</p></sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/impl_developer_tests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/impl_developer_tests.xmi
new file mode 100644
index 0000000..c35f0fe
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/impl_developer_tests.xmi
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_dWPe8KrMEdmqUqi7YGiSxw" name="impl_developer_tests,_0iL1EMlgEdmt3adZL5Dmdw" guid="_dWPe8KrMEdmqUqi7YGiSxw" changeDate="2007-01-15T17:54:27.434-0500" version="1.0.0">
+ <mainDescription><p>
+ Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
+ rather than being directly based on the system requirements.
+</p>
+<p>
+ It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
+ course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
+ etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
+ additional behavior.
+</p></mainDescription>
+ <keyConsiderations><ol>
+ <li>
+ Automate tests via a unit regression testing tool (for example, xUnit) so that tests may be run by developers
+ whenever they make changes to the code.
+ </li>
+ <li>
+ Test to the risk of the component. For example, the more critical a component is, the more important it is to test
+ it thoroughly.
+ </li>
+ <li>
+ Pair with the <a class="elementLink" href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html"
+ guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> in all steps of this task to gain insight on testing and quality
+ considerations.
+ </li>
+</ol></keyConsiderations>
+ <sections xmi:id="_2LYo8KuPEdmhFZtkg1nakg" name="Refine scope and identify the test(s)" guid="_2LYo8KuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Select the increment of work to be tested and identify developer test(s) to verify that the <a class="elementLink"
+ href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html"
+ guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a> being developed behaves correctly. One source for the expected
+ behavior for a software component is the <a class="elementLink"
+ href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>.&nbsp;
+</p>
+<p>
+ In identifying the&nbsp;tests or in any other part of this task, consider collaborating with a <a class="elementLink"
+ href="./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html" guid="_0ZM4MclgEdmt3adZL5Dmdw">Tester</a> who
+ should be well-versed in the issues of testing.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_g8npoC5UEduVhuZHT5jKZQ" name="Write the test setup" guid="_g8npoC5UEduVhuZHT5jKZQ">
+ <sectionDescription>To successfully run a test the system must be in a known state so that the correct behavior can be defined. Implement the
+setup logic that must be performed as part of the <a class="elementLink"
+href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
+guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>.</sectionDescription>
+ </sections>
+ <sections xmi:id="_g1eDUC5VEduVhuZHT5jKZQ" name="Define the expected results" guid="_g1eDUC5VEduVhuZHT5jKZQ">
+ <sectionDescription><p>
+ Define the expected results of each test so that it can be verified.
+</p>
+<p>
+ After a test runs, you need to be able to compare the results of running the test against what was expected to happen.
+ The test is successful when the actual results match the expected results.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_5WtVcKuPEdmhFZtkg1nakg" name="Write the test logic" guid="_5WtVcKuPEdmhFZtkg1nakg">
+ <sectionDescription>Write the steps that perform the actual test(s).</sectionDescription>
+ </sections>
+ <sections xmi:id="_j30aAC5VEduVhuZHT5jKZQ" name="Define the test response" guid="_j30aAC5VEduVhuZHT5jKZQ">
+ <sectionDescription>Define the information the test(s) must produce to successfully indicate success or failure. Consider if a response of True
+or False is sufficient, or if a detailed message should be logged as well.</sectionDescription>
+ </sections>
+ <sections xmi:id="_ku06gC5VEduVhuZHT5jKZQ" name="Write clean-up code" guid="_ku06gC5VEduVhuZHT5jKZQ">
+ <sectionDescription>Identify, and then implement, the steps to be followed in order to restore the environment to the original state for each
+test. The goal is to ensure that there are no side effects from running the tests.</sectionDescription>
+ </sections>
+ <sections xmi:id="_6wZFMKuPEdmhFZtkg1nakg" name="Test the test" guid="_6wZFMKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Verify that each developer test works correctly. To do this:
+</p>
+<ul>
+ <li>
+ Run the test(s), observe their behavior, and fix any defects in the tests.
+ </li>
+ <li>
+ Ensure that the expected results are defined properly and that they're being checked correctly.
+ </li>
+ <li>
+ Check the clean-up logic for each test.
+ </li>
+ <li>
+ Ensure that each developer test works within your test suite framework.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <purpose>Prepare to validate a software component (e.g. an operation, a class, a stored procedure) through unit testing. The result
+is one or more new developer tests.</purpose>
+ <alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
+developer testing in identifying bugs and finding their location in the code.</alternatives>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/implement_solution.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/implement_solution.xmi
new file mode 100644
index 0000000..6e10293
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/implement_solution.xmi
@@ -0,0 +1,159 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_d2aMwKrMEdmqUqi7YGiSxw" name="implement_solution,_0hyzgMlgEdmt3adZL5Dmdw" guid="_d2aMwKrMEdmqUqi7YGiSxw" authors="Jim Ruehlin" changeDate="2006-09-27T18:31:00.562-0700" version="1.0">
+ <mainDescription><p>
+ Usually, this task is focused on a specific element, such as a class or component, but it does not need to be.
+</p>
+<p>
+ You implement a portion of the design during each iteration by performing this task. You can perform the task any
+ number of times during an iteration.
+</p>
+<p>
+ Modify the implementation incrementally. Make additions and changes to the implementation for an issue, run the unit
+ and regression tests, and then complete the issue before moving on to other issues.
+</p>
+<p>
+ See the associated guidelines for information on how to perform the steps described in this task.
+</p></mainDescription>
+ <keyConsiderations><p>
+ This task is complete once the build has successfully completed. The implementation should then be immediately tested.
+</p></keyConsiderations>
+ <sections xmi:id="_2sxisE2iEduU655MA_3VXg" name="Determine a strategy" guid="_2sxisE2iEduU655MA_3VXg">
+ <sectionDescription><p>
+ You need to determine a strategy, based on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>&nbsp;of the work item being worked on, for how you're going to implement it.
+ Your fundamental options are:
+</p>
+<ol>
+ <li>
+ Apply existing, reusable assets.
+ </li>
+ <li>
+ Model the design in detail and generate the source code (by model transformation).
+ </li>
+ <li>
+ Write the source code.
+ </li>
+ <li>
+ Any combination thereof.
+ </li>
+</ol></sectionDescription>
+ </sections>
+ <sections xmi:id="_iMMWoKuPEdmhFZtkg1nakg" name="Identify opportunities for reuse" guid="_iMMWoKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Complete the implementation by reusing code at every opportunity.
+</p>
+<p>
+ Identify existing code or other implementation elements that you can reuse in the portion of the <a class="elementLink" href="./../../openup_basic/workproducts/implementation,_0YoQcMlgEdmt3adZL5Dmdw.html" guid="_0YoQcMlgEdmt3adZL5Dmdw">Implementation</a>&nbsp;that you are creating or changing. A comprehensive understanding
+ of the overall design is helpful, because it is best to leverage reuse opportunities when you have a thorough
+ understanding of the proposed solution.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_pjehkNb7Edq_LtLvi4w2yw" name="Transform design into implementation" guid="_pjehkNb7Edq_LtLvi4w2yw">
+ <sectionDescription><p>
+ If you are using sophisticated modeling tools, you should be able to generate a portion of the required source code
+ from the model.&nbsp;Note that programming is often required to complete the implementation after the design
+ model&nbsp;has been transformed into code.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_mFQ58KuPEdmhFZtkg1nakg" name="Write source code" guid="_mFQ58KuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ You should strive to reuse and/or generate code wherever possible, but you will still need to do some
+ programming.&nbsp;To do so, consider the following:
+</p>
+<ul>
+ <li>
+ Examine the&nbsp;requirements. Because some requirements information does not translate directly into your design
+ you should examine the requirement(s) (potentially including both the <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>) to ensure that they are fully realized in the
+ implementation.
+ </li>
+ <li>
+ Refactor your code to improve its design.&nbsp;<a class="elementLink" href="./../../openup_basic/guidances/concepts/refactoring,_Poc7IPDzEdqYgerqi84oCA.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a>&nbsp;is a technique where you improve the quality of your code via
+ small changes.
+ </li>
+ <li>
+ Tuning the results of the existing implementation by improving performance, the user interface, security, and other
+ nonfunctional areas.
+ </li>
+ <li>
+ Adding missing details, such as completing the logic of operations or adding supporting classes and data structures
+ </li>
+ <li>
+ Handling boundary conditions.
+ </li>
+ <li>
+ Dealing with unusual circumstances or error states.
+ </li>
+ <li>
+ Restricting behavior (preventing users from executing illegal flows, scenarios, or combinations of options).
+ </li>
+ <li>
+ Adding critical sections for multi-threaded or re-entrant code.<br />
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_-0yzwDH4EduMqpUNhaTSRA" name="Create a build" guid="_-0yzwDH4EduMqpUNhaTSRA">
+ <sectionDescription><p>
+ Create a new <a class="elementLink" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>. This might involve simply running an existing build script and/or updating an
+ existing build script.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_ni25UKuPEdmhFZtkg1nakg" name="Evaluate the implementation" guid="_ni25UKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Verify that the implementation is fit for its purpose.&nbsp;Examine the code for its suitability to perform its
+ intended function. This is a quality assurance step that you perform in addition to testing, and it is described in
+ other tasks. Consider these strategies:
+</p>
+<ul>
+ <li>
+ Pair programming.&nbsp;By pairing to implement the code in the first place, you effectively evaluate the code as
+ its being written.
+ </li>
+ <li>
+ Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you make, as a
+ reminder reference.
+ </li>
+ <li>
+ Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or
+ set the compiler to the most detailed warning level.
+ </li>
+ <li>
+ Use tools that can visualize the code. Code visualization, such as the&nbsp;UML visualizations in the Eclipse IDE,
+ help developers identify issues such as excessive coupling or&nbsp;circular dependencies.
+ </li>
+ <li>
+ Perform informal, targeted code inspections. Ask colleagues to review&nbsp;small critical sections of code and code
+ with significant churn. Avoid reviewing large sections of code.
+ </li>
+ <li>
+ Use the Tester to assure the implementation is testable and understandable to testing resources.
+ </li>
+</ul>
+<p>
+ Improve the implementation based on the results of these evaluations.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_q5XiIKuPEdmhFZtkg1nakg" name="Communicate significant decisions" guid="_q5XiIKuPEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Communicate the impact of unexpected changes to the design and requirements.
+</p>
+<p>
+ The issues and constraints that you uncover when you implement the system must be communicated to the team. The impact
+ of issues discovered during implementation must be incorporated into future decisions. If appropriate, update use cases
+ and supporting requirements to reflect ambiguities that you identified and resolved in the implementation so they can
+ be tested and you can manage the <a class="elementLink" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>&nbsp;expectations appropriately. Similarly, update the design to reflect
+ new constraints and issues uncovered during implementation to be sure that the new information is communicated to other
+ developers.
+</p>
+<p>
+ Usually, there is no need for a change request if the required change is small and the same person is designing and
+ implementing the class. That individual can make the design change directly. If the required change has a broad impact,
+ such as a change in a public operation, it may be necessary to communicate that change to the other team members
+ through a change request.<br />
+ <br />
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to
+ fix one or more defects. The result is typically new or modified source code, which is generally referred to <em>the
+ implementation</em>.<br />
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/implement_tests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/implement_tests.xmi
new file mode 100644
index 0000000..485bb7c
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/implement_tests.xmi
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrbRUKeqEdmKDbQuyzCoqQ" name="implement_tests,_0jO98MlgEdmt3adZL5Dmdw" guid="_NrbRUKeqEdmKDbQuyzCoqQ" changeDate="2006-09-20T19:51:14.814-0400" version="1.0.0">
+ <sections xmi:id="_S8JzsKuSEdmhFZtkg1nakg" name="Select appropriate implementation technique" guid="_S8JzsKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Select one or several of the following test implementation&nbsp;techniques:
+</p>
+<ul>
+ <li>
+ manual test scripts
+ </li>
+ <li>
+ programmed test scripts
+ </li>
+ <li>
+ recorded test scripts
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_VN5M0KuSEdmhFZtkg1nakg" name="Implement the test" guid="_VN5M0KuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Using your test-ideas list and test cases as inputs, set up your specifications, spreadsheet, or&nbsp;automated
+ tool&nbsp;to record scripts needed to conduct the test.&nbsp;If you are recording explicit steps for your test,
+ navigate through the system under test identifying steps, groups of related steps, verification points, and control
+ points.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_WvBoYKuSEdmhFZtkg1nakg" name="Establish external data sets" guid="_WvBoYKuSEdmhFZtkg1nakg">
+ <sectionDescription>Create containers for your test data sets. Separate the production data from generated data. Associate your data sets with
+a given build of the system under test.&nbsp;If data sets are associated with a particular part of the system under test,
+mark them accordingly.</sectionDescription>
+ </sections>
+ <sections xmi:id="_X0dmcKuSEdmhFZtkg1nakg" name="Verify Test implementation" guid="_X0dmcKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Run the test script to verify that it implements the tests correctly. For manual testing,&nbsp;conduct a walkthrough of
+ the test script. For automated tests, verify that&nbsp;the test implementation will involve some degree of the
+ configuration of the testing tool.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Y-ABYKuSEdmhFZtkg1nakg" name="Organize tests into test suites" guid="_Y-ABYKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Collect tests into related groups. The grouping you use depends on your test environment. For example, you can organize
+ test cases, test scripts, and test data hierarchically to facilitate navigation within a test, as well as within the
+ suite. Another form of test suite organization is based on system functionality and uses the quality attributes of
+ usability, reliability, and performance as categories for groups.&nbsp;You may choose to follow an iteration-based test
+ suite organization, instead.&nbsp;Since the system under test is undergoing its own evolution, create your test suites
+ to facilitate regression testing, as well as system configuration identification.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ To implement one or more tests that can be executed to validate a system.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/manage_iteration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/manage_iteration.xmi
new file mode 100644
index 0000000..a3ca836
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/manage_iteration.xmi
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-PbfqVxB_j9KN-Jx39_pEUA" name="manage_iteration,_8S2aICbYEdqh1LYUOGRh2A" guid="-PbfqVxB_j9KN-Jx39_pEUA" changeDate="2006-08-31T06:45:37.803-0700" version="1.0.0">
+ <sections xmi:id="_OE65ICuxEdqTIKp3l5PtzQ" name="Capture status" guid="_OE65ICuxEdqTIKp3l5PtzQ">
+ <sectionDescription><p>
+ The project manager needs to continuously monitor the project to ensure its appropriate progress, and to enable the
+ team to react as soon as possible to any change. Many alternative means may be used to track the status:
+</p>
+<ul>
+ <li>
+ Quick, daily meetings with the entire project team, also called "scrum meetings” are useful to understand what team
+ members have accomplished since the&nbsp;last meeting, and what they plan to accomplish before the next meeting. It
+ also allows the team to identify any blocking issues. See <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[SCH04]</a>&nbsp;for guidance on scrum meetings.
+ </li>
+ <li>
+ Basic metrics, ideally automatically generated from the tools at hand, or manually assembled. The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>&nbsp;should outline which metrics the project should use.
+ Examples of such metrics include <a class="elementLinkWithType" href="./../../openup_basic/guidances/reports/iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a>&nbsp;and <a class="elementLinkWithType" href="./../../openup_basic/guidances/reports/project_burndown,_ePrt8Dj3EduxovfWMDsntw.html" guid="_ePrt8Dj3EduxovfWMDsntw">Report: Project Burndown</a>&nbsp;charts, which are reports on the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. See also <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html" guid="_0mYYkMlgEdmt3adZL5Dmdw">Concept: Metrics</a>&nbsp;for more information.
+ </li>
+</ul>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_ztF0UCuxEdqTIKp3l5PtzQ" name="Communicate status" guid="_ztF0UCuxEdqTIKp3l5PtzQ">
+ <sectionDescription><p>
+ Communicating project status is as important as gathering it. Communication is usually done at two levels: the task
+ level and project level.
+</p>
+<ul>
+ <li>
+ <strong>Task Level – Communicated within the project team:</strong> status can be communicated through quick, daily
+ meetings. This allows you to combine the status capturing with the status communications.
+ </li>
+ <li>
+ <strong>Project Level – Communicated to the stakeholders and the project team:</strong> status is usually
+ communicated through core metrics rather than detailed information. This can be done through meetings, e-mail, or
+ Web publishing.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_oIZdkCbZEdqh1LYUOGRh2A" name="Handle exceptions and problems" guid="_oIZdkCbZEdqh1LYUOGRh2A">
+ <sectionDescription><p>
+ One of the project manager's key responsibilities is to know about the project team's problems and issues. The manager
+ needs to focus on problems that are blocking progress. A quick, daily meeting is usually a good way to monitor those
+ problems and issues.
+</p>
+<p>
+ Identify the cause and impact of problems and exceptions as they arise. Identify possible solutions for problems that
+ have an immediate impact on the short-term goals and objectives and identify who needs to be involved in implementing
+ the solution. Then, define the corrective actions and implement them.&nbsp;<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xiFJwCbZEdqh1LYUOGRh2A" name="Identify and manage risks" guid="_xiFJwCbZEdqh1LYUOGRh2A">
+ <sectionDescription><p>
+ Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. The
+ risk list should be revisited weekly, or as a minimum once per iteration, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;and <a class="elementLinkWithType" href="./../../openup_basic/workproducts/risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Artifact: Risk List</a>&nbsp;for more details. The entire team should be involved in
+ identifying and mitigating risk.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_Br6VECuxEdqTIKp3l5PtzQ" name="Reprioritize work as needed" guid="_Br6VECuxEdqTIKp3l5PtzQ">
+ <sectionDescription>When a team is falling significantly behind, or critical problems occur, it may be necessary to reprioritize tasks to
+ensure that the team delivers a useful product increment by the end of the iteration, while maximizing stakeholder value.
+In these rare cases, the project manager should work with the team and stakeholders on revising the iteration plan and, as
+necessary, reduce the emphasis on less critical tasks.</sectionDescription>
+ </sections>
+ <purpose><p>
+ Identify blocking issues and/or opportunities early to take action and keep the project on track.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/plan_iteration.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/plan_iteration.xmi
new file mode 100644
index 0000000..48a9cc5
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/plan_iteration.xmi
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_Wk7noKe1EdmGSrcKGOYDGg" name="plan_iteration,_0keUEMlgEdmt3adZL5Dmdw" guid="_Wk7noKe1EdmGSrcKGOYDGg" changeDate="2006-09-07T19:29:53.219-0400">
+ <sections xmi:id="_CtKCMMBHEdqSgKaj2SZBmg" name="Define the iteration objectives" guid="_CtKCMMBHEdqSgKaj2SZBmg">
+ <sectionDescription><p>
+ At the beginning of an iteration, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a>&nbsp;works with the team to define 1-5 objectives. These objectives should be a refinement of the
+ iteration objectives found in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>, and should provide high-level direction to what should be
+ targeted for the iteration. The objectives should be driven based on <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>&nbsp;priorities, and&nbsp;will be revised as the iteration plan is finalized. The objectives are
+ usually defined as high-level capabilities or scenarios that need to be implemented and tested during the
+ iteration.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_307v0MMsEdmdo9HxCRR_Gw" name="Produce detailed plan" guid="_307v0MMsEdmdo9HxCRR_Gw">
+ <sectionDescription>The <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a> works with the rest of the team, and especially the project
+stakeholders,&nbsp;to identify the high-priority work items from the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to be addressed within the iteration. The high-level
+objectives provide guidance on what work items should be considered. The team should break down work items so they fit
+within the iteration as necessary. Actual effort to complete each Work Item should be estimated. When a team has decided to
+take on a Work Item, it will assign the work to one or several team members. Ideally, this is done by team members signing
+up to do the work, since this makes people motivated and committed to doing the job, but based on culture, you may instead
+have the project manager assign the work.</sectionDescription>
+ </sections>
+ <sections xmi:id="_7Hqr4MMsEdmdo9HxCRR_Gw" name="Define evaluation criteria" guid="_7Hqr4MMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ Each iteration should include testing as a part of the evaluation, and the test objectives and test cases needs to be
+ detailed. Other evaluation criteria may include successful demonstrations to key stakeholders, or favorable usage by a
+ small group of target users.<br />
+</p></sectionDescription>
+ </sections>
+ <purpose><p class="MsoNormal" style="MARGIN: 0in 0in 0pt">
+ Develop a fine-grained plan for a single iteration, identifying the goals and evaluation criteria of an iteration
+ (usually the next one).
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/plan_the_project.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/plan_the_project.xmi
new file mode 100644
index 0000000..77f0332
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/plan_the_project.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_fPbdIKe2Edmzde8VFK5bxg" name="plan_the_project,_0lC70MlgEdmt3adZL5Dmdw" guid="_fPbdIKe2Edmzde8VFK5bxg" changeDate="2006-09-27T13:20:13.359-0700" version="1.0.0">
+ <sections xmi:id="_lrYj0MBAEdqSgKaj2SZBmg" name="Evaluate risks" guid="_lrYj0MBAEdqSgKaj2SZBmg">
+ <sectionDescription><p>
+ The project manager evaluates project risks with the team and updates the <a class="elementLink" href="./../../openup_basic/workproducts/risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Risk List</a>. The risk list will aid the team in prioritization of what to do in which iteration. Higher-ranked risks are
+ addressed in the earlier iterations.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_k1bY4MMsEdmdo9HxCRR_Gw" name="Determine project size and scope" guid="_k1bY4MMsEdmdo9HxCRR_Gw">
+ <sectionDescription><p>
+ Analyze the size and the <a class="elementLink" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a>&nbsp;of the project, and whether it is realistic to deliver what is asked for
+ within the constraints of the project.
+</p>
+<p>
+ If the project is feature-driven, meaning that release criteria is defined as a set of features captured in the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, the team assesses the size of these work items, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. They then look at how many people they would need to
+ complete these work items, which gives them a ballpark understanding of project duration, staffing profile, and scope.
+</p>
+<p>
+ If the project instead is date-driven, the team assesses how much work can roughly be done in the time-frame given and
+ using the available team, captured as a candidate list of work items.
+</p>
+<p>
+ The end result of the two approaches is the same; a rough understanding of the size of the capabilities to be
+ delivered, the size of the team, and expected time of completion.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_OfFTEABjEdqHlpDr8LcRqg" name="Define length, number, and objectives of iterations" guid="_OfFTEABjEdqHlpDr8LcRqg">
+ <sectionDescription><p>
+ Determine iteration length, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>, or use 4 weeks as default iteration length. Use iteration length
+ to assess target velocity, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. Based on the target velocity and overall size of the
+ project, calculate the number of iterations required.
+</p>
+<p>
+ Determine 1-3 high-level objectives for each iteration. The goal is to create a high-level plan outlining how you can
+ build the resulting application in the given set of iterations. The plan will change as you learn more, so time-box
+ this analysis to a few hours or less. Use the Work Items List to outline what features to implement in what iteration,
+ putting top priority work items first. This can be done rapidly by leveraging expected velocity and size estimate of
+ work items.
+</p>
+<p>
+ Produce a brief summary of your analysis in your plan by documenting 1-3 objectives for each iteration. Do not commit
+ individual work items to the plan, since this will force too much re-planning. For some projects, you may have to wait
+ until after the first iteration until you can provide a meaningful plan at this level of detail.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_qcOtIE5dEdu3aqt7VHtzgw" name="Define phase milestones and refine iteration objectives" guid="_qcOtIE5dEdu3aqt7VHtzgw">
+ <sectionDescription><p>
+ Phases provide a focus for a team on meeting key management objectives, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/iteration,_lam4ADkBEduxovfWMDsntw.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>. For example the Elaboration phase should answer the question “Do
+ we agree on the overall solution, and do we understand risks, costs and schedule parameters reasonably well?”
+</p>
+<p>
+ With this in mind, the project manager determines the start and end dates of the phases and aligns the content of the
+ iterations with the perspective of the phase. Therefore the objectives of the iterations assigned to a phase, need to
+ map to the goals of its phase. The milestones, which guard the transition from one phase to another, will provide
+ checkpoints if these goals are satisfied.&nbsp; Revisit the plan to see if you should change the focus of iterations to
+ allow more rapid completion of&nbsp;certain phases.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_F2dQYABjEdqHlpDr8LcRqg" name="Map roles to team members" guid="_F2dQYABjEdqHlpDr8LcRqg">
+ <sectionDescription><p>
+ The project manager assigns project members (people) to roles according to a table like this:<br />
+ <br />
+</p>
+<table style="WIDTH: 227px; HEIGHT: 116px" cellspacing="2" cellpadding="2" width="227" border="2">
+ <tbody>
+ <tr>
+ <td>
+ <strong>Team Member&nbsp;</strong>
+ </td>
+ <td>
+ <strong>Analyst</strong>
+ </td>
+ <td>
+ <strong>Developer</strong>&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td>
+ John
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ <td>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Judy&nbsp;&nbsp;
+ </td>
+ <td>
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Jim&nbsp;
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ <td>
+ &nbsp;&nbsp;&nbsp;&nbsp; X
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<p>
+ The project manager needs to make sure that the roles are staffed according to skills and interests and that every role
+ is covered.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_toVK0E5fEdu3aqt7VHtzgw" name="Tune and get concurrence on the plan" guid="_toVK0E5fEdu3aqt7VHtzgw">
+ <sectionDescription>Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of the
+project and make adjustments as necessary.</sectionDescription>
+ </sections>
+ <purpose>To describe a roadmap that provides direction to the team and continually adapt it based on feedback and changes in the
+environment.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/request_change.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/request_change.xmi
new file mode 100644
index 0000000..84d1c16
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/request_change.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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="_Nr0S4KeqEdmKDbQuyzCoqQ" name="submit_change_request,_0mwzEclgEdmt3adZL5Dmdw" guid="_Nr0S4KeqEdmKDbQuyzCoqQ" changeDate="2005-07-07T14:57:19.105-0700">
+ <sections xmi:id="_qEkewKuoEdmEGLSmmpF1Sg" name="Gather change request information" guid="_qEkewKuoEdmEGLSmmpF1Sg">
+ <sectionDescription><p> Gather the information required to describe the change request. This should
+ include a description of the requested change, the reason for the change (defect
+ or enhancement), the&nbsp;artifact&nbsp;affected,
+ including&nbsp;the version, and&nbsp;the priority
+ of the change. If possible,&nbsp;provide an estimate of the effort required
+ to implement the change. </p></sectionDescription>
+ </sections>
+ <sections xmi:id="_r2aP0KuoEdmEGLSmmpF1Sg" name="Update the Work Item List" guid="_r2aP0KuoEdmEGLSmmpF1Sg">
+ <sectionDescription>Update the <a class="elementLinkWithType" href="./../../basic_unified_process/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
+Work Items List</a>&nbsp;to&nbsp;document the information
+that you gathered in the previous step.</sectionDescription>
+ </sections>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/run_developer_tests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/run_developer_tests.xmi
new file mode 100644
index 0000000..d7547e8
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/run_developer_tests.xmi
@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_W6rc0Lv7EdmmUvZAZjqE3g" name="run_developer_tests,_0iYCUMlgEdmt3adZL5Dmdw" guid="_W6rc0Lv7EdmmUvZAZjqE3g" changeDate="2006-09-29T12:31:32.200-0400" version="1.0.0">
+ <keyConsiderations><p>
+ It is common to require that code pass all Developer tests before it can be delivered in an integrated build (see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/promoting_builds,_SM4YIL6dEdqti4GwqTkbsQ.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Builds</a>).
+</p>
+<p>
+ Pair with the Tester during all steps of this task to gain insight on testing and quality considerations.
+</p></keyConsiderations>
+ <sections xmi:id="_MSnQsMP4EdmWKcx6ixEiwg" name="Run Developer Tests" guid="_MSnQsMP4EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Run the <a class="elementLink" href="./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html"
+ guid="_0YuXEclgEdmt3adZL5Dmdw">Developer Test</a>s. The procedure will vary, depending on whether the test is manual or
+ automated and whether additional test components are necessary,&nbsp;such as&nbsp;drivers or stubs.
+</p>
+<p>
+ To run the tests, you need to make sure that you have initialized the test environment with all necessary elements,
+ such as software, hardware, tools, data, and so on.
+</p>
+<p>
+ Automated tests will often update a <a class="elementLink"
+ href="./../../openup_basic/workproducts/test_log,_0ZlSsMlgEdmt3adZL5Dmdw.html" guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test
+ Log</a>&nbsp;which you can evaluate to determine where your tests went wrong.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_NkRF0MP4EdmWKcx6ixEiwg" name="Evaluate test execution" guid="_NkRF0MP4EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Evaluate the test execution by analyzing the test run.&nbsp;
+</p>
+<p>
+ Testing will&nbsp;complete either&nbsp;normally or abnormally.&nbsp; For correctly implemented tests, a normal
+ completion represents a passed test, though it could warrant additional examination of the test log to ensure&nbsp;the
+ test&nbsp;ran as expected.&nbsp; Abnormal termination could be premature termination or just a test that does not
+ complete as intended.
+</p>
+<p>
+ Review the test log to understand any reported failures, warnings, or unexpected results. The cause of the problem(s)
+ might be that the implementation element being tested is faulty, a problem with the developer tests, or a problem with
+ the environment.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_SXPFkMP4EdmWKcx6ixEiwg" name="Respond to test results" guid="_SXPFkMP4EdmWKcx6ixEiwg">
+ <sectionDescription><p>
+ Determine the appropriate corrective action to recover from a "failed" developer test run. If the implementation
+ element under test is faulty, fix the problem if possible and rerun the tests. If the problem is serious and cannot be
+ immediately addressed, perform the task <a class="elementLink"
+ href="./../../openup_basic/tasks/request_change,_0mwzEclgEdmt3adZL5Dmdw.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request
+ Change</a> to report the defect. If the developer test is faulty fix the test and rerun the tests. If there was a
+ problem with the environment,resolve it and then rerun&nbsp;the tests.
+</p>
+<p>
+ When the developer tests pass, communicate the results. If the passing of these tests represent completion of a
+ requirement, this could involve updating the status of something on the <a class="elementLink"
+ href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
+</p></sectionDescription>
+ </sections>
+ <purpose>To verify that the implementation works as specified.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/run_tests.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/run_tests.xmi
new file mode 100644
index 0000000..4e4a802
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/tasks/run_tests.xmi
@@ -0,0 +1,165 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="_NrbRUqeqEdmKDbQuyzCoqQ" name="run_tests,_0jVEkMlgEdmt3adZL5Dmdw" guid="_NrbRUqeqEdmKDbQuyzCoqQ" changeDate="2006-12-07T16:24:24.839-0500" version="1.0.0">
+ <mainDescription>Run the system test, which addresses functional and system integration tests and, potentially, user acceptance tests.</mainDescription>
+ <keyConsiderations><ul>
+ <li>
+ Run the test regularly. Ideally, that means whenever the code changes but, minimally, once a day.
+ </li>
+ <li>
+ It should be possible for anyone on the test team to run the test at any time.
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_fR4aQKuSEdmhFZtkg1nakg" name="Schedule test execution" guid="_fR4aQKuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Run&nbsp;the system tests as often as possible. Ideally, run&nbsp;the tests whenever new code is checked into&nbsp;the
+ version control tool.
+</p>
+<p>
+ For larger systems, this will be too expensive.&nbsp;The tests may take several hours to run; therefore, you'll need to
+ schedule tests less frequently. If possible, however, run the tests several times a day. As a minimum,
+ run&nbsp;automated tests each night.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_gV408KuSEdmhFZtkg1nakg" name="Run the test" guid="_gV408KuSEdmhFZtkg1nakg">
+ <sectionDescription><p>
+ Run the test at the scheduled time based on the instructions in the <a class="elementLink" href="./../../openup_basic/workproducts/test_script,_0ZfMEMlgEdmt3adZL5Dmdw.html" guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test Script</a>. It is best that the script&nbsp;be automated.
+</p>
+<p>
+ Good practices:
+</p>
+<ol>
+ <li>
+ Run the test in a separate test environment.
+ </li>
+ <li>
+ Ensure that you run the test against the latest clean build.
+ </li>
+ <li>
+ The first step of the test should be to set up the test environment (ensure that the network is available, that the
+ test database is available and reset to a known state, and so on).
+ </li>
+</ol></sectionDescription>
+ </sections>
+ <sections xmi:id="_hfVJQKuSEdmhFZtkg1nakg" name="Close test run" guid="_hfVJQKuSEdmhFZtkg1nakg">
+ <sectionDescription>Close the actual run as the last step of running the test.&nbsp;To do this:
+<ol>
+ <li>
+ Close the test logs. The&nbsp;test log files should be closed and placed in the appropriate folder or directory.
+ </li>
+ <li>
+ Announce results. Send a notice to everyone involved in the project informing them of the result of the test run
+ and where they can find the test logs.
+ </li>
+</ol></sectionDescription>
+ </sections>
+ <sections xmi:id="_sQaC4DO2EduqsLmIADMQ9g" name="Examine the test log" guid="_sQaC4DO2EduqsLmIADMQ9g">
+ <sectionDescription><p>
+ Collect and compile information from test execution logs so you can:
+</p>
+<ul>
+ <li>
+ Capture the high-impact and risk issues discovered in running the tests.
+ </li>
+ <li>
+ Identify errors in test creation, data inputs, or integrating applications and any architectural anomalies.
+ </li>
+ <li>
+ Isolate the target of the test to determine failure points.
+ </li>
+ <li>
+ Diagnose failure symptoms and characteristics.
+ </li>
+ <li>
+ Assess and identify possible solutions.
+ </li>
+</ul>
+<p>
+ After completing these steps, verify that you have enough details to determine the impact of the results. In addition,
+ make sure that enough information exists to assist individuals who are performing dependent tasks.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_0XzAwDO2EduqsLmIADMQ9g" name="Identify failures and propose solutions" guid="_0XzAwDO2EduqsLmIADMQ9g">
+ <sectionDescription><p>
+ Identify whether or not the test has failed and propose a solution based on the type of test and category of
+ failure.&nbsp; The approach to testing will determine the identified failures and candidates for solutions.
+</p>
+<p>
+ Tests that are programmer supporting are used to help prepare and ensure confidence in the code.&nbsp;When identifying
+ failures and proposing solutions for programmer supporting tests:
+</p>
+<ul>
+ <li>
+ Failures will be identified at an object or element level.
+ </li>
+ <li>
+ Solutions will be to help clarify the problem.
+ </li>
+</ul>
+<p>
+ Test that are business supporting are used to uncover prior mistakes and omissions.
+</p>
+<ul>
+ <li>
+ Failures will identify omissions in requirements.
+ </li>
+ <li>
+ Solutions will help to clarify expectations of the system.
+ </li>
+</ul>
+<p>
+ After you have this information and the steps proposed to resolve the failures, you can effectively categorize the type
+ of failure and the appropriate type of solution.
+</p>
+<p>
+ See <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">[MAR03]</a> for more information.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_3t6oADO2EduqsLmIADMQ9g" name="Communicate test results" guid="_3t6oADO2EduqsLmIADMQ9g">
+ <sectionDescription><p>
+ Communicate the test results to the team. For failed tests this might involve adding bugs to the <a class="elementLink" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
+</p>
+<p>
+ Communicating test results can affect the perception of the effectiveness of the tests. When communicating test
+ results, it is important that you:
+</p>
+<ul>
+ <li>
+ Know the audience, so that appropriate information is communicated appropriately
+ </li>
+ <li>
+ Run tests or scenarios that are likely to uncover the high-impact and risk issues or represent actual use of the
+ system
+ </li>
+</ul>
+<p>
+ When preparing test result reports, answer the following questions:
+</p>
+<ul>
+ <li>
+ How many test cases exist, and what are their states (pass, fail, blocked, and so on)?
+ </li>
+ <li>
+ How many bug reports have been filed, and what are their states (open, assigned, ready for testing, closed,
+ deferred)?
+ </li>
+ <li>
+ What trends and patterns do you see in test case and bug report states, especially opened and closed bug reports
+ and passed and failed test cases?
+ </li>
+ <li>
+ For test cases that were blocked or skipped, why are they in this state?
+ </li>
+ <li>
+ Considering all test cases not yet run (and perhaps not even created yet), what key risks and areas of
+ functionality remain untested?
+ </li>
+ <li>
+ For failed test cases, what are the associated bug reports?
+ </li>
+ <li>
+ For bug reports ready for confirmation testing, when can your team perform the test?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <purpose>To execute tests and evaluate the test results.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/architecture_notebook.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/architecture_notebook.xmi
new file mode 100644
index 0000000..e4cdfeb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/architecture_notebook.xmi
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_H4gOYKYTEdmvhNXG0Oc2uA" name="architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw" guid="_H4gOYKYTEdmvhNXG0Oc2uA" changeDate="2007-03-03T10:34:06.078+0000" version="1.0.0">
+ <mainDescription><p>
+ This artifact&nbsp;is a communication vehicle that tells Developers what pieces to build, as well as how those pieces
+ behave and interact with each other. It determines the project structure so that managers can plan the project. It also
+ gives whoever must maintain and change the architecture later their first glimpse of the system; and an understanding
+ of the motivation behind the important technical decisions.
+</p>
+<p>
+ This artifact focuses on specific aspects of the design, concentrating on structure, essential elements, key scenarios
+ and those aspects that have a lasting impact on system qualities such as performance, reliability, adaptability and
+ cost. It defines the set of mechanisms, patterns and styles that will guide the rest of the design, assuring its
+ integrity.
+</p>
+<p>
+ Architectural elements make excellent units of implementation, unit testing, integration, configuration management
+ and&nbsp;documentation. The organisation of the architecture can also help the <a class="elementLink"
+ href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Project
+ Manager</a> decide on the organisation of the team.
+</p></mainDescription>
+ <purpose><p>
+ To describe the essential part of the design of the system so the integrity and understandability of the system is
+ assured.
+</p></purpose>
+ <representationOptions><p>
+ The he architecture can be represented in many forms and from many viewpoints, depending on the needs of the project
+ and the preferences of the project team. The architecture can be expressed as a simple metaphor or as a comparison to a
+ predefined architectural style or set of styles. It may be a precise set of models or documents that describe the
+ various aspects of the system's key elements. Expressing it as skeletal build is another option - although this build
+ may need to be baselined and preserved to ensure that the essence of the system can be understood as the system grows.
+</p>
+<p>
+ It is frequently a design artifact that must be represented in a readable and accessible way. It can reference models
+ that describe <a class="elementLink"
+ href="./../../openup_basic/guidances/guidelines/architectural_view,_T9nygClEEduLGM8dfVsrKg.html"
+ guid="_T9nygClEEduLGM8dfVsrKg">Architectural View</a>s for communicating the architecture. A view is a representation
+ of a system from the perspective of a related set of concerns.&nbsp;To choose the appropriate set of
+ views,&nbsp;identify the Stakeholders who depend on software architecture documentation and the information that they
+ need.
+</p>
+<p>
+ It need not be a formal document. The essence of the architecture can often be communicated through a series of simple
+ diagrams on a whiteboard; or as a list of decisions. Choose the medium that best meets the needs of the project.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/build.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/build.xmi
new file mode 100644
index 0000000..d6e11e4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/build.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqSB0KeqEdmKDbQuyzCoqQ" name="build,_0YuXEMlgEdmt3adZL5Dmdw" guid="_NqSB0KeqEdmKDbQuyzCoqQ" changeDate="2007-01-30T15:24:06.639-0500">
+ <mainDescription><p>
+ This working version of the system is the result of putting the implementation of the system through a build process
+ (typically an automated build script) that creates an executable version of the system, or one that runs.&nbsp; This
+ executable version of the system will typically have a number of supporting files that are also considered part of this
+ composite artifact.
+</p></mainDescription>
+ <keyConsiderations><p>
+ In an iterative lifecycle, each build must evolve from the previous iteration's build, adding more functionality and
+ improving quality.
+</p>
+<p>
+ The purpose of early builds that minimize or eliminate a risk or verify architectural decisions is to achieve
+ consistently stable builds in later iterations.
+</p></keyConsiderations>
+ <purpose>Deliver incremental value to the user and customer, and provide a testable artifact for verification.</purpose>
+ <reasonsForNotNeeding><p>
+ There will always need to be an&nbsp;operational version of the system.
+</p></reasonsForNotNeeding>
+ <representationOptions><p>
+ This work product is&nbsp;almost always a composite product made up of numerous parts required to make the executable
+ system. Therefore a build is more than just executable files; it additionally includes such things as configuration
+ files, help files, and data repositories that will be put together resulting in the product that will be run by the
+ users. The specifics of those parts will vary by technology in use.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/design.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/design.xmi
new file mode 100644
index 0000000..01bbce6
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/design.xmi
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" name="design,_0WuL8slgEdmt3adZL5Dmdw" guid="_zxB-QKYcEdmvhNXG0Oc2uA" changeDate="2007-03-03T07:48:41.814-0500" version="1.0.0">
+ <mainDescription><p>
+ This product can describe multiple static and dynamic views of the system for examination. Although various views may
+ focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit
+ together without contradiction.
+</p>
+<p>
+ It describes the elements that will make up the implemented system. It communicates abstractions of particular portions
+ of the implementation and can describe an&nbsp;encapsulated subsystem, a high-level analysis of the system, a view of
+ the system in only one context, or other perspectives that explain a solution to a specific problem that needs to be
+ communicated.
+</p></mainDescription>
+ <purpose><p>
+ Describe the&nbsp;elements of the system&nbsp;so&nbsp;they can be examined and understood in ways not&nbsp;possible by
+ reading the source code.
+</p></purpose>
+ <impactOfNotHaving><p>
+ Implementation will proceed with fine-grained, inconsistent tactical decisions that lead to poor-quality software.
+</p></impactOfNotHaving>
+ <reasonsForNotNeeding>Some representation of the design will always be necessary. In circumstances where a project involves applying
+well-understood, existing strategies for architecture and design, it is possible that you will not need a <em>new</em>
+design. In those cases, you can simply refer to some existing design.</reasonsForNotNeeding>
+ <representationOptions><p>
+ It is important that the author of this work product be able to analyze key decisions about the structure and behavior
+ of the system and communicate them to other collaborators. It is also important that these decisions can be
+ communicated at various levels of abstraction and granularity. Some aspects of the design can be represented by source
+ code, possibly with some extra annotations. But more abstract representations of the design will be at a higher-level
+ than source code.
+</p>
+<p>
+ The more abstract representation could use various representation options. UML could be used either strictly or
+ informally; it is a preferred notation based on its rich semantics and broad usage in the industry. Other techniques
+ could be used to communicate the design. Or the design could use a mix of techniques as applicable.
+</p>
+<p>
+ Whether you record these representations on a white board or use a formal tool is not governed by this process. But any
+ representation, whether characterized as formal or informal, should unambiguously communicate the technical decisions
+ embodied by the design.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/design_vm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/design_vm.xmi
new file mode 100644
index 0000000..b3d89bd
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/design_vm.xmi
@@ -0,0 +1,5 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<com.ibm.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.uma="http://www.ibm.com/uma/1.0.2/uma.ecore" xmi:id="-vErMTo5DGQ1v_3_GNsccNw" name="design_vm,_ZTGAYL3uEdqLRJZPGVbHDA" guid="-vErMTo5DGQ1v_3_GNsccNw" changeDate="2006-07-30T08:17:30.553-0400">
+ <representationOptions>Whether&nbsp;maintained as a complete, semantically-rich&nbsp;model of the design in some tool or represented informally
+for the sake of investigation and communication, the design should be rendered visually.</representationOptions>
+</com.ibm.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/developer_test.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/developer_test.xmi
new file mode 100644
index 0000000..9a516e9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/developer_test.xmi
@@ -0,0 +1,73 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqSB0qeqEdmKDbQuyzCoqQ" name="developer_test,_0YuXEclgEdmt3adZL5Dmdw" guid="_NqSB0qeqEdmKDbQuyzCoqQ" changeDate="2006-12-21T12:11:53.042-0500" version="1.0.0">
+ <mainDescription><p> This artifact covers all of
+ the steps that are required to validate
+ a software component. It specifies test entries,
+ execution conditions, and expected results. These details
+ are identified for the purpose of evaluating a
+ particular aspect of a scenario. </p>
+<p> The tests should be self-documenting in a way that
+ makes it clear upon completion of the test whether the component has
+ run correctly. </p></mainDescription>
+ <purpose>Evaluate that a software component performs as specified.</purpose>
+ <impactOfNotHaving>Not having developer tests can inhibit iterative development, because
+there is no assurance that modified components are still working correctly
+when you modify components iteration by iteration.</impactOfNotHaving>
+ <reasonsForNotNeeding>If the tests can be embedded into the actual production code, you might not need a separate work product. Nonetheless, some
+level of support for developer testing is always necessary.</reasonsForNotNeeding>
+ <briefOutline><p>
+ There is no predefined template for this&nbsp;work product and a testing tool will&nbsp;affect how the work product is
+ handled, but here are some key issues that should be addressed:
+</p>
+<ul>
+ <li>
+ Setup
+ </li>
+ <li>
+ Inputs
+ </li>
+ <li>
+ Script
+ </li>
+ <li>
+ Expected Results
+ </li>
+ <li>
+ Evaluation Criteria
+ </li>
+ <li>
+ Clean-Up
+ </li>
+</ul></briefOutline>
+ <representationOptions><p align="left">
+ The following are recommendation and options for representing this work product.
+</p>
+<h4>
+ Recommendation: Automated Code Unit
+</h4>
+<p>
+ The most appropriate technique for running these tests is using code that tests the components fully and that you can
+ run regularly as you update the system during development.
+</p>
+<p>
+ When code is the&nbsp;sole form of the tests, you must take care to ensure that the code is self-documenting, including
+ specifications of what conditions you are testing and what setup or clean-up is required for the test to run properly.
+</p>
+<h4>
+ Option: Manual Instructions
+</h4>
+<p>
+ In some cases, manual instructions can suffice. For example, when testing a user interface, a Developer could walk
+ through a script, explaining the component. In this case, it can still be valuable to create a test harness that goes
+ straight to the user interface. That way, the Developer can follow the script without having to walk through a
+ complicated set of instructions to get to a particular screen or page.
+</p>
+<h4>
+ Option: Embedded Code
+</h4>
+<p>
+ Certain technologies (such as Java&trade; 5 Test Annotation) enable you to embed tests in the implementation. In those cases,
+ there will be a logical work product, but it will be assimilated into the code that you are testing. Here, too, take
+ into consideration that you must ensure that the code is self-documenting.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/glossary.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/glossary.xmi
new file mode 100644
index 0000000..5cb0aa1
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/glossary.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-iOn7_gfX_iELWRNGJ2JKPQ" name="glossary,_Wn7HcNcEEdqz_d2XWoVt6Q" guid="-iOn7_gfX_iELWRNGJ2JKPQ" changeDate="2006-12-21T14:23:00.396-0500" version="1.0.0">
+ <mainDescription><p>
+ The Glossary helps you avoid miscommunication by providing two essential resources:
+</p>
+<ul>
+ <li>
+ A central location to look for terms and abbreviations that are new to development team members
+ </li>
+ <li>
+ Definitions of terms that are used in specific ways within the domain
+ </li>
+</ul>
+<p>
+ Definitions for the Glossary terms come from several sources, such as requirements documents, specifications, and
+ discussions with Stakeholders and domain experts.
+</p></mainDescription>
+ <keyConsiderations><p>
+ In some projects that do not involve business or domain modeling, the Glossary is the primary artifact for capturing
+ information about the project's business domain.
+</p>
+<p>
+ Although listed as an output from, and an input to tasks associated with the requirements discipline, this artifact can
+ be updated at any time, by any role, as new terms are identified.
+</p></keyConsiderations>
+ <purpose>The goal is for the Glossary to provide a common
+vocabulary agreed upon by all Stakeholders. It can
+help people from different functional groups reach a mutual
+understanding of the&nbsp;system.
+<!--StartFragment -->
+The goal is not to record all possible terms, but only those
+that are unclear, ambiguous, or require elaboration.</purpose>
+ <impactOfNotHaving>Misunderstandings about the meanings of data items account for many failed projects.
+Some of them become obvious only in the late stages of system testing and can
+be extremely expensive to correct.</impactOfNotHaving>
+ <representationOptions><p>
+ The Glossary is a simple alphabetized listing of domain terms and their definitions.&nbsp; It can be captured in a
+ spreadheet,&nbsp;document, or&nbsp;published on a Wiki site to simplify access and maintenance.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/implementation.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/implementation.xmi
new file mode 100644
index 0000000..8f69f62
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/implementation.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_6u9ZsKYcEdmvhNXG0Oc2uA" name="implementation,_0YoQcMlgEdmt3adZL5Dmdw" guid="_6u9ZsKYcEdmvhNXG0Oc2uA" authors="Jim Ruehlin" changeDate="2007-03-02T10:47:39.492-0800" version="1.0.0">
+ <mainDescription><p>
+ This artifact&nbsp;is the collection of one or more of&nbsp;these elements:
+</p>
+<ul>
+ <li>
+ Source code files
+ </li>
+ <li>
+ Data files&nbsp;
+ </li>
+ <li>
+ Build scripts
+ </li>
+ <li>
+ Other files that are transformed into the executable system
+ </li>
+</ul></mainDescription>
+ <purpose><p>
+ To represent the physical parts that make up the system to be built, organized in a way that is understandable and
+ manageable.
+</p></purpose>
+ <representationOptions><p>
+ Implementation files represented as files in the local file system. File folders (directories), represented as
+ packages, group the files into logical units.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/iteration_plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/iteration_plan.xmi
new file mode 100644
index 0000000..ae48460
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/iteration_plan.xmi
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_BcBR8KX5EdmvhNXG0Oc2uA" name="iteration_plan,_0aQBEslgEdmt3adZL5Dmdw" guid="_BcBR8KX5EdmvhNXG0Oc2uA" changeDate="2006-09-01T13:47:45.470-0700">
+ <mainDescription><p>
+ The main objectives of the iteration plan is to provide the team with one central place for information regarding
+ iteration objectives, detailed plan with task assignments, and evaluation results. This artifcat also helps the team to
+ monitor the progress of the iteration.
+</p>
+<p>
+ The task assignments for an iteration is a subset of all tasks on the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>, therefore the iteration plan ideally references those
+ work items.
+</p></mainDescription>
+ <purpose><p>
+ Communicate the objectives, task assignment, and evaluation criteria for a given iteration.
+</p></purpose>
+ <representationOptions><p>
+ The level of detail/formality of the plan must be adapted to what you need to successfully meet these objectives.The
+ plan could, for example, be captured
+</p>
+<ul>
+ <li>
+ on a whiteboard listing the objectives, task assignments and evaluation criteria,
+ </li>
+ <li>
+ a 1-page document listing the objectives and evaluation criteria of the iteration, as well as referencing the
+ Work Items List for assignments for that iteration,
+ </li>
+ <li>
+ a more complex document, supported by a Gantt or Pert chart in a project planning tool.
+ </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/iteration_plan_pm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/iteration_plan_pm.xmi
new file mode 100644
index 0000000..bebecf9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/iteration_plan_pm.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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="-b9hejTMj8E7U4g2v80xDjA" name="pm_iteration_plan,_xWdL0Dn6Edu_y4hBImiwwQ" guid="-b9hejTMj8E7U4g2v80xDjA" changeDate="2006-09-01T14:06:34.954-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/project_plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/project_plan.xmi
new file mode 100644
index 0000000..ff08177
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/project_plan.xmi
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_IbVp8KX4EdmvhNXG0Oc2uA" name="project_plan,_0a6vcMlgEdmt3adZL5Dmdw" guid="_IbVp8KX4EdmvhNXG0Oc2uA" changeDate="2006-10-30T15:33:37.069-0800" version="1.0.0">
+ <mainDescription><P><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p>This artifact&nbsp;defines the parameters for project progress tracking and specifies the high-level objectives of the iterations and their milestones. Additionally,&nbsp;it describes how the project is organized and which roles are assigned to whom.</o:p></SPAN></P>
+<P><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><o:p>The project manager is responsible for developing the project plan, working very closely with the rest of the team. The project plan allows stakeholders and other team members to understand the big picture and, roughly, when to expect what level of functionality.</o:p></SPAN><SPAN style="FONT-SIZE: 10pt; mso-bidi-font-family: Arial"><o:p><BR></P></o:p></SPAN></mainDescription>
+ <purpose><p>
+ The purpose of this artifact is&nbsp;to provide a central document where any project team member can find the
+ information on how the project will be managed.&nbsp;
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/md_acto2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/md_acto2.gif
new file mode 100644
index 0000000..29ede3a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/md_acto2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/md_acto3.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/md_acto3.gif
new file mode 100644
index 0000000..43fbf21
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/md_acto3.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/supporting_reguirements2.gif b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/supporting_reguirements2.gif
new file mode 100644
index 0000000..cf4c368
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/resources/supporting_reguirements2.gif
Binary files differ
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/risk_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/risk_list.xmi
new file mode 100644
index 0000000..2f3b864
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/risk_list.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-4VJ_0upihz-bR7VRlm63Vw" name="risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA" guid="-4VJ_0upihz-bR7VRlm63Vw" changeDate="2006-10-30T16:42:53.506-0800">
+ <mainDescription>This list identifies, in decreasing order of priority, the events that could lead to a significant negative outcome. It
+serves as a focal point for project activities and is the basis around which iterations are organized. <!--EndFragment--></mainDescription>
+ <keyConsiderations><p>
+ This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider
+ whether they are really serious risks. Tracking more than 20 risks is an onerous task.
+</p></keyConsiderations>
+ <purpose>To&nbsp;capture the perceived risks to the success of the project.</purpose>
+ <representationOptions><h4>
+ Option: list of risks captured in the project plan
+</h4>
+<p>
+ In this approach you put the overall risk list in the project plan. The iteration plan will contain only the tasks you
+ will be doing during the iteration to mitigate the risks. This will ensure that the iteration plan contains only
+ iteration information. The project plan has to be revisited constantly as you update risks.
+</p>
+<h4>
+ Option: list of risks captured in&nbsp;the iteration plan
+</h4>
+<p>
+ In this approach you enter the overall risk list in the current iteration plan. This approach ensures that you look at
+ the risk list at each iteration, as it is part of your iteration plan. The only drawback is that your iteration plan
+ will contain information that is not relevant to the current iteration. All the risks you have not&nbsp;mitigated
+ during the iteration&nbsp;have to be&nbsp;transferred to the next iteration plan.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/status_assessment.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/status_assessment.xmi
new file mode 100644
index 0000000..a3323ec
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/status_assessment.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_K-e8IKX4EdmvhNXG0Oc2uA" name="status_assessment,_0bA2EMlgEdmt3adZL5Dmdw" guid="_K-e8IKX4EdmvhNXG0Oc2uA" changeDate="2006-11-01T15:32:14.824-0800" version="1.0.0">
+ <purpose><p>
+ Capture and communicate whether the project is on track, requires corrective actions, and whether there are
+ opportunities for improvement.
+</p></purpose>
+ <impactOfNotHaving>The team may not understand whether they are on track or not, and whether established iteration objectives and evaluation
+criteria are met. The team may not be able to improve the way they develop software.</impactOfNotHaving>
+ <representationOptions><p>
+ The format of the status assessment varies from one&nbsp;project to another. It can be the minutes of an assessment
+ meeting, an update to a web site, or just an email. The important thing&nbsp;is to effectively communicate&nbsp;to all
+ involved parties whether iteration objectives and evaluation criteria were addressed, and what improvements are
+ needed&nbsp;to the way the team is working.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/supporting_requirements.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/supporting_requirements.xmi
new file mode 100644
index 0000000..40df95d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/supporting_requirements.xmi
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" name="supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" changeDate="2006-12-21T12:42:23.035-0500">
+ <mainDescription><p>
+ Supporting Requirements and Use Cases, together, define the system requirements. Use Cases describe the behavioral
+ requirements for the system, and Supporting Requirements describe system-wide requirements that are not captured in Use
+ Case Specifications. Making this distinction simplifies maintenance.
+</p>
+<p>
+ Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,
+ Performance, Supportability + Constraints). For more information on this classification, see <a
+ class="elementLinkWithType"
+ href="./../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html"
+ guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.
+</p>
+<p>
+ The figure that follows illustrates the relationship among the Supporting Requirements, Use Case Specifications, and
+ Actors.
+</p>
+<p>
+ &nbsp;<img height="400" alt="" src="./resources/supporting_reguirements2.gif" width="600" />
+</p></mainDescription>
+ <impactOfNotHaving><p> The goal of&nbsp;this&nbsp;work product is&nbsp;to make sure that all types
+ of requirements are covered, which reduces the risk of not considering some
+ important facet of the system.&nbsp;FURPS+ requirements are system-wide, and
+ they&nbsp;influence the Architectural Mechanisms that you will create, thus
+ guiding development of the system's foundation.
+ These requirements are frequently the major cost item,
+ because they determine architectural choices.<strong>
+ </strong></p>
+<p> Furthermore, if you do not capture system-wide requirements in a central location,
+ but repeat them throughout the Use Cases, the result will
+ be more maintenance and more chance for error. </p></impactOfNotHaving>
+ <representationOptions><p> This work product does not imply using only one
+ document to capture all requirement types. To manage the communication of the
+ information, it makes more sense to separate the information into separate documents
+ or to use the Work Items List.<strong> </strong></p>
+<p align="left"> The following are recommendation and options for representing
+ the Supporting Requirements:</p>
+<h4> Option: Use the Work Items List</h4>
+<p> Consider capturing Supporting Requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
+ Work Items List</a>, which you can use for prioritizing and managing requirements.
+ If Stakeholders are comfortable with it, or with accessing a report automatically
+ generated from it, then you do not need a separate document. </p>
+<h4>
+ Option: Include as Part of the Vision Document
+</h4>
+<p> Consider including some types of Supporting Requirements in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact:
+ Vision</a>. To keep the Vision stable, follow this option for the requirements
+ types that need less refinement, such as Product Qualities, Documentation, or
+ Compliance. </p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/supporting_requirements_intent_req.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/supporting_requirements_intent_req.xmi
new file mode 100644
index 0000000..3c18369
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/supporting_requirements_intent_req.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-SUqkkwrs1D_5YXZls-3YBg" name=",_oclg0DRXEdudA-StyUUwnw" guid="-SUqkkwrs1D_5YXZls-3YBg" changeDate="2006-09-14T09:34:35.021-0400">
+ <representationOptions><h4>
+ Recommendation: Use the Supporting Requirements Specification Template
+</h4>
+<p>
+ <a class="elementLinkWithType" href="./../../openup_basic/guidances/templates/supporting_requirements_spec,_ItYXcNa9Edqrw4BYKyYKiA.html" guid="_ItYXcNa9Edqrw4BYKyYKiA">Template: Supporting Requirements Specification</a>&nbsp;provides a tool to capture,
+ structure, and organize the supporting requirements.
+</p>
+<p>
+ Even in a small project, a requirements management tool, a database, or a spreadsheet, are recommended for prioritizing
+ and managing requirements. If Stakeholders are comfortable with accessing requirements directly from that tool or with
+ accessing a report automatically generated from the tool, you will not need a separate document.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_case.xmi
new file mode 100644
index 0000000..69061ed
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_case.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqYIdKeqEdmKDbQuyzCoqQ" name="test_case,_0ZS-0MlgEdmt3adZL5Dmdw" guid="_NqYIdKeqEdmKDbQuyzCoqQ" changeDate="2006-09-20T16:57:14.165-0700">
+ <mainDescription><p>
+ A test case specifies the conditions which need to be validated to enable an assessment of some particular aspects of
+ the system under test.&nbsp; A test case is more formal than a test idea and usually takes the form of a
+ specification.&nbsp;In less formal environments, test cases can be created by identifying a unique ID, name, associated
+ test data, and expected results.&nbsp;For an example of this type of test case, see&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/templates/test_case,_0dT8IMlgEdmt3adZL5Dmdw.html" guid="_0dT8IMlgEdmt3adZL5Dmdw">Template: Test Case</a>.
+</p>
+<p>
+ Test cases may be derived from&nbsp;many&nbsp;sources but will usually include a subset of both the requirements (such
+ as use cases, performance characteristics, reliability concerns) and other types of quality attributes.&nbsp; For more
+ information on types of tests and their relationship to quality test attributes, see&nbsp;<a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/types_of_test,_0aJ6cMlgEdmt3adZL5Dmdw.html" guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Types of Test</a>.
+</p></mainDescription>
+ <purpose><p>
+ The purpose of this artifact is to:
+</p>
+<ul>
+ <li>
+ provide a way to capture test inputs, conditions, and expected results for a system
+ </li>
+ <li>
+ systematically identify aspects of the software to test
+ </li>
+ <li>
+ specify whether an expected result has been reached based on verification of a system requirement, set of
+ requirements, or scenario
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_log.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_log.xmi
new file mode 100644
index 0000000..217ba29
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_log.xmi
@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_NqePEKeqEdmKDbQuyzCoqQ" name="test_log,_0ZlSsMlgEdmt3adZL5Dmdw" guid="_NqePEKeqEdmKDbQuyzCoqQ" changeDate="2006-09-29T19:02:01.621-0400">
+ <mainDescription>This artifact&nbsp;provides a detailed, typically time-based record that serves both as verification that a set of tests
+were executed, and provides information relating to the success of those tests.&nbsp; The focus is typically on the
+provision of an accurate audit trail, enabling post-execution diagnosis of failures to be undertaken.&nbsp; This raw data
+will subsequently be analyzed to help determine the results of some aspect of the test effort.</mainDescription>
+ <purpose><ul>
+ <li>
+ To provide verification that a set of tests was executed
+ </li>
+ <li>
+ To provide information relating to the success of those tests
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_script.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_script.xmi
new file mode 100644
index 0000000..a7221c9
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/test_script.xmi
@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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="_NqYIcqeqEdmKDbQuyzCoqQ" name="test_script,_0ZfMEMlgEdmt3adZL5Dmdw" guid="_NqYIcqeqEdmKDbQuyzCoqQ" changeDate="2005-07-19T16:12:17.077-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/uc_model_intent_req_ucm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/uc_model_intent_req_ucm.xmi
new file mode 100644
index 0000000..b504c01
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/uc_model_intent_req_ucm.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_zHZW9KYSEdmvhNXG0Oc2uA" name="uc_model,_0UCrZclgEdmt3adZL5Dmdw" guid="_zHZW9KYSEdmvhNXG0Oc2uA" changeDate="2006-12-21T09:42:02.273-0800" version="1.0.0">
+ <purpose><p>
+ This artifact presents an overview of the system's intended behavior.&nbsp; It&nbsp;is the basis for agreement
+ between&nbsp;stakeholders and the project team regarding the intended functionality for the system. It also helps to
+ guide the various tasks in the software development lifecycle.
+</p></purpose>
+ <representationOptions><p>
+ Tailor this artifact to support the project team's needs.
+</p>
+<p>
+ Representation options include: reports and diagrams from UML modeling tools, graphical representations created using
+ drawing tools, drawings on whiteboards. Most of the information in the use-case model is captured in the use-case
+ specifications.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/use_case.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/use_case.xmi
new file mode 100644
index 0000000..8d86eb2
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/use_case.xmi
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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="_zHZW8qYSEdmvhNXG0Oc2uA" name="use_case,_0VGbUMlgEdmt3adZL5Dmdw" guid="_zHZW8qYSEdmvhNXG0Oc2uA" changeDate="2006-09-13T14:58:40.026-0700">
+ <purpose><p> The primary purpose of the Use Case is to capture the required system behavior
+ from the perspective of the end user, to achieve one or more goals. Different
+ users benefit in different ways, of course: </p>
+<ul>
+ <li> <strong>Customers</strong> use them to describe, or at least to approve,
+ the description of the system's behavior. </li>
+ <li><strong> Potential users</strong> use them to understand the system's behavior.
+ </li>
+ <li><strong> Architects </strong>use them to identify architecturally significant
+ functionality. </li>
+ <li><strong> Developers </strong>use them<strong> </strong> to understand the
+ required system behavior so they can identify classes from the Use Cases'
+ flow of events. </li>
+ <li><strong> Testers</strong> use them as a basis for identifying a subset of
+ the required Test Cases. </li>
+ <li> <strong>M</strong><b>anagers</b> use them<b> </b> to plan and assess the
+ work for each iteration. </li>
+ <li><strong> Technical writers </strong>use them
+ to understand the sequence of system behavior
+ that they need to describe in the documentation. </li>
+</ul></purpose>
+ <representationOptions><p> Decide the extent to which you will elaborate on Use
+ Cases: </p>
+<ul>
+
+ <li> Describe only major flows? </li>
+
+ <li> Describe only the most important Use Cases? </li>
+
+ <li>Fully describe preconditions and post-conditions? </li>
+
+ <li> Describe scenarios first, and then raise the level of abstraction by describing
+ Use Case flows? </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/use_case_intent_req.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/use_case_intent_req.xmi
new file mode 100644
index 0000000..5664855
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/use_case_intent_req.xmi
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-JcGDIeBIMM099mbWX5fXbA" name=",_qis78DRbEduFvfVCXiK3AA" guid="-JcGDIeBIMM099mbWX5fXbA" changeDate="2006-09-14T09:30:41.163-0400">
+ <representationOptions><p>
+ Some projects apply Use Cases informally to help discover requirements, documenting and maintaining these requirements
+ in another form such as user stories. How you tailor Use Cases may depend on project size, team experience, your tool
+ set, the customer relationship, and so forth. See <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q.html" guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance related to documenting
+ Use Cases.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/vision.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/vision.xmi
new file mode 100644
index 0000000..4981962
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/vision.xmi
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" name="vision,_0WVxcMlgEdmt3adZL5Dmdw" guid="_zHTQUKYSEdmvhNXG0Oc2uA" changeDate="2007-02-28T08:55:39.149-0500" version="1.0.0">
+ <mainDescription><p>
+ This artifact&nbsp;provides a complete vision for the software system under development and supports the contract
+ between the customer and the development organization. Every project needs a source for capturing all Stakeholders'
+ expectations.
+</p>
+<p>
+ This artifact&nbsp;is written from the customers' perspective, focusing on the essential features of the system and
+ acceptable levels of quality. The artifact should include a description of what <a class="elementLinkWithUserText"
+ href="./../../openup_basic/guidances/termdefinitions/feature,_PgYREAeYEduWycDgioo5rg.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a>&nbsp;will be included, as well as those considered but not included.
+</p></mainDescription>
+ <purpose><p> This artifact&nbsp;provides a high-level, sometimes contractual, basis for
+ the more detailed technical requirements that are visible to the Stakeholders.
+ It captures the essence of the system by describing high-level
+ requirements and design constraints that give the reader an overview of the
+ system from a behavioral requirements perspective. It serves
+ as input for the project-approval process,
+ communicates the fundamental "what and why" for the project, and provides
+ a plan against which all future decisions should be validated. </p></purpose>
+ <impactOfNotHaving>If this artifact is not used, there is a high risk that Stakeholders and the development
+team will have different expectations.&nbsp;This could lead to cancellation of
+the project.</impactOfNotHaving>
+ <representationOptions>Tailor this artifact as necessary for your project's needs. It is generally good
+practice to keep this artifact brief so you can release
+it to Stakeholders as soon as possible, and to make it easy for Stakeholders to
+read and understand. You can
+accomplish this by including only the most important Stakeholder requests
+and features and avoiding details of requirements.
+You can describe details in the other requirement
+artifacts.</representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/work_items_list.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/work_items_list.xmi
new file mode 100644
index 0000000..ee1880b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/work_items_list.xmi
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-buxz4BVToq97bSxaqyjySg" name="work_items_list,_rGNWsCbSEdqh1LYUOGRh2A" guid="-buxz4BVToq97bSxaqyjySg" changeDate="2006-10-30T14:42:59.632-0800" version="1.0.0">
+ <mainDescription><p>
+ This artifact provides a focal point for the entire team:
+</p>
+<ul>
+ <li>
+ It provides one list containing all requests for additional capabilities or enhancement for that application. Note
+ that some of these requests may never be implemented, or be implemented in later projects
+ </li>
+ <li>
+ It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list
+ is prioritized separately.
+ </li>
+ <li>
+ It provides one place to go to for the development team to understand what needs to be done, get references to
+ material required to carry out the work, and one place to go to report progress made.
+ </li>
+</ul>
+<p>
+ Work items can be very large in scope, especially when capturing requests for enhancements, such as “Support Financial
+ Planning” for a personal finance application. Work Items are analyzed and broken down into smaller Work Items so they
+ can assigned to an iteration, such as a use case scenario for&nbsp;“Calculate Net Worth”. Further breakdown may be
+ required to identify suitable tasks to be assigned to developers, such as “Develop UI for Calculate Net Worth”. This
+ means that Work Items often have parent / child relationships.
+</p></mainDescription>
+ <purpose>To collect all requests for work that will potentially be taken on within the project, so work can be prioritized, effort
+estimated and progress tracked.</purpose>
+ <representationOptions><h3>
+ As a spreadsheet or database
+</h3>
+<p>
+ The Work Items List can be captured as a separate artifact, represented by a spreadsheet or database table, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/examples/work_items_list,_nHomIDgzEdu4E8ZdmlYjtA.html" guid="_nHomIDgzEdu4E8ZdmlYjtA">Example: Work Items List</a>.
+</p>
+<h3>
+ In specific tools
+</h3>
+<p>
+ Project Management, Requirements Management and Change Request tools are an option to capture the list of work to be
+ done.
+</p>
+<h3>
+ Subset As part of the Iteration Plan
+</h3>
+<p>
+ The <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a> typically references Work Items that are assigned to that
+ iteration. If the team is capturing the Iteration Plan on a Whiteboard for example, the team may choose to reference
+ high-level work items in the Work Items List that are assigned to the iteration, and maintain low-level child work
+ items used to track day-to-day work only within an iteration plan.<br />
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/work_items_list_pm.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/work_items_list_pm.xmi
new file mode 100644
index 0000000..3da4895
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducts/work_items_list_pm.xmi
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-fDVhZTkf1TqDyExbI9DM-w" name=",_sNoQ0Dn6Edu_y4hBImiwwQ" guid="-fDVhZTkf1TqDyExbI9DM-w" changeDate="2006-09-07T14:41:14.873-0700">
+ <mainDescription><p>
+ Work Items should contain estimates, see <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/work_items_list,_7vEXEMA4EdqSgKaj2SZBmg.html" guid="_7vEXEMA4EdqSgKaj2SZBmg">Guideline: Work Items List</a>&nbsp;and <a class="elementLinkWithType" href="./../../openup_basic/guidances/guidelines/agile_estimation,_CGHskBEdEdqY7JB6N6CW2w.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/assessment.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/assessment.xmi
new file mode 100644
index 0000000..6f919c4
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/assessment.xmi
@@ -0,0 +1,2 @@
+<?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="-5S6ney_fFdEHm49XznPRiA" name="new_work_product_kind,_2VBNIDz6Edq03rqPoNVoKg" guid="-5S6ney_fFdEHm49XznPRiA" changeDate="2005-10-14T14:38:35.242-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/concept.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/concept.xmi
new file mode 100644
index 0000000..7c5f29a
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/concept.xmi
@@ -0,0 +1,2 @@
+<?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="-Nl-rJ_6aaAG2jpJyGm_wcg" name="new_work_product_kind,_8XKVwDz6Edq03rqPoNVoKg" guid="-Nl-rJ_6aaAG2jpJyGm_wcg" changeDate="2005-10-14T14:39:12.267-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/infrastructure.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/infrastructure.xmi
new file mode 100644
index 0000000..bee3a61
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/infrastructure.xmi
@@ -0,0 +1,2 @@
+<?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="-CKZiRxRx_TZhMbquLd4Sqw" name="new_work_product_kind,_EL6rgDz7Edq03rqPoNVoKg" guid="-CKZiRxRx_TZhMbquLd4Sqw" changeDate="2005-10-14T14:40:04.914-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/model.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/model.xmi
new file mode 100644
index 0000000..ab36227
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/model.xmi
@@ -0,0 +1,2 @@
+<?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="-ARfZUsgYE1XrKQlDgr9mEQ" name="new_work_product_kind,_MQbUgDz7Edq03rqPoNVoKg" guid="-ARfZUsgYE1XrKQlDgr9mEQ" changeDate="2005-10-14T14:40:58.794-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/model_element.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/model_element.xmi
new file mode 100644
index 0000000..802d674
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/model_element.xmi
@@ -0,0 +1,2 @@
+<?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="-cW3aVzDjHhqkVayoItUQqw" name="new_work_product_kind,_SxUOoDz7Edq03rqPoNVoKg" guid="-cW3aVzDjHhqkVayoItUQqw" changeDate="2005-10-14T14:41:44.932-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/plan.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/plan.xmi
new file mode 100644
index 0000000..588a52d
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/plan.xmi
@@ -0,0 +1,2 @@
+<?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="-vpMAMS8Cz-z9DQQhxbjjLA" name="new_work_product_kind,_ZR7b8Dz7Edq03rqPoNVoKg" guid="-vpMAMS8Cz-z9DQQhxbjjLA" changeDate="2005-10-14T14:42:22.998-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/project_data.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/project_data.xmi
new file mode 100644
index 0000000..a2d2d53
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/project_data.xmi
@@ -0,0 +1,2 @@
+<?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="-DBPx56p4GCNFpRTT8uOmiQ" name="new_work_product_kind,_hOaxYDz7Edq03rqPoNVoKg" guid="-DBPx56p4GCNFpRTT8uOmiQ" changeDate="2005-10-14T14:43:18.871-0700"/>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/solution.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/solution.xmi
new file mode 100644
index 0000000..538491b
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/solution.xmi
@@ -0,0 +1,9 @@
+<?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="-sIh01vzZACgxRrG_sv7DVw" name="new_work_product_kind,_mC_6sDz7Edq03rqPoNVoKg" guid="-sIh01vzZACgxRrG_sv7DVw" changeDate="2005-10-14T14:43:49.126-0700">
+ <mainDescription><p>
+ <font face="Arial" size="2">Many work products contribute to the overall solution or product.&nbsp; Tests and test data
+ is needed to validate the solution.&nbsp; User support materials of all sorts are needed in the final product.&nbsp;
+ Source code and other implementation elements are required to build the final product.&nbsp; These work products,
+ including those that ship with the product, are categorized as Solution.</font>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/specification.xmi b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/specification.xmi
new file mode 100644
index 0000000..b488dcb
--- /dev/null
+++ b/OpenUP/OpenUP_baseline_EN/library/openup_basic/workproducttypes/specification.xmi
@@ -0,0 +1,2 @@
+<?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="-C5ih3s1Vn_9qQbjm85-GYg" name="new_work_product_kind,_tJJeADz7Edq03rqPoNVoKg" guid="-C5ih3s1Vn_9qQbjm85-GYg" changeDate="2005-10-14T14:44:42.765-0700"/>
diff --git a/Scrum/Scrum_EN/HTML_to_be_imported/temp b/Scrum/Scrum_EN/HTML_to_be_imported/temp
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/Scrum/Scrum_EN/HTML_to_be_imported/temp
diff --git a/Scrum/Scrum_EN/library/Scrum/about.html b/Scrum/Scrum_EN/library/Scrum/about.html
new file mode 100644
index 0000000..6040025
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/about.html
@@ -0,0 +1,9 @@
+
+<span style="font-weight: bold; font-family: Arial Narrow;">Claude Aubry</span><br/>
+<span style="font-weight: bold; color: rgb(255, 102, 0); font-family: Arial Narrow;">Consultant Méthodes Agiles</span><span style="font-family: Arial Narrow;">
+</span>
+<br/><small style="font-family: Arial Narrow;">
+<span style="color: rgb(102, 102, 102);">Mobile : 06 60 646 946</span>
+<br/>
+<a href="http://scrum.aubryconseil.com">Blog</a> -
+<a href="http://www.aubryconseil.com/">Web</a>
\ No newline at end of file
diff --git a/Scrum/Scrum_EN/library/Scrum/customcategories/Intro.xmi b/Scrum/Scrum_EN/library/Scrum/customcategories/Intro.xmi
new file mode 100644
index 0000000..aa49ac4
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/customcategories/Intro.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-juIDa_fXi2K1BE5NTblPow" name="new_custom_category,_s8y1UABREdu3o4yroaI-tA" guid="-juIDa_fXi2K1BE5NTblPow" changeDate="2006-12-04T21:46:12.515+0100">
+ <mainDescription>Ce site décrit l'utilisation de Scrum</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/customcategories/Scrum Elements.xmi b/Scrum/Scrum_EN/library/Scrum/customcategories/Scrum Elements.xmi
new file mode 100644
index 0000000..35e8dc5
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/customcategories/Scrum Elements.xmi
@@ -0,0 +1,2 @@
+<?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="-zS9h38tmK4L-U9kbgkpGKQ" name="Eléments de Scrum,_nF6fgALYEduFv7wnrO7SvQ" guid="-zS9h38tmK4L-U9kbgkpGKQ" changeDate="2006-07-16T15:44:25.338+0200"/>
diff --git a/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/Scrum/content.xmi b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/Scrum/content.xmi
new file mode 100644
index 0000000..c97db24
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/Scrum/content.xmi
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" epf:version="1.0.0">
+ <org.eclipse.epf.uma:DeliveryProcessDescription xmi:id="-16dzhVoCex78V2iCDZVx0w" name="Scrum,_9llsAQAvEdubGMceRDupFQ" guid="-16dzhVoCex78V2iCDZVx0w">
+ <mainDescription>La production d’une version du logiciel (<a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>) se fait en général en quelques mois. Les fonctionnalités demandées pour la
+release sont collectées dans le backlog de produit et classées par priorité. Le directeur de produit est responsable de
+l’insertion des changements dans ce backlog.&nbsp; <br />
+La release est produite par une série d’itérations de 2 à 4 semaines appelées des <a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s. Le contenu d’un Sprint est défini par l’équipe avec le propriétaire de produit,
+en tenant compte des priorités et de la capacité de l’équipe. L’équipe définit les tâches nécessaires pour réaliser les
+fonctionnalités sélectionnées pour le Sprint.&nbsp; <br />
+Pendant un sprint, des points de contrôle sur l’avancement sont effectués lors des mêlées quotidiennes. Cela permet au
+ScrumMaster de déterminer l’avancement par rapport aux engagements du Sprint et de conseiller des ajustements pour assurer
+le succès du Sprint.&nbsp; <br />
+A la fin de chaque Sprint, l’équipe produit un <a class="elementLink"
+href="./../../Scrum/workproducts/Product increment,_tCmYEP-xEdqLnajTSLeAsA.html" guid="_tCmYEP-xEdqLnajTSLeAsA">Incrément
+de produit</a>&nbsp;potentiellement utilisable, dont l’évaluation permet d’ajuster le backlog pour le Sprint suivant.</mainDescription>
+ <keyConsiderations><p>
+ Scrum contribue à renforcer l’esprit d’équipe dans les projets,&nbsp; avec une collection de pratiques proches de
+ celles que l’on trouve dans des sports collectifs en particulier le rugby.
+</p>
+<br />
+<br /></keyConsiderations>
+ <purpose>.</purpose>
+ <howtoStaff>Une équipe Scrum est composée de 3 à 10 personnes.</howtoStaff>
+ <scope>Scrum ne décrit pas toutes les disciplines du développement de logiciel (analyse, conception, codage, test) et doit être
+considéré, plutôt qu’un processus complet, comme un pattern de processus qui est à utiliser pour la gestion de projet et la
+gestion des exigences. <br />
+Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement.</scope>
+ <estimatingTechnique><p>
+ Il est conseillé de pratiquer une estimation basée sur les points (story points), associés aux éléments du backlog.
+</p></estimatingTechnique>
+ </org.eclipse.epf.uma:DeliveryProcessDescription>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" name="Phase de préparation,_37TdkAL_EduOAKqB9I73uw" guid="-WiMYK8iwLeOO-sSBRBjbNQ">
+ <mainDescription><p>
+ Scrum ne prend pas en compte tous les aspects de préparation d'un projet. Seules sont présentées les taches spécifiques
+ de Scrum plus une qui regroupe tous les travaux pouvant etre réalisés
+</p></mainDescription>
+ </org.eclipse.epf.uma:ActivityDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" name="Travaux quotidiens,_nXmKUANlEduYd-55D-Aiqg" guid="-EpBaHVCIYCqqGX_wv7dlYA">
+ <refinedDescription>Scrum ne propose rien pour la réalisation de ces tâches techniques de conception, codage et test mais se conjugue bien avec
+l’utilisation des techniques XP (binômage, développement dirigé par les tests…). <br />
+Les tâches ne sont pas assignées par le ScrumMaster mais choisies par les membres de l’équipe au fur et à mesure. <br />
+L’équipe met à jour, chaque fois que c’est nécessaire, l’estimation du reste à faire sur les tâches du <br />
+backlog du sprint.</refinedDescription>
+ </org.eclipse.epf.uma:DescriptorDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" name="Sprint de release,_zbM2QIGBEduKE9hnyImx1Q" guid="-EOwIzNPjfNIjzJ3TRAgeWQ">
+ <keyConsiderations>Essayer de ne pas modifier de code lors du dernier sprint, c'est trop tard et risqué.</keyConsiderations>
+ <usageGuidance>Il est optionnel. Cela dépend de la façon dont le produit est mis à disposition de ses utilisateurs finals. On en devrait
+dérouler ce sprint optionnel que des travaux qu'il est impossible de faire avant, dans les sprints "normaux".</usageGuidance>
+ <refinedDescription><p>
+ Les tâches effectuées pendant ce sprint dépendent fortement du type de déploiement du logiciel.
+</p>
+<p>
+ On peut y trouver des travaux portant sur :
+</p>
+<ul>
+ <li>
+ mise en production à chaud,
+ </li>
+ <li>
+ packaging du produit,
+ </li>
+ <li>
+ mise à disposition par téléchargement en ligne,
+ </li>
+ <li>
+ documentation technique,
+ </li>
+ <li>
+ formation des utilisateurs,
+ </li>
+ <li>
+ marketing du produit.
+ </li>
+</ul></refinedDescription>
+ </org.eclipse.epf.uma:DescriptorDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" name="Sprint backlog,_glbG2wMAEduOAKqB9I73uw" guid="-MupkaQeHNEmiF7Lnl3VirQ">
+ <usageGuidance>Un par sprint</usageGuidance>
+ </org.eclipse.epf.uma:DescriptorDescription>
+</xmi:XMI>
diff --git a/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/Scrum/model.xmi b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/Scrum/model.xmi
new file mode 100644
index 0000000..eafcf7c
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/Scrum/model.xmi
@@ -0,0 +1,982 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_9m1CIAAvEdubGMceRDupFQ" guid="_9m1CIAAvEdubGMceRDupFQ">
+ <resourceDescriptors xmi:id="_9m1CIQAvEdubGMceRDupFQ" id="-16dzhVoCex78V2iCDZVx0w" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_-d2LQQMEEduOAKqB9I73uw" id="-WiMYK8iwLeOO-sSBRBjbNQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_8N5DwANlEduYd-55D-Aiqg" id="-EpBaHVCIYCqqGX_wv7dlYA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_iCOP4IGPEduKE9hnyImx1Q" id="-EOwIzNPjfNIjzJ3TRAgeWQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_tObbkLPBEduk5O8SjA21Fg" id="-MupkaQeHNEmiF7Lnl3VirQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_9llsAAAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAAAvEdubGMceRDupFQ">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_37NW8AL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37NW8AL_EduOAKqB9I73uw">
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_37TdkAL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37TdkAL_EduOAKqB9I73uw" briefDescription="Cette phase initiale permet de préparer tout ce qui est nécessaire avant de commencer la série des sprints" presentationName="Phase de préparation" isOptional="true" superActivities="_9llsAQAvEdubGMceRDupFQ" breakdownElements="_zYT-EQMAEduOAKqB9I73uw _zYaEsAMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw _zYaEswMAEduOAKqB9I73uw _zYaEtAMAEduOAKqB9I73uw _7FGsMANkEduYd-55D-Aiqg _7FGsMQNkEduYd-55D-Aiqg _O6XmcANlEduYd-55D-Aiqg">
+ <presentation xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-WiMYK8iwLeOO-sSBRBjbNQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zYT-EQMAEduOAKqB9I73uw" name="Plan release" guid="_zYT-EQMAEduOAKqB9I73uw" presentationName="Planifier la release" superActivities="_37TdkAL_EduOAKqB9I73uw" linkToPredecessor="_2vOSsAMEEduOAKqB9I73uw _MEJPgAPOEdubhrgDuRb4fA _MEPWIAPOEdubhrgDuRb4fA" additionallyPerformedBy="_zYaEswMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw" mandatoryInput="_zYaEtAMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ho-aIP_BEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_8qN08APJEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_BuXEQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_EaLKQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_HDZ2UAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_I71XkAPKEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsAMAEduOAKqB9I73uw" name="Product Owner" guid="_zYaEsAMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_37TdkAL_EduOAKqB9I73uw" responsibleFor="_zYaEtAMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsgMAEduOAKqB9I73uw" name="Team" guid="_zYaEsgMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEswMAEduOAKqB9I73uw" name="ScrumMaster" guid="_zYaEswMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_zYaEtAMAEduOAKqB9I73uw" name="Product Backlog" guid="_zYaEtAMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_2vOSsAMEEduOAKqB9I73uw" guid="_2vOSsAMEEduOAKqB9I73uw" linkType="finishToFinish"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_7FGsMANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_7FGsMANkEduYd-55D-Aiqg" presentationName="Produire le backlog de produit initial" superActivities="_37TdkAL_EduOAKqB9I73uw" additionallyPerformedBy="_7FGsMQNkEduYd-55D-Aiqg _zYaEsgMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_BGFMoANkEduYd-55D-Aiqg"/>
+ <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_pWL_gAPJEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_u0Z7sAPJEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_7FGsMQNkEduYd-55D-Aiqg" name="StakeHolder" guid="_7FGsMQNkEduYd-55D-Aiqg" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_O6XmcANlEduYd-55D-Aiqg" name="Preparation work" guid="_O6XmcANlEduYd-55D-Aiqg" presentationName="Travaux de préparation" isPlanned="true" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw" performedPrimarilyBy="_zYaEsgMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEJPgAPOEdubhrgDuRb4fA" guid="_MEJPgAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_7FGsMANkEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEPWIAPOEdubhrgDuRb4fA" guid="_MEPWIAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_O6XmcANlEduYd-55D-Aiqg"/>
+ <diagrams xmi:id="_y9sh0AMEEduOAKqB9I73uw" guid="_y9sh0AMEEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yocAMEEduOAKqB9I73uw" guid="_y9yocAMEEduOAKqB9I73uw">
+ <position xmi:id="_y9yocQMEEduOAKqB9I73uw" x="84.0" y="34.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2vIMEQMEEduOAKqB9I73uw" guid="_2vIMEQMEEduOAKqB9I73uw" anchor="_2vIMEAMEEduOAKqB9I73uw _2vIMEgMEEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vOSsQMEEduOAKqB9I73uw" guid="_2vOSsQMEEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_2QAAEgMEEduOAKqB9I73uw" guid="_2QAAEgMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_2vIMEAMEEduOAKqB9I73uw" guid="_2vIMEAMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw">
+ <position xmi:id="_2vIMEwMEEduOAKqB9I73uw" x="155.0" y="50.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yocgMEEduOAKqB9I73uw" guid="_y9yocgMEEduOAKqB9I73uw"/>
+ <size xmi:id="_y9yocwMEEduOAKqB9I73uw" width="130.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yodAMEEduOAKqB9I73uw" guid="_y9yodAMEEduOAKqB9I73uw">
+ <position xmi:id="_y9yodQMEEduOAKqB9I73uw" x="158.0" y="214.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nqi5YYGGEduKE9hnyImx1Q" guid="_nqi5YYGGEduKE9hnyImx1Q" anchor="_nqi5YIGGEduKE9hnyImx1Q _nqi5YoGGEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_2vIMEgMEEduOAKqB9I73uw" guid="_2vIMEgMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_MEDI4gPOEdubhrgDuRb4fA" guid="_MEDI4gPOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_nqi5YIGGEduKE9hnyImx1Q" guid="_nqi5YIGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q">
+ <position xmi:id="_nqi5Y4GGEduKE9hnyImx1Q" x="171.0" y="228.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yodgMEEduOAKqB9I73uw" guid="_y9yodgMEEduOAKqB9I73uw" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_y9yodwMEEduOAKqB9I73uw" width="88.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_03XZMAMEEduOAKqB9I73uw" guid="_03XZMAMEEduOAKqB9I73uw">
+ <position xmi:id="_03XZMQMEEduOAKqB9I73uw" x="187.0" y="-6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2QAAEQMEEduOAKqB9I73uw" guid="_2QAAEQMEEduOAKqB9I73uw" anchor="_2QAAEAMEEduOAKqB9I73uw _2QAAEgMEEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-h0qsQNkEduYd-55D-Aiqg" guid="_-h0qsQNkEduYd-55D-Aiqg" anchor="_-h0qsANkEduYd-55D-Aiqg _-h0qsgNkEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_2QAAEAMEEduOAKqB9I73uw" guid="_2QAAEAMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw">
+ <position xmi:id="_2QAAEwMEEduOAKqB9I73uw" x="58.0" y="51.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-h0qsANkEduYd-55D-Aiqg" guid="_-h0qsANkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
+ <position xmi:id="_-h6xUANkEduYd-55D-Aiqg" x="62.0" y="51.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_03XZMgMEEduOAKqB9I73uw" guid="_03XZMgMEEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_03XZMwMEEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8cZ2UANkEduYd-55D-Aiqg" guid="_8cZ2UANkEduYd-55D-Aiqg">
+ <position xmi:id="_8cZ2UQNkEduYd-55D-Aiqg" x="14.0" y="94.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LDfDwQPOEdubhrgDuRb4fA" guid="_LDfDwQPOEdubhrgDuRb4fA" anchor="_LDfDwAPOEdubhrgDuRb4fA _LDfDwgPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_4JEBIgPNEdubhrgDuRb4fA" guid="_4JEBIgPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LDfDwAPOEdubhrgDuRb4fA" guid="_LDfDwAPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LDfDwwPOEdubhrgDuRb4fA" x="114.0" y="145.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8cZ2UgNkEduYd-55D-Aiqg" guid="_8cZ2UgNkEduYd-55D-Aiqg" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_8cZ2UwNkEduYd-55D-Aiqg" width="168.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_n_DhAANnEduYd-55D-Aiqg" guid="_n_DhAANnEduYd-55D-Aiqg">
+ <position xmi:id="_n_DhAQNnEduYd-55D-Aiqg" x="255.0" y="90.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LgIjgQPOEdubhrgDuRb4fA" guid="_LgIjgQPOEdubhrgDuRb4fA" anchor="_LgIjgAPOEdubhrgDuRb4fA _LgIjggPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_114dkgPNEdubhrgDuRb4fA" guid="_114dkgPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LgIjgAPOEdubhrgDuRb4fA" guid="_LgIjgAPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LgIjgwPOEdubhrgDuRb4fA" x="282.0" y="140.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_n_DhAgNnEduYd-55D-Aiqg" guid="_n_DhAgNnEduYd-55D-Aiqg" element="_O6XmcANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_n_DhAwNnEduYd-55D-Aiqg" width="113.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nITO0APNEdubhrgDuRb4fA" guid="_nITO0APNEdubhrgDuRb4fA">
+ <position xmi:id="_nITO0QPNEdubhrgDuRb4fA" x="162.0" y="55.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_114dkQPNEdubhrgDuRb4fA" guid="_114dkQPNEdubhrgDuRb4fA" anchor="_114dkAPNEdubhrgDuRb4fA _114dkgPNEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_4JEBIQPNEdubhrgDuRb4fA" guid="_4JEBIQPNEdubhrgDuRb4fA" anchor="_4JEBIAPNEdubhrgDuRb4fA _4JEBIgPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-h0qsgNkEduYd-55D-Aiqg" guid="_-h0qsgNkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
+ <position xmi:id="_Ip2OIFGGEduRlKB2-_Ejlg" x="36.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_114dkAPNEdubhrgDuRb4fA" guid="_114dkAPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA">
+ <position xmi:id="_114dkwPNEdubhrgDuRb4fA" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_4JEBIAPNEdubhrgDuRb4fA" guid="_4JEBIAPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA">
+ <position xmi:id="_HPd_kAPOEdubhrgDuRb4fA" x="17.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nITO0gPNEdubhrgDuRb4fA" guid="_nITO0gPNEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nITO0wPNEdubhrgDuRb4fA" width="81.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_J5FtMAPOEdubhrgDuRb4fA" guid="_J5FtMAPOEdubhrgDuRb4fA">
+ <position xmi:id="_J5FtMQPOEdubhrgDuRb4fA" x="152.0" y="171.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MEDI4QPOEdubhrgDuRb4fA" guid="_MEDI4QPOEdubhrgDuRb4fA" anchor="_MEDI4APOEdubhrgDuRb4fA _MEDI4gPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LDfDwgPOEdubhrgDuRb4fA" guid="_LDfDwgPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LDfDxAPOEdubhrgDuRb4fA" x="42.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_LgIjggPOEdubhrgDuRb4fA" guid="_LgIjggPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LgIjhAPOEdubhrgDuRb4fA" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MEDI4APOEdubhrgDuRb4fA" guid="_MEDI4APOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA">
+ <position xmi:id="_MJgy8FGGEduRlKB2-_Ejlg" x="49.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_J5FtMgPOEdubhrgDuRb4fA" guid="_J5FtMgPOEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_J5FtMwPOEdubhrgDuRb4fA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mMXrMIGGEduKE9hnyImx1Q" guid="_mMXrMIGGEduKE9hnyImx1Q">
+ <position xmi:id="_mMXrMYGGEduKE9hnyImx1Q" x="190.0" y="282.0"/>
+ <anchorage xmi:id="_nqi5YoGGEduKE9hnyImx1Q" guid="_nqi5YoGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mMXrMoGGEduKE9hnyImx1Q" guid="_mMXrMoGGEduKE9hnyImx1Q" typeInfo="end node"/>
+ <size xmi:id="_mMXrM4GGEduKE9hnyImx1Q" width="24.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9sh0QMEEduOAKqB9I73uw" guid="_y9sh0QMEEduOAKqB9I73uw" presentation="Workflow" element="_37TdkAL_EduOAKqB9I73uw"/>
+ </diagrams>
+ <diagrams xmi:id="_jcymYAPNEdubhrgDuRb4fA" guid="_jcymYAPNEdubhrgDuRb4fA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymYQPNEdubhrgDuRb4fA" guid="_jcymYQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymYgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznBIGMEduKE9hnyImx1Q" guid="_5oznBIGMEduKE9hnyImx1Q" anchor="_5oznA4GMEduKE9hnyImx1Q _5oznBYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeNIGMEduKE9hnyImx1Q" guid="_5uBeNIGMEduKE9hnyImx1Q" anchor="_5uBeM4GMEduKE9hnyImx1Q _5uBeNYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQxLKjEdudsfcMCYa15A" guid="_03qQxLKjEdudsfcMCYa15A" anchor="_03qQw7KjEdudsfcMCYa15A _03qQxbKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_5oznAoGMEduKE9hnyImx1Q" guid="_5oznAoGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5oznA4GMEduKE9hnyImx1Q" guid="_5oznA4GMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeMoGMEduKE9hnyImx1Q" guid="_5uBeMoGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeM4GMEduKE9hnyImx1Q" guid="_5uBeM4GMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQwrKjEdudsfcMCYa15A" guid="_03qQwrKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_03qQw7KjEdudsfcMCYa15A" guid="_03qQw7KjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymYwPNEdubhrgDuRb4fA" guid="_jcymYwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymZAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymZQPNEdubhrgDuRb4fA" guid="_jcymZQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymZgPNEdubhrgDuRb4fA" x="30.0" y="88.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymZwPNEdubhrgDuRb4fA" guid="_jcymZwPNEdubhrgDuRb4fA" element="_zYaEsAMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymaAPNEdubhrgDuRb4fA" width="316.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymaQPNEdubhrgDuRb4fA" guid="_jcymaQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymagPNEdubhrgDuRb4fA" x="30.0" y="283.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymawPNEdubhrgDuRb4fA" guid="_jcymawPNEdubhrgDuRb4fA" element="_zYaEsgMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymbAPNEdubhrgDuRb4fA" width="239.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymbQPNEdubhrgDuRb4fA" guid="_jcymbQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymbgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymbwPNEdubhrgDuRb4fA" guid="_jcymbwPNEdubhrgDuRb4fA" element="_zYaEswMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymcAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymcQPNEdubhrgDuRb4fA" guid="_jcymcQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymcgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymcwPNEdubhrgDuRb4fA" guid="_jcymcwPNEdubhrgDuRb4fA" element="_zYaEtAMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymdAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymdQPNEdubhrgDuRb4fA" guid="_jcymdQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymdgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznB4GMEduKE9hnyImx1Q" guid="_5oznB4GMEduKE9hnyImx1Q" anchor="_5oznBoGMEduKE9hnyImx1Q _5oznCIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeN4GMEduKE9hnyImx1Q" guid="_5uBeN4GMEduKE9hnyImx1Q" anchor="_5uBeNoGMEduKE9hnyImx1Q _5uBeOIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQx7KjEdudsfcMCYa15A" guid="_03qQx7KjEdudsfcMCYa15A" anchor="_03qQxrKjEdudsfcMCYa15A _03qQyLKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_5oznBoGMEduKE9hnyImx1Q" guid="_5oznBoGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeNoGMEduKE9hnyImx1Q" guid="_5uBeNoGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQxrKjEdudsfcMCYa15A" guid="_03qQxrKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymdwPNEdubhrgDuRb4fA" guid="_jcymdwPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymeAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymeQPNEdubhrgDuRb4fA" guid="_jcymeQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymegPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymewPNEdubhrgDuRb4fA" guid="_jcymewPNEdubhrgDuRb4fA" element="_7FGsMQNkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymfAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymfQPNEdubhrgDuRb4fA" guid="_jcymfQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymfgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymfwPNEdubhrgDuRb4fA" guid="_jcymfwPNEdubhrgDuRb4fA" element="_O6XmcANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymgAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6QAPNEdubhrgDuRb4fA" guid="_jdE6QAPNEdubhrgDuRb4fA">
+ <property xmi:id="_jdE6QQPNEdubhrgDuRb4fA" guid="_jdE6QQPNEdubhrgDuRb4fA" key="wpCompositeType" value="1"/>
+ <position xmi:id="_jdE6QgPNEdubhrgDuRb4fA" x="127.0" y="1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_jdRHgQPNEdubhrgDuRb4fA" guid="_jdRHgQPNEdubhrgDuRb4fA" anchor="_jdRHgAPNEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8P1cgRTUEduFIr9xNbwGyQ" guid="_8P1cgRTUEduFIr9xNbwGyQ" anchor="_8P1cgBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznAYGMEduKE9hnyImx1Q" guid="_5oznAYGMEduKE9hnyImx1Q" anchor="_5oznAIGMEduKE9hnyImx1Q _5oznAoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeMYGMEduKE9hnyImx1Q" guid="_5uBeMYGMEduKE9hnyImx1Q" anchor="_5uBeMIGMEduKE9hnyImx1Q _5uBeMoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQwbKjEdudsfcMCYa15A" guid="_03qQwbKjEdudsfcMCYa15A" anchor="_03qQwLKjEdudsfcMCYa15A _03qQwrKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_jdRHgAPNEdubhrgDuRb4fA" guid="_jdRHgAPNEdubhrgDuRb4fA" graphEdge="_jdRHgQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cgBTUEduFIr9xNbwGyQ" guid="_8P1cgBTUEduFIr9xNbwGyQ" graphEdge="_8P1cgRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznAIGMEduKE9hnyImx1Q" guid="_5oznAIGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeMIGMEduKE9hnyImx1Q" guid="_5uBeMIGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQwLKjEdudsfcMCYa15A" guid="_03qQwLKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6QwPNEdubhrgDuRb4fA" guid="_jdE6QwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jdE6RAPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6RQPNEdubhrgDuRb4fA" guid="_jdE6RQPNEdubhrgDuRb4fA">
+ <property xmi:id="_jdE6RgPNEdubhrgDuRb4fA" guid="_jdE6RgPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
+ <position xmi:id="_jdE6RwPNEdubhrgDuRb4fA" x="127.0" y="175.0"/>
+ <anchorage xmi:id="_jdRHggPNEdubhrgDuRb4fA" guid="_jdRHggPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cghTUEduFIr9xNbwGyQ" guid="_8P1cghTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznBYGMEduKE9hnyImx1Q" guid="_5oznBYGMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeNYGMEduKE9hnyImx1Q" guid="_5uBeNYGMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQxbKjEdudsfcMCYa15A" guid="_03qQxbKjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6SAPNEdubhrgDuRb4fA" guid="_jdE6SAPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jdE6SQPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdLA4APNEdubhrgDuRb4fA" guid="_jdLA4APNEdubhrgDuRb4fA">
+ <property xmi:id="_jdLA4QPNEdubhrgDuRb4fA" guid="_jdLA4QPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
+ <position xmi:id="_jdLA4gPNEdubhrgDuRb4fA" x="220.0" y="175.0"/>
+ <anchorage xmi:id="_jdRHgwPNEdubhrgDuRb4fA" guid="_jdRHgwPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cgxTUEduFIr9xNbwGyQ" guid="_8P1cgxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznCIGMEduKE9hnyImx1Q" guid="_5oznCIGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeOIGMEduKE9hnyImx1Q" guid="_5uBeOIGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQyLKjEdudsfcMCYa15A" guid="_03qQyLKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdLA4wPNEdubhrgDuRb4fA" guid="_jdLA4wPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jdLA5APNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymgQPNEdubhrgDuRb4fA" guid="_jcymgQPNEdubhrgDuRb4fA" presentation="Activity Detail" element="_37TdkAL_EduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_NSW6sAMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sAMAEduOAKqB9I73uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_SoXWEAMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEAMAEduOAKqB9I73uw">
+ <processElements xsi:type="org.eclipse.epf.uma:Iteration" xmi:id="_SoXWEQMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEQMAEduOAKqB9I73uw" briefDescription="Déroulement d'un sprint (itération)" presentationName="Sprint" isPlanned="false" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" breakdownElements="_glbG0AMAEduOAKqB9I73uw _glbG0QMAEduOAKqB9I73uw _glbG0wMAEduOAKqB9I73uw _glbG1AMAEduOAKqB9I73uw _glbG1QMAEduOAKqB9I73uw _glbG1gMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw _glbG2wMAEduOAKqB9I73uw _glbG3AMAEduOAKqB9I73uw _glbG3QMAEduOAKqB9I73uw _nXmKUANlEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0AMAEduOAKqB9I73uw" name="Manage problems" guid="_glbG0AMAEduOAKqB9I73uw" presentationName="Gérer les problèmes" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" optionalInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Xpd5gP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_LCxqQAB6EduSVaTQTBfIHA"/>
+ <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_PIKyUAB6EduSVaTQTBfIHA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0QMAEduOAKqB9I73uw" name="Update product backlog" guid="_glbG0QMAEduOAKqB9I73uw" presentationName="Mettre à jour le backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" additionallyPerformedBy="_glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2AMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_STkWYP_BEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_c3HaQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_fkXDoAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_k-kCgAPKEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0wMAEduOAKqB9I73uw" name="Plan sprint" guid="_glbG0wMAEduOAKqB9I73uw" presentationName="Planifier le sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_4LOggPpaEdqsc-f87sBK8A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_TJNsUP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_p4C0sP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_worbAP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_xvy5UAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_DxNQUAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_Iq14wAPLEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1AMAEduOAKqB9I73uw" name="Retrospective" guid="_glbG1AMAEduOAKqB9I73uw" presentationName="Rétrospective" superActivities="_SoXWEQMAEduOAKqB9I73uw" linkToPredecessor="_O0710AMCEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_J_sRIP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_lwzeABGPEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_noL2YBGPEduHloEV5-Zv-w"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1QMAEduOAKqB9I73uw" name="Review sprint" guid="_glbG1QMAEduOAKqB9I73uw" presentationName="Faire la revue du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" isEventDriven="true" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" mandatoryInput="_glbG3QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_MRrRYPpbEdqsc-f87sBK8A"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_XL6VgAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_ZgJB8APLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_cBouUAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_hrswoHoYEduJVrY6eKG_mw"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_d776UHoYEduJVrY6eKG_mw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1gMAEduOAKqB9I73uw" name="Scrum daily meeting" guid="_glbG1gMAEduOAKqB9I73uw" presentationName="Mêlée quotidienne" superActivities="_SoXWEQMAEduOAKqB9I73uw" isRepeatable="true" isEventDriven="true" linkToPredecessor="_34UPdAzNEduDObTFE5q79g _34UPdQzNEduDObTFE5q79g _34UPdgzNEduDObTFE5q79g" additionallyPerformedBy="_glbG2gMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_d09LYP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_oUrlcBGOEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_r0KkEBGOEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_vZkkgBGOEduHloEV5-Zv-w"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG1wMAEduOAKqB9I73uw" name="ScrumMaster" guid="_glbG1wMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG2wMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2AMAEduOAKqB9I73uw" name="Product Owner" guid="_glbG2AMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG3AMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2QMAEduOAKqB9I73uw" name="StakeHolder" guid="_glbG2QMAEduOAKqB9I73uw" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2gMAEduOAKqB9I73uw" name="Team" guid="_glbG2gMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG2wMAEduOAKqB9I73uw" name="Sprint backlog" guid="_glbG2wMAEduOAKqB9I73uw" presentationName="Backlog du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <presentation xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-MupkaQeHNEmiF7Lnl3VirQ"/>
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Dzw70PpZEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3AMAEduOAKqB9I73uw" name="Product Backlog" guid="_glbG3AMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" activityEntryState="courant" activityExitState="mis à jour">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3QMAEduOAKqB9I73uw" name="Product" guid="_glbG3QMAEduOAKqB9I73uw" presentationName="Incrément de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_O0710AMCEduOAKqB9I73uw" guid="_O0710AMCEduOAKqB9I73uw" linkType="finishToFinish" pred="_glbG1QMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_nXmKUANlEduYd-55D-Aiqg" name="Daily work" guid="_nXmKUANlEduYd-55D-Aiqg" briefDescription="L'équipe réalise les taches du backlog pour arriver au but du sprint" presentationName="Travaux quotidiens" isPlanned="true" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG3QMAEduOAKqB9I73uw">
+ <presentation xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" href="uma://-16dzhVoCex78V2iCDZVx0w#-EpBaHVCIYCqqGX_wv7dlYA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdAzNEduDObTFE5q79g" guid="_34UPdAzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0QMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdQzNEduDObTFE5q79g" guid="_34UPdQzNEduDObTFE5q79g" linkType="finishToFinish" pred="_nXmKUANlEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdgzNEduDObTFE5q79g" guid="_34UPdgzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0AMAEduOAKqB9I73uw"/>
+ <diagrams xmi:id="_2vZZMAMBEduOAKqB9I73uw" guid="_2vZZMAMBEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vZZMQMBEduOAKqB9I73uw" guid="_2vZZMQMBEduOAKqB9I73uw">
+ <position xmi:id="_2vZZMgMBEduOAKqB9I73uw" x="199.0" y="174.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LnUDQQMCEduOAKqB9I73uw" guid="_LnUDQQMCEduOAKqB9I73uw" anchor="_LnUDQAMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_LSlwcgMCEduOAKqB9I73uw" guid="_LSlwcgMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_LnUDQAMCEduOAKqB9I73uw" guid="_LnUDQAMCEduOAKqB9I73uw" graphEdge="_LnUDQQMCEduOAKqB9I73uw">
+ <position xmi:id="_LnUDQwMCEduOAKqB9I73uw" x="316.0" y="187.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZMwMBEduOAKqB9I73uw" guid="_2vZZMwMBEduOAKqB9I73uw"/>
+ <size xmi:id="_2vZZNAMBEduOAKqB9I73uw" width="143.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff0AMBEduOAKqB9I73uw" guid="_2vff0AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff0QMBEduOAKqB9I73uw" x="322.0" y="134.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_swPHwQzNEduDObTFE5q79g" guid="_swPHwQzNEduDObTFE5q79g" anchor="_swPHwAzNEduDObTFE5q79g _swPHwgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_L-ChMgMCEduOAKqB9I73uw" guid="_L-ChMgMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_swPHwAzNEduDObTFE5q79g" guid="_swPHwAzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
+ <position xmi:id="_swPHwwzNEduDObTFE5q79g" x="394.0" y="241.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff0gMBEduOAKqB9I73uw" guid="_2vff0gMBEduOAKqB9I73uw" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff0wMBEduOAKqB9I73uw" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff1AMBEduOAKqB9I73uw" guid="_2vff1AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff1QMBEduOAKqB9I73uw" x="19.0" y="127.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_r27hMQzNEduDObTFE5q79g" guid="_r27hMQzNEduDObTFE5q79g" anchor="_r27hMAzNEduDObTFE5q79g _r27hMgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_KNcGQgMCEduOAKqB9I73uw" guid="_KNcGQgMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_r27hMAzNEduDObTFE5q79g" guid="_r27hMAzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
+ <position xmi:id="_r27hMwzNEduDObTFE5q79g" x="123.0" y="239.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff1gMBEduOAKqB9I73uw" guid="_2vff1gMBEduOAKqB9I73uw" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff1wMBEduOAKqB9I73uw" width="130.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff2AMBEduOAKqB9I73uw" guid="_2vff2AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff2QMBEduOAKqB9I73uw" x="76.0" y="269.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff2gMBEduOAKqB9I73uw" guid="_2vff2gMBEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff2wMBEduOAKqB9I73uw" width="88.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff3AMBEduOAKqB9I73uw" guid="_2vff3AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff3QMBEduOAKqB9I73uw" x="190.0" y="3.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-mYC4QzNEduDObTFE5q79g" guid="_-mYC4QzNEduDObTFE5q79g" anchor="_-mYC4AzNEduDObTFE5q79g _-mYC4gzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_I2DckgMCEduOAKqB9I73uw" guid="_I2DckgMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_-mYC4AzNEduDObTFE5q79g" guid="_-mYC4AzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
+ <position xmi:id="_-mYC4wzNEduDObTFE5q79g" x="264.0" y="88.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff3gMBEduOAKqB9I73uw" guid="_2vff3gMBEduOAKqB9I73uw" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff3wMBEduOAKqB9I73uw" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff4AMBEduOAKqB9I73uw" guid="_2vff4AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff4QMBEduOAKqB9I73uw" x="346.0" y="332.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_PENn8QMCEduOAKqB9I73uw" guid="_PENn8QMCEduOAKqB9I73uw" anchor="_PENn8AMCEduOAKqB9I73uw _PENn8gMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_O0vokgMCEduOAKqB9I73uw" guid="_O0vokgMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_PENn8AMCEduOAKqB9I73uw" guid="_PENn8AMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw">
+ <position xmi:id="_PENn8wMCEduOAKqB9I73uw" x="327.0" y="377.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff4gMBEduOAKqB9I73uw" guid="_2vff4gMBEduOAKqB9I73uw" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff4wMBEduOAKqB9I73uw" width="67.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff5AMBEduOAKqB9I73uw" guid="_2vff5AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff5QMBEduOAKqB9I73uw" x="175.0" y="332.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O0vokQMCEduOAKqB9I73uw" guid="_O0vokQMCEduOAKqB9I73uw" anchor="_O0vokAMCEduOAKqB9I73uw _O0vokgMCEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O0710QMCEduOAKqB9I73uw" guid="_O0710QMCEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_Ok5OsgMCEduOAKqB9I73uw" guid="_Ok5OsgMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_O0vokAMCEduOAKqB9I73uw" guid="_O0vokAMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw">
+ <position xmi:id="_O0vokwMCEduOAKqB9I73uw" x="324.0" y="328.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff5gMBEduOAKqB9I73uw" guid="_2vff5gMBEduOAKqB9I73uw" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff5wMBEduOAKqB9I73uw" width="111.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff6AMBEduOAKqB9I73uw" guid="_2vff6AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff6QMBEduOAKqB9I73uw" x="187.0" y="217.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_63CqYQzNEduDObTFE5q79g" guid="_63CqYQzNEduDObTFE5q79g" anchor="_63CqYAzNEduDObTFE5q79g _63CqYgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_34UPcgzNEduDObTFE5q79g" guid="_34UPcgzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_63CqYAzNEduDObTFE5q79g" guid="_63CqYAzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
+ <position xmi:id="_63CqYwzNEduDObTFE5q79g" x="268.0" y="326.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff6gMBEduOAKqB9I73uw" guid="_2vff6gMBEduOAKqB9I73uw" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff6wMBEduOAKqB9I73uw" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DtnjIAMCEduOAKqB9I73uw" guid="_DtnjIAMCEduOAKqB9I73uw">
+ <position xmi:id="_DtnjIQMCEduOAKqB9I73uw" x="9.0" y="15.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_I2DckQMCEduOAKqB9I73uw" guid="_I2DckQMCEduOAKqB9I73uw" anchor="_I2DckAMCEduOAKqB9I73uw _I2DckgMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_I2DckAMCEduOAKqB9I73uw" guid="_I2DckAMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw">
+ <position xmi:id="_I2DckwMCEduOAKqB9I73uw" x="318.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DtnjIgMCEduOAKqB9I73uw" guid="_DtnjIgMCEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_DtnjIwMCEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_EQ85sAMCEduOAKqB9I73uw" guid="_EQ85sAMCEduOAKqB9I73uw">
+ <position xmi:id="_EQ85sQMCEduOAKqB9I73uw" x="531.0" y="342.0"/>
+ <anchorage xmi:id="_PENn8gMCEduOAKqB9I73uw" guid="_PENn8gMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_EQ85sgMCEduOAKqB9I73uw" guid="_EQ85sgMCEduOAKqB9I73uw" typeInfo="end node"/>
+ <size xmi:id="_EQ85swMCEduOAKqB9I73uw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_FLsDoAMCEduOAKqB9I73uw" guid="_FLsDoAMCEduOAKqB9I73uw">
+ <position xmi:id="_FLsDoQMCEduOAKqB9I73uw" x="206.0" y="274.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ok5OsQMCEduOAKqB9I73uw" guid="_Ok5OsQMCEduOAKqB9I73uw" anchor="_Ok5OsAMCEduOAKqB9I73uw _Ok5OsgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ADBAAQzOEduDObTFE5q79g" guid="_ADBAAQzOEduDObTFE5q79g" anchor="_ADBAAAzOEduDObTFE5q79g _ADBAAgzOEduDObTFE5q79g">
+ <waypoints xmi:id="_0PYkcAzOEduDObTFE5q79g" x="491.0" y="285.0"/>
+ <waypoints xmi:id="_0PYkcQzOEduDObTFE5q79g" x="492.0" y="76.0"/>
+ </contained>
+ <anchorage xmi:id="_Ok5OsAMCEduOAKqB9I73uw" guid="_Ok5OsAMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw">
+ <position xmi:id="_cyxCoAMCEduOAKqB9I73uw" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_63CqYgzNEduDObTFE5q79g" guid="_63CqYgzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
+ <position xmi:id="_63CqZAzNEduDObTFE5q79g" x="23.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ADBAAAzOEduDObTFE5q79g" guid="_ADBAAAzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
+ <position xmi:id="_ADBAAwzOEduDObTFE5q79g" x="47.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_FLsDogMCEduOAKqB9I73uw" guid="_FLsDogMCEduOAKqB9I73uw" typeInfo="decision node"/>
+ <size xmi:id="_FLsDowMCEduOAKqB9I73uw" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HEmGAAMCEduOAKqB9I73uw" guid="_HEmGAAMCEduOAKqB9I73uw">
+ <position xmi:id="_HEmGAQMCEduOAKqB9I73uw" x="180.0" y="106.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KNcGQQMCEduOAKqB9I73uw" guid="_KNcGQQMCEduOAKqB9I73uw" anchor="_KNcGQAMCEduOAKqB9I73uw _KNcGQgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LSlwcQMCEduOAKqB9I73uw" guid="_LSlwcQMCEduOAKqB9I73uw" anchor="_LSlwcAMCEduOAKqB9I73uw _LSlwcgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_L-ChMQMCEduOAKqB9I73uw" guid="_L-ChMQMCEduOAKqB9I73uw" anchor="_L-ChMAMCEduOAKqB9I73uw _L-ChMgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_haut0QNmEduYd-55D-Aiqg" guid="_haut0QNmEduYd-55D-Aiqg" anchor="_haut0ANmEduYd-55D-Aiqg _haut0gNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_KNcGQAMCEduOAKqB9I73uw" guid="_KNcGQAMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw">
+ <position xmi:id="_KNcGQwMCEduOAKqB9I73uw" x="47.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_LSlwcAMCEduOAKqB9I73uw" guid="_LSlwcAMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw">
+ <position xmi:id="_LSlwcwMCEduOAKqB9I73uw" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_L-ChMAMCEduOAKqB9I73uw" guid="_L-ChMAMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw">
+ <position xmi:id="_L-In0AMCEduOAKqB9I73uw" x="50.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_haut0ANmEduYd-55D-Aiqg" guid="_haut0ANmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg">
+ <position xmi:id="_8NQZYIGPEduKE9hnyImx1Q" x="50.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="__S4jkgzNEduDObTFE5q79g" guid="__S4jkgzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
+ <position xmi:id="__S4jlAzNEduDObTFE5q79g" x="46.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_HEmGAgMCEduOAKqB9I73uw" guid="_HEmGAgMCEduOAKqB9I73uw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_HEmGAwMCEduOAKqB9I73uw" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_XP3cUANmEduYd-55D-Aiqg" guid="_XP3cUANmEduYd-55D-Aiqg">
+ <position xmi:id="_XP3cUQNmEduYd-55D-Aiqg" x="184.0" y="134.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_sOOm4QzNEduDObTFE5q79g" guid="_sOOm4QzNEduDObTFE5q79g" anchor="_sOOm4AzNEduDObTFE5q79g _sOOm4gzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_haut0gNmEduYd-55D-Aiqg" guid="_haut0gNmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_sOOm4AzNEduDObTFE5q79g" guid="_sOOm4AzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
+ <position xmi:id="_sOOm4wzNEduDObTFE5q79g" x="263.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_XP3cUgNmEduYd-55D-Aiqg" guid="_XP3cUgNmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_XP3cUwNmEduYd-55D-Aiqg" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4Fi44ANmEduYd-55D-Aiqg" name="Add Free Text" guid="_4Fi44ANmEduYd-55D-Aiqg">
+ <property xmi:id="_4Fi44QNmEduYd-55D-Aiqg" guid="_4Fi44QNmEduYd-55D-Aiqg" key="free text" value="date de fin de sprint atteinte"/>
+ <position xmi:id="_4Fi44gNmEduYd-55D-Aiqg" x="154.0" y="297.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_4Fi44wNmEduYd-55D-Aiqg" guid="_4Fi44wNmEduYd-55D-Aiqg" typeInfo="free text"/>
+ <size xmi:id="_4Fi45ANmEduYd-55D-Aiqg" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_S90SkAzNEduDObTFE5q79g" guid="_S90SkAzNEduDObTFE5q79g">
+ <position xmi:id="_S90SkQzNEduDObTFE5q79g" x="206.0" y="66.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__S4jkQzNEduDObTFE5q79g" guid="__S4jkQzNEduDObTFE5q79g" anchor="__S4jkAzNEduDObTFE5q79g __S4jkgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_-mYC4gzNEduDObTFE5q79g" guid="_-mYC4gzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
+ <position xmi:id="_-mYC5AzNEduDObTFE5q79g" x="23.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__S4jkAzNEduDObTFE5q79g" guid="__S4jkAzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
+ <position xmi:id="__S4jkwzNEduDObTFE5q79g" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ADBAAgzOEduDObTFE5q79g" guid="_ADBAAgzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
+ <position xmi:id="_ADBABAzOEduDObTFE5q79g" x="47.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_S90SkgzNEduDObTFE5q79g" guid="_S90SkgzNEduDObTFE5q79g" typeInfo="decision node"/>
+ <size xmi:id="_S90SkwzNEduDObTFE5q79g" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_qmzWEAzNEduDObTFE5q79g" guid="_qmzWEAzNEduDObTFE5q79g">
+ <position xmi:id="_qmzWEQzNEduDObTFE5q79g" x="180.0" y="198.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_34UPcQzNEduDObTFE5q79g" guid="_34UPcQzNEduDObTFE5q79g" anchor="_34UPcAzNEduDObTFE5q79g _34UPcgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_r27hMgzNEduDObTFE5q79g" guid="_r27hMgzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
+ <position xmi:id="_r27hNAzNEduDObTFE5q79g" x="38.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_sOOm4gzNEduDObTFE5q79g" guid="_sOOm4gzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
+ <position xmi:id="_8NQZYYGPEduKE9hnyImx1Q" x="50.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_swPHwgzNEduDObTFE5q79g" guid="_swPHwgzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
+ <position xmi:id="_swPHxAzNEduDObTFE5q79g" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_34UPcAzNEduDObTFE5q79g" guid="_34UPcAzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g">
+ <position xmi:id="_34UPcwzNEduDObTFE5q79g" x="44.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_qmzWEgzNEduDObTFE5q79g" guid="_qmzWEgzNEduDObTFE5q79g" typeInfo="synchnonization bar"/>
+ <size xmi:id="_qmzWEwzNEduDObTFE5q79g" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_f5j60AzOEduDObTFE5q79g" name="Add Free Text" guid="_f5j60AzOEduDObTFE5q79g">
+ <property xmi:id="_f5j60QzOEduDObTFE5q79g" guid="_f5j60QzOEduDObTFE5q79g" key="free text" value="encore des jours dans le sprint"/>
+ <position xmi:id="_f5j60gzOEduDObTFE5q79g" x="289.0" y="266.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_f5j60wzOEduDObTFE5q79g" guid="_f5j60wzOEduDObTFE5q79g" typeInfo="free text"/>
+ <size xmi:id="_f5j61AzOEduDObTFE5q79g" width="165.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZNQMBEduOAKqB9I73uw" guid="_2vZZNQMBEduOAKqB9I73uw" presentation="Workflow" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ <diagrams xmi:id="_O8kwcANmEduYd-55D-Aiqg" guid="_O8kwcANmEduYd-55D-Aiqg">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwcQNmEduYd-55D-Aiqg" guid="_O8kwcQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwcgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RsYGMEduKE9hnyImx1Q" guid="_5q5RsYGMEduKE9hnyImx1Q" anchor="_5q5RsIGMEduKE9hnyImx1Q _5q5RsoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeEYGMEduKE9hnyImx1Q" guid="_51BeEYGMEduKE9hnyImx1Q" anchor="_51BeEIGMEduKE9hnyImx1Q _51BeEoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RsIGMEduKE9hnyImx1Q" guid="_5q5RsIGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeEIGMEduKE9hnyImx1Q" guid="_51BeEIGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwcwNmEduYd-55D-Aiqg" guid="_O8kwcwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kwdANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwdQNmEduYd-55D-Aiqg" guid="_O8kwdQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwdgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rt4GMEduKE9hnyImx1Q" guid="_5q5Rt4GMEduKE9hnyImx1Q" anchor="_5q5RtoGMEduKE9hnyImx1Q _5q5RuIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeF4GMEduKE9hnyImx1Q" guid="_51BeF4GMEduKE9hnyImx1Q" anchor="_51BeFoGMEduKE9hnyImx1Q _51BeGIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RtYGMEduKE9hnyImx1Q" guid="_5q5RtYGMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RtoGMEduKE9hnyImx1Q" guid="_5q5RtoGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeFYGMEduKE9hnyImx1Q" guid="_51BeFYGMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeFoGMEduKE9hnyImx1Q" guid="_51BeFoGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwdwNmEduYd-55D-Aiqg" guid="_O8kwdwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kweANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kweQNmEduYd-55D-Aiqg" guid="_O8kweQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwegNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RvYGMEduKE9hnyImx1Q" guid="_5q5RvYGMEduKE9hnyImx1Q" anchor="_5q5RvIGMEduKE9hnyImx1Q _5q5RvoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeHYGMEduKE9hnyImx1Q" guid="_51BeHYGMEduKE9hnyImx1Q" anchor="_51BeHIGMEduKE9hnyImx1Q _51BeHoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Ru4GMEduKE9hnyImx1Q" guid="_5q5Ru4GMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RvIGMEduKE9hnyImx1Q" guid="_5q5RvIGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeG4GMEduKE9hnyImx1Q" guid="_51BeG4GMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeHIGMEduKE9hnyImx1Q" guid="_51BeHIGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwewNmEduYd-55D-Aiqg" guid="_O8kwewNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kwfANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwfQNmEduYd-55D-Aiqg" guid="_O8kwfQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwfgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RwIGMEduKE9hnyImx1Q" guid="_5q5RwIGMEduKE9hnyImx1Q" anchor="_5q5Rv4GMEduKE9hnyImx1Q _5q5RwYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeIIGMEduKE9hnyImx1Q" guid="_51BeIIGMEduKE9hnyImx1Q" anchor="_51BeH4GMEduKE9hnyImx1Q _51BeIYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Rv4GMEduKE9hnyImx1Q" guid="_5q5Rv4GMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeH4GMEduKE9hnyImx1Q" guid="_51BeH4GMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3EANmEduYd-55D-Aiqg" guid="_O8q3EANmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3EQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3EgNmEduYd-55D-Aiqg" guid="_O8q3EgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3EwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RxoGMEduKE9hnyImx1Q" guid="_5q5RxoGMEduKE9hnyImx1Q" anchor="_5q5RxYGMEduKE9hnyImx1Q _5q5Rx4GMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeJoGMEduKE9hnyImx1Q" guid="_51BeJoGMEduKE9hnyImx1Q" anchor="_51BeJYGMEduKE9hnyImx1Q _51BeJ4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RxIGMEduKE9hnyImx1Q" guid="_5q5RxIGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RxYGMEduKE9hnyImx1Q" guid="_5q5RxYGMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJIGMEduKE9hnyImx1Q" guid="_51BeJIGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJYGMEduKE9hnyImx1Q" guid="_51BeJYGMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3FANmEduYd-55D-Aiqg" guid="_O8q3FANmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3FQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3FgNmEduYd-55D-Aiqg" guid="_O8q3FgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3FwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RzIGMEduKE9hnyImx1Q" guid="_5q5RzIGMEduKE9hnyImx1Q" anchor="_5q5Ry4GMEduKE9hnyImx1Q _5q5RzYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeLIGMEduKE9hnyImx1Q" guid="_51BeLIGMEduKE9hnyImx1Q" anchor="_51BeK4GMEduKE9hnyImx1Q _51BeLYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RyoGMEduKE9hnyImx1Q" guid="_5q5RyoGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Ry4GMEduKE9hnyImx1Q" guid="_5q5Ry4GMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeKoGMEduKE9hnyImx1Q" guid="_51BeKoGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeK4GMEduKE9hnyImx1Q" guid="_51BeK4GMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3GANmEduYd-55D-Aiqg" guid="_O8q3GANmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3GQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3GgNmEduYd-55D-Aiqg" guid="_O8q3GgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3GwNmEduYd-55D-Aiqg" x="30.0" y="88.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3HANmEduYd-55D-Aiqg" guid="_O8q3HANmEduYd-55D-Aiqg" element="_glbG1wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3HQNmEduYd-55D-Aiqg" width="338.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3HgNmEduYd-55D-Aiqg" guid="_O8q3HgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3HwNmEduYd-55D-Aiqg" x="30.0" y="356.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3IANmEduYd-55D-Aiqg" guid="_O8q3IANmEduYd-55D-Aiqg" element="_glbG2AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3IQNmEduYd-55D-Aiqg" width="222.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3IgNmEduYd-55D-Aiqg" guid="_O8q3IgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3IwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3JANmEduYd-55D-Aiqg" guid="_O8q3JANmEduYd-55D-Aiqg" element="_glbG2QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3JQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3JgNmEduYd-55D-Aiqg" guid="_O8q3JgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3JwNmEduYd-55D-Aiqg" x="30.0" y="638.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3KANmEduYd-55D-Aiqg" guid="_O8q3KANmEduYd-55D-Aiqg" element="_glbG2gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3KQNmEduYd-55D-Aiqg" width="374.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3KgNmEduYd-55D-Aiqg" guid="_O8q3KgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3KwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3LANmEduYd-55D-Aiqg" guid="_O8q3LANmEduYd-55D-Aiqg" element="_glbG2wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3LQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3LgNmEduYd-55D-Aiqg" guid="_O8q3LgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3LwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3MANmEduYd-55D-Aiqg" guid="_O8q3MANmEduYd-55D-Aiqg" element="_glbG3AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3MQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3MgNmEduYd-55D-Aiqg" guid="_O8q3MgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3MwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3NANmEduYd-55D-Aiqg" guid="_O8q3NANmEduYd-55D-Aiqg" element="_glbG3QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3NQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3NgNmEduYd-55D-Aiqg" guid="_O8q3NgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3NwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OANmEduYd-55D-Aiqg" guid="_O8q3OANmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_O8q3OQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9bsEANmEduYd-55D-Aiqg" guid="_O9bsEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O9bsEQNmEduYd-55D-Aiqg" guid="_O9bsEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O9bsEgNmEduYd-55D-Aiqg" x="137.0" y="161.0"/>
+ <anchorage xmi:id="_O-9WFQNmEduYd-55D-Aiqg" guid="_O-9WFQNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVsANnEduYd-55D-Aiqg" guid="_oHjVsANnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMAO8EdubhrgDuRb4fA" guid="_D6EPMAO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMAPMEdubhrgDuRb4fA" guid="_-EfTMAPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcBTUEduFIr9xNbwGyQ" guid="_8ZSTcBTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RsoGMEduKE9hnyImx1Q" guid="_5q5RsoGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeEoGMEduKE9hnyImx1Q" guid="_51BeEoGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9bsEwNmEduYd-55D-Aiqg" guid="_O9bsEwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O9bsFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9t_8ANmEduYd-55D-Aiqg" guid="_O9t_8ANmEduYd-55D-Aiqg">
+ <property xmi:id="_O9t_8QNmEduYd-55D-Aiqg" guid="_O9t_8QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O9t_8gNmEduYd-55D-Aiqg" x="142.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WFwNmEduYd-55D-Aiqg" guid="_O-9WFwNmEduYd-55D-Aiqg" anchor="_O-9WFgNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVsgNnEduYd-55D-Aiqg" guid="_oHjVsgNnEduYd-55D-Aiqg" anchor="_oHjVsQNnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPMgO8EdubhrgDuRb4fA" guid="_D6EPMgO8EdubhrgDuRb4fA" anchor="_D6EPMQO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTMgPMEdubhrgDuRb4fA" guid="_-EfTMgPMEdubhrgDuRb4fA" anchor="_-EfTMQPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTchTUEduFIr9xNbwGyQ" guid="_8ZSTchTUEduFIr9xNbwGyQ" anchor="_8ZSTcRTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RtIGMEduKE9hnyImx1Q" guid="_5q5RtIGMEduKE9hnyImx1Q" anchor="_5q5Rs4GMEduKE9hnyImx1Q _5q5RtYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeFIGMEduKE9hnyImx1Q" guid="_51BeFIGMEduKE9hnyImx1Q" anchor="_51BeE4GMEduKE9hnyImx1Q _51BeFYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WFgNmEduYd-55D-Aiqg" guid="_O-9WFgNmEduYd-55D-Aiqg" graphEdge="_O-9WFwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVsQNnEduYd-55D-Aiqg" guid="_oHjVsQNnEduYd-55D-Aiqg" graphEdge="_oHjVsgNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMQO8EdubhrgDuRb4fA" guid="_D6EPMQO8EdubhrgDuRb4fA" graphEdge="_D6EPMgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMQPMEdubhrgDuRb4fA" guid="_-EfTMQPMEdubhrgDuRb4fA" graphEdge="_-EfTMgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcRTUEduFIr9xNbwGyQ" guid="_8ZSTcRTUEduFIr9xNbwGyQ" graphEdge="_8ZSTchTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5Rs4GMEduKE9hnyImx1Q" guid="_5q5Rs4GMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeE4GMEduKE9hnyImx1Q" guid="_51BeE4GMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9t_8wNmEduYd-55D-Aiqg" guid="_O9t_8wNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O9t_9ANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O96NMANmEduYd-55D-Aiqg" guid="_O96NMANmEduYd-55D-Aiqg">
+ <property xmi:id="_O96NMQNmEduYd-55D-Aiqg" guid="_O96NMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O96NMgNmEduYd-55D-Aiqg" x="142.0" y="443.0"/>
+ <anchorage xmi:id="_O-9WGANmEduYd-55D-Aiqg" guid="_O-9WGANmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVswNnEduYd-55D-Aiqg" guid="_oHjVswNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMwO8EdubhrgDuRb4fA" guid="_D6EPMwO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMwPMEdubhrgDuRb4fA" guid="_-EfTMwPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcxTUEduFIr9xNbwGyQ" guid="_8ZSTcxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RuIGMEduKE9hnyImx1Q" guid="_5q5RuIGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeGIGMEduKE9hnyImx1Q" guid="_51BeGIGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O96NMwNmEduYd-55D-Aiqg" guid="_O96NMwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O96NNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-GacANmEduYd-55D-Aiqg" guid="_O-GacANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-GacQNmEduYd-55D-Aiqg" guid="_O-GacQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-GacgNmEduYd-55D-Aiqg" x="289.0" y="551.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WGgNmEduYd-55D-Aiqg" guid="_O-9WGgNmEduYd-55D-Aiqg" anchor="_O-9WGQNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVtQNnEduYd-55D-Aiqg" guid="_oHjVtQNnEduYd-55D-Aiqg" anchor="_oHjVtANnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPNQO8EdubhrgDuRb4fA" guid="_D6EPNQO8EdubhrgDuRb4fA" anchor="_D6EPNAO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTNQPMEdubhrgDuRb4fA" guid="_-EfTNQPMEdubhrgDuRb4fA" anchor="_-EfTNAPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTdRTUEduFIr9xNbwGyQ" guid="_8ZSTdRTUEduFIr9xNbwGyQ" anchor="_8ZSTdBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RuoGMEduKE9hnyImx1Q" guid="_5q5RuoGMEduKE9hnyImx1Q" anchor="_5q5RuYGMEduKE9hnyImx1Q _5q5Ru4GMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeGoGMEduKE9hnyImx1Q" guid="_51BeGoGMEduKE9hnyImx1Q" anchor="_51BeGYGMEduKE9hnyImx1Q _51BeG4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WGQNmEduYd-55D-Aiqg" guid="_O-9WGQNmEduYd-55D-Aiqg" graphEdge="_O-9WGgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtANnEduYd-55D-Aiqg" guid="_oHjVtANnEduYd-55D-Aiqg" graphEdge="_oHjVtQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNAO8EdubhrgDuRb4fA" guid="_D6EPNAO8EdubhrgDuRb4fA" graphEdge="_D6EPNQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNAPMEdubhrgDuRb4fA" guid="_-EfTNAPMEdubhrgDuRb4fA" graphEdge="_-EfTNQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdBTUEduFIr9xNbwGyQ" guid="_8ZSTdBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTdRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RuYGMEduKE9hnyImx1Q" guid="_5q5RuYGMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeGYGMEduKE9hnyImx1Q" guid="_51BeGYGMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-GacwNmEduYd-55D-Aiqg" guid="_O-GacwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-GadANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-MhEANmEduYd-55D-Aiqg" guid="_O-MhEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-MhEQNmEduYd-55D-Aiqg" guid="_O-MhEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-MhEgNmEduYd-55D-Aiqg" x="292.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WGwNmEduYd-55D-Aiqg" guid="_O-9WGwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtgNnEduYd-55D-Aiqg" guid="_oHjVtgNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNgO8EdubhrgDuRb4fA" guid="_D6EPNgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNgPMEdubhrgDuRb4fA" guid="_-EfTNgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdhTUEduFIr9xNbwGyQ" guid="_8ZSTdhTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RvoGMEduKE9hnyImx1Q" guid="_5q5RvoGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeHoGMEduKE9hnyImx1Q" guid="_51BeHoGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-MhEwNmEduYd-55D-Aiqg" guid="_O-MhEwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-MhFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-YuUANmEduYd-55D-Aiqg" guid="_O-YuUANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-YuUQNmEduYd-55D-Aiqg" guid="_O-YuUQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-YuUgNmEduYd-55D-Aiqg" x="121.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WHANmEduYd-55D-Aiqg" guid="_O-9WHANmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtwNnEduYd-55D-Aiqg" guid="_oHjVtwNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNwO8EdubhrgDuRb4fA" guid="_D6EPNwO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNwPMEdubhrgDuRb4fA" guid="_-EfTNwPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdxTUEduFIr9xNbwGyQ" guid="_8ZSTdxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RwYGMEduKE9hnyImx1Q" guid="_5q5RwYGMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeIYGMEduKE9hnyImx1Q" guid="_51BeIYGMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-YuUwNmEduYd-55D-Aiqg" guid="_O-YuUwNmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-YuVANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-k7kANmEduYd-55D-Aiqg" guid="_O-k7kANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-k7kQNmEduYd-55D-Aiqg" guid="_O-k7kQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-k7kgNmEduYd-55D-Aiqg" x="216.0" y="565.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WHgNmEduYd-55D-Aiqg" guid="_O-9WHgNmEduYd-55D-Aiqg" anchor="_O-9WHQNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVuQNnEduYd-55D-Aiqg" guid="_oHjVuQNnEduYd-55D-Aiqg" anchor="_oHjVuANnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPOQO8EdubhrgDuRb4fA" guid="_D6EPOQO8EdubhrgDuRb4fA" anchor="_D6EPOAO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTOQPMEdubhrgDuRb4fA" guid="_-EfTOQPMEdubhrgDuRb4fA" anchor="_-EfTOAPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTeRTUEduFIr9xNbwGyQ" guid="_8ZSTeRTUEduFIr9xNbwGyQ" anchor="_8ZSTeBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rw4GMEduKE9hnyImx1Q" guid="_5q5Rw4GMEduKE9hnyImx1Q" anchor="_5q5RwoGMEduKE9hnyImx1Q _5q5RxIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeI4GMEduKE9hnyImx1Q" guid="_51BeI4GMEduKE9hnyImx1Q" anchor="_51BeIoGMEduKE9hnyImx1Q _51BeJIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WHQNmEduYd-55D-Aiqg" guid="_O-9WHQNmEduYd-55D-Aiqg" graphEdge="_O-9WHgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVuANnEduYd-55D-Aiqg" guid="_oHjVuANnEduYd-55D-Aiqg" graphEdge="_oHjVuQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOAO8EdubhrgDuRb4fA" guid="_D6EPOAO8EdubhrgDuRb4fA" graphEdge="_D6EPOQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOAPMEdubhrgDuRb4fA" guid="_-EfTOAPMEdubhrgDuRb4fA" graphEdge="_-EfTOQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTeBTUEduFIr9xNbwGyQ" guid="_8ZSTeBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTeRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RwoGMEduKE9hnyImx1Q" guid="_5q5RwoGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeIoGMEduKE9hnyImx1Q" guid="_51BeIoGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-k7kwNmEduYd-55D-Aiqg" guid="_O-k7kwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-k7lANmEduYd-55D-Aiqg" width="63.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-rCMANmEduYd-55D-Aiqg" guid="_O-rCMANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-rCMQNmEduYd-55D-Aiqg" guid="_O-rCMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-rCMgNmEduYd-55D-Aiqg" x="209.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WHwNmEduYd-55D-Aiqg" guid="_O-9WHwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVugNnEduYd-55D-Aiqg" guid="_oHjVugNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOgO8EdubhrgDuRb4fA" guid="_D6EPOgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOgPMEdubhrgDuRb4fA" guid="_-EfTOgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTehTUEduFIr9xNbwGyQ" guid="_8ZSTehTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5Rx4GMEduKE9hnyImx1Q" guid="_5q5Rx4GMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJ4GMEduKE9hnyImx1Q" guid="_51BeJ4GMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-rCMwNmEduYd-55D-Aiqg" guid="_O-rCMwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-rCNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-xI0ANmEduYd-55D-Aiqg" guid="_O-xI0ANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-xI0QNmEduYd-55D-Aiqg" guid="_O-xI0QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-xI0gNmEduYd-55D-Aiqg" x="249.0" y="1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WIQNmEduYd-55D-Aiqg" guid="_O-9WIQNmEduYd-55D-Aiqg" anchor="_O-9WIANmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVvANnEduYd-55D-Aiqg" guid="_oHjVvANnEduYd-55D-Aiqg" anchor="_oHjVuwNnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPPAO8EdubhrgDuRb4fA" guid="_D6EPPAO8EdubhrgDuRb4fA" anchor="_D6EPOwO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTPAPMEdubhrgDuRb4fA" guid="_-EfTPAPMEdubhrgDuRb4fA" anchor="_-EfTOwPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTfBTUEduFIr9xNbwGyQ" guid="_8ZSTfBTUEduFIr9xNbwGyQ" anchor="_8ZSTexTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RyYGMEduKE9hnyImx1Q" guid="_5q5RyYGMEduKE9hnyImx1Q" anchor="_5q5RyIGMEduKE9hnyImx1Q _5q5RyoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeKYGMEduKE9hnyImx1Q" guid="_51BeKYGMEduKE9hnyImx1Q" anchor="_51BeKIGMEduKE9hnyImx1Q _51BeKoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WIANmEduYd-55D-Aiqg" guid="_O-9WIANmEduYd-55D-Aiqg" graphEdge="_O-9WIQNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVuwNnEduYd-55D-Aiqg" guid="_oHjVuwNnEduYd-55D-Aiqg" graphEdge="_oHjVvANnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOwO8EdubhrgDuRb4fA" guid="_D6EPOwO8EdubhrgDuRb4fA" graphEdge="_D6EPPAO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOwPMEdubhrgDuRb4fA" guid="_-EfTOwPMEdubhrgDuRb4fA" graphEdge="_-EfTPAPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTexTUEduFIr9xNbwGyQ" guid="_8ZSTexTUEduFIr9xNbwGyQ" graphEdge="_8ZSTfBTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RyIGMEduKE9hnyImx1Q" guid="_5q5RyIGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeKIGMEduKE9hnyImx1Q" guid="_51BeKIGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-xI0wNmEduYd-55D-Aiqg" guid="_O-xI0wNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-xI1ANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-9WEANmEduYd-55D-Aiqg" guid="_O-9WEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-9WEQNmEduYd-55D-Aiqg" guid="_O-9WEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-9WEgNmEduYd-55D-Aiqg" x="249.0" y="161.0"/>
+ <anchorage xmi:id="_O-9WIgNmEduYd-55D-Aiqg" guid="_O-9WIgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVvQNnEduYd-55D-Aiqg" guid="_oHjVvQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPPQO8EdubhrgDuRb4fA" guid="_D6EPPQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTPQPMEdubhrgDuRb4fA" guid="_-EfTPQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTfRTUEduFIr9xNbwGyQ" guid="_8ZSTfRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RzYGMEduKE9hnyImx1Q" guid="_5q5RzYGMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeLYGMEduKE9hnyImx1Q" guid="_51BeLYGMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-9WEwNmEduYd-55D-Aiqg" guid="_O-9WEwNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-9WFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OgNmEduYd-55D-Aiqg" guid="_O8q3OgNmEduYd-55D-Aiqg" presentation="Activity Detail" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_NSW6sQMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sQMAEduOAKqB9I73uw" briefDescription="Cette phase consiste à dérouler les sprints les uns après les autres " presentationName="Phase des sprints" isPlanned="false" superActivities="_9llsAQAvEdubGMceRDupFQ" linkToPredecessor="_9MP9UAMAEduOAKqB9I73uw" breakdownElements="_SoXWEQMAEduOAKqB9I73uw _zbM2QIGBEduKE9hnyImx1Q _MpXRYIGOEduKE9hnyImx1Q _RHd0YIGOEduKE9hnyImx1Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9MP9UAMAEduOAKqB9I73uw" guid="_9MP9UAMAEduOAKqB9I73uw" linkType="finishToFinish" pred="_37TdkAL_EduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zbM2QIGBEduKE9hnyImx1Q" name="Sprint de release" guid="_zbM2QIGBEduKE9hnyImx1Q" briefDescription="Ce dernier sprint permet de préparer la livraison du produit." presentationName="Travaux de livraison" isPlanned="true" isOptional="true" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" mandatoryInput="_RHd0YIGOEduKE9hnyImx1Q" output="_RHd0YIGOEduKE9hnyImx1Q" performedPrimarilyBy="_MpXRYIGOEduKE9hnyImx1Q">
+ <presentation xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-EOwIzNPjfNIjzJ3TRAgeWQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MpXRYIGOEduKE9hnyImx1Q" name="Team" guid="_MpXRYIGOEduKE9hnyImx1Q" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_NSW6sQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_RHd0YIGOEduKE9hnyImx1Q" name="Product increment" guid="_RHd0YIGOEduKE9hnyImx1Q" presentationName="Incrément de produit" superActivities="_NSW6sQMAEduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
+ </processElements>
+ <diagrams xmi:id="_N15QIAMBEduOAKqB9I73uw" guid="_N15QIAMBEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_N15QIQMBEduOAKqB9I73uw" guid="_N15QIQMBEduOAKqB9I73uw">
+ <position xmi:id="_N15QIgMBEduOAKqB9I73uw" x="204.0" y="49.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_APACQWaOEduYmqfjmBwflA" guid="_APACQWaOEduYmqfjmBwflA" anchor="_APACQGaOEduYmqfjmBwflA _APACQmaOEduYmqfjmBwflA"/>
+ <anchorage xmi:id="__iwAQmaNEduYmqfjmBwflA" guid="__iwAQmaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA"/>
+ <anchorage xmi:id="_APACQGaOEduYmqfjmBwflA" guid="_APACQGaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
+ <position xmi:id="_APACQ2aOEduYmqfjmBwflA" x="212.0" y="44.0"/>
+ </anchorage>
+ <anchorage xmi:id="_K_vA8maOEduYmqfjmBwflA" guid="_K_vA8maOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QIwMBEduOAKqB9I73uw" guid="_N15QIwMBEduOAKqB9I73uw" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_N15QJAMBEduOAKqB9I73uw" width="40.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8BvXoGaNEduYmqfjmBwflA" guid="_8BvXoGaNEduYmqfjmBwflA">
+ <position xmi:id="_8BvXoWaNEduYmqfjmBwflA" x="94.0" y="62.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__iwAQWaNEduYmqfjmBwflA" guid="__iwAQWaNEduYmqfjmBwflA" anchor="__iwAQGaNEduYmqfjmBwflA __iwAQmaNEduYmqfjmBwflA"/>
+ <anchorage xmi:id="__iwAQGaNEduYmqfjmBwflA" guid="__iwAQGaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA">
+ <position xmi:id="__iwAQ2aNEduYmqfjmBwflA" x="94.0" y="51.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8BvXomaNEduYmqfjmBwflA" guid="_8BvXomaNEduYmqfjmBwflA" typeInfo="start node"/>
+ <size xmi:id="_8BvXo2aNEduYmqfjmBwflA" width="19.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8oyJgGaNEduYmqfjmBwflA" guid="_8oyJgGaNEduYmqfjmBwflA">
+ <position xmi:id="_8oyJgWaNEduYmqfjmBwflA" x="613.0" y="60.0"/>
+ <anchorage xmi:id="_7lIDYoGEEduKE9hnyImx1Q" guid="_7lIDYoGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_hKUjEoGFEduKE9hnyImx1Q" guid="_hKUjEoGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8oyJgmaNEduYmqfjmBwflA" guid="_8oyJgmaNEduYmqfjmBwflA" typeInfo="end node"/>
+ <size xmi:id="_8oyJg2aNEduYmqfjmBwflA" width="26.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9kPFIGaNEduYmqfjmBwflA" guid="_9kPFIGaNEduYmqfjmBwflA">
+ <position xmi:id="_9kPFIWaNEduYmqfjmBwflA" x="343.0" y="60.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_K_vA8WaOEduYmqfjmBwflA" guid="_K_vA8WaOEduYmqfjmBwflA" anchor="_K_vA8GaOEduYmqfjmBwflA _K_vA8maOEduYmqfjmBwflA">
+ <waypoints xmi:id="_R-7AoGaOEduYmqfjmBwflA" x="363.0" y="17.0"/>
+ <waypoints xmi:id="_QXWl4GaOEduYmqfjmBwflA" x="222.0" y="17.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_a2plkYGFEduKE9hnyImx1Q" guid="_a2plkYGFEduKE9hnyImx1Q" anchor="_a2plkIGFEduKE9hnyImx1Q _a2plkoGFEduKE9hnyImx1Q">
+ <waypoints xmi:id="_DyIEkIGGEduKE9hnyImx1Q" x="363.0" y="133.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_hKUjEYGFEduKE9hnyImx1Q" guid="_hKUjEYGFEduKE9hnyImx1Q" anchor="_hKUjEIGFEduKE9hnyImx1Q _hKUjEoGFEduKE9hnyImx1Q">
+ <waypoints xmi:id="_9g1ssIGFEduKE9hnyImx1Q" x="575.0" y="71.0"/>
+ </contained>
+ <anchorage xmi:id="_APACQmaOEduYmqfjmBwflA" guid="_APACQmaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
+ <position xmi:id="_APACRGaOEduYmqfjmBwflA" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_K_vA8GaOEduYmqfjmBwflA" guid="_K_vA8GaOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA">
+ <position xmi:id="_K_vA82aOEduYmqfjmBwflA" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_a2plkIGFEduKE9hnyImx1Q" guid="_a2plkIGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q">
+ <position xmi:id="_Ais7MIGGEduKE9hnyImx1Q" x="21.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_hKUjEIGFEduKE9hnyImx1Q" guid="_hKUjEIGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q">
+ <position xmi:id="_9C4lYIGFEduKE9hnyImx1Q" x="42.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9kPFImaNEduYmqfjmBwflA" guid="_9kPFImaNEduYmqfjmBwflA" typeInfo="decision node"/>
+ <size xmi:id="_9kPFI2aNEduYmqfjmBwflA" width="43.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_-UpVwHoSEduJVrY6eKG_mw" name="Add Free Text" guid="_-UpVwHoSEduJVrY6eKG_mw">
+ <property xmi:id="_-UpVwXoSEduJVrY6eKG_mw" guid="_-UpVwXoSEduJVrY6eKG_mw" key="free text" value="livraison à préparer"/>
+ <position xmi:id="_-UpVwnoSEduJVrY6eKG_mw" x="377.0" y="102.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_-UpVw3oSEduJVrY6eKG_mw" guid="_-UpVw3oSEduJVrY6eKG_mw" typeInfo="free text"/>
+ <size xmi:id="_-UpVxHoSEduJVrY6eKG_mw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O1l_kHoTEduJVrY6eKG_mw" name="Add Free Text" guid="_O1l_kHoTEduJVrY6eKG_mw">
+ <property xmi:id="_O1l_kXoTEduJVrY6eKG_mw" guid="_O1l_kXoTEduJVrY6eKG_mw" key="free text" value="encore un sprint"/>
+ <position xmi:id="_O1l_knoTEduJVrY6eKG_mw" x="237.0" y="0.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_O1l_k3oTEduJVrY6eKG_mw" guid="_O1l_k3oTEduJVrY6eKG_mw" typeInfo="free text"/>
+ <size xmi:id="_O1l_lHoTEduJVrY6eKG_mw" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4SofQIGBEduKE9hnyImx1Q" guid="_4SofQIGBEduKE9hnyImx1Q">
+ <position xmi:id="_4SofQYGBEduKE9hnyImx1Q" x="457.0" y="104.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7lIDYYGEEduKE9hnyImx1Q" guid="_7lIDYYGEEduKE9hnyImx1Q" anchor="_7lIDYIGEEduKE9hnyImx1Q _7lIDYoGEEduKE9hnyImx1Q">
+ <waypoints xmi:id="_FGeBUIGGEduKE9hnyImx1Q" x="626.0" y="133.0"/>
+ </contained>
+ <anchorage xmi:id="_7lIDYIGEEduKE9hnyImx1Q" guid="_7lIDYIGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q">
+ <position xmi:id="_7lIDY4GEEduKE9hnyImx1Q" x="509.0" y="67.0"/>
+ </anchorage>
+ <anchorage xmi:id="_a2plkoGFEduKE9hnyImx1Q" guid="_a2plkoGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_4SofQoGBEduKE9hnyImx1Q" guid="_4SofQoGBEduKE9hnyImx1Q" element="_zbM2QIGBEduKE9hnyImx1Q"/>
+ <size xmi:id="_4SofQ4GBEduKE9hnyImx1Q" width="82.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JYpoMIGGEduKE9hnyImx1Q" name="Add Free Text" guid="_JYpoMIGGEduKE9hnyImx1Q">
+ <property xmi:id="_JYpoMYGGEduKE9hnyImx1Q" guid="_JYpoMYGGEduKE9hnyImx1Q" key="free text" value="fin de release"/>
+ <position xmi:id="_JYpoMoGGEduKE9hnyImx1Q" x="457.0" y="54.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JYpoM4GGEduKE9hnyImx1Q" guid="_JYpoM4GGEduKE9hnyImx1Q" typeInfo="free text"/>
+ <size xmi:id="_JYpoNIGGEduKE9hnyImx1Q" width="66.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QJQMBEduOAKqB9I73uw" guid="_N15QJQMBEduOAKqB9I73uw" presentation="Workflow" element="_NSW6sQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_E1ptMIF9EduKE9hnyImx1Q" guid="_E1ptMIF9EduKE9hnyImx1Q" linkType="finishToFinish" pred="_NSW6sQMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_XJr8krPCEduk5O8SjA21Fg" name="Product Owner" guid="_XJr8krPCEduk5O8SjA21Fg" suppressed="true" presentationName="Directeur Produit" superActivities="_9llsAQAvEdubGMceRDupFQ">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <diagrams xmi:id="_kZvAwAChEduhO59Otqg2rw" guid="_kZvAwAChEduhO59Otqg2rw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAwQChEduhO59Otqg2rw" guid="_kZvAwQChEduhO59Otqg2rw">
+ <position xmi:id="_kZvAwgChEduhO59Otqg2rw" x="124.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mj1g0QChEduhO59Otqg2rw" guid="_mj1g0QChEduhO59Otqg2rw" anchor="_mj1g0AChEduhO59Otqg2rw _mj1g0gChEduhO59Otqg2rw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_mkBuEQChEduhO59Otqg2rw" guid="_mkBuEQChEduhO59Otqg2rw"/>
+ </contained>
+ <anchorage xmi:id="_mj1g0AChEduhO59Otqg2rw" guid="_mj1g0AChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw">
+ <position xmi:id="_mj1g0wChEduhO59Otqg2rw" x="158.0" y="73.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAwwChEduhO59Otqg2rw" guid="_kZvAwwChEduhO59Otqg2rw"/>
+ <size xmi:id="_kZvAxAChEduhO59Otqg2rw" width="55.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAxQChEduhO59Otqg2rw" guid="_kZvAxQChEduhO59Otqg2rw">
+ <position xmi:id="_kZvAxgChEduhO59Otqg2rw" x="340.0" y="57.0"/>
+ <anchorage xmi:id="_mj1g0gChEduhO59Otqg2rw" guid="_mj1g0gChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAxwChEduhO59Otqg2rw" guid="_kZvAxwChEduhO59Otqg2rw"/>
+ <size xmi:id="_kZvAyAChEduhO59Otqg2rw" width="62.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Ew8_sACiEduhO59Otqg2rw" name="Add Free Text" guid="_Ew8_sACiEduhO59Otqg2rw">
+ <property xmi:id="_Ew8_sQCiEduhO59Otqg2rw" guid="_Ew8_sQCiEduhO59Otqg2rw" key="free text" value="les sprints successifs qui constituent la release"/>
+ <position xmi:id="_Ew8_sgCiEduhO59Otqg2rw" x="299.0" y="87.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Ew8_swCiEduhO59Otqg2rw" guid="_Ew8_swCiEduhO59Otqg2rw" typeInfo="free text"/>
+ <size xmi:id="_Ew8_tACiEduhO59Otqg2rw" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Nk0CAACiEduhO59Otqg2rw" name="Add Free Text" guid="_Nk0CAACiEduhO59Otqg2rw">
+ <property xmi:id="_Nk6IoACiEduhO59Otqg2rw" guid="_Nk6IoACiEduhO59Otqg2rw" key="free text" value="Phase initiale avant le premier sprint"/>
+ <position xmi:id="_Nk6IoQCiEduhO59Otqg2rw" x="134.0" y="89.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Nk6IogCiEduhO59Otqg2rw" guid="_Nk6IogCiEduhO59Otqg2rw" typeInfo="free text"/>
+ <size xmi:id="_Nk6IowCiEduhO59Otqg2rw" width="72.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5YwkAEKEduzRosbOajx7w" guid="_G5YwkAEKEduzRosbOajx7w">
+ <position xmi:id="_G5e3MAEKEduzRosbOajx7w" x="109.0" y="43.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ivhy0QEKEduzRosbOajx7w" guid="_Ivhy0QEKEduzRosbOajx7w" anchor="_Ivhy0AEKEduzRosbOajx7w _Ivhy0gEKEduzRosbOajx7w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_Iv0GsQEKEduzRosbOajx7w" guid="_Iv0GsQEKEduzRosbOajx7w"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ZSAOMQEsEduzRosbOajx7w" guid="_ZSAOMQEsEduzRosbOajx7w" anchor="_ZSAOMAEsEduzRosbOajx7w _ZSAOMgEsEduzRosbOajx7w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZSSiEQEsEduzRosbOajx7w" guid="_ZSSiEQEsEduzRosbOajx7w"/>
+ </contained>
+ <anchorage xmi:id="_Ivhy0AEKEduzRosbOajx7w" guid="_Ivhy0AEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w">
+ <position xmi:id="_Ivhy0wEKEduzRosbOajx7w" x="152.0" y="58.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ZSAOMAEsEduzRosbOajx7w" guid="_ZSAOMAEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w">
+ <position xmi:id="_ZSAOMwEsEduzRosbOajx7w" x="135.0" y="60.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3MQEKEduzRosbOajx7w" guid="_G5e3MQEKEduzRosbOajx7w"/>
+ <size xmi:id="_G5e3MgEKEduzRosbOajx7w" width="55.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5e3MwEKEduzRosbOajx7w" guid="_G5e3MwEKEduzRosbOajx7w">
+ <position xmi:id="_G5e3NAEKEduzRosbOajx7w" x="337.0" y="41.0"/>
+ <anchorage xmi:id="_Ivhy0gEKEduzRosbOajx7w" guid="_Ivhy0gEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3NQEKEduzRosbOajx7w" guid="_G5e3NQEKEduzRosbOajx7w"/>
+ <size xmi:id="_G5e3NgEKEduzRosbOajx7w" width="83.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GOyb8AEsEduzRosbOajx7w" guid="_GOyb8AEsEduzRosbOajx7w">
+ <position xmi:id="_GOyb8QEsEduzRosbOajx7w" x="359.0" y="43.0"/>
+ <anchorage xmi:id="_ZSAOMgEsEduzRosbOajx7w" guid="_ZSAOMgEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GOyb8gEsEduzRosbOajx7w" guid="_GOyb8gEsEduzRosbOajx7w"/>
+ <size xmi:id="_GOyb8wEsEduzRosbOajx7w" width="32.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-4AMAEduOAKqB9I73uw" guid="_6wY-4AMAEduOAKqB9I73uw">
+ <position xmi:id="_6wY-4QMAEduOAKqB9I73uw" x="112.0" y="25.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9LxcMQMAEduOAKqB9I73uw" guid="_9LxcMQMAEduOAKqB9I73uw" anchor="_9LxcMAMAEduOAKqB9I73uw _9LxcMgMAEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9MP9UQMAEduOAKqB9I73uw" guid="_9MP9UQMAEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_9LxcMAMAEduOAKqB9I73uw" guid="_9LxcMAMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw">
+ <position xmi:id="_9LxcMwMAEduOAKqB9I73uw" x="151.0" y="42.0"/>
+ </anchorage>
+ <anchorage xmi:id="_D3KWIgMBEduOAKqB9I73uw" guid="_D3KWIgMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-4gMAEduOAKqB9I73uw" guid="_6wY-4gMAEduOAKqB9I73uw" element="_37TdkAL_EduOAKqB9I73uw"/>
+ <size xmi:id="_6wY-4wMAEduOAKqB9I73uw" width="103.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-5AMAEduOAKqB9I73uw" guid="_6wY-5AMAEduOAKqB9I73uw">
+ <position xmi:id="_6wY-5QMAEduOAKqB9I73uw" x="295.0" y="25.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_EPaeEQMBEduOAKqB9I73uw" guid="_EPaeEQMBEduOAKqB9I73uw" anchor="_EPaeEAMBEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_E1ptMYF9EduKE9hnyImx1Q" guid="_E1ptMYF9EduKE9hnyImx1Q"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_DVQF4YGHEduKE9hnyImx1Q" guid="_DVQF4YGHEduKE9hnyImx1Q" anchor="_DVQF4IGHEduKE9hnyImx1Q _DVQF4oGHEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_9LxcMgMAEduOAKqB9I73uw" guid="_9LxcMgMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_EPaeEAMBEduOAKqB9I73uw" guid="_EPaeEAMBEduOAKqB9I73uw" graphEdge="_EPaeEQMBEduOAKqB9I73uw">
+ <position xmi:id="_EPaeEwMBEduOAKqB9I73uw" x="340.0" y="44.0"/>
+ </anchorage>
+ <anchorage xmi:id="_DVQF4IGHEduKE9hnyImx1Q" guid="_DVQF4IGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q">
+ <position xmi:id="_ENbrEIGHEduKE9hnyImx1Q" x="343.0" y="41.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-5gMAEduOAKqB9I73uw" guid="_6wY-5gMAEduOAKqB9I73uw" element="_NSW6sQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_6wY-5wMAEduOAKqB9I73uw" width="87.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_CL_00AMBEduOAKqB9I73uw" guid="_CL_00AMBEduOAKqB9I73uw">
+ <position xmi:id="_CL_00QMBEduOAKqB9I73uw" x="39.0" y="38.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D3KWIQMBEduOAKqB9I73uw" guid="_D3KWIQMBEduOAKqB9I73uw" anchor="_D3KWIAMBEduOAKqB9I73uw _D3KWIgMBEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_D3KWIAMBEduOAKqB9I73uw" guid="_D3KWIAMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw">
+ <position xmi:id="_D3KWIwMBEduOAKqB9I73uw" x="46.0" y="44.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_CL_00gMBEduOAKqB9I73uw" guid="_CL_00gMBEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_CL_00wMBEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DDxxYAMBEduOAKqB9I73uw" guid="_DDxxYAMBEduOAKqB9I73uw">
+ <position xmi:id="_DD34AAMBEduOAKqB9I73uw" x="456.0" y="36.0"/>
+ <anchorage xmi:id="_DVQF4oGHEduKE9hnyImx1Q" guid="_DVQF4oGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DD34AQMBEduOAKqB9I73uw" guid="_DD34AQMBEduOAKqB9I73uw" typeInfo="end node"/>
+ <size xmi:id="_DD34AgMBEduOAKqB9I73uw" width="24.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAyQChEduhO59Otqg2rw" guid="_kZvAyQChEduhO59Otqg2rw" presentation="Workflow" element="_9llsAQAvEdubGMceRDupFQ"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:DeliveryProcess" xmi:id="_9llsAQAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAQAvEdubGMceRDupFQ" briefDescription="Les phases, les sprints et les tâches à dérouler lors de la production d'une release." presentationName="Release" isRepeatable="true" breakdownElements="_37TdkAL_EduOAKqB9I73uw _NSW6sQMAEduOAKqB9I73uw _XJr8krPCEduk5O8SjA21Fg">
+ <presentation xmi:id="-16dzhVoCex78V2iCDZVx0w" href="uma://-16dzhVoCex78V2iCDZVx0w#-16dzhVoCex78V2iCDZVx0w"/>
+ <concepts href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_XtRuYP-zEdqLnajTSLeAsA"/>
+ <defaultContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
+ <validContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/csm.jpg b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif
new file mode 100644
index 0000000..e7d73b3
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
new file mode 100644
index 0000000..bc69128
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.png b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.png
new file mode 100644
index 0000000..a91525c
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/deliveryprocesses/resources/icescrum_simple.png
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/disciplines/Scrum activities.xmi b/Scrum/Scrum_EN/library/Scrum/disciplines/Scrum activities.xmi
new file mode 100644
index 0000000..48a8e24
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/disciplines/Scrum activities.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" name="Scrum activities,_6sdMAAL-EduOAKqB9I73uw" guid="-4wqJQ0qXLYZ8kCnpDu--tA" changeDate="2006-12-03T10:43:16.000+0100" version="1.0.0">
+ <mainDescription><p>
+ L'application de Scrum concerne essentiellement&nbsp;les disciplines habituelles de gestion de projet et de gestion des
+ exigences.
+</p></mainDescription>
+ <keyConsiderations>Une bonne partie de ces activités est effectuée collectivement,&nbsp;en équipe.</keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Presentation Scrum.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Presentation Scrum.xmi
new file mode 100644
index 0000000..b707be0
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Presentation Scrum.xmi
@@ -0,0 +1,81 @@
+<?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" epf:version="1.0.0" xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" name="new_concept,_3WivIBTQEduFIr9xNbwGyQ" guid="-MSO8KF-0IlKZJGnSwwTNZA" changeDate="2006-12-03T08:21:54.843+0100" version="1.0.0">
+ <mainDescription><p>
+ Scrum est un processus léger et itératif de gestion de projets, qui fait partie de la famille des <a
+ title="Méthode agile" href="http://fr.wikipedia.org/wiki/Méthode_agile">méthodes agiles</a>, qui partage les valeurs
+ définies dans le Manifeste Agile et qui en reprend les principes fondamentaux.
+</p>
+<h5>
+ Résumé
+</h5>
+<p>
+ Scrum peut se résumer ainsi :
+</p>
+<p class="quote">
+ Scrum conduit à montrer souvent et régulièrement (toutes les 2 à 4 semaines, selon la durée du <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>) un produit (partiel) qui fonctionne. Le métier identifie les exigences et
+ définit leur priorité. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les
+ plus prioritaires. A chaque fin de sprint, tout le monde peut voir fonctionner le produit actuel et contribuer à
+ prendre une décision sur ce qu'on fait&nbsp;: soit le livrer dans l'état, soit continuer à l'améliorer pendant&nbsp;un
+ sprint&nbsp;supplémentaire avant de se reposer la question.
+</p>
+<h5>
+ Origine
+</h5>
+<p>
+ Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée,
+ qui cherche à atteindre un but, comme c'est le cas au rugby quand le pack déploie sa force collective pour avancer avec
+ le ballon pendant une mêlée.
+</p>
+<p>
+ Scrum insiste particulièrement sur l’aspect social et collectif du développement. Le but de Scrum est d'améliorer la
+ qualité et la productivité, avec une approche empirique, en s'appuyant sur l'autonomie de l'équipe.
+</p>
+<h5>
+ Empirisme
+</h5>
+<p>
+ Un processus empirique, donc basé sur l'expérience, nécessite une bonne visibilité, des inspections fréquentes et des
+ adaptations aux plans. Cela se décline dans Scrum par les 2 cycles de régulation&nbsp;:
+</p>
+<ul>
+ <li>
+ lors de mêlées quotidiennes, on tient compte de l'expérience du jour passé pour adapter le planning des jours
+ restant dans le sprint.
+ </li>
+ <li>
+ lors des revues de sprint, on tient compte de l'expérience du sprint passé pour adapter le planning de la release,
+ portant sur les sprints à venir.
+ </li>
+</ul>
+<p>
+ Les tâches d'un sprint ne sont pas définies de façon très précise : pas de date de début, pas de date de fin, pas de
+ dépendance. Scrum considère que ce n'est pas prévisible. L'empirisme de Scrum consiste à s'appuyer continuellement sur
+ l'analyse de l'état courant du projet pour contrôler le processus et réduire les risques.
+</p>
+<h5>
+ Portée
+</h5>
+<p>
+ Scrum ne décrit pas toutes les disciplines du développement (analyse, conception, codage, test) et doit être considéré,
+ plutôt qu’un processus complet, comme un pattern de processus qui est&nbsp;concerne la gestion de projet et la gestion
+ des exigences. Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement. C'est à
+ l'équipe de définir elle-même ce qu'elle à faire.
+</p>
+<h5>
+ Diffusion
+</h5>
+<p>
+ Scrum existe depuis les années 90 et connaît une popularité croissante depuis quelques années. Il a été utilisé sur des
+ centaines de projets dans le monde, mais est pour l’instant peu introduit en France. Depuis 3 ans, un processus de
+ certification a été mis en place. En novembre 2006, plus de 7000 personnes avaient obtenu la certification ScrumMaster.
+</p>
+<p>
+ &nbsp;<img height="56" alt="ScrumMaster" src="./resources/csm.jpg" width="179" />
+</p>
+<p>
+ Pour plus d'informations sur Scrum, voir <a href="http://fr.wikipedia.org/wiki/Scrum"
+ target="_blank">http://fr.wikipedia.org/wiki/Scrum</a>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Produit, release et sprint.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Produit, release et sprint.xmi
new file mode 100644
index 0000000..6d73875
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Produit, release et sprint.xmi
@@ -0,0 +1,37 @@
+<?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" epf:version="1.0.0" xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" name="Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA" guid="-BPz1k8sC6CCyJ2yZCc1p2Q" changeDate="2006-12-02T00:54:40.221+0100" version="1.0.0">
+ <mainDescription><p>
+ Une <a class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>&nbsp;est constituée d'une série de <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s et dure en général quelques mois. Pendant la vie d'un produit, on déroule
+ plusieurs releases.
+</p>
+<p>
+ <img height="115" alt="release et sprints" src="./resources/release.jpg" width="600" />
+</p>
+<p>
+ Une release a les attributs suivants :
+</p>
+<ul class="noindent">
+ <li>
+ le but
+ </li>
+ <li>
+ le type, à choisir entre "à date fixée" et "sans date fixée"(par défaut). Dans le cas où on choisit à date fixée,
+ la date est fournie.
+ </li>
+ <li>
+ la durée, en nombre de jours, définie pour les sprints
+ </li>
+ <li>
+ le nombre de sprints&nbsp;prévus
+ </li>
+</ul>
+<p>
+ Le <a class="elementLink" href="./../../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;constitue un niveau de planification du projet : il
+ montre de façon "grosses mailles" les items qu'il est prévu de réaliser au cours des sprints de cette release.<br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Travail collaboratif.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Travail collaboratif.xmi
new file mode 100644
index 0000000..55eac7a
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/Travail collaboratif.xmi
@@ -0,0 +1,134 @@
+<?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" epf:version="1.0.0" xmi:id="-dU_t9olFRQIyOBZQvMndKg" name="new_concept,_OUjj0AEZEduzRosbOajx7w" guid="-dU_t9olFRQIyOBZQvMndKg" changeDate="2006-12-04T21:17:26.750+0100">
+ <mainDescription><p>
+ Le collectif prend forme à travers des réunions. Scrum impose 5 types de réunions :&nbsp;
+</p>
+<ol>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>&nbsp;(1ème partie, sélection du sous-ensemble du backlog))
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>nt (2ème&nbsp;partie, planification du sprint)
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A.html"
+ guid="_d09LYP_AEdqtbrr0B1TG-A">Mêlée quotidienne</a>
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Review sprint,_MRrRYPpbEdqsc-f87sBK8A.html"
+ guid="_MRrRYPpbEdqsc-f87sBK8A">Faire la revue du sprint</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Retrospective,_J_sRIP_AEdqtbrr0B1TG-A.html"
+ guid="_J_sRIP_AEdqtbrr0B1TG-A">Rétrospective</a><br />
+ </li>
+</ol>
+<p>
+ Le tableau ci-dessous montre la participation des rôles Scrum à ces réunions :<br />
+</p>
+<table cellspacing="2" cellpadding="2" width="180" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ 1
+ </th>
+ <th scope="col">
+ 2
+ </th>
+ <th scope="col">
+ 3
+ </th>
+ <th scope="col">
+ 4
+ </th>
+ <th scope="col">
+ 5
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+ </th>
+ <td>
+ Animation
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Equipe
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Intervenant
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ Possible
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/clip_image001.png b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/clip_image001.png
new file mode 100644
index 0000000..32678ac
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/clip_image001.png
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/clip_image002.gif b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/clip_image002.gif
new file mode 100644
index 0000000..aa6b057
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/clip_image002.gif
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/csm.jpg b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/release.jpg b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/release.jpg
new file mode 100644
index 0000000..a270cd4
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/concepts/resources/release.jpg
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/examples/resources/demo_banque_2.JPG b/Scrum/Scrum_EN/library/Scrum/guidances/examples/resources/demo_banque_2.JPG
new file mode 100644
index 0000000..046308b
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/examples/resources/demo_banque_2.JPG
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/reports/Release Burndown Chart.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/reports/Release Burndown Chart.xmi
new file mode 100644
index 0000000..434f1c4
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/reports/Release Burndown Chart.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" name="Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A" guid="-pJuF9iKbSQx7TIwHNBVTgg" changeDate="2006-12-03T15:16:09.515+0100">
+ <mainDescription><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour une release :&nbsp;il montre la tendance dans
+ l'avancement de la release par une présentation graphique du reste à faire à la fin de chaque sprint passé.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/reports/Release Planning.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/reports/Release Planning.xmi
new file mode 100644
index 0000000..9360ab0
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/reports/Release Planning.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" name="new_report,_Z2NzkIGWEduKE9hnyImx1Q" guid="-EmLqiNX2WnmsfEtxNiuyTQ" changeDate="2006-12-02T00:51:59.549+0100">
+ <mainDescription><p>
+ Il est dérivé du backlog de produit : c'est un sous-ensemble contenant uniquement les éléments prévus dans la release
+ et associés aux sprints prévus dans la release.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi
new file mode 100644
index 0000000..10e80bb
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-qVeT6_sAspmZjCYQLOrhbg" name="Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A" guid="-qVeT6_sAspmZjCYQLOrhbg" changeDate="2006-12-03T15:17:51.046+0100">
+ <mainDescription><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour un sprint :&nbsp;il montre la tendance dans
+ l'avancement du sprint par une présentation graphique du reste à faire à la fin de chaque jour passé.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/roadmaps/Application.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/roadmaps/Application.xmi
new file mode 100644
index 0000000..5ade8ce
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/roadmaps/Application.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" name="new_roadmap,_6Jox0IRuEduo75chJsIcXg" guid="-IPxNSDzXKWa-H_kJ2PMtYA" changeDate="2006-12-05T16:29:34.781+0100">
+ <mainDescription><p>
+ Le&nbsp;Manifeste Agile proclame que "les outils et les processus sont utiles, mais que&nbsp;les personnes et les
+ interactions qu'elles ont entre elles sont plus importantes" pour la réussite du projet. Il faut garder ce principe à
+ l'esprit lors de l'application de Scrum. Il convient également de respecter les&nbsp;caractéristiques de Scrum comme :
+</p>
+<ul>
+ <li>
+ l'approche empirique basée sur la régulation,
+ </li>
+ <li>
+ la planification adaptative plutôt que prédictive,
+ </li>
+ <li>
+ l'auto-gestion de l'équipe pour faire ce qu'elle a à faire.
+ </li>
+</ul>
+<p>
+ De plus, Scrum ne décrit pas les activités d'ingénierie nécessaires à la réalisation du produit.
+</p>
+<p>
+ L'application de Scrum décrite ci-dessous&nbsp;doit être lue et utilisée&nbsp;à l'aune de ces principes agiles. Elle
+ montre comment les éléments de Scrum sont utilisés lors du déroulement d'une période de temps,&nbsp;ou cycle de vie.
+</p>
+<p>
+ Ce cycle de vie ne représente pas toute la vie d'un produit, mais porte uniquement sur la production d'une <a
+ class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>. Le guide <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA.html"
+ guid="_XtRuYP-zEdqLnajTSLeAsA">Produit, release et sprint</a>&nbsp;replace cette période dans un contexte plus large.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Copyright.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Copyright.xmi
new file mode 100644
index 0000000..09ba739
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Copyright.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-03XtfjRMEs23qIdCSSQiNQ" name="new_supporting_material,_N8zs0AEGEduzRosbOajx7w" guid="-03XtfjRMEs23qIdCSSQiNQ" changeDate="2007-02-03T11:40:46.906-0800" version="1.0.0">
+ <mainDescription>Ce programme et le matériel qui l'accompagne sont mis à disposition selon les termes de la licence "<a
+href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a>" qui régit cette
+distribution.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Introduction.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Introduction.xmi
new file mode 100644
index 0000000..8254917
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Introduction.xmi
@@ -0,0 +1,24 @@
+<?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" epf:version="1.0.0" xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" name="Introduction,_wz30kABREdu3o4yroaI-tA" guid="-WfzsSn3X35gSHQZ2kqtoVw" changeDate="2006-12-04T21:23:34.453+0100">
+ <mainDescription><p>
+ Ce plugin, réalisé&nbsp;avec&nbsp;<a href="http://www.eclipse.org/epf/" target="_blank">EPF</a> (Eclipse&nbsp;Process
+ Framework)&nbsp;présente :
+</p>
+<ul>
+ <li>
+ une introduction à <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Presentation Scrum,_3WivIBTQEduFIr9xNbwGyQ.html"
+ guid="_3WivIBTQEduFIr9xNbwGyQ">Scrum</a>
+ </li>
+ <li>
+ les notions principales de Scrum (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Scrum Elements,_nF6fgALYEduFv7wnrO7SvQ.html"
+ guid="_nF6fgALYEduFv7wnrO7SvQ">Eléments Scrum</a>),
+ </li>
+ <li>
+ une façon de les appliquer (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Cycle de vie Scrum,_7BSBkABCEduYUKPFgCzFuA.html"
+ guid="_7BSBkABCEduYUKPFgCzFuA">Cycle de vie</a>) qui est à adapter à chaque projet.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Scrum references.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Scrum references.xmi
new file mode 100644
index 0000000..a1f2561
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/supportingmaterials/Scrum references.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-cfa6bdUgQuboNpJRKaCLAw" name="Scrum referencesl,_PTGe4IRvEduo75chJsIcXg" guid="-cfa6bdUgQuboNpJRKaCLAw" changeDate="2006-12-05T15:45:31.406+0100">
+ <mainDescription><ul>
+ <li>
+ Ken Schwaber&nbsp;: <a href="http://softpro.stores.yahoo.net/0-7356-1993-x.html" target="_blank">Agile Project
+ Management with Scrum.</a>&nbsp;
+ </li>
+ <li>
+ Mike Cohn&nbsp;: <a
+ href="http://www.amazon.fr/exec/obidos/ASIN/0131479415/sr=8-1/qid=1152998855/ref=sr_1_1/402-4433368-7461703?_encoding=UTF8&amp;s=gateway&amp;v=glance"
+ target="_blank">Agile Estimating and Planning</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi
new file mode 100644
index 0000000..63ce6f7
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" name="new_term_definition,_X5rREILYEduLd8CaF_IcMA" guid="-KQ4Jzjy6YgAr_2NXa4J67g">
+ <mainDescription>Représentation graphique du reste à faire dans une période, actualisée aussi souvent que possible.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Release.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Release.xmi
new file mode 100644
index 0000000..46444c0
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Release.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" name="Release,_AIB9gIHrEduFs9jH8xc4xw" guid="-XPyPmZTAVbnvJVuOLvYpXw" changeDate="2006-12-02T10:53:51.187+0100" version="1.0.0">
+ <mainDescription>Une release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps
+qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Sprint.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Sprint.xmi
new file mode 100644
index 0000000..0af2272
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Sprint.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" name="new_term_definition,_kftWoIHqEduFs9jH8xc4xw" guid="-fcoz1Nm_QnX6xtLg5YWdVg" changeDate="2006-12-02T10:51:49.500+0100">
+ <mainDescription>Un sprint est un bloc de temps aboutissant à créer un incrément du produit. C'est le terme utilisé dans Scrum pour
+itération.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Theme.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Theme.xmi
new file mode 100644
index 0000000..2814df0
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Theme.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-GKfSarwQLoaHhoT71FQI8Q" name="new_term_definition,_aeYKoIKlEduQgtHqedKdMA" guid="-GKfSarwQLoaHhoT71FQI8Q" changeDate="2006-12-03T09:09:30.312+0100">
+ <mainDescription>Un thème constitue un regroupement fonctionnel d'exigences.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Timebox.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Timebox.xmi
new file mode 100644
index 0000000..0d19473
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Timebox.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-tHVOELWOQDI7i0M2rlMufQ" name="new_term_definition,_3qdXkILXEduLd8CaF_IcMA" guid="-tHVOELWOQDI7i0M2rlMufQ" changeDate="2006-12-03T15:11:12.609+0100">
+ <mainDescription>Une période de temps à échéance fixée et intangible même si tous les objectifs ne sont pas atteints.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Velocity.xmi b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Velocity.xmi
new file mode 100644
index 0000000..ac28bb4
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/guidances/termdefinitions/Velocity.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" name="new_term_definition,_HQEP8ILXEduLd8CaF_IcMA" guid="-PeP4fADValHXs2Z2Z8zJ1w" changeDate="2007-01-29T09:14:31.140+0100" version="1.0.0">
+ <mainDescription>La vélocité est la mesure de la capacité de l'équipe pendant un sprint.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/plugin.xmi b/Scrum/Scrum_EN/library/Scrum/plugin.xmi
new file mode 100644
index 0000000..1789c5d
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/plugin.xmi
@@ -0,0 +1,197 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_5AUAUPpYEdqsc-f87sBK8A" guid="_5AUAUPpYEdqsc-f87sBK8A">
+ <subManagers xmi:id="_9m1CIAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9m1CIAAvEdubGMceRDupFQ"/>
+ <resourceDescriptors xmi:id="_5AUAUfpYEdqsc-f87sBK8A" id="-Y3SFEe-A-lRF8TaEn9vKNQ" uri="roles/ScrumMaster.xmi"/>
+ <resourceDescriptors xmi:id="_N_XCIf-0EdqLnajTSLeAsA" id="-CgLjZ6Bwc0EyYyQCjzlw7g" uri="rolesets/Scrum%20Roles.xmi"/>
+ <resourceDescriptors xmi:id="_aziTsP--Edqtbrr0B1TG-A" id="-NRwwk6YGAtu25V3Lc04G6w" uri="tasks/Plan%20sprint%202.xmi"/>
+ <resourceDescriptors xmi:id="_9lx5QAAvEdubGMceRDupFQ" id="_9llsAAAvEdubGMceRDupFQ" uri="deliveryprocesses/Scrum/model.xmi"/>
+ <resourceDescriptors xmi:id="_qJ7PoABSEdu3o4yroaI-tA" id="-juIDa_fXi2K1BE5NTblPow" uri="customcategories/Intro.xmi"/>
+ <resourceDescriptors xmi:id="_OY10sABaEdu3o4yroaI-tA" id="-WfzsSn3X35gSHQZ2kqtoVw" uri="guidances/supportingmaterials/Introduction.xmi"/>
+ <resourceDescriptors xmi:id="_hhv8QAB7EduSVaTQTBfIHA" id="-35iKPqDM2F2PjKWQLCW4tA" uri="roles/Product%20Owner.xmi"/>
+ <resourceDescriptors xmi:id="_hh2C4AB7EduSVaTQTBfIHA" id="-mZfAV7RcWJlp5idlHzeEcA" uri="tasks/Manage%20problems.xmi"/>
+ <resourceDescriptors xmi:id="_rosG4AEGEduzRosbOajx7w" id="-03XtfjRMEs23qIdCSSQiNQ" uri="guidances/supportingmaterials/Copyright.xmi"/>
+ <resourceDescriptors xmi:id="_kTIcUAELEduzRosbOajx7w" id="-eSc2tcV1h17HBw_s8ROEVw" uri="workproducttypes/Backlogs.xmi"/>
+ <resourceDescriptors xmi:id="_K5MbwAEPEduzRosbOajx7w" id="-Of1SdnAQ9nmsL5DFvD2Uug" uri="workproducts/Product%20Backlog.xmi"/>
+ <resourceDescriptors xmi:id="_K5MbwQEPEduzRosbOajx7w" id="-LVZG5zK2YjEGXO3SwDmqug" uri="roles/Team.xmi"/>
+ <resourceDescriptors xmi:id="_K5YpAAEPEduzRosbOajx7w" id="-u0-b4PNo9XzOh1-dv_aaKA" uri="roles/StakeHolder.xmi"/>
+ <resourceDescriptors xmi:id="_AaX3AAEQEduzRosbOajx7w" id="-8V2DOvzUhvtqwWvTOHMB5g" uri="workproducts/Sprint%20backlog.xmi"/>
+ <resourceDescriptors xmi:id="_A0kNwQESEduzRosbOajx7w" id="-zoJryMCuHfxWP7Q5Er195Q" uri="tasks/Review%20sprint.xmi"/>
+ <resourceDescriptors xmi:id="_A0qUYAESEduzRosbOajx7w" id="-vDOuVl_xPKipKd90HQNZng" uri="tasks/Scrum%20daily%20meeting.xmi"/>
+ <resourceDescriptors xmi:id="_A0qUYQESEduzRosbOajx7w" id="-XdgedeazfFRGDxMY3Fnh5g" uri="tasks/Update%20product%20backlog.xmi"/>
+ <resourceDescriptors xmi:id="_wj_I8AEWEduzRosbOajx7w" id="-S4qXwp40l_8eCcyyI7o-3A" uri="tasks/Retrospective.xmi"/>
+ <resourceDescriptors xmi:id="_WYwq0QEZEduzRosbOajx7w" id="-dU_t9olFRQIyOBZQvMndKg" uri="guidances/concepts/Travail%20collaboratif.xmi"/>
+ <resourceDescriptors xmi:id="_pWgXYAL_EduOAKqB9I73uw" id="-4wqJQ0qXLYZ8kCnpDu--tA" uri="disciplines/Scrum%20activities.xmi"/>
+ <resourceDescriptors xmi:id="_PitjwQOwEduJnc8byNAQ9Q" id="-zS9h38tmK4L-U9kbgkpGKQ" uri="customcategories/Scrum%20Elements.xmi"/>
+ <resourceDescriptors xmi:id="_XQS7sAPKEdubhrgDuRb4fA" id="-3f4axrWBKHGv74oKN2x-gQ" uri="tasks/Plan%20release.xmi"/>
+ <resourceDescriptors xmi:id="_XQZCUAPKEdubhrgDuRb4fA" id="-mi1O4H7RRm0YqlUNyp8TJg" uri="tasks/Initiate%20Product%20Backlog.xmi"/>
+ <resourceDescriptors xmi:id="_E6ZVsBTREduFIr9xNbwGyQ" id="-MSO8KF-0IlKZJGnSwwTNZA" uri="guidances/concepts/Presentation%20Scrum.xmi"/>
+ <resourceDescriptors xmi:id="_ZllqMDwUEdun48PxFCzHCw" id="-BPz1k8sC6CCyJ2yZCc1p2Q" uri="guidances/concepts/Produit,%20release%20et%20sprint.xmi"/>
+ <resourceDescriptors xmi:id="_tO6jEHpCEdug1NkGFo_hTg" id="-6aCUL_kawJFNBtfH_sRXkw" uri="workproducts/Product%20increment.xmi"/>
+ <resourceDescriptors xmi:id="_5nqe4IGJEduKE9hnyImx1Q" id="-KC1R73i9f6P7ZT4pgBOLzA" uri="workproducts/Product%20Backlog%20Item.xmi"/>
+ <resourceDescriptors xmi:id="_74nh8YGWEduKE9hnyImx1Q" id="-EmLqiNX2WnmsfEtxNiuyTQ" uri="guidances/reports/Release%20Planning.xmi"/>
+ <resourceDescriptors xmi:id="_U_2y4IHpEdu3SZQ-Dp1OAA" id="-6UJtuFO3WFBFpJOFeV1QMQ" uri="workproducts/Sprint%20Backlog%20Item.xmi"/>
+ <resourceDescriptors xmi:id="_1MHpkIHqEduFs9jH8xc4xw" id="-fcoz1Nm_QnX6xtLg5YWdVg" uri="guidances/termdefinitions/Sprint.xmi"/>
+ <resourceDescriptors xmi:id="_DD7t8IHrEduFs9jH8xc4xw" id="-XPyPmZTAVbnvJVuOLvYpXw" uri="guidances/termdefinitions/Release.xmi"/>
+ <resourceDescriptors xmi:id="_mmlSkIKlEduQgtHqedKdMA" id="-GKfSarwQLoaHhoT71FQI8Q" uri="guidances/termdefinitions/Theme.xmi"/>
+ <resourceDescriptors xmi:id="_P8d_YILXEduLd8CaF_IcMA" id="-PeP4fADValHXs2Z2Z8zJ1w" uri="guidances/termdefinitions/Velocity.xmi"/>
+ <resourceDescriptors xmi:id="_IbymwILYEduLd8CaF_IcMA" id="-tHVOELWOQDI7i0M2rlMufQ" uri="guidances/termdefinitions/Timebox.xmi"/>
+ <resourceDescriptors xmi:id="_tOn1YILYEduLd8CaF_IcMA" id="-KQ4Jzjy6YgAr_2NXa4J67g" uri="guidances/termdefinitions/Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_-wFhAILYEduLd8CaF_IcMA" id="-pJuF9iKbSQx7TIwHNBVTgg" uri="guidances/reports/Release%20Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_LCa1UILZEduLd8CaF_IcMA" id="-qVeT6_sAspmZjCYQLOrhbg" uri="guidances/reports/Sprint%20Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_egmj0IRvEduo75chJsIcXg" id="-cfa6bdUgQuboNpJRKaCLAw" uri="guidances/supportingmaterials/Scrum%20references.xmi"/>
+ <resourceDescriptors xmi:id="_cpeaYYSAEduo75chJsIcXg" id="-IPxNSDzXKWa-H_kJ2PMtYA" uri="guidances/roadmaps/Application.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" name="Scrum" guid="_mQ3eoPpYEdqsc-f87sBK8A" briefDescription="Ce plugin porte sur l'utilisation de Scrum." authors="Claude Aubry" changeDate="2006-12-05T18:52:42.109+0100" version="1.0" copyrightStatement="_N8zs0AEGEduzRosbOajx7w">
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eofpYEdqsc-f87sBK8A" name="Content" guid="_mQ3eofpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eovpYEdqsc-f87sBK8A" name="Categories" guid="_mQ3eovpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eo_pYEdqsc-f87sBK8A" name="Domains" guid="_mQ3eo_pYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:Domain" xmi:id="_AcwmAANoEduYd-55D-Aiqg" name="Scrum Artefacts" guid="_AcwmAANoEduYd-55D-Aiqg" presentationName="Produits Scrum" workProducts="_tCmYEP-xEdqLnajTSLeAsA _5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epPpYEdqsc-f87sBK8A" name="Disciplines" guid="_mQ3epPpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_6sdMAAL-EduOAKqB9I73uw" name="Scrum activities" guid="_6sdMAAL-EduOAKqB9I73uw" briefDescription="Les activités spécifiques induites par l'application de Scrum." presentationName="Activités Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" tasks="_Xpd5gP_AEdqtbrr0B1TG-A _STkWYP_BEdqtbrr0B1TG-A _ho-aIP_BEdqtbrr0B1TG-A _4LOggPpaEdqsc-f87sBK8A _J_sRIP_AEdqtbrr0B1TG-A _MRrRYPpbEdqsc-f87sBK8A _d09LYP_AEdqtbrr0B1TG-A _BGFMoANkEduYd-55D-Aiqg">
+ <presentation xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" href="uma://-4wqJQ0qXLYZ8kCnpDu--tA#-4wqJQ0qXLYZ8kCnpDu--tA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epfpYEdqsc-f87sBK8A" name="RoleSets" guid="_mQ3epfpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_3qmmoP-zEdqLnajTSLeAsA" name="Scrum Roles" guid="_3qmmoP-zEdqLnajTSLeAsA" briefDescription="Les rôles dans un projet qui applique Scrum." presentationName="Rôles Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" roles="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" href="uma://-CgLjZ6Bwc0EyYyQCjzlw7g#-CgLjZ6Bwc0EyYyQCjzlw7g"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epvpYEdqsc-f87sBK8A" name="WP Types" guid="_mQ3epvpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_d-yk8ABREdu3o4yroaI-tA" name="Backlogs" guid="_d-yk8ABREdu3o4yroaI-tA" briefDescription="Scrum utilise un nombre très restreint de produits de travail, essentiellement 2 listes appelées backlogs." presentationName="Backlogs" workProducts="_5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-eSc2tcV1h17HBw_s8ROEVw" href="uma://-eSc2tcV1h17HBw_s8ROEVw#-eSc2tcV1h17HBw_s8ROEVw"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3ep_pYEdqsc-f87sBK8A" name="Tools" guid="_mQ3ep_pYEdqsc-f87sBK8A"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqPpYEdqsc-f87sBK8A" name="StandardCategories" guid="_mQ3eqPpYEdqsc-f87sBK8A"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqfpYEdqsc-f87sBK8A" name="CustomCategories" guid="_mQ3eqfpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqvpYEdqsc-f87sBK8A" name="Hidden" guid="_mQ3eqvpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mQ3eq_pYEdqsc-f87sBK8A" name="Catégories personnalisées" guid="_mQ3eq_pYEdqsc-f87sBK8A" categorizedElements="_7BSBkABCEduYUKPFgCzFuA _s8y1UABREdu3o4yroaI-tA _nF6fgALYEduFv7wnrO7SvQ"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_7BSBkABCEduYUKPFgCzFuA" name="Cycle de vie Scrum" guid="_7BSBkABCEduYUKPFgCzFuA" presentationName="Cycle de vie">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Roadmap" href="#_6Jox0IRuEduo75chJsIcXg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAQAvEdubGMceRDupFQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_XtRuYP-zEdqLnajTSLeAsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_s8y1UABREdu3o4yroaI-tA" name="Intro" guid="_s8y1UABREdu3o4yroaI-tA" presentationName="Intro" categorizedElements="_wz30kABREdu3o4yroaI-tA _3WivIBTQEduFIr9xNbwGyQ _PTGe4IRvEduo75chJsIcXg">
+ <presentation xmi:id="-juIDa_fXi2K1BE5NTblPow" href="uma://-juIDa_fXi2K1BE5NTblPow#-juIDa_fXi2K1BE5NTblPow"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_nF6fgALYEduFv7wnrO7SvQ" name="Scrum Elements" guid="_nF6fgALYEduFv7wnrO7SvQ" briefDescription="Description des éléments de Scrum : rôles, réunions et backlogs, ainsi que des guides dans leur utilisation." presentationName="Eléments" categorizedElements="_3qmmoP-zEdqLnajTSLeAsA _d-yk8ABREdu3o4yroaI-tA _6sdMAAL-EduOAKqB9I73uw">
+ <presentation xmi:id="-zS9h38tmK4L-U9kbgkpGKQ" href="uma://-zS9h38tmK4L-U9kbgkpGKQ#-zS9h38tmK4L-U9kbgkpGKQ"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3erPpYEdqsc-f87sBK8A" name="CoreContent" guid="_mQ3erPpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_rkSgEPpYEdqsc-f87sBK8A" name="Eléments de Scrum" guid="_rkSgEPpYEdqsc-f87sBK8A" briefDescription="Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet. Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques. ">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_t1K9kPpYEdqsc-f87sBK8A" name="ScrumMaster" guid="_t1K9kPpYEdqsc-f87sBK8A" briefDescription="C' est l'animateur d'une équipe Scrum." presentationName="ScrumMaster" responsibleFor="_Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" href="uma://-Y3SFEe-A-lRF8TaEn9vKNQ#-Y3SFEe-A-lRF8TaEn9vKNQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_5ABscPpYEdqsc-f87sBK8A" name="Product Backlog" guid="_5ABscPpYEdqsc-f87sBK8A" briefDescription="Contient les exigences d'un produit" presentationName="Backlog de produit" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA" reports="_vKqe8PpaEdqsc-f87sBK8A _Z2NzkIGWEduKE9hnyImx1Q">
+ <presentation xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" href="uma://-Of1SdnAQ9nmsL5DFvD2Uug#-Of1SdnAQ9nmsL5DFvD2Uug"/>
+ <containedArtifacts xmi:id="_-D85cIGIEduKE9hnyImx1Q" name="Product Backlog Item" guid="_-D85cIGIEduKE9hnyImx1Q" briefDescription="Chose à faire qui apporte de la valeur. Appelé PBI (Product Backlog Item)" presentationName="Elément de backlog de produit">
+ <presentation xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" href="uma://-KC1R73i9f6P7ZT4pgBOLzA#-KC1R73i9f6P7ZT4pgBOLzA"/>
+ </containedArtifacts>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Dzw70PpZEdqsc-f87sBK8A" name="Sprint backlog" guid="_Dzw70PpZEdqsc-f87sBK8A" briefDescription="Liste des choses à faire du point de vue de l'équipe de développement." presentationName="Backlog du sprint" reports="_jC4NwPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" href="uma://-8V2DOvzUhvtqwWvTOHMB5g#-8V2DOvzUhvtqwWvTOHMB5g"/>
+ <containedArtifacts xmi:id="_9C78MIHnEdu3SZQ-Dp1OAA" name="Sprint Backlog Item" guid="_9C78MIHnEdu3SZQ-Dp1OAA" briefDescription="C'est une tâche, un travail élémentaire à réaliser pendant le sprint." presentationName="Elément de Backlog de Sprint">
+ <presentation xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" href="uma://-6UJtuFO3WFBFpJOFeV1QMQ#-6UJtuFO3WFBFpJOFeV1QMQ"/>
+ </containedArtifacts>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_ICJyYPpaEdqsc-f87sBK8A" name="Product Owner" guid="_ICJyYPpaEdqsc-f87sBK8A" briefDescription="C’est le représentant du "métier" dans le projet. " presentationName="Directeur Produit" responsibleFor="_5ABscPpYEdqsc-f87sBK8A">
+ <presentation xmi:id="-35iKPqDM2F2PjKWQLCW4tA" href="uma://-35iKPqDM2F2PjKWQLCW4tA#-35iKPqDM2F2PjKWQLCW4tA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_jC4NwPpaEdqsc-f87sBK8A" name="Sprint Burndown Chart" guid="_jC4NwPpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement du sprint courant." presentationName="Sprint Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-qVeT6_sAspmZjCYQLOrhbg" href="uma://-qVeT6_sAspmZjCYQLOrhbg#-qVeT6_sAspmZjCYQLOrhbg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_vKqe8PpaEdqsc-f87sBK8A" name="Release Burndown Chart" guid="_vKqe8PpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement de la release." presentationName="Release Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" href="uma://-pJuF9iKbSQx7TIwHNBVTgg#-pJuF9iKbSQx7TIwHNBVTgg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_4LOggPpaEdqsc-f87sBK8A" name="Plan sprint" guid="_4LOggPpaEdqsc-f87sBK8A" briefDescription="Planification du court terme" presentationName="Planifier le sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-NRwwk6YGAtu25V3Lc04G6w" href="uma://-NRwwk6YGAtu25V3Lc04G6w#-NRwwk6YGAtu25V3Lc04G6w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_9apLsPpaEdqsc-f87sBK8A" name="Team" guid="_9apLsPpaEdqsc-f87sBK8A" briefDescription="Il s'agit d'un rôle collectif. Tous les membres de l'équipe participent au travail, sans qu'on disitingue des fonctions particulières pour chacun." presentationName="Equipe Scrum" responsibleFor="_tCmYEP-xEdqLnajTSLeAsA">
+ <presentation xmi:id="-LVZG5zK2YjEGXO3SwDmqug" href="uma://-LVZG5zK2YjEGXO3SwDmqug#-LVZG5zK2YjEGXO3SwDmqug"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_MRrRYPpbEdqsc-f87sBK8A" name="Review sprint" guid="_MRrRYPpbEdqsc-f87sBK8A" briefDescription="Montrer ce qui a été réalisé et fonctionne. En tirer les conséquences." presentationName="Faire la revue du sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_tCmYEP-xEdqLnajTSLeAsA" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-zoJryMCuHfxWP7Q5Er195Q" href="uma://-zoJryMCuHfxWP7Q5Er195Q#-zoJryMCuHfxWP7Q5Er195Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_tCmYEP-xEdqLnajTSLeAsA" name="Product increment" guid="_tCmYEP-xEdqLnajTSLeAsA" briefDescription="Le produit partiel obtenu à la fin de chaque sprint." presentationName="Incrément de produit">
+ <presentation xmi:id="-6aCUL_kawJFNBtfH_sRXkw" href="uma://-6aCUL_kawJFNBtfH_sRXkw#-6aCUL_kawJFNBtfH_sRXkw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_J_sRIP_AEdqtbrr0B1TG-A" name="Retrospective" guid="_J_sRIP_AEdqtbrr0B1TG-A" briefDescription="Faire un bilan du sprint qui se termine" presentationName="Rétrospective" performedBy="_9apLsPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-S4qXwp40l_8eCcyyI7o-3A" href="uma://-S4qXwp40l_8eCcyyI7o-3A#-S4qXwp40l_8eCcyyI7o-3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_Qqmp8P_AEdqtbrr0B1TG-A" name="StakeHolder" guid="_Qqmp8P_AEdqtbrr0B1TG-A" briefDescription="Personne ne participant pas directement au projet mais ayant une influence sur celui-ci." presentationName="Intervenant">
+ <presentation xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" href="uma://-u0-b4PNo9XzOh1-dv_aaKA#-u0-b4PNo9XzOh1-dv_aaKA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_Xpd5gP_AEdqtbrr0B1TG-A" name="Manage problems" guid="_Xpd5gP_AEdqtbrr0B1TG-A" briefDescription="Prendre en compte les événements qui surviennent à tout moment sur un projet et tenter de les régler." presentationName="Gérer les problèmes" performedBy="_t1K9kPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" optionalInput="_Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-mZfAV7RcWJlp5idlHzeEcA" href="uma://-mZfAV7RcWJlp5idlHzeEcA#-mZfAV7RcWJlp5idlHzeEcA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_d09LYP_AEdqtbrr0B1TG-A" name="Scrum daily meeting" guid="_d09LYP_AEdqtbrr0B1TG-A" briefDescription="La régulation des activités de développement et de test se fait à travers les mêlées quotidiennes." presentationName="Mêlée quotidienne" performedBy="_t1K9kPpYEdqsc-f87sBK8A" mandatoryInput="_Dzw70PpZEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_9apLsPpaEdqsc-f87sBK8A _ICJyYPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-vDOuVl_xPKipKd90HQNZng" href="uma://-vDOuVl_xPKipKd90HQNZng#-vDOuVl_xPKipKd90HQNZng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_STkWYP_BEdqtbrr0B1TG-A" name="Update product backlog" guid="_STkWYP_BEdqtbrr0B1TG-A" briefDescription="Prise en compte des changements de périmètre en vue de préparer les sprints suivants." presentationName="Mettre à jour le backlog de produit" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-XdgedeazfFRGDxMY3Fnh5g" href="uma://-XdgedeazfFRGDxMY3Fnh5g#-XdgedeazfFRGDxMY3Fnh5g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_ho-aIP_BEdqtbrr0B1TG-A" name="Plan release" guid="_ho-aIP_BEdqtbrr0B1TG-A" briefDescription="Planification à moyen terme" presentationName="Planifier la release" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-3f4axrWBKHGv74oKN2x-gQ" href="uma://-3f4axrWBKHGv74oKN2x-gQ#-3f4axrWBKHGv74oKN2x-gQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_OUjj0AEZEduzRosbOajx7w" name="Travail collaboratif" guid="_OUjj0AEZEduzRosbOajx7w" presentationName="Travail collaboratif">
+ <presentation xmi:id="-dU_t9olFRQIyOBZQvMndKg" href="uma://-dU_t9olFRQIyOBZQvMndKg#-dU_t9olFRQIyOBZQvMndKg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_XtRuYP-zEdqLnajTSLeAsA" name="Produit, release et sprint" guid="_XtRuYP-zEdqLnajTSLeAsA" presentationName="Produit, release et sprint">
+ <presentation xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" href="uma://-BPz1k8sC6CCyJ2yZCc1p2Q#-BPz1k8sC6CCyJ2yZCc1p2Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_BGFMoANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_BGFMoANkEduYd-55D-Aiqg" briefDescription="Identifier une liste d'items, les inclure dans le backlog et les classer par priorité." presentationName="Elaborer le backlog de produit initial" performedBy="_ICJyYPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" href="uma://-mi1O4H7RRm0YqlUNyp8TJg#-mi1O4H7RRm0YqlUNyp8TJg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_3WivIBTQEduFIr9xNbwGyQ" name="Presentation Scrum" guid="_3WivIBTQEduFIr9xNbwGyQ" briefDescription="Scrum repose sur une technique de gestion de projets qui conduit à obtenir un produit avec la plus grande valeur "métier" possible dans la durée la plus réduite." presentationName="Scrum">
+ <presentation xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" href="uma://-MSO8KF-0IlKZJGnSwwTNZA#-MSO8KF-0IlKZJGnSwwTNZA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_Z2NzkIGWEduKE9hnyImx1Q" name="Release Planning" guid="_Z2NzkIGWEduKE9hnyImx1Q" briefDescription="Plan montrant les sprints et les éléments du backlog associés à ces sprints" presentationName="Planning de la release" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" href="uma://-EmLqiNX2WnmsfEtxNiuyTQ#-EmLqiNX2WnmsfEtxNiuyTQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_kftWoIHqEduFs9jH8xc4xw" name="Sprint" guid="_kftWoIHqEduFs9jH8xc4xw" presentationName="Sprint">
+ <presentation xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" href="uma://-fcoz1Nm_QnX6xtLg5YWdVg#-fcoz1Nm_QnX6xtLg5YWdVg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_AIB9gIHrEduFs9jH8xc4xw" name="Release" guid="_AIB9gIHrEduFs9jH8xc4xw" presentationName="Release">
+ <presentation xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" href="uma://-XPyPmZTAVbnvJVuOLvYpXw#-XPyPmZTAVbnvJVuOLvYpXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_aeYKoIKlEduQgtHqedKdMA" name="Theme" guid="_aeYKoIKlEduQgtHqedKdMA" presentationName="Thème">
+ <presentation xmi:id="-GKfSarwQLoaHhoT71FQI8Q" href="uma://-GKfSarwQLoaHhoT71FQI8Q#-GKfSarwQLoaHhoT71FQI8Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_HQEP8ILXEduLd8CaF_IcMA" name="Velocity" guid="_HQEP8ILXEduLd8CaF_IcMA" presentationName="Vélocité">
+ <presentation xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" href="uma://-PeP4fADValHXs2Z2Z8zJ1w#-PeP4fADValHXs2Z2Z8zJ1w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3qdXkILXEduLd8CaF_IcMA" name="Timebox" guid="_3qdXkILXEduLd8CaF_IcMA" presentationName="Bloc de temps">
+ <presentation xmi:id="-tHVOELWOQDI7i0M2rlMufQ" href="uma://-tHVOELWOQDI7i0M2rlMufQ#-tHVOELWOQDI7i0M2rlMufQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_X5rREILYEduLd8CaF_IcMA" name="Burndown Chart" guid="_X5rREILYEduLd8CaF_IcMA" presentationName="Graphe de tendance">
+ <presentation xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" href="uma://-KQ4Jzjy6YgAr_2NXa4J67g#-KQ4Jzjy6YgAr_2NXa4J67g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Roadmap" xmi:id="_6Jox0IRuEduo75chJsIcXg" name="Application" guid="_6Jox0IRuEduo75chJsIcXg" briefDescription="Appliquer Scrum sans oublier les principes" presentationName="Appliquer Scrum">
+ <presentation xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" href="uma://-IPxNSDzXKWa-H_kJ2PMtYA#-IPxNSDzXKWa-H_kJ2PMtYA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_SqGkoABREdu3o4yroaI-tA" name="Général" guid="_SqGkoABREdu3o4yroaI-tA">
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_wz30kABREdu3o4yroaI-tA" name="Introduction" guid="_wz30kABREdu3o4yroaI-tA" briefDescription="Bienvenue dans Scrum !" presentationName="Introduction">
+ <presentation xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" href="uma://-WfzsSn3X35gSHQZ2kqtoVw#-WfzsSn3X35gSHQZ2kqtoVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_N8zs0AEGEduzRosbOajx7w" name="Copyright" guid="_N8zs0AEGEduzRosbOajx7w" presentationName="Copyright">
+ <presentation xmi:id="-03XtfjRMEs23qIdCSSQiNQ" href="uma://-03XtfjRMEs23qIdCSSQiNQ#-03XtfjRMEs23qIdCSSQiNQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_PTGe4IRvEduo75chJsIcXg" name="Scrum references" guid="_PTGe4IRvEduo75chJsIcXg" presentationName="Références">
+ <presentation xmi:id="-cfa6bdUgQuboNpJRKaCLAw" href="uma://-cfa6bdUgQuboNpJRKaCLAw#-cfa6bdUgQuboNpJRKaCLAw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3erfpYEdqsc-f87sBK8A" name="CapabilityPatterns" guid="_mQ3erfpYEdqsc-f87sBK8A"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3ervpYEdqsc-f87sBK8A" name="DeliveryProcesses" guid="_mQ3ervpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_9llsAAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3er_pYEdqsc-f87sBK8A" name="ProcessContributions" guid="_mQ3er_pYEdqsc-f87sBK8A"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/Scrum/Scrum_EN/library/Scrum/roles/Product Owner.xmi b/Scrum/Scrum_EN/library/Scrum/roles/Product Owner.xmi
new file mode 100644
index 0000000..8a24545
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/roles/Product Owner.xmi
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-35iKPqDM2F2PjKWQLCW4tA" name="Product Owner,_ICJyYPpaEdqsc-f87sBK8A" guid="-35iKPqDM2F2PjKWQLCW4tA" authors="Claude Aubry" changeDate="2006-12-06T09:55:24.078+0100" version="1.0.0">
+ <mainDescription><p>
+ Le Directeur de produit (<i>Product Owner</i>) est le représentant des clients et utilisateurs dans l'équipe.
+</p>
+<p>
+ A ce titre, il est responsable de définir les caractéristiques du produit développé par l'équipe en termes de :
+</p>
+<ul>
+ <li>
+ <strong>fonctionnalités</strong> offertes. Plus précisément il identifie chaque exigence que doit&nbsp;satisfaire
+ le produit comme un&nbsp;<a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;(ou item). Il fournit les détails sur ces
+ exigences quand c'est nécessaire pour l'équipe. Il est souhaitable qu'il spécifie&nbsp;les tests d'acceptation
+ (acceptance tests) de chaque exigence.
+ </li>
+ <li>
+ <strong>priorité</strong>. C'est lui qui définit l'ordre dans lequel ces éléments seront développés en fonction de
+ la valeur qu'ils apportent aux clients et utilisateurs. Cela permet d'alimenter l'équipe avec un <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;prêt pour la planification des sprints,
+ </li>
+ <li>
+ <strong>but</strong>. C'est lui définit l'objectif d'une release et qui prend les décisions concernant le <a
+ class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><p>
+ Son implication est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il&nbsp;donne
+ l'impulsion à l'équipe. En promouvant à l'extérieur le résultat de chaque sprint, il fournit à l'équipe une
+ reconnaissance qui la motive.
+</p></keyConsiderations>
+ <skills><p>
+ Une personne qui joue ce rôle devrait posséder les compétences suivantes :
+</p>
+<ul>
+ <li>
+ bonne connaissance du domaine métier,
+ </li>
+ <li>
+ capacité à avoir une position respectée par tous les intervenants extérieurs (clients et utilisateurs),
+ </li>
+ <li>
+ capacité à prendre une décision au bon moment (pas trop tôt ni trop tard),
+ </li>
+ <li>
+ esprit ouvert au changement,
+ </li>
+ <li>
+ facilité à communiquer avec l'équipe.
+ </li>
+</ul>
+<p>
+ Quelqu'un qui a été Analyste Métier (Business Analyst) est un bon candidat pour ce rôle.
+</p></skills>
+ <assignmentApproaches><p>
+ Il n'y a qu'une seule personne qui joue ce rôle. Cette personne doit être affectée au projet (le Directeur de produit
+ fait partie de l'équipe étendue et participe aux réunions). Le travail nécessite une affectation à plein temps ou
+ presque.
+</p>
+<p>
+ Il est&nbsp;important qu'il soit très disponible pour répondre aux questions de l'équipe, pour définir les tests
+ fonctionnels et&nbsp;donner son avis sur divers aspects du produit (l'interface homme machine d'un logiciel, par
+ exemple).
+</p></assignmentApproaches>
+ <synonyms>Propriétaire de produit (product owner en anglais),&nbsp;Client (dans XP)</synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/roles/ScrumMaster.xmi b/Scrum/Scrum_EN/library/Scrum/roles/ScrumMaster.xmi
new file mode 100644
index 0000000..84b2974
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/roles/ScrumMaster.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" name="new_role,_t1K9kPpYEdqsc-f87sBK8A" guid="-Y3SFEe-A-lRF8TaEn9vKNQ" authors="Claude Aubry" changeDate="2007-01-08T17:37:05.421+0100" version="1.0.0">
+ <mainDescription><p>
+ Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome
+ et à s'améliorer constamment.
+</p>
+<p>
+ Pour cela, il effectue les travaux suivants :&nbsp;
+</p>
+<ul>
+ <li>
+ tâches périodiques,&nbsp;dont l'objectif est de mettre en application Scrum en organisant et animant le&nbsp;<a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>&nbsp;(réunions)&nbsp;:
+ <ul>
+ <li>
+ Mêlée quotidienne.
+ </li>
+ <li>
+ Planification du sprint
+ </li>
+ <li>
+ Revue du sprint
+ </li>
+ <li>
+ Rétrospective
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâches sur évènement
+ <ul>
+ <li>
+ éliminer les obstacles&nbsp;: prendre en compte les évènements qui surviennent à tout moment sur un projet
+ pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâche de fond
+ <ul>
+ <li>
+ faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les
+ éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .
+ </li>
+ </ul>
+ </li>
+</ul>
+<p>
+ Analogies
+</p>
+<ul>
+ <li>
+ Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de
+ ScrumMaster.
+ </li>
+ <li>
+ Ken Schwaber compare le ScrumMaster à un chien de berger.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><ul>
+ <li>
+ Ce n'est pas un chef de projet&nbsp;: il ne dirige pas, il n'impose pas, il ne contraint pas.
+ </li>
+ <li>
+ Il fait partie de l'équipe&nbsp;: il s'engage avec les autres.
+ </li>
+ <li>
+ Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.
+ </li>
+</ul></keyConsiderations>
+ <skills><p>
+ Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est
+ préférable de posséder les compétences suivantes pour jouer&nbsp;ce rôle :
+</p>
+<ul>
+ <li>
+ bien connaître Scrum,
+ </li>
+ <li>
+ avoir des facilités de présentation, de communication et de négociation,
+ </li>
+ <li>
+ guider sans imposer,
+ </li>
+ <li>
+ faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
+ </li>
+ <li>
+ savoir résoudre les conflits et les problèmes,
+ </li>
+ <li>
+ communiquer honnêtement sur le degré d'avancement,
+ </li>
+ <li>
+ garder le respect de l'objectif essentiel, qui est de livrer un produit qui remplit&nbsp;ses exigences.
+ </li>
+</ul>
+<p>
+ En revanche il n'est pas nécessaire de :
+</p>
+<ul>
+ <li>
+ avoir de l'expérience du domaine de l'application (pas indispensable, mais ça peut aider),
+ </li>
+ <li>
+ avoir des compétences techniques sur le développement.
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ Pour une équipe Scrum typique (de 6 à 10 personnes) , une seule personne joue ce rôle sur un projet.
+</p>
+<p>
+ Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela
+ doit rester limité.
+</p></assignmentApproaches>
+ <synonyms><p>
+ Facilitateur de processus. On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela
+ ne favorise pas la compréhension du rôle.
+</p></synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/roles/StakeHolder.xmi b/Scrum/Scrum_EN/library/Scrum/roles/StakeHolder.xmi
new file mode 100644
index 0000000..a1ded05
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/roles/StakeHolder.xmi
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" name="StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A" guid="-u0-b4PNo9XzOh1-dv_aaKA" authors="Claude Aubry" changeDate="2006-12-03T09:39:26.078+0100" version="1.0.0">
+ <mainDescription><p>
+ Un intervenant ne fait pas partie de l'équipe, mais il est intéressé par le produit réalisé. Il peut avoir une
+ influence sur le déroulement du projet. Il participe à des réunions Scrum : voir sa contribution au <a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>.
+</p>
+<p>
+ Dans son jargon, Scrum appelle&nbsp;les personnes jouant ce rôle&nbsp;des poules (chicken) et conseille de protéger
+ l’équipe, constituée des cochons (pigs), de leur influence directe sur le projet pendant un sprint. Cela signifie que
+ les intervenants ont des fenêtres d'intervention qui sont strictement définies afin de ne pas perturber le travail de
+ l'équipe.
+</p></mainDescription>
+ <synonyms><p>
+ Partie-prenante (Stakeholder en anglais)
+</p></synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/roles/Team.xmi b/Scrum/Scrum_EN/library/Scrum/roles/Team.xmi
new file mode 100644
index 0000000..91e38f6
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/roles/Team.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-LVZG5zK2YjEGXO3SwDmqug" name="Team,_9apLsPpaEdqsc-f87sBK8A" guid="-LVZG5zK2YjEGXO3SwDmqug" authors="Claude Aubry" changeDate="2006-12-03T09:36:21.984+0100" version="1.0.0">
+ <mainDescription><p>
+ Une équipe regroupe des membres qui forment un tout soudé capable de réaliser les différentes tâches sur
+ lesquelles&nbsp;elle s’engage collectivement lors de chaque sprint.
+</p>
+<p>
+ Elle possède la latitude voulue pour déterminer ce qui doit être fait afin d’atteindre le but fixé du sprint. Elle
+ s’organise de façon autonome et planifie ses propres travaux, sans se les faire imposer.
+</p></mainDescription>
+ <keyConsiderations>Par son approche centrée sur le collectif,&nbsp;l'agilité contribue à améliorer la camaraderie dans l’équipe.</keyConsiderations>
+ <skills>L’équipe doit être capable de réaliser les différentes tâches sur lesquelles elle s'engage lors de la planification du
+sprint. Cela signifie qu'elle doit être multi-fonctionnelle (cross-functional) pour couvrir les travaux d'analyse, de
+conception, de codage, de test et autres.</skills>
+ <assignmentApproaches>Une équipe Scrum comprend généralement de&nbsp;3 à 10 personnes.</assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/roles/resources/148-le-role-de-scrummaster.html b/Scrum/Scrum_EN/library/Scrum/roles/resources/148-le-role-de-scrummaster.html
new file mode 100644
index 0000000..83644c8
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/roles/resources/148-le-role-de-scrummaster.html
@@ -0,0 +1,296 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html lang="fr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+<head>
+
+
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+
+
+
+
+ <meta name="MSSmartTagsPreventParsing" content="TRUE">
+ <link rel="previous" href="http://www.aubryconseil.com/dotclear/index.php/2007/01/05/146-inscription-technorati" title="Inscription Technorati">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-projets" title="Mes projets">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Evenements" title="Mes événements">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-conseils" title="Mes conseils">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-cours" title="Mes cours">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-france" title="L'agilité en France">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-dans-le-monde" title="L'agilité dans le monde">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-dehors-du-logiciel" title="L'agilité en dehors du logiciel">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-butinage" title="Mon butinage">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-blog" title="Mon blog">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2007/01" title="janvier 2007">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/12" title="décembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/11" title="novembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/10" title="octobre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/09" title="septembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/08" title="août 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/07" title="juillet 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/06" title="juin 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/05" title="mai 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/04" title="avril 2006">
+ <link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.aubryconseil.com/dotclear/rss.php">
+ <link rel="alternate" type="application/xml" title="Atom" href="http://www.aubryconseil.com/dotclear/atom.php">
+ <meta name="DC.title" content="Scrum - Méthodes agiles"><title>Le rôle de ScrumMaster - Scrum - Méthodes agiles</title><!--
+<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
+<rdf:Description
+ rdf:about="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
+ dc:identifier="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
+ dc:title="Le rôle de ScrumMaster"
+ trackback:ping="http://www.aubryconseil.com/dotclear/tb.php?id=148" />
+</rdf:RDF>
+-->
+
+
+
+<link rel="stylesheet" type="text/css" href="148-le-role-de-scrummaster.css" media="all"></head><body>
+
+<div id="page">
+
+<div id="top">
+ <h1><a indepth="true" href="index.html">Scrum - Méthodes agiles</a></h1>
+</div>
+
+<p id="prelude"><a href="#main">Aller au contenu</a> |
+<a href="#sidebar">Aller au menu</a> |
+<a href="#search">Aller à la recherche</a></p>
+
+<div id="main">
+ <div id="content">
+
+<div class="post">
+ <h2 class="post-title">Le rôle de ScrumMaster</h2>
+ <p class="post-info">
+<!--
+claude aubry,
+-->
+ dimanche 7 janvier 2007 à 16:08 <span>::</span> <a indepth="true" href="mes-conseils.html">Mes conseils</a>
+ <span>::</span> <a indepth="true" href="148-le-role-de-scrummaster.html" title="Lien permanent vers : Le rôle de ScrumMaster">#148</a>
+ <span>::</span> <a href="http://www.aubryconseil.com/dotclear/rss.php?type=co&post=148" title="fil RSS des commentaires de : Le rôle de ScrumMaster">rss</a>
+ </p>
+
+ <div class="post-chapo"><p>Un résumé du rôle de ScrumMaster, l'animateur d'une équipe qui applique Scrum.</p></div> <div class="post-content"><h5>Synonymes</h5>
+<ul>
+<li>Facilitateur de processus.</li>
+<li>On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela ne favorise pas la compréhension du rôle <sup>[<a href="#pnote-148-1" id="rev-pnote-148-1">1</a>]</sup>.</li>
+</ul>
+<h5>Analogies</h5>
+<ul>
+<li>Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de ScrumMaster.</li>
+<li>Ken Schwaber compare le ScrumMaster à un chien de berger.</li>
+</ul>
+<h5>Responsabilité</h5>
+
+<p>Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome et à s'améliorer constamment.</p>
+
+
+<h5>Tâches</h5>
+<ul>
+<li>tâches périodiques : mettre en application Scrum en organisant et animant les réunions :
+<ul>
+<li>Mêlée quotidienne.</li>
+<li>Planification du sprint</li>
+<li>Revue du sprint</li>
+<li>Rétrospective</li>
+</ul></li>
+<li>tâches sur évènement
+<ul>
+<li>éliminer les obstacles : prendre en compte les évènements qui surviennent à tout moment sur un projet pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures</li>
+</ul></li>
+<li>tâche de fond
+<ul>
+<li>faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .</li>
+</ul></li>
+</ul>
+
+<h5>Compétences</h5>
+
+<p>Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est préférable de posséder les compétences suivantes pour jouer ce rôle :</p>
+<ul>
+<li>bien connaitre Scrum,</li>
+<li>avoir des facilités de présentation, de communication et de négociation,</li>
+<li>guider sans imposer,</li>
+<li>faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,</li>
+<li>savoir résoudre les conflits et les problèmes,</li>
+<li>communiquer honnêtement sur le degré d'avancement,</li>
+<li>garder le respect de l'objectif essentiel, qui est de livrer un produit qui apporte de la valeur avec une utilisation optimale des ressources.</li>
+</ul>
+
+<p>En revanche il n'est pas nécessaire de :</p>
+<ul>
+<li>avoir de l'expérience du domaine de l'application <sup>[<a href="#pnote-148-2" id="rev-pnote-148-2">2</a>]</sup>,</li>
+<li>avoir des compétences techniques sur le développement logiciel.</li>
+</ul>
+
+<h5>Affectation</h5>
+
+
+<p>Pour une équipe Scrum typique <sup>[<a href="#pnote-148-3" id="rev-pnote-148-3">3</a>]</sup>, une seule personne joue ce rôle sur un projet.</p>
+
+
+<p>Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela doit rester limité.</p>
+
+<h5>Points clés</h5>
+<ul>
+<li>Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas.</li>
+<li>Il fait partie de l'équipe : il s'engage avec les autres.</li>
+<li>Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.</li>
+</ul>
+<div class="footnotes"><h4>Notes</h4>
+<p>[<a href="#rev-pnote-148-1" id="pnote-148-1">1</a>] voir sur ce sujet <a href="http://agilitateur.azeau.com/index.php?itemid=61" hreflang="fr">le billet de l'Agilitateur</a></p>
+<p>[<a href="#rev-pnote-148-2" id="pnote-148-2">2</a>] ce n'est pas indispensable, mais ça peut aider</p>
+<p>[<a href="#rev-pnote-148-3" id="pnote-148-3">3</a>] de 6 à 10 personnes</p></div></div>
+
+
+</div>
+
+<div id="trackbacks">
+ <h3 id="tb">Rétroliens</h3>
+ <p>Aucun rétrolien.</p>
+
+
+
+ <p>Pour faire un rétrolien sur ce billet :
+ http://www.aubryconseil.com/dotclear/tb.php?id=148</p>
+ </div>
+
+<div id="comments">
+ <h3 id="co">Commentaires</h3>
+ <p>Aucun commentaire pour le moment.</p>
+
+
+
+ <h3>Ajouter un commentaire</h3>
+ <form action="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" method="post" id="comment-form">
+<fieldset>
+ <p class="field"><label for="c_nom">Nom ou pseudo :</label>
+ <input name="c_nom" id="c_nom" size="30" maxlength="255" value="" type="text">
+ </p>
+
+ <p class="field"><label for="c_mail">Email (facultatif) :</label>
+ <input name="c_mail" id="c_mail" size="30" maxlength="255" value="" type="text">
+ </p>
+
+ <p class="field"><label for="c_site">Site Web (facultatif) :</label>
+ <input name="c_site" id="c_site" size="30" maxlength="255" value="http://" type="text">
+ </p>
+
+ <p class="field"><label for="c_content">Commentaire :</label>
+ <textarea name="c_content" id="c_content" cols="35" rows="7"></textarea>
+ </p>
+</fieldset>
+
+<p class="form-help">Le code HTML dans le commentaire sera affiché comme du texte,
+les adresses internet seront converties automatiquement.</p>
+
+<fieldset>
+ <p><input id="c_remember" name="c_remember" type="checkbox">
+ <label for="c_remember">Se souvenir de mes informations</label>
+ </p>
+ <p><input class="preview" name="preview" value="prévisualiser" type="submit">
+ <input class="submit" value="envoyer" type="submit">
+ <input name="redir" value="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" type="hidden"></p>
+</fieldset>
+
+</form>
+ </div>
+ </div>
+</div>
+
+ <div id="sidebar">
+
+
+ <div id="presentation"><h2></h2><p>Dans ce blog ma contribution à la diffusion de Scrum à travers mes expériences en tant que <a href="http://www.aubryconseil.com/">consultant</a> et comme enseignant à l'<a href="http://www.iup-ups.ups-tlse.fr/isi/" hreflang="fr">IUP ISI</a> <br>
+Claude Aubry</p>
+ <a indepth="true" href="contact.html">Page contact</a>
+ </div>
+
+ <div id="connexes">
+ <h2>Scrum</h2>
+
+ <ul><li><a indepth="true" href="scrum_001.html">Introduction à Scrum</a>
+</li><li><a indepth="true" href="mon-offre-scrum.html">Essayer Scrum</a>
+</li><li><a indepth="true" href="icescrum.html">IceScrum</a>
+</li><li><a indepth="true" href="liens-scrum.html">Plus d'infos sur Scrum</a>
+</li></ul> </div>
+
+
+
+ <div id="tags">
+ <h2>Tags</h2>
+
+ <ul id="tagcloud"><li class="level-2"><a indepth="true" href="agilite.html">agilité</a> </li><li class="level-1"><a indepth="true" href="backlog.html">backlog</a> </li><li class="level-1"><a indepth="true" href="blog.html">blog</a> </li><li class="level-1"><a indepth="true" href="conference.html">conférence</a> </li><li class="level-1"><a indepth="true" href="contrat.html">contrat</a> </li><li class="level-1"><a indepth="true" href="dotclear.html">dotclear</a> </li><li class="level-1"><a indepth="true" href="epf.html">EPF</a> </li><li class="level-1"><a indepth="true" href="equipe.html">equipe</a> </li><li class="level-2"><a indepth="true" href="estimation.html">estimation</a> </li><li class="level-1"><a indepth="true" href="fac.html">fac</a> </li><li class="level-1"><a indepth="true" href="formation.html">formation</a> </li><li class="level-1"><a indepth="true" href="humour.html">humour</a> </li><li class="level-2"><a indepth="true" href="icescrum_001.html">icescrum</a> </li><li class="level-1"><a indepth="true" href="mesures.html">mesures</a> </li><li class="level-1"><a indepth="true" href="moi.html">moi</a> </li><li class="level-1"><a indepth="true" href="musique.html">musique</a> </li><li class="level-1"><a indepth="true" href="openup.html">OpenUP</a> </li><li class="level-1"><a indepth="true" href="outils.html">outils</a> </li><li class="level-2"><a indepth="true" href="planification.html">planification</a> </li><li class="level-2"><a indepth="true" href="processus.html">processus</a> </li><li class="level-1"><a indepth="true" href="presentation.html">présentation</a> </li><li class="level-1"><a indepth="true" href="release.html">release</a> </li><li class="level-1"><a indepth="true" href="rugby.html">rugby</a> </li><li class="level-1"><a indepth="true" href="retrospective.html">rétrospective</a> </li><li class="level-1"><a indepth="true" href="roles.html">rôles</a> </li><li class="level-5"><a indepth="true" href="scrum.html">scrum</a> </li><li class="level-1"><a indepth="true" href="sigmat.html">sigmat</a> </li><li class="level-1"><a indepth="true" href="tdd.html">tdd</a> </li><li class="level-1"><a indepth="true" href="techno.html">techno</a> </li><li class="level-2"><a indepth="true" href="tendances.html">tendances</a> </li><li class="level-1"><a indepth="true" href="traduction.html">traduction</a> </li><li class="level-1"><a indepth="true" href="uml.html">UML</a> </li><li class="level-2"><a indepth="true" href="user-stories.html">user stories</a> </li><li class="level-1"><a indepth="true" href="vision.html">vision</a> </li><li class="level-1"><a indepth="true" href="xp.html">xp</a> </li></ul> </div>
+
+ <div id="syndicate">
+ <h2>Syndication</h2>
+ <a href="http://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fwww.aubryconseil.com%2Fdotclear"><img src="add2netvibes.gif" alt="Add to Netvibes" height="17" width="91"></a>
+ <ul>
+ <li><a href="http://www.aubryconseil.com/dotclear/rss.php">fil rss</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/rss.php?type=co">fil rss commentaires</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/atom.php">fil atom</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/atom.php?type=co">fil atom commentaires</a></li>
+ </ul>
+ </div>
+
+ <div id="calendar">
+ <h2>Calendrier</h2>
+ <table summary="Calendrier">
+<caption><a indepth="true" href="12.html" title="décembre 2006">«</a> janvier 2007</caption><thead><tr><th scope="col"><abbr title="lundi">lun</abbr></th><th scope="col"><abbr title="mardi">mar</abbr></th><th scope="col"><abbr title="mercredi">mer</abbr></th><th scope="col"><abbr title="jeudi">jeu</abbr></th><th scope="col"><abbr title="vendredi">ven</abbr></th><th scope="col"><abbr title="samedi">sam</abbr></th><th scope="col"><abbr title="dimanche">dim</abbr></th></tr></thead>
+<tbody><tr><td><a indepth="true" href="01.html">1</a></td><td><a indepth="true" href="02.html">2</a></td><td>3</td><td><a indepth="true" href="04.html">4</a></td><td><a indepth="true" href="05.html">5</a></td><td>6</td><td class="active"><a indepth="true" href="07.html">7</a></td></tr>
+<tr><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td><td>13</td><td>14</td></tr>
+<tr><td>15</td><td>16</td><td>17</td><td>18</td><td>19</td><td>20</td><td>21</td></tr>
+<tr><td>22</td><td>23</td><td>24</td><td>25</td><td>26</td><td>27</td><td>28</td></tr>
+<tr><td>29</td><td>30</td><td>31</td><td> </td><td> </td><td> </td><td> </td></tr>
+</tbody>
+</table> </div>
+
+ <div id="search">
+ <form action="http://www.aubryconseil.com/dotclear/index.php/" method="get">
+
+ <h2><label for="q">Rechercher</label></h2>
+ <p class="field"><input name="q" id="q" size="10" value="" accesskey="4" type="text">
+ <input class="submit" value="ok" type="submit"></p>
+
+ </form>
+ </div>
+
+ <div id="selection"><h2>À retenir</h2><ul><li><a indepth="true" href="148-le-role-de-scrummaster.html">Le rôle de ScrumMaster</a></li><li><a indepth="true" href="132-le-role-de-directeur-de-produit.html">Le rôle de directeur de produit</a></li><li><a indepth="true" href="125-scrum-en-bref.html">Scrum en bref</a></li><li><a indepth="true" href="115-backlog-priorise.html">Backlog : critères pour établir les priorités</a></li><li><a indepth="true" href="99-discipline-et-agilite.html">Discipline et agilité</a></li><li><a indepth="true" href="87-duree-fixe-des-iterations.html">Durée fixe des itérations</a></li><li><a indepth="true" href="67-la-minute-ideale-du-randonneur.html">La minute idéale du randonneur</a></li><li><a indepth="true" href="58-agilite-pour-un-contrat-au-forfait.html">Agilité pour un contrat au forfait</a></li><li><a indepth="true" href="36-avant-la-premiere-iteration.html">Avant la première itération</a></li><li><a indepth="true" href="29-duree-d-une-iteration.html">Durée d'une itération</a></li></ul></div>
+
+ <div id="toclink">
+<h2><a indepth="true" href="toc.html">Table des matières</a></h2>
+</div>
+
+
+
+ <div id="archives">
+ <h2>Archives</h2>
+ <ul><li><strong><a indepth="true" href="01_001.html">janvier 2007</a></strong></li><li><a indepth="true" href="12.html">décembre 2006</a></li><li><a indepth="true" href="11.html">novembre 2006</a></li><li><a indepth="true" href="10.html">octobre 2006</a></li><li><a indepth="true" href="09.html">septembre 2006</a></li><li><a indepth="true" href="08.html">août 2006</a></li><li><a indepth="true" href="07_001.html">juillet 2006</a></li><li><a indepth="true" href="06.html">juin 2006</a></li><li><a indepth="true" href="05_001.html">mai 2006</a></li><li><a indepth="true" href="04_001.html">avril 2006</a></li></ul> </div>
+
+ <div id="links">
+ <h2>Blogs lus régulièrement</h2>
+ <h3>Agile</h3><ul><li><a href="http://agilitateur.azeau.com/" hreflang="fr">L'Agilitateur</a></li><li><a href="http://kanemar.wordpress.com/" hreflang="EN">Kane Mar</a></li><li><a href="http://silkandspinach.net/" hreflang="EN">Silk and Spinach</a></li><li><a href="http://www.testing.com/cgi-bin/blog" hreflang="en">Exploration Through Example</a></li><li><a href="http://www.agileadvice.com/" hreflang="EN">Agile Advice</a></li><li><a href="http://theagileblog.net/" hreflang="en">On Be(come)ing Agile</a></li><li><a href="http://bossavit.com/thoughts/" hreflang="EN" rel="co-worker">Laurent Bossavit</a></li><li><a href="http://prog13.free.fr/" hreflang="fr">Avangel</a></li><li><a href="http://tcros.blogspot.com/" hreflang="fr">Thierry Cros</a></li></ul><h3>Techno</h3><ul><li><a href="http://www.dotnetguru2.org/proques/" hreflang="fr" title="Le blog de Pascal Roques">UML Guru</a></li><li><a href="http://www.inherence.fr/dotclear/" hreflang="fr">Parlons ISO 20000</a></li><li><a href="http://nauges.typepad.com/my_weblog/" hreflang="fr">Louis Naugès</a></li><li><a href="http://standblog.org/blog/" hreflang="fr">StandBlog</a></li></ul> </div>
+
+ <div id="categories">
+ <h2>Catégories</h2>
+ <ul><li><a indepth="true" href="mes-projets.html">Mes projets</a></li><li><a indepth="true" href="evenements.html">Mes événements</a></li><li><a indepth="true" href="mes-conseils.html">Mes conseils</a></li><li><a indepth="true" href="mes-cours.html">Mes cours</a></li><li><a indepth="true" href="l-agilite-en-france.html">L'agilité en France</a></li><li><a indepth="true" href="l-agilite-dans-le-monde.html">L'agilité dans le monde</a></li><li><a indepth="true" href="l-agilite-en-dehors-du-logiciel.html">L'agilité en dehors du logiciel</a></li><li><a indepth="true" href="mon-butinage.html">Mon butinage</a></li><li><a indepth="true" href="mon-blog.html">Mon blog</a></li></ul> </div>
+
+
+
+
+</div><p id="footer">Le blog de Claude Aubry est <a href="http://www.dotclear.net/">
+propulsé par DotClear</a></p>
+
+</div>
+<!-- end #page -->
+
+<!-- Blocs en plus pour ajouter des images en tout genre si besoin -->
+<div id="block1"><span></span></div><div id="block2"><span></span></div>
+<div id="block3"><span></span></div><div id="block4"><span></span></div>
+<div id="block5"><span></span></div><div id="block6"><span></span></div>
+
+
+
+</body></html>
diff --git a/Scrum/Scrum_EN/library/Scrum/rolesets/Scrum Roles.xmi b/Scrum/Scrum_EN/library/Scrum/rolesets/Scrum Roles.xmi
new file mode 100644
index 0000000..8542e8b
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/rolesets/Scrum Roles.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" name="new_role_set,_3qmmoP-zEdqLnajTSLeAsA" guid="-CgLjZ6Bwc0EyYyQCjzlw7g" changeDate="2006-12-03T08:51:09.000+0100">
+ <mainDescription><p>
+ Scrum définit uniquement 3 rôles pour les personnes qui participent aux travaux de développement. A la différence
+ d’autres processus, il n’existe pas d’architecte, de programmeur, de testeur, d’analyste, de rédacteur. L’équipe
+ regroupe les compétences sans distinction du rôle de chacun a priori.
+</p>
+<p>
+ Toutes les personnes ayant une influence sur&nbsp;le projet sans y participer directement sont représentées par le rôle
+ <a class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/scrum.jpg b/Scrum/Scrum_EN/library/Scrum/scrum.jpg
new file mode 100644
index 0000000..5fe67e3
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/scrum.jpg
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Initiate Product Backlog.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Initiate Product Backlog.xmi
new file mode 100644
index 0000000..3563196
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Initiate Product Backlog.xmi
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" name="Initiate Product Backlog,_BGFMoANkEduYd-55D-Aiqg" guid="-mi1O4H7RRm0YqlUNyp8TJg" authors="Claude Aubry" changeDate="2006-12-03T09:00:53.343+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Le backlog initial doit permettre de planifier au moins les 2 ou 3 premiers sprints.
+</p></keyConsiderations>
+ <sections xmi:id="_pWL_gAPJEdubhrgDuRb4fA" name="Collecter les éléments du backlog" guid="_pWL_gAPJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;établit une première liste des exigences (une
+ exigence&nbsp;devient un&nbsp;<a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>)&nbsp;qu'il souhaite voir réalisées pour la fin de la
+ release.
+</p>
+<p>
+ Pour compléter cette liste et obtenir un backlog suffisant, il est conseillé d'organiser un workshop réunissant toute
+ l'équipe plus des intervenants. Au cours de ce workshop, le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a>&nbsp;présente son ébauche de backlog et chacun intervient pour proposer de nouveaux items.
+</p>
+<p>
+ Il est fréquent qu'un élément du backlog soit identifié&nbsp;comme une histoire d'utilisateur (User story), technique
+ utilisée à l'origine dans EXtreme Programming (XP) et qui s'adapte très bien&nbsp;à Scrum.
+</p>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_u0Z7sAPJEdubhrgDuRb4fA" name="Ordonner le backlog" guid="_u0Z7sAPJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;ordonne les éléments du backlog selon une priorité
+ décroissante. Pour lui, A plus prioritaire que B signifie qu'il souhaite disposer, dans un produit partiel, de l'item A
+ avant l'item B.
+</p>
+<p>
+ Lorsque le backlog contient beaucoup d'éléments, le classement par priorité de chacun est fastidieux et délicat. C'est
+ pourquoi il est utile de définir des <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Theme,_aeYKoIKlEduQgtHqedKdMA.html"
+ guid="_aeYKoIKlEduQgtHqedKdMA">Thème</a>s, d'associer à&nbsp;chaque élément un thème et de définir les&nbsp;priorités
+ sur les thèmes avant de passer aux éléments. Cela peut être fait lors d'une réunion à laquelle participent les <a
+ class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>s, ainsi que des membres de l'équipe.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de produire un backlog au moins suffisant pour permettre le démarrage de la série des sprints.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Manage problems.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Manage problems.xmi
new file mode 100644
index 0000000..3cbc0ce
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Manage problems.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-mZfAV7RcWJlp5idlHzeEcA" name="Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A" guid="-mZfAV7RcWJlp5idlHzeEcA" changeDate="2006-12-03T10:05:51.734+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Cette tâche est centrée sur la résolution de ces problèmes.
+</p></keyConsiderations>
+ <sections xmi:id="_LCxqQAB6EduSVaTQTBfIHA" name="Prendre connaissance du problème" guid="_LCxqQAB6EduSVaTQTBfIHA">
+ <sectionDescription><p>
+ La réunion quotidienne est l'endroit idéal pour déceler les problèmes qu'une équipe rencontre. Elle peut même permettre
+ de les résoudre immédiatement grâce à la collaboration de l'équipe. Cependant :
+</p>
+<ul>
+ <li>
+ il arrive que des problèmes urgents soient soulevés entre 2 réunions quotidiennes
+ </li>
+ <li>
+ et surtout la résolution des problèmes n'est pas faite en réunion (sauf si elle évidente)
+ </li>
+</ul>
+<p>
+ Suite à la mise en évidence d'un problème, par exemple lors de la réunion quotidienne,&nbsp;identifier la cause du
+ problème et les impacts sur le projet. Pour cela une communication orale, à l'initiative&nbsp;du&nbsp;<a
+ class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>,&nbsp;avec la personne qui a soulevé le problème est souhaitable.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_PIKyUAB6EduSVaTQTBfIHA" name="Décider d'un plan d'action" guid="_PIKyUAB6EduSVaTQTBfIHA">
+ <sectionDescription><p>
+ Identifier les solutions possibles.<br />
+ Une réunion avec le responsable hiérarchique est organisée si des problèmes survenant sur le projet ne peuvent pas
+ être réglés simplement ou sont à un niveau au-dessus de son autorité.
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>&nbsp;doit s'efforcer de résoudre le problème au plus tôt, pour ne pas
+ perturber l'avancement de l'équipe.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de d'éliminer les problèmes rencontrés par l'équipe pour qu'elle puisse se concentrer sur ses véritables
+objectifs.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Plan release.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Plan release.xmi
new file mode 100644
index 0000000..6c78f3b
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Plan release.xmi
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-3f4axrWBKHGv74oKN2x-gQ" name="Plan release,_ho-aIP_BEdqtbrr0B1TG-A" guid="-3f4axrWBKHGv74oKN2x-gQ" changeDate="2006-12-03T09:23:18.328+0100" version="1.0.0">
+ <keyConsiderations>Il s'agit d'un travail collectif à l'initiative du directeur de produit.</keyConsiderations>
+ <sections xmi:id="_8qN08APJEdubhrgDuRb4fA" name="Définir les conditions de succès de la release" guid="_8qN08APJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il existe 2 types de releases&nbsp; :
+</p>
+<ul>
+ <li>
+ une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
+ une date fixée.
+ </li>
+ <li>
+ une release dirigée par les fonctionnalités. La liste des exigences est connue et la release prendra fin lorsque
+ toutes les exigences seront réalisées.
+ </li>
+</ul>
+<p>
+ Les conditions de succès sont définies en fonction de ce type de release.
+</p>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_BuXEQAPKEdubhrgDuRb4fA" name="Estimer les éléments du backlog" guid="_BuXEQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
+</p>
+<p>
+ L'estimation est réalisée en équipe.
+</p>
+<p>
+ La grandeur utilisée pour les estimations est de préférence le point, sans unités. Pour les valeurs utilisées pour les
+ estimations, on utilise souvent la suite de Fibonacci (1, 2, 3, 5, 8 et 13).
+</p>
+<p>
+ Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
+ de pratiquer le "planning poker" et de travailler par analogie en comparant les éléments estimés.&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_EaLKQAPKEdubhrgDuRb4fA" name="Définir la durée des sprints" guid="_EaLKQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Historiquement dans Scrum, la durée d'un sprint est de 30 jours. Cependant il est possible et même recommandé de faire
+ des sprints plus courts. La durée dépend du projet et des contraintes qui s'y appliquent.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_HDZ2UAPKEdubhrgDuRb4fA" name="Estimer la vélocité" guid="_HDZ2UAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;réelle. Elle sera alors utilisée pour cette release, éventuellement
+ ajustée compte tenu de la nature du projet. Attention cependant un point n'a pas forcément la même valeur dans des
+ projets différents.
+</p>
+<p>
+ Si ce n'est pas le cas, il faut faire une estimation de la vélocité. Le mieux est de travailler sur le contenu du
+ premier sprint de la release et de voir ce que l'équipe pense pouvoir réaliser pendant ce premier sprint. Cela donne
+ une vélocité estimée qui peut être utilisée pour la planification de la release. Ensuite la planification sera basée
+ sur la vélocité mesurée dans les sprints précédents.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_I71XkAPKEdubhrgDuRb4fA" name="Associer les éléments du backlog aux sprints" guid="_I71XkAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ En fonction des paramètres suivants :
+</p>
+<ul>
+ <li>
+ les estimations de chaque item,
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité),
+ </li>
+ <li>
+ la vélocité estimée pour la release,
+ </li>
+</ul>
+<p>
+ on affecte les items aux sprints de la release.
+</p>
+<p>
+ Il est normal d'ajuster, c'est à dire de changer légèrement l'ordre des items, ne serait-ce que pour se rapprocher le
+ plus possible de la vélocité (en effet on ne tombe pas toujours "rond").
+</p>
+<p>
+ Il faut associer des items aux premiers sprints (les 2 ou 3 premiers), mais il n'est pas indispensable de le faire pour
+ tous les sprints de la release.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ Elaborer la planification initiale de la release permettant de lancer la série de sprints.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Plan sprint 2.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Plan sprint 2.xmi
new file mode 100644
index 0000000..f745cf2
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Plan sprint 2.xmi
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-NRwwk6YGAtu25V3Lc04G6w" name="Plan sprint,_4LOggPpaEdqsc-f87sBK8A" guid="-NRwwk6YGAtu25V3Lc04G6w" authors="Claude Aubry" changeDate="2006-12-03T09:57:11.890+0100" version="1.0.0">
+ <keyConsiderations><p>
+ La réunion de planification de sprint est un travail réalisé en groupe.
+</p>
+<p>
+ Elle est limitée dans le temps :
+</p>
+<ul>
+ <li>
+ durée max : limitée à 4 heures
+ </li>
+ <li>
+ durée moyenne : 2 heures
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_TJNsUP--Edqtbrr0B1TG-A" name="Définir le but du sprint" guid="_TJNsUP--Edqtbrr0B1TG-A">
+ <sectionDescription><p>
+ Au début lors des premiers sprints de la première release d'un produit, le but est bien souvent de montrer la
+ faisabilité de l'architecture envisagée.
+</p>
+<p>
+ Ensuite, une fois que l'architecture est stabilisée, le but d'un sprint est proposé par le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a> et discuté avec l'équipe. Il porte souvent sur un thème fonctionnel.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xvy5UAPKEdubhrgDuRb4fA" name="Sélectionner les items" guid="_xvy5UAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il s'agit de définir le périmètre de ce sprint. Cela est fait en associant un <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;au sprint puis un autre en tenant compte de la
+ vélocité de l'équipe.
+</p>
+<p>
+ Si un <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;a été effectué, cette étape consiste seulement à valider
+ collectivement le sous-ensemble du backlog prévu pour ce sprint.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_p4C0sP--Edqtbrr0B1TG-A" name="Identifier les tâches à partir des items" guid="_p4C0sP--Edqtbrr0B1TG-A">
+ <sectionDescription><p>
+ La 2ème partie de la réunion a pour objectif de définir comment l’équipe va s’arranger pour réaliser le résultat
+ attendu du sprint.<br />
+ Pour cela, chaque <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;sélectionné est décomposé en tâches. Cela permet
+ à toute l’équipe de discuter et d’éclaircir des points de solution par rapport à cet item, en demandant si nécessaire
+ au propriétaire de produit des précisions sur le comportement du produit.<br />
+</p>
+<p>
+ Normalement l'ensemble des activités du cycle de vie sont déroulées lors d'un sprint :<br />
+</p>
+<ul>
+ <li>
+ Les exigences sélectionnées sont spécifiées
+ </li>
+ <li>
+ L'architecture est remaniée si nécessaire
+ </li>
+ <li>
+ Les classes et sous-systèmes sont conçus, implémentés et testés
+ </li>
+ <li>
+ Les différents composants sont intégrés et testés
+ </li>
+ <li>
+ Le produit est packagé&nbsp;
+ </li>
+ <li>
+ Les tests d'acceptation sont passés.<br />
+ </li>
+</ul>
+<p>
+ L'importance donnée à ces activités dépend de la place du sprint dans la release.<br />
+ <br />
+ Le travail prévu dans un sprint précédent mais qui n'a pu être réalisé à cause de la réduction des objectifs devient
+ prioritaire pour le sprint suivant.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_DxNQUAPLEdubhrgDuRb4fA" name="Estimer les tâches" guid="_DxNQUAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Les taches sont estimées en heures. Il est conseillé d'avoir des tâches suffisamment fines pour qu'une estimation reste
+ inférieure à 16 heures.
+</p>
+<p>
+ L'estimation est faite collectivement, par l'équipe. Au cours de la discussion pour arriver à une estimation, les
+ aspects techniques sont abordés.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_worbAP--Edqtbrr0B1TG-A" name="Attribuer les tâches" guid="_worbAP--Edqtbrr0B1TG-A">
+ <sectionDescription>Une fois que les activités du sprint ont été définies, elles seront affectées aux membres de l'équipe. Les activités
+peuvent être réalisées par une ou plusieurs personnes. Toutes les activités doivent être prises en compte, y compris les
+réunions de travail (hors réunions Scrum), les lectures de documents ou de code.<br />
+Il est préférable de différer l'affectation de certaines activités, qui seront prises pendant le sprint en fonction des
+disponibilités des membres de l'équipe.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Iq14wAPLEdubhrgDuRb4fA" name="Obtenir l'engagement de l'équipe" guid="_Iq14wAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il est souhaitable que l'équipe s'engage collectivement sur le backlog du sprint, c'est à dire sur les éléments du
+ backlog qu'elle estime pouvoir réaliser dans le sprint.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de planifier&nbsp;le sprint&nbsp;qui commence.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Retrospective.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Retrospective.xmi
new file mode 100644
index 0000000..243a584
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Retrospective.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-S4qXwp40l_8eCcyyI7o-3A" name="Retrospective,_J_sRIP_AEdqtbrr0B1TG-A" guid="-S4qXwp40l_8eCcyyI7o-3A" changeDate="2006-12-03T10:01:12.593+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé.
+</p>
+<ul>
+ <li>
+ durée max : 2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_lwzeABGPEduHloEV5-Zv-w" name="Discussion" guid="_lwzeABGPEduHloEV5-Zv-w">
+ <sectionDescription>Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé dans l'application de Scrum sur le
+projet.</sectionDescription>
+ </sections>
+ <sections xmi:id="_noL2YBGPEduHloEV5-Zv-w" name="Définir le plan d'actions" guid="_noL2YBGPEduHloEV5-Zv-w">
+ <sectionDescription><p>
+ L’équipe discute des améliorations possibles et leur donne une priorité.
+</p>
+<p>
+ Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a> ajoute les actions d’amélioration dans le backlog.
+</p></sectionDescription>
+ </sections>
+ <purpose>L’objectif est d'améliorer continuellement le processus.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Review sprint.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Review sprint.xmi
new file mode 100644
index 0000000..a63b191
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Review sprint.xmi
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-zoJryMCuHfxWP7Q5Er195Q" name="Review sprint,_MRrRYPpbEdqsc-f87sBK8A" guid="-zoJryMCuHfxWP7Q5Er195Q" changeDate="2006-12-03T09:52:13.953+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Travail en groupe (lors de la réunion dite de revue de sprint)
+</p>
+<p>
+ Pour la réunion :
+</p>
+<ul class="noindent">
+ <li>
+ durée max : &nbsp;2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_XL6VgAPLEdubhrgDuRb4fA" name="Préparer la démonstration" guid="_XL6VgAPLEdubhrgDuRb4fA">
+ <sectionDescription>La préparation de la réunion ne doit pas excéder une heure.<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_ZgJB8APLEdubhrgDuRb4fA" name="Effectuer la démonstration" guid="_ZgJB8APLEdubhrgDuRb4fA">
+ <sectionDescription>L’équipe présente le produit partiel résultat de ses travaux, sous forme de démonstration des exigences (histoires
+d'utilisateur) réalisées. Seules les exigences complètement finies (et testées) sont présentées. Cela permet d’avoir une
+mesure objective de l’avancement. <br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_cBouUAPLEdubhrgDuRb4fA" name="Evaluer les résultats du sprint" guid="_cBouUAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> et les intervenants présents (clients, utilisateurs) posent des
+ questions à l’équipe, donnent leur impression, font des propositions et des demandes de changement. Le <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;est enrichi avec les bugs découverts et les demandes
+ d’évolution.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_hrswoHoYEduJVrY6eKG_mw" name="Calculer la vélocité réelle" guid="_hrswoHoYEduJVrY6eKG_mw">
+ <sectionDescription><p>
+ La <a class="elementLink" href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;du sprint&nbsp;est obtenue en faisant la somme de tous les points
+ associés aux exigences considérées comme effectivement finies. Elle est comparée à celle des sprints précédents, le
+ plus souvent à travers un <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>.&nbsp;&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_d776UHoYEduJVrY6eKG_mw" name="Ajuster le plan de la release" guid="_d776UHoYEduJVrY6eKG_mw">
+ <sectionDescription><p>
+ Les conditions ont pu changer depuis la dernière planification de la release :
+</p>
+<ul>
+ <li>
+ des items ont pu être ajoutés ou suppirmés, les estimations modifiées,&nbsp;
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité) a pu être modifié,
+ </li>
+</ul>
+<p>
+ De plus la vélocité&nbsp;moyenne a pu évoluer avec la prise de la vélocité calculée du sprint.&nbsp;
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> est ajusté en tenant compte de ces nouveaux paramètres.
+</p></sectionDescription>
+ </sections>
+ <purpose>&nbsp;Le but est de montrer les exigences réalisées pendant le sprint par une démonstration du produit partiel</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Scrum daily meeting.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Scrum daily meeting.xmi
new file mode 100644
index 0000000..f9cd5b0
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Scrum daily meeting.xmi
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-vDOuVl_xPKipKd90HQNZng" name="Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A" guid="-vDOuVl_xPKipKd90HQNZng" changeDate="2006-12-03T10:07:26.890+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Se déroule tous les jours, avec toute l'équipe, de préférence le matin en arrivant : il est souhaitable que la réunion
+ ait lieu tous les jours au même endroit et à la même heure.
+</p>
+<p>
+ La réunion est limitée à 15 minutes.&nbsp;<br />
+ L’objectif est d’examiner l’avancement des travaux et d'identifier les problèmes potentiels, mais pas de résoudre les
+ problèmes
+</p></keyConsiderations>
+ <sections xmi:id="_oUrlcBGOEduHloEV5-Zv-w" name="Préparer" guid="_oUrlcBGOEduHloEV5-Zv-w">
+ <sectionDescription>Chacun met à jour le planning ( le backlog se sprint) en actualisant le reste à faire sur ses tâches, ce qui permet de
+produire un <a class="elementLink"
+href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>.</sectionDescription>
+ </sections>
+ <sections xmi:id="_r0KkEBGOEduHloEV5-Zv-w" name="Se réunir" guid="_r0KkEBGOEduHloEV5-Zv-w">
+ <sectionDescription><p>
+ Chaque membre de l’équipe s’exprime tour à tour, en répondant à 3 questions sur :
+</p>
+<ol>
+ <li>
+ Ce qui a été fait depuis la mêlée précédente (en principe la veille)
+ </li>
+ <li>
+ Ce qui va être fait aujourd’hui
+ </li>
+ <li>
+ Les problèmes rencontrés&nbsp;
+ </li>
+</ol>
+<p>
+ Il est souhaitable que la réunion s'effectue avec tous les personnes de l'équipe debout en cercle et en ayant sous les
+ yeux le <a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+ guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;et le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>&nbsp;actualisés.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_vZkkgBGOEduHloEV5-Zv-w" name="Consolider" guid="_vZkkgBGOEduHloEV5-Zv-w">
+ <sectionDescription>Le&nbsp;<a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;remis à jour sert à prendre une décision sur l'ajustement du but
+du sprint. Il faut avoir à l'esprit qu'un sprint est limité dans le temps (bloc de temps) et qu'il est préférable de
+supprimer du contenu prévu initialement plutôt que d'avoir du retard. <br />
+Les problèmes soulevés sont résolus&nbsp;lors de&nbsp;<a class="elementLink"
+href="./../../Scrum/tasks/Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A.html" guid="_Xpd5gP_AEdqtbrr0B1TG-A">Gérer les
+problèmes</a>&nbsp;à l'initiative du <a class="elementLink"
+href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html" guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>.</sectionDescription>
+ </sections>
+ <purpose>Le but est de faire le point sur l'avancement de l'équipe et d'identifier les problèmes. L’objectif est uniquement
+d’examiner l’avancement des travaux, pas de résoudre les problèmes.</purpose>
+ <alternatives><p>
+ Appelé aussi Stand-Up Meeting (XP)
+</p></alternatives>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/tasks/Update product backlog.xmi b/Scrum/Scrum_EN/library/Scrum/tasks/Update product backlog.xmi
new file mode 100644
index 0000000..af19cc7
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/tasks/Update product backlog.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-XdgedeazfFRGDxMY3Fnh5g" name="Manage product backlog,_STkWYP_BEdqtbrr0B1TG-A" guid="-XdgedeazfFRGDxMY3Fnh5g" changeDate="2006-12-03T09:12:31.968+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Pendant le sprint, personne ne peut modifier la sélection des items du backlog effectuée au début du sprint : le
+ périmètre du sprint reste inchangé.
+</p>
+<p>
+ En revanche, n’importe qui, même un intervenant extérieur, peut proposer de nouveaux items pour plus tard. Ces items
+ sont étudiés et ordonnés par le propriétaire du produit en vue de la planification du prochain sprint.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p></keyConsiderations>
+ <sections xmi:id="_c3HaQAPKEdubhrgDuRb4fA" name="Collecter les changements" guid="_c3HaQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ N’importe qui, même un intervenant extérieur, peut proposer des changements à ajouter au backlog.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p>
+<p>
+ Ces éléments sont analysés par le propriétaire du produit en vue de la planification du prochain sprint.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_fkXDoAPKEdubhrgDuRb4fA" name="Réordonner les items" guid="_fkXDoAPKEdubhrgDuRb4fA">
+ <sectionDescription>Les éléments ajoutés depuis le sprint précédent sont ordonnés dans le backlog par le&nbsp;<a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+en vue de la planification à venir.</sectionDescription>
+ </sections>
+ <sections xmi:id="_k-kCgAPKEdubhrgDuRb4fA" name="Réestimer les items" guid="_k-kCgAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'estimation en points des nouveaux éléments introduits dans le backlog est faite par l'équipe, de préférence lors d'un
+ travail de groupe avec le Directeur de prouit, un ou 2 jours avant la revue de fin de sprint.
+</p>
+<p>
+ Des items déjà présents peuvent également être réestimés.
+</p></sectionDescription>
+ </sections>
+ <purpose>Actualiser le backlog et ajuster la planification en tenant compte des changements apparus depuis le dernier sprint.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducts/Product Backlog Item.xmi b/Scrum/Scrum_EN/library/Scrum/workproducts/Product Backlog Item.xmi
new file mode 100644
index 0000000..adf4810
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducts/Product Backlog Item.xmi
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" name="new_artifact,_-D85cIGIEduKE9hnyImx1Q" guid="-KC1R73i9f6P7ZT4pgBOLzA" changeDate="2006-12-01T23:15:03.002+0100">
+ <mainDescription>C'est une exigence fonctionnelle ou non fonctionnelle (technique), une demande d'évolution, un bug ou tout autre
+chose&nbsp;dont la réalisation apporte de la valeur au <a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+Produit</a>.&nbsp;
+<p>
+ Il possède des attributs qui sont généralement :
+</p>
+<ul>
+ <li>
+ une estimation de sa valeur qui est le plus souvent montrée de façon relative aux autres éléments par la notion de
+ priorité,
+ </li>
+ <li>
+ une estimation de son coût de développement,
+ </li>
+ <li>
+ éventuellement le thème (domaine fonctionnel) dont il fait partie,
+ </li>
+ <li>
+ éventuellement son type (défini en fonction du projet, par exemple histoire d'utilisateur, bug, exigence non
+ fonctionnelle),
+ </li>
+</ul>
+<p>
+ Si on utilise la technique des histoires d'utilisateur (user stories) et le développement dirigé par les tests (TDD),
+ on associe les critères servant aux tests d'acceptation de cet élément.
+</p>
+<p>
+ La vie d'un PBI passe par les états suivants :
+</p>
+<ul class="noindent">
+ <li>
+ créé
+ </li>
+ <li>
+ estimé
+ </li>
+ <li>
+ planifié (associé à un&nbsp;sprint futur
+ </li>
+ <li>
+ associé au sprint courant (on le réalise)
+ </li>
+ <li>
+ réalisé
+ </li>
+ <li style="list-style: none">
+ <br />
+ </li>
+</ul></mainDescription>
+ <keyConsiderations>Le principe de Scrum est de finir complètement un PBI dans un sprint.</keyConsiderations>
+ <externalId>PBI</externalId>
+ <purpose>Sert à la gestion de projet : il sera placé dans un sprint</purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducts/Product Backlog.xmi b/Scrum/Scrum_EN/library/Scrum/workproducts/Product Backlog.xmi
new file mode 100644
index 0000000..4d8cb72
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducts/Product Backlog.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" name="Product Backlog,_5ABscPpYEdqsc-f87sBK8A" guid="-Of1SdnAQ9nmsL5DFvD2Uug" authors="Claude AUbry" changeDate="2006-12-03T09:31:43.140+0100" version="1.0.0">
+ <mainDescription><p>
+ Le backlog du produit est le référentiel des exigences. Il contient des éléments du backlog (appelés aussi des items de
+ backlog de produit).
+</p>
+<p>
+ Sa vie est liée à celle du produit.
+</p></mainDescription>
+ <purpose>Lister toutes les choses à faire&nbsp;du point de vue du client (le quoi)</purpose>
+ <impactOfNotHaving>Obligatoire</impactOfNotHaving>
+ <briefOutline>Visible par tous, il est mis à jour régulièrement. Il est présenté à la revue de planification du sprint et, une fois
+accepté, la partie contenant les exigences allouées au sprint courant est gelée.</briefOutline>
+ <representationOptions><ul>
+ <li>
+ Cartes (story cards)
+ </li>
+ <li>
+ Feuille d'un tableur
+ </li>
+ <li>
+ Outil IceScrum&nbsp;
+ </li>
+ <li>
+ Base de données
+ </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducts/Product increment.xmi b/Scrum/Scrum_EN/library/Scrum/workproducts/Product increment.xmi
new file mode 100644
index 0000000..bc47bed
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducts/Product increment.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-6aCUL_kawJFNBtfH_sRXkw" name="Product increment,_tCmYEP-xEdqLnajTSLeAsA" guid="-6aCUL_kawJFNBtfH_sRXkw" changeDate="2006-12-03T10:04:18.218+0100" version="1.0.0">
+ <mainDescription><p>
+ Le résultat principal d'un sprint est le produit partiel qui réalise, en plus de ce qui existait au début du
+ sprint,&nbsp;les exigences supplémentaires réalisées pendant ce sprint.
+</p>
+<p>
+ On peut&nbsp;trouver 3 utilisations -après la démonstration lors de la revue de sprintes- du produit partiel obtenu en
+ fin d'itération&nbsp;:
+</p>
+<ul>
+ <li>
+ il n'est pas utilisé en dehors de l'équipe. Il a été produit pour chercher à minimiser les risques liés à la
+ technologie et à la capacité de l'équipe à intégrer pour produire un <q>build</q>. Cela arrive surtout au début
+ d'un nouveau produit.
+ </li>
+ <li>
+ il est utilisé par des clients privilégiés, en plus du directeur produit. Cela leur donne la possibilité de jouer
+ avec, ce qui permet de réduire les risques portant sur l'IHM liées à la facilité d'utilisation des fonctionnalités.
+ Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
+ </li>
+ <li>
+ il est mis en production ou en exploitation et utilisé par ses utilisateurs finals. C'est évidemment ce qu'il faut
+ viser puisque chaque nouvelle version apporte de la valeur. Autant l'apporter le plus tôt possible, dès qu'elle est
+ disponible. Mais ce n'est généralement pas possible de mettre en production à la fin de chaque sprint : trop de
+ temps serait pris pour passer les tests de recette sur tout le système, déployer sur l'environnement de production,
+ écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs... C'est pourquoi ce travail
+ particulier nécessite souvent une activité de préparation à la mise en production. Mais si on réussit à limiter le
+ temps pour faire tout ça, on peut alors mettre en production plus souvent qu'à la fin des releases.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><p>
+ Le produit évolue pendant toute sa vie jusqu'à son retrait.
+</p></keyConsiderations>
+ <briefOutline>Le produit partiel peut être déployé dans l'environnement de production&nbsp;ou simplement mis à disposition des
+utilisateurs.</briefOutline>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducts/Sprint Backlog Item.xmi b/Scrum/Scrum_EN/library/Scrum/workproducts/Sprint Backlog Item.xmi
new file mode 100644
index 0000000..1f7bd5b
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducts/Sprint Backlog Item.xmi
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" name="new_artifact,_9C78MIHnEdu3SZQ-Dp1OAA" guid="-6UJtuFO3WFBFpJOFeV1QMQ" changeDate="2006-12-02T10:38:33.140+0100">
+ <mainDescription><p>
+ Chaque tâche possède les attributs suivants :
+</p>
+<ul>
+ <li>
+ l'estimation du temps à passer pour finir la tâche. Les efforts sont estimés, par l’équipe, en heures sur une
+ échelle qui varie habituellement de 1à 16 heures. Les tâches plus grandes devraient être décomposées. L’estimation
+ du reste à faire est réactualisée tous les jours.
+ </li>
+ <li>
+ l'<a class="elementLink" href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;à l'origine de cette tâche
+ </li>
+ <li>
+ la personne qui prend en compte cette tâche<br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducts/Sprint backlog.xmi b/Scrum/Scrum_EN/library/Scrum/workproducts/Sprint backlog.xmi
new file mode 100644
index 0000000..da5b496
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducts/Sprint backlog.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" name="Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A" guid="-8V2DOvzUhvtqwWvTOHMB5g" changeDate="2006-12-03T10:17:45.781+0100" version="1.0.0">
+ <mainDescription><p>
+ Il&nbsp;contient la liste des tâches que l’équipe s’engage à faire afin de compléter les éléments de backlog de produit
+ sélectionnés pour ce sprint.<br />
+ L’équipe peut modifier une tâche, la supprimer ou en ajouter de nouvelles : il est courant que des tâches apparaissent
+ lors du sprint.
+</p></mainDescription>
+ <purpose>Il&nbsp;décrit l'ensemble des&nbsp;tâches d'un sprint, avec les ressources qui y sont affectées et le travail qui reste à
+faire. C'est un plan qui porte sur des tâches détaillées, il est dit à "mailles fines".</purpose>
+ <impactOfNotHaving>Obligatoire</impactOfNotHaving>
+ <briefOutline><p>
+ C'est un outil de communication essentiel qui aide à gérer le sprint. Il doit être facilement mis à jour et rester
+ visible à toute l'équipe.
+</p></briefOutline>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducts/resources/EtatsPBI.jpg b/Scrum/Scrum_EN/library/Scrum/workproducts/resources/EtatsPBI.jpg
new file mode 100644
index 0000000..4e1e28f
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducts/resources/EtatsPBI.jpg
Binary files differ
diff --git a/Scrum/Scrum_EN/library/Scrum/workproducttypes/Backlogs.xmi b/Scrum/Scrum_EN/library/Scrum/workproducttypes/Backlogs.xmi
new file mode 100644
index 0000000..67ae2e4
--- /dev/null
+++ b/Scrum/Scrum_EN/library/Scrum/workproducttypes/Backlogs.xmi
@@ -0,0 +1,15 @@
+<?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="-eSc2tcV1h17HBw_s8ROEVw" name="Backlogs,_d-yk8ABREdu3o4yroaI-tA" guid="-eSc2tcV1h17HBw_s8ROEVw" changeDate="2006-06-22T22:06:50.327+0200">
+ <mainDescription><p>
+ Les backlogs de Produit et de Sprint sont des éléments de gestion majeurs dans l'utilisation de Scrum.
+</p>
+<p>
+ A partir des backlogs, on produit des rapports comme le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>&nbsp;ou le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>
+</p></mainDescription>
+ <keyConsiderations>Un backlog est une liste d'items. Le terme n'est pas traduit en français car il est couramment utilisé dans la communauté
+des développeurs.</keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_EN/library/configurations/Scrum.xmi b/Scrum/Scrum_EN/library/configurations/Scrum.xmi
new file mode 100644
index 0000000..4575445
--- /dev/null
+++ b/Scrum/Scrum_EN/library/configurations/Scrum.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:MethodConfiguration xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_IqDLgP_OEdqtbrr0B1TG-A" name="Scrum" guid="_IqDLgP_OEdqtbrr0B1TG-A" briefDescription="Le processus Scrum" version="1.0.0">
+ <methodPluginSelection href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eofpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eovpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eo_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ep_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ervpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epvpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3er_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqvpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_rkSgEPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_SqGkoABREdu3o4yroaI-tA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_37NW8AL_EduOAKqB9I73uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_NSW6sAMAEduOAKqB9I73uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_SoXWEAMAEduOAKqB9I73uw"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_s8y1UABREdu3o4yroaI-tA"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_nF6fgALYEduFv7wnrO7SvQ"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_7BSBkABCEduYUKPFgCzFuA"/>
+</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/Scrum/Scrum_EN/library/library.xmi b/Scrum/Scrum_EN/library/library.xmi
new file mode 100644
index 0000000..16d6058
--- /dev/null
+++ b/Scrum/Scrum_EN/library/library.xmi
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_hDRYYfpYEdqsc-f87sBK8A" guid="_hDRYYfpYEdqsc-f87sBK8A">
+ <subManagers xmi:id="_5AUAUPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5AUAUPpYEdqsc-f87sBK8A"/>
+ <resourceDescriptors xmi:id="_hDRYYvpYEdqsc-f87sBK8A" id="_hDRYYPpYEdqsc-f87sBK8A" uri=""/>
+ <resourceDescriptors xmi:id="_mRDr4PpYEdqsc-f87sBK8A" id="_mQ3eoPpYEdqsc-f87sBK8A" uri="Scrum/plugin.xmi"/>
+ <resourceDescriptors xmi:id="_VRheAYPTEdu0eqo2Hxw7OA" id="_VRheAIPTEdu0eqo2Hxw7OA" uri="IceScrum/plugin.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodLibrary xmi:id="_hDRYYPpYEdqsc-f87sBK8A" name="scrum" guid="_hDRYYPpYEdqsc-f87sBK8A">
+ <methodPlugins xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
+ </org.eclipse.epf.uma:MethodLibrary>
+</xmi:XMI>
diff --git a/Scrum/Scrum_PT/HTML_to_be_imported/temp b/Scrum/Scrum_PT/HTML_to_be_imported/temp
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/Scrum/Scrum_PT/HTML_to_be_imported/temp
diff --git a/Scrum/Scrum_PT/library/Scrum/about.html b/Scrum/Scrum_PT/library/Scrum/about.html
new file mode 100644
index 0000000..6040025
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/about.html
@@ -0,0 +1,9 @@
+
+<span style="font-weight: bold; font-family: Arial Narrow;">Claude Aubry</span><br/>
+<span style="font-weight: bold; color: rgb(255, 102, 0); font-family: Arial Narrow;">Consultant Méthodes Agiles</span><span style="font-family: Arial Narrow;">
+</span>
+<br/><small style="font-family: Arial Narrow;">
+<span style="color: rgb(102, 102, 102);">Mobile : 06 60 646 946</span>
+<br/>
+<a href="http://scrum.aubryconseil.com">Blog</a> -
+<a href="http://www.aubryconseil.com/">Web</a>
\ No newline at end of file
diff --git a/Scrum/Scrum_PT/library/Scrum/customcategories/Intro.xmi b/Scrum/Scrum_PT/library/Scrum/customcategories/Intro.xmi
new file mode 100644
index 0000000..aa49ac4
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/customcategories/Intro.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-juIDa_fXi2K1BE5NTblPow" name="new_custom_category,_s8y1UABREdu3o4yroaI-tA" guid="-juIDa_fXi2K1BE5NTblPow" changeDate="2006-12-04T21:46:12.515+0100">
+ <mainDescription>Ce site décrit l'utilisation de Scrum</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/customcategories/Scrum Elements.xmi b/Scrum/Scrum_PT/library/Scrum/customcategories/Scrum Elements.xmi
new file mode 100644
index 0000000..35e8dc5
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/customcategories/Scrum Elements.xmi
@@ -0,0 +1,2 @@
+<?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="-zS9h38tmK4L-U9kbgkpGKQ" name="Eléments de Scrum,_nF6fgALYEduFv7wnrO7SvQ" guid="-zS9h38tmK4L-U9kbgkpGKQ" changeDate="2006-07-16T15:44:25.338+0200"/>
diff --git a/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/Scrum/content.xmi b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/Scrum/content.xmi
new file mode 100644
index 0000000..c97db24
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/Scrum/content.xmi
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" epf:version="1.0.0">
+ <org.eclipse.epf.uma:DeliveryProcessDescription xmi:id="-16dzhVoCex78V2iCDZVx0w" name="Scrum,_9llsAQAvEdubGMceRDupFQ" guid="-16dzhVoCex78V2iCDZVx0w">
+ <mainDescription>La production d’une version du logiciel (<a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>) se fait en général en quelques mois. Les fonctionnalités demandées pour la
+release sont collectées dans le backlog de produit et classées par priorité. Le directeur de produit est responsable de
+l’insertion des changements dans ce backlog.&nbsp; <br />
+La release est produite par une série d’itérations de 2 à 4 semaines appelées des <a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s. Le contenu d’un Sprint est défini par l’équipe avec le propriétaire de produit,
+en tenant compte des priorités et de la capacité de l’équipe. L’équipe définit les tâches nécessaires pour réaliser les
+fonctionnalités sélectionnées pour le Sprint.&nbsp; <br />
+Pendant un sprint, des points de contrôle sur l’avancement sont effectués lors des mêlées quotidiennes. Cela permet au
+ScrumMaster de déterminer l’avancement par rapport aux engagements du Sprint et de conseiller des ajustements pour assurer
+le succès du Sprint.&nbsp; <br />
+A la fin de chaque Sprint, l’équipe produit un <a class="elementLink"
+href="./../../Scrum/workproducts/Product increment,_tCmYEP-xEdqLnajTSLeAsA.html" guid="_tCmYEP-xEdqLnajTSLeAsA">Incrément
+de produit</a>&nbsp;potentiellement utilisable, dont l’évaluation permet d’ajuster le backlog pour le Sprint suivant.</mainDescription>
+ <keyConsiderations><p>
+ Scrum contribue à renforcer l’esprit d’équipe dans les projets,&nbsp; avec une collection de pratiques proches de
+ celles que l’on trouve dans des sports collectifs en particulier le rugby.
+</p>
+<br />
+<br /></keyConsiderations>
+ <purpose>.</purpose>
+ <howtoStaff>Une équipe Scrum est composée de 3 à 10 personnes.</howtoStaff>
+ <scope>Scrum ne décrit pas toutes les disciplines du développement de logiciel (analyse, conception, codage, test) et doit être
+considéré, plutôt qu’un processus complet, comme un pattern de processus qui est à utiliser pour la gestion de projet et la
+gestion des exigences. <br />
+Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement.</scope>
+ <estimatingTechnique><p>
+ Il est conseillé de pratiquer une estimation basée sur les points (story points), associés aux éléments du backlog.
+</p></estimatingTechnique>
+ </org.eclipse.epf.uma:DeliveryProcessDescription>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" name="Phase de préparation,_37TdkAL_EduOAKqB9I73uw" guid="-WiMYK8iwLeOO-sSBRBjbNQ">
+ <mainDescription><p>
+ Scrum ne prend pas en compte tous les aspects de préparation d'un projet. Seules sont présentées les taches spécifiques
+ de Scrum plus une qui regroupe tous les travaux pouvant etre réalisés
+</p></mainDescription>
+ </org.eclipse.epf.uma:ActivityDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" name="Travaux quotidiens,_nXmKUANlEduYd-55D-Aiqg" guid="-EpBaHVCIYCqqGX_wv7dlYA">
+ <refinedDescription>Scrum ne propose rien pour la réalisation de ces tâches techniques de conception, codage et test mais se conjugue bien avec
+l’utilisation des techniques XP (binômage, développement dirigé par les tests…). <br />
+Les tâches ne sont pas assignées par le ScrumMaster mais choisies par les membres de l’équipe au fur et à mesure. <br />
+L’équipe met à jour, chaque fois que c’est nécessaire, l’estimation du reste à faire sur les tâches du <br />
+backlog du sprint.</refinedDescription>
+ </org.eclipse.epf.uma:DescriptorDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" name="Sprint de release,_zbM2QIGBEduKE9hnyImx1Q" guid="-EOwIzNPjfNIjzJ3TRAgeWQ">
+ <keyConsiderations>Essayer de ne pas modifier de code lors du dernier sprint, c'est trop tard et risqué.</keyConsiderations>
+ <usageGuidance>Il est optionnel. Cela dépend de la façon dont le produit est mis à disposition de ses utilisateurs finals. On en devrait
+dérouler ce sprint optionnel que des travaux qu'il est impossible de faire avant, dans les sprints "normaux".</usageGuidance>
+ <refinedDescription><p>
+ Les tâches effectuées pendant ce sprint dépendent fortement du type de déploiement du logiciel.
+</p>
+<p>
+ On peut y trouver des travaux portant sur :
+</p>
+<ul>
+ <li>
+ mise en production à chaud,
+ </li>
+ <li>
+ packaging du produit,
+ </li>
+ <li>
+ mise à disposition par téléchargement en ligne,
+ </li>
+ <li>
+ documentation technique,
+ </li>
+ <li>
+ formation des utilisateurs,
+ </li>
+ <li>
+ marketing du produit.
+ </li>
+</ul></refinedDescription>
+ </org.eclipse.epf.uma:DescriptorDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" name="Sprint backlog,_glbG2wMAEduOAKqB9I73uw" guid="-MupkaQeHNEmiF7Lnl3VirQ">
+ <usageGuidance>Un par sprint</usageGuidance>
+ </org.eclipse.epf.uma:DescriptorDescription>
+</xmi:XMI>
diff --git a/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/Scrum/model.xmi b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/Scrum/model.xmi
new file mode 100644
index 0000000..eafcf7c
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/Scrum/model.xmi
@@ -0,0 +1,982 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_9m1CIAAvEdubGMceRDupFQ" guid="_9m1CIAAvEdubGMceRDupFQ">
+ <resourceDescriptors xmi:id="_9m1CIQAvEdubGMceRDupFQ" id="-16dzhVoCex78V2iCDZVx0w" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_-d2LQQMEEduOAKqB9I73uw" id="-WiMYK8iwLeOO-sSBRBjbNQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_8N5DwANlEduYd-55D-Aiqg" id="-EpBaHVCIYCqqGX_wv7dlYA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_iCOP4IGPEduKE9hnyImx1Q" id="-EOwIzNPjfNIjzJ3TRAgeWQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_tObbkLPBEduk5O8SjA21Fg" id="-MupkaQeHNEmiF7Lnl3VirQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_9llsAAAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAAAvEdubGMceRDupFQ">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_37NW8AL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37NW8AL_EduOAKqB9I73uw">
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_37TdkAL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37TdkAL_EduOAKqB9I73uw" briefDescription="Cette phase initiale permet de préparer tout ce qui est nécessaire avant de commencer la série des sprints" presentationName="Phase de préparation" isOptional="true" superActivities="_9llsAQAvEdubGMceRDupFQ" breakdownElements="_zYT-EQMAEduOAKqB9I73uw _zYaEsAMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw _zYaEswMAEduOAKqB9I73uw _zYaEtAMAEduOAKqB9I73uw _7FGsMANkEduYd-55D-Aiqg _7FGsMQNkEduYd-55D-Aiqg _O6XmcANlEduYd-55D-Aiqg">
+ <presentation xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-WiMYK8iwLeOO-sSBRBjbNQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zYT-EQMAEduOAKqB9I73uw" name="Plan release" guid="_zYT-EQMAEduOAKqB9I73uw" presentationName="Planifier la release" superActivities="_37TdkAL_EduOAKqB9I73uw" linkToPredecessor="_2vOSsAMEEduOAKqB9I73uw _MEJPgAPOEdubhrgDuRb4fA _MEPWIAPOEdubhrgDuRb4fA" additionallyPerformedBy="_zYaEswMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw" mandatoryInput="_zYaEtAMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ho-aIP_BEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_8qN08APJEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_BuXEQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_EaLKQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_HDZ2UAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_I71XkAPKEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsAMAEduOAKqB9I73uw" name="Product Owner" guid="_zYaEsAMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_37TdkAL_EduOAKqB9I73uw" responsibleFor="_zYaEtAMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsgMAEduOAKqB9I73uw" name="Team" guid="_zYaEsgMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEswMAEduOAKqB9I73uw" name="ScrumMaster" guid="_zYaEswMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_zYaEtAMAEduOAKqB9I73uw" name="Product Backlog" guid="_zYaEtAMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_2vOSsAMEEduOAKqB9I73uw" guid="_2vOSsAMEEduOAKqB9I73uw" linkType="finishToFinish"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_7FGsMANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_7FGsMANkEduYd-55D-Aiqg" presentationName="Produire le backlog de produit initial" superActivities="_37TdkAL_EduOAKqB9I73uw" additionallyPerformedBy="_7FGsMQNkEduYd-55D-Aiqg _zYaEsgMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_BGFMoANkEduYd-55D-Aiqg"/>
+ <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_pWL_gAPJEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_u0Z7sAPJEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_7FGsMQNkEduYd-55D-Aiqg" name="StakeHolder" guid="_7FGsMQNkEduYd-55D-Aiqg" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_O6XmcANlEduYd-55D-Aiqg" name="Preparation work" guid="_O6XmcANlEduYd-55D-Aiqg" presentationName="Travaux de préparation" isPlanned="true" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw" performedPrimarilyBy="_zYaEsgMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEJPgAPOEdubhrgDuRb4fA" guid="_MEJPgAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_7FGsMANkEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEPWIAPOEdubhrgDuRb4fA" guid="_MEPWIAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_O6XmcANlEduYd-55D-Aiqg"/>
+ <diagrams xmi:id="_y9sh0AMEEduOAKqB9I73uw" guid="_y9sh0AMEEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yocAMEEduOAKqB9I73uw" guid="_y9yocAMEEduOAKqB9I73uw">
+ <position xmi:id="_y9yocQMEEduOAKqB9I73uw" x="84.0" y="34.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2vIMEQMEEduOAKqB9I73uw" guid="_2vIMEQMEEduOAKqB9I73uw" anchor="_2vIMEAMEEduOAKqB9I73uw _2vIMEgMEEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vOSsQMEEduOAKqB9I73uw" guid="_2vOSsQMEEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_2QAAEgMEEduOAKqB9I73uw" guid="_2QAAEgMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_2vIMEAMEEduOAKqB9I73uw" guid="_2vIMEAMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw">
+ <position xmi:id="_2vIMEwMEEduOAKqB9I73uw" x="155.0" y="50.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yocgMEEduOAKqB9I73uw" guid="_y9yocgMEEduOAKqB9I73uw"/>
+ <size xmi:id="_y9yocwMEEduOAKqB9I73uw" width="130.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yodAMEEduOAKqB9I73uw" guid="_y9yodAMEEduOAKqB9I73uw">
+ <position xmi:id="_y9yodQMEEduOAKqB9I73uw" x="158.0" y="214.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nqi5YYGGEduKE9hnyImx1Q" guid="_nqi5YYGGEduKE9hnyImx1Q" anchor="_nqi5YIGGEduKE9hnyImx1Q _nqi5YoGGEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_2vIMEgMEEduOAKqB9I73uw" guid="_2vIMEgMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_MEDI4gPOEdubhrgDuRb4fA" guid="_MEDI4gPOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_nqi5YIGGEduKE9hnyImx1Q" guid="_nqi5YIGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q">
+ <position xmi:id="_nqi5Y4GGEduKE9hnyImx1Q" x="171.0" y="228.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yodgMEEduOAKqB9I73uw" guid="_y9yodgMEEduOAKqB9I73uw" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_y9yodwMEEduOAKqB9I73uw" width="88.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_03XZMAMEEduOAKqB9I73uw" guid="_03XZMAMEEduOAKqB9I73uw">
+ <position xmi:id="_03XZMQMEEduOAKqB9I73uw" x="187.0" y="-6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2QAAEQMEEduOAKqB9I73uw" guid="_2QAAEQMEEduOAKqB9I73uw" anchor="_2QAAEAMEEduOAKqB9I73uw _2QAAEgMEEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-h0qsQNkEduYd-55D-Aiqg" guid="_-h0qsQNkEduYd-55D-Aiqg" anchor="_-h0qsANkEduYd-55D-Aiqg _-h0qsgNkEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_2QAAEAMEEduOAKqB9I73uw" guid="_2QAAEAMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw">
+ <position xmi:id="_2QAAEwMEEduOAKqB9I73uw" x="58.0" y="51.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-h0qsANkEduYd-55D-Aiqg" guid="_-h0qsANkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
+ <position xmi:id="_-h6xUANkEduYd-55D-Aiqg" x="62.0" y="51.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_03XZMgMEEduOAKqB9I73uw" guid="_03XZMgMEEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_03XZMwMEEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8cZ2UANkEduYd-55D-Aiqg" guid="_8cZ2UANkEduYd-55D-Aiqg">
+ <position xmi:id="_8cZ2UQNkEduYd-55D-Aiqg" x="14.0" y="94.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LDfDwQPOEdubhrgDuRb4fA" guid="_LDfDwQPOEdubhrgDuRb4fA" anchor="_LDfDwAPOEdubhrgDuRb4fA _LDfDwgPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_4JEBIgPNEdubhrgDuRb4fA" guid="_4JEBIgPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LDfDwAPOEdubhrgDuRb4fA" guid="_LDfDwAPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LDfDwwPOEdubhrgDuRb4fA" x="114.0" y="145.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8cZ2UgNkEduYd-55D-Aiqg" guid="_8cZ2UgNkEduYd-55D-Aiqg" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_8cZ2UwNkEduYd-55D-Aiqg" width="168.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_n_DhAANnEduYd-55D-Aiqg" guid="_n_DhAANnEduYd-55D-Aiqg">
+ <position xmi:id="_n_DhAQNnEduYd-55D-Aiqg" x="255.0" y="90.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LgIjgQPOEdubhrgDuRb4fA" guid="_LgIjgQPOEdubhrgDuRb4fA" anchor="_LgIjgAPOEdubhrgDuRb4fA _LgIjggPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_114dkgPNEdubhrgDuRb4fA" guid="_114dkgPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LgIjgAPOEdubhrgDuRb4fA" guid="_LgIjgAPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LgIjgwPOEdubhrgDuRb4fA" x="282.0" y="140.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_n_DhAgNnEduYd-55D-Aiqg" guid="_n_DhAgNnEduYd-55D-Aiqg" element="_O6XmcANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_n_DhAwNnEduYd-55D-Aiqg" width="113.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nITO0APNEdubhrgDuRb4fA" guid="_nITO0APNEdubhrgDuRb4fA">
+ <position xmi:id="_nITO0QPNEdubhrgDuRb4fA" x="162.0" y="55.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_114dkQPNEdubhrgDuRb4fA" guid="_114dkQPNEdubhrgDuRb4fA" anchor="_114dkAPNEdubhrgDuRb4fA _114dkgPNEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_4JEBIQPNEdubhrgDuRb4fA" guid="_4JEBIQPNEdubhrgDuRb4fA" anchor="_4JEBIAPNEdubhrgDuRb4fA _4JEBIgPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-h0qsgNkEduYd-55D-Aiqg" guid="_-h0qsgNkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
+ <position xmi:id="_Ip2OIFGGEduRlKB2-_Ejlg" x="36.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_114dkAPNEdubhrgDuRb4fA" guid="_114dkAPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA">
+ <position xmi:id="_114dkwPNEdubhrgDuRb4fA" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_4JEBIAPNEdubhrgDuRb4fA" guid="_4JEBIAPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA">
+ <position xmi:id="_HPd_kAPOEdubhrgDuRb4fA" x="17.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nITO0gPNEdubhrgDuRb4fA" guid="_nITO0gPNEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nITO0wPNEdubhrgDuRb4fA" width="81.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_J5FtMAPOEdubhrgDuRb4fA" guid="_J5FtMAPOEdubhrgDuRb4fA">
+ <position xmi:id="_J5FtMQPOEdubhrgDuRb4fA" x="152.0" y="171.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MEDI4QPOEdubhrgDuRb4fA" guid="_MEDI4QPOEdubhrgDuRb4fA" anchor="_MEDI4APOEdubhrgDuRb4fA _MEDI4gPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LDfDwgPOEdubhrgDuRb4fA" guid="_LDfDwgPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LDfDxAPOEdubhrgDuRb4fA" x="42.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_LgIjggPOEdubhrgDuRb4fA" guid="_LgIjggPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LgIjhAPOEdubhrgDuRb4fA" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MEDI4APOEdubhrgDuRb4fA" guid="_MEDI4APOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA">
+ <position xmi:id="_MJgy8FGGEduRlKB2-_Ejlg" x="49.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_J5FtMgPOEdubhrgDuRb4fA" guid="_J5FtMgPOEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_J5FtMwPOEdubhrgDuRb4fA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mMXrMIGGEduKE9hnyImx1Q" guid="_mMXrMIGGEduKE9hnyImx1Q">
+ <position xmi:id="_mMXrMYGGEduKE9hnyImx1Q" x="190.0" y="282.0"/>
+ <anchorage xmi:id="_nqi5YoGGEduKE9hnyImx1Q" guid="_nqi5YoGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mMXrMoGGEduKE9hnyImx1Q" guid="_mMXrMoGGEduKE9hnyImx1Q" typeInfo="end node"/>
+ <size xmi:id="_mMXrM4GGEduKE9hnyImx1Q" width="24.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9sh0QMEEduOAKqB9I73uw" guid="_y9sh0QMEEduOAKqB9I73uw" presentation="Workflow" element="_37TdkAL_EduOAKqB9I73uw"/>
+ </diagrams>
+ <diagrams xmi:id="_jcymYAPNEdubhrgDuRb4fA" guid="_jcymYAPNEdubhrgDuRb4fA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymYQPNEdubhrgDuRb4fA" guid="_jcymYQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymYgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznBIGMEduKE9hnyImx1Q" guid="_5oznBIGMEduKE9hnyImx1Q" anchor="_5oznA4GMEduKE9hnyImx1Q _5oznBYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeNIGMEduKE9hnyImx1Q" guid="_5uBeNIGMEduKE9hnyImx1Q" anchor="_5uBeM4GMEduKE9hnyImx1Q _5uBeNYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQxLKjEdudsfcMCYa15A" guid="_03qQxLKjEdudsfcMCYa15A" anchor="_03qQw7KjEdudsfcMCYa15A _03qQxbKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_5oznAoGMEduKE9hnyImx1Q" guid="_5oznAoGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5oznA4GMEduKE9hnyImx1Q" guid="_5oznA4GMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeMoGMEduKE9hnyImx1Q" guid="_5uBeMoGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeM4GMEduKE9hnyImx1Q" guid="_5uBeM4GMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQwrKjEdudsfcMCYa15A" guid="_03qQwrKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_03qQw7KjEdudsfcMCYa15A" guid="_03qQw7KjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymYwPNEdubhrgDuRb4fA" guid="_jcymYwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymZAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymZQPNEdubhrgDuRb4fA" guid="_jcymZQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymZgPNEdubhrgDuRb4fA" x="30.0" y="88.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymZwPNEdubhrgDuRb4fA" guid="_jcymZwPNEdubhrgDuRb4fA" element="_zYaEsAMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymaAPNEdubhrgDuRb4fA" width="316.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymaQPNEdubhrgDuRb4fA" guid="_jcymaQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymagPNEdubhrgDuRb4fA" x="30.0" y="283.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymawPNEdubhrgDuRb4fA" guid="_jcymawPNEdubhrgDuRb4fA" element="_zYaEsgMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymbAPNEdubhrgDuRb4fA" width="239.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymbQPNEdubhrgDuRb4fA" guid="_jcymbQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymbgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymbwPNEdubhrgDuRb4fA" guid="_jcymbwPNEdubhrgDuRb4fA" element="_zYaEswMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymcAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymcQPNEdubhrgDuRb4fA" guid="_jcymcQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymcgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymcwPNEdubhrgDuRb4fA" guid="_jcymcwPNEdubhrgDuRb4fA" element="_zYaEtAMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymdAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymdQPNEdubhrgDuRb4fA" guid="_jcymdQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymdgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznB4GMEduKE9hnyImx1Q" guid="_5oznB4GMEduKE9hnyImx1Q" anchor="_5oznBoGMEduKE9hnyImx1Q _5oznCIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeN4GMEduKE9hnyImx1Q" guid="_5uBeN4GMEduKE9hnyImx1Q" anchor="_5uBeNoGMEduKE9hnyImx1Q _5uBeOIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQx7KjEdudsfcMCYa15A" guid="_03qQx7KjEdudsfcMCYa15A" anchor="_03qQxrKjEdudsfcMCYa15A _03qQyLKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_5oznBoGMEduKE9hnyImx1Q" guid="_5oznBoGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeNoGMEduKE9hnyImx1Q" guid="_5uBeNoGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQxrKjEdudsfcMCYa15A" guid="_03qQxrKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymdwPNEdubhrgDuRb4fA" guid="_jcymdwPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymeAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymeQPNEdubhrgDuRb4fA" guid="_jcymeQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymegPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymewPNEdubhrgDuRb4fA" guid="_jcymewPNEdubhrgDuRb4fA" element="_7FGsMQNkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymfAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymfQPNEdubhrgDuRb4fA" guid="_jcymfQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymfgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymfwPNEdubhrgDuRb4fA" guid="_jcymfwPNEdubhrgDuRb4fA" element="_O6XmcANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymgAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6QAPNEdubhrgDuRb4fA" guid="_jdE6QAPNEdubhrgDuRb4fA">
+ <property xmi:id="_jdE6QQPNEdubhrgDuRb4fA" guid="_jdE6QQPNEdubhrgDuRb4fA" key="wpCompositeType" value="1"/>
+ <position xmi:id="_jdE6QgPNEdubhrgDuRb4fA" x="127.0" y="1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_jdRHgQPNEdubhrgDuRb4fA" guid="_jdRHgQPNEdubhrgDuRb4fA" anchor="_jdRHgAPNEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8P1cgRTUEduFIr9xNbwGyQ" guid="_8P1cgRTUEduFIr9xNbwGyQ" anchor="_8P1cgBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznAYGMEduKE9hnyImx1Q" guid="_5oznAYGMEduKE9hnyImx1Q" anchor="_5oznAIGMEduKE9hnyImx1Q _5oznAoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeMYGMEduKE9hnyImx1Q" guid="_5uBeMYGMEduKE9hnyImx1Q" anchor="_5uBeMIGMEduKE9hnyImx1Q _5uBeMoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQwbKjEdudsfcMCYa15A" guid="_03qQwbKjEdudsfcMCYa15A" anchor="_03qQwLKjEdudsfcMCYa15A _03qQwrKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_jdRHgAPNEdubhrgDuRb4fA" guid="_jdRHgAPNEdubhrgDuRb4fA" graphEdge="_jdRHgQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cgBTUEduFIr9xNbwGyQ" guid="_8P1cgBTUEduFIr9xNbwGyQ" graphEdge="_8P1cgRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznAIGMEduKE9hnyImx1Q" guid="_5oznAIGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeMIGMEduKE9hnyImx1Q" guid="_5uBeMIGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQwLKjEdudsfcMCYa15A" guid="_03qQwLKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6QwPNEdubhrgDuRb4fA" guid="_jdE6QwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jdE6RAPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6RQPNEdubhrgDuRb4fA" guid="_jdE6RQPNEdubhrgDuRb4fA">
+ <property xmi:id="_jdE6RgPNEdubhrgDuRb4fA" guid="_jdE6RgPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
+ <position xmi:id="_jdE6RwPNEdubhrgDuRb4fA" x="127.0" y="175.0"/>
+ <anchorage xmi:id="_jdRHggPNEdubhrgDuRb4fA" guid="_jdRHggPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cghTUEduFIr9xNbwGyQ" guid="_8P1cghTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznBYGMEduKE9hnyImx1Q" guid="_5oznBYGMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeNYGMEduKE9hnyImx1Q" guid="_5uBeNYGMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQxbKjEdudsfcMCYa15A" guid="_03qQxbKjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6SAPNEdubhrgDuRb4fA" guid="_jdE6SAPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jdE6SQPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdLA4APNEdubhrgDuRb4fA" guid="_jdLA4APNEdubhrgDuRb4fA">
+ <property xmi:id="_jdLA4QPNEdubhrgDuRb4fA" guid="_jdLA4QPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
+ <position xmi:id="_jdLA4gPNEdubhrgDuRb4fA" x="220.0" y="175.0"/>
+ <anchorage xmi:id="_jdRHgwPNEdubhrgDuRb4fA" guid="_jdRHgwPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cgxTUEduFIr9xNbwGyQ" guid="_8P1cgxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznCIGMEduKE9hnyImx1Q" guid="_5oznCIGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeOIGMEduKE9hnyImx1Q" guid="_5uBeOIGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQyLKjEdudsfcMCYa15A" guid="_03qQyLKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdLA4wPNEdubhrgDuRb4fA" guid="_jdLA4wPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jdLA5APNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymgQPNEdubhrgDuRb4fA" guid="_jcymgQPNEdubhrgDuRb4fA" presentation="Activity Detail" element="_37TdkAL_EduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_NSW6sAMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sAMAEduOAKqB9I73uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_SoXWEAMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEAMAEduOAKqB9I73uw">
+ <processElements xsi:type="org.eclipse.epf.uma:Iteration" xmi:id="_SoXWEQMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEQMAEduOAKqB9I73uw" briefDescription="Déroulement d'un sprint (itération)" presentationName="Sprint" isPlanned="false" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" breakdownElements="_glbG0AMAEduOAKqB9I73uw _glbG0QMAEduOAKqB9I73uw _glbG0wMAEduOAKqB9I73uw _glbG1AMAEduOAKqB9I73uw _glbG1QMAEduOAKqB9I73uw _glbG1gMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw _glbG2wMAEduOAKqB9I73uw _glbG3AMAEduOAKqB9I73uw _glbG3QMAEduOAKqB9I73uw _nXmKUANlEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0AMAEduOAKqB9I73uw" name="Manage problems" guid="_glbG0AMAEduOAKqB9I73uw" presentationName="Gérer les problèmes" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" optionalInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Xpd5gP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_LCxqQAB6EduSVaTQTBfIHA"/>
+ <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_PIKyUAB6EduSVaTQTBfIHA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0QMAEduOAKqB9I73uw" name="Update product backlog" guid="_glbG0QMAEduOAKqB9I73uw" presentationName="Mettre à jour le backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" additionallyPerformedBy="_glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2AMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_STkWYP_BEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_c3HaQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_fkXDoAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_k-kCgAPKEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0wMAEduOAKqB9I73uw" name="Plan sprint" guid="_glbG0wMAEduOAKqB9I73uw" presentationName="Planifier le sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_4LOggPpaEdqsc-f87sBK8A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_TJNsUP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_p4C0sP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_worbAP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_xvy5UAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_DxNQUAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_Iq14wAPLEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1AMAEduOAKqB9I73uw" name="Retrospective" guid="_glbG1AMAEduOAKqB9I73uw" presentationName="Rétrospective" superActivities="_SoXWEQMAEduOAKqB9I73uw" linkToPredecessor="_O0710AMCEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_J_sRIP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_lwzeABGPEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_noL2YBGPEduHloEV5-Zv-w"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1QMAEduOAKqB9I73uw" name="Review sprint" guid="_glbG1QMAEduOAKqB9I73uw" presentationName="Faire la revue du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" isEventDriven="true" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" mandatoryInput="_glbG3QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_MRrRYPpbEdqsc-f87sBK8A"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_XL6VgAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_ZgJB8APLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_cBouUAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_hrswoHoYEduJVrY6eKG_mw"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_d776UHoYEduJVrY6eKG_mw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1gMAEduOAKqB9I73uw" name="Scrum daily meeting" guid="_glbG1gMAEduOAKqB9I73uw" presentationName="Mêlée quotidienne" superActivities="_SoXWEQMAEduOAKqB9I73uw" isRepeatable="true" isEventDriven="true" linkToPredecessor="_34UPdAzNEduDObTFE5q79g _34UPdQzNEduDObTFE5q79g _34UPdgzNEduDObTFE5q79g" additionallyPerformedBy="_glbG2gMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_d09LYP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_oUrlcBGOEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_r0KkEBGOEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_vZkkgBGOEduHloEV5-Zv-w"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG1wMAEduOAKqB9I73uw" name="ScrumMaster" guid="_glbG1wMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG2wMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2AMAEduOAKqB9I73uw" name="Product Owner" guid="_glbG2AMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG3AMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2QMAEduOAKqB9I73uw" name="StakeHolder" guid="_glbG2QMAEduOAKqB9I73uw" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2gMAEduOAKqB9I73uw" name="Team" guid="_glbG2gMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG2wMAEduOAKqB9I73uw" name="Sprint backlog" guid="_glbG2wMAEduOAKqB9I73uw" presentationName="Backlog du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <presentation xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-MupkaQeHNEmiF7Lnl3VirQ"/>
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Dzw70PpZEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3AMAEduOAKqB9I73uw" name="Product Backlog" guid="_glbG3AMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" activityEntryState="courant" activityExitState="mis à jour">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3QMAEduOAKqB9I73uw" name="Product" guid="_glbG3QMAEduOAKqB9I73uw" presentationName="Incrément de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_O0710AMCEduOAKqB9I73uw" guid="_O0710AMCEduOAKqB9I73uw" linkType="finishToFinish" pred="_glbG1QMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_nXmKUANlEduYd-55D-Aiqg" name="Daily work" guid="_nXmKUANlEduYd-55D-Aiqg" briefDescription="L'équipe réalise les taches du backlog pour arriver au but du sprint" presentationName="Travaux quotidiens" isPlanned="true" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG3QMAEduOAKqB9I73uw">
+ <presentation xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" href="uma://-16dzhVoCex78V2iCDZVx0w#-EpBaHVCIYCqqGX_wv7dlYA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdAzNEduDObTFE5q79g" guid="_34UPdAzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0QMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdQzNEduDObTFE5q79g" guid="_34UPdQzNEduDObTFE5q79g" linkType="finishToFinish" pred="_nXmKUANlEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdgzNEduDObTFE5q79g" guid="_34UPdgzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0AMAEduOAKqB9I73uw"/>
+ <diagrams xmi:id="_2vZZMAMBEduOAKqB9I73uw" guid="_2vZZMAMBEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vZZMQMBEduOAKqB9I73uw" guid="_2vZZMQMBEduOAKqB9I73uw">
+ <position xmi:id="_2vZZMgMBEduOAKqB9I73uw" x="199.0" y="174.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LnUDQQMCEduOAKqB9I73uw" guid="_LnUDQQMCEduOAKqB9I73uw" anchor="_LnUDQAMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_LSlwcgMCEduOAKqB9I73uw" guid="_LSlwcgMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_LnUDQAMCEduOAKqB9I73uw" guid="_LnUDQAMCEduOAKqB9I73uw" graphEdge="_LnUDQQMCEduOAKqB9I73uw">
+ <position xmi:id="_LnUDQwMCEduOAKqB9I73uw" x="316.0" y="187.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZMwMBEduOAKqB9I73uw" guid="_2vZZMwMBEduOAKqB9I73uw"/>
+ <size xmi:id="_2vZZNAMBEduOAKqB9I73uw" width="143.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff0AMBEduOAKqB9I73uw" guid="_2vff0AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff0QMBEduOAKqB9I73uw" x="322.0" y="134.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_swPHwQzNEduDObTFE5q79g" guid="_swPHwQzNEduDObTFE5q79g" anchor="_swPHwAzNEduDObTFE5q79g _swPHwgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_L-ChMgMCEduOAKqB9I73uw" guid="_L-ChMgMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_swPHwAzNEduDObTFE5q79g" guid="_swPHwAzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
+ <position xmi:id="_swPHwwzNEduDObTFE5q79g" x="394.0" y="241.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff0gMBEduOAKqB9I73uw" guid="_2vff0gMBEduOAKqB9I73uw" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff0wMBEduOAKqB9I73uw" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff1AMBEduOAKqB9I73uw" guid="_2vff1AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff1QMBEduOAKqB9I73uw" x="19.0" y="127.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_r27hMQzNEduDObTFE5q79g" guid="_r27hMQzNEduDObTFE5q79g" anchor="_r27hMAzNEduDObTFE5q79g _r27hMgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_KNcGQgMCEduOAKqB9I73uw" guid="_KNcGQgMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_r27hMAzNEduDObTFE5q79g" guid="_r27hMAzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
+ <position xmi:id="_r27hMwzNEduDObTFE5q79g" x="123.0" y="239.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff1gMBEduOAKqB9I73uw" guid="_2vff1gMBEduOAKqB9I73uw" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff1wMBEduOAKqB9I73uw" width="130.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff2AMBEduOAKqB9I73uw" guid="_2vff2AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff2QMBEduOAKqB9I73uw" x="76.0" y="269.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff2gMBEduOAKqB9I73uw" guid="_2vff2gMBEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff2wMBEduOAKqB9I73uw" width="88.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff3AMBEduOAKqB9I73uw" guid="_2vff3AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff3QMBEduOAKqB9I73uw" x="190.0" y="3.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-mYC4QzNEduDObTFE5q79g" guid="_-mYC4QzNEduDObTFE5q79g" anchor="_-mYC4AzNEduDObTFE5q79g _-mYC4gzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_I2DckgMCEduOAKqB9I73uw" guid="_I2DckgMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_-mYC4AzNEduDObTFE5q79g" guid="_-mYC4AzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
+ <position xmi:id="_-mYC4wzNEduDObTFE5q79g" x="264.0" y="88.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff3gMBEduOAKqB9I73uw" guid="_2vff3gMBEduOAKqB9I73uw" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff3wMBEduOAKqB9I73uw" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff4AMBEduOAKqB9I73uw" guid="_2vff4AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff4QMBEduOAKqB9I73uw" x="346.0" y="332.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_PENn8QMCEduOAKqB9I73uw" guid="_PENn8QMCEduOAKqB9I73uw" anchor="_PENn8AMCEduOAKqB9I73uw _PENn8gMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_O0vokgMCEduOAKqB9I73uw" guid="_O0vokgMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_PENn8AMCEduOAKqB9I73uw" guid="_PENn8AMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw">
+ <position xmi:id="_PENn8wMCEduOAKqB9I73uw" x="327.0" y="377.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff4gMBEduOAKqB9I73uw" guid="_2vff4gMBEduOAKqB9I73uw" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff4wMBEduOAKqB9I73uw" width="67.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff5AMBEduOAKqB9I73uw" guid="_2vff5AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff5QMBEduOAKqB9I73uw" x="175.0" y="332.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O0vokQMCEduOAKqB9I73uw" guid="_O0vokQMCEduOAKqB9I73uw" anchor="_O0vokAMCEduOAKqB9I73uw _O0vokgMCEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O0710QMCEduOAKqB9I73uw" guid="_O0710QMCEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_Ok5OsgMCEduOAKqB9I73uw" guid="_Ok5OsgMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_O0vokAMCEduOAKqB9I73uw" guid="_O0vokAMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw">
+ <position xmi:id="_O0vokwMCEduOAKqB9I73uw" x="324.0" y="328.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff5gMBEduOAKqB9I73uw" guid="_2vff5gMBEduOAKqB9I73uw" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff5wMBEduOAKqB9I73uw" width="111.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff6AMBEduOAKqB9I73uw" guid="_2vff6AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff6QMBEduOAKqB9I73uw" x="187.0" y="217.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_63CqYQzNEduDObTFE5q79g" guid="_63CqYQzNEduDObTFE5q79g" anchor="_63CqYAzNEduDObTFE5q79g _63CqYgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_34UPcgzNEduDObTFE5q79g" guid="_34UPcgzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_63CqYAzNEduDObTFE5q79g" guid="_63CqYAzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
+ <position xmi:id="_63CqYwzNEduDObTFE5q79g" x="268.0" y="326.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff6gMBEduOAKqB9I73uw" guid="_2vff6gMBEduOAKqB9I73uw" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff6wMBEduOAKqB9I73uw" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DtnjIAMCEduOAKqB9I73uw" guid="_DtnjIAMCEduOAKqB9I73uw">
+ <position xmi:id="_DtnjIQMCEduOAKqB9I73uw" x="9.0" y="15.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_I2DckQMCEduOAKqB9I73uw" guid="_I2DckQMCEduOAKqB9I73uw" anchor="_I2DckAMCEduOAKqB9I73uw _I2DckgMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_I2DckAMCEduOAKqB9I73uw" guid="_I2DckAMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw">
+ <position xmi:id="_I2DckwMCEduOAKqB9I73uw" x="318.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DtnjIgMCEduOAKqB9I73uw" guid="_DtnjIgMCEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_DtnjIwMCEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_EQ85sAMCEduOAKqB9I73uw" guid="_EQ85sAMCEduOAKqB9I73uw">
+ <position xmi:id="_EQ85sQMCEduOAKqB9I73uw" x="531.0" y="342.0"/>
+ <anchorage xmi:id="_PENn8gMCEduOAKqB9I73uw" guid="_PENn8gMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_EQ85sgMCEduOAKqB9I73uw" guid="_EQ85sgMCEduOAKqB9I73uw" typeInfo="end node"/>
+ <size xmi:id="_EQ85swMCEduOAKqB9I73uw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_FLsDoAMCEduOAKqB9I73uw" guid="_FLsDoAMCEduOAKqB9I73uw">
+ <position xmi:id="_FLsDoQMCEduOAKqB9I73uw" x="206.0" y="274.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ok5OsQMCEduOAKqB9I73uw" guid="_Ok5OsQMCEduOAKqB9I73uw" anchor="_Ok5OsAMCEduOAKqB9I73uw _Ok5OsgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ADBAAQzOEduDObTFE5q79g" guid="_ADBAAQzOEduDObTFE5q79g" anchor="_ADBAAAzOEduDObTFE5q79g _ADBAAgzOEduDObTFE5q79g">
+ <waypoints xmi:id="_0PYkcAzOEduDObTFE5q79g" x="491.0" y="285.0"/>
+ <waypoints xmi:id="_0PYkcQzOEduDObTFE5q79g" x="492.0" y="76.0"/>
+ </contained>
+ <anchorage xmi:id="_Ok5OsAMCEduOAKqB9I73uw" guid="_Ok5OsAMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw">
+ <position xmi:id="_cyxCoAMCEduOAKqB9I73uw" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_63CqYgzNEduDObTFE5q79g" guid="_63CqYgzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
+ <position xmi:id="_63CqZAzNEduDObTFE5q79g" x="23.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ADBAAAzOEduDObTFE5q79g" guid="_ADBAAAzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
+ <position xmi:id="_ADBAAwzOEduDObTFE5q79g" x="47.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_FLsDogMCEduOAKqB9I73uw" guid="_FLsDogMCEduOAKqB9I73uw" typeInfo="decision node"/>
+ <size xmi:id="_FLsDowMCEduOAKqB9I73uw" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HEmGAAMCEduOAKqB9I73uw" guid="_HEmGAAMCEduOAKqB9I73uw">
+ <position xmi:id="_HEmGAQMCEduOAKqB9I73uw" x="180.0" y="106.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KNcGQQMCEduOAKqB9I73uw" guid="_KNcGQQMCEduOAKqB9I73uw" anchor="_KNcGQAMCEduOAKqB9I73uw _KNcGQgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LSlwcQMCEduOAKqB9I73uw" guid="_LSlwcQMCEduOAKqB9I73uw" anchor="_LSlwcAMCEduOAKqB9I73uw _LSlwcgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_L-ChMQMCEduOAKqB9I73uw" guid="_L-ChMQMCEduOAKqB9I73uw" anchor="_L-ChMAMCEduOAKqB9I73uw _L-ChMgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_haut0QNmEduYd-55D-Aiqg" guid="_haut0QNmEduYd-55D-Aiqg" anchor="_haut0ANmEduYd-55D-Aiqg _haut0gNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_KNcGQAMCEduOAKqB9I73uw" guid="_KNcGQAMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw">
+ <position xmi:id="_KNcGQwMCEduOAKqB9I73uw" x="47.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_LSlwcAMCEduOAKqB9I73uw" guid="_LSlwcAMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw">
+ <position xmi:id="_LSlwcwMCEduOAKqB9I73uw" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_L-ChMAMCEduOAKqB9I73uw" guid="_L-ChMAMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw">
+ <position xmi:id="_L-In0AMCEduOAKqB9I73uw" x="50.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_haut0ANmEduYd-55D-Aiqg" guid="_haut0ANmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg">
+ <position xmi:id="_8NQZYIGPEduKE9hnyImx1Q" x="50.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="__S4jkgzNEduDObTFE5q79g" guid="__S4jkgzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
+ <position xmi:id="__S4jlAzNEduDObTFE5q79g" x="46.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_HEmGAgMCEduOAKqB9I73uw" guid="_HEmGAgMCEduOAKqB9I73uw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_HEmGAwMCEduOAKqB9I73uw" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_XP3cUANmEduYd-55D-Aiqg" guid="_XP3cUANmEduYd-55D-Aiqg">
+ <position xmi:id="_XP3cUQNmEduYd-55D-Aiqg" x="184.0" y="134.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_sOOm4QzNEduDObTFE5q79g" guid="_sOOm4QzNEduDObTFE5q79g" anchor="_sOOm4AzNEduDObTFE5q79g _sOOm4gzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_haut0gNmEduYd-55D-Aiqg" guid="_haut0gNmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_sOOm4AzNEduDObTFE5q79g" guid="_sOOm4AzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
+ <position xmi:id="_sOOm4wzNEduDObTFE5q79g" x="263.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_XP3cUgNmEduYd-55D-Aiqg" guid="_XP3cUgNmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_XP3cUwNmEduYd-55D-Aiqg" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4Fi44ANmEduYd-55D-Aiqg" name="Add Free Text" guid="_4Fi44ANmEduYd-55D-Aiqg">
+ <property xmi:id="_4Fi44QNmEduYd-55D-Aiqg" guid="_4Fi44QNmEduYd-55D-Aiqg" key="free text" value="date de fin de sprint atteinte"/>
+ <position xmi:id="_4Fi44gNmEduYd-55D-Aiqg" x="154.0" y="297.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_4Fi44wNmEduYd-55D-Aiqg" guid="_4Fi44wNmEduYd-55D-Aiqg" typeInfo="free text"/>
+ <size xmi:id="_4Fi45ANmEduYd-55D-Aiqg" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_S90SkAzNEduDObTFE5q79g" guid="_S90SkAzNEduDObTFE5q79g">
+ <position xmi:id="_S90SkQzNEduDObTFE5q79g" x="206.0" y="66.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__S4jkQzNEduDObTFE5q79g" guid="__S4jkQzNEduDObTFE5q79g" anchor="__S4jkAzNEduDObTFE5q79g __S4jkgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_-mYC4gzNEduDObTFE5q79g" guid="_-mYC4gzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
+ <position xmi:id="_-mYC5AzNEduDObTFE5q79g" x="23.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__S4jkAzNEduDObTFE5q79g" guid="__S4jkAzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
+ <position xmi:id="__S4jkwzNEduDObTFE5q79g" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ADBAAgzOEduDObTFE5q79g" guid="_ADBAAgzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
+ <position xmi:id="_ADBABAzOEduDObTFE5q79g" x="47.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_S90SkgzNEduDObTFE5q79g" guid="_S90SkgzNEduDObTFE5q79g" typeInfo="decision node"/>
+ <size xmi:id="_S90SkwzNEduDObTFE5q79g" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_qmzWEAzNEduDObTFE5q79g" guid="_qmzWEAzNEduDObTFE5q79g">
+ <position xmi:id="_qmzWEQzNEduDObTFE5q79g" x="180.0" y="198.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_34UPcQzNEduDObTFE5q79g" guid="_34UPcQzNEduDObTFE5q79g" anchor="_34UPcAzNEduDObTFE5q79g _34UPcgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_r27hMgzNEduDObTFE5q79g" guid="_r27hMgzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
+ <position xmi:id="_r27hNAzNEduDObTFE5q79g" x="38.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_sOOm4gzNEduDObTFE5q79g" guid="_sOOm4gzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
+ <position xmi:id="_8NQZYYGPEduKE9hnyImx1Q" x="50.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_swPHwgzNEduDObTFE5q79g" guid="_swPHwgzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
+ <position xmi:id="_swPHxAzNEduDObTFE5q79g" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_34UPcAzNEduDObTFE5q79g" guid="_34UPcAzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g">
+ <position xmi:id="_34UPcwzNEduDObTFE5q79g" x="44.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_qmzWEgzNEduDObTFE5q79g" guid="_qmzWEgzNEduDObTFE5q79g" typeInfo="synchnonization bar"/>
+ <size xmi:id="_qmzWEwzNEduDObTFE5q79g" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_f5j60AzOEduDObTFE5q79g" name="Add Free Text" guid="_f5j60AzOEduDObTFE5q79g">
+ <property xmi:id="_f5j60QzOEduDObTFE5q79g" guid="_f5j60QzOEduDObTFE5q79g" key="free text" value="encore des jours dans le sprint"/>
+ <position xmi:id="_f5j60gzOEduDObTFE5q79g" x="289.0" y="266.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_f5j60wzOEduDObTFE5q79g" guid="_f5j60wzOEduDObTFE5q79g" typeInfo="free text"/>
+ <size xmi:id="_f5j61AzOEduDObTFE5q79g" width="165.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZNQMBEduOAKqB9I73uw" guid="_2vZZNQMBEduOAKqB9I73uw" presentation="Workflow" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ <diagrams xmi:id="_O8kwcANmEduYd-55D-Aiqg" guid="_O8kwcANmEduYd-55D-Aiqg">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwcQNmEduYd-55D-Aiqg" guid="_O8kwcQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwcgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RsYGMEduKE9hnyImx1Q" guid="_5q5RsYGMEduKE9hnyImx1Q" anchor="_5q5RsIGMEduKE9hnyImx1Q _5q5RsoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeEYGMEduKE9hnyImx1Q" guid="_51BeEYGMEduKE9hnyImx1Q" anchor="_51BeEIGMEduKE9hnyImx1Q _51BeEoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RsIGMEduKE9hnyImx1Q" guid="_5q5RsIGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeEIGMEduKE9hnyImx1Q" guid="_51BeEIGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwcwNmEduYd-55D-Aiqg" guid="_O8kwcwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kwdANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwdQNmEduYd-55D-Aiqg" guid="_O8kwdQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwdgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rt4GMEduKE9hnyImx1Q" guid="_5q5Rt4GMEduKE9hnyImx1Q" anchor="_5q5RtoGMEduKE9hnyImx1Q _5q5RuIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeF4GMEduKE9hnyImx1Q" guid="_51BeF4GMEduKE9hnyImx1Q" anchor="_51BeFoGMEduKE9hnyImx1Q _51BeGIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RtYGMEduKE9hnyImx1Q" guid="_5q5RtYGMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RtoGMEduKE9hnyImx1Q" guid="_5q5RtoGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeFYGMEduKE9hnyImx1Q" guid="_51BeFYGMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeFoGMEduKE9hnyImx1Q" guid="_51BeFoGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwdwNmEduYd-55D-Aiqg" guid="_O8kwdwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kweANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kweQNmEduYd-55D-Aiqg" guid="_O8kweQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwegNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RvYGMEduKE9hnyImx1Q" guid="_5q5RvYGMEduKE9hnyImx1Q" anchor="_5q5RvIGMEduKE9hnyImx1Q _5q5RvoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeHYGMEduKE9hnyImx1Q" guid="_51BeHYGMEduKE9hnyImx1Q" anchor="_51BeHIGMEduKE9hnyImx1Q _51BeHoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Ru4GMEduKE9hnyImx1Q" guid="_5q5Ru4GMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RvIGMEduKE9hnyImx1Q" guid="_5q5RvIGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeG4GMEduKE9hnyImx1Q" guid="_51BeG4GMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeHIGMEduKE9hnyImx1Q" guid="_51BeHIGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwewNmEduYd-55D-Aiqg" guid="_O8kwewNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kwfANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwfQNmEduYd-55D-Aiqg" guid="_O8kwfQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwfgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RwIGMEduKE9hnyImx1Q" guid="_5q5RwIGMEduKE9hnyImx1Q" anchor="_5q5Rv4GMEduKE9hnyImx1Q _5q5RwYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeIIGMEduKE9hnyImx1Q" guid="_51BeIIGMEduKE9hnyImx1Q" anchor="_51BeH4GMEduKE9hnyImx1Q _51BeIYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Rv4GMEduKE9hnyImx1Q" guid="_5q5Rv4GMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeH4GMEduKE9hnyImx1Q" guid="_51BeH4GMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3EANmEduYd-55D-Aiqg" guid="_O8q3EANmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3EQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3EgNmEduYd-55D-Aiqg" guid="_O8q3EgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3EwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RxoGMEduKE9hnyImx1Q" guid="_5q5RxoGMEduKE9hnyImx1Q" anchor="_5q5RxYGMEduKE9hnyImx1Q _5q5Rx4GMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeJoGMEduKE9hnyImx1Q" guid="_51BeJoGMEduKE9hnyImx1Q" anchor="_51BeJYGMEduKE9hnyImx1Q _51BeJ4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RxIGMEduKE9hnyImx1Q" guid="_5q5RxIGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RxYGMEduKE9hnyImx1Q" guid="_5q5RxYGMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJIGMEduKE9hnyImx1Q" guid="_51BeJIGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJYGMEduKE9hnyImx1Q" guid="_51BeJYGMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3FANmEduYd-55D-Aiqg" guid="_O8q3FANmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3FQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3FgNmEduYd-55D-Aiqg" guid="_O8q3FgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3FwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RzIGMEduKE9hnyImx1Q" guid="_5q5RzIGMEduKE9hnyImx1Q" anchor="_5q5Ry4GMEduKE9hnyImx1Q _5q5RzYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeLIGMEduKE9hnyImx1Q" guid="_51BeLIGMEduKE9hnyImx1Q" anchor="_51BeK4GMEduKE9hnyImx1Q _51BeLYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RyoGMEduKE9hnyImx1Q" guid="_5q5RyoGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Ry4GMEduKE9hnyImx1Q" guid="_5q5Ry4GMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeKoGMEduKE9hnyImx1Q" guid="_51BeKoGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeK4GMEduKE9hnyImx1Q" guid="_51BeK4GMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3GANmEduYd-55D-Aiqg" guid="_O8q3GANmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3GQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3GgNmEduYd-55D-Aiqg" guid="_O8q3GgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3GwNmEduYd-55D-Aiqg" x="30.0" y="88.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3HANmEduYd-55D-Aiqg" guid="_O8q3HANmEduYd-55D-Aiqg" element="_glbG1wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3HQNmEduYd-55D-Aiqg" width="338.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3HgNmEduYd-55D-Aiqg" guid="_O8q3HgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3HwNmEduYd-55D-Aiqg" x="30.0" y="356.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3IANmEduYd-55D-Aiqg" guid="_O8q3IANmEduYd-55D-Aiqg" element="_glbG2AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3IQNmEduYd-55D-Aiqg" width="222.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3IgNmEduYd-55D-Aiqg" guid="_O8q3IgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3IwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3JANmEduYd-55D-Aiqg" guid="_O8q3JANmEduYd-55D-Aiqg" element="_glbG2QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3JQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3JgNmEduYd-55D-Aiqg" guid="_O8q3JgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3JwNmEduYd-55D-Aiqg" x="30.0" y="638.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3KANmEduYd-55D-Aiqg" guid="_O8q3KANmEduYd-55D-Aiqg" element="_glbG2gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3KQNmEduYd-55D-Aiqg" width="374.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3KgNmEduYd-55D-Aiqg" guid="_O8q3KgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3KwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3LANmEduYd-55D-Aiqg" guid="_O8q3LANmEduYd-55D-Aiqg" element="_glbG2wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3LQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3LgNmEduYd-55D-Aiqg" guid="_O8q3LgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3LwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3MANmEduYd-55D-Aiqg" guid="_O8q3MANmEduYd-55D-Aiqg" element="_glbG3AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3MQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3MgNmEduYd-55D-Aiqg" guid="_O8q3MgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3MwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3NANmEduYd-55D-Aiqg" guid="_O8q3NANmEduYd-55D-Aiqg" element="_glbG3QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3NQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3NgNmEduYd-55D-Aiqg" guid="_O8q3NgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3NwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OANmEduYd-55D-Aiqg" guid="_O8q3OANmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_O8q3OQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9bsEANmEduYd-55D-Aiqg" guid="_O9bsEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O9bsEQNmEduYd-55D-Aiqg" guid="_O9bsEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O9bsEgNmEduYd-55D-Aiqg" x="137.0" y="161.0"/>
+ <anchorage xmi:id="_O-9WFQNmEduYd-55D-Aiqg" guid="_O-9WFQNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVsANnEduYd-55D-Aiqg" guid="_oHjVsANnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMAO8EdubhrgDuRb4fA" guid="_D6EPMAO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMAPMEdubhrgDuRb4fA" guid="_-EfTMAPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcBTUEduFIr9xNbwGyQ" guid="_8ZSTcBTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RsoGMEduKE9hnyImx1Q" guid="_5q5RsoGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeEoGMEduKE9hnyImx1Q" guid="_51BeEoGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9bsEwNmEduYd-55D-Aiqg" guid="_O9bsEwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O9bsFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9t_8ANmEduYd-55D-Aiqg" guid="_O9t_8ANmEduYd-55D-Aiqg">
+ <property xmi:id="_O9t_8QNmEduYd-55D-Aiqg" guid="_O9t_8QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O9t_8gNmEduYd-55D-Aiqg" x="142.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WFwNmEduYd-55D-Aiqg" guid="_O-9WFwNmEduYd-55D-Aiqg" anchor="_O-9WFgNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVsgNnEduYd-55D-Aiqg" guid="_oHjVsgNnEduYd-55D-Aiqg" anchor="_oHjVsQNnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPMgO8EdubhrgDuRb4fA" guid="_D6EPMgO8EdubhrgDuRb4fA" anchor="_D6EPMQO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTMgPMEdubhrgDuRb4fA" guid="_-EfTMgPMEdubhrgDuRb4fA" anchor="_-EfTMQPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTchTUEduFIr9xNbwGyQ" guid="_8ZSTchTUEduFIr9xNbwGyQ" anchor="_8ZSTcRTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RtIGMEduKE9hnyImx1Q" guid="_5q5RtIGMEduKE9hnyImx1Q" anchor="_5q5Rs4GMEduKE9hnyImx1Q _5q5RtYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeFIGMEduKE9hnyImx1Q" guid="_51BeFIGMEduKE9hnyImx1Q" anchor="_51BeE4GMEduKE9hnyImx1Q _51BeFYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WFgNmEduYd-55D-Aiqg" guid="_O-9WFgNmEduYd-55D-Aiqg" graphEdge="_O-9WFwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVsQNnEduYd-55D-Aiqg" guid="_oHjVsQNnEduYd-55D-Aiqg" graphEdge="_oHjVsgNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMQO8EdubhrgDuRb4fA" guid="_D6EPMQO8EdubhrgDuRb4fA" graphEdge="_D6EPMgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMQPMEdubhrgDuRb4fA" guid="_-EfTMQPMEdubhrgDuRb4fA" graphEdge="_-EfTMgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcRTUEduFIr9xNbwGyQ" guid="_8ZSTcRTUEduFIr9xNbwGyQ" graphEdge="_8ZSTchTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5Rs4GMEduKE9hnyImx1Q" guid="_5q5Rs4GMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeE4GMEduKE9hnyImx1Q" guid="_51BeE4GMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9t_8wNmEduYd-55D-Aiqg" guid="_O9t_8wNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O9t_9ANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O96NMANmEduYd-55D-Aiqg" guid="_O96NMANmEduYd-55D-Aiqg">
+ <property xmi:id="_O96NMQNmEduYd-55D-Aiqg" guid="_O96NMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O96NMgNmEduYd-55D-Aiqg" x="142.0" y="443.0"/>
+ <anchorage xmi:id="_O-9WGANmEduYd-55D-Aiqg" guid="_O-9WGANmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVswNnEduYd-55D-Aiqg" guid="_oHjVswNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMwO8EdubhrgDuRb4fA" guid="_D6EPMwO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMwPMEdubhrgDuRb4fA" guid="_-EfTMwPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcxTUEduFIr9xNbwGyQ" guid="_8ZSTcxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RuIGMEduKE9hnyImx1Q" guid="_5q5RuIGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeGIGMEduKE9hnyImx1Q" guid="_51BeGIGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O96NMwNmEduYd-55D-Aiqg" guid="_O96NMwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O96NNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-GacANmEduYd-55D-Aiqg" guid="_O-GacANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-GacQNmEduYd-55D-Aiqg" guid="_O-GacQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-GacgNmEduYd-55D-Aiqg" x="289.0" y="551.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WGgNmEduYd-55D-Aiqg" guid="_O-9WGgNmEduYd-55D-Aiqg" anchor="_O-9WGQNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVtQNnEduYd-55D-Aiqg" guid="_oHjVtQNnEduYd-55D-Aiqg" anchor="_oHjVtANnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPNQO8EdubhrgDuRb4fA" guid="_D6EPNQO8EdubhrgDuRb4fA" anchor="_D6EPNAO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTNQPMEdubhrgDuRb4fA" guid="_-EfTNQPMEdubhrgDuRb4fA" anchor="_-EfTNAPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTdRTUEduFIr9xNbwGyQ" guid="_8ZSTdRTUEduFIr9xNbwGyQ" anchor="_8ZSTdBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RuoGMEduKE9hnyImx1Q" guid="_5q5RuoGMEduKE9hnyImx1Q" anchor="_5q5RuYGMEduKE9hnyImx1Q _5q5Ru4GMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeGoGMEduKE9hnyImx1Q" guid="_51BeGoGMEduKE9hnyImx1Q" anchor="_51BeGYGMEduKE9hnyImx1Q _51BeG4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WGQNmEduYd-55D-Aiqg" guid="_O-9WGQNmEduYd-55D-Aiqg" graphEdge="_O-9WGgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtANnEduYd-55D-Aiqg" guid="_oHjVtANnEduYd-55D-Aiqg" graphEdge="_oHjVtQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNAO8EdubhrgDuRb4fA" guid="_D6EPNAO8EdubhrgDuRb4fA" graphEdge="_D6EPNQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNAPMEdubhrgDuRb4fA" guid="_-EfTNAPMEdubhrgDuRb4fA" graphEdge="_-EfTNQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdBTUEduFIr9xNbwGyQ" guid="_8ZSTdBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTdRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RuYGMEduKE9hnyImx1Q" guid="_5q5RuYGMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeGYGMEduKE9hnyImx1Q" guid="_51BeGYGMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-GacwNmEduYd-55D-Aiqg" guid="_O-GacwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-GadANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-MhEANmEduYd-55D-Aiqg" guid="_O-MhEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-MhEQNmEduYd-55D-Aiqg" guid="_O-MhEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-MhEgNmEduYd-55D-Aiqg" x="292.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WGwNmEduYd-55D-Aiqg" guid="_O-9WGwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtgNnEduYd-55D-Aiqg" guid="_oHjVtgNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNgO8EdubhrgDuRb4fA" guid="_D6EPNgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNgPMEdubhrgDuRb4fA" guid="_-EfTNgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdhTUEduFIr9xNbwGyQ" guid="_8ZSTdhTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RvoGMEduKE9hnyImx1Q" guid="_5q5RvoGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeHoGMEduKE9hnyImx1Q" guid="_51BeHoGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-MhEwNmEduYd-55D-Aiqg" guid="_O-MhEwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-MhFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-YuUANmEduYd-55D-Aiqg" guid="_O-YuUANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-YuUQNmEduYd-55D-Aiqg" guid="_O-YuUQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-YuUgNmEduYd-55D-Aiqg" x="121.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WHANmEduYd-55D-Aiqg" guid="_O-9WHANmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtwNnEduYd-55D-Aiqg" guid="_oHjVtwNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNwO8EdubhrgDuRb4fA" guid="_D6EPNwO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNwPMEdubhrgDuRb4fA" guid="_-EfTNwPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdxTUEduFIr9xNbwGyQ" guid="_8ZSTdxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RwYGMEduKE9hnyImx1Q" guid="_5q5RwYGMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeIYGMEduKE9hnyImx1Q" guid="_51BeIYGMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-YuUwNmEduYd-55D-Aiqg" guid="_O-YuUwNmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-YuVANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-k7kANmEduYd-55D-Aiqg" guid="_O-k7kANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-k7kQNmEduYd-55D-Aiqg" guid="_O-k7kQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-k7kgNmEduYd-55D-Aiqg" x="216.0" y="565.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WHgNmEduYd-55D-Aiqg" guid="_O-9WHgNmEduYd-55D-Aiqg" anchor="_O-9WHQNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVuQNnEduYd-55D-Aiqg" guid="_oHjVuQNnEduYd-55D-Aiqg" anchor="_oHjVuANnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPOQO8EdubhrgDuRb4fA" guid="_D6EPOQO8EdubhrgDuRb4fA" anchor="_D6EPOAO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTOQPMEdubhrgDuRb4fA" guid="_-EfTOQPMEdubhrgDuRb4fA" anchor="_-EfTOAPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTeRTUEduFIr9xNbwGyQ" guid="_8ZSTeRTUEduFIr9xNbwGyQ" anchor="_8ZSTeBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rw4GMEduKE9hnyImx1Q" guid="_5q5Rw4GMEduKE9hnyImx1Q" anchor="_5q5RwoGMEduKE9hnyImx1Q _5q5RxIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeI4GMEduKE9hnyImx1Q" guid="_51BeI4GMEduKE9hnyImx1Q" anchor="_51BeIoGMEduKE9hnyImx1Q _51BeJIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WHQNmEduYd-55D-Aiqg" guid="_O-9WHQNmEduYd-55D-Aiqg" graphEdge="_O-9WHgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVuANnEduYd-55D-Aiqg" guid="_oHjVuANnEduYd-55D-Aiqg" graphEdge="_oHjVuQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOAO8EdubhrgDuRb4fA" guid="_D6EPOAO8EdubhrgDuRb4fA" graphEdge="_D6EPOQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOAPMEdubhrgDuRb4fA" guid="_-EfTOAPMEdubhrgDuRb4fA" graphEdge="_-EfTOQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTeBTUEduFIr9xNbwGyQ" guid="_8ZSTeBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTeRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RwoGMEduKE9hnyImx1Q" guid="_5q5RwoGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeIoGMEduKE9hnyImx1Q" guid="_51BeIoGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-k7kwNmEduYd-55D-Aiqg" guid="_O-k7kwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-k7lANmEduYd-55D-Aiqg" width="63.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-rCMANmEduYd-55D-Aiqg" guid="_O-rCMANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-rCMQNmEduYd-55D-Aiqg" guid="_O-rCMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-rCMgNmEduYd-55D-Aiqg" x="209.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WHwNmEduYd-55D-Aiqg" guid="_O-9WHwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVugNnEduYd-55D-Aiqg" guid="_oHjVugNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOgO8EdubhrgDuRb4fA" guid="_D6EPOgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOgPMEdubhrgDuRb4fA" guid="_-EfTOgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTehTUEduFIr9xNbwGyQ" guid="_8ZSTehTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5Rx4GMEduKE9hnyImx1Q" guid="_5q5Rx4GMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJ4GMEduKE9hnyImx1Q" guid="_51BeJ4GMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-rCMwNmEduYd-55D-Aiqg" guid="_O-rCMwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-rCNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-xI0ANmEduYd-55D-Aiqg" guid="_O-xI0ANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-xI0QNmEduYd-55D-Aiqg" guid="_O-xI0QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-xI0gNmEduYd-55D-Aiqg" x="249.0" y="1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WIQNmEduYd-55D-Aiqg" guid="_O-9WIQNmEduYd-55D-Aiqg" anchor="_O-9WIANmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVvANnEduYd-55D-Aiqg" guid="_oHjVvANnEduYd-55D-Aiqg" anchor="_oHjVuwNnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPPAO8EdubhrgDuRb4fA" guid="_D6EPPAO8EdubhrgDuRb4fA" anchor="_D6EPOwO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTPAPMEdubhrgDuRb4fA" guid="_-EfTPAPMEdubhrgDuRb4fA" anchor="_-EfTOwPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTfBTUEduFIr9xNbwGyQ" guid="_8ZSTfBTUEduFIr9xNbwGyQ" anchor="_8ZSTexTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RyYGMEduKE9hnyImx1Q" guid="_5q5RyYGMEduKE9hnyImx1Q" anchor="_5q5RyIGMEduKE9hnyImx1Q _5q5RyoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeKYGMEduKE9hnyImx1Q" guid="_51BeKYGMEduKE9hnyImx1Q" anchor="_51BeKIGMEduKE9hnyImx1Q _51BeKoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WIANmEduYd-55D-Aiqg" guid="_O-9WIANmEduYd-55D-Aiqg" graphEdge="_O-9WIQNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVuwNnEduYd-55D-Aiqg" guid="_oHjVuwNnEduYd-55D-Aiqg" graphEdge="_oHjVvANnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOwO8EdubhrgDuRb4fA" guid="_D6EPOwO8EdubhrgDuRb4fA" graphEdge="_D6EPPAO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOwPMEdubhrgDuRb4fA" guid="_-EfTOwPMEdubhrgDuRb4fA" graphEdge="_-EfTPAPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTexTUEduFIr9xNbwGyQ" guid="_8ZSTexTUEduFIr9xNbwGyQ" graphEdge="_8ZSTfBTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RyIGMEduKE9hnyImx1Q" guid="_5q5RyIGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeKIGMEduKE9hnyImx1Q" guid="_51BeKIGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-xI0wNmEduYd-55D-Aiqg" guid="_O-xI0wNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-xI1ANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-9WEANmEduYd-55D-Aiqg" guid="_O-9WEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-9WEQNmEduYd-55D-Aiqg" guid="_O-9WEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-9WEgNmEduYd-55D-Aiqg" x="249.0" y="161.0"/>
+ <anchorage xmi:id="_O-9WIgNmEduYd-55D-Aiqg" guid="_O-9WIgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVvQNnEduYd-55D-Aiqg" guid="_oHjVvQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPPQO8EdubhrgDuRb4fA" guid="_D6EPPQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTPQPMEdubhrgDuRb4fA" guid="_-EfTPQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTfRTUEduFIr9xNbwGyQ" guid="_8ZSTfRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RzYGMEduKE9hnyImx1Q" guid="_5q5RzYGMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeLYGMEduKE9hnyImx1Q" guid="_51BeLYGMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-9WEwNmEduYd-55D-Aiqg" guid="_O-9WEwNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-9WFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OgNmEduYd-55D-Aiqg" guid="_O8q3OgNmEduYd-55D-Aiqg" presentation="Activity Detail" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_NSW6sQMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sQMAEduOAKqB9I73uw" briefDescription="Cette phase consiste à dérouler les sprints les uns après les autres " presentationName="Phase des sprints" isPlanned="false" superActivities="_9llsAQAvEdubGMceRDupFQ" linkToPredecessor="_9MP9UAMAEduOAKqB9I73uw" breakdownElements="_SoXWEQMAEduOAKqB9I73uw _zbM2QIGBEduKE9hnyImx1Q _MpXRYIGOEduKE9hnyImx1Q _RHd0YIGOEduKE9hnyImx1Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9MP9UAMAEduOAKqB9I73uw" guid="_9MP9UAMAEduOAKqB9I73uw" linkType="finishToFinish" pred="_37TdkAL_EduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zbM2QIGBEduKE9hnyImx1Q" name="Sprint de release" guid="_zbM2QIGBEduKE9hnyImx1Q" briefDescription="Ce dernier sprint permet de préparer la livraison du produit." presentationName="Travaux de livraison" isPlanned="true" isOptional="true" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" mandatoryInput="_RHd0YIGOEduKE9hnyImx1Q" output="_RHd0YIGOEduKE9hnyImx1Q" performedPrimarilyBy="_MpXRYIGOEduKE9hnyImx1Q">
+ <presentation xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-EOwIzNPjfNIjzJ3TRAgeWQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MpXRYIGOEduKE9hnyImx1Q" name="Team" guid="_MpXRYIGOEduKE9hnyImx1Q" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_NSW6sQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_RHd0YIGOEduKE9hnyImx1Q" name="Product increment" guid="_RHd0YIGOEduKE9hnyImx1Q" presentationName="Incrément de produit" superActivities="_NSW6sQMAEduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
+ </processElements>
+ <diagrams xmi:id="_N15QIAMBEduOAKqB9I73uw" guid="_N15QIAMBEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_N15QIQMBEduOAKqB9I73uw" guid="_N15QIQMBEduOAKqB9I73uw">
+ <position xmi:id="_N15QIgMBEduOAKqB9I73uw" x="204.0" y="49.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_APACQWaOEduYmqfjmBwflA" guid="_APACQWaOEduYmqfjmBwflA" anchor="_APACQGaOEduYmqfjmBwflA _APACQmaOEduYmqfjmBwflA"/>
+ <anchorage xmi:id="__iwAQmaNEduYmqfjmBwflA" guid="__iwAQmaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA"/>
+ <anchorage xmi:id="_APACQGaOEduYmqfjmBwflA" guid="_APACQGaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
+ <position xmi:id="_APACQ2aOEduYmqfjmBwflA" x="212.0" y="44.0"/>
+ </anchorage>
+ <anchorage xmi:id="_K_vA8maOEduYmqfjmBwflA" guid="_K_vA8maOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QIwMBEduOAKqB9I73uw" guid="_N15QIwMBEduOAKqB9I73uw" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_N15QJAMBEduOAKqB9I73uw" width="40.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8BvXoGaNEduYmqfjmBwflA" guid="_8BvXoGaNEduYmqfjmBwflA">
+ <position xmi:id="_8BvXoWaNEduYmqfjmBwflA" x="94.0" y="62.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__iwAQWaNEduYmqfjmBwflA" guid="__iwAQWaNEduYmqfjmBwflA" anchor="__iwAQGaNEduYmqfjmBwflA __iwAQmaNEduYmqfjmBwflA"/>
+ <anchorage xmi:id="__iwAQGaNEduYmqfjmBwflA" guid="__iwAQGaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA">
+ <position xmi:id="__iwAQ2aNEduYmqfjmBwflA" x="94.0" y="51.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8BvXomaNEduYmqfjmBwflA" guid="_8BvXomaNEduYmqfjmBwflA" typeInfo="start node"/>
+ <size xmi:id="_8BvXo2aNEduYmqfjmBwflA" width="19.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8oyJgGaNEduYmqfjmBwflA" guid="_8oyJgGaNEduYmqfjmBwflA">
+ <position xmi:id="_8oyJgWaNEduYmqfjmBwflA" x="613.0" y="60.0"/>
+ <anchorage xmi:id="_7lIDYoGEEduKE9hnyImx1Q" guid="_7lIDYoGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_hKUjEoGFEduKE9hnyImx1Q" guid="_hKUjEoGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8oyJgmaNEduYmqfjmBwflA" guid="_8oyJgmaNEduYmqfjmBwflA" typeInfo="end node"/>
+ <size xmi:id="_8oyJg2aNEduYmqfjmBwflA" width="26.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9kPFIGaNEduYmqfjmBwflA" guid="_9kPFIGaNEduYmqfjmBwflA">
+ <position xmi:id="_9kPFIWaNEduYmqfjmBwflA" x="343.0" y="60.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_K_vA8WaOEduYmqfjmBwflA" guid="_K_vA8WaOEduYmqfjmBwflA" anchor="_K_vA8GaOEduYmqfjmBwflA _K_vA8maOEduYmqfjmBwflA">
+ <waypoints xmi:id="_R-7AoGaOEduYmqfjmBwflA" x="363.0" y="17.0"/>
+ <waypoints xmi:id="_QXWl4GaOEduYmqfjmBwflA" x="222.0" y="17.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_a2plkYGFEduKE9hnyImx1Q" guid="_a2plkYGFEduKE9hnyImx1Q" anchor="_a2plkIGFEduKE9hnyImx1Q _a2plkoGFEduKE9hnyImx1Q">
+ <waypoints xmi:id="_DyIEkIGGEduKE9hnyImx1Q" x="363.0" y="133.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_hKUjEYGFEduKE9hnyImx1Q" guid="_hKUjEYGFEduKE9hnyImx1Q" anchor="_hKUjEIGFEduKE9hnyImx1Q _hKUjEoGFEduKE9hnyImx1Q">
+ <waypoints xmi:id="_9g1ssIGFEduKE9hnyImx1Q" x="575.0" y="71.0"/>
+ </contained>
+ <anchorage xmi:id="_APACQmaOEduYmqfjmBwflA" guid="_APACQmaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
+ <position xmi:id="_APACRGaOEduYmqfjmBwflA" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_K_vA8GaOEduYmqfjmBwflA" guid="_K_vA8GaOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA">
+ <position xmi:id="_K_vA82aOEduYmqfjmBwflA" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_a2plkIGFEduKE9hnyImx1Q" guid="_a2plkIGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q">
+ <position xmi:id="_Ais7MIGGEduKE9hnyImx1Q" x="21.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_hKUjEIGFEduKE9hnyImx1Q" guid="_hKUjEIGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q">
+ <position xmi:id="_9C4lYIGFEduKE9hnyImx1Q" x="42.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9kPFImaNEduYmqfjmBwflA" guid="_9kPFImaNEduYmqfjmBwflA" typeInfo="decision node"/>
+ <size xmi:id="_9kPFI2aNEduYmqfjmBwflA" width="43.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_-UpVwHoSEduJVrY6eKG_mw" name="Add Free Text" guid="_-UpVwHoSEduJVrY6eKG_mw">
+ <property xmi:id="_-UpVwXoSEduJVrY6eKG_mw" guid="_-UpVwXoSEduJVrY6eKG_mw" key="free text" value="livraison à préparer"/>
+ <position xmi:id="_-UpVwnoSEduJVrY6eKG_mw" x="377.0" y="102.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_-UpVw3oSEduJVrY6eKG_mw" guid="_-UpVw3oSEduJVrY6eKG_mw" typeInfo="free text"/>
+ <size xmi:id="_-UpVxHoSEduJVrY6eKG_mw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O1l_kHoTEduJVrY6eKG_mw" name="Add Free Text" guid="_O1l_kHoTEduJVrY6eKG_mw">
+ <property xmi:id="_O1l_kXoTEduJVrY6eKG_mw" guid="_O1l_kXoTEduJVrY6eKG_mw" key="free text" value="encore un sprint"/>
+ <position xmi:id="_O1l_knoTEduJVrY6eKG_mw" x="237.0" y="0.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_O1l_k3oTEduJVrY6eKG_mw" guid="_O1l_k3oTEduJVrY6eKG_mw" typeInfo="free text"/>
+ <size xmi:id="_O1l_lHoTEduJVrY6eKG_mw" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4SofQIGBEduKE9hnyImx1Q" guid="_4SofQIGBEduKE9hnyImx1Q">
+ <position xmi:id="_4SofQYGBEduKE9hnyImx1Q" x="457.0" y="104.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7lIDYYGEEduKE9hnyImx1Q" guid="_7lIDYYGEEduKE9hnyImx1Q" anchor="_7lIDYIGEEduKE9hnyImx1Q _7lIDYoGEEduKE9hnyImx1Q">
+ <waypoints xmi:id="_FGeBUIGGEduKE9hnyImx1Q" x="626.0" y="133.0"/>
+ </contained>
+ <anchorage xmi:id="_7lIDYIGEEduKE9hnyImx1Q" guid="_7lIDYIGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q">
+ <position xmi:id="_7lIDY4GEEduKE9hnyImx1Q" x="509.0" y="67.0"/>
+ </anchorage>
+ <anchorage xmi:id="_a2plkoGFEduKE9hnyImx1Q" guid="_a2plkoGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_4SofQoGBEduKE9hnyImx1Q" guid="_4SofQoGBEduKE9hnyImx1Q" element="_zbM2QIGBEduKE9hnyImx1Q"/>
+ <size xmi:id="_4SofQ4GBEduKE9hnyImx1Q" width="82.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JYpoMIGGEduKE9hnyImx1Q" name="Add Free Text" guid="_JYpoMIGGEduKE9hnyImx1Q">
+ <property xmi:id="_JYpoMYGGEduKE9hnyImx1Q" guid="_JYpoMYGGEduKE9hnyImx1Q" key="free text" value="fin de release"/>
+ <position xmi:id="_JYpoMoGGEduKE9hnyImx1Q" x="457.0" y="54.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JYpoM4GGEduKE9hnyImx1Q" guid="_JYpoM4GGEduKE9hnyImx1Q" typeInfo="free text"/>
+ <size xmi:id="_JYpoNIGGEduKE9hnyImx1Q" width="66.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QJQMBEduOAKqB9I73uw" guid="_N15QJQMBEduOAKqB9I73uw" presentation="Workflow" element="_NSW6sQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_E1ptMIF9EduKE9hnyImx1Q" guid="_E1ptMIF9EduKE9hnyImx1Q" linkType="finishToFinish" pred="_NSW6sQMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_XJr8krPCEduk5O8SjA21Fg" name="Product Owner" guid="_XJr8krPCEduk5O8SjA21Fg" suppressed="true" presentationName="Directeur Produit" superActivities="_9llsAQAvEdubGMceRDupFQ">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <diagrams xmi:id="_kZvAwAChEduhO59Otqg2rw" guid="_kZvAwAChEduhO59Otqg2rw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAwQChEduhO59Otqg2rw" guid="_kZvAwQChEduhO59Otqg2rw">
+ <position xmi:id="_kZvAwgChEduhO59Otqg2rw" x="124.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mj1g0QChEduhO59Otqg2rw" guid="_mj1g0QChEduhO59Otqg2rw" anchor="_mj1g0AChEduhO59Otqg2rw _mj1g0gChEduhO59Otqg2rw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_mkBuEQChEduhO59Otqg2rw" guid="_mkBuEQChEduhO59Otqg2rw"/>
+ </contained>
+ <anchorage xmi:id="_mj1g0AChEduhO59Otqg2rw" guid="_mj1g0AChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw">
+ <position xmi:id="_mj1g0wChEduhO59Otqg2rw" x="158.0" y="73.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAwwChEduhO59Otqg2rw" guid="_kZvAwwChEduhO59Otqg2rw"/>
+ <size xmi:id="_kZvAxAChEduhO59Otqg2rw" width="55.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAxQChEduhO59Otqg2rw" guid="_kZvAxQChEduhO59Otqg2rw">
+ <position xmi:id="_kZvAxgChEduhO59Otqg2rw" x="340.0" y="57.0"/>
+ <anchorage xmi:id="_mj1g0gChEduhO59Otqg2rw" guid="_mj1g0gChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAxwChEduhO59Otqg2rw" guid="_kZvAxwChEduhO59Otqg2rw"/>
+ <size xmi:id="_kZvAyAChEduhO59Otqg2rw" width="62.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Ew8_sACiEduhO59Otqg2rw" name="Add Free Text" guid="_Ew8_sACiEduhO59Otqg2rw">
+ <property xmi:id="_Ew8_sQCiEduhO59Otqg2rw" guid="_Ew8_sQCiEduhO59Otqg2rw" key="free text" value="les sprints successifs qui constituent la release"/>
+ <position xmi:id="_Ew8_sgCiEduhO59Otqg2rw" x="299.0" y="87.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Ew8_swCiEduhO59Otqg2rw" guid="_Ew8_swCiEduhO59Otqg2rw" typeInfo="free text"/>
+ <size xmi:id="_Ew8_tACiEduhO59Otqg2rw" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Nk0CAACiEduhO59Otqg2rw" name="Add Free Text" guid="_Nk0CAACiEduhO59Otqg2rw">
+ <property xmi:id="_Nk6IoACiEduhO59Otqg2rw" guid="_Nk6IoACiEduhO59Otqg2rw" key="free text" value="Phase initiale avant le premier sprint"/>
+ <position xmi:id="_Nk6IoQCiEduhO59Otqg2rw" x="134.0" y="89.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Nk6IogCiEduhO59Otqg2rw" guid="_Nk6IogCiEduhO59Otqg2rw" typeInfo="free text"/>
+ <size xmi:id="_Nk6IowCiEduhO59Otqg2rw" width="72.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5YwkAEKEduzRosbOajx7w" guid="_G5YwkAEKEduzRosbOajx7w">
+ <position xmi:id="_G5e3MAEKEduzRosbOajx7w" x="109.0" y="43.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ivhy0QEKEduzRosbOajx7w" guid="_Ivhy0QEKEduzRosbOajx7w" anchor="_Ivhy0AEKEduzRosbOajx7w _Ivhy0gEKEduzRosbOajx7w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_Iv0GsQEKEduzRosbOajx7w" guid="_Iv0GsQEKEduzRosbOajx7w"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ZSAOMQEsEduzRosbOajx7w" guid="_ZSAOMQEsEduzRosbOajx7w" anchor="_ZSAOMAEsEduzRosbOajx7w _ZSAOMgEsEduzRosbOajx7w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZSSiEQEsEduzRosbOajx7w" guid="_ZSSiEQEsEduzRosbOajx7w"/>
+ </contained>
+ <anchorage xmi:id="_Ivhy0AEKEduzRosbOajx7w" guid="_Ivhy0AEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w">
+ <position xmi:id="_Ivhy0wEKEduzRosbOajx7w" x="152.0" y="58.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ZSAOMAEsEduzRosbOajx7w" guid="_ZSAOMAEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w">
+ <position xmi:id="_ZSAOMwEsEduzRosbOajx7w" x="135.0" y="60.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3MQEKEduzRosbOajx7w" guid="_G5e3MQEKEduzRosbOajx7w"/>
+ <size xmi:id="_G5e3MgEKEduzRosbOajx7w" width="55.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5e3MwEKEduzRosbOajx7w" guid="_G5e3MwEKEduzRosbOajx7w">
+ <position xmi:id="_G5e3NAEKEduzRosbOajx7w" x="337.0" y="41.0"/>
+ <anchorage xmi:id="_Ivhy0gEKEduzRosbOajx7w" guid="_Ivhy0gEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3NQEKEduzRosbOajx7w" guid="_G5e3NQEKEduzRosbOajx7w"/>
+ <size xmi:id="_G5e3NgEKEduzRosbOajx7w" width="83.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GOyb8AEsEduzRosbOajx7w" guid="_GOyb8AEsEduzRosbOajx7w">
+ <position xmi:id="_GOyb8QEsEduzRosbOajx7w" x="359.0" y="43.0"/>
+ <anchorage xmi:id="_ZSAOMgEsEduzRosbOajx7w" guid="_ZSAOMgEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GOyb8gEsEduzRosbOajx7w" guid="_GOyb8gEsEduzRosbOajx7w"/>
+ <size xmi:id="_GOyb8wEsEduzRosbOajx7w" width="32.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-4AMAEduOAKqB9I73uw" guid="_6wY-4AMAEduOAKqB9I73uw">
+ <position xmi:id="_6wY-4QMAEduOAKqB9I73uw" x="112.0" y="25.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9LxcMQMAEduOAKqB9I73uw" guid="_9LxcMQMAEduOAKqB9I73uw" anchor="_9LxcMAMAEduOAKqB9I73uw _9LxcMgMAEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9MP9UQMAEduOAKqB9I73uw" guid="_9MP9UQMAEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_9LxcMAMAEduOAKqB9I73uw" guid="_9LxcMAMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw">
+ <position xmi:id="_9LxcMwMAEduOAKqB9I73uw" x="151.0" y="42.0"/>
+ </anchorage>
+ <anchorage xmi:id="_D3KWIgMBEduOAKqB9I73uw" guid="_D3KWIgMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-4gMAEduOAKqB9I73uw" guid="_6wY-4gMAEduOAKqB9I73uw" element="_37TdkAL_EduOAKqB9I73uw"/>
+ <size xmi:id="_6wY-4wMAEduOAKqB9I73uw" width="103.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-5AMAEduOAKqB9I73uw" guid="_6wY-5AMAEduOAKqB9I73uw">
+ <position xmi:id="_6wY-5QMAEduOAKqB9I73uw" x="295.0" y="25.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_EPaeEQMBEduOAKqB9I73uw" guid="_EPaeEQMBEduOAKqB9I73uw" anchor="_EPaeEAMBEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_E1ptMYF9EduKE9hnyImx1Q" guid="_E1ptMYF9EduKE9hnyImx1Q"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_DVQF4YGHEduKE9hnyImx1Q" guid="_DVQF4YGHEduKE9hnyImx1Q" anchor="_DVQF4IGHEduKE9hnyImx1Q _DVQF4oGHEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_9LxcMgMAEduOAKqB9I73uw" guid="_9LxcMgMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_EPaeEAMBEduOAKqB9I73uw" guid="_EPaeEAMBEduOAKqB9I73uw" graphEdge="_EPaeEQMBEduOAKqB9I73uw">
+ <position xmi:id="_EPaeEwMBEduOAKqB9I73uw" x="340.0" y="44.0"/>
+ </anchorage>
+ <anchorage xmi:id="_DVQF4IGHEduKE9hnyImx1Q" guid="_DVQF4IGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q">
+ <position xmi:id="_ENbrEIGHEduKE9hnyImx1Q" x="343.0" y="41.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-5gMAEduOAKqB9I73uw" guid="_6wY-5gMAEduOAKqB9I73uw" element="_NSW6sQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_6wY-5wMAEduOAKqB9I73uw" width="87.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_CL_00AMBEduOAKqB9I73uw" guid="_CL_00AMBEduOAKqB9I73uw">
+ <position xmi:id="_CL_00QMBEduOAKqB9I73uw" x="39.0" y="38.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D3KWIQMBEduOAKqB9I73uw" guid="_D3KWIQMBEduOAKqB9I73uw" anchor="_D3KWIAMBEduOAKqB9I73uw _D3KWIgMBEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_D3KWIAMBEduOAKqB9I73uw" guid="_D3KWIAMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw">
+ <position xmi:id="_D3KWIwMBEduOAKqB9I73uw" x="46.0" y="44.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_CL_00gMBEduOAKqB9I73uw" guid="_CL_00gMBEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_CL_00wMBEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DDxxYAMBEduOAKqB9I73uw" guid="_DDxxYAMBEduOAKqB9I73uw">
+ <position xmi:id="_DD34AAMBEduOAKqB9I73uw" x="456.0" y="36.0"/>
+ <anchorage xmi:id="_DVQF4oGHEduKE9hnyImx1Q" guid="_DVQF4oGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DD34AQMBEduOAKqB9I73uw" guid="_DD34AQMBEduOAKqB9I73uw" typeInfo="end node"/>
+ <size xmi:id="_DD34AgMBEduOAKqB9I73uw" width="24.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAyQChEduhO59Otqg2rw" guid="_kZvAyQChEduhO59Otqg2rw" presentation="Workflow" element="_9llsAQAvEdubGMceRDupFQ"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:DeliveryProcess" xmi:id="_9llsAQAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAQAvEdubGMceRDupFQ" briefDescription="Les phases, les sprints et les tâches à dérouler lors de la production d'une release." presentationName="Release" isRepeatable="true" breakdownElements="_37TdkAL_EduOAKqB9I73uw _NSW6sQMAEduOAKqB9I73uw _XJr8krPCEduk5O8SjA21Fg">
+ <presentation xmi:id="-16dzhVoCex78V2iCDZVx0w" href="uma://-16dzhVoCex78V2iCDZVx0w#-16dzhVoCex78V2iCDZVx0w"/>
+ <concepts href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_XtRuYP-zEdqLnajTSLeAsA"/>
+ <defaultContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
+ <validContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/csm.jpg b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif
new file mode 100644
index 0000000..e7d73b3
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
new file mode 100644
index 0000000..bc69128
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.png b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.png
new file mode 100644
index 0000000..a91525c
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/deliveryprocesses/resources/icescrum_simple.png
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/disciplines/Scrum activities.xmi b/Scrum/Scrum_PT/library/Scrum/disciplines/Scrum activities.xmi
new file mode 100644
index 0000000..48a8e24
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/disciplines/Scrum activities.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" name="Scrum activities,_6sdMAAL-EduOAKqB9I73uw" guid="-4wqJQ0qXLYZ8kCnpDu--tA" changeDate="2006-12-03T10:43:16.000+0100" version="1.0.0">
+ <mainDescription><p>
+ L'application de Scrum concerne essentiellement&nbsp;les disciplines habituelles de gestion de projet et de gestion des
+ exigences.
+</p></mainDescription>
+ <keyConsiderations>Une bonne partie de ces activités est effectuée collectivement,&nbsp;en équipe.</keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Presentation Scrum.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Presentation Scrum.xmi
new file mode 100644
index 0000000..b707be0
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Presentation Scrum.xmi
@@ -0,0 +1,81 @@
+<?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" epf:version="1.0.0" xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" name="new_concept,_3WivIBTQEduFIr9xNbwGyQ" guid="-MSO8KF-0IlKZJGnSwwTNZA" changeDate="2006-12-03T08:21:54.843+0100" version="1.0.0">
+ <mainDescription><p>
+ Scrum est un processus léger et itératif de gestion de projets, qui fait partie de la famille des <a
+ title="Méthode agile" href="http://fr.wikipedia.org/wiki/Méthode_agile">méthodes agiles</a>, qui partage les valeurs
+ définies dans le Manifeste Agile et qui en reprend les principes fondamentaux.
+</p>
+<h5>
+ Résumé
+</h5>
+<p>
+ Scrum peut se résumer ainsi :
+</p>
+<p class="quote">
+ Scrum conduit à montrer souvent et régulièrement (toutes les 2 à 4 semaines, selon la durée du <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>) un produit (partiel) qui fonctionne. Le métier identifie les exigences et
+ définit leur priorité. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les
+ plus prioritaires. A chaque fin de sprint, tout le monde peut voir fonctionner le produit actuel et contribuer à
+ prendre une décision sur ce qu'on fait&nbsp;: soit le livrer dans l'état, soit continuer à l'améliorer pendant&nbsp;un
+ sprint&nbsp;supplémentaire avant de se reposer la question.
+</p>
+<h5>
+ Origine
+</h5>
+<p>
+ Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée,
+ qui cherche à atteindre un but, comme c'est le cas au rugby quand le pack déploie sa force collective pour avancer avec
+ le ballon pendant une mêlée.
+</p>
+<p>
+ Scrum insiste particulièrement sur l’aspect social et collectif du développement. Le but de Scrum est d'améliorer la
+ qualité et la productivité, avec une approche empirique, en s'appuyant sur l'autonomie de l'équipe.
+</p>
+<h5>
+ Empirisme
+</h5>
+<p>
+ Un processus empirique, donc basé sur l'expérience, nécessite une bonne visibilité, des inspections fréquentes et des
+ adaptations aux plans. Cela se décline dans Scrum par les 2 cycles de régulation&nbsp;:
+</p>
+<ul>
+ <li>
+ lors de mêlées quotidiennes, on tient compte de l'expérience du jour passé pour adapter le planning des jours
+ restant dans le sprint.
+ </li>
+ <li>
+ lors des revues de sprint, on tient compte de l'expérience du sprint passé pour adapter le planning de la release,
+ portant sur les sprints à venir.
+ </li>
+</ul>
+<p>
+ Les tâches d'un sprint ne sont pas définies de façon très précise : pas de date de début, pas de date de fin, pas de
+ dépendance. Scrum considère que ce n'est pas prévisible. L'empirisme de Scrum consiste à s'appuyer continuellement sur
+ l'analyse de l'état courant du projet pour contrôler le processus et réduire les risques.
+</p>
+<h5>
+ Portée
+</h5>
+<p>
+ Scrum ne décrit pas toutes les disciplines du développement (analyse, conception, codage, test) et doit être considéré,
+ plutôt qu’un processus complet, comme un pattern de processus qui est&nbsp;concerne la gestion de projet et la gestion
+ des exigences. Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement. C'est à
+ l'équipe de définir elle-même ce qu'elle à faire.
+</p>
+<h5>
+ Diffusion
+</h5>
+<p>
+ Scrum existe depuis les années 90 et connaît une popularité croissante depuis quelques années. Il a été utilisé sur des
+ centaines de projets dans le monde, mais est pour l’instant peu introduit en France. Depuis 3 ans, un processus de
+ certification a été mis en place. En novembre 2006, plus de 7000 personnes avaient obtenu la certification ScrumMaster.
+</p>
+<p>
+ &nbsp;<img height="56" alt="ScrumMaster" src="./resources/csm.jpg" width="179" />
+</p>
+<p>
+ Pour plus d'informations sur Scrum, voir <a href="http://fr.wikipedia.org/wiki/Scrum"
+ target="_blank">http://fr.wikipedia.org/wiki/Scrum</a>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Produit, release et sprint.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Produit, release et sprint.xmi
new file mode 100644
index 0000000..6d73875
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Produit, release et sprint.xmi
@@ -0,0 +1,37 @@
+<?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" epf:version="1.0.0" xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" name="Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA" guid="-BPz1k8sC6CCyJ2yZCc1p2Q" changeDate="2006-12-02T00:54:40.221+0100" version="1.0.0">
+ <mainDescription><p>
+ Une <a class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>&nbsp;est constituée d'une série de <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s et dure en général quelques mois. Pendant la vie d'un produit, on déroule
+ plusieurs releases.
+</p>
+<p>
+ <img height="115" alt="release et sprints" src="./resources/release.jpg" width="600" />
+</p>
+<p>
+ Une release a les attributs suivants :
+</p>
+<ul class="noindent">
+ <li>
+ le but
+ </li>
+ <li>
+ le type, à choisir entre "à date fixée" et "sans date fixée"(par défaut). Dans le cas où on choisit à date fixée,
+ la date est fournie.
+ </li>
+ <li>
+ la durée, en nombre de jours, définie pour les sprints
+ </li>
+ <li>
+ le nombre de sprints&nbsp;prévus
+ </li>
+</ul>
+<p>
+ Le <a class="elementLink" href="./../../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;constitue un niveau de planification du projet : il
+ montre de façon "grosses mailles" les items qu'il est prévu de réaliser au cours des sprints de cette release.<br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Travail collaboratif.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Travail collaboratif.xmi
new file mode 100644
index 0000000..55eac7a
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/Travail collaboratif.xmi
@@ -0,0 +1,134 @@
+<?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" epf:version="1.0.0" xmi:id="-dU_t9olFRQIyOBZQvMndKg" name="new_concept,_OUjj0AEZEduzRosbOajx7w" guid="-dU_t9olFRQIyOBZQvMndKg" changeDate="2006-12-04T21:17:26.750+0100">
+ <mainDescription><p>
+ Le collectif prend forme à travers des réunions. Scrum impose 5 types de réunions :&nbsp;
+</p>
+<ol>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>&nbsp;(1ème partie, sélection du sous-ensemble du backlog))
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>nt (2ème&nbsp;partie, planification du sprint)
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A.html"
+ guid="_d09LYP_AEdqtbrr0B1TG-A">Mêlée quotidienne</a>
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Review sprint,_MRrRYPpbEdqsc-f87sBK8A.html"
+ guid="_MRrRYPpbEdqsc-f87sBK8A">Faire la revue du sprint</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Retrospective,_J_sRIP_AEdqtbrr0B1TG-A.html"
+ guid="_J_sRIP_AEdqtbrr0B1TG-A">Rétrospective</a><br />
+ </li>
+</ol>
+<p>
+ Le tableau ci-dessous montre la participation des rôles Scrum à ces réunions :<br />
+</p>
+<table cellspacing="2" cellpadding="2" width="180" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ 1
+ </th>
+ <th scope="col">
+ 2
+ </th>
+ <th scope="col">
+ 3
+ </th>
+ <th scope="col">
+ 4
+ </th>
+ <th scope="col">
+ 5
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+ </th>
+ <td>
+ Animation
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Equipe
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Intervenant
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ Possible
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/clip_image001.png b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/clip_image001.png
new file mode 100644
index 0000000..32678ac
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/clip_image001.png
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/clip_image002.gif b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/clip_image002.gif
new file mode 100644
index 0000000..aa6b057
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/clip_image002.gif
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/csm.jpg b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/release.jpg b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/release.jpg
new file mode 100644
index 0000000..a270cd4
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/concepts/resources/release.jpg
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/examples/resources/demo_banque_2.JPG b/Scrum/Scrum_PT/library/Scrum/guidances/examples/resources/demo_banque_2.JPG
new file mode 100644
index 0000000..046308b
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/examples/resources/demo_banque_2.JPG
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/reports/Release Burndown Chart.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/reports/Release Burndown Chart.xmi
new file mode 100644
index 0000000..434f1c4
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/reports/Release Burndown Chart.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" name="Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A" guid="-pJuF9iKbSQx7TIwHNBVTgg" changeDate="2006-12-03T15:16:09.515+0100">
+ <mainDescription><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour une release :&nbsp;il montre la tendance dans
+ l'avancement de la release par une présentation graphique du reste à faire à la fin de chaque sprint passé.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/reports/Release Planning.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/reports/Release Planning.xmi
new file mode 100644
index 0000000..9360ab0
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/reports/Release Planning.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" name="new_report,_Z2NzkIGWEduKE9hnyImx1Q" guid="-EmLqiNX2WnmsfEtxNiuyTQ" changeDate="2006-12-02T00:51:59.549+0100">
+ <mainDescription><p>
+ Il est dérivé du backlog de produit : c'est un sous-ensemble contenant uniquement les éléments prévus dans la release
+ et associés aux sprints prévus dans la release.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi
new file mode 100644
index 0000000..10e80bb
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-qVeT6_sAspmZjCYQLOrhbg" name="Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A" guid="-qVeT6_sAspmZjCYQLOrhbg" changeDate="2006-12-03T15:17:51.046+0100">
+ <mainDescription><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour un sprint :&nbsp;il montre la tendance dans
+ l'avancement du sprint par une présentation graphique du reste à faire à la fin de chaque jour passé.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/roadmaps/Application.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/roadmaps/Application.xmi
new file mode 100644
index 0000000..5ade8ce
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/roadmaps/Application.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" name="new_roadmap,_6Jox0IRuEduo75chJsIcXg" guid="-IPxNSDzXKWa-H_kJ2PMtYA" changeDate="2006-12-05T16:29:34.781+0100">
+ <mainDescription><p>
+ Le&nbsp;Manifeste Agile proclame que "les outils et les processus sont utiles, mais que&nbsp;les personnes et les
+ interactions qu'elles ont entre elles sont plus importantes" pour la réussite du projet. Il faut garder ce principe à
+ l'esprit lors de l'application de Scrum. Il convient également de respecter les&nbsp;caractéristiques de Scrum comme :
+</p>
+<ul>
+ <li>
+ l'approche empirique basée sur la régulation,
+ </li>
+ <li>
+ la planification adaptative plutôt que prédictive,
+ </li>
+ <li>
+ l'auto-gestion de l'équipe pour faire ce qu'elle a à faire.
+ </li>
+</ul>
+<p>
+ De plus, Scrum ne décrit pas les activités d'ingénierie nécessaires à la réalisation du produit.
+</p>
+<p>
+ L'application de Scrum décrite ci-dessous&nbsp;doit être lue et utilisée&nbsp;à l'aune de ces principes agiles. Elle
+ montre comment les éléments de Scrum sont utilisés lors du déroulement d'une période de temps,&nbsp;ou cycle de vie.
+</p>
+<p>
+ Ce cycle de vie ne représente pas toute la vie d'un produit, mais porte uniquement sur la production d'une <a
+ class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>. Le guide <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA.html"
+ guid="_XtRuYP-zEdqLnajTSLeAsA">Produit, release et sprint</a>&nbsp;replace cette période dans un contexte plus large.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Copyright.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Copyright.xmi
new file mode 100644
index 0000000..09ba739
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Copyright.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-03XtfjRMEs23qIdCSSQiNQ" name="new_supporting_material,_N8zs0AEGEduzRosbOajx7w" guid="-03XtfjRMEs23qIdCSSQiNQ" changeDate="2007-02-03T11:40:46.906-0800" version="1.0.0">
+ <mainDescription>Ce programme et le matériel qui l'accompagne sont mis à disposition selon les termes de la licence "<a
+href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a>" qui régit cette
+distribution.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Introduction.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Introduction.xmi
new file mode 100644
index 0000000..8254917
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Introduction.xmi
@@ -0,0 +1,24 @@
+<?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" epf:version="1.0.0" xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" name="Introduction,_wz30kABREdu3o4yroaI-tA" guid="-WfzsSn3X35gSHQZ2kqtoVw" changeDate="2006-12-04T21:23:34.453+0100">
+ <mainDescription><p>
+ Ce plugin, réalisé&nbsp;avec&nbsp;<a href="http://www.eclipse.org/epf/" target="_blank">EPF</a> (Eclipse&nbsp;Process
+ Framework)&nbsp;présente :
+</p>
+<ul>
+ <li>
+ une introduction à <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Presentation Scrum,_3WivIBTQEduFIr9xNbwGyQ.html"
+ guid="_3WivIBTQEduFIr9xNbwGyQ">Scrum</a>
+ </li>
+ <li>
+ les notions principales de Scrum (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Scrum Elements,_nF6fgALYEduFv7wnrO7SvQ.html"
+ guid="_nF6fgALYEduFv7wnrO7SvQ">Eléments Scrum</a>),
+ </li>
+ <li>
+ une façon de les appliquer (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Cycle de vie Scrum,_7BSBkABCEduYUKPFgCzFuA.html"
+ guid="_7BSBkABCEduYUKPFgCzFuA">Cycle de vie</a>) qui est à adapter à chaque projet.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Scrum references.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Scrum references.xmi
new file mode 100644
index 0000000..a1f2561
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/supportingmaterials/Scrum references.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-cfa6bdUgQuboNpJRKaCLAw" name="Scrum referencesl,_PTGe4IRvEduo75chJsIcXg" guid="-cfa6bdUgQuboNpJRKaCLAw" changeDate="2006-12-05T15:45:31.406+0100">
+ <mainDescription><ul>
+ <li>
+ Ken Schwaber&nbsp;: <a href="http://softpro.stores.yahoo.net/0-7356-1993-x.html" target="_blank">Agile Project
+ Management with Scrum.</a>&nbsp;
+ </li>
+ <li>
+ Mike Cohn&nbsp;: <a
+ href="http://www.amazon.fr/exec/obidos/ASIN/0131479415/sr=8-1/qid=1152998855/ref=sr_1_1/402-4433368-7461703?_encoding=UTF8&amp;s=gateway&amp;v=glance"
+ target="_blank">Agile Estimating and Planning</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi
new file mode 100644
index 0000000..63ce6f7
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" name="new_term_definition,_X5rREILYEduLd8CaF_IcMA" guid="-KQ4Jzjy6YgAr_2NXa4J67g">
+ <mainDescription>Représentation graphique du reste à faire dans une période, actualisée aussi souvent que possible.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Release.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Release.xmi
new file mode 100644
index 0000000..46444c0
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Release.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" name="Release,_AIB9gIHrEduFs9jH8xc4xw" guid="-XPyPmZTAVbnvJVuOLvYpXw" changeDate="2006-12-02T10:53:51.187+0100" version="1.0.0">
+ <mainDescription>Une release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps
+qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Sprint.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Sprint.xmi
new file mode 100644
index 0000000..0af2272
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Sprint.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" name="new_term_definition,_kftWoIHqEduFs9jH8xc4xw" guid="-fcoz1Nm_QnX6xtLg5YWdVg" changeDate="2006-12-02T10:51:49.500+0100">
+ <mainDescription>Un sprint est un bloc de temps aboutissant à créer un incrément du produit. C'est le terme utilisé dans Scrum pour
+itération.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Theme.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Theme.xmi
new file mode 100644
index 0000000..2814df0
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Theme.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-GKfSarwQLoaHhoT71FQI8Q" name="new_term_definition,_aeYKoIKlEduQgtHqedKdMA" guid="-GKfSarwQLoaHhoT71FQI8Q" changeDate="2006-12-03T09:09:30.312+0100">
+ <mainDescription>Un thème constitue un regroupement fonctionnel d'exigences.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Timebox.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Timebox.xmi
new file mode 100644
index 0000000..0d19473
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Timebox.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-tHVOELWOQDI7i0M2rlMufQ" name="new_term_definition,_3qdXkILXEduLd8CaF_IcMA" guid="-tHVOELWOQDI7i0M2rlMufQ" changeDate="2006-12-03T15:11:12.609+0100">
+ <mainDescription>Une période de temps à échéance fixée et intangible même si tous les objectifs ne sont pas atteints.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Velocity.xmi b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Velocity.xmi
new file mode 100644
index 0000000..ac28bb4
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/guidances/termdefinitions/Velocity.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" name="new_term_definition,_HQEP8ILXEduLd8CaF_IcMA" guid="-PeP4fADValHXs2Z2Z8zJ1w" changeDate="2007-01-29T09:14:31.140+0100" version="1.0.0">
+ <mainDescription>La vélocité est la mesure de la capacité de l'équipe pendant un sprint.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/plugin.xmi b/Scrum/Scrum_PT/library/Scrum/plugin.xmi
new file mode 100644
index 0000000..1789c5d
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/plugin.xmi
@@ -0,0 +1,197 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_5AUAUPpYEdqsc-f87sBK8A" guid="_5AUAUPpYEdqsc-f87sBK8A">
+ <subManagers xmi:id="_9m1CIAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9m1CIAAvEdubGMceRDupFQ"/>
+ <resourceDescriptors xmi:id="_5AUAUfpYEdqsc-f87sBK8A" id="-Y3SFEe-A-lRF8TaEn9vKNQ" uri="roles/ScrumMaster.xmi"/>
+ <resourceDescriptors xmi:id="_N_XCIf-0EdqLnajTSLeAsA" id="-CgLjZ6Bwc0EyYyQCjzlw7g" uri="rolesets/Scrum%20Roles.xmi"/>
+ <resourceDescriptors xmi:id="_aziTsP--Edqtbrr0B1TG-A" id="-NRwwk6YGAtu25V3Lc04G6w" uri="tasks/Plan%20sprint%202.xmi"/>
+ <resourceDescriptors xmi:id="_9lx5QAAvEdubGMceRDupFQ" id="_9llsAAAvEdubGMceRDupFQ" uri="deliveryprocesses/Scrum/model.xmi"/>
+ <resourceDescriptors xmi:id="_qJ7PoABSEdu3o4yroaI-tA" id="-juIDa_fXi2K1BE5NTblPow" uri="customcategories/Intro.xmi"/>
+ <resourceDescriptors xmi:id="_OY10sABaEdu3o4yroaI-tA" id="-WfzsSn3X35gSHQZ2kqtoVw" uri="guidances/supportingmaterials/Introduction.xmi"/>
+ <resourceDescriptors xmi:id="_hhv8QAB7EduSVaTQTBfIHA" id="-35iKPqDM2F2PjKWQLCW4tA" uri="roles/Product%20Owner.xmi"/>
+ <resourceDescriptors xmi:id="_hh2C4AB7EduSVaTQTBfIHA" id="-mZfAV7RcWJlp5idlHzeEcA" uri="tasks/Manage%20problems.xmi"/>
+ <resourceDescriptors xmi:id="_rosG4AEGEduzRosbOajx7w" id="-03XtfjRMEs23qIdCSSQiNQ" uri="guidances/supportingmaterials/Copyright.xmi"/>
+ <resourceDescriptors xmi:id="_kTIcUAELEduzRosbOajx7w" id="-eSc2tcV1h17HBw_s8ROEVw" uri="workproducttypes/Backlogs.xmi"/>
+ <resourceDescriptors xmi:id="_K5MbwAEPEduzRosbOajx7w" id="-Of1SdnAQ9nmsL5DFvD2Uug" uri="workproducts/Product%20Backlog.xmi"/>
+ <resourceDescriptors xmi:id="_K5MbwQEPEduzRosbOajx7w" id="-LVZG5zK2YjEGXO3SwDmqug" uri="roles/Team.xmi"/>
+ <resourceDescriptors xmi:id="_K5YpAAEPEduzRosbOajx7w" id="-u0-b4PNo9XzOh1-dv_aaKA" uri="roles/StakeHolder.xmi"/>
+ <resourceDescriptors xmi:id="_AaX3AAEQEduzRosbOajx7w" id="-8V2DOvzUhvtqwWvTOHMB5g" uri="workproducts/Sprint%20backlog.xmi"/>
+ <resourceDescriptors xmi:id="_A0kNwQESEduzRosbOajx7w" id="-zoJryMCuHfxWP7Q5Er195Q" uri="tasks/Review%20sprint.xmi"/>
+ <resourceDescriptors xmi:id="_A0qUYAESEduzRosbOajx7w" id="-vDOuVl_xPKipKd90HQNZng" uri="tasks/Scrum%20daily%20meeting.xmi"/>
+ <resourceDescriptors xmi:id="_A0qUYQESEduzRosbOajx7w" id="-XdgedeazfFRGDxMY3Fnh5g" uri="tasks/Update%20product%20backlog.xmi"/>
+ <resourceDescriptors xmi:id="_wj_I8AEWEduzRosbOajx7w" id="-S4qXwp40l_8eCcyyI7o-3A" uri="tasks/Retrospective.xmi"/>
+ <resourceDescriptors xmi:id="_WYwq0QEZEduzRosbOajx7w" id="-dU_t9olFRQIyOBZQvMndKg" uri="guidances/concepts/Travail%20collaboratif.xmi"/>
+ <resourceDescriptors xmi:id="_pWgXYAL_EduOAKqB9I73uw" id="-4wqJQ0qXLYZ8kCnpDu--tA" uri="disciplines/Scrum%20activities.xmi"/>
+ <resourceDescriptors xmi:id="_PitjwQOwEduJnc8byNAQ9Q" id="-zS9h38tmK4L-U9kbgkpGKQ" uri="customcategories/Scrum%20Elements.xmi"/>
+ <resourceDescriptors xmi:id="_XQS7sAPKEdubhrgDuRb4fA" id="-3f4axrWBKHGv74oKN2x-gQ" uri="tasks/Plan%20release.xmi"/>
+ <resourceDescriptors xmi:id="_XQZCUAPKEdubhrgDuRb4fA" id="-mi1O4H7RRm0YqlUNyp8TJg" uri="tasks/Initiate%20Product%20Backlog.xmi"/>
+ <resourceDescriptors xmi:id="_E6ZVsBTREduFIr9xNbwGyQ" id="-MSO8KF-0IlKZJGnSwwTNZA" uri="guidances/concepts/Presentation%20Scrum.xmi"/>
+ <resourceDescriptors xmi:id="_ZllqMDwUEdun48PxFCzHCw" id="-BPz1k8sC6CCyJ2yZCc1p2Q" uri="guidances/concepts/Produit,%20release%20et%20sprint.xmi"/>
+ <resourceDescriptors xmi:id="_tO6jEHpCEdug1NkGFo_hTg" id="-6aCUL_kawJFNBtfH_sRXkw" uri="workproducts/Product%20increment.xmi"/>
+ <resourceDescriptors xmi:id="_5nqe4IGJEduKE9hnyImx1Q" id="-KC1R73i9f6P7ZT4pgBOLzA" uri="workproducts/Product%20Backlog%20Item.xmi"/>
+ <resourceDescriptors xmi:id="_74nh8YGWEduKE9hnyImx1Q" id="-EmLqiNX2WnmsfEtxNiuyTQ" uri="guidances/reports/Release%20Planning.xmi"/>
+ <resourceDescriptors xmi:id="_U_2y4IHpEdu3SZQ-Dp1OAA" id="-6UJtuFO3WFBFpJOFeV1QMQ" uri="workproducts/Sprint%20Backlog%20Item.xmi"/>
+ <resourceDescriptors xmi:id="_1MHpkIHqEduFs9jH8xc4xw" id="-fcoz1Nm_QnX6xtLg5YWdVg" uri="guidances/termdefinitions/Sprint.xmi"/>
+ <resourceDescriptors xmi:id="_DD7t8IHrEduFs9jH8xc4xw" id="-XPyPmZTAVbnvJVuOLvYpXw" uri="guidances/termdefinitions/Release.xmi"/>
+ <resourceDescriptors xmi:id="_mmlSkIKlEduQgtHqedKdMA" id="-GKfSarwQLoaHhoT71FQI8Q" uri="guidances/termdefinitions/Theme.xmi"/>
+ <resourceDescriptors xmi:id="_P8d_YILXEduLd8CaF_IcMA" id="-PeP4fADValHXs2Z2Z8zJ1w" uri="guidances/termdefinitions/Velocity.xmi"/>
+ <resourceDescriptors xmi:id="_IbymwILYEduLd8CaF_IcMA" id="-tHVOELWOQDI7i0M2rlMufQ" uri="guidances/termdefinitions/Timebox.xmi"/>
+ <resourceDescriptors xmi:id="_tOn1YILYEduLd8CaF_IcMA" id="-KQ4Jzjy6YgAr_2NXa4J67g" uri="guidances/termdefinitions/Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_-wFhAILYEduLd8CaF_IcMA" id="-pJuF9iKbSQx7TIwHNBVTgg" uri="guidances/reports/Release%20Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_LCa1UILZEduLd8CaF_IcMA" id="-qVeT6_sAspmZjCYQLOrhbg" uri="guidances/reports/Sprint%20Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_egmj0IRvEduo75chJsIcXg" id="-cfa6bdUgQuboNpJRKaCLAw" uri="guidances/supportingmaterials/Scrum%20references.xmi"/>
+ <resourceDescriptors xmi:id="_cpeaYYSAEduo75chJsIcXg" id="-IPxNSDzXKWa-H_kJ2PMtYA" uri="guidances/roadmaps/Application.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" name="Scrum" guid="_mQ3eoPpYEdqsc-f87sBK8A" briefDescription="Ce plugin porte sur l'utilisation de Scrum." authors="Claude Aubry" changeDate="2006-12-05T18:52:42.109+0100" version="1.0" copyrightStatement="_N8zs0AEGEduzRosbOajx7w">
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eofpYEdqsc-f87sBK8A" name="Content" guid="_mQ3eofpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eovpYEdqsc-f87sBK8A" name="Categories" guid="_mQ3eovpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eo_pYEdqsc-f87sBK8A" name="Domains" guid="_mQ3eo_pYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:Domain" xmi:id="_AcwmAANoEduYd-55D-Aiqg" name="Scrum Artefacts" guid="_AcwmAANoEduYd-55D-Aiqg" presentationName="Produits Scrum" workProducts="_tCmYEP-xEdqLnajTSLeAsA _5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epPpYEdqsc-f87sBK8A" name="Disciplines" guid="_mQ3epPpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_6sdMAAL-EduOAKqB9I73uw" name="Scrum activities" guid="_6sdMAAL-EduOAKqB9I73uw" briefDescription="Les activités spécifiques induites par l'application de Scrum." presentationName="Activités Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" tasks="_Xpd5gP_AEdqtbrr0B1TG-A _STkWYP_BEdqtbrr0B1TG-A _ho-aIP_BEdqtbrr0B1TG-A _4LOggPpaEdqsc-f87sBK8A _J_sRIP_AEdqtbrr0B1TG-A _MRrRYPpbEdqsc-f87sBK8A _d09LYP_AEdqtbrr0B1TG-A _BGFMoANkEduYd-55D-Aiqg">
+ <presentation xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" href="uma://-4wqJQ0qXLYZ8kCnpDu--tA#-4wqJQ0qXLYZ8kCnpDu--tA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epfpYEdqsc-f87sBK8A" name="RoleSets" guid="_mQ3epfpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_3qmmoP-zEdqLnajTSLeAsA" name="Scrum Roles" guid="_3qmmoP-zEdqLnajTSLeAsA" briefDescription="Les rôles dans un projet qui applique Scrum." presentationName="Rôles Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" roles="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" href="uma://-CgLjZ6Bwc0EyYyQCjzlw7g#-CgLjZ6Bwc0EyYyQCjzlw7g"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epvpYEdqsc-f87sBK8A" name="WP Types" guid="_mQ3epvpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_d-yk8ABREdu3o4yroaI-tA" name="Backlogs" guid="_d-yk8ABREdu3o4yroaI-tA" briefDescription="Scrum utilise un nombre très restreint de produits de travail, essentiellement 2 listes appelées backlogs." presentationName="Backlogs" workProducts="_5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-eSc2tcV1h17HBw_s8ROEVw" href="uma://-eSc2tcV1h17HBw_s8ROEVw#-eSc2tcV1h17HBw_s8ROEVw"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3ep_pYEdqsc-f87sBK8A" name="Tools" guid="_mQ3ep_pYEdqsc-f87sBK8A"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqPpYEdqsc-f87sBK8A" name="StandardCategories" guid="_mQ3eqPpYEdqsc-f87sBK8A"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqfpYEdqsc-f87sBK8A" name="CustomCategories" guid="_mQ3eqfpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqvpYEdqsc-f87sBK8A" name="Hidden" guid="_mQ3eqvpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mQ3eq_pYEdqsc-f87sBK8A" name="Catégories personnalisées" guid="_mQ3eq_pYEdqsc-f87sBK8A" categorizedElements="_7BSBkABCEduYUKPFgCzFuA _s8y1UABREdu3o4yroaI-tA _nF6fgALYEduFv7wnrO7SvQ"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_7BSBkABCEduYUKPFgCzFuA" name="Cycle de vie Scrum" guid="_7BSBkABCEduYUKPFgCzFuA" presentationName="Cycle de vie">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Roadmap" href="#_6Jox0IRuEduo75chJsIcXg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAQAvEdubGMceRDupFQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_XtRuYP-zEdqLnajTSLeAsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_s8y1UABREdu3o4yroaI-tA" name="Intro" guid="_s8y1UABREdu3o4yroaI-tA" presentationName="Intro" categorizedElements="_wz30kABREdu3o4yroaI-tA _3WivIBTQEduFIr9xNbwGyQ _PTGe4IRvEduo75chJsIcXg">
+ <presentation xmi:id="-juIDa_fXi2K1BE5NTblPow" href="uma://-juIDa_fXi2K1BE5NTblPow#-juIDa_fXi2K1BE5NTblPow"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_nF6fgALYEduFv7wnrO7SvQ" name="Scrum Elements" guid="_nF6fgALYEduFv7wnrO7SvQ" briefDescription="Description des éléments de Scrum : rôles, réunions et backlogs, ainsi que des guides dans leur utilisation." presentationName="Eléments" categorizedElements="_3qmmoP-zEdqLnajTSLeAsA _d-yk8ABREdu3o4yroaI-tA _6sdMAAL-EduOAKqB9I73uw">
+ <presentation xmi:id="-zS9h38tmK4L-U9kbgkpGKQ" href="uma://-zS9h38tmK4L-U9kbgkpGKQ#-zS9h38tmK4L-U9kbgkpGKQ"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3erPpYEdqsc-f87sBK8A" name="CoreContent" guid="_mQ3erPpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_rkSgEPpYEdqsc-f87sBK8A" name="Eléments de Scrum" guid="_rkSgEPpYEdqsc-f87sBK8A" briefDescription="Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet. Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques. ">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_t1K9kPpYEdqsc-f87sBK8A" name="ScrumMaster" guid="_t1K9kPpYEdqsc-f87sBK8A" briefDescription="C' est l'animateur d'une équipe Scrum." presentationName="ScrumMaster" responsibleFor="_Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" href="uma://-Y3SFEe-A-lRF8TaEn9vKNQ#-Y3SFEe-A-lRF8TaEn9vKNQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_5ABscPpYEdqsc-f87sBK8A" name="Product Backlog" guid="_5ABscPpYEdqsc-f87sBK8A" briefDescription="Contient les exigences d'un produit" presentationName="Backlog de produit" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA" reports="_vKqe8PpaEdqsc-f87sBK8A _Z2NzkIGWEduKE9hnyImx1Q">
+ <presentation xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" href="uma://-Of1SdnAQ9nmsL5DFvD2Uug#-Of1SdnAQ9nmsL5DFvD2Uug"/>
+ <containedArtifacts xmi:id="_-D85cIGIEduKE9hnyImx1Q" name="Product Backlog Item" guid="_-D85cIGIEduKE9hnyImx1Q" briefDescription="Chose à faire qui apporte de la valeur. Appelé PBI (Product Backlog Item)" presentationName="Elément de backlog de produit">
+ <presentation xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" href="uma://-KC1R73i9f6P7ZT4pgBOLzA#-KC1R73i9f6P7ZT4pgBOLzA"/>
+ </containedArtifacts>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Dzw70PpZEdqsc-f87sBK8A" name="Sprint backlog" guid="_Dzw70PpZEdqsc-f87sBK8A" briefDescription="Liste des choses à faire du point de vue de l'équipe de développement." presentationName="Backlog du sprint" reports="_jC4NwPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" href="uma://-8V2DOvzUhvtqwWvTOHMB5g#-8V2DOvzUhvtqwWvTOHMB5g"/>
+ <containedArtifacts xmi:id="_9C78MIHnEdu3SZQ-Dp1OAA" name="Sprint Backlog Item" guid="_9C78MIHnEdu3SZQ-Dp1OAA" briefDescription="C'est une tâche, un travail élémentaire à réaliser pendant le sprint." presentationName="Elément de Backlog de Sprint">
+ <presentation xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" href="uma://-6UJtuFO3WFBFpJOFeV1QMQ#-6UJtuFO3WFBFpJOFeV1QMQ"/>
+ </containedArtifacts>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_ICJyYPpaEdqsc-f87sBK8A" name="Product Owner" guid="_ICJyYPpaEdqsc-f87sBK8A" briefDescription="C’est le représentant du "métier" dans le projet. " presentationName="Directeur Produit" responsibleFor="_5ABscPpYEdqsc-f87sBK8A">
+ <presentation xmi:id="-35iKPqDM2F2PjKWQLCW4tA" href="uma://-35iKPqDM2F2PjKWQLCW4tA#-35iKPqDM2F2PjKWQLCW4tA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_jC4NwPpaEdqsc-f87sBK8A" name="Sprint Burndown Chart" guid="_jC4NwPpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement du sprint courant." presentationName="Sprint Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-qVeT6_sAspmZjCYQLOrhbg" href="uma://-qVeT6_sAspmZjCYQLOrhbg#-qVeT6_sAspmZjCYQLOrhbg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_vKqe8PpaEdqsc-f87sBK8A" name="Release Burndown Chart" guid="_vKqe8PpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement de la release." presentationName="Release Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" href="uma://-pJuF9iKbSQx7TIwHNBVTgg#-pJuF9iKbSQx7TIwHNBVTgg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_4LOggPpaEdqsc-f87sBK8A" name="Plan sprint" guid="_4LOggPpaEdqsc-f87sBK8A" briefDescription="Planification du court terme" presentationName="Planifier le sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-NRwwk6YGAtu25V3Lc04G6w" href="uma://-NRwwk6YGAtu25V3Lc04G6w#-NRwwk6YGAtu25V3Lc04G6w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_9apLsPpaEdqsc-f87sBK8A" name="Team" guid="_9apLsPpaEdqsc-f87sBK8A" briefDescription="Il s'agit d'un rôle collectif. Tous les membres de l'équipe participent au travail, sans qu'on disitingue des fonctions particulières pour chacun." presentationName="Equipe Scrum" responsibleFor="_tCmYEP-xEdqLnajTSLeAsA">
+ <presentation xmi:id="-LVZG5zK2YjEGXO3SwDmqug" href="uma://-LVZG5zK2YjEGXO3SwDmqug#-LVZG5zK2YjEGXO3SwDmqug"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_MRrRYPpbEdqsc-f87sBK8A" name="Review sprint" guid="_MRrRYPpbEdqsc-f87sBK8A" briefDescription="Montrer ce qui a été réalisé et fonctionne. En tirer les conséquences." presentationName="Faire la revue du sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_tCmYEP-xEdqLnajTSLeAsA" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-zoJryMCuHfxWP7Q5Er195Q" href="uma://-zoJryMCuHfxWP7Q5Er195Q#-zoJryMCuHfxWP7Q5Er195Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_tCmYEP-xEdqLnajTSLeAsA" name="Product increment" guid="_tCmYEP-xEdqLnajTSLeAsA" briefDescription="Le produit partiel obtenu à la fin de chaque sprint." presentationName="Incrément de produit">
+ <presentation xmi:id="-6aCUL_kawJFNBtfH_sRXkw" href="uma://-6aCUL_kawJFNBtfH_sRXkw#-6aCUL_kawJFNBtfH_sRXkw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_J_sRIP_AEdqtbrr0B1TG-A" name="Retrospective" guid="_J_sRIP_AEdqtbrr0B1TG-A" briefDescription="Faire un bilan du sprint qui se termine" presentationName="Rétrospective" performedBy="_9apLsPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-S4qXwp40l_8eCcyyI7o-3A" href="uma://-S4qXwp40l_8eCcyyI7o-3A#-S4qXwp40l_8eCcyyI7o-3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_Qqmp8P_AEdqtbrr0B1TG-A" name="StakeHolder" guid="_Qqmp8P_AEdqtbrr0B1TG-A" briefDescription="Personne ne participant pas directement au projet mais ayant une influence sur celui-ci." presentationName="Intervenant">
+ <presentation xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" href="uma://-u0-b4PNo9XzOh1-dv_aaKA#-u0-b4PNo9XzOh1-dv_aaKA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_Xpd5gP_AEdqtbrr0B1TG-A" name="Manage problems" guid="_Xpd5gP_AEdqtbrr0B1TG-A" briefDescription="Prendre en compte les événements qui surviennent à tout moment sur un projet et tenter de les régler." presentationName="Gérer les problèmes" performedBy="_t1K9kPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" optionalInput="_Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-mZfAV7RcWJlp5idlHzeEcA" href="uma://-mZfAV7RcWJlp5idlHzeEcA#-mZfAV7RcWJlp5idlHzeEcA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_d09LYP_AEdqtbrr0B1TG-A" name="Scrum daily meeting" guid="_d09LYP_AEdqtbrr0B1TG-A" briefDescription="La régulation des activités de développement et de test se fait à travers les mêlées quotidiennes." presentationName="Mêlée quotidienne" performedBy="_t1K9kPpYEdqsc-f87sBK8A" mandatoryInput="_Dzw70PpZEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_9apLsPpaEdqsc-f87sBK8A _ICJyYPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-vDOuVl_xPKipKd90HQNZng" href="uma://-vDOuVl_xPKipKd90HQNZng#-vDOuVl_xPKipKd90HQNZng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_STkWYP_BEdqtbrr0B1TG-A" name="Update product backlog" guid="_STkWYP_BEdqtbrr0B1TG-A" briefDescription="Prise en compte des changements de périmètre en vue de préparer les sprints suivants." presentationName="Mettre à jour le backlog de produit" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-XdgedeazfFRGDxMY3Fnh5g" href="uma://-XdgedeazfFRGDxMY3Fnh5g#-XdgedeazfFRGDxMY3Fnh5g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_ho-aIP_BEdqtbrr0B1TG-A" name="Plan release" guid="_ho-aIP_BEdqtbrr0B1TG-A" briefDescription="Planification à moyen terme" presentationName="Planifier la release" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-3f4axrWBKHGv74oKN2x-gQ" href="uma://-3f4axrWBKHGv74oKN2x-gQ#-3f4axrWBKHGv74oKN2x-gQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_OUjj0AEZEduzRosbOajx7w" name="Travail collaboratif" guid="_OUjj0AEZEduzRosbOajx7w" presentationName="Travail collaboratif">
+ <presentation xmi:id="-dU_t9olFRQIyOBZQvMndKg" href="uma://-dU_t9olFRQIyOBZQvMndKg#-dU_t9olFRQIyOBZQvMndKg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_XtRuYP-zEdqLnajTSLeAsA" name="Produit, release et sprint" guid="_XtRuYP-zEdqLnajTSLeAsA" presentationName="Produit, release et sprint">
+ <presentation xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" href="uma://-BPz1k8sC6CCyJ2yZCc1p2Q#-BPz1k8sC6CCyJ2yZCc1p2Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_BGFMoANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_BGFMoANkEduYd-55D-Aiqg" briefDescription="Identifier une liste d'items, les inclure dans le backlog et les classer par priorité." presentationName="Elaborer le backlog de produit initial" performedBy="_ICJyYPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" href="uma://-mi1O4H7RRm0YqlUNyp8TJg#-mi1O4H7RRm0YqlUNyp8TJg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_3WivIBTQEduFIr9xNbwGyQ" name="Presentation Scrum" guid="_3WivIBTQEduFIr9xNbwGyQ" briefDescription="Scrum repose sur une technique de gestion de projets qui conduit à obtenir un produit avec la plus grande valeur "métier" possible dans la durée la plus réduite." presentationName="Scrum">
+ <presentation xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" href="uma://-MSO8KF-0IlKZJGnSwwTNZA#-MSO8KF-0IlKZJGnSwwTNZA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_Z2NzkIGWEduKE9hnyImx1Q" name="Release Planning" guid="_Z2NzkIGWEduKE9hnyImx1Q" briefDescription="Plan montrant les sprints et les éléments du backlog associés à ces sprints" presentationName="Planning de la release" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" href="uma://-EmLqiNX2WnmsfEtxNiuyTQ#-EmLqiNX2WnmsfEtxNiuyTQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_kftWoIHqEduFs9jH8xc4xw" name="Sprint" guid="_kftWoIHqEduFs9jH8xc4xw" presentationName="Sprint">
+ <presentation xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" href="uma://-fcoz1Nm_QnX6xtLg5YWdVg#-fcoz1Nm_QnX6xtLg5YWdVg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_AIB9gIHrEduFs9jH8xc4xw" name="Release" guid="_AIB9gIHrEduFs9jH8xc4xw" presentationName="Release">
+ <presentation xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" href="uma://-XPyPmZTAVbnvJVuOLvYpXw#-XPyPmZTAVbnvJVuOLvYpXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_aeYKoIKlEduQgtHqedKdMA" name="Theme" guid="_aeYKoIKlEduQgtHqedKdMA" presentationName="Thème">
+ <presentation xmi:id="-GKfSarwQLoaHhoT71FQI8Q" href="uma://-GKfSarwQLoaHhoT71FQI8Q#-GKfSarwQLoaHhoT71FQI8Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_HQEP8ILXEduLd8CaF_IcMA" name="Velocity" guid="_HQEP8ILXEduLd8CaF_IcMA" presentationName="Vélocité">
+ <presentation xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" href="uma://-PeP4fADValHXs2Z2Z8zJ1w#-PeP4fADValHXs2Z2Z8zJ1w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3qdXkILXEduLd8CaF_IcMA" name="Timebox" guid="_3qdXkILXEduLd8CaF_IcMA" presentationName="Bloc de temps">
+ <presentation xmi:id="-tHVOELWOQDI7i0M2rlMufQ" href="uma://-tHVOELWOQDI7i0M2rlMufQ#-tHVOELWOQDI7i0M2rlMufQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_X5rREILYEduLd8CaF_IcMA" name="Burndown Chart" guid="_X5rREILYEduLd8CaF_IcMA" presentationName="Graphe de tendance">
+ <presentation xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" href="uma://-KQ4Jzjy6YgAr_2NXa4J67g#-KQ4Jzjy6YgAr_2NXa4J67g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Roadmap" xmi:id="_6Jox0IRuEduo75chJsIcXg" name="Application" guid="_6Jox0IRuEduo75chJsIcXg" briefDescription="Appliquer Scrum sans oublier les principes" presentationName="Appliquer Scrum">
+ <presentation xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" href="uma://-IPxNSDzXKWa-H_kJ2PMtYA#-IPxNSDzXKWa-H_kJ2PMtYA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_SqGkoABREdu3o4yroaI-tA" name="Général" guid="_SqGkoABREdu3o4yroaI-tA">
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_wz30kABREdu3o4yroaI-tA" name="Introduction" guid="_wz30kABREdu3o4yroaI-tA" briefDescription="Bienvenue dans Scrum !" presentationName="Introduction">
+ <presentation xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" href="uma://-WfzsSn3X35gSHQZ2kqtoVw#-WfzsSn3X35gSHQZ2kqtoVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_N8zs0AEGEduzRosbOajx7w" name="Copyright" guid="_N8zs0AEGEduzRosbOajx7w" presentationName="Copyright">
+ <presentation xmi:id="-03XtfjRMEs23qIdCSSQiNQ" href="uma://-03XtfjRMEs23qIdCSSQiNQ#-03XtfjRMEs23qIdCSSQiNQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_PTGe4IRvEduo75chJsIcXg" name="Scrum references" guid="_PTGe4IRvEduo75chJsIcXg" presentationName="Références">
+ <presentation xmi:id="-cfa6bdUgQuboNpJRKaCLAw" href="uma://-cfa6bdUgQuboNpJRKaCLAw#-cfa6bdUgQuboNpJRKaCLAw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3erfpYEdqsc-f87sBK8A" name="CapabilityPatterns" guid="_mQ3erfpYEdqsc-f87sBK8A"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3ervpYEdqsc-f87sBK8A" name="DeliveryProcesses" guid="_mQ3ervpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_9llsAAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3er_pYEdqsc-f87sBK8A" name="ProcessContributions" guid="_mQ3er_pYEdqsc-f87sBK8A"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/Scrum/Scrum_PT/library/Scrum/roles/Product Owner.xmi b/Scrum/Scrum_PT/library/Scrum/roles/Product Owner.xmi
new file mode 100644
index 0000000..8a24545
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/roles/Product Owner.xmi
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-35iKPqDM2F2PjKWQLCW4tA" name="Product Owner,_ICJyYPpaEdqsc-f87sBK8A" guid="-35iKPqDM2F2PjKWQLCW4tA" authors="Claude Aubry" changeDate="2006-12-06T09:55:24.078+0100" version="1.0.0">
+ <mainDescription><p>
+ Le Directeur de produit (<i>Product Owner</i>) est le représentant des clients et utilisateurs dans l'équipe.
+</p>
+<p>
+ A ce titre, il est responsable de définir les caractéristiques du produit développé par l'équipe en termes de :
+</p>
+<ul>
+ <li>
+ <strong>fonctionnalités</strong> offertes. Plus précisément il identifie chaque exigence que doit&nbsp;satisfaire
+ le produit comme un&nbsp;<a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;(ou item). Il fournit les détails sur ces
+ exigences quand c'est nécessaire pour l'équipe. Il est souhaitable qu'il spécifie&nbsp;les tests d'acceptation
+ (acceptance tests) de chaque exigence.
+ </li>
+ <li>
+ <strong>priorité</strong>. C'est lui qui définit l'ordre dans lequel ces éléments seront développés en fonction de
+ la valeur qu'ils apportent aux clients et utilisateurs. Cela permet d'alimenter l'équipe avec un <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;prêt pour la planification des sprints,
+ </li>
+ <li>
+ <strong>but</strong>. C'est lui définit l'objectif d'une release et qui prend les décisions concernant le <a
+ class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><p>
+ Son implication est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il&nbsp;donne
+ l'impulsion à l'équipe. En promouvant à l'extérieur le résultat de chaque sprint, il fournit à l'équipe une
+ reconnaissance qui la motive.
+</p></keyConsiderations>
+ <skills><p>
+ Une personne qui joue ce rôle devrait posséder les compétences suivantes :
+</p>
+<ul>
+ <li>
+ bonne connaissance du domaine métier,
+ </li>
+ <li>
+ capacité à avoir une position respectée par tous les intervenants extérieurs (clients et utilisateurs),
+ </li>
+ <li>
+ capacité à prendre une décision au bon moment (pas trop tôt ni trop tard),
+ </li>
+ <li>
+ esprit ouvert au changement,
+ </li>
+ <li>
+ facilité à communiquer avec l'équipe.
+ </li>
+</ul>
+<p>
+ Quelqu'un qui a été Analyste Métier (Business Analyst) est un bon candidat pour ce rôle.
+</p></skills>
+ <assignmentApproaches><p>
+ Il n'y a qu'une seule personne qui joue ce rôle. Cette personne doit être affectée au projet (le Directeur de produit
+ fait partie de l'équipe étendue et participe aux réunions). Le travail nécessite une affectation à plein temps ou
+ presque.
+</p>
+<p>
+ Il est&nbsp;important qu'il soit très disponible pour répondre aux questions de l'équipe, pour définir les tests
+ fonctionnels et&nbsp;donner son avis sur divers aspects du produit (l'interface homme machine d'un logiciel, par
+ exemple).
+</p></assignmentApproaches>
+ <synonyms>Propriétaire de produit (product owner en anglais),&nbsp;Client (dans XP)</synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/roles/ScrumMaster.xmi b/Scrum/Scrum_PT/library/Scrum/roles/ScrumMaster.xmi
new file mode 100644
index 0000000..84b2974
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/roles/ScrumMaster.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" name="new_role,_t1K9kPpYEdqsc-f87sBK8A" guid="-Y3SFEe-A-lRF8TaEn9vKNQ" authors="Claude Aubry" changeDate="2007-01-08T17:37:05.421+0100" version="1.0.0">
+ <mainDescription><p>
+ Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome
+ et à s'améliorer constamment.
+</p>
+<p>
+ Pour cela, il effectue les travaux suivants :&nbsp;
+</p>
+<ul>
+ <li>
+ tâches périodiques,&nbsp;dont l'objectif est de mettre en application Scrum en organisant et animant le&nbsp;<a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>&nbsp;(réunions)&nbsp;:
+ <ul>
+ <li>
+ Mêlée quotidienne.
+ </li>
+ <li>
+ Planification du sprint
+ </li>
+ <li>
+ Revue du sprint
+ </li>
+ <li>
+ Rétrospective
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâches sur évènement
+ <ul>
+ <li>
+ éliminer les obstacles&nbsp;: prendre en compte les évènements qui surviennent à tout moment sur un projet
+ pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâche de fond
+ <ul>
+ <li>
+ faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les
+ éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .
+ </li>
+ </ul>
+ </li>
+</ul>
+<p>
+ Analogies
+</p>
+<ul>
+ <li>
+ Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de
+ ScrumMaster.
+ </li>
+ <li>
+ Ken Schwaber compare le ScrumMaster à un chien de berger.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><ul>
+ <li>
+ Ce n'est pas un chef de projet&nbsp;: il ne dirige pas, il n'impose pas, il ne contraint pas.
+ </li>
+ <li>
+ Il fait partie de l'équipe&nbsp;: il s'engage avec les autres.
+ </li>
+ <li>
+ Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.
+ </li>
+</ul></keyConsiderations>
+ <skills><p>
+ Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est
+ préférable de posséder les compétences suivantes pour jouer&nbsp;ce rôle :
+</p>
+<ul>
+ <li>
+ bien connaître Scrum,
+ </li>
+ <li>
+ avoir des facilités de présentation, de communication et de négociation,
+ </li>
+ <li>
+ guider sans imposer,
+ </li>
+ <li>
+ faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
+ </li>
+ <li>
+ savoir résoudre les conflits et les problèmes,
+ </li>
+ <li>
+ communiquer honnêtement sur le degré d'avancement,
+ </li>
+ <li>
+ garder le respect de l'objectif essentiel, qui est de livrer un produit qui remplit&nbsp;ses exigences.
+ </li>
+</ul>
+<p>
+ En revanche il n'est pas nécessaire de :
+</p>
+<ul>
+ <li>
+ avoir de l'expérience du domaine de l'application (pas indispensable, mais ça peut aider),
+ </li>
+ <li>
+ avoir des compétences techniques sur le développement.
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ Pour une équipe Scrum typique (de 6 à 10 personnes) , une seule personne joue ce rôle sur un projet.
+</p>
+<p>
+ Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela
+ doit rester limité.
+</p></assignmentApproaches>
+ <synonyms><p>
+ Facilitateur de processus. On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela
+ ne favorise pas la compréhension du rôle.
+</p></synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/roles/StakeHolder.xmi b/Scrum/Scrum_PT/library/Scrum/roles/StakeHolder.xmi
new file mode 100644
index 0000000..a1ded05
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/roles/StakeHolder.xmi
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" name="StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A" guid="-u0-b4PNo9XzOh1-dv_aaKA" authors="Claude Aubry" changeDate="2006-12-03T09:39:26.078+0100" version="1.0.0">
+ <mainDescription><p>
+ Un intervenant ne fait pas partie de l'équipe, mais il est intéressé par le produit réalisé. Il peut avoir une
+ influence sur le déroulement du projet. Il participe à des réunions Scrum : voir sa contribution au <a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>.
+</p>
+<p>
+ Dans son jargon, Scrum appelle&nbsp;les personnes jouant ce rôle&nbsp;des poules (chicken) et conseille de protéger
+ l’équipe, constituée des cochons (pigs), de leur influence directe sur le projet pendant un sprint. Cela signifie que
+ les intervenants ont des fenêtres d'intervention qui sont strictement définies afin de ne pas perturber le travail de
+ l'équipe.
+</p></mainDescription>
+ <synonyms><p>
+ Partie-prenante (Stakeholder en anglais)
+</p></synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/roles/Team.xmi b/Scrum/Scrum_PT/library/Scrum/roles/Team.xmi
new file mode 100644
index 0000000..91e38f6
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/roles/Team.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-LVZG5zK2YjEGXO3SwDmqug" name="Team,_9apLsPpaEdqsc-f87sBK8A" guid="-LVZG5zK2YjEGXO3SwDmqug" authors="Claude Aubry" changeDate="2006-12-03T09:36:21.984+0100" version="1.0.0">
+ <mainDescription><p>
+ Une équipe regroupe des membres qui forment un tout soudé capable de réaliser les différentes tâches sur
+ lesquelles&nbsp;elle s’engage collectivement lors de chaque sprint.
+</p>
+<p>
+ Elle possède la latitude voulue pour déterminer ce qui doit être fait afin d’atteindre le but fixé du sprint. Elle
+ s’organise de façon autonome et planifie ses propres travaux, sans se les faire imposer.
+</p></mainDescription>
+ <keyConsiderations>Par son approche centrée sur le collectif,&nbsp;l'agilité contribue à améliorer la camaraderie dans l’équipe.</keyConsiderations>
+ <skills>L’équipe doit être capable de réaliser les différentes tâches sur lesquelles elle s'engage lors de la planification du
+sprint. Cela signifie qu'elle doit être multi-fonctionnelle (cross-functional) pour couvrir les travaux d'analyse, de
+conception, de codage, de test et autres.</skills>
+ <assignmentApproaches>Une équipe Scrum comprend généralement de&nbsp;3 à 10 personnes.</assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/roles/resources/148-le-role-de-scrummaster.html b/Scrum/Scrum_PT/library/Scrum/roles/resources/148-le-role-de-scrummaster.html
new file mode 100644
index 0000000..83644c8
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/roles/resources/148-le-role-de-scrummaster.html
@@ -0,0 +1,296 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html lang="fr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+<head>
+
+
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+
+
+
+
+ <meta name="MSSmartTagsPreventParsing" content="TRUE">
+ <link rel="previous" href="http://www.aubryconseil.com/dotclear/index.php/2007/01/05/146-inscription-technorati" title="Inscription Technorati">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-projets" title="Mes projets">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Evenements" title="Mes événements">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-conseils" title="Mes conseils">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-cours" title="Mes cours">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-france" title="L'agilité en France">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-dans-le-monde" title="L'agilité dans le monde">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-dehors-du-logiciel" title="L'agilité en dehors du logiciel">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-butinage" title="Mon butinage">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-blog" title="Mon blog">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2007/01" title="janvier 2007">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/12" title="décembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/11" title="novembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/10" title="octobre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/09" title="septembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/08" title="août 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/07" title="juillet 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/06" title="juin 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/05" title="mai 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/04" title="avril 2006">
+ <link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.aubryconseil.com/dotclear/rss.php">
+ <link rel="alternate" type="application/xml" title="Atom" href="http://www.aubryconseil.com/dotclear/atom.php">
+ <meta name="DC.title" content="Scrum - Méthodes agiles"><title>Le rôle de ScrumMaster - Scrum - Méthodes agiles</title><!--
+<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
+<rdf:Description
+ rdf:about="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
+ dc:identifier="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
+ dc:title="Le rôle de ScrumMaster"
+ trackback:ping="http://www.aubryconseil.com/dotclear/tb.php?id=148" />
+</rdf:RDF>
+-->
+
+
+
+<link rel="stylesheet" type="text/css" href="148-le-role-de-scrummaster.css" media="all"></head><body>
+
+<div id="page">
+
+<div id="top">
+ <h1><a indepth="true" href="index.html">Scrum - Méthodes agiles</a></h1>
+</div>
+
+<p id="prelude"><a href="#main">Aller au contenu</a> |
+<a href="#sidebar">Aller au menu</a> |
+<a href="#search">Aller à la recherche</a></p>
+
+<div id="main">
+ <div id="content">
+
+<div class="post">
+ <h2 class="post-title">Le rôle de ScrumMaster</h2>
+ <p class="post-info">
+<!--
+claude aubry,
+-->
+ dimanche 7 janvier 2007 à 16:08 <span>::</span> <a indepth="true" href="mes-conseils.html">Mes conseils</a>
+ <span>::</span> <a indepth="true" href="148-le-role-de-scrummaster.html" title="Lien permanent vers : Le rôle de ScrumMaster">#148</a>
+ <span>::</span> <a href="http://www.aubryconseil.com/dotclear/rss.php?type=co&post=148" title="fil RSS des commentaires de : Le rôle de ScrumMaster">rss</a>
+ </p>
+
+ <div class="post-chapo"><p>Un résumé du rôle de ScrumMaster, l'animateur d'une équipe qui applique Scrum.</p></div> <div class="post-content"><h5>Synonymes</h5>
+<ul>
+<li>Facilitateur de processus.</li>
+<li>On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela ne favorise pas la compréhension du rôle <sup>[<a href="#pnote-148-1" id="rev-pnote-148-1">1</a>]</sup>.</li>
+</ul>
+<h5>Analogies</h5>
+<ul>
+<li>Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de ScrumMaster.</li>
+<li>Ken Schwaber compare le ScrumMaster à un chien de berger.</li>
+</ul>
+<h5>Responsabilité</h5>
+
+<p>Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome et à s'améliorer constamment.</p>
+
+
+<h5>Tâches</h5>
+<ul>
+<li>tâches périodiques : mettre en application Scrum en organisant et animant les réunions :
+<ul>
+<li>Mêlée quotidienne.</li>
+<li>Planification du sprint</li>
+<li>Revue du sprint</li>
+<li>Rétrospective</li>
+</ul></li>
+<li>tâches sur évènement
+<ul>
+<li>éliminer les obstacles : prendre en compte les évènements qui surviennent à tout moment sur un projet pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures</li>
+</ul></li>
+<li>tâche de fond
+<ul>
+<li>faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .</li>
+</ul></li>
+</ul>
+
+<h5>Compétences</h5>
+
+<p>Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est préférable de posséder les compétences suivantes pour jouer ce rôle :</p>
+<ul>
+<li>bien connaitre Scrum,</li>
+<li>avoir des facilités de présentation, de communication et de négociation,</li>
+<li>guider sans imposer,</li>
+<li>faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,</li>
+<li>savoir résoudre les conflits et les problèmes,</li>
+<li>communiquer honnêtement sur le degré d'avancement,</li>
+<li>garder le respect de l'objectif essentiel, qui est de livrer un produit qui apporte de la valeur avec une utilisation optimale des ressources.</li>
+</ul>
+
+<p>En revanche il n'est pas nécessaire de :</p>
+<ul>
+<li>avoir de l'expérience du domaine de l'application <sup>[<a href="#pnote-148-2" id="rev-pnote-148-2">2</a>]</sup>,</li>
+<li>avoir des compétences techniques sur le développement logiciel.</li>
+</ul>
+
+<h5>Affectation</h5>
+
+
+<p>Pour une équipe Scrum typique <sup>[<a href="#pnote-148-3" id="rev-pnote-148-3">3</a>]</sup>, une seule personne joue ce rôle sur un projet.</p>
+
+
+<p>Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela doit rester limité.</p>
+
+<h5>Points clés</h5>
+<ul>
+<li>Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas.</li>
+<li>Il fait partie de l'équipe : il s'engage avec les autres.</li>
+<li>Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.</li>
+</ul>
+<div class="footnotes"><h4>Notes</h4>
+<p>[<a href="#rev-pnote-148-1" id="pnote-148-1">1</a>] voir sur ce sujet <a href="http://agilitateur.azeau.com/index.php?itemid=61" hreflang="fr">le billet de l'Agilitateur</a></p>
+<p>[<a href="#rev-pnote-148-2" id="pnote-148-2">2</a>] ce n'est pas indispensable, mais ça peut aider</p>
+<p>[<a href="#rev-pnote-148-3" id="pnote-148-3">3</a>] de 6 à 10 personnes</p></div></div>
+
+
+</div>
+
+<div id="trackbacks">
+ <h3 id="tb">Rétroliens</h3>
+ <p>Aucun rétrolien.</p>
+
+
+
+ <p>Pour faire un rétrolien sur ce billet :
+ http://www.aubryconseil.com/dotclear/tb.php?id=148</p>
+ </div>
+
+<div id="comments">
+ <h3 id="co">Commentaires</h3>
+ <p>Aucun commentaire pour le moment.</p>
+
+
+
+ <h3>Ajouter un commentaire</h3>
+ <form action="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" method="post" id="comment-form">
+<fieldset>
+ <p class="field"><label for="c_nom">Nom ou pseudo :</label>
+ <input name="c_nom" id="c_nom" size="30" maxlength="255" value="" type="text">
+ </p>
+
+ <p class="field"><label for="c_mail">Email (facultatif) :</label>
+ <input name="c_mail" id="c_mail" size="30" maxlength="255" value="" type="text">
+ </p>
+
+ <p class="field"><label for="c_site">Site Web (facultatif) :</label>
+ <input name="c_site" id="c_site" size="30" maxlength="255" value="http://" type="text">
+ </p>
+
+ <p class="field"><label for="c_content">Commentaire :</label>
+ <textarea name="c_content" id="c_content" cols="35" rows="7"></textarea>
+ </p>
+</fieldset>
+
+<p class="form-help">Le code HTML dans le commentaire sera affiché comme du texte,
+les adresses internet seront converties automatiquement.</p>
+
+<fieldset>
+ <p><input id="c_remember" name="c_remember" type="checkbox">
+ <label for="c_remember">Se souvenir de mes informations</label>
+ </p>
+ <p><input class="preview" name="preview" value="prévisualiser" type="submit">
+ <input class="submit" value="envoyer" type="submit">
+ <input name="redir" value="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" type="hidden"></p>
+</fieldset>
+
+</form>
+ </div>
+ </div>
+</div>
+
+ <div id="sidebar">
+
+
+ <div id="presentation"><h2></h2><p>Dans ce blog ma contribution à la diffusion de Scrum à travers mes expériences en tant que <a href="http://www.aubryconseil.com/">consultant</a> et comme enseignant à l'<a href="http://www.iup-ups.ups-tlse.fr/isi/" hreflang="fr">IUP ISI</a> <br>
+Claude Aubry</p>
+ <a indepth="true" href="contact.html">Page contact</a>
+ </div>
+
+ <div id="connexes">
+ <h2>Scrum</h2>
+
+ <ul><li><a indepth="true" href="scrum_001.html">Introduction à Scrum</a>
+</li><li><a indepth="true" href="mon-offre-scrum.html">Essayer Scrum</a>
+</li><li><a indepth="true" href="icescrum.html">IceScrum</a>
+</li><li><a indepth="true" href="liens-scrum.html">Plus d'infos sur Scrum</a>
+</li></ul> </div>
+
+
+
+ <div id="tags">
+ <h2>Tags</h2>
+
+ <ul id="tagcloud"><li class="level-2"><a indepth="true" href="agilite.html">agilité</a> </li><li class="level-1"><a indepth="true" href="backlog.html">backlog</a> </li><li class="level-1"><a indepth="true" href="blog.html">blog</a> </li><li class="level-1"><a indepth="true" href="conference.html">conférence</a> </li><li class="level-1"><a indepth="true" href="contrat.html">contrat</a> </li><li class="level-1"><a indepth="true" href="dotclear.html">dotclear</a> </li><li class="level-1"><a indepth="true" href="epf.html">EPF</a> </li><li class="level-1"><a indepth="true" href="equipe.html">equipe</a> </li><li class="level-2"><a indepth="true" href="estimation.html">estimation</a> </li><li class="level-1"><a indepth="true" href="fac.html">fac</a> </li><li class="level-1"><a indepth="true" href="formation.html">formation</a> </li><li class="level-1"><a indepth="true" href="humour.html">humour</a> </li><li class="level-2"><a indepth="true" href="icescrum_001.html">icescrum</a> </li><li class="level-1"><a indepth="true" href="mesures.html">mesures</a> </li><li class="level-1"><a indepth="true" href="moi.html">moi</a> </li><li class="level-1"><a indepth="true" href="musique.html">musique</a> </li><li class="level-1"><a indepth="true" href="openup.html">OpenUP</a> </li><li class="level-1"><a indepth="true" href="outils.html">outils</a> </li><li class="level-2"><a indepth="true" href="planification.html">planification</a> </li><li class="level-2"><a indepth="true" href="processus.html">processus</a> </li><li class="level-1"><a indepth="true" href="presentation.html">présentation</a> </li><li class="level-1"><a indepth="true" href="release.html">release</a> </li><li class="level-1"><a indepth="true" href="rugby.html">rugby</a> </li><li class="level-1"><a indepth="true" href="retrospective.html">rétrospective</a> </li><li class="level-1"><a indepth="true" href="roles.html">rôles</a> </li><li class="level-5"><a indepth="true" href="scrum.html">scrum</a> </li><li class="level-1"><a indepth="true" href="sigmat.html">sigmat</a> </li><li class="level-1"><a indepth="true" href="tdd.html">tdd</a> </li><li class="level-1"><a indepth="true" href="techno.html">techno</a> </li><li class="level-2"><a indepth="true" href="tendances.html">tendances</a> </li><li class="level-1"><a indepth="true" href="traduction.html">traduction</a> </li><li class="level-1"><a indepth="true" href="uml.html">UML</a> </li><li class="level-2"><a indepth="true" href="user-stories.html">user stories</a> </li><li class="level-1"><a indepth="true" href="vision.html">vision</a> </li><li class="level-1"><a indepth="true" href="xp.html">xp</a> </li></ul> </div>
+
+ <div id="syndicate">
+ <h2>Syndication</h2>
+ <a href="http://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fwww.aubryconseil.com%2Fdotclear"><img src="add2netvibes.gif" alt="Add to Netvibes" height="17" width="91"></a>
+ <ul>
+ <li><a href="http://www.aubryconseil.com/dotclear/rss.php">fil rss</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/rss.php?type=co">fil rss commentaires</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/atom.php">fil atom</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/atom.php?type=co">fil atom commentaires</a></li>
+ </ul>
+ </div>
+
+ <div id="calendar">
+ <h2>Calendrier</h2>
+ <table summary="Calendrier">
+<caption><a indepth="true" href="12.html" title="décembre 2006">«</a> janvier 2007</caption><thead><tr><th scope="col"><abbr title="lundi">lun</abbr></th><th scope="col"><abbr title="mardi">mar</abbr></th><th scope="col"><abbr title="mercredi">mer</abbr></th><th scope="col"><abbr title="jeudi">jeu</abbr></th><th scope="col"><abbr title="vendredi">ven</abbr></th><th scope="col"><abbr title="samedi">sam</abbr></th><th scope="col"><abbr title="dimanche">dim</abbr></th></tr></thead>
+<tbody><tr><td><a indepth="true" href="01.html">1</a></td><td><a indepth="true" href="02.html">2</a></td><td>3</td><td><a indepth="true" href="04.html">4</a></td><td><a indepth="true" href="05.html">5</a></td><td>6</td><td class="active"><a indepth="true" href="07.html">7</a></td></tr>
+<tr><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td><td>13</td><td>14</td></tr>
+<tr><td>15</td><td>16</td><td>17</td><td>18</td><td>19</td><td>20</td><td>21</td></tr>
+<tr><td>22</td><td>23</td><td>24</td><td>25</td><td>26</td><td>27</td><td>28</td></tr>
+<tr><td>29</td><td>30</td><td>31</td><td> </td><td> </td><td> </td><td> </td></tr>
+</tbody>
+</table> </div>
+
+ <div id="search">
+ <form action="http://www.aubryconseil.com/dotclear/index.php/" method="get">
+
+ <h2><label for="q">Rechercher</label></h2>
+ <p class="field"><input name="q" id="q" size="10" value="" accesskey="4" type="text">
+ <input class="submit" value="ok" type="submit"></p>
+
+ </form>
+ </div>
+
+ <div id="selection"><h2>À retenir</h2><ul><li><a indepth="true" href="148-le-role-de-scrummaster.html">Le rôle de ScrumMaster</a></li><li><a indepth="true" href="132-le-role-de-directeur-de-produit.html">Le rôle de directeur de produit</a></li><li><a indepth="true" href="125-scrum-en-bref.html">Scrum en bref</a></li><li><a indepth="true" href="115-backlog-priorise.html">Backlog : critères pour établir les priorités</a></li><li><a indepth="true" href="99-discipline-et-agilite.html">Discipline et agilité</a></li><li><a indepth="true" href="87-duree-fixe-des-iterations.html">Durée fixe des itérations</a></li><li><a indepth="true" href="67-la-minute-ideale-du-randonneur.html">La minute idéale du randonneur</a></li><li><a indepth="true" href="58-agilite-pour-un-contrat-au-forfait.html">Agilité pour un contrat au forfait</a></li><li><a indepth="true" href="36-avant-la-premiere-iteration.html">Avant la première itération</a></li><li><a indepth="true" href="29-duree-d-une-iteration.html">Durée d'une itération</a></li></ul></div>
+
+ <div id="toclink">
+<h2><a indepth="true" href="toc.html">Table des matières</a></h2>
+</div>
+
+
+
+ <div id="archives">
+ <h2>Archives</h2>
+ <ul><li><strong><a indepth="true" href="01_001.html">janvier 2007</a></strong></li><li><a indepth="true" href="12.html">décembre 2006</a></li><li><a indepth="true" href="11.html">novembre 2006</a></li><li><a indepth="true" href="10.html">octobre 2006</a></li><li><a indepth="true" href="09.html">septembre 2006</a></li><li><a indepth="true" href="08.html">août 2006</a></li><li><a indepth="true" href="07_001.html">juillet 2006</a></li><li><a indepth="true" href="06.html">juin 2006</a></li><li><a indepth="true" href="05_001.html">mai 2006</a></li><li><a indepth="true" href="04_001.html">avril 2006</a></li></ul> </div>
+
+ <div id="links">
+ <h2>Blogs lus régulièrement</h2>
+ <h3>Agile</h3><ul><li><a href="http://agilitateur.azeau.com/" hreflang="fr">L'Agilitateur</a></li><li><a href="http://kanemar.wordpress.com/" hreflang="EN">Kane Mar</a></li><li><a href="http://silkandspinach.net/" hreflang="EN">Silk and Spinach</a></li><li><a href="http://www.testing.com/cgi-bin/blog" hreflang="en">Exploration Through Example</a></li><li><a href="http://www.agileadvice.com/" hreflang="EN">Agile Advice</a></li><li><a href="http://theagileblog.net/" hreflang="en">On Be(come)ing Agile</a></li><li><a href="http://bossavit.com/thoughts/" hreflang="EN" rel="co-worker">Laurent Bossavit</a></li><li><a href="http://prog13.free.fr/" hreflang="fr">Avangel</a></li><li><a href="http://tcros.blogspot.com/" hreflang="fr">Thierry Cros</a></li></ul><h3>Techno</h3><ul><li><a href="http://www.dotnetguru2.org/proques/" hreflang="fr" title="Le blog de Pascal Roques">UML Guru</a></li><li><a href="http://www.inherence.fr/dotclear/" hreflang="fr">Parlons ISO 20000</a></li><li><a href="http://nauges.typepad.com/my_weblog/" hreflang="fr">Louis Naugès</a></li><li><a href="http://standblog.org/blog/" hreflang="fr">StandBlog</a></li></ul> </div>
+
+ <div id="categories">
+ <h2>Catégories</h2>
+ <ul><li><a indepth="true" href="mes-projets.html">Mes projets</a></li><li><a indepth="true" href="evenements.html">Mes événements</a></li><li><a indepth="true" href="mes-conseils.html">Mes conseils</a></li><li><a indepth="true" href="mes-cours.html">Mes cours</a></li><li><a indepth="true" href="l-agilite-en-france.html">L'agilité en France</a></li><li><a indepth="true" href="l-agilite-dans-le-monde.html">L'agilité dans le monde</a></li><li><a indepth="true" href="l-agilite-en-dehors-du-logiciel.html">L'agilité en dehors du logiciel</a></li><li><a indepth="true" href="mon-butinage.html">Mon butinage</a></li><li><a indepth="true" href="mon-blog.html">Mon blog</a></li></ul> </div>
+
+
+
+
+</div><p id="footer">Le blog de Claude Aubry est <a href="http://www.dotclear.net/">
+propulsé par DotClear</a></p>
+
+</div>
+<!-- end #page -->
+
+<!-- Blocs en plus pour ajouter des images en tout genre si besoin -->
+<div id="block1"><span></span></div><div id="block2"><span></span></div>
+<div id="block3"><span></span></div><div id="block4"><span></span></div>
+<div id="block5"><span></span></div><div id="block6"><span></span></div>
+
+
+
+</body></html>
diff --git a/Scrum/Scrum_PT/library/Scrum/rolesets/Scrum Roles.xmi b/Scrum/Scrum_PT/library/Scrum/rolesets/Scrum Roles.xmi
new file mode 100644
index 0000000..8542e8b
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/rolesets/Scrum Roles.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" name="new_role_set,_3qmmoP-zEdqLnajTSLeAsA" guid="-CgLjZ6Bwc0EyYyQCjzlw7g" changeDate="2006-12-03T08:51:09.000+0100">
+ <mainDescription><p>
+ Scrum définit uniquement 3 rôles pour les personnes qui participent aux travaux de développement. A la différence
+ d’autres processus, il n’existe pas d’architecte, de programmeur, de testeur, d’analyste, de rédacteur. L’équipe
+ regroupe les compétences sans distinction du rôle de chacun a priori.
+</p>
+<p>
+ Toutes les personnes ayant une influence sur&nbsp;le projet sans y participer directement sont représentées par le rôle
+ <a class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/scrum.jpg b/Scrum/Scrum_PT/library/Scrum/scrum.jpg
new file mode 100644
index 0000000..5fe67e3
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/scrum.jpg
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Initiate Product Backlog.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Initiate Product Backlog.xmi
new file mode 100644
index 0000000..3563196
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Initiate Product Backlog.xmi
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" name="Initiate Product Backlog,_BGFMoANkEduYd-55D-Aiqg" guid="-mi1O4H7RRm0YqlUNyp8TJg" authors="Claude Aubry" changeDate="2006-12-03T09:00:53.343+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Le backlog initial doit permettre de planifier au moins les 2 ou 3 premiers sprints.
+</p></keyConsiderations>
+ <sections xmi:id="_pWL_gAPJEdubhrgDuRb4fA" name="Collecter les éléments du backlog" guid="_pWL_gAPJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;établit une première liste des exigences (une
+ exigence&nbsp;devient un&nbsp;<a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>)&nbsp;qu'il souhaite voir réalisées pour la fin de la
+ release.
+</p>
+<p>
+ Pour compléter cette liste et obtenir un backlog suffisant, il est conseillé d'organiser un workshop réunissant toute
+ l'équipe plus des intervenants. Au cours de ce workshop, le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a>&nbsp;présente son ébauche de backlog et chacun intervient pour proposer de nouveaux items.
+</p>
+<p>
+ Il est fréquent qu'un élément du backlog soit identifié&nbsp;comme une histoire d'utilisateur (User story), technique
+ utilisée à l'origine dans EXtreme Programming (XP) et qui s'adapte très bien&nbsp;à Scrum.
+</p>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_u0Z7sAPJEdubhrgDuRb4fA" name="Ordonner le backlog" guid="_u0Z7sAPJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;ordonne les éléments du backlog selon une priorité
+ décroissante. Pour lui, A plus prioritaire que B signifie qu'il souhaite disposer, dans un produit partiel, de l'item A
+ avant l'item B.
+</p>
+<p>
+ Lorsque le backlog contient beaucoup d'éléments, le classement par priorité de chacun est fastidieux et délicat. C'est
+ pourquoi il est utile de définir des <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Theme,_aeYKoIKlEduQgtHqedKdMA.html"
+ guid="_aeYKoIKlEduQgtHqedKdMA">Thème</a>s, d'associer à&nbsp;chaque élément un thème et de définir les&nbsp;priorités
+ sur les thèmes avant de passer aux éléments. Cela peut être fait lors d'une réunion à laquelle participent les <a
+ class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>s, ainsi que des membres de l'équipe.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de produire un backlog au moins suffisant pour permettre le démarrage de la série des sprints.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Manage problems.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Manage problems.xmi
new file mode 100644
index 0000000..3cbc0ce
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Manage problems.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-mZfAV7RcWJlp5idlHzeEcA" name="Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A" guid="-mZfAV7RcWJlp5idlHzeEcA" changeDate="2006-12-03T10:05:51.734+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Cette tâche est centrée sur la résolution de ces problèmes.
+</p></keyConsiderations>
+ <sections xmi:id="_LCxqQAB6EduSVaTQTBfIHA" name="Prendre connaissance du problème" guid="_LCxqQAB6EduSVaTQTBfIHA">
+ <sectionDescription><p>
+ La réunion quotidienne est l'endroit idéal pour déceler les problèmes qu'une équipe rencontre. Elle peut même permettre
+ de les résoudre immédiatement grâce à la collaboration de l'équipe. Cependant :
+</p>
+<ul>
+ <li>
+ il arrive que des problèmes urgents soient soulevés entre 2 réunions quotidiennes
+ </li>
+ <li>
+ et surtout la résolution des problèmes n'est pas faite en réunion (sauf si elle évidente)
+ </li>
+</ul>
+<p>
+ Suite à la mise en évidence d'un problème, par exemple lors de la réunion quotidienne,&nbsp;identifier la cause du
+ problème et les impacts sur le projet. Pour cela une communication orale, à l'initiative&nbsp;du&nbsp;<a
+ class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>,&nbsp;avec la personne qui a soulevé le problème est souhaitable.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_PIKyUAB6EduSVaTQTBfIHA" name="Décider d'un plan d'action" guid="_PIKyUAB6EduSVaTQTBfIHA">
+ <sectionDescription><p>
+ Identifier les solutions possibles.<br />
+ Une réunion avec le responsable hiérarchique est organisée si des problèmes survenant sur le projet ne peuvent pas
+ être réglés simplement ou sont à un niveau au-dessus de son autorité.
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>&nbsp;doit s'efforcer de résoudre le problème au plus tôt, pour ne pas
+ perturber l'avancement de l'équipe.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de d'éliminer les problèmes rencontrés par l'équipe pour qu'elle puisse se concentrer sur ses véritables
+objectifs.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Plan release.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Plan release.xmi
new file mode 100644
index 0000000..6c78f3b
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Plan release.xmi
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-3f4axrWBKHGv74oKN2x-gQ" name="Plan release,_ho-aIP_BEdqtbrr0B1TG-A" guid="-3f4axrWBKHGv74oKN2x-gQ" changeDate="2006-12-03T09:23:18.328+0100" version="1.0.0">
+ <keyConsiderations>Il s'agit d'un travail collectif à l'initiative du directeur de produit.</keyConsiderations>
+ <sections xmi:id="_8qN08APJEdubhrgDuRb4fA" name="Définir les conditions de succès de la release" guid="_8qN08APJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il existe 2 types de releases&nbsp; :
+</p>
+<ul>
+ <li>
+ une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
+ une date fixée.
+ </li>
+ <li>
+ une release dirigée par les fonctionnalités. La liste des exigences est connue et la release prendra fin lorsque
+ toutes les exigences seront réalisées.
+ </li>
+</ul>
+<p>
+ Les conditions de succès sont définies en fonction de ce type de release.
+</p>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_BuXEQAPKEdubhrgDuRb4fA" name="Estimer les éléments du backlog" guid="_BuXEQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
+</p>
+<p>
+ L'estimation est réalisée en équipe.
+</p>
+<p>
+ La grandeur utilisée pour les estimations est de préférence le point, sans unités. Pour les valeurs utilisées pour les
+ estimations, on utilise souvent la suite de Fibonacci (1, 2, 3, 5, 8 et 13).
+</p>
+<p>
+ Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
+ de pratiquer le "planning poker" et de travailler par analogie en comparant les éléments estimés.&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_EaLKQAPKEdubhrgDuRb4fA" name="Définir la durée des sprints" guid="_EaLKQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Historiquement dans Scrum, la durée d'un sprint est de 30 jours. Cependant il est possible et même recommandé de faire
+ des sprints plus courts. La durée dépend du projet et des contraintes qui s'y appliquent.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_HDZ2UAPKEdubhrgDuRb4fA" name="Estimer la vélocité" guid="_HDZ2UAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;réelle. Elle sera alors utilisée pour cette release, éventuellement
+ ajustée compte tenu de la nature du projet. Attention cependant un point n'a pas forcément la même valeur dans des
+ projets différents.
+</p>
+<p>
+ Si ce n'est pas le cas, il faut faire une estimation de la vélocité. Le mieux est de travailler sur le contenu du
+ premier sprint de la release et de voir ce que l'équipe pense pouvoir réaliser pendant ce premier sprint. Cela donne
+ une vélocité estimée qui peut être utilisée pour la planification de la release. Ensuite la planification sera basée
+ sur la vélocité mesurée dans les sprints précédents.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_I71XkAPKEdubhrgDuRb4fA" name="Associer les éléments du backlog aux sprints" guid="_I71XkAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ En fonction des paramètres suivants :
+</p>
+<ul>
+ <li>
+ les estimations de chaque item,
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité),
+ </li>
+ <li>
+ la vélocité estimée pour la release,
+ </li>
+</ul>
+<p>
+ on affecte les items aux sprints de la release.
+</p>
+<p>
+ Il est normal d'ajuster, c'est à dire de changer légèrement l'ordre des items, ne serait-ce que pour se rapprocher le
+ plus possible de la vélocité (en effet on ne tombe pas toujours "rond").
+</p>
+<p>
+ Il faut associer des items aux premiers sprints (les 2 ou 3 premiers), mais il n'est pas indispensable de le faire pour
+ tous les sprints de la release.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ Elaborer la planification initiale de la release permettant de lancer la série de sprints.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Plan sprint 2.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Plan sprint 2.xmi
new file mode 100644
index 0000000..f745cf2
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Plan sprint 2.xmi
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-NRwwk6YGAtu25V3Lc04G6w" name="Plan sprint,_4LOggPpaEdqsc-f87sBK8A" guid="-NRwwk6YGAtu25V3Lc04G6w" authors="Claude Aubry" changeDate="2006-12-03T09:57:11.890+0100" version="1.0.0">
+ <keyConsiderations><p>
+ La réunion de planification de sprint est un travail réalisé en groupe.
+</p>
+<p>
+ Elle est limitée dans le temps :
+</p>
+<ul>
+ <li>
+ durée max : limitée à 4 heures
+ </li>
+ <li>
+ durée moyenne : 2 heures
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_TJNsUP--Edqtbrr0B1TG-A" name="Définir le but du sprint" guid="_TJNsUP--Edqtbrr0B1TG-A">
+ <sectionDescription><p>
+ Au début lors des premiers sprints de la première release d'un produit, le but est bien souvent de montrer la
+ faisabilité de l'architecture envisagée.
+</p>
+<p>
+ Ensuite, une fois que l'architecture est stabilisée, le but d'un sprint est proposé par le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a> et discuté avec l'équipe. Il porte souvent sur un thème fonctionnel.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xvy5UAPKEdubhrgDuRb4fA" name="Sélectionner les items" guid="_xvy5UAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il s'agit de définir le périmètre de ce sprint. Cela est fait en associant un <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;au sprint puis un autre en tenant compte de la
+ vélocité de l'équipe.
+</p>
+<p>
+ Si un <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;a été effectué, cette étape consiste seulement à valider
+ collectivement le sous-ensemble du backlog prévu pour ce sprint.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_p4C0sP--Edqtbrr0B1TG-A" name="Identifier les tâches à partir des items" guid="_p4C0sP--Edqtbrr0B1TG-A">
+ <sectionDescription><p>
+ La 2ème partie de la réunion a pour objectif de définir comment l’équipe va s’arranger pour réaliser le résultat
+ attendu du sprint.<br />
+ Pour cela, chaque <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;sélectionné est décomposé en tâches. Cela permet
+ à toute l’équipe de discuter et d’éclaircir des points de solution par rapport à cet item, en demandant si nécessaire
+ au propriétaire de produit des précisions sur le comportement du produit.<br />
+</p>
+<p>
+ Normalement l'ensemble des activités du cycle de vie sont déroulées lors d'un sprint :<br />
+</p>
+<ul>
+ <li>
+ Les exigences sélectionnées sont spécifiées
+ </li>
+ <li>
+ L'architecture est remaniée si nécessaire
+ </li>
+ <li>
+ Les classes et sous-systèmes sont conçus, implémentés et testés
+ </li>
+ <li>
+ Les différents composants sont intégrés et testés
+ </li>
+ <li>
+ Le produit est packagé&nbsp;
+ </li>
+ <li>
+ Les tests d'acceptation sont passés.<br />
+ </li>
+</ul>
+<p>
+ L'importance donnée à ces activités dépend de la place du sprint dans la release.<br />
+ <br />
+ Le travail prévu dans un sprint précédent mais qui n'a pu être réalisé à cause de la réduction des objectifs devient
+ prioritaire pour le sprint suivant.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_DxNQUAPLEdubhrgDuRb4fA" name="Estimer les tâches" guid="_DxNQUAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Les taches sont estimées en heures. Il est conseillé d'avoir des tâches suffisamment fines pour qu'une estimation reste
+ inférieure à 16 heures.
+</p>
+<p>
+ L'estimation est faite collectivement, par l'équipe. Au cours de la discussion pour arriver à une estimation, les
+ aspects techniques sont abordés.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_worbAP--Edqtbrr0B1TG-A" name="Attribuer les tâches" guid="_worbAP--Edqtbrr0B1TG-A">
+ <sectionDescription>Une fois que les activités du sprint ont été définies, elles seront affectées aux membres de l'équipe. Les activités
+peuvent être réalisées par une ou plusieurs personnes. Toutes les activités doivent être prises en compte, y compris les
+réunions de travail (hors réunions Scrum), les lectures de documents ou de code.<br />
+Il est préférable de différer l'affectation de certaines activités, qui seront prises pendant le sprint en fonction des
+disponibilités des membres de l'équipe.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Iq14wAPLEdubhrgDuRb4fA" name="Obtenir l'engagement de l'équipe" guid="_Iq14wAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il est souhaitable que l'équipe s'engage collectivement sur le backlog du sprint, c'est à dire sur les éléments du
+ backlog qu'elle estime pouvoir réaliser dans le sprint.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de planifier&nbsp;le sprint&nbsp;qui commence.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Retrospective.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Retrospective.xmi
new file mode 100644
index 0000000..243a584
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Retrospective.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-S4qXwp40l_8eCcyyI7o-3A" name="Retrospective,_J_sRIP_AEdqtbrr0B1TG-A" guid="-S4qXwp40l_8eCcyyI7o-3A" changeDate="2006-12-03T10:01:12.593+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé.
+</p>
+<ul>
+ <li>
+ durée max : 2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_lwzeABGPEduHloEV5-Zv-w" name="Discussion" guid="_lwzeABGPEduHloEV5-Zv-w">
+ <sectionDescription>Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé dans l'application de Scrum sur le
+projet.</sectionDescription>
+ </sections>
+ <sections xmi:id="_noL2YBGPEduHloEV5-Zv-w" name="Définir le plan d'actions" guid="_noL2YBGPEduHloEV5-Zv-w">
+ <sectionDescription><p>
+ L’équipe discute des améliorations possibles et leur donne une priorité.
+</p>
+<p>
+ Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a> ajoute les actions d’amélioration dans le backlog.
+</p></sectionDescription>
+ </sections>
+ <purpose>L’objectif est d'améliorer continuellement le processus.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Review sprint.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Review sprint.xmi
new file mode 100644
index 0000000..a63b191
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Review sprint.xmi
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-zoJryMCuHfxWP7Q5Er195Q" name="Review sprint,_MRrRYPpbEdqsc-f87sBK8A" guid="-zoJryMCuHfxWP7Q5Er195Q" changeDate="2006-12-03T09:52:13.953+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Travail en groupe (lors de la réunion dite de revue de sprint)
+</p>
+<p>
+ Pour la réunion :
+</p>
+<ul class="noindent">
+ <li>
+ durée max : &nbsp;2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_XL6VgAPLEdubhrgDuRb4fA" name="Préparer la démonstration" guid="_XL6VgAPLEdubhrgDuRb4fA">
+ <sectionDescription>La préparation de la réunion ne doit pas excéder une heure.<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_ZgJB8APLEdubhrgDuRb4fA" name="Effectuer la démonstration" guid="_ZgJB8APLEdubhrgDuRb4fA">
+ <sectionDescription>L’équipe présente le produit partiel résultat de ses travaux, sous forme de démonstration des exigences (histoires
+d'utilisateur) réalisées. Seules les exigences complètement finies (et testées) sont présentées. Cela permet d’avoir une
+mesure objective de l’avancement. <br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_cBouUAPLEdubhrgDuRb4fA" name="Evaluer les résultats du sprint" guid="_cBouUAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> et les intervenants présents (clients, utilisateurs) posent des
+ questions à l’équipe, donnent leur impression, font des propositions et des demandes de changement. Le <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;est enrichi avec les bugs découverts et les demandes
+ d’évolution.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_hrswoHoYEduJVrY6eKG_mw" name="Calculer la vélocité réelle" guid="_hrswoHoYEduJVrY6eKG_mw">
+ <sectionDescription><p>
+ La <a class="elementLink" href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;du sprint&nbsp;est obtenue en faisant la somme de tous les points
+ associés aux exigences considérées comme effectivement finies. Elle est comparée à celle des sprints précédents, le
+ plus souvent à travers un <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>.&nbsp;&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_d776UHoYEduJVrY6eKG_mw" name="Ajuster le plan de la release" guid="_d776UHoYEduJVrY6eKG_mw">
+ <sectionDescription><p>
+ Les conditions ont pu changer depuis la dernière planification de la release :
+</p>
+<ul>
+ <li>
+ des items ont pu être ajoutés ou suppirmés, les estimations modifiées,&nbsp;
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité) a pu être modifié,
+ </li>
+</ul>
+<p>
+ De plus la vélocité&nbsp;moyenne a pu évoluer avec la prise de la vélocité calculée du sprint.&nbsp;
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> est ajusté en tenant compte de ces nouveaux paramètres.
+</p></sectionDescription>
+ </sections>
+ <purpose>&nbsp;Le but est de montrer les exigences réalisées pendant le sprint par une démonstration du produit partiel</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Scrum daily meeting.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Scrum daily meeting.xmi
new file mode 100644
index 0000000..f9cd5b0
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Scrum daily meeting.xmi
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-vDOuVl_xPKipKd90HQNZng" name="Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A" guid="-vDOuVl_xPKipKd90HQNZng" changeDate="2006-12-03T10:07:26.890+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Se déroule tous les jours, avec toute l'équipe, de préférence le matin en arrivant : il est souhaitable que la réunion
+ ait lieu tous les jours au même endroit et à la même heure.
+</p>
+<p>
+ La réunion est limitée à 15 minutes.&nbsp;<br />
+ L’objectif est d’examiner l’avancement des travaux et d'identifier les problèmes potentiels, mais pas de résoudre les
+ problèmes
+</p></keyConsiderations>
+ <sections xmi:id="_oUrlcBGOEduHloEV5-Zv-w" name="Préparer" guid="_oUrlcBGOEduHloEV5-Zv-w">
+ <sectionDescription>Chacun met à jour le planning ( le backlog se sprint) en actualisant le reste à faire sur ses tâches, ce qui permet de
+produire un <a class="elementLink"
+href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>.</sectionDescription>
+ </sections>
+ <sections xmi:id="_r0KkEBGOEduHloEV5-Zv-w" name="Se réunir" guid="_r0KkEBGOEduHloEV5-Zv-w">
+ <sectionDescription><p>
+ Chaque membre de l’équipe s’exprime tour à tour, en répondant à 3 questions sur :
+</p>
+<ol>
+ <li>
+ Ce qui a été fait depuis la mêlée précédente (en principe la veille)
+ </li>
+ <li>
+ Ce qui va être fait aujourd’hui
+ </li>
+ <li>
+ Les problèmes rencontrés&nbsp;
+ </li>
+</ol>
+<p>
+ Il est souhaitable que la réunion s'effectue avec tous les personnes de l'équipe debout en cercle et en ayant sous les
+ yeux le <a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+ guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;et le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>&nbsp;actualisés.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_vZkkgBGOEduHloEV5-Zv-w" name="Consolider" guid="_vZkkgBGOEduHloEV5-Zv-w">
+ <sectionDescription>Le&nbsp;<a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;remis à jour sert à prendre une décision sur l'ajustement du but
+du sprint. Il faut avoir à l'esprit qu'un sprint est limité dans le temps (bloc de temps) et qu'il est préférable de
+supprimer du contenu prévu initialement plutôt que d'avoir du retard. <br />
+Les problèmes soulevés sont résolus&nbsp;lors de&nbsp;<a class="elementLink"
+href="./../../Scrum/tasks/Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A.html" guid="_Xpd5gP_AEdqtbrr0B1TG-A">Gérer les
+problèmes</a>&nbsp;à l'initiative du <a class="elementLink"
+href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html" guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>.</sectionDescription>
+ </sections>
+ <purpose>Le but est de faire le point sur l'avancement de l'équipe et d'identifier les problèmes. L’objectif est uniquement
+d’examiner l’avancement des travaux, pas de résoudre les problèmes.</purpose>
+ <alternatives><p>
+ Appelé aussi Stand-Up Meeting (XP)
+</p></alternatives>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/tasks/Update product backlog.xmi b/Scrum/Scrum_PT/library/Scrum/tasks/Update product backlog.xmi
new file mode 100644
index 0000000..af19cc7
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/tasks/Update product backlog.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-XdgedeazfFRGDxMY3Fnh5g" name="Manage product backlog,_STkWYP_BEdqtbrr0B1TG-A" guid="-XdgedeazfFRGDxMY3Fnh5g" changeDate="2006-12-03T09:12:31.968+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Pendant le sprint, personne ne peut modifier la sélection des items du backlog effectuée au début du sprint : le
+ périmètre du sprint reste inchangé.
+</p>
+<p>
+ En revanche, n’importe qui, même un intervenant extérieur, peut proposer de nouveaux items pour plus tard. Ces items
+ sont étudiés et ordonnés par le propriétaire du produit en vue de la planification du prochain sprint.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p></keyConsiderations>
+ <sections xmi:id="_c3HaQAPKEdubhrgDuRb4fA" name="Collecter les changements" guid="_c3HaQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ N’importe qui, même un intervenant extérieur, peut proposer des changements à ajouter au backlog.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p>
+<p>
+ Ces éléments sont analysés par le propriétaire du produit en vue de la planification du prochain sprint.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_fkXDoAPKEdubhrgDuRb4fA" name="Réordonner les items" guid="_fkXDoAPKEdubhrgDuRb4fA">
+ <sectionDescription>Les éléments ajoutés depuis le sprint précédent sont ordonnés dans le backlog par le&nbsp;<a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+en vue de la planification à venir.</sectionDescription>
+ </sections>
+ <sections xmi:id="_k-kCgAPKEdubhrgDuRb4fA" name="Réestimer les items" guid="_k-kCgAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'estimation en points des nouveaux éléments introduits dans le backlog est faite par l'équipe, de préférence lors d'un
+ travail de groupe avec le Directeur de prouit, un ou 2 jours avant la revue de fin de sprint.
+</p>
+<p>
+ Des items déjà présents peuvent également être réestimés.
+</p></sectionDescription>
+ </sections>
+ <purpose>Actualiser le backlog et ajuster la planification en tenant compte des changements apparus depuis le dernier sprint.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducts/Product Backlog Item.xmi b/Scrum/Scrum_PT/library/Scrum/workproducts/Product Backlog Item.xmi
new file mode 100644
index 0000000..adf4810
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducts/Product Backlog Item.xmi
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" name="new_artifact,_-D85cIGIEduKE9hnyImx1Q" guid="-KC1R73i9f6P7ZT4pgBOLzA" changeDate="2006-12-01T23:15:03.002+0100">
+ <mainDescription>C'est une exigence fonctionnelle ou non fonctionnelle (technique), une demande d'évolution, un bug ou tout autre
+chose&nbsp;dont la réalisation apporte de la valeur au <a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+Produit</a>.&nbsp;
+<p>
+ Il possède des attributs qui sont généralement :
+</p>
+<ul>
+ <li>
+ une estimation de sa valeur qui est le plus souvent montrée de façon relative aux autres éléments par la notion de
+ priorité,
+ </li>
+ <li>
+ une estimation de son coût de développement,
+ </li>
+ <li>
+ éventuellement le thème (domaine fonctionnel) dont il fait partie,
+ </li>
+ <li>
+ éventuellement son type (défini en fonction du projet, par exemple histoire d'utilisateur, bug, exigence non
+ fonctionnelle),
+ </li>
+</ul>
+<p>
+ Si on utilise la technique des histoires d'utilisateur (user stories) et le développement dirigé par les tests (TDD),
+ on associe les critères servant aux tests d'acceptation de cet élément.
+</p>
+<p>
+ La vie d'un PBI passe par les états suivants :
+</p>
+<ul class="noindent">
+ <li>
+ créé
+ </li>
+ <li>
+ estimé
+ </li>
+ <li>
+ planifié (associé à un&nbsp;sprint futur
+ </li>
+ <li>
+ associé au sprint courant (on le réalise)
+ </li>
+ <li>
+ réalisé
+ </li>
+ <li style="list-style: none">
+ <br />
+ </li>
+</ul></mainDescription>
+ <keyConsiderations>Le principe de Scrum est de finir complètement un PBI dans un sprint.</keyConsiderations>
+ <externalId>PBI</externalId>
+ <purpose>Sert à la gestion de projet : il sera placé dans un sprint</purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducts/Product Backlog.xmi b/Scrum/Scrum_PT/library/Scrum/workproducts/Product Backlog.xmi
new file mode 100644
index 0000000..4d8cb72
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducts/Product Backlog.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" name="Product Backlog,_5ABscPpYEdqsc-f87sBK8A" guid="-Of1SdnAQ9nmsL5DFvD2Uug" authors="Claude AUbry" changeDate="2006-12-03T09:31:43.140+0100" version="1.0.0">
+ <mainDescription><p>
+ Le backlog du produit est le référentiel des exigences. Il contient des éléments du backlog (appelés aussi des items de
+ backlog de produit).
+</p>
+<p>
+ Sa vie est liée à celle du produit.
+</p></mainDescription>
+ <purpose>Lister toutes les choses à faire&nbsp;du point de vue du client (le quoi)</purpose>
+ <impactOfNotHaving>Obligatoire</impactOfNotHaving>
+ <briefOutline>Visible par tous, il est mis à jour régulièrement. Il est présenté à la revue de planification du sprint et, une fois
+accepté, la partie contenant les exigences allouées au sprint courant est gelée.</briefOutline>
+ <representationOptions><ul>
+ <li>
+ Cartes (story cards)
+ </li>
+ <li>
+ Feuille d'un tableur
+ </li>
+ <li>
+ Outil IceScrum&nbsp;
+ </li>
+ <li>
+ Base de données
+ </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducts/Product increment.xmi b/Scrum/Scrum_PT/library/Scrum/workproducts/Product increment.xmi
new file mode 100644
index 0000000..bc47bed
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducts/Product increment.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-6aCUL_kawJFNBtfH_sRXkw" name="Product increment,_tCmYEP-xEdqLnajTSLeAsA" guid="-6aCUL_kawJFNBtfH_sRXkw" changeDate="2006-12-03T10:04:18.218+0100" version="1.0.0">
+ <mainDescription><p>
+ Le résultat principal d'un sprint est le produit partiel qui réalise, en plus de ce qui existait au début du
+ sprint,&nbsp;les exigences supplémentaires réalisées pendant ce sprint.
+</p>
+<p>
+ On peut&nbsp;trouver 3 utilisations -après la démonstration lors de la revue de sprintes- du produit partiel obtenu en
+ fin d'itération&nbsp;:
+</p>
+<ul>
+ <li>
+ il n'est pas utilisé en dehors de l'équipe. Il a été produit pour chercher à minimiser les risques liés à la
+ technologie et à la capacité de l'équipe à intégrer pour produire un <q>build</q>. Cela arrive surtout au début
+ d'un nouveau produit.
+ </li>
+ <li>
+ il est utilisé par des clients privilégiés, en plus du directeur produit. Cela leur donne la possibilité de jouer
+ avec, ce qui permet de réduire les risques portant sur l'IHM liées à la facilité d'utilisation des fonctionnalités.
+ Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
+ </li>
+ <li>
+ il est mis en production ou en exploitation et utilisé par ses utilisateurs finals. C'est évidemment ce qu'il faut
+ viser puisque chaque nouvelle version apporte de la valeur. Autant l'apporter le plus tôt possible, dès qu'elle est
+ disponible. Mais ce n'est généralement pas possible de mettre en production à la fin de chaque sprint : trop de
+ temps serait pris pour passer les tests de recette sur tout le système, déployer sur l'environnement de production,
+ écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs... C'est pourquoi ce travail
+ particulier nécessite souvent une activité de préparation à la mise en production. Mais si on réussit à limiter le
+ temps pour faire tout ça, on peut alors mettre en production plus souvent qu'à la fin des releases.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><p>
+ Le produit évolue pendant toute sa vie jusqu'à son retrait.
+</p></keyConsiderations>
+ <briefOutline>Le produit partiel peut être déployé dans l'environnement de production&nbsp;ou simplement mis à disposition des
+utilisateurs.</briefOutline>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducts/Sprint Backlog Item.xmi b/Scrum/Scrum_PT/library/Scrum/workproducts/Sprint Backlog Item.xmi
new file mode 100644
index 0000000..1f7bd5b
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducts/Sprint Backlog Item.xmi
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" name="new_artifact,_9C78MIHnEdu3SZQ-Dp1OAA" guid="-6UJtuFO3WFBFpJOFeV1QMQ" changeDate="2006-12-02T10:38:33.140+0100">
+ <mainDescription><p>
+ Chaque tâche possède les attributs suivants :
+</p>
+<ul>
+ <li>
+ l'estimation du temps à passer pour finir la tâche. Les efforts sont estimés, par l’équipe, en heures sur une
+ échelle qui varie habituellement de 1à 16 heures. Les tâches plus grandes devraient être décomposées. L’estimation
+ du reste à faire est réactualisée tous les jours.
+ </li>
+ <li>
+ l'<a class="elementLink" href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;à l'origine de cette tâche
+ </li>
+ <li>
+ la personne qui prend en compte cette tâche<br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducts/Sprint backlog.xmi b/Scrum/Scrum_PT/library/Scrum/workproducts/Sprint backlog.xmi
new file mode 100644
index 0000000..da5b496
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducts/Sprint backlog.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" name="Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A" guid="-8V2DOvzUhvtqwWvTOHMB5g" changeDate="2006-12-03T10:17:45.781+0100" version="1.0.0">
+ <mainDescription><p>
+ Il&nbsp;contient la liste des tâches que l’équipe s’engage à faire afin de compléter les éléments de backlog de produit
+ sélectionnés pour ce sprint.<br />
+ L’équipe peut modifier une tâche, la supprimer ou en ajouter de nouvelles : il est courant que des tâches apparaissent
+ lors du sprint.
+</p></mainDescription>
+ <purpose>Il&nbsp;décrit l'ensemble des&nbsp;tâches d'un sprint, avec les ressources qui y sont affectées et le travail qui reste à
+faire. C'est un plan qui porte sur des tâches détaillées, il est dit à "mailles fines".</purpose>
+ <impactOfNotHaving>Obligatoire</impactOfNotHaving>
+ <briefOutline><p>
+ C'est un outil de communication essentiel qui aide à gérer le sprint. Il doit être facilement mis à jour et rester
+ visible à toute l'équipe.
+</p></briefOutline>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducts/resources/EtatsPBI.jpg b/Scrum/Scrum_PT/library/Scrum/workproducts/resources/EtatsPBI.jpg
new file mode 100644
index 0000000..4e1e28f
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducts/resources/EtatsPBI.jpg
Binary files differ
diff --git a/Scrum/Scrum_PT/library/Scrum/workproducttypes/Backlogs.xmi b/Scrum/Scrum_PT/library/Scrum/workproducttypes/Backlogs.xmi
new file mode 100644
index 0000000..67ae2e4
--- /dev/null
+++ b/Scrum/Scrum_PT/library/Scrum/workproducttypes/Backlogs.xmi
@@ -0,0 +1,15 @@
+<?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="-eSc2tcV1h17HBw_s8ROEVw" name="Backlogs,_d-yk8ABREdu3o4yroaI-tA" guid="-eSc2tcV1h17HBw_s8ROEVw" changeDate="2006-06-22T22:06:50.327+0200">
+ <mainDescription><p>
+ Les backlogs de Produit et de Sprint sont des éléments de gestion majeurs dans l'utilisation de Scrum.
+</p>
+<p>
+ A partir des backlogs, on produit des rapports comme le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>&nbsp;ou le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>
+</p></mainDescription>
+ <keyConsiderations>Un backlog est une liste d'items. Le terme n'est pas traduit en français car il est couramment utilisé dans la communauté
+des développeurs.</keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_PT/library/configurations/Scrum.xmi b/Scrum/Scrum_PT/library/configurations/Scrum.xmi
new file mode 100644
index 0000000..4575445
--- /dev/null
+++ b/Scrum/Scrum_PT/library/configurations/Scrum.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:MethodConfiguration xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_IqDLgP_OEdqtbrr0B1TG-A" name="Scrum" guid="_IqDLgP_OEdqtbrr0B1TG-A" briefDescription="Le processus Scrum" version="1.0.0">
+ <methodPluginSelection href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eofpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eovpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eo_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ep_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ervpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epvpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3er_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqvpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_rkSgEPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_SqGkoABREdu3o4yroaI-tA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_37NW8AL_EduOAKqB9I73uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_NSW6sAMAEduOAKqB9I73uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_SoXWEAMAEduOAKqB9I73uw"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_s8y1UABREdu3o4yroaI-tA"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_nF6fgALYEduFv7wnrO7SvQ"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_7BSBkABCEduYUKPFgCzFuA"/>
+</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/Scrum/Scrum_PT/library/library.xmi b/Scrum/Scrum_PT/library/library.xmi
new file mode 100644
index 0000000..16d6058
--- /dev/null
+++ b/Scrum/Scrum_PT/library/library.xmi
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_hDRYYfpYEdqsc-f87sBK8A" guid="_hDRYYfpYEdqsc-f87sBK8A">
+ <subManagers xmi:id="_5AUAUPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5AUAUPpYEdqsc-f87sBK8A"/>
+ <resourceDescriptors xmi:id="_hDRYYvpYEdqsc-f87sBK8A" id="_hDRYYPpYEdqsc-f87sBK8A" uri=""/>
+ <resourceDescriptors xmi:id="_mRDr4PpYEdqsc-f87sBK8A" id="_mQ3eoPpYEdqsc-f87sBK8A" uri="Scrum/plugin.xmi"/>
+ <resourceDescriptors xmi:id="_VRheAYPTEdu0eqo2Hxw7OA" id="_VRheAIPTEdu0eqo2Hxw7OA" uri="IceScrum/plugin.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodLibrary xmi:id="_hDRYYPpYEdqsc-f87sBK8A" name="scrum" guid="_hDRYYPpYEdqsc-f87sBK8A">
+ <methodPlugins xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
+ </org.eclipse.epf.uma:MethodLibrary>
+</xmi:XMI>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/customcategories/Intro.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/customcategories/Intro.html
new file mode 100644
index 0000000..ccf5f6d
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/customcategories/Intro.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\customcategories\Intro.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Intro.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_s8y1UABREdu3o4yroaI-tA CRC: 3687115300 -->Intro<!-- END:presentationName,_s8y1UABREdu3o4yroaI-tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-juIDa_fXi2K1BE5NTblPow CRC: 2580991762 -->Ce site décrit l'utilisation de Scrum<!-- END:mainDescription,-juIDa_fXi2K1BE5NTblPow -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/customcategories/Scrum_Elements.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/customcategories/Scrum_Elements.html
new file mode 100644
index 0000000..ff44426
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/customcategories/Scrum_Elements.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\customcategories\Scrum Elements.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Scrum Elements.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_nF6fgALYEduFv7wnrO7SvQ CRC: 2615340209 -->Eléments<!-- END:presentationName,_nF6fgALYEduFv7wnrO7SvQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_nF6fgALYEduFv7wnrO7SvQ CRC: 163987696 -->Description des éléments de Scrum : rôles, réunions et backlogs, ainsi que des guides dans leur utilisation.<!-- END:briefDescription,_nF6fgALYEduFv7wnrO7SvQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/deliveryprocesses/Scrum/content.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/deliveryprocesses/Scrum/content.html
new file mode 100644
index 0000000..c20106f
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/deliveryprocesses/Scrum/content.html
@@ -0,0 +1,178 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\deliveryprocesses\Scrum\content.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: content.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9llsAQAvEdubGMceRDupFQ CRC: 1375353473 -->Release<!-- END:presentationName,_9llsAQAvEdubGMceRDupFQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_9llsAQAvEdubGMceRDupFQ CRC: 3250773394 -->Les phases, les sprints et les tâches à dérouler lors de la production d'une release.<!-- END:briefDescription,_9llsAQAvEdubGMceRDupFQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-16dzhVoCex78V2iCDZVx0w CRC: 1282541273 -->La production d’une version du logiciel (<a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>) se fait en général en quelques mois. Les fonctionnalités demandées pour la
+release sont collectées dans le backlog de produit et classées par priorité. Le directeur de produit est responsable de
+l’insertion des changements dans ce backlog. <br />
+La release est produite par une série d’itérations de 2 à 4 semaines appelées des <a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s. Le contenu d’un Sprint est défini par l’équipe avec le propriétaire de produit,
+en tenant compte des priorités et de la capacité de l’équipe. L’équipe définit les tâches nécessaires pour réaliser les
+fonctionnalités sélectionnées pour le Sprint. <br />
+Pendant un sprint, des points de contrôle sur l’avancement sont effectués lors des mêlées quotidiennes. Cela permet au
+ScrumMaster de déterminer l’avancement par rapport aux engagements du Sprint et de conseiller des ajustements pour assurer
+le succès du Sprint. <br />
+A la fin de chaque Sprint, l’équipe produit un <a class="elementLink"
+href="./../../Scrum/workproducts/Product increment,_tCmYEP-xEdqLnajTSLeAsA.html" guid="_tCmYEP-xEdqLnajTSLeAsA">Incrément
+de produit</a> potentiellement utilisable, dont l’évaluation permet d’ajuster le backlog pour le Sprint suivant.<!-- END:mainDescription,-16dzhVoCex78V2iCDZVx0w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-16dzhVoCex78V2iCDZVx0w CRC: 1038429763 --><p>
+ Scrum contribue à renforcer l’esprit d’équipe dans les projets, avec une collection de pratiques proches de
+ celles que l’on trouve dans des sports collectifs en particulier le rugby.
+</p>
+<br />
+<br /><!-- END:keyConsiderations,-16dzhVoCex78V2iCDZVx0w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-16dzhVoCex78V2iCDZVx0w CRC: 248832578 -->.<!-- END:purpose,-16dzhVoCex78V2iCDZVx0w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: howtoStaff<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:howtoStaff,-16dzhVoCex78V2iCDZVx0w CRC: 2552836619 -->Une équipe Scrum est composée de 3 à 10 personnes.<!-- END:howtoStaff,-16dzhVoCex78V2iCDZVx0w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: scope<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:scope,-16dzhVoCex78V2iCDZVx0w CRC: 2095136763 -->Scrum ne décrit pas toutes les disciplines du développement de logiciel (analyse, conception, codage, test) et doit être
+considéré, plutôt qu’un processus complet, comme un pattern de processus qui est à utiliser pour la gestion de projet et la
+gestion des exigences. <br />
+Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement.<!-- END:scope,-16dzhVoCex78V2iCDZVx0w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: estimatingTechnique<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:estimatingTechnique,-16dzhVoCex78V2iCDZVx0w CRC: 490364943 --><p>
+ Il est conseillé de pratiquer une estimation basée sur les points (story points), associés aux éléments du backlog.
+</p><!-- END:estimatingTechnique,-16dzhVoCex78V2iCDZVx0w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_37TdkAL_EduOAKqB9I73uw CRC: 3791558351 -->Phase de préparation<!-- END:presentationName,_37TdkAL_EduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_37TdkAL_EduOAKqB9I73uw CRC: 2350875665 -->Cette phase initiale permet de préparer tout ce qui est nécessaire avant de commencer la série des sprints<!-- END:briefDescription,_37TdkAL_EduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-WiMYK8iwLeOO-sSBRBjbNQ CRC: 2234503055 --><p>
+ Scrum ne prend pas en compte tous les aspects de préparation d'un projet. Seules sont présentées les taches spécifiques
+ de Scrum plus une qui regroupe tous les travaux pouvant etre réalisés
+</p><!-- END:mainDescription,-WiMYK8iwLeOO-sSBRBjbNQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG2wMAEduOAKqB9I73uw CRC: 3420918181 -->Backlog du sprint<!-- END:presentationName,_glbG2wMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageGuidance<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageGuidance,-MupkaQeHNEmiF7Lnl3VirQ CRC: 2666903867 -->Un par sprint<!-- END:usageGuidance,-MupkaQeHNEmiF7Lnl3VirQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_nXmKUANlEduYd-55D-Aiqg CRC: 571725627 -->Travaux quotidiens<!-- END:presentationName,_nXmKUANlEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_nXmKUANlEduYd-55D-Aiqg CRC: 2413536670 -->L'équipe réalise les taches du backlog pour arriver au but du sprint<!-- END:briefDescription,_nXmKUANlEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: refinedDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:refinedDescription,-EpBaHVCIYCqqGX_wv7dlYA CRC: 3266550244 -->Scrum ne propose rien pour la réalisation de ces tâches techniques de conception, codage et test mais se conjugue bien avec
+l’utilisation des techniques XP (binômage, développement dirigé par les tests…). <br />
+Les tâches ne sont pas assignées par le ScrumMaster mais choisies par les membres de l’équipe au fur et à mesure. <br />
+L’équipe met à jour, chaque fois que c’est nécessaire, l’estimation du reste à faire sur les tâches du <br />
+backlog du sprint.<!-- END:refinedDescription,-EpBaHVCIYCqqGX_wv7dlYA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zbM2QIGBEduKE9hnyImx1Q CRC: 2656084017 -->Travaux de livraison<!-- END:presentationName,_zbM2QIGBEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_zbM2QIGBEduKE9hnyImx1Q CRC: 880815055 -->Ce dernier sprint permet de préparer la livraison du produit.<!-- END:briefDescription,_zbM2QIGBEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-EOwIzNPjfNIjzJ3TRAgeWQ CRC: 887255782 -->Essayer de ne pas modifier de code lors du dernier sprint, c'est trop tard et risqué.<!-- END:keyConsiderations,-EOwIzNPjfNIjzJ3TRAgeWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: usageGuidance<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:usageGuidance,-EOwIzNPjfNIjzJ3TRAgeWQ CRC: 805908360 -->Il est optionnel. Cela dépend de la façon dont le produit est mis à disposition de ses utilisateurs finals. On en devrait
+dérouler ce sprint optionnel que des travaux qu'il est impossible de faire avant, dans les sprints "normaux".<!-- END:usageGuidance,-EOwIzNPjfNIjzJ3TRAgeWQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: refinedDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:refinedDescription,-EOwIzNPjfNIjzJ3TRAgeWQ CRC: 2944631748 --><p>
+ Les tâches effectuées pendant ce sprint dépendent fortement du type de déploiement du logiciel.
+</p>
+<p>
+ On peut y trouver des travaux portant sur :
+</p>
+<ul>
+ <li>
+ mise en production à chaud,
+ </li>
+ <li>
+ packaging du produit,
+ </li>
+ <li>
+ mise à disposition par téléchargement en ligne,
+ </li>
+ <li>
+ documentation technique,
+ </li>
+ <li>
+ formation des utilisateurs,
+ </li>
+ <li>
+ marketing du produit.
+ </li>
+</ul><!-- END:refinedDescription,-EOwIzNPjfNIjzJ3TRAgeWQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/deliveryprocesses/Scrum/model.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/deliveryprocesses/Scrum/model.html
new file mode 100644
index 0000000..6b0c3ec
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/deliveryprocesses/Scrum/model.html
@@ -0,0 +1,200 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\deliveryprocesses\Scrum\model.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: model.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zYT-EQMAEduOAKqB9I73uw CRC: 3928792880 -->Planifier la release<!-- END:presentationName,_zYT-EQMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7FGsMANkEduYd-55D-Aiqg CRC: 702380472 -->Produire le backlog de produit initial<!-- END:presentationName,_7FGsMANkEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7FGsMQNkEduYd-55D-Aiqg CRC: 4115438475 -->Intervenant<!-- END:presentationName,_7FGsMQNkEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zYaEsgMAEduOAKqB9I73uw CRC: 511034597 -->Equipe Scrum<!-- END:presentationName,_zYaEsgMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zYaEtAMAEduOAKqB9I73uw CRC: 1996011610 -->Backlog de produit<!-- END:presentationName,_zYaEtAMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zYaEsAMAEduOAKqB9I73uw CRC: 1560166875 -->Directeur Produit<!-- END:presentationName,_zYaEsAMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_O6XmcANlEduYd-55D-Aiqg CRC: 2727586088 -->Travaux de préparation<!-- END:presentationName,_O6XmcANlEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_zYaEswMAEduOAKqB9I73uw CRC: 4226345851 -->ScrumMaster<!-- END:presentationName,_zYaEswMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_NSW6sQMAEduOAKqB9I73uw CRC: 2610930715 -->Phase des sprints<!-- END:presentationName,_NSW6sQMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_NSW6sQMAEduOAKqB9I73uw CRC: 2325346992 -->Cette phase consiste à dérouler les sprints les uns après les autres <!-- END:briefDescription,_NSW6sQMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_SoXWEQMAEduOAKqB9I73uw CRC: 3895218305 -->Sprint<!-- END:presentationName,_SoXWEQMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_SoXWEQMAEduOAKqB9I73uw CRC: 183411847 -->Déroulement d'un sprint (itération)<!-- END:briefDescription,_SoXWEQMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG0AMAEduOAKqB9I73uw CRC: 1092083131 -->Gérer les problèmes<!-- END:presentationName,_glbG0AMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG1wMAEduOAKqB9I73uw CRC: 4226345851 -->ScrumMaster<!-- END:presentationName,_glbG1wMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG0QMAEduOAKqB9I73uw CRC: 1161395959 -->Mettre à jour le backlog de produit<!-- END:presentationName,_glbG0QMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG2QMAEduOAKqB9I73uw CRC: 4115438475 -->Intervenant<!-- END:presentationName,_glbG2QMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG2gMAEduOAKqB9I73uw CRC: 511034597 -->Equipe Scrum<!-- END:presentationName,_glbG2gMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG3AMAEduOAKqB9I73uw CRC: 1996011610 -->Backlog de produit<!-- END:presentationName,_glbG3AMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: activityEntryState<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:activityEntryState,_glbG3AMAEduOAKqB9I73uw CRC: 3415695674 -->courant<!-- END:activityEntryState,_glbG3AMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: activityExitState<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:activityExitState,_glbG3AMAEduOAKqB9I73uw CRC: 857105674 -->mis à jour<!-- END:activityExitState,_glbG3AMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG2AMAEduOAKqB9I73uw CRC: 1560166875 -->Directeur Produit<!-- END:presentationName,_glbG2AMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG0wMAEduOAKqB9I73uw CRC: 2978278606 -->Planifier le sprint<!-- END:presentationName,_glbG0wMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG1AMAEduOAKqB9I73uw CRC: 3268100930 -->Rétrospective<!-- END:presentationName,_glbG1AMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG1QMAEduOAKqB9I73uw CRC: 2848551171 -->Faire la revue du sprint<!-- END:presentationName,_glbG1QMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG3QMAEduOAKqB9I73uw CRC: 2138190734 -->Incrément de produit<!-- END:presentationName,_glbG3QMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_glbG1gMAEduOAKqB9I73uw CRC: 234147036 -->Mêlée quotidienne<!-- END:presentationName,_glbG1gMAEduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_RHd0YIGOEduKE9hnyImx1Q CRC: 2138190734 -->Incrément de produit<!-- END:presentationName,_RHd0YIGOEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MpXRYIGOEduKE9hnyImx1Q CRC: 511034597 -->Equipe Scrum<!-- END:presentationName,_MpXRYIGOEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_XJr8krPCEduk5O8SjA21Fg CRC: 1560166875 -->Directeur Produit<!-- END:presentationName,_XJr8krPCEduk5O8SjA21Fg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_9llsAAAvEdubGMceRDupFQ CRC: 2788963971 -->Scrum<!-- END:name,_9llsAAAvEdubGMceRDupFQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_4Fi44QNmEduYd-55D-Aiqg CRC: 250175125 -->date de fin de sprint atteinte<!-- END:value,_4Fi44QNmEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_f5j60QzOEduDObTFE5q79g CRC: 668566809 -->encore des jours dans le sprint<!-- END:value,_f5j60QzOEduDObTFE5q79g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_-UpVwXoSEduJVrY6eKG_mw CRC: 1358752689 -->livraison à préparer<!-- END:value,_-UpVwXoSEduJVrY6eKG_mw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_O1l_kXoTEduJVrY6eKG_mw CRC: 2446605457 -->encore un sprint<!-- END:value,_O1l_kXoTEduJVrY6eKG_mw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_JYpoMYGGEduKE9hnyImx1Q CRC: 1603830779 -->fin de release<!-- END:value,_JYpoMYGGEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_Ew8_sQCiEduhO59Otqg2rw CRC: 1837496682 -->les sprints successifs qui constituent la release<!-- END:value,_Ew8_sQCiEduhO59Otqg2rw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: value<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:value,_Nk6IoACiEduhO59Otqg2rw CRC: 2673724047 -->Phase initiale avant le premier sprint<!-- END:value,_Nk6IoACiEduhO59Otqg2rw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/disciplines/Scrum_activities.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/disciplines/Scrum_activities.html
new file mode 100644
index 0000000..50312b9
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/disciplines/Scrum_activities.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\disciplines\Scrum activities.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Scrum activities.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_6sdMAAL-EduOAKqB9I73uw CRC: 3564997427 -->Activités Scrum<!-- END:presentationName,_6sdMAAL-EduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_6sdMAAL-EduOAKqB9I73uw CRC: 1202879359 -->Les activités spécifiques induites par l'application de Scrum.<!-- END:briefDescription,_6sdMAAL-EduOAKqB9I73uw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-4wqJQ0qXLYZ8kCnpDu--tA CRC: 3045823106 --><p>
+ L'application de Scrum concerne essentiellement les disciplines habituelles de gestion de projet et de gestion des
+ exigences.
+</p><!-- END:mainDescription,-4wqJQ0qXLYZ8kCnpDu--tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-4wqJQ0qXLYZ8kCnpDu--tA CRC: 1867777277 -->Une bonne partie de ces activités est effectuée collectivement, en équipe.<!-- END:keyConsiderations,-4wqJQ0qXLYZ8kCnpDu--tA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Presentation_Scrum.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Presentation_Scrum.html
new file mode 100644
index 0000000..65a662b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Presentation_Scrum.html
@@ -0,0 +1,107 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\concepts\Presentation Scrum.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Presentation Scrum.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3WivIBTQEduFIr9xNbwGyQ CRC: 2788963971 -->Scrum<!-- END:presentationName,_3WivIBTQEduFIr9xNbwGyQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_3WivIBTQEduFIr9xNbwGyQ CRC: 2264033131 -->Scrum repose sur une technique de gestion de projets qui conduit à obtenir un produit avec la plus grande valeur "métier" possible dans la durée la plus réduite.<!-- END:briefDescription,_3WivIBTQEduFIr9xNbwGyQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-MSO8KF-0IlKZJGnSwwTNZA CRC: 2556876446 --><p>
+ Scrum est un processus léger et itératif de gestion de projets, qui fait partie de la famille des <a
+ title="Méthode agile" href="http://fr.wikipedia.org/wiki/Méthode_agile">méthodes agiles</a>, qui partage les valeurs
+ définies dans le Manifeste Agile et qui en reprend les principes fondamentaux.
+</p>
+<h5>
+ Résumé
+</h5>
+<p>
+ Scrum peut se résumer ainsi :
+</p>
+<p class="quote">
+ Scrum conduit à montrer souvent et régulièrement (toutes les 2 à 4 semaines, selon la durée du <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>) un produit (partiel) qui fonctionne. Le métier identifie les exigences et
+ définit leur priorité. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les
+ plus prioritaires. A chaque fin de sprint, tout le monde peut voir fonctionner le produit actuel et contribuer à
+ prendre une décision sur ce qu'on fait : soit le livrer dans l'état, soit continuer à l'améliorer pendant un
+ sprint supplémentaire avant de se reposer la question.
+</p>
+<h5>
+ Origine
+</h5>
+<p>
+ Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée,
+ qui cherche à atteindre un but, comme c'est le cas au rugby quand le pack déploie sa force collective pour avancer avec
+ le ballon pendant une mêlée.
+</p>
+<p>
+ Scrum insiste particulièrement sur l’aspect social et collectif du développement. Le but de Scrum est d'améliorer la
+ qualité et la productivité, avec une approche empirique, en s'appuyant sur l'autonomie de l'équipe.
+</p>
+<h5>
+ Empirisme
+</h5>
+<p>
+ Un processus empirique, donc basé sur l'expérience, nécessite une bonne visibilité, des inspections fréquentes et des
+ adaptations aux plans. Cela se décline dans Scrum par les 2 cycles de régulation :
+</p>
+<ul>
+ <li>
+ lors de mêlées quotidiennes, on tient compte de l'expérience du jour passé pour adapter le planning des jours
+ restant dans le sprint.
+ </li>
+ <li>
+ lors des revues de sprint, on tient compte de l'expérience du sprint passé pour adapter le planning de la release,
+ portant sur les sprints à venir.
+ </li>
+</ul>
+<p>
+ Les tâches d'un sprint ne sont pas définies de façon très précise : pas de date de début, pas de date de fin, pas de
+ dépendance. Scrum considère que ce n'est pas prévisible. L'empirisme de Scrum consiste à s'appuyer continuellement sur
+ l'analyse de l'état courant du projet pour contrôler le processus et réduire les risques.
+</p>
+<h5>
+ Portée
+</h5>
+<p>
+ Scrum ne décrit pas toutes les disciplines du développement (analyse, conception, codage, test) et doit être considéré,
+ plutôt qu’un processus complet, comme un pattern de processus qui est concerne la gestion de projet et la gestion
+ des exigences. Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement. C'est à
+ l'équipe de définir elle-même ce qu'elle à faire.
+</p>
+<h5>
+ Diffusion
+</h5>
+<p>
+ Scrum existe depuis les années 90 et connaît une popularité croissante depuis quelques années. Il a été utilisé sur des
+ centaines de projets dans le monde, mais est pour l’instant peu introduit en France. Depuis 3 ans, un processus de
+ certification a été mis en place. En novembre 2006, plus de 7000 personnes avaient obtenu la certification ScrumMaster.
+</p>
+<p>
+ <img height="56" alt="ScrumMaster" src="./resources/csm.jpg" width="179" />
+</p>
+<p>
+ Pour plus d'informations sur Scrum, voir <a href="http://fr.wikipedia.org/wiki/Scrum"
+ target="_blank">http://fr.wikipedia.org/wiki/Scrum</a>
+</p><!-- END:mainDescription,-MSO8KF-0IlKZJGnSwwTNZA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Produit__release_et_sprint.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Produit__release_et_sprint.html
new file mode 100644
index 0000000..dd29547
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Produit__release_et_sprint.html
@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\concepts\Produit, release et sprint.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Produit<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_XtRuYP-zEdqLnajTSLeAsA CRC: 3769340222 -->Produit, release et sprint<!-- END:presentationName,_XtRuYP-zEdqLnajTSLeAsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-BPz1k8sC6CCyJ2yZCc1p2Q CRC: 1599293141 --><p>
+ Une <a class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a> est constituée d'une série de <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s et dure en général quelques mois. Pendant la vie d'un produit, on déroule
+ plusieurs releases.
+</p>
+<p>
+ <img height="115" alt="release et sprints" src="./resources/release.jpg" width="600" />
+</p>
+<p>
+ Une release a les attributs suivants :
+</p>
+<ul class="noindent">
+ <li>
+ le but
+ </li>
+ <li>
+ le type, à choisir entre "à date fixée" et "sans date fixée"(par défaut). Dans le cas où on choisit à date fixée,
+ la date est fournie.
+ </li>
+ <li>
+ la durée, en nombre de jours, définie pour les sprints
+ </li>
+ <li>
+ le nombre de sprints prévus
+ </li>
+</ul>
+<p>
+ Le <a class="elementLink" href="./../../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> constitue un niveau de planification du projet : il
+ montre de façon "grosses mailles" les items qu'il est prévu de réaliser au cours des sprints de cette release.<br />
+ <br />
+</p><!-- END:mainDescription,-BPz1k8sC6CCyJ2yZCc1p2Q -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Travail_collaboratif.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Travail_collaboratif.html
new file mode 100644
index 0000000..31039c0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/Travail_collaboratif.html
@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\concepts\Travail collaboratif.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Travail collaboratif.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_OUjj0AEZEduzRosbOajx7w CRC: 2993569129 -->Travail collaboratif<!-- END:presentationName,_OUjj0AEZEduzRosbOajx7w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dU_t9olFRQIyOBZQvMndKg CRC: 3821094428 --><p>
+ Le collectif prend forme à travers des réunions. Scrum impose 5 types de réunions :
+</p>
+<ol>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a> (1ème partie, sélection du sous-ensemble du backlog))
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>nt (2ème partie, planification du sprint)
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A.html"
+ guid="_d09LYP_AEdqtbrr0B1TG-A">Mêlée quotidienne</a>
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Review sprint,_MRrRYPpbEdqsc-f87sBK8A.html"
+ guid="_MRrRYPpbEdqsc-f87sBK8A">Faire la revue du sprint</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Retrospective,_J_sRIP_AEdqtbrr0B1TG-A.html"
+ guid="_J_sRIP_AEdqtbrr0B1TG-A">Rétrospective</a><br />
+ </li>
+</ol>
+<p>
+ Le tableau ci-dessous montre la participation des rôles Scrum à ces réunions :<br />
+</p>
+<table cellspacing="2" cellpadding="2" width="180" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ 1
+ </th>
+ <th scope="col">
+ 2
+ </th>
+ <th scope="col">
+ 3
+ </th>
+ <th scope="col">
+ 4
+ </th>
+ <th scope="col">
+ 5
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+ </th>
+ <td>
+ Animation
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Equipe
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Intervenant
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ Possible
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br /><!-- END:mainDescription,-dU_t9olFRQIyOBZQvMndKg -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/resources/csm.jpg b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/resources/release.jpg b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/resources/release.jpg
new file mode 100644
index 0000000..a270cd4
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/concepts/resources/release.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Release_Burndown_Chart.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Release_Burndown_Chart.html
new file mode 100644
index 0000000..f1bcb4a
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Release_Burndown_Chart.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\reports\Release Burndown Chart.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Release Burndown Chart.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_vKqe8PpaEdqsc-f87sBK8A CRC: 1486376198 -->Release Burndown Chart<!-- END:presentationName,_vKqe8PpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_vKqe8PpaEdqsc-f87sBK8A CRC: 1620309490 -->Présentation de l'avancement de la release.<!-- END:briefDescription,_vKqe8PpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-pJuF9iKbSQx7TIwHNBVTgg CRC: 3526652727 --><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a> pour une release : il montre la tendance dans
+ l'avancement de la release par une présentation graphique du reste à faire à la fin de chaque sprint passé.
+</p><!-- END:mainDescription,-pJuF9iKbSQx7TIwHNBVTgg -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Release_Planning.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Release_Planning.html
new file mode 100644
index 0000000..41aacbd
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Release_Planning.html
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\reports\Release Planning.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Release Planning.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Z2NzkIGWEduKE9hnyImx1Q CRC: 1236554079 -->Planning de la release<!-- END:presentationName,_Z2NzkIGWEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Z2NzkIGWEduKE9hnyImx1Q CRC: 771836301 -->Plan montrant les sprints et les éléments du backlog associés à ces sprints<!-- END:briefDescription,_Z2NzkIGWEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-EmLqiNX2WnmsfEtxNiuyTQ CRC: 341568499 --><p>
+ Il est dérivé du backlog de produit : c'est un sous-ensemble contenant uniquement les éléments prévus dans la release
+ et associés aux sprints prévus dans la release.
+</p><!-- END:mainDescription,-EmLqiNX2WnmsfEtxNiuyTQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Sprint_Burndown_Chart.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Sprint_Burndown_Chart.html
new file mode 100644
index 0000000..66b916e
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/reports/Sprint_Burndown_Chart.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\reports\Sprint Burndown Chart.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Sprint Burndown Chart.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_jC4NwPpaEdqsc-f87sBK8A CRC: 3861952122 -->Sprint Burndown Chart<!-- END:presentationName,_jC4NwPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_jC4NwPpaEdqsc-f87sBK8A CRC: 2294664448 -->Présentation de l'avancement du sprint courant.<!-- END:briefDescription,_jC4NwPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-qVeT6_sAspmZjCYQLOrhbg CRC: 3828940937 --><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a> pour un sprint : il montre la tendance dans
+ l'avancement du sprint par une présentation graphique du reste à faire à la fin de chaque jour passé.
+</p><!-- END:mainDescription,-qVeT6_sAspmZjCYQLOrhbg -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/roadmaps/Application.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/roadmaps/Application.html
new file mode 100644
index 0000000..35cd17a
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/roadmaps/Application.html
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\roadmaps\Application.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Application.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_6Jox0IRuEduo75chJsIcXg CRC: 3581421262 -->Appliquer Scrum<!-- END:presentationName,_6Jox0IRuEduo75chJsIcXg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_6Jox0IRuEduo75chJsIcXg CRC: 370691013 -->Appliquer Scrum sans oublier les principes<!-- END:briefDescription,_6Jox0IRuEduo75chJsIcXg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-IPxNSDzXKWa-H_kJ2PMtYA CRC: 3766127703 --><p>
+ Le Manifeste Agile proclame que "les outils et les processus sont utiles, mais que les personnes et les
+ interactions qu'elles ont entre elles sont plus importantes" pour la réussite du projet. Il faut garder ce principe à
+ l'esprit lors de l'application de Scrum. Il convient également de respecter les caractéristiques de Scrum comme :
+</p>
+<ul>
+ <li>
+ l'approche empirique basée sur la régulation,
+ </li>
+ <li>
+ la planification adaptative plutôt que prédictive,
+ </li>
+ <li>
+ l'auto-gestion de l'équipe pour faire ce qu'elle a à faire.
+ </li>
+</ul>
+<p>
+ De plus, Scrum ne décrit pas les activités d'ingénierie nécessaires à la réalisation du produit.
+</p>
+<p>
+ L'application de Scrum décrite ci-dessous doit être lue et utilisée à l'aune de ces principes agiles. Elle
+ montre comment les éléments de Scrum sont utilisés lors du déroulement d'une période de temps, ou cycle de vie.
+</p>
+<p>
+ Ce cycle de vie ne représente pas toute la vie d'un produit, mais porte uniquement sur la production d'une <a
+ class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>. Le guide <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA.html"
+ guid="_XtRuYP-zEdqLnajTSLeAsA">Produit, release et sprint</a> replace cette période dans un contexte plus large.
+</p><!-- END:mainDescription,-IPxNSDzXKWa-H_kJ2PMtYA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Copyright.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Copyright.html
new file mode 100644
index 0000000..41cf565
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Copyright.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\supportingmaterials\Copyright.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Copyright.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_N8zs0AEGEduzRosbOajx7w CRC: 3127940944 -->Copyright<!-- END:presentationName,_N8zs0AEGEduzRosbOajx7w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-03XtfjRMEs23qIdCSSQiNQ CRC: 2203246763 -->Ce programme et le matériel qui l'accompagne sont mis à disposition selon les termes de la licence "<a
+href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a>" qui régit cette
+distribution.<!-- END:mainDescription,-03XtfjRMEs23qIdCSSQiNQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Introduction.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Introduction.html
new file mode 100644
index 0000000..8e873f2
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Introduction.html
@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\supportingmaterials\Introduction.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Introduction.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_wz30kABREdu3o4yroaI-tA CRC: 3979448284 -->Introduction<!-- END:presentationName,_wz30kABREdu3o4yroaI-tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_wz30kABREdu3o4yroaI-tA CRC: 641369441 -->Bienvenue dans Scrum !<!-- END:briefDescription,_wz30kABREdu3o4yroaI-tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-WfzsSn3X35gSHQZ2kqtoVw CRC: 660578826 --><p>
+ Ce plugin, réalisé avec <a href="http://www.eclipse.org/epf/" target="_blank">EPF</a> (Eclipse Process
+ Framework) présente :
+</p>
+<ul>
+ <li>
+ une introduction à <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Presentation Scrum,_3WivIBTQEduFIr9xNbwGyQ.html"
+ guid="_3WivIBTQEduFIr9xNbwGyQ">Scrum</a>
+ </li>
+ <li>
+ les notions principales de Scrum (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Scrum Elements,_nF6fgALYEduFv7wnrO7SvQ.html"
+ guid="_nF6fgALYEduFv7wnrO7SvQ">Eléments Scrum</a>),
+ </li>
+ <li>
+ une façon de les appliquer (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Cycle de vie Scrum,_7BSBkABCEduYUKPFgCzFuA.html"
+ guid="_7BSBkABCEduYUKPFgCzFuA">Cycle de vie</a>) qui est à adapter à chaque projet.
+ </li>
+</ul><!-- END:mainDescription,-WfzsSn3X35gSHQZ2kqtoVw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Scrum_references.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Scrum_references.html
new file mode 100644
index 0000000..df11fcc
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/supportingmaterials/Scrum_references.html
@@ -0,0 +1,35 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\supportingmaterials\Scrum references.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Scrum references.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_PTGe4IRvEduo75chJsIcXg CRC: 2552649995 -->Références<!-- END:presentationName,_PTGe4IRvEduo75chJsIcXg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-cfa6bdUgQuboNpJRKaCLAw CRC: 3395711479 --><ul>
+ <li>
+ Ken Schwaber : <a href="http://softpro.stores.yahoo.net/0-7356-1993-x.html" target="_blank">Agile Project
+ Management with Scrum.</a>
+ </li>
+ <li>
+ Mike Cohn : <a
+ href="http://www.amazon.fr/exec/obidos/ASIN/0131479415/sr=8-1/qid=1152998855/ref=sr_1_1/402-4433368-7461703?_encoding=UTF8&s=gateway&v=glance"
+ target="_blank">Agile Estimating and Planning</a>
+ </li>
+</ul><!-- END:mainDescription,-cfa6bdUgQuboNpJRKaCLAw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Burndown_Chart.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Burndown_Chart.html
new file mode 100644
index 0000000..2d4afca
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Burndown_Chart.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\termdefinitions\Burndown Chart.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Burndown Chart.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_X5rREILYEduLd8CaF_IcMA CRC: 3776790192 -->Graphe de tendance<!-- END:presentationName,_X5rREILYEduLd8CaF_IcMA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KQ4Jzjy6YgAr_2NXa4J67g CRC: 1165227047 -->Représentation graphique du reste à faire dans une période, actualisée aussi souvent que possible.<!-- END:mainDescription,-KQ4Jzjy6YgAr_2NXa4J67g -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Release.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Release.html
new file mode 100644
index 0000000..91c43b0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Release.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\termdefinitions\Release.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Release.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_AIB9gIHrEduFs9jH8xc4xw CRC: 1375353473 -->Release<!-- END:presentationName,_AIB9gIHrEduFs9jH8xc4xw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-XPyPmZTAVbnvJVuOLvYpXw CRC: 1957346605 -->Une release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps
+qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs.<!-- END:mainDescription,-XPyPmZTAVbnvJVuOLvYpXw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Sprint.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Sprint.html
new file mode 100644
index 0000000..985c71a
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Sprint.html
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\termdefinitions\Sprint.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Sprint.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_kftWoIHqEduFs9jH8xc4xw CRC: 3895218305 -->Sprint<!-- END:presentationName,_kftWoIHqEduFs9jH8xc4xw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-fcoz1Nm_QnX6xtLg5YWdVg CRC: 414377054 -->Un sprint est un bloc de temps aboutissant à créer un incrément du produit. C'est le terme utilisé dans Scrum pour
+itération.<!-- END:mainDescription,-fcoz1Nm_QnX6xtLg5YWdVg -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Theme.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Theme.html
new file mode 100644
index 0000000..46da0d7
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Theme.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\termdefinitions\Theme.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Theme.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_aeYKoIKlEduQgtHqedKdMA CRC: 3515292355 -->Thème<!-- END:presentationName,_aeYKoIKlEduQgtHqedKdMA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-GKfSarwQLoaHhoT71FQI8Q CRC: 2942741686 -->Un thème constitue un regroupement fonctionnel d'exigences.<!-- END:mainDescription,-GKfSarwQLoaHhoT71FQI8Q -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Timebox.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Timebox.html
new file mode 100644
index 0000000..de3366e
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Timebox.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\termdefinitions\Timebox.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Timebox.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3qdXkILXEduLd8CaF_IcMA CRC: 2833618125 -->Bloc de temps<!-- END:presentationName,_3qdXkILXEduLd8CaF_IcMA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-tHVOELWOQDI7i0M2rlMufQ CRC: 2992139808 -->Une période de temps à échéance fixée et intangible même si tous les objectifs ne sont pas atteints.<!-- END:mainDescription,-tHVOELWOQDI7i0M2rlMufQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Velocity.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Velocity.html
new file mode 100644
index 0000000..6f7c811
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/guidances/termdefinitions/Velocity.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\guidances\termdefinitions\Velocity.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Velocity.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_HQEP8ILXEduLd8CaF_IcMA CRC: 1390750740 -->Vélocité<!-- END:presentationName,_HQEP8ILXEduLd8CaF_IcMA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-PeP4fADValHXs2Z2Z8zJ1w CRC: 2430539459 -->La vélocité est la mesure de la capacité de l'équipe pendant un sprint.<!-- END:mainDescription,-PeP4fADValHXs2Z2Z8zJ1w -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/plugin.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/plugin.html
new file mode 100644
index 0000000..641d5a8
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/plugin.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\plugin.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plugin.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_mQ3eoPpYEdqsc-f87sBK8A CRC: 2072183283 -->Ce plugin porte sur l'utilisation de Scrum.<!-- END:briefDescription,_mQ3eoPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_AcwmAANoEduYd-55D-Aiqg CRC: 3831203073 -->Produits Scrum<!-- END:presentationName,_AcwmAANoEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_7BSBkABCEduYUKPFgCzFuA CRC: 3580419597 -->Cycle de vie<!-- END:presentationName,_7BSBkABCEduYUKPFgCzFuA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_rkSgEPpYEdqsc-f87sBK8A CRC: 3868928744 -->Eléments de Scrum<!-- END:name,_rkSgEPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_rkSgEPpYEdqsc-f87sBK8A CRC: 1484055475 -->Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet. Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques. <!-- END:briefDescription,_rkSgEPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_SqGkoABREdu3o4yroaI-tA CRC: 3110063372 -->Général<!-- END:name,_SqGkoABREdu3o4yroaI-tA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/Product_Owner.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/Product_Owner.html
new file mode 100644
index 0000000..7f4f568
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/Product_Owner.html
@@ -0,0 +1,112 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\roles\Product Owner.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Product Owner.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ICJyYPpaEdqsc-f87sBK8A CRC: 1560166875 -->Directeur Produit<!-- END:presentationName,_ICJyYPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ICJyYPpaEdqsc-f87sBK8A CRC: 2655024683 -->C’est le représentant du "métier" dans le projet. <!-- END:briefDescription,_ICJyYPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-35iKPqDM2F2PjKWQLCW4tA CRC: 2935725989 --><p>
+ Le Directeur de produit (<i>Product Owner</i>) est le représentant des clients et utilisateurs dans l'équipe.
+</p>
+<p>
+ A ce titre, il est responsable de définir les caractéristiques du produit développé par l'équipe en termes de :
+</p>
+<ul>
+ <li>
+ <strong>fonctionnalités</strong> offertes. Plus précisément il identifie chaque exigence que doit satisfaire
+ le produit comme un <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a> (ou item). Il fournit les détails sur ces
+ exigences quand c'est nécessaire pour l'équipe. Il est souhaitable qu'il spécifie les tests d'acceptation
+ (acceptance tests) de chaque exigence.
+ </li>
+ <li>
+ <strong>priorité</strong>. C'est lui qui définit l'ordre dans lequel ces éléments seront développés en fonction de
+ la valeur qu'ils apportent aux clients et utilisateurs. Cela permet d'alimenter l'équipe avec un <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a> prêt pour la planification des sprints,
+ </li>
+ <li>
+ <strong>but</strong>. C'est lui définit l'objectif d'une release et qui prend les décisions concernant le <a
+ class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>.
+ </li>
+</ul>
+<br /><!-- END:mainDescription,-35iKPqDM2F2PjKWQLCW4tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-35iKPqDM2F2PjKWQLCW4tA CRC: 3325089670 --><p>
+ Son implication est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il donne
+ l'impulsion à l'équipe. En promouvant à l'extérieur le résultat de chaque sprint, il fournit à l'équipe une
+ reconnaissance qui la motive.
+</p><!-- END:keyConsiderations,-35iKPqDM2F2PjKWQLCW4tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-35iKPqDM2F2PjKWQLCW4tA CRC: 1155206492 --><p>
+ Une personne qui joue ce rôle devrait posséder les compétences suivantes :
+</p>
+<ul>
+ <li>
+ bonne connaissance du domaine métier,
+ </li>
+ <li>
+ capacité à avoir une position respectée par tous les intervenants extérieurs (clients et utilisateurs),
+ </li>
+ <li>
+ capacité à prendre une décision au bon moment (pas trop tôt ni trop tard),
+ </li>
+ <li>
+ esprit ouvert au changement,
+ </li>
+ <li>
+ facilité à communiquer avec l'équipe.
+ </li>
+</ul>
+<p>
+ Quelqu'un qui a été Analyste Métier (Business Analyst) est un bon candidat pour ce rôle.
+</p><!-- END:skills,-35iKPqDM2F2PjKWQLCW4tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,-35iKPqDM2F2PjKWQLCW4tA CRC: 3299669871 --><p>
+ Il n'y a qu'une seule personne qui joue ce rôle. Cette personne doit être affectée au projet (le Directeur de produit
+ fait partie de l'équipe étendue et participe aux réunions). Le travail nécessite une affectation à plein temps ou
+ presque.
+</p>
+<p>
+ Il est important qu'il soit très disponible pour répondre aux questions de l'équipe, pour définir les tests
+ fonctionnels et donner son avis sur divers aspects du produit (l'interface homme machine d'un logiciel, par
+ exemple).
+</p><!-- END:assignmentApproaches,-35iKPqDM2F2PjKWQLCW4tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: synonyms<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:synonyms,-35iKPqDM2F2PjKWQLCW4tA CRC: 2615276665 -->Propriétaire de produit (product owner en anglais), Client (dans XP)<!-- END:synonyms,-35iKPqDM2F2PjKWQLCW4tA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/ScrumMaster.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/ScrumMaster.html
new file mode 100644
index 0000000..5ba8ee8
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/ScrumMaster.html
@@ -0,0 +1,164 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\roles\ScrumMaster.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: ScrumMaster.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_t1K9kPpYEdqsc-f87sBK8A CRC: 4226345851 -->ScrumMaster<!-- END:presentationName,_t1K9kPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_t1K9kPpYEdqsc-f87sBK8A CRC: 2432138996 -->C' est l'animateur d'une équipe Scrum.<!-- END:briefDescription,_t1K9kPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Y3SFEe-A-lRF8TaEn9vKNQ CRC: 1896641090 --><p>
+ Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome
+ et à s'améliorer constamment.
+</p>
+<p>
+ Pour cela, il effectue les travaux suivants :
+</p>
+<ul>
+ <li>
+ tâches périodiques, dont l'objectif est de mettre en application Scrum en organisant et animant le <a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a> (réunions) :
+ <ul>
+ <li>
+ Mêlée quotidienne.
+ </li>
+ <li>
+ Planification du sprint
+ </li>
+ <li>
+ Revue du sprint
+ </li>
+ <li>
+ Rétrospective
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâches sur évènement
+ <ul>
+ <li>
+ éliminer les obstacles : prendre en compte les évènements qui surviennent à tout moment sur un projet
+ pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâche de fond
+ <ul>
+ <li>
+ faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les
+ éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .
+ </li>
+ </ul>
+ </li>
+</ul>
+<p>
+ Analogies
+</p>
+<ul>
+ <li>
+ Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de
+ ScrumMaster.
+ </li>
+ <li>
+ Ken Schwaber compare le ScrumMaster à un chien de berger.
+ </li>
+</ul>
+<br /><!-- END:mainDescription,-Y3SFEe-A-lRF8TaEn9vKNQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-Y3SFEe-A-lRF8TaEn9vKNQ CRC: 1533268570 --><ul>
+ <li>
+ Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas.
+ </li>
+ <li>
+ Il fait partie de l'équipe : il s'engage avec les autres.
+ </li>
+ <li>
+ Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.
+ </li>
+</ul><!-- END:keyConsiderations,-Y3SFEe-A-lRF8TaEn9vKNQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-Y3SFEe-A-lRF8TaEn9vKNQ CRC: 1137854156 --><p>
+ Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est
+ préférable de posséder les compétences suivantes pour jouer ce rôle :
+</p>
+<ul>
+ <li>
+ bien connaître Scrum,
+ </li>
+ <li>
+ avoir des facilités de présentation, de communication et de négociation,
+ </li>
+ <li>
+ guider sans imposer,
+ </li>
+ <li>
+ faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
+ </li>
+ <li>
+ savoir résoudre les conflits et les problèmes,
+ </li>
+ <li>
+ communiquer honnêtement sur le degré d'avancement,
+ </li>
+ <li>
+ garder le respect de l'objectif essentiel, qui est de livrer un produit qui remplit ses exigences.
+ </li>
+</ul>
+<p>
+ En revanche il n'est pas nécessaire de :
+</p>
+<ul>
+ <li>
+ avoir de l'expérience du domaine de l'application (pas indispensable, mais ça peut aider),
+ </li>
+ <li>
+ avoir des compétences techniques sur le développement.
+ </li>
+</ul><!-- END:skills,-Y3SFEe-A-lRF8TaEn9vKNQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,-Y3SFEe-A-lRF8TaEn9vKNQ CRC: 3814805409 --><p>
+ Pour une équipe Scrum typique (de 6 à 10 personnes) , une seule personne joue ce rôle sur un projet.
+</p>
+<p>
+ Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela
+ doit rester limité.
+</p><!-- END:assignmentApproaches,-Y3SFEe-A-lRF8TaEn9vKNQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: synonyms<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:synonyms,-Y3SFEe-A-lRF8TaEn9vKNQ CRC: 3528901502 --><p>
+ Facilitateur de processus. On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela
+ ne favorise pas la compréhension du rôle.
+</p><!-- END:synonyms,-Y3SFEe-A-lRF8TaEn9vKNQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/StakeHolder.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/StakeHolder.html
new file mode 100644
index 0000000..e59cbef
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/StakeHolder.html
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\roles\StakeHolder.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: StakeHolder.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Qqmp8P_AEdqtbrr0B1TG-A CRC: 4115438475 -->Intervenant<!-- END:presentationName,_Qqmp8P_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Qqmp8P_AEdqtbrr0B1TG-A CRC: 3029589477 -->Personne ne participant pas directement au projet mais ayant une influence sur celui-ci.<!-- END:briefDescription,_Qqmp8P_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-u0-b4PNo9XzOh1-dv_aaKA CRC: 2411863165 --><p>
+ Un intervenant ne fait pas partie de l'équipe, mais il est intéressé par le produit réalisé. Il peut avoir une
+ influence sur le déroulement du projet. Il participe à des réunions Scrum : voir sa contribution au <a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>.
+</p>
+<p>
+ Dans son jargon, Scrum appelle les personnes jouant ce rôle des poules (chicken) et conseille de protéger
+ l’équipe, constituée des cochons (pigs), de leur influence directe sur le projet pendant un sprint. Cela signifie que
+ les intervenants ont des fenêtres d'intervention qui sont strictement définies afin de ne pas perturber le travail de
+ l'équipe.
+</p><!-- END:mainDescription,-u0-b4PNo9XzOh1-dv_aaKA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: synonyms<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:synonyms,-u0-b4PNo9XzOh1-dv_aaKA CRC: 2235490754 --><p>
+ Partie-prenante (Stakeholder en anglais)
+</p><!-- END:synonyms,-u0-b4PNo9XzOh1-dv_aaKA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/Team.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/Team.html
new file mode 100644
index 0000000..777e3c6
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/roles/Team.html
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\roles\Team.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Team.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9apLsPpaEdqsc-f87sBK8A CRC: 511034597 -->Equipe Scrum<!-- END:presentationName,_9apLsPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_9apLsPpaEdqsc-f87sBK8A CRC: 2640185647 -->Il s'agit d'un rôle collectif. Tous les membres de l'équipe participent au travail, sans qu'on disitingue des fonctions particulières pour chacun.<!-- END:briefDescription,_9apLsPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-LVZG5zK2YjEGXO3SwDmqug CRC: 3353500154 --><p>
+ Une équipe regroupe des membres qui forment un tout soudé capable de réaliser les différentes tâches sur
+ lesquelles elle s’engage collectivement lors de chaque sprint.
+</p>
+<p>
+ Elle possède la latitude voulue pour déterminer ce qui doit être fait afin d’atteindre le but fixé du sprint. Elle
+ s’organise de façon autonome et planifie ses propres travaux, sans se les faire imposer.
+</p><!-- END:mainDescription,-LVZG5zK2YjEGXO3SwDmqug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-LVZG5zK2YjEGXO3SwDmqug CRC: 1409651416 -->Par son approche centrée sur le collectif, l'agilité contribue à améliorer la camaraderie dans l’équipe.<!-- END:keyConsiderations,-LVZG5zK2YjEGXO3SwDmqug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-LVZG5zK2YjEGXO3SwDmqug CRC: 3469799279 -->L’équipe doit être capable de réaliser les différentes tâches sur lesquelles elle s'engage lors de la planification du
+sprint. Cela signifie qu'elle doit être multi-fonctionnelle (cross-functional) pour couvrir les travaux d'analyse, de
+conception, de codage, de test et autres.<!-- END:skills,-LVZG5zK2YjEGXO3SwDmqug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: assignmentApproaches<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:assignmentApproaches,-LVZG5zK2YjEGXO3SwDmqug CRC: 3126790376 -->Une équipe Scrum comprend généralement de 3 à 10 personnes.<!-- END:assignmentApproaches,-LVZG5zK2YjEGXO3SwDmqug -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/rolesets/Scrum_Roles.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/rolesets/Scrum_Roles.html
new file mode 100644
index 0000000..72f63d1
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/rolesets/Scrum_Roles.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\rolesets\Scrum Roles.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Scrum Roles.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_3qmmoP-zEdqLnajTSLeAsA CRC: 2360193471 -->Rôles Scrum<!-- END:presentationName,_3qmmoP-zEdqLnajTSLeAsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_3qmmoP-zEdqLnajTSLeAsA CRC: 331839585 -->Les rôles dans un projet qui applique Scrum.<!-- END:briefDescription,_3qmmoP-zEdqLnajTSLeAsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-CgLjZ6Bwc0EyYyQCjzlw7g CRC: 731115018 --><p>
+ Scrum définit uniquement 3 rôles pour les personnes qui participent aux travaux de développement. A la différence
+ d’autres processus, il n’existe pas d’architecte, de programmeur, de testeur, d’analyste, de rédacteur. L’équipe
+ regroupe les compétences sans distinction du rôle de chacun a priori.
+</p>
+<p>
+ Toutes les personnes ayant une influence sur le projet sans y participer directement sont représentées par le rôle
+ <a class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>.
+</p><!-- END:mainDescription,-CgLjZ6Bwc0EyYyQCjzlw7g -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Initiate_Product_Backlog.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Initiate_Product_Backlog.html
new file mode 100644
index 0000000..7ca78ef
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Initiate_Product_Backlog.html
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Initiate Product Backlog.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Initiate Product Backlog.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_BGFMoANkEduYd-55D-Aiqg CRC: 727012805 -->Elaborer le backlog de produit initial<!-- END:presentationName,_BGFMoANkEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_BGFMoANkEduYd-55D-Aiqg CRC: 2170073726 -->Identifier une liste d'items, les inclure dans le backlog et les classer par priorité.<!-- END:briefDescription,_BGFMoANkEduYd-55D-Aiqg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-mi1O4H7RRm0YqlUNyp8TJg CRC: 919313895 --><p>
+ Le backlog initial doit permettre de planifier au moins les 2 ou 3 premiers sprints.
+</p><!-- END:keyConsiderations,-mi1O4H7RRm0YqlUNyp8TJg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-mi1O4H7RRm0YqlUNyp8TJg CRC: 3385836891 -->Le but est de produire un backlog au moins suffisant pour permettre le démarrage de la série des sprints.<!-- END:purpose,-mi1O4H7RRm0YqlUNyp8TJg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_pWL_gAPJEdubhrgDuRb4fA CRC: 3629735713 -->Collecter les éléments du backlog<!-- END:name,_pWL_gAPJEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_pWL_gAPJEdubhrgDuRb4fA CRC: 2317119429 --><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> établit une première liste des exigences (une
+ exigence devient un <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>) qu'il souhaite voir réalisées pour la fin de la
+ release.
+</p>
+<p>
+ Pour compléter cette liste et obtenir un backlog suffisant, il est conseillé d'organiser un workshop réunissant toute
+ l'équipe plus des intervenants. Au cours de ce workshop, le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a> présente son ébauche de backlog et chacun intervient pour proposer de nouveaux items.
+</p>
+<p>
+ Il est fréquent qu'un élément du backlog soit identifié comme une histoire d'utilisateur (User story), technique
+ utilisée à l'origine dans EXtreme Programming (XP) et qui s'adapte très bien à Scrum.
+</p>
+<br /><!-- END:sectionDescription,_pWL_gAPJEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_u0Z7sAPJEdubhrgDuRb4fA CRC: 2739709896 -->Ordonner le backlog<!-- END:name,_u0Z7sAPJEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_u0Z7sAPJEdubhrgDuRb4fA CRC: 756747292 --><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> ordonne les éléments du backlog selon une priorité
+ décroissante. Pour lui, A plus prioritaire que B signifie qu'il souhaite disposer, dans un produit partiel, de l'item A
+ avant l'item B.
+</p>
+<p>
+ Lorsque le backlog contient beaucoup d'éléments, le classement par priorité de chacun est fastidieux et délicat. C'est
+ pourquoi il est utile de définir des <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Theme,_aeYKoIKlEduQgtHqedKdMA.html"
+ guid="_aeYKoIKlEduQgtHqedKdMA">Thème</a>s, d'associer à chaque élément un thème et de définir les priorités
+ sur les thèmes avant de passer aux éléments. Cela peut être fait lors d'une réunion à laquelle participent les <a
+ class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>s, ainsi que des membres de l'équipe.
+</p><!-- END:sectionDescription,_u0Z7sAPJEdubhrgDuRb4fA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Manage_problems.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Manage_problems.html
new file mode 100644
index 0000000..c3ace94
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Manage_problems.html
@@ -0,0 +1,84 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Manage problems.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Manage problems.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Xpd5gP_AEdqtbrr0B1TG-A CRC: 1092083131 -->Gérer les problèmes<!-- END:presentationName,_Xpd5gP_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Xpd5gP_AEdqtbrr0B1TG-A CRC: 2920115610 -->Prendre en compte les événements qui surviennent à tout moment sur un projet et tenter de les régler.<!-- END:briefDescription,_Xpd5gP_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-mZfAV7RcWJlp5idlHzeEcA CRC: 339914848 --><p>
+ Cette tâche est centrée sur la résolution de ces problèmes.
+</p><!-- END:keyConsiderations,-mZfAV7RcWJlp5idlHzeEcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-mZfAV7RcWJlp5idlHzeEcA CRC: 892691220 -->Le but est de d'éliminer les problèmes rencontrés par l'équipe pour qu'elle puisse se concentrer sur ses véritables
+objectifs.<!-- END:purpose,-mZfAV7RcWJlp5idlHzeEcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_LCxqQAB6EduSVaTQTBfIHA CRC: 954760299 -->Prendre connaissance du problème<!-- END:name,_LCxqQAB6EduSVaTQTBfIHA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_LCxqQAB6EduSVaTQTBfIHA CRC: 1350130701 --><p>
+ La réunion quotidienne est l'endroit idéal pour déceler les problèmes qu'une équipe rencontre. Elle peut même permettre
+ de les résoudre immédiatement grâce à la collaboration de l'équipe. Cependant :
+</p>
+<ul>
+ <li>
+ il arrive que des problèmes urgents soient soulevés entre 2 réunions quotidiennes
+ </li>
+ <li>
+ et surtout la résolution des problèmes n'est pas faite en réunion (sauf si elle évidente)
+ </li>
+</ul>
+<p>
+ Suite à la mise en évidence d'un problème, par exemple lors de la réunion quotidienne, identifier la cause du
+ problème et les impacts sur le projet. Pour cela une communication orale, à l'initiative du <a
+ class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>, avec la personne qui a soulevé le problème est souhaitable.
+</p><!-- END:sectionDescription,_LCxqQAB6EduSVaTQTBfIHA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_PIKyUAB6EduSVaTQTBfIHA CRC: 546248621 -->Décider d'un plan d'action<!-- END:name,_PIKyUAB6EduSVaTQTBfIHA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_PIKyUAB6EduSVaTQTBfIHA CRC: 585614096 --><p>
+ Identifier les solutions possibles.<br />
+ Une réunion avec le responsable hiérarchique est organisée si des problèmes survenant sur le projet ne peuvent pas
+ être réglés simplement ou sont à un niveau au-dessus de son autorité.
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a> doit s'efforcer de résoudre le problème au plus tôt, pour ne pas
+ perturber l'avancement de l'équipe.
+</p><!-- END:sectionDescription,_PIKyUAB6EduSVaTQTBfIHA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Plan_release.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Plan_release.html
new file mode 100644
index 0000000..568a40b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Plan_release.html
@@ -0,0 +1,155 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Plan release.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Plan release.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ho-aIP_BEdqtbrr0B1TG-A CRC: 3928792880 -->Planifier la release<!-- END:presentationName,_ho-aIP_BEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_ho-aIP_BEdqtbrr0B1TG-A CRC: 1919342363 -->Planification à moyen terme<!-- END:briefDescription,_ho-aIP_BEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-3f4axrWBKHGv74oKN2x-gQ CRC: 3158628158 -->Il s'agit d'un travail collectif à l'initiative du directeur de produit.<!-- END:keyConsiderations,-3f4axrWBKHGv74oKN2x-gQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-3f4axrWBKHGv74oKN2x-gQ CRC: 3655311501 --><p>
+ Elaborer la planification initiale de la release permettant de lancer la série de sprints.
+</p><!-- END:purpose,-3f4axrWBKHGv74oKN2x-gQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_8qN08APJEdubhrgDuRb4fA CRC: 3490483541 -->Définir les conditions de succès de la release<!-- END:name,_8qN08APJEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_8qN08APJEdubhrgDuRb4fA CRC: 4214547619 --><p>
+ Il existe 2 types de releases :
+</p>
+<ul>
+ <li>
+ une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
+ une date fixée.
+ </li>
+ <li>
+ une release dirigée par les fonctionnalités. La liste des exigences est connue et la release prendra fin lorsque
+ toutes les exigences seront réalisées.
+ </li>
+</ul>
+<p>
+ Les conditions de succès sont définies en fonction de ce type de release.
+</p>
+<br /><!-- END:sectionDescription,_8qN08APJEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_BuXEQAPKEdubhrgDuRb4fA CRC: 2262499874 -->Estimer les éléments du backlog<!-- END:name,_BuXEQAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_BuXEQAPKEdubhrgDuRb4fA CRC: 669332130 --><p>
+ L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
+</p>
+<p>
+ L'estimation est réalisée en équipe.
+</p>
+<p>
+ La grandeur utilisée pour les estimations est de préférence le point, sans unités. Pour les valeurs utilisées pour les
+ estimations, on utilise souvent la suite de Fibonacci (1, 2, 3, 5, 8 et 13).
+</p>
+<p>
+ Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
+ de pratiquer le "planning poker" et de travailler par analogie en comparant les éléments estimés.
+</p><!-- END:sectionDescription,_BuXEQAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_EaLKQAPKEdubhrgDuRb4fA CRC: 2660189374 -->Définir la durée des sprints<!-- END:name,_EaLKQAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_EaLKQAPKEdubhrgDuRb4fA CRC: 3641580099 --><p>
+ Historiquement dans Scrum, la durée d'un sprint est de 30 jours. Cependant il est possible et même recommandé de faire
+ des sprints plus courts. La durée dépend du projet et des contraintes qui s'y appliquent.<br />
+</p><!-- END:sectionDescription,_EaLKQAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_HDZ2UAPKEdubhrgDuRb4fA CRC: 3358480651 -->Estimer la vélocité<!-- END:name,_HDZ2UAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_HDZ2UAPKEdubhrgDuRb4fA CRC: 1339097853 --><p>
+ L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a> réelle. Elle sera alors utilisée pour cette release, éventuellement
+ ajustée compte tenu de la nature du projet. Attention cependant un point n'a pas forcément la même valeur dans des
+ projets différents.
+</p>
+<p>
+ Si ce n'est pas le cas, il faut faire une estimation de la vélocité. Le mieux est de travailler sur le contenu du
+ premier sprint de la release et de voir ce que l'équipe pense pouvoir réaliser pendant ce premier sprint. Cela donne
+ une vélocité estimée qui peut être utilisée pour la planification de la release. Ensuite la planification sera basée
+ sur la vélocité mesurée dans les sprints précédents.
+</p><!-- END:sectionDescription,_HDZ2UAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_I71XkAPKEdubhrgDuRb4fA CRC: 2325176769 -->Associer les éléments du backlog aux sprints<!-- END:name,_I71XkAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_I71XkAPKEdubhrgDuRb4fA CRC: 3330010867 --><p>
+ En fonction des paramètres suivants :
+</p>
+<ul>
+ <li>
+ les estimations de chaque item,
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité),
+ </li>
+ <li>
+ la vélocité estimée pour la release,
+ </li>
+</ul>
+<p>
+ on affecte les items aux sprints de la release.
+</p>
+<p>
+ Il est normal d'ajuster, c'est à dire de changer légèrement l'ordre des items, ne serait-ce que pour se rapprocher le
+ plus possible de la vélocité (en effet on ne tombe pas toujours "rond").
+</p>
+<p>
+ Il faut associer des items aux premiers sprints (les 2 ou 3 premiers), mais il n'est pas indispensable de le faire pour
+ tous les sprints de la release.
+</p><!-- END:sectionDescription,_I71XkAPKEdubhrgDuRb4fA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Plan_sprint_2.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Plan_sprint_2.html
new file mode 100644
index 0000000..c20926d
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Plan_sprint_2.html
@@ -0,0 +1,177 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Plan sprint 2.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Plan sprint 2.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_4LOggPpaEdqsc-f87sBK8A CRC: 2978278606 -->Planifier le sprint<!-- END:presentationName,_4LOggPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_4LOggPpaEdqsc-f87sBK8A CRC: 3974195252 -->Planification du court terme<!-- END:briefDescription,_4LOggPpaEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-NRwwk6YGAtu25V3Lc04G6w CRC: 4228366794 --><p>
+ La réunion de planification de sprint est un travail réalisé en groupe.
+</p>
+<p>
+ Elle est limitée dans le temps :
+</p>
+<ul>
+ <li>
+ durée max : limitée à 4 heures
+ </li>
+ <li>
+ durée moyenne : 2 heures
+ </li>
+</ul><!-- END:keyConsiderations,-NRwwk6YGAtu25V3Lc04G6w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-NRwwk6YGAtu25V3Lc04G6w CRC: 3319225101 -->Le but est de planifier le sprint qui commence.<!-- END:purpose,-NRwwk6YGAtu25V3Lc04G6w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_TJNsUP--Edqtbrr0B1TG-A CRC: 84701924 -->Définir le but du sprint<!-- END:name,_TJNsUP--Edqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_TJNsUP--Edqtbrr0B1TG-A CRC: 568426307 --><p>
+ Au début lors des premiers sprints de la première release d'un produit, le but est bien souvent de montrer la
+ faisabilité de l'architecture envisagée.
+</p>
+<p>
+ Ensuite, une fois que l'architecture est stabilisée, le but d'un sprint est proposé par le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a> et discuté avec l'équipe. Il porte souvent sur un thème fonctionnel.
+</p><!-- END:sectionDescription,_TJNsUP--Edqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_xvy5UAPKEdubhrgDuRb4fA CRC: 3619794437 -->Sélectionner les items<!-- END:name,_xvy5UAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_xvy5UAPKEdubhrgDuRb4fA CRC: 1436541147 --><p>
+ Il s'agit de définir le périmètre de ce sprint. Cela est fait en associant un <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a> au sprint puis un autre en tenant compte de la
+ vélocité de l'équipe.
+</p>
+<p>
+ Si un <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> a été effectué, cette étape consiste seulement à valider
+ collectivement le sous-ensemble du backlog prévu pour ce sprint.
+</p><!-- END:sectionDescription,_xvy5UAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_p4C0sP--Edqtbrr0B1TG-A CRC: 382414914 -->Identifier les tâches à partir des items<!-- END:name,_p4C0sP--Edqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_p4C0sP--Edqtbrr0B1TG-A CRC: 3752350718 --><p>
+ La 2ème partie de la réunion a pour objectif de définir comment l’équipe va s’arranger pour réaliser le résultat
+ attendu du sprint.<br />
+ Pour cela, chaque <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a> sélectionné est décomposé en tâches. Cela permet
+ à toute l’équipe de discuter et d’éclaircir des points de solution par rapport à cet item, en demandant si nécessaire
+ au propriétaire de produit des précisions sur le comportement du produit.<br />
+</p>
+<p>
+ Normalement l'ensemble des activités du cycle de vie sont déroulées lors d'un sprint :<br />
+</p>
+<ul>
+ <li>
+ Les exigences sélectionnées sont spécifiées
+ </li>
+ <li>
+ L'architecture est remaniée si nécessaire
+ </li>
+ <li>
+ Les classes et sous-systèmes sont conçus, implémentés et testés
+ </li>
+ <li>
+ Les différents composants sont intégrés et testés
+ </li>
+ <li>
+ Le produit est packagé
+ </li>
+ <li>
+ Les tests d'acceptation sont passés.<br />
+ </li>
+</ul>
+<p>
+ L'importance donnée à ces activités dépend de la place du sprint dans la release.<br />
+ <br />
+ Le travail prévu dans un sprint précédent mais qui n'a pu être réalisé à cause de la réduction des objectifs devient
+ prioritaire pour le sprint suivant.
+</p><!-- END:sectionDescription,_p4C0sP--Edqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_DxNQUAPLEdubhrgDuRb4fA CRC: 1795174630 -->Estimer les tâches<!-- END:name,_DxNQUAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_DxNQUAPLEdubhrgDuRb4fA CRC: 3162440086 --><p>
+ Les taches sont estimées en heures. Il est conseillé d'avoir des tâches suffisamment fines pour qu'une estimation reste
+ inférieure à 16 heures.
+</p>
+<p>
+ L'estimation est faite collectivement, par l'équipe. Au cours de la discussion pour arriver à une estimation, les
+ aspects techniques sont abordés.
+</p><!-- END:sectionDescription,_DxNQUAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_worbAP--Edqtbrr0B1TG-A CRC: 3283188657 -->Attribuer les tâches<!-- END:name,_worbAP--Edqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_worbAP--Edqtbrr0B1TG-A CRC: 2941712191 -->Une fois que les activités du sprint ont été définies, elles seront affectées aux membres de l'équipe. Les activités
+peuvent être réalisées par une ou plusieurs personnes. Toutes les activités doivent être prises en compte, y compris les
+réunions de travail (hors réunions Scrum), les lectures de documents ou de code.<br />
+Il est préférable de différer l'affectation de certaines activités, qui seront prises pendant le sprint en fonction des
+disponibilités des membres de l'équipe.<!-- END:sectionDescription,_worbAP--Edqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_Iq14wAPLEdubhrgDuRb4fA CRC: 2825760581 -->Obtenir l'engagement de l'équipe<!-- END:name,_Iq14wAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_Iq14wAPLEdubhrgDuRb4fA CRC: 1541491738 --><p>
+ Il est souhaitable que l'équipe s'engage collectivement sur le backlog du sprint, c'est à dire sur les éléments du
+ backlog qu'elle estime pouvoir réaliser dans le sprint.
+</p><!-- END:sectionDescription,_Iq14wAPLEdubhrgDuRb4fA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Retrospective.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Retrospective.html
new file mode 100644
index 0000000..477866a
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Retrospective.html
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Retrospective.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Retrospective.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_J_sRIP_AEdqtbrr0B1TG-A CRC: 3268100930 -->Rétrospective<!-- END:presentationName,_J_sRIP_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_J_sRIP_AEdqtbrr0B1TG-A CRC: 3494061 -->Faire un bilan du sprint qui se termine<!-- END:briefDescription,_J_sRIP_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-S4qXwp40l_8eCcyyI7o-3A CRC: 3334116596 --><p>
+ Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé.
+</p>
+<ul>
+ <li>
+ durée max : 2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul><!-- END:keyConsiderations,-S4qXwp40l_8eCcyyI7o-3A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-S4qXwp40l_8eCcyyI7o-3A CRC: 2198851676 -->L’objectif est d'améliorer continuellement le processus.<!-- END:purpose,-S4qXwp40l_8eCcyyI7o-3A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_lwzeABGPEduHloEV5-Zv-w CRC: 2414148319 -->Discussion<!-- END:name,_lwzeABGPEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_lwzeABGPEduHloEV5-Zv-w CRC: 498736588 -->Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé dans l'application de Scrum sur le
+projet.<!-- END:sectionDescription,_lwzeABGPEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_noL2YBGPEduHloEV5-Zv-w CRC: 1965324673 -->Définir le plan d'actions<!-- END:name,_noL2YBGPEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_noL2YBGPEduHloEV5-Zv-w CRC: 4289622288 --><p>
+ L’équipe discute des améliorations possibles et leur donne une priorité.
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a> ajoute les actions d’amélioration dans le backlog.
+</p><!-- END:sectionDescription,_noL2YBGPEduHloEV5-Zv-w -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Review_sprint.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Review_sprint.html
new file mode 100644
index 0000000..a8a4886
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Review_sprint.html
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Review sprint.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Review sprint.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_MRrRYPpbEdqsc-f87sBK8A CRC: 2848551171 -->Faire la revue du sprint<!-- END:presentationName,_MRrRYPpbEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_MRrRYPpbEdqsc-f87sBK8A CRC: 415282164 -->Montrer ce qui a été réalisé et fonctionne. En tirer les conséquences.<!-- END:briefDescription,_MRrRYPpbEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-zoJryMCuHfxWP7Q5Er195Q CRC: 2451787950 --><p>
+ Travail en groupe (lors de la réunion dite de revue de sprint)
+</p>
+<p>
+ Pour la réunion :
+</p>
+<ul class="noindent">
+ <li>
+ durée max : 2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul><!-- END:keyConsiderations,-zoJryMCuHfxWP7Q5Er195Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-zoJryMCuHfxWP7Q5Er195Q CRC: 111227448 --> Le but est de montrer les exigences réalisées pendant le sprint par une démonstration du produit partiel<!-- END:purpose,-zoJryMCuHfxWP7Q5Er195Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_XL6VgAPLEdubhrgDuRb4fA CRC: 778248270 -->Préparer la démonstration<!-- END:name,_XL6VgAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_XL6VgAPLEdubhrgDuRb4fA CRC: 4275440719 -->La préparation de la réunion ne doit pas excéder une heure.<br /><!-- END:sectionDescription,_XL6VgAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ZgJB8APLEdubhrgDuRb4fA CRC: 2421078709 -->Effectuer la démonstration<!-- END:name,_ZgJB8APLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_ZgJB8APLEdubhrgDuRb4fA CRC: 2917638041 -->L’équipe présente le produit partiel résultat de ses travaux, sous forme de démonstration des exigences (histoires
+d'utilisateur) réalisées. Seules les exigences complètement finies (et testées) sont présentées. Cela permet d’avoir une
+mesure objective de l’avancement. <br /><!-- END:sectionDescription,_ZgJB8APLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_cBouUAPLEdubhrgDuRb4fA CRC: 2899021807 -->Evaluer les résultats du sprint<!-- END:name,_cBouUAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_cBouUAPLEdubhrgDuRb4fA CRC: 820057396 --><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> et les intervenants présents (clients, utilisateurs) posent des
+ questions à l’équipe, donnent leur impression, font des propositions et des demandes de changement. Le <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a> est enrichi avec les bugs découverts et les demandes
+ d’évolution.
+</p><!-- END:sectionDescription,_cBouUAPLEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_hrswoHoYEduJVrY6eKG_mw CRC: 2200641363 -->Calculer la vélocité réelle<!-- END:name,_hrswoHoYEduJVrY6eKG_mw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_hrswoHoYEduJVrY6eKG_mw CRC: 343871744 --><p>
+ La <a class="elementLink" href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a> du sprint est obtenue en faisant la somme de tous les points
+ associés aux exigences considérées comme effectivement finies. Elle est comparée à celle des sprints précédents, le
+ plus souvent à travers un <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>.
+</p><!-- END:sectionDescription,_hrswoHoYEduJVrY6eKG_mw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_d776UHoYEduJVrY6eKG_mw CRC: 3268365380 -->Ajuster le plan de la release<!-- END:name,_d776UHoYEduJVrY6eKG_mw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_d776UHoYEduJVrY6eKG_mw CRC: 3552975041 --><p>
+ Les conditions ont pu changer depuis la dernière planification de la release :
+</p>
+<ul>
+ <li>
+ des items ont pu être ajoutés ou suppirmés, les estimations modifiées,
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité) a pu être modifié,
+ </li>
+</ul>
+<p>
+ De plus la vélocité moyenne a pu évoluer avec la prise de la vélocité calculée du sprint.
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> est ajusté en tenant compte de ces nouveaux paramètres.
+</p><!-- END:sectionDescription,_d776UHoYEduJVrY6eKG_mw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Scrum_daily_meeting.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Scrum_daily_meeting.html
new file mode 100644
index 0000000..d7e073c
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Scrum_daily_meeting.html
@@ -0,0 +1,111 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Scrum daily meeting.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Scrum daily meeting.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d09LYP_AEdqtbrr0B1TG-A CRC: 234147036 -->Mêlée quotidienne<!-- END:presentationName,_d09LYP_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_d09LYP_AEdqtbrr0B1TG-A CRC: 2031247625 -->La régulation des activités de développement et de test se fait à travers les mêlées quotidiennes.<!-- END:briefDescription,_d09LYP_AEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-vDOuVl_xPKipKd90HQNZng CRC: 2990886273 --><p>
+ Se déroule tous les jours, avec toute l'équipe, de préférence le matin en arrivant : il est souhaitable que la réunion
+ ait lieu tous les jours au même endroit et à la même heure.
+</p>
+<p>
+ La réunion est limitée à 15 minutes. <br />
+ L’objectif est d’examiner l’avancement des travaux et d'identifier les problèmes potentiels, mais pas de résoudre les
+ problèmes
+</p><!-- END:keyConsiderations,-vDOuVl_xPKipKd90HQNZng -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-vDOuVl_xPKipKd90HQNZng CRC: 43008283 -->Le but est de faire le point sur l'avancement de l'équipe et d'identifier les problèmes. L’objectif est uniquement
+d’examiner l’avancement des travaux, pas de résoudre les problèmes.<!-- END:purpose,-vDOuVl_xPKipKd90HQNZng -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: alternatives<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:alternatives,-vDOuVl_xPKipKd90HQNZng CRC: 1014503942 --><p>
+ Appelé aussi Stand-Up Meeting (XP)
+</p><!-- END:alternatives,-vDOuVl_xPKipKd90HQNZng -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oUrlcBGOEduHloEV5-Zv-w CRC: 846480736 -->Préparer<!-- END:name,_oUrlcBGOEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oUrlcBGOEduHloEV5-Zv-w CRC: 2319814343 -->Chacun met à jour le planning ( le backlog se sprint) en actualisant le reste à faire sur ses tâches, ce qui permet de
+produire un <a class="elementLink"
+href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>.<!-- END:sectionDescription,_oUrlcBGOEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_r0KkEBGOEduHloEV5-Zv-w CRC: 3674985733 -->Se réunir<!-- END:name,_r0KkEBGOEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_r0KkEBGOEduHloEV5-Zv-w CRC: 2115350014 --><p>
+ Chaque membre de l’équipe s’exprime tour à tour, en répondant à 3 questions sur :
+</p>
+<ol>
+ <li>
+ Ce qui a été fait depuis la mêlée précédente (en principe la veille)
+ </li>
+ <li>
+ Ce qui va être fait aujourd’hui
+ </li>
+ <li>
+ Les problèmes rencontrés
+ </li>
+</ol>
+<p>
+ Il est souhaitable que la réunion s'effectue avec tous les personnes de l'équipe debout en cercle et en ayant sous les
+ yeux le <a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+ guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a> et le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a> actualisés.
+</p><!-- END:sectionDescription,_r0KkEBGOEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_vZkkgBGOEduHloEV5-Zv-w CRC: 120426971 -->Consolider<!-- END:name,_vZkkgBGOEduHloEV5-Zv-w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_vZkkgBGOEduHloEV5-Zv-w CRC: 2586214309 -->Le <a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a> remis à jour sert à prendre une décision sur l'ajustement du but
+du sprint. Il faut avoir à l'esprit qu'un sprint est limité dans le temps (bloc de temps) et qu'il est préférable de
+supprimer du contenu prévu initialement plutôt que d'avoir du retard. <br />
+Les problèmes soulevés sont résolus lors de <a class="elementLink"
+href="./../../Scrum/tasks/Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A.html" guid="_Xpd5gP_AEdqtbrr0B1TG-A">Gérer les
+problèmes</a> à l'initiative du <a class="elementLink"
+href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html" guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>.<!-- END:sectionDescription,_vZkkgBGOEduHloEV5-Zv-w -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Update_product_backlog.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Update_product_backlog.html
new file mode 100644
index 0000000..b93b29e
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/tasks/Update_product_backlog.html
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\tasks\Update product backlog.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Update product backlog.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_STkWYP_BEdqtbrr0B1TG-A CRC: 1161395959 -->Mettre à jour le backlog de produit<!-- END:presentationName,_STkWYP_BEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_STkWYP_BEdqtbrr0B1TG-A CRC: 1942379861 -->Prise en compte des changements de périmètre en vue de préparer les sprints suivants.<!-- END:briefDescription,_STkWYP_BEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-XdgedeazfFRGDxMY3Fnh5g CRC: 1443932922 --><p>
+ Pendant le sprint, personne ne peut modifier la sélection des items du backlog effectuée au début du sprint : le
+ périmètre du sprint reste inchangé.
+</p>
+<p>
+ En revanche, n’importe qui, même un intervenant extérieur, peut proposer de nouveaux items pour plus tard. Ces items
+ sont étudiés et ordonnés par le propriétaire du produit en vue de la planification du prochain sprint.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p><!-- END:keyConsiderations,-XdgedeazfFRGDxMY3Fnh5g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-XdgedeazfFRGDxMY3Fnh5g CRC: 3671884806 -->Actualiser le backlog et ajuster la planification en tenant compte des changements apparus depuis le dernier sprint.<!-- END:purpose,-XdgedeazfFRGDxMY3Fnh5g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_c3HaQAPKEdubhrgDuRb4fA CRC: 2312100472 -->Collecter les changements<!-- END:name,_c3HaQAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_c3HaQAPKEdubhrgDuRb4fA CRC: 2599715 --><p>
+ N’importe qui, même un intervenant extérieur, peut proposer des changements à ajouter au backlog.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p>
+<p>
+ Ces éléments sont analysés par le propriétaire du produit en vue de la planification du prochain sprint.
+</p><!-- END:sectionDescription,_c3HaQAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_fkXDoAPKEdubhrgDuRb4fA CRC: 3870589554 -->Réordonner les items<!-- END:name,_fkXDoAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_fkXDoAPKEdubhrgDuRb4fA CRC: 48517143 -->Les éléments ajoutés depuis le sprint précédent sont ordonnés dans le backlog par le <a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+en vue de la planification à venir.<!-- END:sectionDescription,_fkXDoAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_k-kCgAPKEdubhrgDuRb4fA CRC: 2138776853 -->Réestimer les items<!-- END:name,_k-kCgAPKEdubhrgDuRb4fA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_k-kCgAPKEdubhrgDuRb4fA CRC: 2910097392 --><p>
+ L'estimation en points des nouveaux éléments introduits dans le backlog est faite par l'équipe, de préférence lors d'un
+ travail de groupe avec le Directeur de prouit, un ou 2 jours avant la revue de fin de sprint.
+</p>
+<p>
+ Des items déjà présents peuvent également être réestimés.
+</p><!-- END:sectionDescription,_k-kCgAPKEdubhrgDuRb4fA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_Backlog.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_Backlog.html
new file mode 100644
index 0000000..d552107
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_Backlog.html
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\workproducts\Product Backlog.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Product Backlog.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_5ABscPpYEdqsc-f87sBK8A CRC: 1996011610 -->Backlog de produit<!-- END:presentationName,_5ABscPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_5ABscPpYEdqsc-f87sBK8A CRC: 2377793297 -->Contient les exigences d'un produit<!-- END:briefDescription,_5ABscPpYEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Of1SdnAQ9nmsL5DFvD2Uug CRC: 3818812146 --><p>
+ Le backlog du produit est le référentiel des exigences. Il contient des éléments du backlog (appelés aussi des items de
+ backlog de produit).
+</p>
+<p>
+ Sa vie est liée à celle du produit.
+</p><!-- END:mainDescription,-Of1SdnAQ9nmsL5DFvD2Uug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-Of1SdnAQ9nmsL5DFvD2Uug CRC: 1366946200 -->Lister toutes les choses à faire du point de vue du client (le quoi)<!-- END:purpose,-Of1SdnAQ9nmsL5DFvD2Uug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,-Of1SdnAQ9nmsL5DFvD2Uug CRC: 196030570 -->Obligatoire<!-- END:impactOfNotHaving,-Of1SdnAQ9nmsL5DFvD2Uug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefOutline<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefOutline,-Of1SdnAQ9nmsL5DFvD2Uug CRC: 4112116110 -->Visible par tous, il est mis à jour régulièrement. Il est présenté à la revue de planification du sprint et, une fois
+accepté, la partie contenant les exigences allouées au sprint courant est gelée.<!-- END:briefOutline,-Of1SdnAQ9nmsL5DFvD2Uug -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-Of1SdnAQ9nmsL5DFvD2Uug CRC: 3624886494 --><ul>
+ <li>
+ Cartes (story cards)
+ </li>
+ <li>
+ Feuille d'un tableur
+ </li>
+ <li>
+ Outil IceScrum
+ </li>
+ <li>
+ Base de données
+ </li>
+</ul><!-- END:representationOptions,-Of1SdnAQ9nmsL5DFvD2Uug -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_Backlog_Item.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_Backlog_Item.html
new file mode 100644
index 0000000..977354b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_Backlog_Item.html
@@ -0,0 +1,89 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\workproducts\Product Backlog Item.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Product Backlog Item.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_-D85cIGIEduKE9hnyImx1Q CRC: 436919639 -->Elément de backlog de produit<!-- END:presentationName,_-D85cIGIEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_-D85cIGIEduKE9hnyImx1Q CRC: 2737221503 -->Chose à faire qui apporte de la valeur. Appelé PBI (Product Backlog Item)<!-- END:briefDescription,_-D85cIGIEduKE9hnyImx1Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KC1R73i9f6P7ZT4pgBOLzA CRC: 386624364 -->C'est une exigence fonctionnelle ou non fonctionnelle (technique), une demande d'évolution, un bug ou tout autre
+chose dont la réalisation apporte de la valeur au <a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+Produit</a>.
+<p>
+ Il possède des attributs qui sont généralement :
+</p>
+<ul>
+ <li>
+ une estimation de sa valeur qui est le plus souvent montrée de façon relative aux autres éléments par la notion de
+ priorité,
+ </li>
+ <li>
+ une estimation de son coût de développement,
+ </li>
+ <li>
+ éventuellement le thème (domaine fonctionnel) dont il fait partie,
+ </li>
+ <li>
+ éventuellement son type (défini en fonction du projet, par exemple histoire d'utilisateur, bug, exigence non
+ fonctionnelle),
+ </li>
+</ul>
+<p>
+ Si on utilise la technique des histoires d'utilisateur (user stories) et le développement dirigé par les tests (TDD),
+ on associe les critères servant aux tests d'acceptation de cet élément.
+</p>
+<p>
+ La vie d'un PBI passe par les états suivants :
+</p>
+<ul class="noindent">
+ <li>
+ créé
+ </li>
+ <li>
+ estimé
+ </li>
+ <li>
+ planifié (associé à un sprint futur
+ </li>
+ <li>
+ associé au sprint courant (on le réalise)
+ </li>
+ <li>
+ réalisé
+ </li>
+ <li style="list-style: none">
+ <br />
+ </li>
+</ul><!-- END:mainDescription,-KC1R73i9f6P7ZT4pgBOLzA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-KC1R73i9f6P7ZT4pgBOLzA CRC: 4066930091 -->Le principe de Scrum est de finir complètement un PBI dans un sprint.<!-- END:keyConsiderations,-KC1R73i9f6P7ZT4pgBOLzA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-KC1R73i9f6P7ZT4pgBOLzA CRC: 3975210310 -->Sert à la gestion de projet : il sera placé dans un sprint<!-- END:purpose,-KC1R73i9f6P7ZT4pgBOLzA -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_increment.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_increment.html
new file mode 100644
index 0000000..1706e6a
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Product_increment.html
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\workproducts\Product increment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Product increment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_tCmYEP-xEdqLnajTSLeAsA CRC: 2138190734 -->Incrément de produit<!-- END:presentationName,_tCmYEP-xEdqLnajTSLeAsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_tCmYEP-xEdqLnajTSLeAsA CRC: 2461235673 -->Le produit partiel obtenu à la fin de chaque sprint.<!-- END:briefDescription,_tCmYEP-xEdqLnajTSLeAsA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-6aCUL_kawJFNBtfH_sRXkw CRC: 2108154798 --><p>
+ Le résultat principal d'un sprint est le produit partiel qui réalise, en plus de ce qui existait au début du
+ sprint, les exigences supplémentaires réalisées pendant ce sprint.
+</p>
+<p>
+ On peut trouver 3 utilisations -après la démonstration lors de la revue de sprintes- du produit partiel obtenu en
+ fin d'itération :
+</p>
+<ul>
+ <li>
+ il n'est pas utilisé en dehors de l'équipe. Il a été produit pour chercher à minimiser les risques liés à la
+ technologie et à la capacité de l'équipe à intégrer pour produire un <q>build</q>. Cela arrive surtout au début
+ d'un nouveau produit.
+ </li>
+ <li>
+ il est utilisé par des clients privilégiés, en plus du directeur produit. Cela leur donne la possibilité de jouer
+ avec, ce qui permet de réduire les risques portant sur l'IHM liées à la facilité d'utilisation des fonctionnalités.
+ Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
+ </li>
+ <li>
+ il est mis en production ou en exploitation et utilisé par ses utilisateurs finals. C'est évidemment ce qu'il faut
+ viser puisque chaque nouvelle version apporte de la valeur. Autant l'apporter le plus tôt possible, dès qu'elle est
+ disponible. Mais ce n'est généralement pas possible de mettre en production à la fin de chaque sprint : trop de
+ temps serait pris pour passer les tests de recette sur tout le système, déployer sur l'environnement de production,
+ écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs... C'est pourquoi ce travail
+ particulier nécessite souvent une activité de préparation à la mise en production. Mais si on réussit à limiter le
+ temps pour faire tout ça, on peut alors mettre en production plus souvent qu'à la fin des releases.
+ </li>
+</ul>
+<br /><!-- END:mainDescription,-6aCUL_kawJFNBtfH_sRXkw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-6aCUL_kawJFNBtfH_sRXkw CRC: 360590533 --><p>
+ Le produit évolue pendant toute sa vie jusqu'à son retrait.
+</p><!-- END:keyConsiderations,-6aCUL_kawJFNBtfH_sRXkw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefOutline<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefOutline,-6aCUL_kawJFNBtfH_sRXkw CRC: 2728733924 -->Le produit partiel peut être déployé dans l'environnement de production ou simplement mis à disposition des
+utilisateurs.<!-- END:briefOutline,-6aCUL_kawJFNBtfH_sRXkw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Sprint_Backlog_Item.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Sprint_Backlog_Item.html
new file mode 100644
index 0000000..155860d
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Sprint_Backlog_Item.html
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\workproducts\Sprint Backlog Item.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Sprint Backlog Item.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_9C78MIHnEdu3SZQ-Dp1OAA CRC: 1789130518 -->Elément de Backlog de Sprint<!-- END:presentationName,_9C78MIHnEdu3SZQ-Dp1OAA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_9C78MIHnEdu3SZQ-Dp1OAA CRC: 3864528759 -->C'est une tâche, un travail élémentaire à réaliser pendant le sprint.<!-- END:briefDescription,_9C78MIHnEdu3SZQ-Dp1OAA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-6UJtuFO3WFBFpJOFeV1QMQ CRC: 763814899 --><p>
+ Chaque tâche possède les attributs suivants :
+</p>
+<ul>
+ <li>
+ l'estimation du temps à passer pour finir la tâche. Les efforts sont estimés, par l’équipe, en heures sur une
+ échelle qui varie habituellement de 1à 16 heures. Les tâches plus grandes devraient être décomposées. L’estimation
+ du reste à faire est réactualisée tous les jours.
+ </li>
+ <li>
+ l'<a class="elementLink" href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a> à l'origine de cette tâche
+ </li>
+ <li>
+ la personne qui prend en compte cette tâche<br />
+ </li>
+</ul><!-- END:mainDescription,-6UJtuFO3WFBFpJOFeV1QMQ -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Sprint_backlog.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Sprint_backlog.html
new file mode 100644
index 0000000..c5531a8
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducts/Sprint_backlog.html
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\workproducts\Sprint backlog.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Sprint backlog.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_Dzw70PpZEdqsc-f87sBK8A CRC: 3420918181 -->Backlog du sprint<!-- END:presentationName,_Dzw70PpZEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_Dzw70PpZEdqsc-f87sBK8A CRC: 2629907100 -->Liste des choses à faire du point de vue de l'équipe de développement.<!-- END:briefDescription,_Dzw70PpZEdqsc-f87sBK8A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-8V2DOvzUhvtqwWvTOHMB5g CRC: 473767903 --><p>
+ Il contient la liste des tâches que l’équipe s’engage à faire afin de compléter les éléments de backlog de produit
+ sélectionnés pour ce sprint.<br />
+ L’équipe peut modifier une tâche, la supprimer ou en ajouter de nouvelles : il est courant que des tâches apparaissent
+ lors du sprint.
+</p><!-- END:mainDescription,-8V2DOvzUhvtqwWvTOHMB5g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-8V2DOvzUhvtqwWvTOHMB5g CRC: 629447067 -->Il décrit l'ensemble des tâches d'un sprint, avec les ressources qui y sont affectées et le travail qui reste à
+faire. C'est un plan qui porte sur des tâches détaillées, il est dit à "mailles fines".<!-- END:purpose,-8V2DOvzUhvtqwWvTOHMB5g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: impactOfNotHaving<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:impactOfNotHaving,-8V2DOvzUhvtqwWvTOHMB5g CRC: 196030570 -->Obligatoire<!-- END:impactOfNotHaving,-8V2DOvzUhvtqwWvTOHMB5g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefOutline<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefOutline,-8V2DOvzUhvtqwWvTOHMB5g CRC: 3415867599 --><p>
+ C'est un outil de communication essentiel qui aide à gérer le sprint. Il doit être facilement mis à jour et rester
+ visible à toute l'équipe.
+</p><!-- END:briefOutline,-8V2DOvzUhvtqwWvTOHMB5g -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducttypes/Backlogs.html b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducttypes/Backlogs.html
new file mode 100644
index 0000000..65c39f2
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/Scrum/workproducttypes/Backlogs.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\Scrum\workproducttypes\Backlogs.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Backlogs.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_d-yk8ABREdu3o4yroaI-tA CRC: 2450685760 -->Backlogs<!-- END:presentationName,_d-yk8ABREdu3o4yroaI-tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_d-yk8ABREdu3o4yroaI-tA CRC: 2638812005 -->Scrum utilise un nombre très restreint de produits de travail, essentiellement 2 listes appelées backlogs.<!-- END:briefDescription,_d-yk8ABREdu3o4yroaI-tA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-eSc2tcV1h17HBw_s8ROEVw CRC: 1977088049 --><p>
+ Les backlogs de Produit et de Sprint sont des éléments de gestion majeurs dans l'utilisation de Scrum.
+</p>
+<p>
+ A partir des backlogs, on produit des rapports comme le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a> ou le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>
+</p><!-- END:mainDescription,-eSc2tcV1h17HBw_s8ROEVw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-eSc2tcV1h17HBw_s8ROEVw CRC: 4160101100 -->Un backlog est une liste d'items. Le terme n'est pas traduit en français car il est couramment utilisé dans la communauté
+des développeurs.<!-- END:keyConsiderations,-eSc2tcV1h17HBw_s8ROEVw -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/exported_HTML/configurations/Scrum.html b/Scrum/Scrum_baseline_FR/exported_HTML/configurations/Scrum.html
new file mode 100644
index 0000000..57c028c
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/exported_HTML/configurations/Scrum.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\configurations\Scrum.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: Scrum.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_IqDLgP_OEdqtbrr0B1TG-A CRC: 2788963971 -->Scrum<!-- END:name,_IqDLgP_OEdqtbrr0B1TG-A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,_IqDLgP_OEdqtbrr0B1TG-A CRC: 2170056724 -->Le processus Scrum<!-- END:briefDescription,_IqDLgP_OEdqtbrr0B1TG-A -->
+</body>
+</html>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/about.html b/Scrum/Scrum_baseline_FR/library/Scrum/about.html
new file mode 100644
index 0000000..6040025
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/about.html
@@ -0,0 +1,9 @@
+
+<span style="font-weight: bold; font-family: Arial Narrow;">Claude Aubry</span><br/>
+<span style="font-weight: bold; color: rgb(255, 102, 0); font-family: Arial Narrow;">Consultant Méthodes Agiles</span><span style="font-family: Arial Narrow;">
+</span>
+<br/><small style="font-family: Arial Narrow;">
+<span style="color: rgb(102, 102, 102);">Mobile : 06 60 646 946</span>
+<br/>
+<a href="http://scrum.aubryconseil.com">Blog</a> -
+<a href="http://www.aubryconseil.com/">Web</a>
\ No newline at end of file
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/customcategories/Intro.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/customcategories/Intro.xmi
new file mode 100644
index 0000000..aa49ac4
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/customcategories/Intro.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-juIDa_fXi2K1BE5NTblPow" name="new_custom_category,_s8y1UABREdu3o4yroaI-tA" guid="-juIDa_fXi2K1BE5NTblPow" changeDate="2006-12-04T21:46:12.515+0100">
+ <mainDescription>Ce site décrit l'utilisation de Scrum</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/customcategories/Scrum Elements.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/customcategories/Scrum Elements.xmi
new file mode 100644
index 0000000..35e8dc5
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/customcategories/Scrum Elements.xmi
@@ -0,0 +1,2 @@
+<?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="-zS9h38tmK4L-U9kbgkpGKQ" name="Eléments de Scrum,_nF6fgALYEduFv7wnrO7SvQ" guid="-zS9h38tmK4L-U9kbgkpGKQ" changeDate="2006-07-16T15:44:25.338+0200"/>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/Scrum/content.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/Scrum/content.xmi
new file mode 100644
index 0000000..c97db24
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/Scrum/content.xmi
@@ -0,0 +1,83 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" epf:version="1.0.0">
+ <org.eclipse.epf.uma:DeliveryProcessDescription xmi:id="-16dzhVoCex78V2iCDZVx0w" name="Scrum,_9llsAQAvEdubGMceRDupFQ" guid="-16dzhVoCex78V2iCDZVx0w">
+ <mainDescription>La production d’une version du logiciel (<a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>) se fait en général en quelques mois. Les fonctionnalités demandées pour la
+release sont collectées dans le backlog de produit et classées par priorité. Le directeur de produit est responsable de
+l’insertion des changements dans ce backlog.&nbsp; <br />
+La release est produite par une série d’itérations de 2 à 4 semaines appelées des <a class="elementLink"
+href="./../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s. Le contenu d’un Sprint est défini par l’équipe avec le propriétaire de produit,
+en tenant compte des priorités et de la capacité de l’équipe. L’équipe définit les tâches nécessaires pour réaliser les
+fonctionnalités sélectionnées pour le Sprint.&nbsp; <br />
+Pendant un sprint, des points de contrôle sur l’avancement sont effectués lors des mêlées quotidiennes. Cela permet au
+ScrumMaster de déterminer l’avancement par rapport aux engagements du Sprint et de conseiller des ajustements pour assurer
+le succès du Sprint.&nbsp; <br />
+A la fin de chaque Sprint, l’équipe produit un <a class="elementLink"
+href="./../../Scrum/workproducts/Product increment,_tCmYEP-xEdqLnajTSLeAsA.html" guid="_tCmYEP-xEdqLnajTSLeAsA">Incrément
+de produit</a>&nbsp;potentiellement utilisable, dont l’évaluation permet d’ajuster le backlog pour le Sprint suivant.</mainDescription>
+ <keyConsiderations><p>
+ Scrum contribue à renforcer l’esprit d’équipe dans les projets,&nbsp; avec une collection de pratiques proches de
+ celles que l’on trouve dans des sports collectifs en particulier le rugby.
+</p>
+<br />
+<br /></keyConsiderations>
+ <purpose>.</purpose>
+ <howtoStaff>Une équipe Scrum est composée de 3 à 10 personnes.</howtoStaff>
+ <scope>Scrum ne décrit pas toutes les disciplines du développement de logiciel (analyse, conception, codage, test) et doit être
+considéré, plutôt qu’un processus complet, comme un pattern de processus qui est à utiliser pour la gestion de projet et la
+gestion des exigences. <br />
+Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement.</scope>
+ <estimatingTechnique><p>
+ Il est conseillé de pratiquer une estimation basée sur les points (story points), associés aux éléments du backlog.
+</p></estimatingTechnique>
+ </org.eclipse.epf.uma:DeliveryProcessDescription>
+ <org.eclipse.epf.uma:ActivityDescription xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" name="Phase de préparation,_37TdkAL_EduOAKqB9I73uw" guid="-WiMYK8iwLeOO-sSBRBjbNQ">
+ <mainDescription><p>
+ Scrum ne prend pas en compte tous les aspects de préparation d'un projet. Seules sont présentées les taches spécifiques
+ de Scrum plus une qui regroupe tous les travaux pouvant etre réalisés
+</p></mainDescription>
+ </org.eclipse.epf.uma:ActivityDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" name="Travaux quotidiens,_nXmKUANlEduYd-55D-Aiqg" guid="-EpBaHVCIYCqqGX_wv7dlYA">
+ <refinedDescription>Scrum ne propose rien pour la réalisation de ces tâches techniques de conception, codage et test mais se conjugue bien avec
+l’utilisation des techniques XP (binômage, développement dirigé par les tests…). <br />
+Les tâches ne sont pas assignées par le ScrumMaster mais choisies par les membres de l’équipe au fur et à mesure. <br />
+L’équipe met à jour, chaque fois que c’est nécessaire, l’estimation du reste à faire sur les tâches du <br />
+backlog du sprint.</refinedDescription>
+ </org.eclipse.epf.uma:DescriptorDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" name="Sprint de release,_zbM2QIGBEduKE9hnyImx1Q" guid="-EOwIzNPjfNIjzJ3TRAgeWQ">
+ <keyConsiderations>Essayer de ne pas modifier de code lors du dernier sprint, c'est trop tard et risqué.</keyConsiderations>
+ <usageGuidance>Il est optionnel. Cela dépend de la façon dont le produit est mis à disposition de ses utilisateurs finals. On en devrait
+dérouler ce sprint optionnel que des travaux qu'il est impossible de faire avant, dans les sprints "normaux".</usageGuidance>
+ <refinedDescription><p>
+ Les tâches effectuées pendant ce sprint dépendent fortement du type de déploiement du logiciel.
+</p>
+<p>
+ On peut y trouver des travaux portant sur :
+</p>
+<ul>
+ <li>
+ mise en production à chaud,
+ </li>
+ <li>
+ packaging du produit,
+ </li>
+ <li>
+ mise à disposition par téléchargement en ligne,
+ </li>
+ <li>
+ documentation technique,
+ </li>
+ <li>
+ formation des utilisateurs,
+ </li>
+ <li>
+ marketing du produit.
+ </li>
+</ul></refinedDescription>
+ </org.eclipse.epf.uma:DescriptorDescription>
+ <org.eclipse.epf.uma:DescriptorDescription xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" name="Sprint backlog,_glbG2wMAEduOAKqB9I73uw" guid="-MupkaQeHNEmiF7Lnl3VirQ">
+ <usageGuidance>Un par sprint</usageGuidance>
+ </org.eclipse.epf.uma:DescriptorDescription>
+</xmi:XMI>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/Scrum/model.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/Scrum/model.xmi
new file mode 100644
index 0000000..eafcf7c
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/Scrum/model.xmi
@@ -0,0 +1,982 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_9m1CIAAvEdubGMceRDupFQ" guid="_9m1CIAAvEdubGMceRDupFQ">
+ <resourceDescriptors xmi:id="_9m1CIQAvEdubGMceRDupFQ" id="-16dzhVoCex78V2iCDZVx0w" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_-d2LQQMEEduOAKqB9I73uw" id="-WiMYK8iwLeOO-sSBRBjbNQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_8N5DwANlEduYd-55D-Aiqg" id="-EpBaHVCIYCqqGX_wv7dlYA" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_iCOP4IGPEduKE9hnyImx1Q" id="-EOwIzNPjfNIjzJ3TRAgeWQ" uri="content.xmi"/>
+ <resourceDescriptors xmi:id="_tObbkLPBEduk5O8SjA21Fg" id="-MupkaQeHNEmiF7Lnl3VirQ" uri="content.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:ProcessComponent xmi:id="_9llsAAAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAAAvEdubGMceRDupFQ">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_37NW8AL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37NW8AL_EduOAKqB9I73uw">
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_37TdkAL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37TdkAL_EduOAKqB9I73uw" briefDescription="Cette phase initiale permet de préparer tout ce qui est nécessaire avant de commencer la série des sprints" presentationName="Phase de préparation" isOptional="true" superActivities="_9llsAQAvEdubGMceRDupFQ" breakdownElements="_zYT-EQMAEduOAKqB9I73uw _zYaEsAMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw _zYaEswMAEduOAKqB9I73uw _zYaEtAMAEduOAKqB9I73uw _7FGsMANkEduYd-55D-Aiqg _7FGsMQNkEduYd-55D-Aiqg _O6XmcANlEduYd-55D-Aiqg">
+ <presentation xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-WiMYK8iwLeOO-sSBRBjbNQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zYT-EQMAEduOAKqB9I73uw" name="Plan release" guid="_zYT-EQMAEduOAKqB9I73uw" presentationName="Planifier la release" superActivities="_37TdkAL_EduOAKqB9I73uw" linkToPredecessor="_2vOSsAMEEduOAKqB9I73uw _MEJPgAPOEdubhrgDuRb4fA _MEPWIAPOEdubhrgDuRb4fA" additionallyPerformedBy="_zYaEswMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw" mandatoryInput="_zYaEtAMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ho-aIP_BEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_8qN08APJEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_BuXEQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_EaLKQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_HDZ2UAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_I71XkAPKEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsAMAEduOAKqB9I73uw" name="Product Owner" guid="_zYaEsAMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_37TdkAL_EduOAKqB9I73uw" responsibleFor="_zYaEtAMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsgMAEduOAKqB9I73uw" name="Team" guid="_zYaEsgMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEswMAEduOAKqB9I73uw" name="ScrumMaster" guid="_zYaEswMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_zYaEtAMAEduOAKqB9I73uw" name="Product Backlog" guid="_zYaEtAMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_2vOSsAMEEduOAKqB9I73uw" guid="_2vOSsAMEEduOAKqB9I73uw" linkType="finishToFinish"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_7FGsMANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_7FGsMANkEduYd-55D-Aiqg" presentationName="Produire le backlog de produit initial" superActivities="_37TdkAL_EduOAKqB9I73uw" additionallyPerformedBy="_7FGsMQNkEduYd-55D-Aiqg _zYaEsgMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_BGFMoANkEduYd-55D-Aiqg"/>
+ <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_pWL_gAPJEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_u0Z7sAPJEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_7FGsMQNkEduYd-55D-Aiqg" name="StakeHolder" guid="_7FGsMQNkEduYd-55D-Aiqg" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_O6XmcANlEduYd-55D-Aiqg" name="Preparation work" guid="_O6XmcANlEduYd-55D-Aiqg" presentationName="Travaux de préparation" isPlanned="true" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw" performedPrimarilyBy="_zYaEsgMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEJPgAPOEdubhrgDuRb4fA" guid="_MEJPgAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_7FGsMANkEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEPWIAPOEdubhrgDuRb4fA" guid="_MEPWIAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_O6XmcANlEduYd-55D-Aiqg"/>
+ <diagrams xmi:id="_y9sh0AMEEduOAKqB9I73uw" guid="_y9sh0AMEEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yocAMEEduOAKqB9I73uw" guid="_y9yocAMEEduOAKqB9I73uw">
+ <position xmi:id="_y9yocQMEEduOAKqB9I73uw" x="84.0" y="34.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2vIMEQMEEduOAKqB9I73uw" guid="_2vIMEQMEEduOAKqB9I73uw" anchor="_2vIMEAMEEduOAKqB9I73uw _2vIMEgMEEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vOSsQMEEduOAKqB9I73uw" guid="_2vOSsQMEEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_2QAAEgMEEduOAKqB9I73uw" guid="_2QAAEgMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_2vIMEAMEEduOAKqB9I73uw" guid="_2vIMEAMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw">
+ <position xmi:id="_2vIMEwMEEduOAKqB9I73uw" x="155.0" y="50.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yocgMEEduOAKqB9I73uw" guid="_y9yocgMEEduOAKqB9I73uw"/>
+ <size xmi:id="_y9yocwMEEduOAKqB9I73uw" width="130.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yodAMEEduOAKqB9I73uw" guid="_y9yodAMEEduOAKqB9I73uw">
+ <position xmi:id="_y9yodQMEEduOAKqB9I73uw" x="158.0" y="214.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nqi5YYGGEduKE9hnyImx1Q" guid="_nqi5YYGGEduKE9hnyImx1Q" anchor="_nqi5YIGGEduKE9hnyImx1Q _nqi5YoGGEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_2vIMEgMEEduOAKqB9I73uw" guid="_2vIMEgMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_MEDI4gPOEdubhrgDuRb4fA" guid="_MEDI4gPOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_nqi5YIGGEduKE9hnyImx1Q" guid="_nqi5YIGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q">
+ <position xmi:id="_nqi5Y4GGEduKE9hnyImx1Q" x="171.0" y="228.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yodgMEEduOAKqB9I73uw" guid="_y9yodgMEEduOAKqB9I73uw" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_y9yodwMEEduOAKqB9I73uw" width="88.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_03XZMAMEEduOAKqB9I73uw" guid="_03XZMAMEEduOAKqB9I73uw">
+ <position xmi:id="_03XZMQMEEduOAKqB9I73uw" x="187.0" y="-6.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2QAAEQMEEduOAKqB9I73uw" guid="_2QAAEQMEEduOAKqB9I73uw" anchor="_2QAAEAMEEduOAKqB9I73uw _2QAAEgMEEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-h0qsQNkEduYd-55D-Aiqg" guid="_-h0qsQNkEduYd-55D-Aiqg" anchor="_-h0qsANkEduYd-55D-Aiqg _-h0qsgNkEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_2QAAEAMEEduOAKqB9I73uw" guid="_2QAAEAMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw">
+ <position xmi:id="_2QAAEwMEEduOAKqB9I73uw" x="58.0" y="51.0"/>
+ </anchorage>
+ <anchorage xmi:id="_-h0qsANkEduYd-55D-Aiqg" guid="_-h0qsANkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
+ <position xmi:id="_-h6xUANkEduYd-55D-Aiqg" x="62.0" y="51.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_03XZMgMEEduOAKqB9I73uw" guid="_03XZMgMEEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_03XZMwMEEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8cZ2UANkEduYd-55D-Aiqg" guid="_8cZ2UANkEduYd-55D-Aiqg">
+ <position xmi:id="_8cZ2UQNkEduYd-55D-Aiqg" x="14.0" y="94.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LDfDwQPOEdubhrgDuRb4fA" guid="_LDfDwQPOEdubhrgDuRb4fA" anchor="_LDfDwAPOEdubhrgDuRb4fA _LDfDwgPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_4JEBIgPNEdubhrgDuRb4fA" guid="_4JEBIgPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LDfDwAPOEdubhrgDuRb4fA" guid="_LDfDwAPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LDfDwwPOEdubhrgDuRb4fA" x="114.0" y="145.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8cZ2UgNkEduYd-55D-Aiqg" guid="_8cZ2UgNkEduYd-55D-Aiqg" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_8cZ2UwNkEduYd-55D-Aiqg" width="168.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_n_DhAANnEduYd-55D-Aiqg" guid="_n_DhAANnEduYd-55D-Aiqg">
+ <position xmi:id="_n_DhAQNnEduYd-55D-Aiqg" x="255.0" y="90.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LgIjgQPOEdubhrgDuRb4fA" guid="_LgIjgQPOEdubhrgDuRb4fA" anchor="_LgIjgAPOEdubhrgDuRb4fA _LgIjggPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_114dkgPNEdubhrgDuRb4fA" guid="_114dkgPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LgIjgAPOEdubhrgDuRb4fA" guid="_LgIjgAPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LgIjgwPOEdubhrgDuRb4fA" x="282.0" y="140.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_n_DhAgNnEduYd-55D-Aiqg" guid="_n_DhAgNnEduYd-55D-Aiqg" element="_O6XmcANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_n_DhAwNnEduYd-55D-Aiqg" width="113.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nITO0APNEdubhrgDuRb4fA" guid="_nITO0APNEdubhrgDuRb4fA">
+ <position xmi:id="_nITO0QPNEdubhrgDuRb4fA" x="162.0" y="55.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_114dkQPNEdubhrgDuRb4fA" guid="_114dkQPNEdubhrgDuRb4fA" anchor="_114dkAPNEdubhrgDuRb4fA _114dkgPNEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_4JEBIQPNEdubhrgDuRb4fA" guid="_4JEBIQPNEdubhrgDuRb4fA" anchor="_4JEBIAPNEdubhrgDuRb4fA _4JEBIgPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-h0qsgNkEduYd-55D-Aiqg" guid="_-h0qsgNkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
+ <position xmi:id="_Ip2OIFGGEduRlKB2-_Ejlg" x="36.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_114dkAPNEdubhrgDuRb4fA" guid="_114dkAPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA">
+ <position xmi:id="_114dkwPNEdubhrgDuRb4fA" x="67.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_4JEBIAPNEdubhrgDuRb4fA" guid="_4JEBIAPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA">
+ <position xmi:id="_HPd_kAPOEdubhrgDuRb4fA" x="17.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nITO0gPNEdubhrgDuRb4fA" guid="_nITO0gPNEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_nITO0wPNEdubhrgDuRb4fA" width="81.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_J5FtMAPOEdubhrgDuRb4fA" guid="_J5FtMAPOEdubhrgDuRb4fA">
+ <position xmi:id="_J5FtMQPOEdubhrgDuRb4fA" x="152.0" y="171.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MEDI4QPOEdubhrgDuRb4fA" guid="_MEDI4QPOEdubhrgDuRb4fA" anchor="_MEDI4APOEdubhrgDuRb4fA _MEDI4gPOEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_LDfDwgPOEdubhrgDuRb4fA" guid="_LDfDwgPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LDfDxAPOEdubhrgDuRb4fA" x="42.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_LgIjggPOEdubhrgDuRb4fA" guid="_LgIjggPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
+ <position xmi:id="_LgIjhAPOEdubhrgDuRb4fA" x="54.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_MEDI4APOEdubhrgDuRb4fA" guid="_MEDI4APOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA">
+ <position xmi:id="_MJgy8FGGEduRlKB2-_Ejlg" x="49.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_J5FtMgPOEdubhrgDuRb4fA" guid="_J5FtMgPOEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
+ <size xmi:id="_J5FtMwPOEdubhrgDuRb4fA" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mMXrMIGGEduKE9hnyImx1Q" guid="_mMXrMIGGEduKE9hnyImx1Q">
+ <position xmi:id="_mMXrMYGGEduKE9hnyImx1Q" x="190.0" y="282.0"/>
+ <anchorage xmi:id="_nqi5YoGGEduKE9hnyImx1Q" guid="_nqi5YoGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mMXrMoGGEduKE9hnyImx1Q" guid="_mMXrMoGGEduKE9hnyImx1Q" typeInfo="end node"/>
+ <size xmi:id="_mMXrM4GGEduKE9hnyImx1Q" width="24.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9sh0QMEEduOAKqB9I73uw" guid="_y9sh0QMEEduOAKqB9I73uw" presentation="Workflow" element="_37TdkAL_EduOAKqB9I73uw"/>
+ </diagrams>
+ <diagrams xmi:id="_jcymYAPNEdubhrgDuRb4fA" guid="_jcymYAPNEdubhrgDuRb4fA">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymYQPNEdubhrgDuRb4fA" guid="_jcymYQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymYgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznBIGMEduKE9hnyImx1Q" guid="_5oznBIGMEduKE9hnyImx1Q" anchor="_5oznA4GMEduKE9hnyImx1Q _5oznBYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeNIGMEduKE9hnyImx1Q" guid="_5uBeNIGMEduKE9hnyImx1Q" anchor="_5uBeM4GMEduKE9hnyImx1Q _5uBeNYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQxLKjEdudsfcMCYa15A" guid="_03qQxLKjEdudsfcMCYa15A" anchor="_03qQw7KjEdudsfcMCYa15A _03qQxbKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_5oznAoGMEduKE9hnyImx1Q" guid="_5oznAoGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5oznA4GMEduKE9hnyImx1Q" guid="_5oznA4GMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeMoGMEduKE9hnyImx1Q" guid="_5uBeMoGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeM4GMEduKE9hnyImx1Q" guid="_5uBeM4GMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQwrKjEdudsfcMCYa15A" guid="_03qQwrKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_03qQw7KjEdudsfcMCYa15A" guid="_03qQw7KjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymYwPNEdubhrgDuRb4fA" guid="_jcymYwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymZAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymZQPNEdubhrgDuRb4fA" guid="_jcymZQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymZgPNEdubhrgDuRb4fA" x="30.0" y="88.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymZwPNEdubhrgDuRb4fA" guid="_jcymZwPNEdubhrgDuRb4fA" element="_zYaEsAMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymaAPNEdubhrgDuRb4fA" width="316.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymaQPNEdubhrgDuRb4fA" guid="_jcymaQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymagPNEdubhrgDuRb4fA" x="30.0" y="283.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymawPNEdubhrgDuRb4fA" guid="_jcymawPNEdubhrgDuRb4fA" element="_zYaEsgMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymbAPNEdubhrgDuRb4fA" width="239.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymbQPNEdubhrgDuRb4fA" guid="_jcymbQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymbgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymbwPNEdubhrgDuRb4fA" guid="_jcymbwPNEdubhrgDuRb4fA" element="_zYaEswMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymcAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymcQPNEdubhrgDuRb4fA" guid="_jcymcQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymcgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymcwPNEdubhrgDuRb4fA" guid="_jcymcwPNEdubhrgDuRb4fA" element="_zYaEtAMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jcymdAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymdQPNEdubhrgDuRb4fA" guid="_jcymdQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymdgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznB4GMEduKE9hnyImx1Q" guid="_5oznB4GMEduKE9hnyImx1Q" anchor="_5oznBoGMEduKE9hnyImx1Q _5oznCIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeN4GMEduKE9hnyImx1Q" guid="_5uBeN4GMEduKE9hnyImx1Q" anchor="_5uBeNoGMEduKE9hnyImx1Q _5uBeOIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQx7KjEdudsfcMCYa15A" guid="_03qQx7KjEdudsfcMCYa15A" anchor="_03qQxrKjEdudsfcMCYa15A _03qQyLKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_5oznBoGMEduKE9hnyImx1Q" guid="_5oznBoGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeNoGMEduKE9hnyImx1Q" guid="_5uBeNoGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQxrKjEdudsfcMCYa15A" guid="_03qQxrKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymdwPNEdubhrgDuRb4fA" guid="_jcymdwPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymeAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymeQPNEdubhrgDuRb4fA" guid="_jcymeQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymegPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymewPNEdubhrgDuRb4fA" guid="_jcymewPNEdubhrgDuRb4fA" element="_7FGsMQNkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymfAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymfQPNEdubhrgDuRb4fA" guid="_jcymfQPNEdubhrgDuRb4fA">
+ <position xmi:id="_jcymfgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymfwPNEdubhrgDuRb4fA" guid="_jcymfwPNEdubhrgDuRb4fA" element="_O6XmcANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_jcymgAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6QAPNEdubhrgDuRb4fA" guid="_jdE6QAPNEdubhrgDuRb4fA">
+ <property xmi:id="_jdE6QQPNEdubhrgDuRb4fA" guid="_jdE6QQPNEdubhrgDuRb4fA" key="wpCompositeType" value="1"/>
+ <position xmi:id="_jdE6QgPNEdubhrgDuRb4fA" x="127.0" y="1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_jdRHgQPNEdubhrgDuRb4fA" guid="_jdRHgQPNEdubhrgDuRb4fA" anchor="_jdRHgAPNEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8P1cgRTUEduFIr9xNbwGyQ" guid="_8P1cgRTUEduFIr9xNbwGyQ" anchor="_8P1cgBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznAYGMEduKE9hnyImx1Q" guid="_5oznAYGMEduKE9hnyImx1Q" anchor="_5oznAIGMEduKE9hnyImx1Q _5oznAoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeMYGMEduKE9hnyImx1Q" guid="_5uBeMYGMEduKE9hnyImx1Q" anchor="_5uBeMIGMEduKE9hnyImx1Q _5uBeMoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQwbKjEdudsfcMCYa15A" guid="_03qQwbKjEdudsfcMCYa15A" anchor="_03qQwLKjEdudsfcMCYa15A _03qQwrKjEdudsfcMCYa15A"/>
+ <anchorage xmi:id="_jdRHgAPNEdubhrgDuRb4fA" guid="_jdRHgAPNEdubhrgDuRb4fA" graphEdge="_jdRHgQPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cgBTUEduFIr9xNbwGyQ" guid="_8P1cgBTUEduFIr9xNbwGyQ" graphEdge="_8P1cgRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznAIGMEduKE9hnyImx1Q" guid="_5oznAIGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeMIGMEduKE9hnyImx1Q" guid="_5uBeMIGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQwLKjEdudsfcMCYa15A" guid="_03qQwLKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6QwPNEdubhrgDuRb4fA" guid="_jdE6QwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jdE6RAPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6RQPNEdubhrgDuRb4fA" guid="_jdE6RQPNEdubhrgDuRb4fA">
+ <property xmi:id="_jdE6RgPNEdubhrgDuRb4fA" guid="_jdE6RgPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
+ <position xmi:id="_jdE6RwPNEdubhrgDuRb4fA" x="127.0" y="175.0"/>
+ <anchorage xmi:id="_jdRHggPNEdubhrgDuRb4fA" guid="_jdRHggPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cghTUEduFIr9xNbwGyQ" guid="_8P1cghTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznBYGMEduKE9hnyImx1Q" guid="_5oznBYGMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeNYGMEduKE9hnyImx1Q" guid="_5uBeNYGMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQxbKjEdudsfcMCYa15A" guid="_03qQxbKjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6SAPNEdubhrgDuRb4fA" guid="_jdE6SAPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_jdE6SQPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdLA4APNEdubhrgDuRb4fA" guid="_jdLA4APNEdubhrgDuRb4fA">
+ <property xmi:id="_jdLA4QPNEdubhrgDuRb4fA" guid="_jdLA4QPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
+ <position xmi:id="_jdLA4gPNEdubhrgDuRb4fA" x="220.0" y="175.0"/>
+ <anchorage xmi:id="_jdRHgwPNEdubhrgDuRb4fA" guid="_jdRHgwPNEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8P1cgxTUEduFIr9xNbwGyQ" guid="_8P1cgxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5oznCIGMEduKE9hnyImx1Q" guid="_5oznCIGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5uBeOIGMEduKE9hnyImx1Q" guid="_5uBeOIGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_03qQyLKjEdudsfcMCYa15A" guid="_03qQyLKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdLA4wPNEdubhrgDuRb4fA" guid="_jdLA4wPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
+ <size xmi:id="_jdLA5APNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymgQPNEdubhrgDuRb4fA" guid="_jcymgQPNEdubhrgDuRb4fA" presentation="Activity Detail" element="_37TdkAL_EduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_NSW6sAMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sAMAEduOAKqB9I73uw">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_SoXWEAMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEAMAEduOAKqB9I73uw">
+ <processElements xsi:type="org.eclipse.epf.uma:Iteration" xmi:id="_SoXWEQMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEQMAEduOAKqB9I73uw" briefDescription="Déroulement d'un sprint (itération)" presentationName="Sprint" isPlanned="false" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" breakdownElements="_glbG0AMAEduOAKqB9I73uw _glbG0QMAEduOAKqB9I73uw _glbG0wMAEduOAKqB9I73uw _glbG1AMAEduOAKqB9I73uw _glbG1QMAEduOAKqB9I73uw _glbG1gMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw _glbG2wMAEduOAKqB9I73uw _glbG3AMAEduOAKqB9I73uw _glbG3QMAEduOAKqB9I73uw _nXmKUANlEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0AMAEduOAKqB9I73uw" name="Manage problems" guid="_glbG0AMAEduOAKqB9I73uw" presentationName="Gérer les problèmes" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" optionalInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Xpd5gP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_LCxqQAB6EduSVaTQTBfIHA"/>
+ <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_PIKyUAB6EduSVaTQTBfIHA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0QMAEduOAKqB9I73uw" name="Update product backlog" guid="_glbG0QMAEduOAKqB9I73uw" presentationName="Mettre à jour le backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" additionallyPerformedBy="_glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2AMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_STkWYP_BEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_c3HaQAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_fkXDoAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_k-kCgAPKEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0wMAEduOAKqB9I73uw" name="Plan sprint" guid="_glbG0wMAEduOAKqB9I73uw" presentationName="Planifier le sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_4LOggPpaEdqsc-f87sBK8A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_TJNsUP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_p4C0sP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_worbAP--Edqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_xvy5UAPKEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_DxNQUAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_Iq14wAPLEdubhrgDuRb4fA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1AMAEduOAKqB9I73uw" name="Retrospective" guid="_glbG1AMAEduOAKqB9I73uw" presentationName="Rétrospective" superActivities="_SoXWEQMAEduOAKqB9I73uw" linkToPredecessor="_O0710AMCEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_J_sRIP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_lwzeABGPEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_noL2YBGPEduHloEV5-Zv-w"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1QMAEduOAKqB9I73uw" name="Review sprint" guid="_glbG1QMAEduOAKqB9I73uw" presentationName="Faire la revue du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" isEventDriven="true" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" mandatoryInput="_glbG3QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_MRrRYPpbEdqsc-f87sBK8A"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_XL6VgAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_ZgJB8APLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_cBouUAPLEdubhrgDuRb4fA"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_hrswoHoYEduJVrY6eKG_mw"/>
+ <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_d776UHoYEduJVrY6eKG_mw"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1gMAEduOAKqB9I73uw" name="Scrum daily meeting" guid="_glbG1gMAEduOAKqB9I73uw" presentationName="Mêlée quotidienne" superActivities="_SoXWEQMAEduOAKqB9I73uw" isRepeatable="true" isEventDriven="true" linkToPredecessor="_34UPdAzNEduDObTFE5q79g _34UPdQzNEduDObTFE5q79g _34UPdgzNEduDObTFE5q79g" additionallyPerformedBy="_glbG2gMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
+ <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_d09LYP_AEdqtbrr0B1TG-A"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_oUrlcBGOEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_r0KkEBGOEduHloEV5-Zv-w"/>
+ <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_vZkkgBGOEduHloEV5-Zv-w"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG1wMAEduOAKqB9I73uw" name="ScrumMaster" guid="_glbG1wMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG2wMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2AMAEduOAKqB9I73uw" name="Product Owner" guid="_glbG2AMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG3AMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2QMAEduOAKqB9I73uw" name="StakeHolder" guid="_glbG2QMAEduOAKqB9I73uw" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2gMAEduOAKqB9I73uw" name="Team" guid="_glbG2gMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG2wMAEduOAKqB9I73uw" name="Sprint backlog" guid="_glbG2wMAEduOAKqB9I73uw" presentationName="Backlog du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <presentation xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-MupkaQeHNEmiF7Lnl3VirQ"/>
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Dzw70PpZEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3AMAEduOAKqB9I73uw" name="Product Backlog" guid="_glbG3AMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" activityEntryState="courant" activityExitState="mis à jour">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3QMAEduOAKqB9I73uw" name="Product" guid="_glbG3QMAEduOAKqB9I73uw" presentationName="Incrément de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_O0710AMCEduOAKqB9I73uw" guid="_O0710AMCEduOAKqB9I73uw" linkType="finishToFinish" pred="_glbG1QMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_nXmKUANlEduYd-55D-Aiqg" name="Daily work" guid="_nXmKUANlEduYd-55D-Aiqg" briefDescription="L'équipe réalise les taches du backlog pour arriver au but du sprint" presentationName="Travaux quotidiens" isPlanned="true" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG3QMAEduOAKqB9I73uw">
+ <presentation xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" href="uma://-16dzhVoCex78V2iCDZVx0w#-EpBaHVCIYCqqGX_wv7dlYA"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdAzNEduDObTFE5q79g" guid="_34UPdAzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0QMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdQzNEduDObTFE5q79g" guid="_34UPdQzNEduDObTFE5q79g" linkType="finishToFinish" pred="_nXmKUANlEduYd-55D-Aiqg"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdgzNEduDObTFE5q79g" guid="_34UPdgzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0AMAEduOAKqB9I73uw"/>
+ <diagrams xmi:id="_2vZZMAMBEduOAKqB9I73uw" guid="_2vZZMAMBEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vZZMQMBEduOAKqB9I73uw" guid="_2vZZMQMBEduOAKqB9I73uw">
+ <position xmi:id="_2vZZMgMBEduOAKqB9I73uw" x="199.0" y="174.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LnUDQQMCEduOAKqB9I73uw" guid="_LnUDQQMCEduOAKqB9I73uw" anchor="_LnUDQAMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_LSlwcgMCEduOAKqB9I73uw" guid="_LSlwcgMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_LnUDQAMCEduOAKqB9I73uw" guid="_LnUDQAMCEduOAKqB9I73uw" graphEdge="_LnUDQQMCEduOAKqB9I73uw">
+ <position xmi:id="_LnUDQwMCEduOAKqB9I73uw" x="316.0" y="187.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZMwMBEduOAKqB9I73uw" guid="_2vZZMwMBEduOAKqB9I73uw"/>
+ <size xmi:id="_2vZZNAMBEduOAKqB9I73uw" width="143.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff0AMBEduOAKqB9I73uw" guid="_2vff0AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff0QMBEduOAKqB9I73uw" x="322.0" y="134.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_swPHwQzNEduDObTFE5q79g" guid="_swPHwQzNEduDObTFE5q79g" anchor="_swPHwAzNEduDObTFE5q79g _swPHwgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_L-ChMgMCEduOAKqB9I73uw" guid="_L-ChMgMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_swPHwAzNEduDObTFE5q79g" guid="_swPHwAzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
+ <position xmi:id="_swPHwwzNEduDObTFE5q79g" x="394.0" y="241.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff0gMBEduOAKqB9I73uw" guid="_2vff0gMBEduOAKqB9I73uw" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff0wMBEduOAKqB9I73uw" width="98.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff1AMBEduOAKqB9I73uw" guid="_2vff1AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff1QMBEduOAKqB9I73uw" x="19.0" y="127.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_r27hMQzNEduDObTFE5q79g" guid="_r27hMQzNEduDObTFE5q79g" anchor="_r27hMAzNEduDObTFE5q79g _r27hMgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_KNcGQgMCEduOAKqB9I73uw" guid="_KNcGQgMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_r27hMAzNEduDObTFE5q79g" guid="_r27hMAzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
+ <position xmi:id="_r27hMwzNEduDObTFE5q79g" x="123.0" y="239.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff1gMBEduOAKqB9I73uw" guid="_2vff1gMBEduOAKqB9I73uw" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff1wMBEduOAKqB9I73uw" width="130.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff2AMBEduOAKqB9I73uw" guid="_2vff2AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff2QMBEduOAKqB9I73uw" x="76.0" y="269.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff2gMBEduOAKqB9I73uw" guid="_2vff2gMBEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff2wMBEduOAKqB9I73uw" width="88.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff3AMBEduOAKqB9I73uw" guid="_2vff3AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff3QMBEduOAKqB9I73uw" x="190.0" y="3.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-mYC4QzNEduDObTFE5q79g" guid="_-mYC4QzNEduDObTFE5q79g" anchor="_-mYC4AzNEduDObTFE5q79g _-mYC4gzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_I2DckgMCEduOAKqB9I73uw" guid="_I2DckgMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_-mYC4AzNEduDObTFE5q79g" guid="_-mYC4AzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
+ <position xmi:id="_-mYC4wzNEduDObTFE5q79g" x="264.0" y="88.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff3gMBEduOAKqB9I73uw" guid="_2vff3gMBEduOAKqB9I73uw" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff3wMBEduOAKqB9I73uw" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff4AMBEduOAKqB9I73uw" guid="_2vff4AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff4QMBEduOAKqB9I73uw" x="346.0" y="332.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_PENn8QMCEduOAKqB9I73uw" guid="_PENn8QMCEduOAKqB9I73uw" anchor="_PENn8AMCEduOAKqB9I73uw _PENn8gMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_O0vokgMCEduOAKqB9I73uw" guid="_O0vokgMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_PENn8AMCEduOAKqB9I73uw" guid="_PENn8AMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw">
+ <position xmi:id="_PENn8wMCEduOAKqB9I73uw" x="327.0" y="377.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff4gMBEduOAKqB9I73uw" guid="_2vff4gMBEduOAKqB9I73uw" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff4wMBEduOAKqB9I73uw" width="67.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff5AMBEduOAKqB9I73uw" guid="_2vff5AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff5QMBEduOAKqB9I73uw" x="175.0" y="332.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O0vokQMCEduOAKqB9I73uw" guid="_O0vokQMCEduOAKqB9I73uw" anchor="_O0vokAMCEduOAKqB9I73uw _O0vokgMCEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O0710QMCEduOAKqB9I73uw" guid="_O0710QMCEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_Ok5OsgMCEduOAKqB9I73uw" guid="_Ok5OsgMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_O0vokAMCEduOAKqB9I73uw" guid="_O0vokAMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw">
+ <position xmi:id="_O0vokwMCEduOAKqB9I73uw" x="324.0" y="328.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff5gMBEduOAKqB9I73uw" guid="_2vff5gMBEduOAKqB9I73uw" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff5wMBEduOAKqB9I73uw" width="111.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff6AMBEduOAKqB9I73uw" guid="_2vff6AMBEduOAKqB9I73uw">
+ <position xmi:id="_2vff6QMBEduOAKqB9I73uw" x="187.0" y="217.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_63CqYQzNEduDObTFE5q79g" guid="_63CqYQzNEduDObTFE5q79g" anchor="_63CqYAzNEduDObTFE5q79g _63CqYgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_34UPcgzNEduDObTFE5q79g" guid="_34UPcgzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_63CqYAzNEduDObTFE5q79g" guid="_63CqYAzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
+ <position xmi:id="_63CqYwzNEduDObTFE5q79g" x="268.0" y="326.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff6gMBEduOAKqB9I73uw" guid="_2vff6gMBEduOAKqB9I73uw" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_2vff6wMBEduOAKqB9I73uw" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DtnjIAMCEduOAKqB9I73uw" guid="_DtnjIAMCEduOAKqB9I73uw">
+ <position xmi:id="_DtnjIQMCEduOAKqB9I73uw" x="9.0" y="15.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_I2DckQMCEduOAKqB9I73uw" guid="_I2DckQMCEduOAKqB9I73uw" anchor="_I2DckAMCEduOAKqB9I73uw _I2DckgMCEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_I2DckAMCEduOAKqB9I73uw" guid="_I2DckAMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw">
+ <position xmi:id="_I2DckwMCEduOAKqB9I73uw" x="318.0" y="32.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DtnjIgMCEduOAKqB9I73uw" guid="_DtnjIgMCEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_DtnjIwMCEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_EQ85sAMCEduOAKqB9I73uw" guid="_EQ85sAMCEduOAKqB9I73uw">
+ <position xmi:id="_EQ85sQMCEduOAKqB9I73uw" x="531.0" y="342.0"/>
+ <anchorage xmi:id="_PENn8gMCEduOAKqB9I73uw" guid="_PENn8gMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_EQ85sgMCEduOAKqB9I73uw" guid="_EQ85sgMCEduOAKqB9I73uw" typeInfo="end node"/>
+ <size xmi:id="_EQ85swMCEduOAKqB9I73uw" width="24.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_FLsDoAMCEduOAKqB9I73uw" guid="_FLsDoAMCEduOAKqB9I73uw">
+ <position xmi:id="_FLsDoQMCEduOAKqB9I73uw" x="206.0" y="274.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ok5OsQMCEduOAKqB9I73uw" guid="_Ok5OsQMCEduOAKqB9I73uw" anchor="_Ok5OsAMCEduOAKqB9I73uw _Ok5OsgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ADBAAQzOEduDObTFE5q79g" guid="_ADBAAQzOEduDObTFE5q79g" anchor="_ADBAAAzOEduDObTFE5q79g _ADBAAgzOEduDObTFE5q79g">
+ <waypoints xmi:id="_0PYkcAzOEduDObTFE5q79g" x="491.0" y="285.0"/>
+ <waypoints xmi:id="_0PYkcQzOEduDObTFE5q79g" x="492.0" y="76.0"/>
+ </contained>
+ <anchorage xmi:id="_Ok5OsAMCEduOAKqB9I73uw" guid="_Ok5OsAMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw">
+ <position xmi:id="_cyxCoAMCEduOAKqB9I73uw" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_63CqYgzNEduDObTFE5q79g" guid="_63CqYgzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
+ <position xmi:id="_63CqZAzNEduDObTFE5q79g" x="23.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ADBAAAzOEduDObTFE5q79g" guid="_ADBAAAzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
+ <position xmi:id="_ADBAAwzOEduDObTFE5q79g" x="47.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_FLsDogMCEduOAKqB9I73uw" guid="_FLsDogMCEduOAKqB9I73uw" typeInfo="decision node"/>
+ <size xmi:id="_FLsDowMCEduOAKqB9I73uw" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HEmGAAMCEduOAKqB9I73uw" guid="_HEmGAAMCEduOAKqB9I73uw">
+ <position xmi:id="_HEmGAQMCEduOAKqB9I73uw" x="180.0" y="106.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KNcGQQMCEduOAKqB9I73uw" guid="_KNcGQQMCEduOAKqB9I73uw" anchor="_KNcGQAMCEduOAKqB9I73uw _KNcGQgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LSlwcQMCEduOAKqB9I73uw" guid="_LSlwcQMCEduOAKqB9I73uw" anchor="_LSlwcAMCEduOAKqB9I73uw _LSlwcgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_L-ChMQMCEduOAKqB9I73uw" guid="_L-ChMQMCEduOAKqB9I73uw" anchor="_L-ChMAMCEduOAKqB9I73uw _L-ChMgMCEduOAKqB9I73uw"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_haut0QNmEduYd-55D-Aiqg" guid="_haut0QNmEduYd-55D-Aiqg" anchor="_haut0ANmEduYd-55D-Aiqg _haut0gNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_KNcGQAMCEduOAKqB9I73uw" guid="_KNcGQAMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw">
+ <position xmi:id="_KNcGQwMCEduOAKqB9I73uw" x="47.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_LSlwcAMCEduOAKqB9I73uw" guid="_LSlwcAMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw">
+ <position xmi:id="_LSlwcwMCEduOAKqB9I73uw" x="49.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_L-ChMAMCEduOAKqB9I73uw" guid="_L-ChMAMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw">
+ <position xmi:id="_L-In0AMCEduOAKqB9I73uw" x="50.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="_haut0ANmEduYd-55D-Aiqg" guid="_haut0ANmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg">
+ <position xmi:id="_8NQZYIGPEduKE9hnyImx1Q" x="50.0" y="5.0"/>
+ </anchorage>
+ <anchorage xmi:id="__S4jkgzNEduDObTFE5q79g" guid="__S4jkgzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
+ <position xmi:id="__S4jlAzNEduDObTFE5q79g" x="46.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_HEmGAgMCEduOAKqB9I73uw" guid="_HEmGAgMCEduOAKqB9I73uw" typeInfo="synchnonization bar"/>
+ <size xmi:id="_HEmGAwMCEduOAKqB9I73uw" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_XP3cUANmEduYd-55D-Aiqg" guid="_XP3cUANmEduYd-55D-Aiqg">
+ <position xmi:id="_XP3cUQNmEduYd-55D-Aiqg" x="184.0" y="134.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_sOOm4QzNEduDObTFE5q79g" guid="_sOOm4QzNEduDObTFE5q79g" anchor="_sOOm4AzNEduDObTFE5q79g _sOOm4gzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_haut0gNmEduYd-55D-Aiqg" guid="_haut0gNmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_sOOm4AzNEduDObTFE5q79g" guid="_sOOm4AzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
+ <position xmi:id="_sOOm4wzNEduDObTFE5q79g" x="263.0" y="237.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_XP3cUgNmEduYd-55D-Aiqg" guid="_XP3cUgNmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_XP3cUwNmEduYd-55D-Aiqg" width="92.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4Fi44ANmEduYd-55D-Aiqg" name="Add Free Text" guid="_4Fi44ANmEduYd-55D-Aiqg">
+ <property xmi:id="_4Fi44QNmEduYd-55D-Aiqg" guid="_4Fi44QNmEduYd-55D-Aiqg" key="free text" value="date de fin de sprint atteinte"/>
+ <position xmi:id="_4Fi44gNmEduYd-55D-Aiqg" x="154.0" y="297.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_4Fi44wNmEduYd-55D-Aiqg" guid="_4Fi44wNmEduYd-55D-Aiqg" typeInfo="free text"/>
+ <size xmi:id="_4Fi45ANmEduYd-55D-Aiqg" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_S90SkAzNEduDObTFE5q79g" guid="_S90SkAzNEduDObTFE5q79g">
+ <position xmi:id="_S90SkQzNEduDObTFE5q79g" x="206.0" y="66.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__S4jkQzNEduDObTFE5q79g" guid="__S4jkQzNEduDObTFE5q79g" anchor="__S4jkAzNEduDObTFE5q79g __S4jkgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_-mYC4gzNEduDObTFE5q79g" guid="_-mYC4gzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
+ <position xmi:id="_-mYC5AzNEduDObTFE5q79g" x="23.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="__S4jkAzNEduDObTFE5q79g" guid="__S4jkAzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
+ <position xmi:id="__S4jkwzNEduDObTFE5q79g" x="23.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ADBAAgzOEduDObTFE5q79g" guid="_ADBAAgzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
+ <position xmi:id="_ADBABAzOEduDObTFE5q79g" x="47.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_S90SkgzNEduDObTFE5q79g" guid="_S90SkgzNEduDObTFE5q79g" typeInfo="decision node"/>
+ <size xmi:id="_S90SkwzNEduDObTFE5q79g" width="48.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_qmzWEAzNEduDObTFE5q79g" guid="_qmzWEAzNEduDObTFE5q79g">
+ <position xmi:id="_qmzWEQzNEduDObTFE5q79g" x="180.0" y="198.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_34UPcQzNEduDObTFE5q79g" guid="_34UPcQzNEduDObTFE5q79g" anchor="_34UPcAzNEduDObTFE5q79g _34UPcgzNEduDObTFE5q79g"/>
+ <anchorage xmi:id="_r27hMgzNEduDObTFE5q79g" guid="_r27hMgzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
+ <position xmi:id="_r27hNAzNEduDObTFE5q79g" x="38.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_sOOm4gzNEduDObTFE5q79g" guid="_sOOm4gzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
+ <position xmi:id="_8NQZYYGPEduKE9hnyImx1Q" x="50.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_swPHwgzNEduDObTFE5q79g" guid="_swPHwgzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
+ <position xmi:id="_swPHxAzNEduDObTFE5q79g" x="48.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_34UPcAzNEduDObTFE5q79g" guid="_34UPcAzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g">
+ <position xmi:id="_34UPcwzNEduDObTFE5q79g" x="44.0" y="0.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_qmzWEgzNEduDObTFE5q79g" guid="_qmzWEgzNEduDObTFE5q79g" typeInfo="synchnonization bar"/>
+ <size xmi:id="_qmzWEwzNEduDObTFE5q79g" width="100.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_f5j60AzOEduDObTFE5q79g" name="Add Free Text" guid="_f5j60AzOEduDObTFE5q79g">
+ <property xmi:id="_f5j60QzOEduDObTFE5q79g" guid="_f5j60QzOEduDObTFE5q79g" key="free text" value="encore des jours dans le sprint"/>
+ <position xmi:id="_f5j60gzOEduDObTFE5q79g" x="289.0" y="266.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_f5j60wzOEduDObTFE5q79g" guid="_f5j60wzOEduDObTFE5q79g" typeInfo="free text"/>
+ <size xmi:id="_f5j61AzOEduDObTFE5q79g" width="165.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZNQMBEduOAKqB9I73uw" guid="_2vZZNQMBEduOAKqB9I73uw" presentation="Workflow" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ <diagrams xmi:id="_O8kwcANmEduYd-55D-Aiqg" guid="_O8kwcANmEduYd-55D-Aiqg">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwcQNmEduYd-55D-Aiqg" guid="_O8kwcQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwcgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RsYGMEduKE9hnyImx1Q" guid="_5q5RsYGMEduKE9hnyImx1Q" anchor="_5q5RsIGMEduKE9hnyImx1Q _5q5RsoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeEYGMEduKE9hnyImx1Q" guid="_51BeEYGMEduKE9hnyImx1Q" anchor="_51BeEIGMEduKE9hnyImx1Q _51BeEoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RsIGMEduKE9hnyImx1Q" guid="_5q5RsIGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeEIGMEduKE9hnyImx1Q" guid="_51BeEIGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwcwNmEduYd-55D-Aiqg" guid="_O8kwcwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kwdANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwdQNmEduYd-55D-Aiqg" guid="_O8kwdQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwdgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rt4GMEduKE9hnyImx1Q" guid="_5q5Rt4GMEduKE9hnyImx1Q" anchor="_5q5RtoGMEduKE9hnyImx1Q _5q5RuIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeF4GMEduKE9hnyImx1Q" guid="_51BeF4GMEduKE9hnyImx1Q" anchor="_51BeFoGMEduKE9hnyImx1Q _51BeGIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RtYGMEduKE9hnyImx1Q" guid="_5q5RtYGMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RtoGMEduKE9hnyImx1Q" guid="_5q5RtoGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeFYGMEduKE9hnyImx1Q" guid="_51BeFYGMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeFoGMEduKE9hnyImx1Q" guid="_51BeFoGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwdwNmEduYd-55D-Aiqg" guid="_O8kwdwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kweANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kweQNmEduYd-55D-Aiqg" guid="_O8kweQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwegNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RvYGMEduKE9hnyImx1Q" guid="_5q5RvYGMEduKE9hnyImx1Q" anchor="_5q5RvIGMEduKE9hnyImx1Q _5q5RvoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeHYGMEduKE9hnyImx1Q" guid="_51BeHYGMEduKE9hnyImx1Q" anchor="_51BeHIGMEduKE9hnyImx1Q _51BeHoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Ru4GMEduKE9hnyImx1Q" guid="_5q5Ru4GMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RvIGMEduKE9hnyImx1Q" guid="_5q5RvIGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeG4GMEduKE9hnyImx1Q" guid="_51BeG4GMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeHIGMEduKE9hnyImx1Q" guid="_51BeHIGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwewNmEduYd-55D-Aiqg" guid="_O8kwewNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8kwfANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwfQNmEduYd-55D-Aiqg" guid="_O8kwfQNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8kwfgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RwIGMEduKE9hnyImx1Q" guid="_5q5RwIGMEduKE9hnyImx1Q" anchor="_5q5Rv4GMEduKE9hnyImx1Q _5q5RwYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeIIGMEduKE9hnyImx1Q" guid="_51BeIIGMEduKE9hnyImx1Q" anchor="_51BeH4GMEduKE9hnyImx1Q _51BeIYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Rv4GMEduKE9hnyImx1Q" guid="_5q5Rv4GMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeH4GMEduKE9hnyImx1Q" guid="_51BeH4GMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3EANmEduYd-55D-Aiqg" guid="_O8q3EANmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3EQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3EgNmEduYd-55D-Aiqg" guid="_O8q3EgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3EwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RxoGMEduKE9hnyImx1Q" guid="_5q5RxoGMEduKE9hnyImx1Q" anchor="_5q5RxYGMEduKE9hnyImx1Q _5q5Rx4GMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeJoGMEduKE9hnyImx1Q" guid="_51BeJoGMEduKE9hnyImx1Q" anchor="_51BeJYGMEduKE9hnyImx1Q _51BeJ4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RxIGMEduKE9hnyImx1Q" guid="_5q5RxIGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RxYGMEduKE9hnyImx1Q" guid="_5q5RxYGMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJIGMEduKE9hnyImx1Q" guid="_51BeJIGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJYGMEduKE9hnyImx1Q" guid="_51BeJYGMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3FANmEduYd-55D-Aiqg" guid="_O8q3FANmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3FQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3FgNmEduYd-55D-Aiqg" guid="_O8q3FgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3FwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RzIGMEduKE9hnyImx1Q" guid="_5q5RzIGMEduKE9hnyImx1Q" anchor="_5q5Ry4GMEduKE9hnyImx1Q _5q5RzYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeLIGMEduKE9hnyImx1Q" guid="_51BeLIGMEduKE9hnyImx1Q" anchor="_51BeK4GMEduKE9hnyImx1Q _51BeLYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5RyoGMEduKE9hnyImx1Q" guid="_5q5RyoGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_5q5Ry4GMEduKE9hnyImx1Q" guid="_5q5Ry4GMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeKoGMEduKE9hnyImx1Q" guid="_51BeKoGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeK4GMEduKE9hnyImx1Q" guid="_51BeK4GMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3GANmEduYd-55D-Aiqg" guid="_O8q3GANmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3GQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3GgNmEduYd-55D-Aiqg" guid="_O8q3GgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3GwNmEduYd-55D-Aiqg" x="30.0" y="88.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3HANmEduYd-55D-Aiqg" guid="_O8q3HANmEduYd-55D-Aiqg" element="_glbG1wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3HQNmEduYd-55D-Aiqg" width="338.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3HgNmEduYd-55D-Aiqg" guid="_O8q3HgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3HwNmEduYd-55D-Aiqg" x="30.0" y="356.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3IANmEduYd-55D-Aiqg" guid="_O8q3IANmEduYd-55D-Aiqg" element="_glbG2AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3IQNmEduYd-55D-Aiqg" width="222.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3IgNmEduYd-55D-Aiqg" guid="_O8q3IgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3IwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3JANmEduYd-55D-Aiqg" guid="_O8q3JANmEduYd-55D-Aiqg" element="_glbG2QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3JQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3JgNmEduYd-55D-Aiqg" guid="_O8q3JgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3JwNmEduYd-55D-Aiqg" x="30.0" y="638.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3KANmEduYd-55D-Aiqg" guid="_O8q3KANmEduYd-55D-Aiqg" element="_glbG2gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3KQNmEduYd-55D-Aiqg" width="374.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3KgNmEduYd-55D-Aiqg" guid="_O8q3KgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3KwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3LANmEduYd-55D-Aiqg" guid="_O8q3LANmEduYd-55D-Aiqg" element="_glbG2wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3LQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3LgNmEduYd-55D-Aiqg" guid="_O8q3LgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3LwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3MANmEduYd-55D-Aiqg" guid="_O8q3MANmEduYd-55D-Aiqg" element="_glbG3AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3MQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3MgNmEduYd-55D-Aiqg" guid="_O8q3MgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3MwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3NANmEduYd-55D-Aiqg" guid="_O8q3NANmEduYd-55D-Aiqg" element="_glbG3QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O8q3NQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3NgNmEduYd-55D-Aiqg" guid="_O8q3NgNmEduYd-55D-Aiqg">
+ <position xmi:id="_O8q3NwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OANmEduYd-55D-Aiqg" guid="_O8q3OANmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
+ <size xmi:id="_O8q3OQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9bsEANmEduYd-55D-Aiqg" guid="_O9bsEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O9bsEQNmEduYd-55D-Aiqg" guid="_O9bsEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O9bsEgNmEduYd-55D-Aiqg" x="137.0" y="161.0"/>
+ <anchorage xmi:id="_O-9WFQNmEduYd-55D-Aiqg" guid="_O-9WFQNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVsANnEduYd-55D-Aiqg" guid="_oHjVsANnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMAO8EdubhrgDuRb4fA" guid="_D6EPMAO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMAPMEdubhrgDuRb4fA" guid="_-EfTMAPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcBTUEduFIr9xNbwGyQ" guid="_8ZSTcBTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RsoGMEduKE9hnyImx1Q" guid="_5q5RsoGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeEoGMEduKE9hnyImx1Q" guid="_51BeEoGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9bsEwNmEduYd-55D-Aiqg" guid="_O9bsEwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O9bsFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9t_8ANmEduYd-55D-Aiqg" guid="_O9t_8ANmEduYd-55D-Aiqg">
+ <property xmi:id="_O9t_8QNmEduYd-55D-Aiqg" guid="_O9t_8QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O9t_8gNmEduYd-55D-Aiqg" x="142.0" y="269.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WFwNmEduYd-55D-Aiqg" guid="_O-9WFwNmEduYd-55D-Aiqg" anchor="_O-9WFgNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVsgNnEduYd-55D-Aiqg" guid="_oHjVsgNnEduYd-55D-Aiqg" anchor="_oHjVsQNnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPMgO8EdubhrgDuRb4fA" guid="_D6EPMgO8EdubhrgDuRb4fA" anchor="_D6EPMQO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTMgPMEdubhrgDuRb4fA" guid="_-EfTMgPMEdubhrgDuRb4fA" anchor="_-EfTMQPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTchTUEduFIr9xNbwGyQ" guid="_8ZSTchTUEduFIr9xNbwGyQ" anchor="_8ZSTcRTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RtIGMEduKE9hnyImx1Q" guid="_5q5RtIGMEduKE9hnyImx1Q" anchor="_5q5Rs4GMEduKE9hnyImx1Q _5q5RtYGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeFIGMEduKE9hnyImx1Q" guid="_51BeFIGMEduKE9hnyImx1Q" anchor="_51BeE4GMEduKE9hnyImx1Q _51BeFYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WFgNmEduYd-55D-Aiqg" guid="_O-9WFgNmEduYd-55D-Aiqg" graphEdge="_O-9WFwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVsQNnEduYd-55D-Aiqg" guid="_oHjVsQNnEduYd-55D-Aiqg" graphEdge="_oHjVsgNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMQO8EdubhrgDuRb4fA" guid="_D6EPMQO8EdubhrgDuRb4fA" graphEdge="_D6EPMgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMQPMEdubhrgDuRb4fA" guid="_-EfTMQPMEdubhrgDuRb4fA" graphEdge="_-EfTMgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcRTUEduFIr9xNbwGyQ" guid="_8ZSTcRTUEduFIr9xNbwGyQ" graphEdge="_8ZSTchTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5Rs4GMEduKE9hnyImx1Q" guid="_5q5Rs4GMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeE4GMEduKE9hnyImx1Q" guid="_51BeE4GMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9t_8wNmEduYd-55D-Aiqg" guid="_O9t_8wNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O9t_9ANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O96NMANmEduYd-55D-Aiqg" guid="_O96NMANmEduYd-55D-Aiqg">
+ <property xmi:id="_O96NMQNmEduYd-55D-Aiqg" guid="_O96NMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O96NMgNmEduYd-55D-Aiqg" x="142.0" y="443.0"/>
+ <anchorage xmi:id="_O-9WGANmEduYd-55D-Aiqg" guid="_O-9WGANmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVswNnEduYd-55D-Aiqg" guid="_oHjVswNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPMwO8EdubhrgDuRb4fA" guid="_D6EPMwO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTMwPMEdubhrgDuRb4fA" guid="_-EfTMwPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTcxTUEduFIr9xNbwGyQ" guid="_8ZSTcxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RuIGMEduKE9hnyImx1Q" guid="_5q5RuIGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeGIGMEduKE9hnyImx1Q" guid="_51BeGIGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O96NMwNmEduYd-55D-Aiqg" guid="_O96NMwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O96NNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-GacANmEduYd-55D-Aiqg" guid="_O-GacANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-GacQNmEduYd-55D-Aiqg" guid="_O-GacQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-GacgNmEduYd-55D-Aiqg" x="289.0" y="551.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WGgNmEduYd-55D-Aiqg" guid="_O-9WGgNmEduYd-55D-Aiqg" anchor="_O-9WGQNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVtQNnEduYd-55D-Aiqg" guid="_oHjVtQNnEduYd-55D-Aiqg" anchor="_oHjVtANnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPNQO8EdubhrgDuRb4fA" guid="_D6EPNQO8EdubhrgDuRb4fA" anchor="_D6EPNAO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTNQPMEdubhrgDuRb4fA" guid="_-EfTNQPMEdubhrgDuRb4fA" anchor="_-EfTNAPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTdRTUEduFIr9xNbwGyQ" guid="_8ZSTdRTUEduFIr9xNbwGyQ" anchor="_8ZSTdBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RuoGMEduKE9hnyImx1Q" guid="_5q5RuoGMEduKE9hnyImx1Q" anchor="_5q5RuYGMEduKE9hnyImx1Q _5q5Ru4GMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeGoGMEduKE9hnyImx1Q" guid="_51BeGoGMEduKE9hnyImx1Q" anchor="_51BeGYGMEduKE9hnyImx1Q _51BeG4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WGQNmEduYd-55D-Aiqg" guid="_O-9WGQNmEduYd-55D-Aiqg" graphEdge="_O-9WGgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtANnEduYd-55D-Aiqg" guid="_oHjVtANnEduYd-55D-Aiqg" graphEdge="_oHjVtQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNAO8EdubhrgDuRb4fA" guid="_D6EPNAO8EdubhrgDuRb4fA" graphEdge="_D6EPNQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNAPMEdubhrgDuRb4fA" guid="_-EfTNAPMEdubhrgDuRb4fA" graphEdge="_-EfTNQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdBTUEduFIr9xNbwGyQ" guid="_8ZSTdBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTdRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RuYGMEduKE9hnyImx1Q" guid="_5q5RuYGMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeGYGMEduKE9hnyImx1Q" guid="_51BeGYGMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-GacwNmEduYd-55D-Aiqg" guid="_O-GacwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-GadANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-MhEANmEduYd-55D-Aiqg" guid="_O-MhEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-MhEQNmEduYd-55D-Aiqg" guid="_O-MhEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-MhEgNmEduYd-55D-Aiqg" x="292.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WGwNmEduYd-55D-Aiqg" guid="_O-9WGwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtgNnEduYd-55D-Aiqg" guid="_oHjVtgNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNgO8EdubhrgDuRb4fA" guid="_D6EPNgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNgPMEdubhrgDuRb4fA" guid="_-EfTNgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdhTUEduFIr9xNbwGyQ" guid="_8ZSTdhTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RvoGMEduKE9hnyImx1Q" guid="_5q5RvoGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeHoGMEduKE9hnyImx1Q" guid="_51BeHoGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-MhEwNmEduYd-55D-Aiqg" guid="_O-MhEwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-MhFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-YuUANmEduYd-55D-Aiqg" guid="_O-YuUANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-YuUQNmEduYd-55D-Aiqg" guid="_O-YuUQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-YuUgNmEduYd-55D-Aiqg" x="121.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WHANmEduYd-55D-Aiqg" guid="_O-9WHANmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVtwNnEduYd-55D-Aiqg" guid="_oHjVtwNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPNwO8EdubhrgDuRb4fA" guid="_D6EPNwO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTNwPMEdubhrgDuRb4fA" guid="_-EfTNwPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTdxTUEduFIr9xNbwGyQ" guid="_8ZSTdxTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RwYGMEduKE9hnyImx1Q" guid="_5q5RwYGMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeIYGMEduKE9hnyImx1Q" guid="_51BeIYGMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-YuUwNmEduYd-55D-Aiqg" guid="_O-YuUwNmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-YuVANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-k7kANmEduYd-55D-Aiqg" guid="_O-k7kANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-k7kQNmEduYd-55D-Aiqg" guid="_O-k7kQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-k7kgNmEduYd-55D-Aiqg" x="216.0" y="565.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WHgNmEduYd-55D-Aiqg" guid="_O-9WHgNmEduYd-55D-Aiqg" anchor="_O-9WHQNmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVuQNnEduYd-55D-Aiqg" guid="_oHjVuQNnEduYd-55D-Aiqg" anchor="_oHjVuANnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPOQO8EdubhrgDuRb4fA" guid="_D6EPOQO8EdubhrgDuRb4fA" anchor="_D6EPOAO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTOQPMEdubhrgDuRb4fA" guid="_-EfTOQPMEdubhrgDuRb4fA" anchor="_-EfTOAPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTeRTUEduFIr9xNbwGyQ" guid="_8ZSTeRTUEduFIr9xNbwGyQ" anchor="_8ZSTeBTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rw4GMEduKE9hnyImx1Q" guid="_5q5Rw4GMEduKE9hnyImx1Q" anchor="_5q5RwoGMEduKE9hnyImx1Q _5q5RxIGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeI4GMEduKE9hnyImx1Q" guid="_51BeI4GMEduKE9hnyImx1Q" anchor="_51BeIoGMEduKE9hnyImx1Q _51BeJIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WHQNmEduYd-55D-Aiqg" guid="_O-9WHQNmEduYd-55D-Aiqg" graphEdge="_O-9WHgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVuANnEduYd-55D-Aiqg" guid="_oHjVuANnEduYd-55D-Aiqg" graphEdge="_oHjVuQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOAO8EdubhrgDuRb4fA" guid="_D6EPOAO8EdubhrgDuRb4fA" graphEdge="_D6EPOQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOAPMEdubhrgDuRb4fA" guid="_-EfTOAPMEdubhrgDuRb4fA" graphEdge="_-EfTOQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTeBTUEduFIr9xNbwGyQ" guid="_8ZSTeBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTeRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RwoGMEduKE9hnyImx1Q" guid="_5q5RwoGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeIoGMEduKE9hnyImx1Q" guid="_51BeIoGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-k7kwNmEduYd-55D-Aiqg" guid="_O-k7kwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-k7lANmEduYd-55D-Aiqg" width="63.0" height="53.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-rCMANmEduYd-55D-Aiqg" guid="_O-rCMANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-rCMQNmEduYd-55D-Aiqg" guid="_O-rCMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-rCMgNmEduYd-55D-Aiqg" x="209.0" y="725.0"/>
+ <anchorage xmi:id="_O-9WHwNmEduYd-55D-Aiqg" guid="_O-9WHwNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVugNnEduYd-55D-Aiqg" guid="_oHjVugNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOgO8EdubhrgDuRb4fA" guid="_D6EPOgO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOgPMEdubhrgDuRb4fA" guid="_-EfTOgPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTehTUEduFIr9xNbwGyQ" guid="_8ZSTehTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5Rx4GMEduKE9hnyImx1Q" guid="_5q5Rx4GMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeJ4GMEduKE9hnyImx1Q" guid="_51BeJ4GMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-rCMwNmEduYd-55D-Aiqg" guid="_O-rCMwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-rCNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-xI0ANmEduYd-55D-Aiqg" guid="_O-xI0ANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-xI0QNmEduYd-55D-Aiqg" guid="_O-xI0QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
+ <position xmi:id="_O-xI0gNmEduYd-55D-Aiqg" x="249.0" y="1.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WIQNmEduYd-55D-Aiqg" guid="_O-9WIQNmEduYd-55D-Aiqg" anchor="_O-9WIANmEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVvANnEduYd-55D-Aiqg" guid="_oHjVvANnEduYd-55D-Aiqg" anchor="_oHjVuwNnEduYd-55D-Aiqg"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPPAO8EdubhrgDuRb4fA" guid="_D6EPPAO8EdubhrgDuRb4fA" anchor="_D6EPOwO8EdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTPAPMEdubhrgDuRb4fA" guid="_-EfTPAPMEdubhrgDuRb4fA" anchor="_-EfTOwPMEdubhrgDuRb4fA"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTfBTUEduFIr9xNbwGyQ" guid="_8ZSTfBTUEduFIr9xNbwGyQ" anchor="_8ZSTexTUEduFIr9xNbwGyQ"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RyYGMEduKE9hnyImx1Q" guid="_5q5RyYGMEduKE9hnyImx1Q" anchor="_5q5RyIGMEduKE9hnyImx1Q _5q5RyoGMEduKE9hnyImx1Q"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeKYGMEduKE9hnyImx1Q" guid="_51BeKYGMEduKE9hnyImx1Q" anchor="_51BeKIGMEduKE9hnyImx1Q _51BeKoGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_O-9WIANmEduYd-55D-Aiqg" guid="_O-9WIANmEduYd-55D-Aiqg" graphEdge="_O-9WIQNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVuwNnEduYd-55D-Aiqg" guid="_oHjVuwNnEduYd-55D-Aiqg" graphEdge="_oHjVvANnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPOwO8EdubhrgDuRb4fA" guid="_D6EPOwO8EdubhrgDuRb4fA" graphEdge="_D6EPPAO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTOwPMEdubhrgDuRb4fA" guid="_-EfTOwPMEdubhrgDuRb4fA" graphEdge="_-EfTPAPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTexTUEduFIr9xNbwGyQ" guid="_8ZSTexTUEduFIr9xNbwGyQ" graphEdge="_8ZSTfBTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RyIGMEduKE9hnyImx1Q" guid="_5q5RyIGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeKIGMEduKE9hnyImx1Q" guid="_51BeKIGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-xI0wNmEduYd-55D-Aiqg" guid="_O-xI0wNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-xI1ANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-9WEANmEduYd-55D-Aiqg" guid="_O-9WEANmEduYd-55D-Aiqg">
+ <property xmi:id="_O-9WEQNmEduYd-55D-Aiqg" guid="_O-9WEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
+ <position xmi:id="_O-9WEgNmEduYd-55D-Aiqg" x="249.0" y="161.0"/>
+ <anchorage xmi:id="_O-9WIgNmEduYd-55D-Aiqg" guid="_O-9WIgNmEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_oHjVvQNnEduYd-55D-Aiqg" guid="_oHjVvQNnEduYd-55D-Aiqg"/>
+ <anchorage xmi:id="_D6EPPQO8EdubhrgDuRb4fA" guid="_D6EPPQO8EdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_-EfTPQPMEdubhrgDuRb4fA" guid="_-EfTPQPMEdubhrgDuRb4fA"/>
+ <anchorage xmi:id="_8ZSTfRTUEduFIr9xNbwGyQ" guid="_8ZSTfRTUEduFIr9xNbwGyQ"/>
+ <anchorage xmi:id="_5q5RzYGMEduKE9hnyImx1Q" guid="_5q5RzYGMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_51BeLYGMEduKE9hnyImx1Q" guid="_51BeLYGMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-9WEwNmEduYd-55D-Aiqg" guid="_O-9WEwNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
+ <size xmi:id="_O-9WFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OgNmEduYd-55D-Aiqg" guid="_O8q3OgNmEduYd-55D-Aiqg" presentation="Activity Detail" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_NSW6sQMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sQMAEduOAKqB9I73uw" briefDescription="Cette phase consiste à dérouler les sprints les uns après les autres " presentationName="Phase des sprints" isPlanned="false" superActivities="_9llsAQAvEdubGMceRDupFQ" linkToPredecessor="_9MP9UAMAEduOAKqB9I73uw" breakdownElements="_SoXWEQMAEduOAKqB9I73uw _zbM2QIGBEduKE9hnyImx1Q _MpXRYIGOEduKE9hnyImx1Q _RHd0YIGOEduKE9hnyImx1Q"/>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9MP9UAMAEduOAKqB9I73uw" guid="_9MP9UAMAEduOAKqB9I73uw" linkType="finishToFinish" pred="_37TdkAL_EduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zbM2QIGBEduKE9hnyImx1Q" name="Sprint de release" guid="_zbM2QIGBEduKE9hnyImx1Q" briefDescription="Ce dernier sprint permet de préparer la livraison du produit." presentationName="Travaux de livraison" isPlanned="true" isOptional="true" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" mandatoryInput="_RHd0YIGOEduKE9hnyImx1Q" output="_RHd0YIGOEduKE9hnyImx1Q" performedPrimarilyBy="_MpXRYIGOEduKE9hnyImx1Q">
+ <presentation xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-EOwIzNPjfNIjzJ3TRAgeWQ"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MpXRYIGOEduKE9hnyImx1Q" name="Team" guid="_MpXRYIGOEduKE9hnyImx1Q" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_NSW6sQMAEduOAKqB9I73uw">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_RHd0YIGOEduKE9hnyImx1Q" name="Product increment" guid="_RHd0YIGOEduKE9hnyImx1Q" presentationName="Incrément de produit" superActivities="_NSW6sQMAEduOAKqB9I73uw">
+ <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
+ </processElements>
+ <diagrams xmi:id="_N15QIAMBEduOAKqB9I73uw" guid="_N15QIAMBEduOAKqB9I73uw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_N15QIQMBEduOAKqB9I73uw" guid="_N15QIQMBEduOAKqB9I73uw">
+ <position xmi:id="_N15QIgMBEduOAKqB9I73uw" x="204.0" y="49.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_APACQWaOEduYmqfjmBwflA" guid="_APACQWaOEduYmqfjmBwflA" anchor="_APACQGaOEduYmqfjmBwflA _APACQmaOEduYmqfjmBwflA"/>
+ <anchorage xmi:id="__iwAQmaNEduYmqfjmBwflA" guid="__iwAQmaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA"/>
+ <anchorage xmi:id="_APACQGaOEduYmqfjmBwflA" guid="_APACQGaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
+ <position xmi:id="_APACQ2aOEduYmqfjmBwflA" x="212.0" y="44.0"/>
+ </anchorage>
+ <anchorage xmi:id="_K_vA8maOEduYmqfjmBwflA" guid="_K_vA8maOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QIwMBEduOAKqB9I73uw" guid="_N15QIwMBEduOAKqB9I73uw" element="_SoXWEQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_N15QJAMBEduOAKqB9I73uw" width="40.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8BvXoGaNEduYmqfjmBwflA" guid="_8BvXoGaNEduYmqfjmBwflA">
+ <position xmi:id="_8BvXoWaNEduYmqfjmBwflA" x="94.0" y="62.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__iwAQWaNEduYmqfjmBwflA" guid="__iwAQWaNEduYmqfjmBwflA" anchor="__iwAQGaNEduYmqfjmBwflA __iwAQmaNEduYmqfjmBwflA"/>
+ <anchorage xmi:id="__iwAQGaNEduYmqfjmBwflA" guid="__iwAQGaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA">
+ <position xmi:id="__iwAQ2aNEduYmqfjmBwflA" x="94.0" y="51.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8BvXomaNEduYmqfjmBwflA" guid="_8BvXomaNEduYmqfjmBwflA" typeInfo="start node"/>
+ <size xmi:id="_8BvXo2aNEduYmqfjmBwflA" width="19.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8oyJgGaNEduYmqfjmBwflA" guid="_8oyJgGaNEduYmqfjmBwflA">
+ <position xmi:id="_8oyJgWaNEduYmqfjmBwflA" x="613.0" y="60.0"/>
+ <anchorage xmi:id="_7lIDYoGEEduKE9hnyImx1Q" guid="_7lIDYoGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_hKUjEoGFEduKE9hnyImx1Q" guid="_hKUjEoGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8oyJgmaNEduYmqfjmBwflA" guid="_8oyJgmaNEduYmqfjmBwflA" typeInfo="end node"/>
+ <size xmi:id="_8oyJg2aNEduYmqfjmBwflA" width="26.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9kPFIGaNEduYmqfjmBwflA" guid="_9kPFIGaNEduYmqfjmBwflA">
+ <position xmi:id="_9kPFIWaNEduYmqfjmBwflA" x="343.0" y="60.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_K_vA8WaOEduYmqfjmBwflA" guid="_K_vA8WaOEduYmqfjmBwflA" anchor="_K_vA8GaOEduYmqfjmBwflA _K_vA8maOEduYmqfjmBwflA">
+ <waypoints xmi:id="_R-7AoGaOEduYmqfjmBwflA" x="363.0" y="17.0"/>
+ <waypoints xmi:id="_QXWl4GaOEduYmqfjmBwflA" x="222.0" y="17.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_a2plkYGFEduKE9hnyImx1Q" guid="_a2plkYGFEduKE9hnyImx1Q" anchor="_a2plkIGFEduKE9hnyImx1Q _a2plkoGFEduKE9hnyImx1Q">
+ <waypoints xmi:id="_DyIEkIGGEduKE9hnyImx1Q" x="363.0" y="133.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_hKUjEYGFEduKE9hnyImx1Q" guid="_hKUjEYGFEduKE9hnyImx1Q" anchor="_hKUjEIGFEduKE9hnyImx1Q _hKUjEoGFEduKE9hnyImx1Q">
+ <waypoints xmi:id="_9g1ssIGFEduKE9hnyImx1Q" x="575.0" y="71.0"/>
+ </contained>
+ <anchorage xmi:id="_APACQmaOEduYmqfjmBwflA" guid="_APACQmaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
+ <position xmi:id="_APACRGaOEduYmqfjmBwflA" x="0.0" y="11.0"/>
+ </anchorage>
+ <anchorage xmi:id="_K_vA8GaOEduYmqfjmBwflA" guid="_K_vA8GaOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA">
+ <position xmi:id="_K_vA82aOEduYmqfjmBwflA" x="21.0" y="0.0"/>
+ </anchorage>
+ <anchorage xmi:id="_a2plkIGFEduKE9hnyImx1Q" guid="_a2plkIGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q">
+ <position xmi:id="_Ais7MIGGEduKE9hnyImx1Q" x="21.0" y="23.0"/>
+ </anchorage>
+ <anchorage xmi:id="_hKUjEIGFEduKE9hnyImx1Q" guid="_hKUjEIGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q">
+ <position xmi:id="_9C4lYIGFEduKE9hnyImx1Q" x="42.0" y="11.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9kPFImaNEduYmqfjmBwflA" guid="_9kPFImaNEduYmqfjmBwflA" typeInfo="decision node"/>
+ <size xmi:id="_9kPFI2aNEduYmqfjmBwflA" width="43.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_-UpVwHoSEduJVrY6eKG_mw" name="Add Free Text" guid="_-UpVwHoSEduJVrY6eKG_mw">
+ <property xmi:id="_-UpVwXoSEduJVrY6eKG_mw" guid="_-UpVwXoSEduJVrY6eKG_mw" key="free text" value="livraison à préparer"/>
+ <position xmi:id="_-UpVwnoSEduJVrY6eKG_mw" x="377.0" y="102.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_-UpVw3oSEduJVrY6eKG_mw" guid="_-UpVw3oSEduJVrY6eKG_mw" typeInfo="free text"/>
+ <size xmi:id="_-UpVxHoSEduJVrY6eKG_mw" width="69.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O1l_kHoTEduJVrY6eKG_mw" name="Add Free Text" guid="_O1l_kHoTEduJVrY6eKG_mw">
+ <property xmi:id="_O1l_kXoTEduJVrY6eKG_mw" guid="_O1l_kXoTEduJVrY6eKG_mw" key="free text" value="encore un sprint"/>
+ <position xmi:id="_O1l_knoTEduJVrY6eKG_mw" x="237.0" y="0.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_O1l_k3oTEduJVrY6eKG_mw" guid="_O1l_k3oTEduJVrY6eKG_mw" typeInfo="free text"/>
+ <size xmi:id="_O1l_lHoTEduJVrY6eKG_mw" width="79.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4SofQIGBEduKE9hnyImx1Q" guid="_4SofQIGBEduKE9hnyImx1Q">
+ <position xmi:id="_4SofQYGBEduKE9hnyImx1Q" x="457.0" y="104.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7lIDYYGEEduKE9hnyImx1Q" guid="_7lIDYYGEEduKE9hnyImx1Q" anchor="_7lIDYIGEEduKE9hnyImx1Q _7lIDYoGEEduKE9hnyImx1Q">
+ <waypoints xmi:id="_FGeBUIGGEduKE9hnyImx1Q" x="626.0" y="133.0"/>
+ </contained>
+ <anchorage xmi:id="_7lIDYIGEEduKE9hnyImx1Q" guid="_7lIDYIGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q">
+ <position xmi:id="_7lIDY4GEEduKE9hnyImx1Q" x="509.0" y="67.0"/>
+ </anchorage>
+ <anchorage xmi:id="_a2plkoGFEduKE9hnyImx1Q" guid="_a2plkoGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_4SofQoGBEduKE9hnyImx1Q" guid="_4SofQoGBEduKE9hnyImx1Q" element="_zbM2QIGBEduKE9hnyImx1Q"/>
+ <size xmi:id="_4SofQ4GBEduKE9hnyImx1Q" width="82.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JYpoMIGGEduKE9hnyImx1Q" name="Add Free Text" guid="_JYpoMIGGEduKE9hnyImx1Q">
+ <property xmi:id="_JYpoMYGGEduKE9hnyImx1Q" guid="_JYpoMYGGEduKE9hnyImx1Q" key="free text" value="fin de release"/>
+ <position xmi:id="_JYpoMoGGEduKE9hnyImx1Q" x="457.0" y="54.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JYpoM4GGEduKE9hnyImx1Q" guid="_JYpoM4GGEduKE9hnyImx1Q" typeInfo="free text"/>
+ <size xmi:id="_JYpoNIGGEduKE9hnyImx1Q" width="66.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QJQMBEduOAKqB9I73uw" guid="_N15QJQMBEduOAKqB9I73uw" presentation="Workflow" element="_NSW6sQMAEduOAKqB9I73uw"/>
+ </diagrams>
+ </childPackages>
+ <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_E1ptMIF9EduKE9hnyImx1Q" guid="_E1ptMIF9EduKE9hnyImx1Q" linkType="finishToFinish" pred="_NSW6sQMAEduOAKqB9I73uw"/>
+ <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_XJr8krPCEduk5O8SjA21Fg" name="Product Owner" guid="_XJr8krPCEduk5O8SjA21Fg" suppressed="true" presentationName="Directeur Produit" superActivities="_9llsAQAvEdubGMceRDupFQ">
+ <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
+ </processElements>
+ <diagrams xmi:id="_kZvAwAChEduhO59Otqg2rw" guid="_kZvAwAChEduhO59Otqg2rw">
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAwQChEduhO59Otqg2rw" guid="_kZvAwQChEduhO59Otqg2rw">
+ <position xmi:id="_kZvAwgChEduhO59Otqg2rw" x="124.0" y="57.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mj1g0QChEduhO59Otqg2rw" guid="_mj1g0QChEduhO59Otqg2rw" anchor="_mj1g0AChEduhO59Otqg2rw _mj1g0gChEduhO59Otqg2rw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_mkBuEQChEduhO59Otqg2rw" guid="_mkBuEQChEduhO59Otqg2rw"/>
+ </contained>
+ <anchorage xmi:id="_mj1g0AChEduhO59Otqg2rw" guid="_mj1g0AChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw">
+ <position xmi:id="_mj1g0wChEduhO59Otqg2rw" x="158.0" y="73.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAwwChEduhO59Otqg2rw" guid="_kZvAwwChEduhO59Otqg2rw"/>
+ <size xmi:id="_kZvAxAChEduhO59Otqg2rw" width="55.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAxQChEduhO59Otqg2rw" guid="_kZvAxQChEduhO59Otqg2rw">
+ <position xmi:id="_kZvAxgChEduhO59Otqg2rw" x="340.0" y="57.0"/>
+ <anchorage xmi:id="_mj1g0gChEduhO59Otqg2rw" guid="_mj1g0gChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAxwChEduhO59Otqg2rw" guid="_kZvAxwChEduhO59Otqg2rw"/>
+ <size xmi:id="_kZvAyAChEduhO59Otqg2rw" width="62.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Ew8_sACiEduhO59Otqg2rw" name="Add Free Text" guid="_Ew8_sACiEduhO59Otqg2rw">
+ <property xmi:id="_Ew8_sQCiEduhO59Otqg2rw" guid="_Ew8_sQCiEduhO59Otqg2rw" key="free text" value="les sprints successifs qui constituent la release"/>
+ <position xmi:id="_Ew8_sgCiEduhO59Otqg2rw" x="299.0" y="87.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Ew8_swCiEduhO59Otqg2rw" guid="_Ew8_swCiEduhO59Otqg2rw" typeInfo="free text"/>
+ <size xmi:id="_Ew8_tACiEduhO59Otqg2rw" width="86.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Nk0CAACiEduhO59Otqg2rw" name="Add Free Text" guid="_Nk0CAACiEduhO59Otqg2rw">
+ <property xmi:id="_Nk6IoACiEduhO59Otqg2rw" guid="_Nk6IoACiEduhO59Otqg2rw" key="free text" value="Phase initiale avant le premier sprint"/>
+ <position xmi:id="_Nk6IoQCiEduhO59Otqg2rw" x="134.0" y="89.0"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Nk6IogCiEduhO59Otqg2rw" guid="_Nk6IogCiEduhO59Otqg2rw" typeInfo="free text"/>
+ <size xmi:id="_Nk6IowCiEduhO59Otqg2rw" width="72.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5YwkAEKEduzRosbOajx7w" guid="_G5YwkAEKEduzRosbOajx7w">
+ <position xmi:id="_G5e3MAEKEduzRosbOajx7w" x="109.0" y="43.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ivhy0QEKEduzRosbOajx7w" guid="_Ivhy0QEKEduzRosbOajx7w" anchor="_Ivhy0AEKEduzRosbOajx7w _Ivhy0gEKEduzRosbOajx7w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_Iv0GsQEKEduzRosbOajx7w" guid="_Iv0GsQEKEduzRosbOajx7w"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ZSAOMQEsEduzRosbOajx7w" guid="_ZSAOMQEsEduzRosbOajx7w" anchor="_ZSAOMAEsEduzRosbOajx7w _ZSAOMgEsEduzRosbOajx7w">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZSSiEQEsEduzRosbOajx7w" guid="_ZSSiEQEsEduzRosbOajx7w"/>
+ </contained>
+ <anchorage xmi:id="_Ivhy0AEKEduzRosbOajx7w" guid="_Ivhy0AEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w">
+ <position xmi:id="_Ivhy0wEKEduzRosbOajx7w" x="152.0" y="58.0"/>
+ </anchorage>
+ <anchorage xmi:id="_ZSAOMAEsEduzRosbOajx7w" guid="_ZSAOMAEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w">
+ <position xmi:id="_ZSAOMwEsEduzRosbOajx7w" x="135.0" y="60.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3MQEKEduzRosbOajx7w" guid="_G5e3MQEKEduzRosbOajx7w"/>
+ <size xmi:id="_G5e3MgEKEduzRosbOajx7w" width="55.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5e3MwEKEduzRosbOajx7w" guid="_G5e3MwEKEduzRosbOajx7w">
+ <position xmi:id="_G5e3NAEKEduzRosbOajx7w" x="337.0" y="41.0"/>
+ <anchorage xmi:id="_Ivhy0gEKEduzRosbOajx7w" guid="_Ivhy0gEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3NQEKEduzRosbOajx7w" guid="_G5e3NQEKEduzRosbOajx7w"/>
+ <size xmi:id="_G5e3NgEKEduzRosbOajx7w" width="83.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GOyb8AEsEduzRosbOajx7w" guid="_GOyb8AEsEduzRosbOajx7w">
+ <position xmi:id="_GOyb8QEsEduzRosbOajx7w" x="359.0" y="43.0"/>
+ <anchorage xmi:id="_ZSAOMgEsEduzRosbOajx7w" guid="_ZSAOMgEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GOyb8gEsEduzRosbOajx7w" guid="_GOyb8gEsEduzRosbOajx7w"/>
+ <size xmi:id="_GOyb8wEsEduzRosbOajx7w" width="32.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-4AMAEduOAKqB9I73uw" guid="_6wY-4AMAEduOAKqB9I73uw">
+ <position xmi:id="_6wY-4QMAEduOAKqB9I73uw" x="112.0" y="25.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9LxcMQMAEduOAKqB9I73uw" guid="_9LxcMQMAEduOAKqB9I73uw" anchor="_9LxcMAMAEduOAKqB9I73uw _9LxcMgMAEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9MP9UQMAEduOAKqB9I73uw" guid="_9MP9UQMAEduOAKqB9I73uw"/>
+ </contained>
+ <anchorage xmi:id="_9LxcMAMAEduOAKqB9I73uw" guid="_9LxcMAMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw">
+ <position xmi:id="_9LxcMwMAEduOAKqB9I73uw" x="151.0" y="42.0"/>
+ </anchorage>
+ <anchorage xmi:id="_D3KWIgMBEduOAKqB9I73uw" guid="_D3KWIgMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-4gMAEduOAKqB9I73uw" guid="_6wY-4gMAEduOAKqB9I73uw" element="_37TdkAL_EduOAKqB9I73uw"/>
+ <size xmi:id="_6wY-4wMAEduOAKqB9I73uw" width="103.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-5AMAEduOAKqB9I73uw" guid="_6wY-5AMAEduOAKqB9I73uw">
+ <position xmi:id="_6wY-5QMAEduOAKqB9I73uw" x="295.0" y="25.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_EPaeEQMBEduOAKqB9I73uw" guid="_EPaeEQMBEduOAKqB9I73uw" anchor="_EPaeEAMBEduOAKqB9I73uw">
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_E1ptMYF9EduKE9hnyImx1Q" guid="_E1ptMYF9EduKE9hnyImx1Q"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_DVQF4YGHEduKE9hnyImx1Q" guid="_DVQF4YGHEduKE9hnyImx1Q" anchor="_DVQF4IGHEduKE9hnyImx1Q _DVQF4oGHEduKE9hnyImx1Q"/>
+ <anchorage xmi:id="_9LxcMgMAEduOAKqB9I73uw" guid="_9LxcMgMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_EPaeEAMBEduOAKqB9I73uw" guid="_EPaeEAMBEduOAKqB9I73uw" graphEdge="_EPaeEQMBEduOAKqB9I73uw">
+ <position xmi:id="_EPaeEwMBEduOAKqB9I73uw" x="340.0" y="44.0"/>
+ </anchorage>
+ <anchorage xmi:id="_DVQF4IGHEduKE9hnyImx1Q" guid="_DVQF4IGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q">
+ <position xmi:id="_ENbrEIGHEduKE9hnyImx1Q" x="343.0" y="41.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-5gMAEduOAKqB9I73uw" guid="_6wY-5gMAEduOAKqB9I73uw" element="_NSW6sQMAEduOAKqB9I73uw"/>
+ <size xmi:id="_6wY-5wMAEduOAKqB9I73uw" width="87.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_CL_00AMBEduOAKqB9I73uw" guid="_CL_00AMBEduOAKqB9I73uw">
+ <position xmi:id="_CL_00QMBEduOAKqB9I73uw" x="39.0" y="38.0"/>
+ <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D3KWIQMBEduOAKqB9I73uw" guid="_D3KWIQMBEduOAKqB9I73uw" anchor="_D3KWIAMBEduOAKqB9I73uw _D3KWIgMBEduOAKqB9I73uw"/>
+ <anchorage xmi:id="_D3KWIAMBEduOAKqB9I73uw" guid="_D3KWIAMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw">
+ <position xmi:id="_D3KWIwMBEduOAKqB9I73uw" x="46.0" y="44.0"/>
+ </anchorage>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_CL_00gMBEduOAKqB9I73uw" guid="_CL_00gMBEduOAKqB9I73uw" typeInfo="start node"/>
+ <size xmi:id="_CL_00wMBEduOAKqB9I73uw" width="20.0" height="-1.0"/>
+ </contained>
+ <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DDxxYAMBEduOAKqB9I73uw" guid="_DDxxYAMBEduOAKqB9I73uw">
+ <position xmi:id="_DD34AAMBEduOAKqB9I73uw" x="456.0" y="36.0"/>
+ <anchorage xmi:id="_DVQF4oGHEduKE9hnyImx1Q" guid="_DVQF4oGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q"/>
+ <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DD34AQMBEduOAKqB9I73uw" guid="_DD34AQMBEduOAKqB9I73uw" typeInfo="end node"/>
+ <size xmi:id="_DD34AgMBEduOAKqB9I73uw" width="24.0" height="-1.0"/>
+ </contained>
+ <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAyQChEduhO59Otqg2rw" guid="_kZvAyQChEduhO59Otqg2rw" presentation="Workflow" element="_9llsAQAvEdubGMceRDupFQ"/>
+ </diagrams>
+ <process xsi:type="org.eclipse.epf.uma:DeliveryProcess" xmi:id="_9llsAQAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAQAvEdubGMceRDupFQ" briefDescription="Les phases, les sprints et les tâches à dérouler lors de la production d'une release." presentationName="Release" isRepeatable="true" breakdownElements="_37TdkAL_EduOAKqB9I73uw _NSW6sQMAEduOAKqB9I73uw _XJr8krPCEduk5O8SjA21Fg">
+ <presentation xmi:id="-16dzhVoCex78V2iCDZVx0w" href="uma://-16dzhVoCex78V2iCDZVx0w#-16dzhVoCex78V2iCDZVx0w"/>
+ <concepts href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_XtRuYP-zEdqLnajTSLeAsA"/>
+ <defaultContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
+ <validContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
+ </process>
+ </org.eclipse.epf.uma:ProcessComponent>
+</xmi:XMI>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/csm.jpg b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif
new file mode 100644
index 0000000..e7d73b3
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.gif
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
new file mode 100644
index 0000000..bc69128
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.png b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.png
new file mode 100644
index 0000000..a91525c
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/deliveryprocesses/resources/icescrum_simple.png
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/disciplines/Scrum activities.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/disciplines/Scrum activities.xmi
new file mode 100644
index 0000000..48a8e24
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/disciplines/Scrum activities.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" name="Scrum activities,_6sdMAAL-EduOAKqB9I73uw" guid="-4wqJQ0qXLYZ8kCnpDu--tA" changeDate="2006-12-03T10:43:16.000+0100" version="1.0.0">
+ <mainDescription><p>
+ L'application de Scrum concerne essentiellement&nbsp;les disciplines habituelles de gestion de projet et de gestion des
+ exigences.
+</p></mainDescription>
+ <keyConsiderations>Une bonne partie de ces activités est effectuée collectivement,&nbsp;en équipe.</keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Presentation Scrum.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Presentation Scrum.xmi
new file mode 100644
index 0000000..b707be0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Presentation Scrum.xmi
@@ -0,0 +1,81 @@
+<?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" epf:version="1.0.0" xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" name="new_concept,_3WivIBTQEduFIr9xNbwGyQ" guid="-MSO8KF-0IlKZJGnSwwTNZA" changeDate="2006-12-03T08:21:54.843+0100" version="1.0.0">
+ <mainDescription><p>
+ Scrum est un processus léger et itératif de gestion de projets, qui fait partie de la famille des <a
+ title="Méthode agile" href="http://fr.wikipedia.org/wiki/Méthode_agile">méthodes agiles</a>, qui partage les valeurs
+ définies dans le Manifeste Agile et qui en reprend les principes fondamentaux.
+</p>
+<h5>
+ Résumé
+</h5>
+<p>
+ Scrum peut se résumer ainsi :
+</p>
+<p class="quote">
+ Scrum conduit à montrer souvent et régulièrement (toutes les 2 à 4 semaines, selon la durée du <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>) un produit (partiel) qui fonctionne. Le métier identifie les exigences et
+ définit leur priorité. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les
+ plus prioritaires. A chaque fin de sprint, tout le monde peut voir fonctionner le produit actuel et contribuer à
+ prendre une décision sur ce qu'on fait&nbsp;: soit le livrer dans l'état, soit continuer à l'améliorer pendant&nbsp;un
+ sprint&nbsp;supplémentaire avant de se reposer la question.
+</p>
+<h5>
+ Origine
+</h5>
+<p>
+ Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée,
+ qui cherche à atteindre un but, comme c'est le cas au rugby quand le pack déploie sa force collective pour avancer avec
+ le ballon pendant une mêlée.
+</p>
+<p>
+ Scrum insiste particulièrement sur l’aspect social et collectif du développement. Le but de Scrum est d'améliorer la
+ qualité et la productivité, avec une approche empirique, en s'appuyant sur l'autonomie de l'équipe.
+</p>
+<h5>
+ Empirisme
+</h5>
+<p>
+ Un processus empirique, donc basé sur l'expérience, nécessite une bonne visibilité, des inspections fréquentes et des
+ adaptations aux plans. Cela se décline dans Scrum par les 2 cycles de régulation&nbsp;:
+</p>
+<ul>
+ <li>
+ lors de mêlées quotidiennes, on tient compte de l'expérience du jour passé pour adapter le planning des jours
+ restant dans le sprint.
+ </li>
+ <li>
+ lors des revues de sprint, on tient compte de l'expérience du sprint passé pour adapter le planning de la release,
+ portant sur les sprints à venir.
+ </li>
+</ul>
+<p>
+ Les tâches d'un sprint ne sont pas définies de façon très précise : pas de date de début, pas de date de fin, pas de
+ dépendance. Scrum considère que ce n'est pas prévisible. L'empirisme de Scrum consiste à s'appuyer continuellement sur
+ l'analyse de l'état courant du projet pour contrôler le processus et réduire les risques.
+</p>
+<h5>
+ Portée
+</h5>
+<p>
+ Scrum ne décrit pas toutes les disciplines du développement (analyse, conception, codage, test) et doit être considéré,
+ plutôt qu’un processus complet, comme un pattern de processus qui est&nbsp;concerne la gestion de projet et la gestion
+ des exigences. Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement. C'est à
+ l'équipe de définir elle-même ce qu'elle à faire.
+</p>
+<h5>
+ Diffusion
+</h5>
+<p>
+ Scrum existe depuis les années 90 et connaît une popularité croissante depuis quelques années. Il a été utilisé sur des
+ centaines de projets dans le monde, mais est pour l’instant peu introduit en France. Depuis 3 ans, un processus de
+ certification a été mis en place. En novembre 2006, plus de 7000 personnes avaient obtenu la certification ScrumMaster.
+</p>
+<p>
+ &nbsp;<img height="56" alt="ScrumMaster" src="./resources/csm.jpg" width="179" />
+</p>
+<p>
+ Pour plus d'informations sur Scrum, voir <a href="http://fr.wikipedia.org/wiki/Scrum"
+ target="_blank">http://fr.wikipedia.org/wiki/Scrum</a>
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Produit, release et sprint.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Produit, release et sprint.xmi
new file mode 100644
index 0000000..6d73875
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Produit, release et sprint.xmi
@@ -0,0 +1,37 @@
+<?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" epf:version="1.0.0" xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" name="Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA" guid="-BPz1k8sC6CCyJ2yZCc1p2Q" changeDate="2006-12-02T00:54:40.221+0100" version="1.0.0">
+ <mainDescription><p>
+ Une <a class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>&nbsp;est constituée d'une série de <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
+ guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s et dure en général quelques mois. Pendant la vie d'un produit, on déroule
+ plusieurs releases.
+</p>
+<p>
+ <img height="115" alt="release et sprints" src="./resources/release.jpg" width="600" />
+</p>
+<p>
+ Une release a les attributs suivants :
+</p>
+<ul class="noindent">
+ <li>
+ le but
+ </li>
+ <li>
+ le type, à choisir entre "à date fixée" et "sans date fixée"(par défaut). Dans le cas où on choisit à date fixée,
+ la date est fournie.
+ </li>
+ <li>
+ la durée, en nombre de jours, définie pour les sprints
+ </li>
+ <li>
+ le nombre de sprints&nbsp;prévus
+ </li>
+</ul>
+<p>
+ Le <a class="elementLink" href="./../../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;constitue un niveau de planification du projet : il
+ montre de façon "grosses mailles" les items qu'il est prévu de réaliser au cours des sprints de cette release.<br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Travail collaboratif.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Travail collaboratif.xmi
new file mode 100644
index 0000000..55eac7a
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/Travail collaboratif.xmi
@@ -0,0 +1,134 @@
+<?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" epf:version="1.0.0" xmi:id="-dU_t9olFRQIyOBZQvMndKg" name="new_concept,_OUjj0AEZEduzRosbOajx7w" guid="-dU_t9olFRQIyOBZQvMndKg" changeDate="2006-12-04T21:17:26.750+0100">
+ <mainDescription><p>
+ Le collectif prend forme à travers des réunions. Scrum impose 5 types de réunions :&nbsp;
+</p>
+<ol>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>&nbsp;(1ème partie, sélection du sous-ensemble du backlog))
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
+ guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>nt (2ème&nbsp;partie, planification du sprint)
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A.html"
+ guid="_d09LYP_AEdqtbrr0B1TG-A">Mêlée quotidienne</a>
+ </li>
+ <li>
+ Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Review sprint,_MRrRYPpbEdqsc-f87sBK8A.html"
+ guid="_MRrRYPpbEdqsc-f87sBK8A">Faire la revue du sprint</a>
+ </li>
+ <li>
+ <a class="elementLink" href="./../../../Scrum/tasks/Retrospective,_J_sRIP_AEdqtbrr0B1TG-A.html"
+ guid="_J_sRIP_AEdqtbrr0B1TG-A">Rétrospective</a><br />
+ </li>
+</ol>
+<p>
+ Le tableau ci-dessous montre la participation des rôles Scrum à ces réunions :<br />
+</p>
+<table cellspacing="2" cellpadding="2" width="180" border="1">
+ <tbody>
+ <tr>
+ <th scope="col">
+ </th>
+ <th scope="col">
+ 1
+ </th>
+ <th scope="col">
+ 2
+ </th>
+ <th scope="col">
+ 3
+ </th>
+ <th scope="col">
+ 4
+ </th>
+ <th scope="col">
+ 5
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ <a class="elementLink" href="./../../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+ </th>
+ <td>
+ Animation
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Equipe
+ </th>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ <td>
+ Animation
+ </td>
+ <td>
+ Obligatoire
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Intervenant
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ Possible
+ </td>
+ <td>
+ Souhaitée
+ </td>
+ <td>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/clip_image001.png b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/clip_image001.png
new file mode 100644
index 0000000..32678ac
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/clip_image001.png
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/clip_image002.gif b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/clip_image002.gif
new file mode 100644
index 0000000..aa6b057
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/clip_image002.gif
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/csm.jpg b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/csm.jpg
new file mode 100644
index 0000000..18cd417
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/csm.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/release.jpg b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/release.jpg
new file mode 100644
index 0000000..a270cd4
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/concepts/resources/release.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/examples/resources/demo_banque_2.JPG b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/examples/resources/demo_banque_2.JPG
new file mode 100644
index 0000000..046308b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/examples/resources/demo_banque_2.JPG
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Release Burndown Chart.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Release Burndown Chart.xmi
new file mode 100644
index 0000000..434f1c4
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Release Burndown Chart.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" name="Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A" guid="-pJuF9iKbSQx7TIwHNBVTgg" changeDate="2006-12-03T15:16:09.515+0100">
+ <mainDescription><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour une release :&nbsp;il montre la tendance dans
+ l'avancement de la release par une présentation graphique du reste à faire à la fin de chaque sprint passé.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Release Planning.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Release Planning.xmi
new file mode 100644
index 0000000..9360ab0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Release Planning.xmi
@@ -0,0 +1,7 @@
+<?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" epf:version="1.0.0" xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" name="new_report,_Z2NzkIGWEduKE9hnyImx1Q" guid="-EmLqiNX2WnmsfEtxNiuyTQ" changeDate="2006-12-02T00:51:59.549+0100">
+ <mainDescription><p>
+ Il est dérivé du backlog de produit : c'est un sous-ensemble contenant uniquement les éléments prévus dans la release
+ et associés aux sprints prévus dans la release.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi
new file mode 100644
index 0000000..10e80bb
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/reports/Sprint Burndown Chart.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-qVeT6_sAspmZjCYQLOrhbg" name="Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A" guid="-qVeT6_sAspmZjCYQLOrhbg" changeDate="2006-12-03T15:17:51.046+0100">
+ <mainDescription><p>
+ C'est un <a class="elementLink"
+ href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
+ guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour un sprint :&nbsp;il montre la tendance dans
+ l'avancement du sprint par une présentation graphique du reste à faire à la fin de chaque jour passé.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/roadmaps/Application.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/roadmaps/Application.xmi
new file mode 100644
index 0000000..5ade8ce
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/roadmaps/Application.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" name="new_roadmap,_6Jox0IRuEduo75chJsIcXg" guid="-IPxNSDzXKWa-H_kJ2PMtYA" changeDate="2006-12-05T16:29:34.781+0100">
+ <mainDescription><p>
+ Le&nbsp;Manifeste Agile proclame que "les outils et les processus sont utiles, mais que&nbsp;les personnes et les
+ interactions qu'elles ont entre elles sont plus importantes" pour la réussite du projet. Il faut garder ce principe à
+ l'esprit lors de l'application de Scrum. Il convient également de respecter les&nbsp;caractéristiques de Scrum comme :
+</p>
+<ul>
+ <li>
+ l'approche empirique basée sur la régulation,
+ </li>
+ <li>
+ la planification adaptative plutôt que prédictive,
+ </li>
+ <li>
+ l'auto-gestion de l'équipe pour faire ce qu'elle a à faire.
+ </li>
+</ul>
+<p>
+ De plus, Scrum ne décrit pas les activités d'ingénierie nécessaires à la réalisation du produit.
+</p>
+<p>
+ L'application de Scrum décrite ci-dessous&nbsp;doit être lue et utilisée&nbsp;à l'aune de ces principes agiles. Elle
+ montre comment les éléments de Scrum sont utilisés lors du déroulement d'une période de temps,&nbsp;ou cycle de vie.
+</p>
+<p>
+ Ce cycle de vie ne représente pas toute la vie d'un produit, mais porte uniquement sur la production d'une <a
+ class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
+ guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>. Le guide <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA.html"
+ guid="_XtRuYP-zEdqLnajTSLeAsA">Produit, release et sprint</a>&nbsp;replace cette période dans un contexte plus large.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Copyright.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Copyright.xmi
new file mode 100644
index 0000000..09ba739
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Copyright.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-03XtfjRMEs23qIdCSSQiNQ" name="new_supporting_material,_N8zs0AEGEduzRosbOajx7w" guid="-03XtfjRMEs23qIdCSSQiNQ" changeDate="2007-02-03T11:40:46.906-0800" version="1.0.0">
+ <mainDescription>Ce programme et le matériel qui l'accompagne sont mis à disposition selon les termes de la licence "<a
+href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a>" qui régit cette
+distribution.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Introduction.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Introduction.xmi
new file mode 100644
index 0000000..8254917
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Introduction.xmi
@@ -0,0 +1,24 @@
+<?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" epf:version="1.0.0" xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" name="Introduction,_wz30kABREdu3o4yroaI-tA" guid="-WfzsSn3X35gSHQZ2kqtoVw" changeDate="2006-12-04T21:23:34.453+0100">
+ <mainDescription><p>
+ Ce plugin, réalisé&nbsp;avec&nbsp;<a href="http://www.eclipse.org/epf/" target="_blank">EPF</a> (Eclipse&nbsp;Process
+ Framework)&nbsp;présente :
+</p>
+<ul>
+ <li>
+ une introduction à <a class="elementLink"
+ href="./../../../Scrum/guidances/concepts/Presentation Scrum,_3WivIBTQEduFIr9xNbwGyQ.html"
+ guid="_3WivIBTQEduFIr9xNbwGyQ">Scrum</a>
+ </li>
+ <li>
+ les notions principales de Scrum (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Scrum Elements,_nF6fgALYEduFv7wnrO7SvQ.html"
+ guid="_nF6fgALYEduFv7wnrO7SvQ">Eléments Scrum</a>),
+ </li>
+ <li>
+ une façon de les appliquer (<a class="elementLink"
+ href="./../../../Scrum/customcategories/Cycle de vie Scrum,_7BSBkABCEduYUKPFgCzFuA.html"
+ guid="_7BSBkABCEduYUKPFgCzFuA">Cycle de vie</a>) qui est à adapter à chaque projet.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Scrum references.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Scrum references.xmi
new file mode 100644
index 0000000..a1f2561
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/supportingmaterials/Scrum references.xmi
@@ -0,0 +1,14 @@
+<?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" epf:version="1.0.0" xmi:id="-cfa6bdUgQuboNpJRKaCLAw" name="Scrum referencesl,_PTGe4IRvEduo75chJsIcXg" guid="-cfa6bdUgQuboNpJRKaCLAw" changeDate="2006-12-05T15:45:31.406+0100">
+ <mainDescription><ul>
+ <li>
+ Ken Schwaber&nbsp;: <a href="http://softpro.stores.yahoo.net/0-7356-1993-x.html" target="_blank">Agile Project
+ Management with Scrum.</a>&nbsp;
+ </li>
+ <li>
+ Mike Cohn&nbsp;: <a
+ href="http://www.amazon.fr/exec/obidos/ASIN/0131479415/sr=8-1/qid=1152998855/ref=sr_1_1/402-4433368-7461703?_encoding=UTF8&amp;s=gateway&amp;v=glance"
+ target="_blank">Agile Estimating and Planning</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi
new file mode 100644
index 0000000..63ce6f7
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Burndown Chart.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" name="new_term_definition,_X5rREILYEduLd8CaF_IcMA" guid="-KQ4Jzjy6YgAr_2NXa4J67g">
+ <mainDescription>Représentation graphique du reste à faire dans une période, actualisée aussi souvent que possible.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Release.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Release.xmi
new file mode 100644
index 0000000..46444c0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Release.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" name="Release,_AIB9gIHrEduFs9jH8xc4xw" guid="-XPyPmZTAVbnvJVuOLvYpXw" changeDate="2006-12-02T10:53:51.187+0100" version="1.0.0">
+ <mainDescription>Une release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps
+qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Sprint.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Sprint.xmi
new file mode 100644
index 0000000..0af2272
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Sprint.xmi
@@ -0,0 +1,5 @@
+<?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" epf:version="1.0.0" xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" name="new_term_definition,_kftWoIHqEduFs9jH8xc4xw" guid="-fcoz1Nm_QnX6xtLg5YWdVg" changeDate="2006-12-02T10:51:49.500+0100">
+ <mainDescription>Un sprint est un bloc de temps aboutissant à créer un incrément du produit. C'est le terme utilisé dans Scrum pour
+itération.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Theme.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Theme.xmi
new file mode 100644
index 0000000..2814df0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Theme.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-GKfSarwQLoaHhoT71FQI8Q" name="new_term_definition,_aeYKoIKlEduQgtHqedKdMA" guid="-GKfSarwQLoaHhoT71FQI8Q" changeDate="2006-12-03T09:09:30.312+0100">
+ <mainDescription>Un thème constitue un regroupement fonctionnel d'exigences.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Timebox.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Timebox.xmi
new file mode 100644
index 0000000..0d19473
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Timebox.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-tHVOELWOQDI7i0M2rlMufQ" name="new_term_definition,_3qdXkILXEduLd8CaF_IcMA" guid="-tHVOELWOQDI7i0M2rlMufQ" changeDate="2006-12-03T15:11:12.609+0100">
+ <mainDescription>Une période de temps à échéance fixée et intangible même si tous les objectifs ne sont pas atteints.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Velocity.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Velocity.xmi
new file mode 100644
index 0000000..ac28bb4
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/guidances/termdefinitions/Velocity.xmi
@@ -0,0 +1,4 @@
+<?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" epf:version="1.0.0" xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" name="new_term_definition,_HQEP8ILXEduLd8CaF_IcMA" guid="-PeP4fADValHXs2Z2Z8zJ1w" changeDate="2007-01-29T09:14:31.140+0100" version="1.0.0">
+ <mainDescription>La vélocité est la mesure de la capacité de l'équipe pendant un sprint.</mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/plugin.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/plugin.xmi
new file mode 100644
index 0000000..1789c5d
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/plugin.xmi
@@ -0,0 +1,197 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_5AUAUPpYEdqsc-f87sBK8A" guid="_5AUAUPpYEdqsc-f87sBK8A">
+ <subManagers xmi:id="_9m1CIAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9m1CIAAvEdubGMceRDupFQ"/>
+ <resourceDescriptors xmi:id="_5AUAUfpYEdqsc-f87sBK8A" id="-Y3SFEe-A-lRF8TaEn9vKNQ" uri="roles/ScrumMaster.xmi"/>
+ <resourceDescriptors xmi:id="_N_XCIf-0EdqLnajTSLeAsA" id="-CgLjZ6Bwc0EyYyQCjzlw7g" uri="rolesets/Scrum%20Roles.xmi"/>
+ <resourceDescriptors xmi:id="_aziTsP--Edqtbrr0B1TG-A" id="-NRwwk6YGAtu25V3Lc04G6w" uri="tasks/Plan%20sprint%202.xmi"/>
+ <resourceDescriptors xmi:id="_9lx5QAAvEdubGMceRDupFQ" id="_9llsAAAvEdubGMceRDupFQ" uri="deliveryprocesses/Scrum/model.xmi"/>
+ <resourceDescriptors xmi:id="_qJ7PoABSEdu3o4yroaI-tA" id="-juIDa_fXi2K1BE5NTblPow" uri="customcategories/Intro.xmi"/>
+ <resourceDescriptors xmi:id="_OY10sABaEdu3o4yroaI-tA" id="-WfzsSn3X35gSHQZ2kqtoVw" uri="guidances/supportingmaterials/Introduction.xmi"/>
+ <resourceDescriptors xmi:id="_hhv8QAB7EduSVaTQTBfIHA" id="-35iKPqDM2F2PjKWQLCW4tA" uri="roles/Product%20Owner.xmi"/>
+ <resourceDescriptors xmi:id="_hh2C4AB7EduSVaTQTBfIHA" id="-mZfAV7RcWJlp5idlHzeEcA" uri="tasks/Manage%20problems.xmi"/>
+ <resourceDescriptors xmi:id="_rosG4AEGEduzRosbOajx7w" id="-03XtfjRMEs23qIdCSSQiNQ" uri="guidances/supportingmaterials/Copyright.xmi"/>
+ <resourceDescriptors xmi:id="_kTIcUAELEduzRosbOajx7w" id="-eSc2tcV1h17HBw_s8ROEVw" uri="workproducttypes/Backlogs.xmi"/>
+ <resourceDescriptors xmi:id="_K5MbwAEPEduzRosbOajx7w" id="-Of1SdnAQ9nmsL5DFvD2Uug" uri="workproducts/Product%20Backlog.xmi"/>
+ <resourceDescriptors xmi:id="_K5MbwQEPEduzRosbOajx7w" id="-LVZG5zK2YjEGXO3SwDmqug" uri="roles/Team.xmi"/>
+ <resourceDescriptors xmi:id="_K5YpAAEPEduzRosbOajx7w" id="-u0-b4PNo9XzOh1-dv_aaKA" uri="roles/StakeHolder.xmi"/>
+ <resourceDescriptors xmi:id="_AaX3AAEQEduzRosbOajx7w" id="-8V2DOvzUhvtqwWvTOHMB5g" uri="workproducts/Sprint%20backlog.xmi"/>
+ <resourceDescriptors xmi:id="_A0kNwQESEduzRosbOajx7w" id="-zoJryMCuHfxWP7Q5Er195Q" uri="tasks/Review%20sprint.xmi"/>
+ <resourceDescriptors xmi:id="_A0qUYAESEduzRosbOajx7w" id="-vDOuVl_xPKipKd90HQNZng" uri="tasks/Scrum%20daily%20meeting.xmi"/>
+ <resourceDescriptors xmi:id="_A0qUYQESEduzRosbOajx7w" id="-XdgedeazfFRGDxMY3Fnh5g" uri="tasks/Update%20product%20backlog.xmi"/>
+ <resourceDescriptors xmi:id="_wj_I8AEWEduzRosbOajx7w" id="-S4qXwp40l_8eCcyyI7o-3A" uri="tasks/Retrospective.xmi"/>
+ <resourceDescriptors xmi:id="_WYwq0QEZEduzRosbOajx7w" id="-dU_t9olFRQIyOBZQvMndKg" uri="guidances/concepts/Travail%20collaboratif.xmi"/>
+ <resourceDescriptors xmi:id="_pWgXYAL_EduOAKqB9I73uw" id="-4wqJQ0qXLYZ8kCnpDu--tA" uri="disciplines/Scrum%20activities.xmi"/>
+ <resourceDescriptors xmi:id="_PitjwQOwEduJnc8byNAQ9Q" id="-zS9h38tmK4L-U9kbgkpGKQ" uri="customcategories/Scrum%20Elements.xmi"/>
+ <resourceDescriptors xmi:id="_XQS7sAPKEdubhrgDuRb4fA" id="-3f4axrWBKHGv74oKN2x-gQ" uri="tasks/Plan%20release.xmi"/>
+ <resourceDescriptors xmi:id="_XQZCUAPKEdubhrgDuRb4fA" id="-mi1O4H7RRm0YqlUNyp8TJg" uri="tasks/Initiate%20Product%20Backlog.xmi"/>
+ <resourceDescriptors xmi:id="_E6ZVsBTREduFIr9xNbwGyQ" id="-MSO8KF-0IlKZJGnSwwTNZA" uri="guidances/concepts/Presentation%20Scrum.xmi"/>
+ <resourceDescriptors xmi:id="_ZllqMDwUEdun48PxFCzHCw" id="-BPz1k8sC6CCyJ2yZCc1p2Q" uri="guidances/concepts/Produit,%20release%20et%20sprint.xmi"/>
+ <resourceDescriptors xmi:id="_tO6jEHpCEdug1NkGFo_hTg" id="-6aCUL_kawJFNBtfH_sRXkw" uri="workproducts/Product%20increment.xmi"/>
+ <resourceDescriptors xmi:id="_5nqe4IGJEduKE9hnyImx1Q" id="-KC1R73i9f6P7ZT4pgBOLzA" uri="workproducts/Product%20Backlog%20Item.xmi"/>
+ <resourceDescriptors xmi:id="_74nh8YGWEduKE9hnyImx1Q" id="-EmLqiNX2WnmsfEtxNiuyTQ" uri="guidances/reports/Release%20Planning.xmi"/>
+ <resourceDescriptors xmi:id="_U_2y4IHpEdu3SZQ-Dp1OAA" id="-6UJtuFO3WFBFpJOFeV1QMQ" uri="workproducts/Sprint%20Backlog%20Item.xmi"/>
+ <resourceDescriptors xmi:id="_1MHpkIHqEduFs9jH8xc4xw" id="-fcoz1Nm_QnX6xtLg5YWdVg" uri="guidances/termdefinitions/Sprint.xmi"/>
+ <resourceDescriptors xmi:id="_DD7t8IHrEduFs9jH8xc4xw" id="-XPyPmZTAVbnvJVuOLvYpXw" uri="guidances/termdefinitions/Release.xmi"/>
+ <resourceDescriptors xmi:id="_mmlSkIKlEduQgtHqedKdMA" id="-GKfSarwQLoaHhoT71FQI8Q" uri="guidances/termdefinitions/Theme.xmi"/>
+ <resourceDescriptors xmi:id="_P8d_YILXEduLd8CaF_IcMA" id="-PeP4fADValHXs2Z2Z8zJ1w" uri="guidances/termdefinitions/Velocity.xmi"/>
+ <resourceDescriptors xmi:id="_IbymwILYEduLd8CaF_IcMA" id="-tHVOELWOQDI7i0M2rlMufQ" uri="guidances/termdefinitions/Timebox.xmi"/>
+ <resourceDescriptors xmi:id="_tOn1YILYEduLd8CaF_IcMA" id="-KQ4Jzjy6YgAr_2NXa4J67g" uri="guidances/termdefinitions/Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_-wFhAILYEduLd8CaF_IcMA" id="-pJuF9iKbSQx7TIwHNBVTgg" uri="guidances/reports/Release%20Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_LCa1UILZEduLd8CaF_IcMA" id="-qVeT6_sAspmZjCYQLOrhbg" uri="guidances/reports/Sprint%20Burndown%20Chart.xmi"/>
+ <resourceDescriptors xmi:id="_egmj0IRvEduo75chJsIcXg" id="-cfa6bdUgQuboNpJRKaCLAw" uri="guidances/supportingmaterials/Scrum%20references.xmi"/>
+ <resourceDescriptors xmi:id="_cpeaYYSAEduo75chJsIcXg" id="-IPxNSDzXKWa-H_kJ2PMtYA" uri="guidances/roadmaps/Application.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" name="Scrum" guid="_mQ3eoPpYEdqsc-f87sBK8A" briefDescription="Ce plugin porte sur l'utilisation de Scrum." authors="Claude Aubry" changeDate="2006-12-05T18:52:42.109+0100" version="1.0" copyrightStatement="_N8zs0AEGEduzRosbOajx7w">
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eofpYEdqsc-f87sBK8A" name="Content" guid="_mQ3eofpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eovpYEdqsc-f87sBK8A" name="Categories" guid="_mQ3eovpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eo_pYEdqsc-f87sBK8A" name="Domains" guid="_mQ3eo_pYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:Domain" xmi:id="_AcwmAANoEduYd-55D-Aiqg" name="Scrum Artefacts" guid="_AcwmAANoEduYd-55D-Aiqg" presentationName="Produits Scrum" workProducts="_tCmYEP-xEdqLnajTSLeAsA _5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epPpYEdqsc-f87sBK8A" name="Disciplines" guid="_mQ3epPpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_6sdMAAL-EduOAKqB9I73uw" name="Scrum activities" guid="_6sdMAAL-EduOAKqB9I73uw" briefDescription="Les activités spécifiques induites par l'application de Scrum." presentationName="Activités Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" tasks="_Xpd5gP_AEdqtbrr0B1TG-A _STkWYP_BEdqtbrr0B1TG-A _ho-aIP_BEdqtbrr0B1TG-A _4LOggPpaEdqsc-f87sBK8A _J_sRIP_AEdqtbrr0B1TG-A _MRrRYPpbEdqsc-f87sBK8A _d09LYP_AEdqtbrr0B1TG-A _BGFMoANkEduYd-55D-Aiqg">
+ <presentation xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" href="uma://-4wqJQ0qXLYZ8kCnpDu--tA#-4wqJQ0qXLYZ8kCnpDu--tA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epfpYEdqsc-f87sBK8A" name="RoleSets" guid="_mQ3epfpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_3qmmoP-zEdqLnajTSLeAsA" name="Scrum Roles" guid="_3qmmoP-zEdqLnajTSLeAsA" briefDescription="Les rôles dans un projet qui applique Scrum." presentationName="Rôles Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" roles="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" href="uma://-CgLjZ6Bwc0EyYyQCjzlw7g#-CgLjZ6Bwc0EyYyQCjzlw7g"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epvpYEdqsc-f87sBK8A" name="WP Types" guid="_mQ3epvpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_d-yk8ABREdu3o4yroaI-tA" name="Backlogs" guid="_d-yk8ABREdu3o4yroaI-tA" briefDescription="Scrum utilise un nombre très restreint de produits de travail, essentiellement 2 listes appelées backlogs." presentationName="Backlogs" workProducts="_5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-eSc2tcV1h17HBw_s8ROEVw" href="uma://-eSc2tcV1h17HBw_s8ROEVw#-eSc2tcV1h17HBw_s8ROEVw"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3ep_pYEdqsc-f87sBK8A" name="Tools" guid="_mQ3ep_pYEdqsc-f87sBK8A"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqPpYEdqsc-f87sBK8A" name="StandardCategories" guid="_mQ3eqPpYEdqsc-f87sBK8A"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqfpYEdqsc-f87sBK8A" name="CustomCategories" guid="_mQ3eqfpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqvpYEdqsc-f87sBK8A" name="Hidden" guid="_mQ3eqvpYEdqsc-f87sBK8A">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mQ3eq_pYEdqsc-f87sBK8A" name="Catégories personnalisées" guid="_mQ3eq_pYEdqsc-f87sBK8A" categorizedElements="_7BSBkABCEduYUKPFgCzFuA _s8y1UABREdu3o4yroaI-tA _nF6fgALYEduFv7wnrO7SvQ"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_7BSBkABCEduYUKPFgCzFuA" name="Cycle de vie Scrum" guid="_7BSBkABCEduYUKPFgCzFuA" presentationName="Cycle de vie">
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Roadmap" href="#_6Jox0IRuEduo75chJsIcXg"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAQAvEdubGMceRDupFQ"/>
+ <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_XtRuYP-zEdqLnajTSLeAsA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_s8y1UABREdu3o4yroaI-tA" name="Intro" guid="_s8y1UABREdu3o4yroaI-tA" presentationName="Intro" categorizedElements="_wz30kABREdu3o4yroaI-tA _3WivIBTQEduFIr9xNbwGyQ _PTGe4IRvEduo75chJsIcXg">
+ <presentation xmi:id="-juIDa_fXi2K1BE5NTblPow" href="uma://-juIDa_fXi2K1BE5NTblPow#-juIDa_fXi2K1BE5NTblPow"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_nF6fgALYEduFv7wnrO7SvQ" name="Scrum Elements" guid="_nF6fgALYEduFv7wnrO7SvQ" briefDescription="Description des éléments de Scrum : rôles, réunions et backlogs, ainsi que des guides dans leur utilisation." presentationName="Eléments" categorizedElements="_3qmmoP-zEdqLnajTSLeAsA _d-yk8ABREdu3o4yroaI-tA _6sdMAAL-EduOAKqB9I73uw">
+ <presentation xmi:id="-zS9h38tmK4L-U9kbgkpGKQ" href="uma://-zS9h38tmK4L-U9kbgkpGKQ#-zS9h38tmK4L-U9kbgkpGKQ"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3erPpYEdqsc-f87sBK8A" name="CoreContent" guid="_mQ3erPpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_rkSgEPpYEdqsc-f87sBK8A" name="Eléments de Scrum" guid="_rkSgEPpYEdqsc-f87sBK8A" briefDescription="Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet. Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques. ">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_t1K9kPpYEdqsc-f87sBK8A" name="ScrumMaster" guid="_t1K9kPpYEdqsc-f87sBK8A" briefDescription="C' est l'animateur d'une équipe Scrum." presentationName="ScrumMaster" responsibleFor="_Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" href="uma://-Y3SFEe-A-lRF8TaEn9vKNQ#-Y3SFEe-A-lRF8TaEn9vKNQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_5ABscPpYEdqsc-f87sBK8A" name="Product Backlog" guid="_5ABscPpYEdqsc-f87sBK8A" briefDescription="Contient les exigences d'un produit" presentationName="Backlog de produit" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA" reports="_vKqe8PpaEdqsc-f87sBK8A _Z2NzkIGWEduKE9hnyImx1Q">
+ <presentation xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" href="uma://-Of1SdnAQ9nmsL5DFvD2Uug#-Of1SdnAQ9nmsL5DFvD2Uug"/>
+ <containedArtifacts xmi:id="_-D85cIGIEduKE9hnyImx1Q" name="Product Backlog Item" guid="_-D85cIGIEduKE9hnyImx1Q" briefDescription="Chose à faire qui apporte de la valeur. Appelé PBI (Product Backlog Item)" presentationName="Elément de backlog de produit">
+ <presentation xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" href="uma://-KC1R73i9f6P7ZT4pgBOLzA#-KC1R73i9f6P7ZT4pgBOLzA"/>
+ </containedArtifacts>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Dzw70PpZEdqsc-f87sBK8A" name="Sprint backlog" guid="_Dzw70PpZEdqsc-f87sBK8A" briefDescription="Liste des choses à faire du point de vue de l'équipe de développement." presentationName="Backlog du sprint" reports="_jC4NwPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" href="uma://-8V2DOvzUhvtqwWvTOHMB5g#-8V2DOvzUhvtqwWvTOHMB5g"/>
+ <containedArtifacts xmi:id="_9C78MIHnEdu3SZQ-Dp1OAA" name="Sprint Backlog Item" guid="_9C78MIHnEdu3SZQ-Dp1OAA" briefDescription="C'est une tâche, un travail élémentaire à réaliser pendant le sprint." presentationName="Elément de Backlog de Sprint">
+ <presentation xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" href="uma://-6UJtuFO3WFBFpJOFeV1QMQ#-6UJtuFO3WFBFpJOFeV1QMQ"/>
+ </containedArtifacts>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_ICJyYPpaEdqsc-f87sBK8A" name="Product Owner" guid="_ICJyYPpaEdqsc-f87sBK8A" briefDescription="C’est le représentant du "métier" dans le projet. " presentationName="Directeur Produit" responsibleFor="_5ABscPpYEdqsc-f87sBK8A">
+ <presentation xmi:id="-35iKPqDM2F2PjKWQLCW4tA" href="uma://-35iKPqDM2F2PjKWQLCW4tA#-35iKPqDM2F2PjKWQLCW4tA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_jC4NwPpaEdqsc-f87sBK8A" name="Sprint Burndown Chart" guid="_jC4NwPpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement du sprint courant." presentationName="Sprint Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-qVeT6_sAspmZjCYQLOrhbg" href="uma://-qVeT6_sAspmZjCYQLOrhbg#-qVeT6_sAspmZjCYQLOrhbg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_vKqe8PpaEdqsc-f87sBK8A" name="Release Burndown Chart" guid="_vKqe8PpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement de la release." presentationName="Release Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" href="uma://-pJuF9iKbSQx7TIwHNBVTgg#-pJuF9iKbSQx7TIwHNBVTgg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_4LOggPpaEdqsc-f87sBK8A" name="Plan sprint" guid="_4LOggPpaEdqsc-f87sBK8A" briefDescription="Planification du court terme" presentationName="Planifier le sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-NRwwk6YGAtu25V3Lc04G6w" href="uma://-NRwwk6YGAtu25V3Lc04G6w#-NRwwk6YGAtu25V3Lc04G6w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_9apLsPpaEdqsc-f87sBK8A" name="Team" guid="_9apLsPpaEdqsc-f87sBK8A" briefDescription="Il s'agit d'un rôle collectif. Tous les membres de l'équipe participent au travail, sans qu'on disitingue des fonctions particulières pour chacun." presentationName="Equipe Scrum" responsibleFor="_tCmYEP-xEdqLnajTSLeAsA">
+ <presentation xmi:id="-LVZG5zK2YjEGXO3SwDmqug" href="uma://-LVZG5zK2YjEGXO3SwDmqug#-LVZG5zK2YjEGXO3SwDmqug"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_MRrRYPpbEdqsc-f87sBK8A" name="Review sprint" guid="_MRrRYPpbEdqsc-f87sBK8A" briefDescription="Montrer ce qui a été réalisé et fonctionne. En tirer les conséquences." presentationName="Faire la revue du sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_tCmYEP-xEdqLnajTSLeAsA" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-zoJryMCuHfxWP7Q5Er195Q" href="uma://-zoJryMCuHfxWP7Q5Er195Q#-zoJryMCuHfxWP7Q5Er195Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_tCmYEP-xEdqLnajTSLeAsA" name="Product increment" guid="_tCmYEP-xEdqLnajTSLeAsA" briefDescription="Le produit partiel obtenu à la fin de chaque sprint." presentationName="Incrément de produit">
+ <presentation xmi:id="-6aCUL_kawJFNBtfH_sRXkw" href="uma://-6aCUL_kawJFNBtfH_sRXkw#-6aCUL_kawJFNBtfH_sRXkw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_J_sRIP_AEdqtbrr0B1TG-A" name="Retrospective" guid="_J_sRIP_AEdqtbrr0B1TG-A" briefDescription="Faire un bilan du sprint qui se termine" presentationName="Rétrospective" performedBy="_9apLsPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
+ <presentation xmi:id="-S4qXwp40l_8eCcyyI7o-3A" href="uma://-S4qXwp40l_8eCcyyI7o-3A#-S4qXwp40l_8eCcyyI7o-3A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_Qqmp8P_AEdqtbrr0B1TG-A" name="StakeHolder" guid="_Qqmp8P_AEdqtbrr0B1TG-A" briefDescription="Personne ne participant pas directement au projet mais ayant une influence sur celui-ci." presentationName="Intervenant">
+ <presentation xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" href="uma://-u0-b4PNo9XzOh1-dv_aaKA#-u0-b4PNo9XzOh1-dv_aaKA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_Xpd5gP_AEdqtbrr0B1TG-A" name="Manage problems" guid="_Xpd5gP_AEdqtbrr0B1TG-A" briefDescription="Prendre en compte les événements qui surviennent à tout moment sur un projet et tenter de les régler." presentationName="Gérer les problèmes" performedBy="_t1K9kPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" optionalInput="_Dzw70PpZEdqsc-f87sBK8A">
+ <presentation xmi:id="-mZfAV7RcWJlp5idlHzeEcA" href="uma://-mZfAV7RcWJlp5idlHzeEcA#-mZfAV7RcWJlp5idlHzeEcA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_d09LYP_AEdqtbrr0B1TG-A" name="Scrum daily meeting" guid="_d09LYP_AEdqtbrr0B1TG-A" briefDescription="La régulation des activités de développement et de test se fait à travers les mêlées quotidiennes." presentationName="Mêlée quotidienne" performedBy="_t1K9kPpYEdqsc-f87sBK8A" mandatoryInput="_Dzw70PpZEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_9apLsPpaEdqsc-f87sBK8A _ICJyYPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-vDOuVl_xPKipKd90HQNZng" href="uma://-vDOuVl_xPKipKd90HQNZng#-vDOuVl_xPKipKd90HQNZng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_STkWYP_BEdqtbrr0B1TG-A" name="Update product backlog" guid="_STkWYP_BEdqtbrr0B1TG-A" briefDescription="Prise en compte des changements de périmètre en vue de préparer les sprints suivants." presentationName="Mettre à jour le backlog de produit" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-XdgedeazfFRGDxMY3Fnh5g" href="uma://-XdgedeazfFRGDxMY3Fnh5g#-XdgedeazfFRGDxMY3Fnh5g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_ho-aIP_BEdqtbrr0B1TG-A" name="Plan release" guid="_ho-aIP_BEdqtbrr0B1TG-A" briefDescription="Planification à moyen terme" presentationName="Planifier la release" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-3f4axrWBKHGv74oKN2x-gQ" href="uma://-3f4axrWBKHGv74oKN2x-gQ#-3f4axrWBKHGv74oKN2x-gQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_OUjj0AEZEduzRosbOajx7w" name="Travail collaboratif" guid="_OUjj0AEZEduzRosbOajx7w" presentationName="Travail collaboratif">
+ <presentation xmi:id="-dU_t9olFRQIyOBZQvMndKg" href="uma://-dU_t9olFRQIyOBZQvMndKg#-dU_t9olFRQIyOBZQvMndKg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_XtRuYP-zEdqLnajTSLeAsA" name="Produit, release et sprint" guid="_XtRuYP-zEdqLnajTSLeAsA" presentationName="Produit, release et sprint">
+ <presentation xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" href="uma://-BPz1k8sC6CCyJ2yZCc1p2Q#-BPz1k8sC6CCyJ2yZCc1p2Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_BGFMoANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_BGFMoANkEduYd-55D-Aiqg" briefDescription="Identifier une liste d'items, les inclure dans le backlog et les classer par priorité." presentationName="Elaborer le backlog de produit initial" performedBy="_ICJyYPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
+ <presentation xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" href="uma://-mi1O4H7RRm0YqlUNyp8TJg#-mi1O4H7RRm0YqlUNyp8TJg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_3WivIBTQEduFIr9xNbwGyQ" name="Presentation Scrum" guid="_3WivIBTQEduFIr9xNbwGyQ" briefDescription="Scrum repose sur une technique de gestion de projets qui conduit à obtenir un produit avec la plus grande valeur "métier" possible dans la durée la plus réduite." presentationName="Scrum">
+ <presentation xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" href="uma://-MSO8KF-0IlKZJGnSwwTNZA#-MSO8KF-0IlKZJGnSwwTNZA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_Z2NzkIGWEduKE9hnyImx1Q" name="Release Planning" guid="_Z2NzkIGWEduKE9hnyImx1Q" briefDescription="Plan montrant les sprints et les éléments du backlog associés à ces sprints" presentationName="Planning de la release" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
+ <presentation xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" href="uma://-EmLqiNX2WnmsfEtxNiuyTQ#-EmLqiNX2WnmsfEtxNiuyTQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_kftWoIHqEduFs9jH8xc4xw" name="Sprint" guid="_kftWoIHqEduFs9jH8xc4xw" presentationName="Sprint">
+ <presentation xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" href="uma://-fcoz1Nm_QnX6xtLg5YWdVg#-fcoz1Nm_QnX6xtLg5YWdVg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_AIB9gIHrEduFs9jH8xc4xw" name="Release" guid="_AIB9gIHrEduFs9jH8xc4xw" presentationName="Release">
+ <presentation xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" href="uma://-XPyPmZTAVbnvJVuOLvYpXw#-XPyPmZTAVbnvJVuOLvYpXw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_aeYKoIKlEduQgtHqedKdMA" name="Theme" guid="_aeYKoIKlEduQgtHqedKdMA" presentationName="Thème">
+ <presentation xmi:id="-GKfSarwQLoaHhoT71FQI8Q" href="uma://-GKfSarwQLoaHhoT71FQI8Q#-GKfSarwQLoaHhoT71FQI8Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_HQEP8ILXEduLd8CaF_IcMA" name="Velocity" guid="_HQEP8ILXEduLd8CaF_IcMA" presentationName="Vélocité">
+ <presentation xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" href="uma://-PeP4fADValHXs2Z2Z8zJ1w#-PeP4fADValHXs2Z2Z8zJ1w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3qdXkILXEduLd8CaF_IcMA" name="Timebox" guid="_3qdXkILXEduLd8CaF_IcMA" presentationName="Bloc de temps">
+ <presentation xmi:id="-tHVOELWOQDI7i0M2rlMufQ" href="uma://-tHVOELWOQDI7i0M2rlMufQ#-tHVOELWOQDI7i0M2rlMufQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_X5rREILYEduLd8CaF_IcMA" name="Burndown Chart" guid="_X5rREILYEduLd8CaF_IcMA" presentationName="Graphe de tendance">
+ <presentation xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" href="uma://-KQ4Jzjy6YgAr_2NXa4J67g#-KQ4Jzjy6YgAr_2NXa4J67g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Roadmap" xmi:id="_6Jox0IRuEduo75chJsIcXg" name="Application" guid="_6Jox0IRuEduo75chJsIcXg" briefDescription="Appliquer Scrum sans oublier les principes" presentationName="Appliquer Scrum">
+ <presentation xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" href="uma://-IPxNSDzXKWa-H_kJ2PMtYA#-IPxNSDzXKWa-H_kJ2PMtYA"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_SqGkoABREdu3o4yroaI-tA" name="Général" guid="_SqGkoABREdu3o4yroaI-tA">
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_wz30kABREdu3o4yroaI-tA" name="Introduction" guid="_wz30kABREdu3o4yroaI-tA" briefDescription="Bienvenue dans Scrum !" presentationName="Introduction">
+ <presentation xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" href="uma://-WfzsSn3X35gSHQZ2kqtoVw#-WfzsSn3X35gSHQZ2kqtoVw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_N8zs0AEGEduzRosbOajx7w" name="Copyright" guid="_N8zs0AEGEduzRosbOajx7w" presentationName="Copyright">
+ <presentation xmi:id="-03XtfjRMEs23qIdCSSQiNQ" href="uma://-03XtfjRMEs23qIdCSSQiNQ#-03XtfjRMEs23qIdCSSQiNQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_PTGe4IRvEduo75chJsIcXg" name="Scrum references" guid="_PTGe4IRvEduo75chJsIcXg" presentationName="Références">
+ <presentation xmi:id="-cfa6bdUgQuboNpJRKaCLAw" href="uma://-cfa6bdUgQuboNpJRKaCLAw#-cfa6bdUgQuboNpJRKaCLAw"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3erfpYEdqsc-f87sBK8A" name="CapabilityPatterns" guid="_mQ3erfpYEdqsc-f87sBK8A"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3ervpYEdqsc-f87sBK8A" name="DeliveryProcesses" guid="_mQ3ervpYEdqsc-f87sBK8A">
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_9llsAAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3er_pYEdqsc-f87sBK8A" name="ProcessContributions" guid="_mQ3er_pYEdqsc-f87sBK8A"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/roles/Product Owner.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/roles/Product Owner.xmi
new file mode 100644
index 0000000..8a24545
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/roles/Product Owner.xmi
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-35iKPqDM2F2PjKWQLCW4tA" name="Product Owner,_ICJyYPpaEdqsc-f87sBK8A" guid="-35iKPqDM2F2PjKWQLCW4tA" authors="Claude Aubry" changeDate="2006-12-06T09:55:24.078+0100" version="1.0.0">
+ <mainDescription><p>
+ Le Directeur de produit (<i>Product Owner</i>) est le représentant des clients et utilisateurs dans l'équipe.
+</p>
+<p>
+ A ce titre, il est responsable de définir les caractéristiques du produit développé par l'équipe en termes de :
+</p>
+<ul>
+ <li>
+ <strong>fonctionnalités</strong> offertes. Plus précisément il identifie chaque exigence que doit&nbsp;satisfaire
+ le produit comme un&nbsp;<a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;(ou item). Il fournit les détails sur ces
+ exigences quand c'est nécessaire pour l'équipe. Il est souhaitable qu'il spécifie&nbsp;les tests d'acceptation
+ (acceptance tests) de chaque exigence.
+ </li>
+ <li>
+ <strong>priorité</strong>. C'est lui qui définit l'ordre dans lequel ces éléments seront développés en fonction de
+ la valeur qu'ils apportent aux clients et utilisateurs. Cela permet d'alimenter l'équipe avec un <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;prêt pour la planification des sprints,
+ </li>
+ <li>
+ <strong>but</strong>. C'est lui définit l'objectif d'une release et qui prend les décisions concernant le <a
+ class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><p>
+ Son implication est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il&nbsp;donne
+ l'impulsion à l'équipe. En promouvant à l'extérieur le résultat de chaque sprint, il fournit à l'équipe une
+ reconnaissance qui la motive.
+</p></keyConsiderations>
+ <skills><p>
+ Une personne qui joue ce rôle devrait posséder les compétences suivantes :
+</p>
+<ul>
+ <li>
+ bonne connaissance du domaine métier,
+ </li>
+ <li>
+ capacité à avoir une position respectée par tous les intervenants extérieurs (clients et utilisateurs),
+ </li>
+ <li>
+ capacité à prendre une décision au bon moment (pas trop tôt ni trop tard),
+ </li>
+ <li>
+ esprit ouvert au changement,
+ </li>
+ <li>
+ facilité à communiquer avec l'équipe.
+ </li>
+</ul>
+<p>
+ Quelqu'un qui a été Analyste Métier (Business Analyst) est un bon candidat pour ce rôle.
+</p></skills>
+ <assignmentApproaches><p>
+ Il n'y a qu'une seule personne qui joue ce rôle. Cette personne doit être affectée au projet (le Directeur de produit
+ fait partie de l'équipe étendue et participe aux réunions). Le travail nécessite une affectation à plein temps ou
+ presque.
+</p>
+<p>
+ Il est&nbsp;important qu'il soit très disponible pour répondre aux questions de l'équipe, pour définir les tests
+ fonctionnels et&nbsp;donner son avis sur divers aspects du produit (l'interface homme machine d'un logiciel, par
+ exemple).
+</p></assignmentApproaches>
+ <synonyms>Propriétaire de produit (product owner en anglais),&nbsp;Client (dans XP)</synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/roles/ScrumMaster.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/roles/ScrumMaster.xmi
new file mode 100644
index 0000000..84b2974
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/roles/ScrumMaster.xmi
@@ -0,0 +1,122 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" name="new_role,_t1K9kPpYEdqsc-f87sBK8A" guid="-Y3SFEe-A-lRF8TaEn9vKNQ" authors="Claude Aubry" changeDate="2007-01-08T17:37:05.421+0100" version="1.0.0">
+ <mainDescription><p>
+ Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome
+ et à s'améliorer constamment.
+</p>
+<p>
+ Pour cela, il effectue les travaux suivants :&nbsp;
+</p>
+<ul>
+ <li>
+ tâches périodiques,&nbsp;dont l'objectif est de mettre en application Scrum en organisant et animant le&nbsp;<a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>&nbsp;(réunions)&nbsp;:
+ <ul>
+ <li>
+ Mêlée quotidienne.
+ </li>
+ <li>
+ Planification du sprint
+ </li>
+ <li>
+ Revue du sprint
+ </li>
+ <li>
+ Rétrospective
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâches sur évènement
+ <ul>
+ <li>
+ éliminer les obstacles&nbsp;: prendre en compte les évènements qui surviennent à tout moment sur un projet
+ pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures
+ </li>
+ </ul>
+ </li>
+ <li>
+ tâche de fond
+ <ul>
+ <li>
+ faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les
+ éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .
+ </li>
+ </ul>
+ </li>
+</ul>
+<p>
+ Analogies
+</p>
+<ul>
+ <li>
+ Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de
+ ScrumMaster.
+ </li>
+ <li>
+ Ken Schwaber compare le ScrumMaster à un chien de berger.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><ul>
+ <li>
+ Ce n'est pas un chef de projet&nbsp;: il ne dirige pas, il n'impose pas, il ne contraint pas.
+ </li>
+ <li>
+ Il fait partie de l'équipe&nbsp;: il s'engage avec les autres.
+ </li>
+ <li>
+ Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.
+ </li>
+</ul></keyConsiderations>
+ <skills><p>
+ Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est
+ préférable de posséder les compétences suivantes pour jouer&nbsp;ce rôle :
+</p>
+<ul>
+ <li>
+ bien connaître Scrum,
+ </li>
+ <li>
+ avoir des facilités de présentation, de communication et de négociation,
+ </li>
+ <li>
+ guider sans imposer,
+ </li>
+ <li>
+ faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
+ </li>
+ <li>
+ savoir résoudre les conflits et les problèmes,
+ </li>
+ <li>
+ communiquer honnêtement sur le degré d'avancement,
+ </li>
+ <li>
+ garder le respect de l'objectif essentiel, qui est de livrer un produit qui remplit&nbsp;ses exigences.
+ </li>
+</ul>
+<p>
+ En revanche il n'est pas nécessaire de :
+</p>
+<ul>
+ <li>
+ avoir de l'expérience du domaine de l'application (pas indispensable, mais ça peut aider),
+ </li>
+ <li>
+ avoir des compétences techniques sur le développement.
+ </li>
+</ul></skills>
+ <assignmentApproaches><p>
+ Pour une équipe Scrum typique (de 6 à 10 personnes) , une seule personne joue ce rôle sur un projet.
+</p>
+<p>
+ Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela
+ doit rester limité.
+</p></assignmentApproaches>
+ <synonyms><p>
+ Facilitateur de processus. On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela
+ ne favorise pas la compréhension du rôle.
+</p></synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/roles/StakeHolder.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/roles/StakeHolder.xmi
new file mode 100644
index 0000000..a1ded05
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/roles/StakeHolder.xmi
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" name="StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A" guid="-u0-b4PNo9XzOh1-dv_aaKA" authors="Claude Aubry" changeDate="2006-12-03T09:39:26.078+0100" version="1.0.0">
+ <mainDescription><p>
+ Un intervenant ne fait pas partie de l'équipe, mais il est intéressé par le produit réalisé. Il peut avoir une
+ influence sur le déroulement du projet. Il participe à des réunions Scrum : voir sa contribution au <a
+ class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
+ guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>.
+</p>
+<p>
+ Dans son jargon, Scrum appelle&nbsp;les personnes jouant ce rôle&nbsp;des poules (chicken) et conseille de protéger
+ l’équipe, constituée des cochons (pigs), de leur influence directe sur le projet pendant un sprint. Cela signifie que
+ les intervenants ont des fenêtres d'intervention qui sont strictement définies afin de ne pas perturber le travail de
+ l'équipe.
+</p></mainDescription>
+ <synonyms><p>
+ Partie-prenante (Stakeholder en anglais)
+</p></synonyms>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/roles/Team.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/roles/Team.xmi
new file mode 100644
index 0000000..91e38f6
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/roles/Team.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-LVZG5zK2YjEGXO3SwDmqug" name="Team,_9apLsPpaEdqsc-f87sBK8A" guid="-LVZG5zK2YjEGXO3SwDmqug" authors="Claude Aubry" changeDate="2006-12-03T09:36:21.984+0100" version="1.0.0">
+ <mainDescription><p>
+ Une équipe regroupe des membres qui forment un tout soudé capable de réaliser les différentes tâches sur
+ lesquelles&nbsp;elle s’engage collectivement lors de chaque sprint.
+</p>
+<p>
+ Elle possède la latitude voulue pour déterminer ce qui doit être fait afin d’atteindre le but fixé du sprint. Elle
+ s’organise de façon autonome et planifie ses propres travaux, sans se les faire imposer.
+</p></mainDescription>
+ <keyConsiderations>Par son approche centrée sur le collectif,&nbsp;l'agilité contribue à améliorer la camaraderie dans l’équipe.</keyConsiderations>
+ <skills>L’équipe doit être capable de réaliser les différentes tâches sur lesquelles elle s'engage lors de la planification du
+sprint. Cela signifie qu'elle doit être multi-fonctionnelle (cross-functional) pour couvrir les travaux d'analyse, de
+conception, de codage, de test et autres.</skills>
+ <assignmentApproaches>Une équipe Scrum comprend généralement de&nbsp;3 à 10 personnes.</assignmentApproaches>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/roles/resources/148-le-role-de-scrummaster.html b/Scrum/Scrum_baseline_FR/library/Scrum/roles/resources/148-le-role-de-scrummaster.html
new file mode 100644
index 0000000..83644c8
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/roles/resources/148-le-role-de-scrummaster.html
@@ -0,0 +1,296 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html lang="fr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
+<head>
+
+
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+
+
+
+
+
+ <meta name="MSSmartTagsPreventParsing" content="TRUE">
+ <link rel="previous" href="http://www.aubryconseil.com/dotclear/index.php/2007/01/05/146-inscription-technorati" title="Inscription Technorati">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-projets" title="Mes projets">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Evenements" title="Mes événements">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-conseils" title="Mes conseils">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-cours" title="Mes cours">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-france" title="L'agilité en France">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-dans-le-monde" title="L'agilité dans le monde">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-dehors-du-logiciel" title="L'agilité en dehors du logiciel">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-butinage" title="Mon butinage">
+<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-blog" title="Mon blog">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2007/01" title="janvier 2007">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/12" title="décembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/11" title="novembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/10" title="octobre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/09" title="septembre 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/08" title="août 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/07" title="juillet 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/06" title="juin 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/05" title="mai 2006">
+<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/04" title="avril 2006">
+ <link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.aubryconseil.com/dotclear/rss.php">
+ <link rel="alternate" type="application/xml" title="Atom" href="http://www.aubryconseil.com/dotclear/atom.php">
+ <meta name="DC.title" content="Scrum - Méthodes agiles"><title>Le rôle de ScrumMaster - Scrum - Méthodes agiles</title><!--
+<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
+<rdf:Description
+ rdf:about="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
+ dc:identifier="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
+ dc:title="Le rôle de ScrumMaster"
+ trackback:ping="http://www.aubryconseil.com/dotclear/tb.php?id=148" />
+</rdf:RDF>
+-->
+
+
+
+<link rel="stylesheet" type="text/css" href="148-le-role-de-scrummaster.css" media="all"></head><body>
+
+<div id="page">
+
+<div id="top">
+ <h1><a indepth="true" href="index.html">Scrum - Méthodes agiles</a></h1>
+</div>
+
+<p id="prelude"><a href="#main">Aller au contenu</a> |
+<a href="#sidebar">Aller au menu</a> |
+<a href="#search">Aller à la recherche</a></p>
+
+<div id="main">
+ <div id="content">
+
+<div class="post">
+ <h2 class="post-title">Le rôle de ScrumMaster</h2>
+ <p class="post-info">
+<!--
+claude aubry,
+-->
+ dimanche 7 janvier 2007 à 16:08 <span>::</span> <a indepth="true" href="mes-conseils.html">Mes conseils</a>
+ <span>::</span> <a indepth="true" href="148-le-role-de-scrummaster.html" title="Lien permanent vers : Le rôle de ScrumMaster">#148</a>
+ <span>::</span> <a href="http://www.aubryconseil.com/dotclear/rss.php?type=co&post=148" title="fil RSS des commentaires de : Le rôle de ScrumMaster">rss</a>
+ </p>
+
+ <div class="post-chapo"><p>Un résumé du rôle de ScrumMaster, l'animateur d'une équipe qui applique Scrum.</p></div> <div class="post-content"><h5>Synonymes</h5>
+<ul>
+<li>Facilitateur de processus.</li>
+<li>On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela ne favorise pas la compréhension du rôle <sup>[<a href="#pnote-148-1" id="rev-pnote-148-1">1</a>]</sup>.</li>
+</ul>
+<h5>Analogies</h5>
+<ul>
+<li>Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de ScrumMaster.</li>
+<li>Ken Schwaber compare le ScrumMaster à un chien de berger.</li>
+</ul>
+<h5>Responsabilité</h5>
+
+<p>Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome et à s'améliorer constamment.</p>
+
+
+<h5>Tâches</h5>
+<ul>
+<li>tâches périodiques : mettre en application Scrum en organisant et animant les réunions :
+<ul>
+<li>Mêlée quotidienne.</li>
+<li>Planification du sprint</li>
+<li>Revue du sprint</li>
+<li>Rétrospective</li>
+</ul></li>
+<li>tâches sur évènement
+<ul>
+<li>éliminer les obstacles : prendre en compte les évènements qui surviennent à tout moment sur un projet pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures</li>
+</ul></li>
+<li>tâche de fond
+<ul>
+<li>faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .</li>
+</ul></li>
+</ul>
+
+<h5>Compétences</h5>
+
+<p>Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est préférable de posséder les compétences suivantes pour jouer ce rôle :</p>
+<ul>
+<li>bien connaitre Scrum,</li>
+<li>avoir des facilités de présentation, de communication et de négociation,</li>
+<li>guider sans imposer,</li>
+<li>faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,</li>
+<li>savoir résoudre les conflits et les problèmes,</li>
+<li>communiquer honnêtement sur le degré d'avancement,</li>
+<li>garder le respect de l'objectif essentiel, qui est de livrer un produit qui apporte de la valeur avec une utilisation optimale des ressources.</li>
+</ul>
+
+<p>En revanche il n'est pas nécessaire de :</p>
+<ul>
+<li>avoir de l'expérience du domaine de l'application <sup>[<a href="#pnote-148-2" id="rev-pnote-148-2">2</a>]</sup>,</li>
+<li>avoir des compétences techniques sur le développement logiciel.</li>
+</ul>
+
+<h5>Affectation</h5>
+
+
+<p>Pour une équipe Scrum typique <sup>[<a href="#pnote-148-3" id="rev-pnote-148-3">3</a>]</sup>, une seule personne joue ce rôle sur un projet.</p>
+
+
+<p>Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela doit rester limité.</p>
+
+<h5>Points clés</h5>
+<ul>
+<li>Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas.</li>
+<li>Il fait partie de l'équipe : il s'engage avec les autres.</li>
+<li>Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.</li>
+</ul>
+<div class="footnotes"><h4>Notes</h4>
+<p>[<a href="#rev-pnote-148-1" id="pnote-148-1">1</a>] voir sur ce sujet <a href="http://agilitateur.azeau.com/index.php?itemid=61" hreflang="fr">le billet de l'Agilitateur</a></p>
+<p>[<a href="#rev-pnote-148-2" id="pnote-148-2">2</a>] ce n'est pas indispensable, mais ça peut aider</p>
+<p>[<a href="#rev-pnote-148-3" id="pnote-148-3">3</a>] de 6 à 10 personnes</p></div></div>
+
+
+</div>
+
+<div id="trackbacks">
+ <h3 id="tb">Rétroliens</h3>
+ <p>Aucun rétrolien.</p>
+
+
+
+ <p>Pour faire un rétrolien sur ce billet :
+ http://www.aubryconseil.com/dotclear/tb.php?id=148</p>
+ </div>
+
+<div id="comments">
+ <h3 id="co">Commentaires</h3>
+ <p>Aucun commentaire pour le moment.</p>
+
+
+
+ <h3>Ajouter un commentaire</h3>
+ <form action="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" method="post" id="comment-form">
+<fieldset>
+ <p class="field"><label for="c_nom">Nom ou pseudo :</label>
+ <input name="c_nom" id="c_nom" size="30" maxlength="255" value="" type="text">
+ </p>
+
+ <p class="field"><label for="c_mail">Email (facultatif) :</label>
+ <input name="c_mail" id="c_mail" size="30" maxlength="255" value="" type="text">
+ </p>
+
+ <p class="field"><label for="c_site">Site Web (facultatif) :</label>
+ <input name="c_site" id="c_site" size="30" maxlength="255" value="http://" type="text">
+ </p>
+
+ <p class="field"><label for="c_content">Commentaire :</label>
+ <textarea name="c_content" id="c_content" cols="35" rows="7"></textarea>
+ </p>
+</fieldset>
+
+<p class="form-help">Le code HTML dans le commentaire sera affiché comme du texte,
+les adresses internet seront converties automatiquement.</p>
+
+<fieldset>
+ <p><input id="c_remember" name="c_remember" type="checkbox">
+ <label for="c_remember">Se souvenir de mes informations</label>
+ </p>
+ <p><input class="preview" name="preview" value="prévisualiser" type="submit">
+ <input class="submit" value="envoyer" type="submit">
+ <input name="redir" value="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" type="hidden"></p>
+</fieldset>
+
+</form>
+ </div>
+ </div>
+</div>
+
+ <div id="sidebar">
+
+
+ <div id="presentation"><h2></h2><p>Dans ce blog ma contribution à la diffusion de Scrum à travers mes expériences en tant que <a href="http://www.aubryconseil.com/">consultant</a> et comme enseignant à l'<a href="http://www.iup-ups.ups-tlse.fr/isi/" hreflang="fr">IUP ISI</a> <br>
+Claude Aubry</p>
+ <a indepth="true" href="contact.html">Page contact</a>
+ </div>
+
+ <div id="connexes">
+ <h2>Scrum</h2>
+
+ <ul><li><a indepth="true" href="scrum_001.html">Introduction à Scrum</a>
+</li><li><a indepth="true" href="mon-offre-scrum.html">Essayer Scrum</a>
+</li><li><a indepth="true" href="icescrum.html">IceScrum</a>
+</li><li><a indepth="true" href="liens-scrum.html">Plus d'infos sur Scrum</a>
+</li></ul> </div>
+
+
+
+ <div id="tags">
+ <h2>Tags</h2>
+
+ <ul id="tagcloud"><li class="level-2"><a indepth="true" href="agilite.html">agilité</a> </li><li class="level-1"><a indepth="true" href="backlog.html">backlog</a> </li><li class="level-1"><a indepth="true" href="blog.html">blog</a> </li><li class="level-1"><a indepth="true" href="conference.html">conférence</a> </li><li class="level-1"><a indepth="true" href="contrat.html">contrat</a> </li><li class="level-1"><a indepth="true" href="dotclear.html">dotclear</a> </li><li class="level-1"><a indepth="true" href="epf.html">EPF</a> </li><li class="level-1"><a indepth="true" href="equipe.html">equipe</a> </li><li class="level-2"><a indepth="true" href="estimation.html">estimation</a> </li><li class="level-1"><a indepth="true" href="fac.html">fac</a> </li><li class="level-1"><a indepth="true" href="formation.html">formation</a> </li><li class="level-1"><a indepth="true" href="humour.html">humour</a> </li><li class="level-2"><a indepth="true" href="icescrum_001.html">icescrum</a> </li><li class="level-1"><a indepth="true" href="mesures.html">mesures</a> </li><li class="level-1"><a indepth="true" href="moi.html">moi</a> </li><li class="level-1"><a indepth="true" href="musique.html">musique</a> </li><li class="level-1"><a indepth="true" href="openup.html">OpenUP</a> </li><li class="level-1"><a indepth="true" href="outils.html">outils</a> </li><li class="level-2"><a indepth="true" href="planification.html">planification</a> </li><li class="level-2"><a indepth="true" href="processus.html">processus</a> </li><li class="level-1"><a indepth="true" href="presentation.html">présentation</a> </li><li class="level-1"><a indepth="true" href="release.html">release</a> </li><li class="level-1"><a indepth="true" href="rugby.html">rugby</a> </li><li class="level-1"><a indepth="true" href="retrospective.html">rétrospective</a> </li><li class="level-1"><a indepth="true" href="roles.html">rôles</a> </li><li class="level-5"><a indepth="true" href="scrum.html">scrum</a> </li><li class="level-1"><a indepth="true" href="sigmat.html">sigmat</a> </li><li class="level-1"><a indepth="true" href="tdd.html">tdd</a> </li><li class="level-1"><a indepth="true" href="techno.html">techno</a> </li><li class="level-2"><a indepth="true" href="tendances.html">tendances</a> </li><li class="level-1"><a indepth="true" href="traduction.html">traduction</a> </li><li class="level-1"><a indepth="true" href="uml.html">UML</a> </li><li class="level-2"><a indepth="true" href="user-stories.html">user stories</a> </li><li class="level-1"><a indepth="true" href="vision.html">vision</a> </li><li class="level-1"><a indepth="true" href="xp.html">xp</a> </li></ul> </div>
+
+ <div id="syndicate">
+ <h2>Syndication</h2>
+ <a href="http://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fwww.aubryconseil.com%2Fdotclear"><img src="add2netvibes.gif" alt="Add to Netvibes" height="17" width="91"></a>
+ <ul>
+ <li><a href="http://www.aubryconseil.com/dotclear/rss.php">fil rss</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/rss.php?type=co">fil rss commentaires</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/atom.php">fil atom</a></li>
+ <li><a href="http://www.aubryconseil.com/dotclear/atom.php?type=co">fil atom commentaires</a></li>
+ </ul>
+ </div>
+
+ <div id="calendar">
+ <h2>Calendrier</h2>
+ <table summary="Calendrier">
+<caption><a indepth="true" href="12.html" title="décembre 2006">«</a> janvier 2007</caption><thead><tr><th scope="col"><abbr title="lundi">lun</abbr></th><th scope="col"><abbr title="mardi">mar</abbr></th><th scope="col"><abbr title="mercredi">mer</abbr></th><th scope="col"><abbr title="jeudi">jeu</abbr></th><th scope="col"><abbr title="vendredi">ven</abbr></th><th scope="col"><abbr title="samedi">sam</abbr></th><th scope="col"><abbr title="dimanche">dim</abbr></th></tr></thead>
+<tbody><tr><td><a indepth="true" href="01.html">1</a></td><td><a indepth="true" href="02.html">2</a></td><td>3</td><td><a indepth="true" href="04.html">4</a></td><td><a indepth="true" href="05.html">5</a></td><td>6</td><td class="active"><a indepth="true" href="07.html">7</a></td></tr>
+<tr><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td><td>13</td><td>14</td></tr>
+<tr><td>15</td><td>16</td><td>17</td><td>18</td><td>19</td><td>20</td><td>21</td></tr>
+<tr><td>22</td><td>23</td><td>24</td><td>25</td><td>26</td><td>27</td><td>28</td></tr>
+<tr><td>29</td><td>30</td><td>31</td><td> </td><td> </td><td> </td><td> </td></tr>
+</tbody>
+</table> </div>
+
+ <div id="search">
+ <form action="http://www.aubryconseil.com/dotclear/index.php/" method="get">
+
+ <h2><label for="q">Rechercher</label></h2>
+ <p class="field"><input name="q" id="q" size="10" value="" accesskey="4" type="text">
+ <input class="submit" value="ok" type="submit"></p>
+
+ </form>
+ </div>
+
+ <div id="selection"><h2>À retenir</h2><ul><li><a indepth="true" href="148-le-role-de-scrummaster.html">Le rôle de ScrumMaster</a></li><li><a indepth="true" href="132-le-role-de-directeur-de-produit.html">Le rôle de directeur de produit</a></li><li><a indepth="true" href="125-scrum-en-bref.html">Scrum en bref</a></li><li><a indepth="true" href="115-backlog-priorise.html">Backlog : critères pour établir les priorités</a></li><li><a indepth="true" href="99-discipline-et-agilite.html">Discipline et agilité</a></li><li><a indepth="true" href="87-duree-fixe-des-iterations.html">Durée fixe des itérations</a></li><li><a indepth="true" href="67-la-minute-ideale-du-randonneur.html">La minute idéale du randonneur</a></li><li><a indepth="true" href="58-agilite-pour-un-contrat-au-forfait.html">Agilité pour un contrat au forfait</a></li><li><a indepth="true" href="36-avant-la-premiere-iteration.html">Avant la première itération</a></li><li><a indepth="true" href="29-duree-d-une-iteration.html">Durée d'une itération</a></li></ul></div>
+
+ <div id="toclink">
+<h2><a indepth="true" href="toc.html">Table des matières</a></h2>
+</div>
+
+
+
+ <div id="archives">
+ <h2>Archives</h2>
+ <ul><li><strong><a indepth="true" href="01_001.html">janvier 2007</a></strong></li><li><a indepth="true" href="12.html">décembre 2006</a></li><li><a indepth="true" href="11.html">novembre 2006</a></li><li><a indepth="true" href="10.html">octobre 2006</a></li><li><a indepth="true" href="09.html">septembre 2006</a></li><li><a indepth="true" href="08.html">août 2006</a></li><li><a indepth="true" href="07_001.html">juillet 2006</a></li><li><a indepth="true" href="06.html">juin 2006</a></li><li><a indepth="true" href="05_001.html">mai 2006</a></li><li><a indepth="true" href="04_001.html">avril 2006</a></li></ul> </div>
+
+ <div id="links">
+ <h2>Blogs lus régulièrement</h2>
+ <h3>Agile</h3><ul><li><a href="http://agilitateur.azeau.com/" hreflang="fr">L'Agilitateur</a></li><li><a href="http://kanemar.wordpress.com/" hreflang="EN">Kane Mar</a></li><li><a href="http://silkandspinach.net/" hreflang="EN">Silk and Spinach</a></li><li><a href="http://www.testing.com/cgi-bin/blog" hreflang="en">Exploration Through Example</a></li><li><a href="http://www.agileadvice.com/" hreflang="EN">Agile Advice</a></li><li><a href="http://theagileblog.net/" hreflang="en">On Be(come)ing Agile</a></li><li><a href="http://bossavit.com/thoughts/" hreflang="EN" rel="co-worker">Laurent Bossavit</a></li><li><a href="http://prog13.free.fr/" hreflang="fr">Avangel</a></li><li><a href="http://tcros.blogspot.com/" hreflang="fr">Thierry Cros</a></li></ul><h3>Techno</h3><ul><li><a href="http://www.dotnetguru2.org/proques/" hreflang="fr" title="Le blog de Pascal Roques">UML Guru</a></li><li><a href="http://www.inherence.fr/dotclear/" hreflang="fr">Parlons ISO 20000</a></li><li><a href="http://nauges.typepad.com/my_weblog/" hreflang="fr">Louis Naugès</a></li><li><a href="http://standblog.org/blog/" hreflang="fr">StandBlog</a></li></ul> </div>
+
+ <div id="categories">
+ <h2>Catégories</h2>
+ <ul><li><a indepth="true" href="mes-projets.html">Mes projets</a></li><li><a indepth="true" href="evenements.html">Mes événements</a></li><li><a indepth="true" href="mes-conseils.html">Mes conseils</a></li><li><a indepth="true" href="mes-cours.html">Mes cours</a></li><li><a indepth="true" href="l-agilite-en-france.html">L'agilité en France</a></li><li><a indepth="true" href="l-agilite-dans-le-monde.html">L'agilité dans le monde</a></li><li><a indepth="true" href="l-agilite-en-dehors-du-logiciel.html">L'agilité en dehors du logiciel</a></li><li><a indepth="true" href="mon-butinage.html">Mon butinage</a></li><li><a indepth="true" href="mon-blog.html">Mon blog</a></li></ul> </div>
+
+
+
+
+</div><p id="footer">Le blog de Claude Aubry est <a href="http://www.dotclear.net/">
+propulsé par DotClear</a></p>
+
+</div>
+<!-- end #page -->
+
+<!-- Blocs en plus pour ajouter des images en tout genre si besoin -->
+<div id="block1"><span></span></div><div id="block2"><span></span></div>
+<div id="block3"><span></span></div><div id="block4"><span></span></div>
+<div id="block5"><span></span></div><div id="block6"><span></span></div>
+
+
+
+</body></html>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/rolesets/Scrum Roles.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/rolesets/Scrum Roles.xmi
new file mode 100644
index 0000000..8542e8b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/rolesets/Scrum Roles.xmi
@@ -0,0 +1,13 @@
+<?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" epf:version="1.0.0" xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" name="new_role_set,_3qmmoP-zEdqLnajTSLeAsA" guid="-CgLjZ6Bwc0EyYyQCjzlw7g" changeDate="2006-12-03T08:51:09.000+0100">
+ <mainDescription><p>
+ Scrum définit uniquement 3 rôles pour les personnes qui participent aux travaux de développement. A la différence
+ d’autres processus, il n’existe pas d’architecte, de programmeur, de testeur, d’analyste, de rédacteur. L’équipe
+ regroupe les compétences sans distinction du rôle de chacun a priori.
+</p>
+<p>
+ Toutes les personnes ayant une influence sur&nbsp;le projet sans y participer directement sont représentées par le rôle
+ <a class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/scrum.jpg b/Scrum/Scrum_baseline_FR/library/Scrum/scrum.jpg
new file mode 100644
index 0000000..5fe67e3
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/scrum.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Initiate Product Backlog.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Initiate Product Backlog.xmi
new file mode 100644
index 0000000..3563196
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Initiate Product Backlog.xmi
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" name="Initiate Product Backlog,_BGFMoANkEduYd-55D-Aiqg" guid="-mi1O4H7RRm0YqlUNyp8TJg" authors="Claude Aubry" changeDate="2006-12-03T09:00:53.343+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Le backlog initial doit permettre de planifier au moins les 2 ou 3 premiers sprints.
+</p></keyConsiderations>
+ <sections xmi:id="_pWL_gAPJEdubhrgDuRb4fA" name="Collecter les éléments du backlog" guid="_pWL_gAPJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;établit une première liste des exigences (une
+ exigence&nbsp;devient un&nbsp;<a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>)&nbsp;qu'il souhaite voir réalisées pour la fin de la
+ release.
+</p>
+<p>
+ Pour compléter cette liste et obtenir un backlog suffisant, il est conseillé d'organiser un workshop réunissant toute
+ l'équipe plus des intervenants. Au cours de ce workshop, le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a>&nbsp;présente son ébauche de backlog et chacun intervient pour proposer de nouveaux items.
+</p>
+<p>
+ Il est fréquent qu'un élément du backlog soit identifié&nbsp;comme une histoire d'utilisateur (User story), technique
+ utilisée à l'origine dans EXtreme Programming (XP) et qui s'adapte très bien&nbsp;à Scrum.
+</p>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_u0Z7sAPJEdubhrgDuRb4fA" name="Ordonner le backlog" guid="_u0Z7sAPJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;ordonne les éléments du backlog selon une priorité
+ décroissante. Pour lui, A plus prioritaire que B signifie qu'il souhaite disposer, dans un produit partiel, de l'item A
+ avant l'item B.
+</p>
+<p>
+ Lorsque le backlog contient beaucoup d'éléments, le classement par priorité de chacun est fastidieux et délicat. C'est
+ pourquoi il est utile de définir des <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Theme,_aeYKoIKlEduQgtHqedKdMA.html"
+ guid="_aeYKoIKlEduQgtHqedKdMA">Thème</a>s, d'associer à&nbsp;chaque élément un thème et de définir les&nbsp;priorités
+ sur les thèmes avant de passer aux éléments. Cela peut être fait lors d'une réunion à laquelle participent les <a
+ class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
+ guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>s, ainsi que des membres de l'équipe.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de produire un backlog au moins suffisant pour permettre le démarrage de la série des sprints.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Manage problems.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Manage problems.xmi
new file mode 100644
index 0000000..3cbc0ce
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Manage problems.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-mZfAV7RcWJlp5idlHzeEcA" name="Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A" guid="-mZfAV7RcWJlp5idlHzeEcA" changeDate="2006-12-03T10:05:51.734+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Cette tâche est centrée sur la résolution de ces problèmes.
+</p></keyConsiderations>
+ <sections xmi:id="_LCxqQAB6EduSVaTQTBfIHA" name="Prendre connaissance du problème" guid="_LCxqQAB6EduSVaTQTBfIHA">
+ <sectionDescription><p>
+ La réunion quotidienne est l'endroit idéal pour déceler les problèmes qu'une équipe rencontre. Elle peut même permettre
+ de les résoudre immédiatement grâce à la collaboration de l'équipe. Cependant :
+</p>
+<ul>
+ <li>
+ il arrive que des problèmes urgents soient soulevés entre 2 réunions quotidiennes
+ </li>
+ <li>
+ et surtout la résolution des problèmes n'est pas faite en réunion (sauf si elle évidente)
+ </li>
+</ul>
+<p>
+ Suite à la mise en évidence d'un problème, par exemple lors de la réunion quotidienne,&nbsp;identifier la cause du
+ problème et les impacts sur le projet. Pour cela une communication orale, à l'initiative&nbsp;du&nbsp;<a
+ class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>,&nbsp;avec la personne qui a soulevé le problème est souhaitable.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_PIKyUAB6EduSVaTQTBfIHA" name="Décider d'un plan d'action" guid="_PIKyUAB6EduSVaTQTBfIHA">
+ <sectionDescription><p>
+ Identifier les solutions possibles.<br />
+ Une réunion avec le responsable hiérarchique est organisée si des problèmes survenant sur le projet ne peuvent pas
+ être réglés simplement ou sont à un niveau au-dessus de son autorité.
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>&nbsp;doit s'efforcer de résoudre le problème au plus tôt, pour ne pas
+ perturber l'avancement de l'équipe.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de d'éliminer les problèmes rencontrés par l'équipe pour qu'elle puisse se concentrer sur ses véritables
+objectifs.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Plan release.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Plan release.xmi
new file mode 100644
index 0000000..6c78f3b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Plan release.xmi
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-3f4axrWBKHGv74oKN2x-gQ" name="Plan release,_ho-aIP_BEdqtbrr0B1TG-A" guid="-3f4axrWBKHGv74oKN2x-gQ" changeDate="2006-12-03T09:23:18.328+0100" version="1.0.0">
+ <keyConsiderations>Il s'agit d'un travail collectif à l'initiative du directeur de produit.</keyConsiderations>
+ <sections xmi:id="_8qN08APJEdubhrgDuRb4fA" name="Définir les conditions de succès de la release" guid="_8qN08APJEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il existe 2 types de releases&nbsp; :
+</p>
+<ul>
+ <li>
+ une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
+ une date fixée.
+ </li>
+ <li>
+ une release dirigée par les fonctionnalités. La liste des exigences est connue et la release prendra fin lorsque
+ toutes les exigences seront réalisées.
+ </li>
+</ul>
+<p>
+ Les conditions de succès sont définies en fonction de ce type de release.
+</p>
+<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_BuXEQAPKEdubhrgDuRb4fA" name="Estimer les éléments du backlog" guid="_BuXEQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
+</p>
+<p>
+ L'estimation est réalisée en équipe.
+</p>
+<p>
+ La grandeur utilisée pour les estimations est de préférence le point, sans unités. Pour les valeurs utilisées pour les
+ estimations, on utilise souvent la suite de Fibonacci (1, 2, 3, 5, 8 et 13).
+</p>
+<p>
+ Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
+ de pratiquer le "planning poker" et de travailler par analogie en comparant les éléments estimés.&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_EaLKQAPKEdubhrgDuRb4fA" name="Définir la durée des sprints" guid="_EaLKQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Historiquement dans Scrum, la durée d'un sprint est de 30 jours. Cependant il est possible et même recommandé de faire
+ des sprints plus courts. La durée dépend du projet et des contraintes qui s'y appliquent.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_HDZ2UAPKEdubhrgDuRb4fA" name="Estimer la vélocité" guid="_HDZ2UAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa <a class="elementLink"
+ href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;réelle. Elle sera alors utilisée pour cette release, éventuellement
+ ajustée compte tenu de la nature du projet. Attention cependant un point n'a pas forcément la même valeur dans des
+ projets différents.
+</p>
+<p>
+ Si ce n'est pas le cas, il faut faire une estimation de la vélocité. Le mieux est de travailler sur le contenu du
+ premier sprint de la release et de voir ce que l'équipe pense pouvoir réaliser pendant ce premier sprint. Cela donne
+ une vélocité estimée qui peut être utilisée pour la planification de la release. Ensuite la planification sera basée
+ sur la vélocité mesurée dans les sprints précédents.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_I71XkAPKEdubhrgDuRb4fA" name="Associer les éléments du backlog aux sprints" guid="_I71XkAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ En fonction des paramètres suivants :
+</p>
+<ul>
+ <li>
+ les estimations de chaque item,
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité),
+ </li>
+ <li>
+ la vélocité estimée pour la release,
+ </li>
+</ul>
+<p>
+ on affecte les items aux sprints de la release.
+</p>
+<p>
+ Il est normal d'ajuster, c'est à dire de changer légèrement l'ordre des items, ne serait-ce que pour se rapprocher le
+ plus possible de la vélocité (en effet on ne tombe pas toujours "rond").
+</p>
+<p>
+ Il faut associer des items aux premiers sprints (les 2 ou 3 premiers), mais il n'est pas indispensable de le faire pour
+ tous les sprints de la release.
+</p></sectionDescription>
+ </sections>
+ <purpose><p>
+ Elaborer la planification initiale de la release permettant de lancer la série de sprints.
+</p></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Plan sprint 2.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Plan sprint 2.xmi
new file mode 100644
index 0000000..f745cf2
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Plan sprint 2.xmi
@@ -0,0 +1,105 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-NRwwk6YGAtu25V3Lc04G6w" name="Plan sprint,_4LOggPpaEdqsc-f87sBK8A" guid="-NRwwk6YGAtu25V3Lc04G6w" authors="Claude Aubry" changeDate="2006-12-03T09:57:11.890+0100" version="1.0.0">
+ <keyConsiderations><p>
+ La réunion de planification de sprint est un travail réalisé en groupe.
+</p>
+<p>
+ Elle est limitée dans le temps :
+</p>
+<ul>
+ <li>
+ durée max : limitée à 4 heures
+ </li>
+ <li>
+ durée moyenne : 2 heures
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_TJNsUP--Edqtbrr0B1TG-A" name="Définir le but du sprint" guid="_TJNsUP--Edqtbrr0B1TG-A">
+ <sectionDescription><p>
+ Au début lors des premiers sprints de la première release d'un produit, le but est bien souvent de montrer la
+ faisabilité de l'architecture envisagée.
+</p>
+<p>
+ Ensuite, une fois que l'architecture est stabilisée, le but d'un sprint est proposé par le <a class="elementLink"
+ href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+ Produit</a> et discuté avec l'équipe. Il porte souvent sur un thème fonctionnel.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_xvy5UAPKEdubhrgDuRb4fA" name="Sélectionner les items" guid="_xvy5UAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il s'agit de définir le périmètre de ce sprint. Cela est fait en associant un <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;au sprint puis un autre en tenant compte de la
+ vélocité de l'équipe.
+</p>
+<p>
+ Si un <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;a été effectué, cette étape consiste seulement à valider
+ collectivement le sous-ensemble du backlog prévu pour ce sprint.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_p4C0sP--Edqtbrr0B1TG-A" name="Identifier les tâches à partir des items" guid="_p4C0sP--Edqtbrr0B1TG-A">
+ <sectionDescription><p>
+ La 2ème partie de la réunion a pour objectif de définir comment l’équipe va s’arranger pour réaliser le résultat
+ attendu du sprint.<br />
+ Pour cela, chaque <a class="elementLink"
+ href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;sélectionné est décomposé en tâches. Cela permet
+ à toute l’équipe de discuter et d’éclaircir des points de solution par rapport à cet item, en demandant si nécessaire
+ au propriétaire de produit des précisions sur le comportement du produit.<br />
+</p>
+<p>
+ Normalement l'ensemble des activités du cycle de vie sont déroulées lors d'un sprint :<br />
+</p>
+<ul>
+ <li>
+ Les exigences sélectionnées sont spécifiées
+ </li>
+ <li>
+ L'architecture est remaniée si nécessaire
+ </li>
+ <li>
+ Les classes et sous-systèmes sont conçus, implémentés et testés
+ </li>
+ <li>
+ Les différents composants sont intégrés et testés
+ </li>
+ <li>
+ Le produit est packagé&nbsp;
+ </li>
+ <li>
+ Les tests d'acceptation sont passés.<br />
+ </li>
+</ul>
+<p>
+ L'importance donnée à ces activités dépend de la place du sprint dans la release.<br />
+ <br />
+ Le travail prévu dans un sprint précédent mais qui n'a pu être réalisé à cause de la réduction des objectifs devient
+ prioritaire pour le sprint suivant.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_DxNQUAPLEdubhrgDuRb4fA" name="Estimer les tâches" guid="_DxNQUAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Les taches sont estimées en heures. Il est conseillé d'avoir des tâches suffisamment fines pour qu'une estimation reste
+ inférieure à 16 heures.
+</p>
+<p>
+ L'estimation est faite collectivement, par l'équipe. Au cours de la discussion pour arriver à une estimation, les
+ aspects techniques sont abordés.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_worbAP--Edqtbrr0B1TG-A" name="Attribuer les tâches" guid="_worbAP--Edqtbrr0B1TG-A">
+ <sectionDescription>Une fois que les activités du sprint ont été définies, elles seront affectées aux membres de l'équipe. Les activités
+peuvent être réalisées par une ou plusieurs personnes. Toutes les activités doivent être prises en compte, y compris les
+réunions de travail (hors réunions Scrum), les lectures de documents ou de code.<br />
+Il est préférable de différer l'affectation de certaines activités, qui seront prises pendant le sprint en fonction des
+disponibilités des membres de l'équipe.</sectionDescription>
+ </sections>
+ <sections xmi:id="_Iq14wAPLEdubhrgDuRb4fA" name="Obtenir l'engagement de l'équipe" guid="_Iq14wAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Il est souhaitable que l'équipe s'engage collectivement sur le backlog du sprint, c'est à dire sur les éléments du
+ backlog qu'elle estime pouvoir réaliser dans le sprint.
+</p></sectionDescription>
+ </sections>
+ <purpose>Le but est de planifier&nbsp;le sprint&nbsp;qui commence.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Retrospective.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Retrospective.xmi
new file mode 100644
index 0000000..243a584
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Retrospective.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-S4qXwp40l_8eCcyyI7o-3A" name="Retrospective,_J_sRIP_AEdqtbrr0B1TG-A" guid="-S4qXwp40l_8eCcyyI7o-3A" changeDate="2006-12-03T10:01:12.593+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé.
+</p>
+<ul>
+ <li>
+ durée max : 2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_lwzeABGPEduHloEV5-Zv-w" name="Discussion" guid="_lwzeABGPEduHloEV5-Zv-w">
+ <sectionDescription>Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé dans l'application de Scrum sur le
+projet.</sectionDescription>
+ </sections>
+ <sections xmi:id="_noL2YBGPEduHloEV5-Zv-w" name="Définir le plan d'actions" guid="_noL2YBGPEduHloEV5-Zv-w">
+ <sectionDescription><p>
+ L’équipe discute des améliorations possibles et leur donne une priorité.
+</p>
+<p>
+ Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
+ guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a> ajoute les actions d’amélioration dans le backlog.
+</p></sectionDescription>
+ </sections>
+ <purpose>L’objectif est d'améliorer continuellement le processus.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Review sprint.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Review sprint.xmi
new file mode 100644
index 0000000..a63b191
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Review sprint.xmi
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-zoJryMCuHfxWP7Q5Er195Q" name="Review sprint,_MRrRYPpbEdqsc-f87sBK8A" guid="-zoJryMCuHfxWP7Q5Er195Q" changeDate="2006-12-03T09:52:13.953+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Travail en groupe (lors de la réunion dite de revue de sprint)
+</p>
+<p>
+ Pour la réunion :
+</p>
+<ul class="noindent">
+ <li>
+ durée max : &nbsp;2 heures
+ </li>
+ <li>
+ durée moyenne : 1 heure
+ </li>
+</ul></keyConsiderations>
+ <sections xmi:id="_XL6VgAPLEdubhrgDuRb4fA" name="Préparer la démonstration" guid="_XL6VgAPLEdubhrgDuRb4fA">
+ <sectionDescription>La préparation de la réunion ne doit pas excéder une heure.<br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_ZgJB8APLEdubhrgDuRb4fA" name="Effectuer la démonstration" guid="_ZgJB8APLEdubhrgDuRb4fA">
+ <sectionDescription>L’équipe présente le produit partiel résultat de ses travaux, sous forme de démonstration des exigences (histoires
+d'utilisateur) réalisées. Seules les exigences complètement finies (et testées) sont présentées. Cela permet d’avoir une
+mesure objective de l’avancement. <br /></sectionDescription>
+ </sections>
+ <sections xmi:id="_cBouUAPLEdubhrgDuRb4fA" name="Evaluer les résultats du sprint" guid="_cBouUAPLEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
+ guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> et les intervenants présents (clients, utilisateurs) posent des
+ questions à l’équipe, donnent leur impression, font des propositions et des demandes de changement. Le <a
+ class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
+ guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;est enrichi avec les bugs découverts et les demandes
+ d’évolution.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_hrswoHoYEduJVrY6eKG_mw" name="Calculer la vélocité réelle" guid="_hrswoHoYEduJVrY6eKG_mw">
+ <sectionDescription><p>
+ La <a class="elementLink" href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
+ guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;du sprint&nbsp;est obtenue en faisant la somme de tous les points
+ associés aux exigences considérées comme effectivement finies. Elle est comparée à celle des sprints précédents, le
+ plus souvent à travers un <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>.&nbsp;&nbsp;
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_d776UHoYEduJVrY6eKG_mw" name="Ajuster le plan de la release" guid="_d776UHoYEduJVrY6eKG_mw">
+ <sectionDescription><p>
+ Les conditions ont pu changer depuis la dernière planification de la release :
+</p>
+<ul>
+ <li>
+ des items ont pu être ajoutés ou suppirmés, les estimations modifiées,&nbsp;
+ </li>
+ <li>
+ l'ordre dans lesquels les items sont classés (la priorité) a pu être modifié,
+ </li>
+</ul>
+<p>
+ De plus la vélocité&nbsp;moyenne a pu évoluer avec la prise de la vélocité calculée du sprint.&nbsp;
+</p>
+<p>
+ Le <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
+ guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> est ajusté en tenant compte de ces nouveaux paramètres.
+</p></sectionDescription>
+ </sections>
+ <purpose>&nbsp;Le but est de montrer les exigences réalisées pendant le sprint par une démonstration du produit partiel</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Scrum daily meeting.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Scrum daily meeting.xmi
new file mode 100644
index 0000000..f9cd5b0
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Scrum daily meeting.xmi
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-vDOuVl_xPKipKd90HQNZng" name="Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A" guid="-vDOuVl_xPKipKd90HQNZng" changeDate="2006-12-03T10:07:26.890+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Se déroule tous les jours, avec toute l'équipe, de préférence le matin en arrivant : il est souhaitable que la réunion
+ ait lieu tous les jours au même endroit et à la même heure.
+</p>
+<p>
+ La réunion est limitée à 15 minutes.&nbsp;<br />
+ L’objectif est d’examiner l’avancement des travaux et d'identifier les problèmes potentiels, mais pas de résoudre les
+ problèmes
+</p></keyConsiderations>
+ <sections xmi:id="_oUrlcBGOEduHloEV5-Zv-w" name="Préparer" guid="_oUrlcBGOEduHloEV5-Zv-w">
+ <sectionDescription>Chacun met à jour le planning ( le backlog se sprint) en actualisant le reste à faire sur ses tâches, ce qui permet de
+produire un <a class="elementLink"
+href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>.</sectionDescription>
+ </sections>
+ <sections xmi:id="_r0KkEBGOEduHloEV5-Zv-w" name="Se réunir" guid="_r0KkEBGOEduHloEV5-Zv-w">
+ <sectionDescription><p>
+ Chaque membre de l’équipe s’exprime tour à tour, en répondant à 3 questions sur :
+</p>
+<ol>
+ <li>
+ Ce qui a été fait depuis la mêlée précédente (en principe la veille)
+ </li>
+ <li>
+ Ce qui va être fait aujourd’hui
+ </li>
+ <li>
+ Les problèmes rencontrés&nbsp;
+ </li>
+</ol>
+<p>
+ Il est souhaitable que la réunion s'effectue avec tous les personnes de l'équipe debout en cercle et en ayant sous les
+ yeux le <a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+ guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;et le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>&nbsp;actualisés.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_vZkkgBGOEduHloEV5-Zv-w" name="Consolider" guid="_vZkkgBGOEduHloEV5-Zv-w">
+ <sectionDescription>Le&nbsp;<a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
+guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;remis à jour sert à prendre une décision sur l'ajustement du but
+du sprint. Il faut avoir à l'esprit qu'un sprint est limité dans le temps (bloc de temps) et qu'il est préférable de
+supprimer du contenu prévu initialement plutôt que d'avoir du retard. <br />
+Les problèmes soulevés sont résolus&nbsp;lors de&nbsp;<a class="elementLink"
+href="./../../Scrum/tasks/Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A.html" guid="_Xpd5gP_AEdqtbrr0B1TG-A">Gérer les
+problèmes</a>&nbsp;à l'initiative du <a class="elementLink"
+href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html" guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>.</sectionDescription>
+ </sections>
+ <purpose>Le but est de faire le point sur l'avancement de l'équipe et d'identifier les problèmes. L’objectif est uniquement
+d’examiner l’avancement des travaux, pas de résoudre les problèmes.</purpose>
+ <alternatives><p>
+ Appelé aussi Stand-Up Meeting (XP)
+</p></alternatives>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Update product backlog.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Update product backlog.xmi
new file mode 100644
index 0000000..af19cc7
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/tasks/Update product backlog.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-XdgedeazfFRGDxMY3Fnh5g" name="Manage product backlog,_STkWYP_BEdqtbrr0B1TG-A" guid="-XdgedeazfFRGDxMY3Fnh5g" changeDate="2006-12-03T09:12:31.968+0100" version="1.0.0">
+ <keyConsiderations><p>
+ Pendant le sprint, personne ne peut modifier la sélection des items du backlog effectuée au début du sprint : le
+ périmètre du sprint reste inchangé.
+</p>
+<p>
+ En revanche, n’importe qui, même un intervenant extérieur, peut proposer de nouveaux items pour plus tard. Ces items
+ sont étudiés et ordonnés par le propriétaire du produit en vue de la planification du prochain sprint.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p></keyConsiderations>
+ <sections xmi:id="_c3HaQAPKEdubhrgDuRb4fA" name="Collecter les changements" guid="_c3HaQAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ N’importe qui, même un intervenant extérieur, peut proposer des changements à ajouter au backlog.<br />
+ Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
+ également enrichir le backlog.
+</p>
+<p>
+ Ces éléments sont analysés par le propriétaire du produit en vue de la planification du prochain sprint.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_fkXDoAPKEdubhrgDuRb4fA" name="Réordonner les items" guid="_fkXDoAPKEdubhrgDuRb4fA">
+ <sectionDescription>Les éléments ajoutés depuis le sprint précédent sont ordonnés dans le backlog par le&nbsp;<a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
+en vue de la planification à venir.</sectionDescription>
+ </sections>
+ <sections xmi:id="_k-kCgAPKEdubhrgDuRb4fA" name="Réestimer les items" guid="_k-kCgAPKEdubhrgDuRb4fA">
+ <sectionDescription><p>
+ L'estimation en points des nouveaux éléments introduits dans le backlog est faite par l'équipe, de préférence lors d'un
+ travail de groupe avec le Directeur de prouit, un ou 2 jours avant la revue de fin de sprint.
+</p>
+<p>
+ Des items déjà présents peuvent également être réestimés.
+</p></sectionDescription>
+ </sections>
+ <purpose>Actualiser le backlog et ajuster la planification en tenant compte des changements apparus depuis le dernier sprint.</purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product Backlog Item.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product Backlog Item.xmi
new file mode 100644
index 0000000..adf4810
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product Backlog Item.xmi
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" name="new_artifact,_-D85cIGIEduKE9hnyImx1Q" guid="-KC1R73i9f6P7ZT4pgBOLzA" changeDate="2006-12-01T23:15:03.002+0100">
+ <mainDescription>C'est une exigence fonctionnelle ou non fonctionnelle (technique), une demande d'évolution, un bug ou tout autre
+chose&nbsp;dont la réalisation apporte de la valeur au <a class="elementLink"
+href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
+Produit</a>.&nbsp;
+<p>
+ Il possède des attributs qui sont généralement :
+</p>
+<ul>
+ <li>
+ une estimation de sa valeur qui est le plus souvent montrée de façon relative aux autres éléments par la notion de
+ priorité,
+ </li>
+ <li>
+ une estimation de son coût de développement,
+ </li>
+ <li>
+ éventuellement le thème (domaine fonctionnel) dont il fait partie,
+ </li>
+ <li>
+ éventuellement son type (défini en fonction du projet, par exemple histoire d'utilisateur, bug, exigence non
+ fonctionnelle),
+ </li>
+</ul>
+<p>
+ Si on utilise la technique des histoires d'utilisateur (user stories) et le développement dirigé par les tests (TDD),
+ on associe les critères servant aux tests d'acceptation de cet élément.
+</p>
+<p>
+ La vie d'un PBI passe par les états suivants :
+</p>
+<ul class="noindent">
+ <li>
+ créé
+ </li>
+ <li>
+ estimé
+ </li>
+ <li>
+ planifié (associé à un&nbsp;sprint futur
+ </li>
+ <li>
+ associé au sprint courant (on le réalise)
+ </li>
+ <li>
+ réalisé
+ </li>
+ <li style="list-style: none">
+ <br />
+ </li>
+</ul></mainDescription>
+ <keyConsiderations>Le principe de Scrum est de finir complètement un PBI dans un sprint.</keyConsiderations>
+ <externalId>PBI</externalId>
+ <purpose>Sert à la gestion de projet : il sera placé dans un sprint</purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product Backlog.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product Backlog.xmi
new file mode 100644
index 0000000..4d8cb72
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product Backlog.xmi
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" name="Product Backlog,_5ABscPpYEdqsc-f87sBK8A" guid="-Of1SdnAQ9nmsL5DFvD2Uug" authors="Claude AUbry" changeDate="2006-12-03T09:31:43.140+0100" version="1.0.0">
+ <mainDescription><p>
+ Le backlog du produit est le référentiel des exigences. Il contient des éléments du backlog (appelés aussi des items de
+ backlog de produit).
+</p>
+<p>
+ Sa vie est liée à celle du produit.
+</p></mainDescription>
+ <purpose>Lister toutes les choses à faire&nbsp;du point de vue du client (le quoi)</purpose>
+ <impactOfNotHaving>Obligatoire</impactOfNotHaving>
+ <briefOutline>Visible par tous, il est mis à jour régulièrement. Il est présenté à la revue de planification du sprint et, une fois
+accepté, la partie contenant les exigences allouées au sprint courant est gelée.</briefOutline>
+ <representationOptions><ul>
+ <li>
+ Cartes (story cards)
+ </li>
+ <li>
+ Feuille d'un tableur
+ </li>
+ <li>
+ Outil IceScrum&nbsp;
+ </li>
+ <li>
+ Base de données
+ </li>
+</ul></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product increment.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product increment.xmi
new file mode 100644
index 0000000..bc47bed
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Product increment.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-6aCUL_kawJFNBtfH_sRXkw" name="Product increment,_tCmYEP-xEdqLnajTSLeAsA" guid="-6aCUL_kawJFNBtfH_sRXkw" changeDate="2006-12-03T10:04:18.218+0100" version="1.0.0">
+ <mainDescription><p>
+ Le résultat principal d'un sprint est le produit partiel qui réalise, en plus de ce qui existait au début du
+ sprint,&nbsp;les exigences supplémentaires réalisées pendant ce sprint.
+</p>
+<p>
+ On peut&nbsp;trouver 3 utilisations -après la démonstration lors de la revue de sprintes- du produit partiel obtenu en
+ fin d'itération&nbsp;:
+</p>
+<ul>
+ <li>
+ il n'est pas utilisé en dehors de l'équipe. Il a été produit pour chercher à minimiser les risques liés à la
+ technologie et à la capacité de l'équipe à intégrer pour produire un <q>build</q>. Cela arrive surtout au début
+ d'un nouveau produit.
+ </li>
+ <li>
+ il est utilisé par des clients privilégiés, en plus du directeur produit. Cela leur donne la possibilité de jouer
+ avec, ce qui permet de réduire les risques portant sur l'IHM liées à la facilité d'utilisation des fonctionnalités.
+ Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
+ </li>
+ <li>
+ il est mis en production ou en exploitation et utilisé par ses utilisateurs finals. C'est évidemment ce qu'il faut
+ viser puisque chaque nouvelle version apporte de la valeur. Autant l'apporter le plus tôt possible, dès qu'elle est
+ disponible. Mais ce n'est généralement pas possible de mettre en production à la fin de chaque sprint : trop de
+ temps serait pris pour passer les tests de recette sur tout le système, déployer sur l'environnement de production,
+ écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs... C'est pourquoi ce travail
+ particulier nécessite souvent une activité de préparation à la mise en production. Mais si on réussit à limiter le
+ temps pour faire tout ça, on peut alors mettre en production plus souvent qu'à la fin des releases.
+ </li>
+</ul>
+<br /></mainDescription>
+ <keyConsiderations><p>
+ Le produit évolue pendant toute sa vie jusqu'à son retrait.
+</p></keyConsiderations>
+ <briefOutline>Le produit partiel peut être déployé dans l'environnement de production&nbsp;ou simplement mis à disposition des
+utilisateurs.</briefOutline>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Sprint Backlog Item.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Sprint Backlog Item.xmi
new file mode 100644
index 0000000..1f7bd5b
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Sprint Backlog Item.xmi
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" name="new_artifact,_9C78MIHnEdu3SZQ-Dp1OAA" guid="-6UJtuFO3WFBFpJOFeV1QMQ" changeDate="2006-12-02T10:38:33.140+0100">
+ <mainDescription><p>
+ Chaque tâche possède les attributs suivants :
+</p>
+<ul>
+ <li>
+ l'estimation du temps à passer pour finir la tâche. Les efforts sont estimés, par l’équipe, en heures sur une
+ échelle qui varie habituellement de 1à 16 heures. Les tâches plus grandes devraient être décomposées. L’estimation
+ du reste à faire est réactualisée tous les jours.
+ </li>
+ <li>
+ l'<a class="elementLink" href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
+ guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;à l'origine de cette tâche
+ </li>
+ <li>
+ la personne qui prend en compte cette tâche<br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Sprint backlog.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Sprint backlog.xmi
new file mode 100644
index 0000000..da5b496
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/Sprint backlog.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" name="Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A" guid="-8V2DOvzUhvtqwWvTOHMB5g" changeDate="2006-12-03T10:17:45.781+0100" version="1.0.0">
+ <mainDescription><p>
+ Il&nbsp;contient la liste des tâches que l’équipe s’engage à faire afin de compléter les éléments de backlog de produit
+ sélectionnés pour ce sprint.<br />
+ L’équipe peut modifier une tâche, la supprimer ou en ajouter de nouvelles : il est courant que des tâches apparaissent
+ lors du sprint.
+</p></mainDescription>
+ <purpose>Il&nbsp;décrit l'ensemble des&nbsp;tâches d'un sprint, avec les ressources qui y sont affectées et le travail qui reste à
+faire. C'est un plan qui porte sur des tâches détaillées, il est dit à "mailles fines".</purpose>
+ <impactOfNotHaving>Obligatoire</impactOfNotHaving>
+ <briefOutline><p>
+ C'est un outil de communication essentiel qui aide à gérer le sprint. Il doit être facilement mis à jour et rester
+ visible à toute l'équipe.
+</p></briefOutline>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/resources/EtatsPBI.jpg b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/resources/EtatsPBI.jpg
new file mode 100644
index 0000000..4e1e28f
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducts/resources/EtatsPBI.jpg
Binary files differ
diff --git a/Scrum/Scrum_baseline_FR/library/Scrum/workproducttypes/Backlogs.xmi b/Scrum/Scrum_baseline_FR/library/Scrum/workproducttypes/Backlogs.xmi
new file mode 100644
index 0000000..67ae2e4
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/Scrum/workproducttypes/Backlogs.xmi
@@ -0,0 +1,15 @@
+<?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="-eSc2tcV1h17HBw_s8ROEVw" name="Backlogs,_d-yk8ABREdu3o4yroaI-tA" guid="-eSc2tcV1h17HBw_s8ROEVw" changeDate="2006-06-22T22:06:50.327+0200">
+ <mainDescription><p>
+ Les backlogs de Produit et de Sprint sont des éléments de gestion majeurs dans l'utilisation de Scrum.
+</p>
+<p>
+ A partir des backlogs, on produit des rapports comme le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
+ guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>&nbsp;ou le <a class="elementLink"
+ href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
+ guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>
+</p></mainDescription>
+ <keyConsiderations>Un backlog est une liste d'items. Le terme n'est pas traduit en français car il est couramment utilisé dans la communauté
+des développeurs.</keyConsiderations>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum/Scrum_baseline_FR/library/configurations/Scrum.xmi b/Scrum/Scrum_baseline_FR/library/configurations/Scrum.xmi
new file mode 100644
index 0000000..4575445
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/configurations/Scrum.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:MethodConfiguration xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_IqDLgP_OEdqtbrr0B1TG-A" name="Scrum" guid="_IqDLgP_OEdqtbrr0B1TG-A" briefDescription="Le processus Scrum" version="1.0.0">
+ <methodPluginSelection href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eofpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eovpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eo_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ep_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ervpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epvpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3er_pYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqfpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqvpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_rkSgEPpYEdqsc-f87sBK8A"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_SqGkoABREdu3o4yroaI-tA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_37NW8AL_EduOAKqB9I73uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_NSW6sAMAEduOAKqB9I73uw"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_SoXWEAMAEduOAKqB9I73uw"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_s8y1UABREdu3o4yroaI-tA"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_nF6fgALYEduFv7wnrO7SvQ"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_7BSBkABCEduYUKPFgCzFuA"/>
+</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/Scrum/Scrum_baseline_FR/library/library.xmi b/Scrum/Scrum_baseline_FR/library/library.xmi
new file mode 100644
index 0000000..16d6058
--- /dev/null
+++ b/Scrum/Scrum_baseline_FR/library/library.xmi
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_hDRYYfpYEdqsc-f87sBK8A" guid="_hDRYYfpYEdqsc-f87sBK8A">
+ <subManagers xmi:id="_5AUAUPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5AUAUPpYEdqsc-f87sBK8A"/>
+ <resourceDescriptors xmi:id="_hDRYYvpYEdqsc-f87sBK8A" id="_hDRYYPpYEdqsc-f87sBK8A" uri=""/>
+ <resourceDescriptors xmi:id="_mRDr4PpYEdqsc-f87sBK8A" id="_mQ3eoPpYEdqsc-f87sBK8A" uri="Scrum/plugin.xmi"/>
+ <resourceDescriptors xmi:id="_VRheAYPTEdu0eqo2Hxw7OA" id="_VRheAIPTEdu0eqo2Hxw7OA" uri="IceScrum/plugin.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodLibrary xmi:id="_hDRYYPpYEdqsc-f87sBK8A" name="scrum" guid="_hDRYYPpYEdqsc-f87sBK8A">
+ <methodPlugins xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
+ </org.eclipse.epf.uma:MethodLibrary>
+</xmi:XMI>
diff --git a/XP/XP_baseline_EN/exported_HTML/configurations/config_for_xp.html b/XP/XP_baseline_EN/exported_HTML/configurations/config_for_xp.html
new file mode 100644
index 0000000..06f2fa1
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/configurations/config_for_xp.html
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\configurations\config_for_xp.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: config_for_xp.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_mohucGE-EdqnIZeW8YpHcA CRC: 324616930 -->config_for_xp<!-- END:name,_mohucGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/conceptual_road_maps.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/conceptual_road_maps.html
new file mode 100644
index 0000000..c91ae01
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/conceptual_road_maps.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\conceptual_road_maps.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: conceptual_road_maps.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mtDpJGE-EdqnIZeW8YpHcA CRC: 2656238689 -->Conceptual Roadmap<!-- END:presentationName,_mtDpJGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-QcM1bn-XJLcMSggRp54YlQ CRC: 3788131239 --><p class="node">
+
+</p>
+<br />
+<br />
+<br /><!-- END:mainDescription,-QcM1bn-XJLcMSggRp54YlQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/getting_started.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/getting_started.html
new file mode 100644
index 0000000..39dbf81
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/getting_started.html
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\getting_started.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: getting_started.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ms9ig2E-EdqnIZeW8YpHcA CRC: 282220576 -->Getting Started<!-- END:presentationName,_ms9ig2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-MqIvi7DInwjz8kX7QEyU3g CRC: 1756791188 --><h3>
+ <a id="WhatisXP" name="WhatisXP">What is XP?</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. XP is currently one of the
+ most widely used agile processes in the industry.
+</p>
+<p>
+ <img height="540" alt="" src="resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map" border="0" />
+ <map id="xp_practices_image_map" name="xp_practices_image_map">
+ <area shape="RECT" coords="298,19,390,88"
+ href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
+ <area shape="RECT" coords="176,135,282,200"
+ href="./../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
+ <area shape="RECT" coords="297,168,434,231"
+ href="./../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
+ <area shape="RECT" coords="447,135,547,198"
+ href="./../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
+ <area shape="RECT" coords="15,236,122,305"
+ href="./../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
+ <area shape="RECT" coords="218,238,362,307"
+ href="./../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
+ <area shape="RECT" coords="392,241,512,305"
+ href="./../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
+ <area shape="RECT" coords="614,236,714,302"
+ href="./../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
+ <area shape="RECT" coords="143,325,270,393"
+ href="./../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
+ <area shape="RECT" coords="310,321,412,379"
+ href="./../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
+ <area shape="RECT" coords="468,323,597,393"
+ href="./../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
+ <area shape="RECT" coords="307,386,413,436"
+ href="./../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
+ <area shape="RECT" coords="312,475,419,539"
+ href="./../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
+ <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
+ </map>
+</p>
+<p>
+ This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
+ exemplifies the steering and control cycles of the process. For more details, see <a class="elementLinkWithType"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">Concept:
+ XP Practices</a>.
+</p>
+<h2>
+ <a id="Start" name="Start">Where do I start?</a>
+</h2>
+<p>
+ If you are unfamiliar with XP and want to learn more about it, we suggest you take the following steps:
+</p>
+<ul>
+ <li>
+ Get a quick <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html" guid="9.251272550276345E-306">overview
+ of XP</a>.
+ </li>
+ <li>
+ Learn what the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
+ guid="1.6390805262958034E-306">motivation behind XP</a> is.
+ </li>
+ <li>
+ Understand what <a class="elementLink"
+ href="./../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a> means.
+ </li>
+ <li>
+ Take a tour of the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a> and <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>.
+ </li>
+</ul>
+<p>
+ If you are familiar with XP and are interested in trying XP on your RUP project, we simply suggest you start by reading
+ the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/extreme_programming,5.2637267673584526E-306.html"
+ guid="5.2637267673584526E-306">Extreme Programming Roadmap</a>.<br />
+</p>
+<h3>
+ <a id="Who" name="Who">Who is behind the plug-in?</a>
+</h3>
+<p>
+ This plug-in is a collaboration between <a href="http://www.objectmentor.com/" target="_blank">Object Mentor Inc.</a>
+ and <a href="http://www.ibm.com/" target="_blank">IBM Corporation</a>.
+</p><!-- END:mainDescription,-MqIvi7DInwjz8kX7QEyU3g -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/guidelines_overview.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/guidelines_overview.html
new file mode 100644
index 0000000..fbd6b85
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/guidelines_overview.html
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\guidelines_overview.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: guidelines_overview.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,2.0279775416255596E-305 CRC: 1434462586 -->Guidelines Overview<!-- END:presentationName,2.0279775416255596E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-8FSBtYSGN9EGWRr1N6fbPQ CRC: 1760168571 --><p>
+ <b>Guidelines</b> provide practical information about the implementation of specific activities in the process.
+</p><!-- END:mainDescription,-8FSBtYSGN9EGWRr1N6fbPQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/key_xp_concepts.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/key_xp_concepts.html
new file mode 100644
index 0000000..f56a8ab
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/key_xp_concepts.html
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\key_xp_concepts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: key_xp_concepts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.9093436569802954E-305 CRC: 4223452062 -->Key XP Concepts<!-- END:presentationName,1.9093436569802954E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,1.9093436569802954E-305 CRC: 1913873965 -->The following concepts are a good starting point to introduce the "spirit" of XP.<!-- END:briefDescription,1.9093436569802954E-305 -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/references.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/references.html
new file mode 100644
index 0000000..3f39758
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/references.html
@@ -0,0 +1,3478 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\references.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: references.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mtcqtmE-EdqnIZeW8YpHcA CRC: 3494063692 -->References<!-- END:presentationName,_mtcqtmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-a8huB5Sn0Qjfe-SkZubH1w CRC: 2585364322 --><a id="XE_references__bibliography_of" name="XE_references__bibliography_of"></a><a id="XE_bibliography__references_for"
+name="XE_bibliography__references_for"></a>
+<h5>
+ Topics
+</h5>
+<ul>
+ <li>
+ <a href="#Business Modeling references">Business Modeling</a>
+ </li>
+ <li>
+ <a href="#Configuration Management references">Configuration Management</a>
+ </li>
+ <li>
+ <a href="#Miscellaneous references">Miscellaneous</a>
+ </li>
+ <li>
+ <a href="#Modeling and Unified Modeling Language references">Modeling and Unified Modeling Language</a>
+ </li>
+ <li>
+ <a href="#Object-Oriented Technology references">Object-Oriented Technology</a>
+ </li>
+ <li>
+ <a href="#Project Management references">Project Management</a>
+ </li>
+ <li>
+ <a href="#Requirement Management references">Requirements Management</a>
+ </li>
+ <li>
+ <a href="#Software Architecture references">Software Architecture</a>
+ </li>
+ <li>
+ <a href="#Software Development Process references">Software Development Process</a>
+ </li>
+ <li>
+ <a href="#Testing and Quality references">Testing and Quality</a>
+ </li>
+</ul>
+<h2 align="left">
+ <a id="Business Modeling references" name="Business Modeling references">Business Modeling</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BRO95" name="BRO95">BRO95</a>
+ </td>
+ <td colspan="2">
+ Frederick P. Brooks, Jr. 1995. <i>The Mythical Man-Month-Essays on Software Engineering</i> 2nd ed.
+ Reading, MA, Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic that should be read and re-read by everyone involved in software development. We recommend
+ this 20-year anniversary edition rather than the original 1975 edition.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLA97" name="CLA97">CLA97</a>
+ </td>
+ <td colspan="2">
+ Carl von Clausewitz 1997. <i>On War.</i> Wordsworth Editions.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the greatest books ever written on the subject of war, and applicable to the field of
+ management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CHM95" name="CHM95">CHM95</a>
+ </td>
+ <td colspan="2">
+ James Champy 1995. <i>Reengineering Management: The Mandate for New Leadership.</i> New York, NY:
+ HarperCollins.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Gives some insight into the precarious art of managing a business (re-)engineering effort.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DVP93" name="DVP93">DVP93</a>
+ </td>
+ <td colspan="2">
+ Thomas H. Davenport 1993. <i>Process Innovation-Reengineering Work through Information
+ Technology.</i> Boston, MA: Harvard Business School Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Solid and comprehensive introduction about how information technology enables business improvement and
+ (re-)engineering.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAO97" name="GAO97">GAO97</a>
+ </td>
+ <td colspan="2">
+ United States General Accounting Office 1997. <i>Business Process Reengineering Assessment Guide</i>.
+ <a href="http://www.gao.gov" target="_blank">http://www.gao.gov</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Describes a framework for assessing a business (re-)engineering effort.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ERI00" name="ERI00">ERI00</a>
+ </td>
+ <td colspan="2">
+ Hans-Erik Eriksson and Magnus Penker 2000. <i>Business Modeling With UML: Business Patterns at
+ Work. </i>New York, NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Presents a set of valuable patterns for business modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HAM93" name="HAM93">HAM93</a>
+ </td>
+ <td colspan="2">
+ Michael Hammer and James Champy 1993. <i>Reengineering the Corporation-A Manifesto for Business
+ Revolution.</i> <br />
+ New York, NY: HarperBusiness.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The book that popularized the movement of business (re-)engineering. An excellent complement to <i>The
+ Object Advantage-Business Process Reengineering with Object Technology</i> cited above<i>. </i>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HAR91" name="HAR91">HAR91</a>
+ </td>
+ <td colspan="2">
+ H. James Harrington 1991. <i>Business Process Improvement: The Breakthrough Strategy for Total Quality,
+ Productivity, and Competitiveness</i>. New York, NY: McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Another contributor to the topic of business (re-)engineering.<i> </i>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC94" name="JAC94">JAC94</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Maria Ericsson, and Agneta Jacobson 1994. <i>The Object Advantage-Business Process
+ Reengineering with Object Technology</i>. Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The basis of the Business Modeling discipline, this is the very first book that applied object
+ technology to the field of business modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAP96" name="KAP96">KAP96</a>
+ </td>
+ <td colspan="2">
+ Robert Kaplan and David Norton 1996. <i>The Balanced Scorecard</i>. Boston, MA: Harvard Business School
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Best practices for successfully implementing the Balanced Scorecard.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KOT96" name="KOT96">KOT96</a>
+ </td>
+ <td colspan="2">
+ John P. Kotter 1996. <i>Leading Change</i>. Boston, MA: Harvard Business School Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A practical, proven model for planning and managing organizational change.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MARS00" name="MARS00">MARS00</a>
+ </td>
+ <td colspan="2">
+ Chris Marshall 2000. <i>Enterprise Modeling with UML</i>. Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Describes how to create business models that facilitate the development software systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="NDL97" name="NDL97">NDL97</a>
+ </td>
+ <td colspan="2">
+ David A. Nadler and Michael L. Tushman 1999. <i>Competing by Design-the Power of Organizational
+ Architecture.</i> Oxford University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Defines organizational architecture and capabilities as a source of competitive advantage.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="OHM91" name="OHM91">OHM91</a>
+ </td>
+ <td colspan="2">
+ Kenichi Ohmae 1991. <i>The Mind of the Strategist: The Art of Japanese Business.</i> McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A crisp and practical guide to strategic management.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ODL98" name="ODL98">ODL98</a>
+ </td>
+ <td colspan="2">
+ James J. Odell 1998. <i>Advanced Object-Oriented Analysis & Design Using UML.</i> Cambridge
+ University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Provides a good overview, among other things, on the topic of business rules.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PFE99" name="PFE99">PFE99</a>
+ </td>
+ <td colspan="2">
+ Jeffrey Pfeffer and Robert Sutton 1999. <i>The Knowing-Doing Gap.</i> Boston, MA: Harvard
+ Business School Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Discusses the reasons why some organizations do not apply their own lessons learned and provides
+ pointers for how to overcome this challenge.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PLR99" name="PLR99">PLR99</a>
+ </td>
+ <td colspan="2">
+ R. Steven Player (Editor) and David Keys (Editor) 1999. <i>Activity-Based Management: Arthur
+ Andersen's Lessons from the ABM Battlefield.</i> Wiley Cost Management Series.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An introduction to understanding the management of costs, and how to implement activity-based costing
+ (ABC) and activity-based management (ABM) systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="POR98" name="POR98">POR98</a>
+ </td>
+ <td colspan="2">
+ Michael Porter 1998. <i>Competitive Strategy: Techniques for Analyzing Industries and
+ Competitors.</i> Simon & Schuster, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A practical guide for the strategic planner.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROS97" name="ROS97">ROS97</a>
+ </td>
+ <td colspan="2">
+ Ron Ross 1997. <i>The Business Rule Book: Classifying, Defining and Modeling Rules.</i> Boston,
+ MA: Database Research Group.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A complete handbook for the business rules analyst.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SEY98" name="SEY98">SEY98</a>
+ </td>
+ <td colspan="2">
+ Patricia Seybold 1998. <i>Customers.com.</i> Random House Publishing.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ An excellent collection of practical guidelines and case studies on the benefits of e-business and
+ (re-)engineering.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Configuration Management references" name="Configuration Management references">Configuration Management</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BER92" name="BER92">BER92</a>
+ </td>
+ <td colspan="2">
+ H. Berlack 1992. <i>Software Configuration Management.</i> New York, NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BUC93" name="BUC93">BUC93</a>
+ </td>
+ <td colspan="2">
+ J. Buckley 1993. <i>Implementing Configuration Management, Hardware, Software and Firmware.</i>
+ Los Alamitos, CA: IEEE Computer Science Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WHI00" name="WHI00">WHI00</a>
+ </td>
+ <td colspan="2">
+ Brian White and Geoff Glemm 2000. <i>Software Configuration Management Strategies and Rational
+ ClearCase: A Practical Introduction.</i> Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WHI91" name="WHI91">WHI91</a>
+ </td>
+ <td colspan="2">
+ David Whitgift 1991. <i>Methods and Tools for Software Configuration Management.</i> New York,
+ NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2>
+ <a id="Miscellaneous references" name="Miscellaneous references">Miscellaneous</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOU94" name="BOU94">BOU94</a>
+ </td>
+ <td colspan="2">
+ Serge Bouchy 1994. <i>L'ingénierie des systèmes informatiques évolutifs,</i> Paris, France:
+ Eyrolles, 330p.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BRO95" name="BRO95">BRO95</a>
+ </td>
+ <td colspan="2">
+ Frederick P. Brooks, Jr. 1995. <i>The Mythical Man-Month-Essays on Software Engineering</i> 2nd ed.
+ Reading, MA, Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic that should be read and re-read by everyone involved in software development. We recommend
+ this 20-year anniversary edition rather than the original 1975 edition.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="con92" name="con92">CON92</a>
+ </td>
+ <td colspan="2">
+ D. Conner 1992. <i>Managing at the Speed of Change.</i> New York, NY: Random House, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DAT99" name="DAT99">DAT99</a>
+ </td>
+ <td colspan="2">
+ C.J. Date 1999. <i>An Introduction to Database Systems.</i> 7th ed. New York, NY:
+ Addison-Wesley Publishing Company, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Excellent introduction, reference, and source of background information on Database Systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DAV95" name="DAV95">DAV95</a>
+ </td>
+ <td colspan="2">
+ Alan Davis 1995. <i>201 Principles of Software Development.</i> New York, NY: McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Full of good advice for every team member on a project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DEG90" name="DEG90">DEG90</a>
+ </td>
+ <td colspan="2">
+ Peter DeGrace and Leslie Stahl 1990. <i>Wicked Problems, Righteous Solutions: A Catalog of Modern
+ Software Engineering Practices.</i> Englewood Cliffs, NJ: Yourdon Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An insightful book on various process lifecycles and their origins, flaws, and strengths; useful for
+ understanding the importance of process.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DEI84" name="DEI84">DEI84</a>
+ </td>
+ <td colspan="2">
+ Harvey M. Deitel 1984. <i>An Introduction to Operating Systems.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FIS96" name="FIS96">FIS96</a>
+ </td>
+ <td colspan="2">
+ Charles Fishman 1996. <i>Johnson Space Center Shuttle Software Group, "They Write the Right
+ Stuff"</i><i>.</i> Fastcompany, Issue 6, p. 95, December, 1996.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GRA97" name="GRA97">GRA97</a>
+ </td>
+ <td colspan="2">
+ Ian Graham, et al. 1997. <i>The OPEN Process Specification</i>. Harlow, England: Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Another process model, coming from down under that shares some principles with the Rational Unified
+ Process (RUP).
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="hac97" name="hac97">HAC97</a>
+ </td>
+ <td colspan="2">
+ JoAnn T. Hackos and Dawn M. Stevens 1997. <i>Standards for Online Communication.</i> John Wiley and
+ Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ For the modern technical writer, this book has become the defacto standard. It defines a process for
+ developing user manuals, specifically focusing on how you produce online help systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HER99" name="HER99">HER99</a>
+ </td>
+ <td colspan="2">
+ Peter Herzum and Oliver Sims 1999. <i>Business Component Factory: A Comprehensive Overview of
+ Component-Based Development for the Enterprise.</i> John Wiley & Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Defines and describes component-based development-from creating small components to creating
+ federations of large component-based systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM2000
+ </td>
+ <td colspan="2">
+ <i>IBM System Integrated Method.</i> International Business Machines Corporation 1998, 1999, 2000.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM99a
+ </td>
+ <td colspan="2">
+ <i>An Approach to Designing e-business Solutions.</i> International Business Machines Corporation 1999.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <a href="http://www.redbooks.ibm.com/abstracts/sg245949.html"
+ target="_blank">http://www.redbooks.ibm.com/abstracts/sg245949.html</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM99b
+ </td>
+ <td colspan="2">
+ <i>Design Considerations: From Client Server Applications to e-business Applications.</i> International
+ Business Machines Corporation 1999.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <a href="http://www.redbooks.ibm.com/abstracts/sg245503.html"
+ target="_blank">http://www.redbooks.ibm.com/abstracts/sg245503.html</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM99c
+ </td>
+ <td colspan="2">
+ <i>The Front of IBM WebSphere-Building e-business User Interfaces.</i> International Business Machines
+ Corporation 1999.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <a href="http://www.redbooks.ibm.com/abstracts/sg245488.html"
+ target="_blank">http://www.redbooks.ibm.com/abstracts/sg245488.html</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM98a
+ </td>
+ <td colspan="2">
+ <i>Architecture Description Standard: Overview.</i> International Business Machines Corporation
+ 1998.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM98b
+ </td>
+ <td colspan="2">
+ <i>Architecture Description Standard: Semantic Specification.</i> International Business Machines
+ Corporation 1998.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Other relevant Web sites for the preceding IBM references are:<br />
+ <a href="http://www.redbooks.ibm.com" target="_blank">http://www.redbooks.ibm.com<br />
+ </a> <a href="http://www.ibm.com/e-business/" target="_blank">http://www.ibm.com/e-business/<br />
+ </a> <a href="http://www.ibm.com/software" target="_blank">http://www.ibm.com/software<br />
+ </a> <a href="http://www.ibm.com/developer/" target="_blank">http://www.ibm.com/developer/<br />
+ </a> <a href="http://www.ibm.com/services/" target="_blank">http://www.ibm.com/services/</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IBM97" name="IBM97">IBM97</a>
+ </td>
+ <td colspan="2">
+ IBM 1997. <i>Developing Object-Oriented Software</i><i>-</i><i>An Experienced- based Approach.</i>
+ Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Like the RUP, an iterative, incremental, object-oriented, scenario-driven, risk-aware process developed
+ by the IBM Object Technology Center.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IE610.12" name="IE610.12">IE610.12</a>
+ </td>
+ <td colspan="2">
+ IEEE Std 610.12-1990. <i>IEEE Standard Glossary of Software Engineering Terminology.</i> The Institute
+ of Electrical and Electronics Engineers, Inc.: New York, NY, 10017-2394, USA. 1990.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" height="23">
+ <a id="JAV03" name="JAV03">JAV03</a>
+ </td>
+ <td colspan="2">
+ JavaTM 2 Platform, Standard Edition, v 1.4.2 API Specification -
+ http://java.sun.com/j2se/1.4.2/docs/api/index.html
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="jel93" name="jel93">JEL93</a>
+ </td>
+ <td colspan="2">
+ J. Jellison 1993. <i>Overcoming Resistance: A Practical Guide to Producing Change in the
+ Workplace.</i> New York, NY: Simon & Schuster, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAT93" name="KAT93">KAT93</a>
+ </td>
+ <td colspan="2">
+ Jon R. Katzenbach and Douglas K. Smith 1993. <i>The Wisdom of Teams.</i> New York, NY: Harper Business.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The secret of effective teams.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KET98" name="KET98">KET98</a>
+ </td>
+ <td colspan="2">
+ Nasser Kettani, et al. 1998. <i>De Merise à UML.</i> Paris, France: Editions Eyrolles.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Merise is a very popular software development methodology in France, which has been upgraded to use
+ UML. It has some similitude with the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="LEA97" name="LEA97">LEA97</a>
+ </td>
+ <td colspan="2">
+ Doug Lea 1999. <i>Concurrent Programming in Java.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCA95" name="MCA95">MCA95</a>
+ </td>
+ <td colspan="2">
+ Jim McCarthy 1995. <i>Dynamics of Software Development.</i> Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Fifty-three rules of thumb by a Microsoft development manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCO97" name="MCO97">MCO97</a>
+ </td>
+ <td colspan="2">
+ Steve McConnell 1997. <i>Software Project Survival Guide.</i> Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A collection of practical experience on how to deliver successful software projects.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCO93" name="MCO93">MCO93</a>
+ </td>
+ <td colspan="2">
+ Steve McConnell 1993. <i>Code Complete</i><i>-</i><i>A Practical Handbook of Software Construction.</i>
+ Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great book for the implementers and for testers looking at the implementation, integration, and test
+ aspects of the development process.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="mos98" name="mos98">MOS98</a>
+ </td>
+ <td colspan="2">
+ Microsoft 1998. The <i>Microsoft Manual of Style for Technical Publications.</i> Redmond, WA:
+ Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="STA97" name="STA97">STA97</a>
+ </td>
+ <td colspan="2">
+ Jennifer Stapleton 1997. <i>The Dynamic System Development Method.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ At 15,000 feet, the DSDM approach could be seen as an introduction to the RUP. Although they use a
+ different terminology, the two processes are very close to each other, and you can see the RUP as an
+ instance or an implementation of DSDM.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="TAN86" name="TAN86">TAN86</a>
+ </td>
+ <td colspan="2">
+ Andrew S. Tannenbaum 1986. <i>Operating Systems: Design and Implementation. </i> Upper Saddle
+ River, NJ: Prentice Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WID00" name="WID00">WID00</a>
+ </td>
+ <td colspan="2">
+ R. Max Wideman and PMForum, February, 1999 and January, 2000. <i>Wideman Comparative Glossary of
+ Project Management Terms v2.0.</i> www.pmforum.org
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This great collection of various software engineering terms and their many definitions is available
+ online at <a href="http://www.pmforum.org/library/glossary/"
+ target="_blank">http://www.pmforum.org/library/glossary/</a>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="YOU97" name="YOU97">YOU97</a>
+ </td>
+ <td colspan="2">
+ Edward Yourdon 1997. <i>Death March: Managing "Mission Impossible" Projects.</i> Upper Saddle River,
+ NJ: Prentice Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An interesting view on project troubles.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Modeling and Unified Modeling Language references"
+ name="Modeling and Unified Modeling Language references">Modeling and Unified Modeling Language</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="BOO98" name="BOO98">BOO98</a>
+ </td>
+ <td colspan="2">
+ G. Booch, J. Rumbaugh, and I. Jacobson, 1998. <i>UML User Guide</i>. Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Published at the same time as Rational Unified Process 5.1, this book is an excellent user's guide on
+ UML by its main authors.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="CHE01" name="CHE01">CHE01</a>
+ </td>
+ <td colspan="2">
+ John Cheesman and John Daniels, 2001. <i>UML Components: A Simple Process for Specifying
+ Component-Based Software</i>. Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book provides a lot of in-depth practical guidance for specifying component-based systems, at the
+ same time remaining compact and readable.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="CONA99" name="CONA99">CONA99</a>
+ </td>
+ <td colspan="2">
+ Jim Conallen, 1999. <i>Building Web Applications with UML.</i> Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good introduction to the basics of web application development in the context of the RUP. This book
+ also shows how to use the UML to model web applications and introduces a Web Application Extension to
+ the UML.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="DOUG98" name="DOUG98">DOUG98</a>
+ </td>
+ <td colspan="2">
+ Bruce Powel Douglass 1998. <i>Real-Time UML.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Using UML as the notation, this book offers good advice on the application of object-oriented
+ technology for real-time systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ <a id="ERI04" name="ERI04">ERI04</a>
+ </td>
+ <td colspan="2">
+ Hans-Erik Eriksson, Magnus Penker, Brian Lyons and David Fado 2004. <i>UML 2 Toolkit</i>. Indianopolis:
+ Wiley Publishing, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="ERI97" name="ERI97">ERI97</a>
+ </td>
+ <td colspan="2">
+ Hans-Erik Eriksson and Magnus Penker 1997. <i>UML Toolkit</i>. New York: John Wiley & Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A more comprehensive book on UML as seen from Sweden by another pair of Rational friends.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="FOW97" name="FOW97">FOW97</a>
+ </td>
+ <td colspan="2">
+ Martin Fowler 1997. <i>UML Distilled-Applying the standard object modeling language</i>. Addison-Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A very nice little introduction to UML if you're in a hurry.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="FRA03" name="FRA03">FRA03</a>
+ </td>
+ <td colspan="2">
+ David S. Frankel 2003. <i>Model Driven Architecture: Applying MDA to Enterprise Computing.</i> John
+ Wiley & Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+
+ </td>
+ <td>
+
+ </td>
+ <td>
+ A foundational work on the OMG's Model Driven Architecture initiative, written by one of its principal
+ developers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="KLE03" name="KLE03">KLE03</a>
+ </td>
+ <td colspan="2">
+ Anneke Kleppe, Jos Warmer and Wim Bast 2003. <i>MDA Explained-The Model Driven
+ Architecture(TM):Practice and Promise.</i> Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+
+ </td>
+ <td>
+
+ </td>
+ <td>
+ More useful insights into MDA from a practitioner's viewpoint, written by contributors to the creation
+ of MDA.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="LAR02" name="LAR02">LAR02</a>
+ </td>
+ <td colspan="2">
+ Craig Larman 2002. <i>Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
+ Design and the Unified Process,</i> 2nd ed. Prentice-Hall, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book is a great illustration of what happens in the Analysis & Design discipline. It teaches
+ analysis and design, the use of UML, and the application of the concept of pattern in the context of
+ the Unified Process. By presenting the case study in an iterative, risk-driven, architecture-centric
+ process, Mr. Larman's advice has a realistic context. He exposes the dynamics of what really happens in
+ software development and shows the external forces at play. The design activities are connected to
+ other tasks, and they no longer appear as a purely cerebral activity of systematic transformations or
+ creative intuition.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="MEL04" name="MEL04">MEL04</a>
+ </td>
+ <td colspan="2">
+ Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise 2004. <i>MDA Distilled-Principles of
+ Model-Driven Architecture.</i> Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+
+ </td>
+ <td>
+
+ </td>
+ <td>
+ Extracts and presents the essence of MDA, with an emphasis on the technology for executable models.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="MUL98" name="MUL98">MUL98</a>
+ </td>
+ <td colspan="2">
+ Pierre-Alain Muller 1998. <i>Instant UML.</i> Wrox Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Another short introduction to UML by a former colleague.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="NBG01" name="NBG01">NBG01</a>
+ </td>
+ <td colspan="2">
+ Eric J. Naiburg and Robert A. Maksimchuk 2001. <i>UML For Database Design</i>. New York, NY:
+ Addison-Wesley Publishing Company, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+
+ </td>
+ <td width="11%">
+
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Application of UML to database modeling and design. Supported throughout by a case study.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="OMG03" name="OMG03">OMG03</a>
+ </td>
+ <td colspan="2">
+ <i>MDA Guide Version 1.0.1.</i> Object Management Group. Document omg/2003-06-01, June 2003
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+
+ </td>
+ <td>
+
+ </td>
+ <td>
+ <p>
+ A specification of the concepts and terminology of Model Driven Architecture from the OMG.
+ </p>
+ <p>
+ <a href="http://www.omg.org/mda/specs.htm" target="_blank">http://www.omg.org/mda/specs.htm</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="QUA98" name="QUA98">QUA98</a>
+ </td>
+ <td colspan="2">
+ Terry Quatrani 1998. <i>Visual Modeling with Rational Rose and UML.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+
+ </td>
+ <td width="11%">
+
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Provides step-by-step guidance on how to build UML models. At the same time, it follows the RUP, in
+ effect providing a small scale example.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ <a id="RUM05" name="RUM05">RUM05</a>
+ </td>
+ <td colspan="2">
+ James Rumbaugh, Ivar Jacobson, Grady Booch, 2005. <i>The Unified Modeling Language Reference Manual,
+ second edition.</i> Addison-Wesley, Boston.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="RUM98" name="RUM98">RUM98</a>
+ </td>
+ <td colspan="2">
+ J. Rumbaugh, I. Jacobson, and G. Booch, 1998. <i>UML Reference Manual.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Certainly more digestible than the OMG standard; UML fully exposed by its main authors.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="UML01" name="UML01">UML01</a>
+ </td>
+ <td colspan="2">
+ <i>OMG Unified Modeling Language Specification, Version 1.4. </i> Rational Software Corporation,
+ 18880 Homestead Road, Cupertino, CA 95014, and Object Management Group, Inc., 492 Old Connecticut Path,
+ Framingham, MA 01701.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The latest specification of the UML. Available online at <a href="http://www.rational.com/uml"
+ target="_blank">http://www.rational.com/uml</a>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%" height="21">
+ <a id="UML04" name="UML04">UML04</a>
+ </td>
+ <td colspan="2">
+ <i>OMG Unified Modeling Language Specification, Version 2.0. </i> Object Management Group, Inc.,
+ Needham, MA 02494
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Final Adopted Specification (2003-08-02)
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="UML96" name="UML96">UML96</a>
+ </td>
+ <td colspan="2">
+ G. Booch, J. Rumbaugh, and I. Jacobson 1996. <i>The Unified Modeling Language for Object-Oriented
+ Development.</i> Documentation set, version 0.9 Addendum, Rational Software Corporation.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="UML95" name="UML95">UML95</a>
+ </td>
+ <td colspan="2">
+ G. Booch and J. Rumbaugh 1995. <i>Unified Method for Object-Oriented Development.</i> Documentation
+ set, version 0.8, Rational Software Corporation.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Object-Oriented Technology references" name="Object-Oriented Technology references">Object-Oriented
+ Technology</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOO93" name="BOO93">BOO93</a>
+ </td>
+ <td colspan="2">
+ Grady Booch 1993. <i>Object-Oriented Analysis and Design with Applications,</i> 2nd edition. Redwood
+ City, CA: The Benjamin/Cummings Publishing Company.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BUH96" name="BUH96">BUH96</a>
+ </td>
+ <td colspan="2">
+ R. J. A. Buhr and R. S. Casselman 1996. <i>Use Case Maps for Object-Oriented Systems.</i> Upper Saddle
+ River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book develops some other views on use cases.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC92" name="JAC92">JAC92</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, et al. 1992. <i>Object-Oriented Software Engineering-A Use Case-Driven Approach</i>,
+ Wokingham, England: Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="RUM91" name="RUM91">RUM91</a>
+ </td>
+ <td colspan="2">
+ James Rumbaugh, et al. 1991. <i>Object-Oriented Modeling and Design.</i> Upper Saddle River, NJ:
+ Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The three books above are the original roots to the object-oriented analysis and design discipline from
+ "the three amigos", just before the advent of the UML and the RUP. Despite the use of their original
+ notations, they are still the key references for OO designers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="RUM96" name="RUM96">RUM96</a>
+ </td>
+ <td colspan="2">
+ James Rumbaugh 1996. <i>OMT Insights.</i> New York: SIGS Books.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A complement to the original OMT book, diving into special topics: inheritance, use cases, and so
+ on.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SEL94" name="SEL94">SEL94</a>
+ </td>
+ <td colspan="2">
+ Bran Selic, Garth Gullekson, and Paul Ward 1994. <i>Real-time Object-Oriented Modeling.</i> New York,
+ NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The reference work on using object technology for the design of reactive systems by the people who have
+ brought us <i>ObjecTime Developer</i>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WIR90" name="WIR90">WIR90</a>
+ </td>
+ <td colspan="2">
+ Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener 1990. <i>Designing Object-Oriented
+ Software.</i> Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book describes the Class, Responsibility, Collaboration (CRC) approach to object-oriented software
+ development.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Project Management references" name="Project Management references">Project Management</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AMI95" name="AMI95">AMI95</a>
+ </td>
+ <td colspan="2">
+ K. Pulford, A. Kuntzmann-Combelles, and S. Shirlaw 1995. <i>A Quantitative Approach to Software
+ Management-The AMI Handbook.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE00" name="BOE00">BOE00</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm et al, 2000. Software Cost Estimation with COCOMO II. Upper Saddle River, NJ:
+ Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The successor to the original classic work.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE81" name="BOE81">BOE81</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1981. <i>Software Engineering Economics.</i> Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic work on software effort estimation that describes the original COCOMO estimation model.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE91" name="BOE91">BOE91</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1991. <i>Software Risk Management: Principles and Practices</i>, <i>IEEE Software,</i>
+ Jan. 1991, IEEE, pp.32-41.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Still the best little introduction to risk management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOO95" name="BOO95">BOO95</a>
+ </td>
+ <td colspan="2">
+ Grady Booch 1995. <i>Object Solutions-Managing the Object-Oriented Project.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A pragmatic book for managers of object-oriented projects; one of the sources on the underlying
+ philosophy of the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CAN01" name="CAN01">CAN01</a>
+ </td>
+ <td colspan="2">
+ Murray Cantor 2001. <i>Software Leadership.</i> Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CAR93" name="CAR93">CAR93</a>
+ </td>
+ <td colspan="2">
+ Marvin J. Carr, et al. 1993. <i>Taxonomy-Based Risk Identification,</i> Technical Report
+ CMU/SEI-93-TR-6, Pittsburgh, PA, SEI, June 1993, 24p.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Provides a source of inspiration to get started on your own list of risks.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CHA89" name="CHA89">CHA89</a>
+ </td>
+ <td colspan="2">
+ Robert Charette 1989. <i>Software Engineering Risk Analysis and Management.</i> New York, NY:
+ McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Practical perspective on risk management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CHID94" name="CHID94">CHID94</a>
+ </td>
+ <td colspan="2">
+ Chidamber and Kemerer 1994. <i>A metrics suite for object-oriented design,</i> IEEE Transactions on
+ Software Engineering, 20(6), 1994.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the original contributions to the field of OO software metrics.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLE96" name="CLE96">CLE96</a>
+ </td>
+ <td colspan="2">
+ Robert T. Clemen 1996. <i>Making Hard Decisions: An Introduction to Decision Analysis.</i> Duxbury
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Thorough yet accessible treatment of the fundamentals of decision analysis.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DEV95" name="DEV95">DEV95</a>
+ </td>
+ <td colspan="2">
+ Michael T. Devlin and Walker E. Royce. <i>Improving Software Economics in the Aerospace and
+ Defense Industry,</i> Technical Paper TP-46, Santa Clara, CA, Rational Software Corporation, 1995.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="EVA98" name="EVA98">EVA98</a>
+ </td>
+ <td colspan="2">
+ James R. Evans and David L. Olson 1998. <i>Introduction to Simulation and Risk Analysis.</i>
+ Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Good introduction to the use of simulation for business modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FAI94" name="FAI94">FAI94</a>
+ </td>
+ <td colspan="2">
+ Richard Fairley 1994. "Risk Management for Software Project," <i>IEEE Software,</i> 11 (3), May 1994,
+ pp.57-67
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Straightforward strategy for risk management if you have never done this before.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GIL88" name="GIL88">GIL88</a>
+ </td>
+ <td colspan="2">
+ Tom Gilb 1988. <i>Principles of Software Engineering Management.</i> Harlow, England: Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great book by a pioneer of iterative development, it's full of pragmatic advice for the project
+ manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HEND96" name="HEND96">HEND96</a>
+ </td>
+ <td colspan="2">
+ Brian Henderson-Sellers 1996. <i>Object-Oriented Metrics, Measures of Complexity.</i> Prentice Hall
+ PTR.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Good, detailed coverage of OO-specific metrics.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JON94" name="JON94">JON94</a>
+ </td>
+ <td colspan="2">
+ Capers Jones 1994. <i>Assessment and Control of Software Risks.</i> Yourdon Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An indispensable source of risks to check your list against to make sure it's is complete.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAR96" name="KAR96">KAR96</a>
+ </td>
+ <td colspan="2">
+ Dale Karolak 1996. <i>Software Engineering Risk Management.</i> Los Alamitos, CA: IEEE Computer Society
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Offers more sophisticated advice and techniques for risk management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCO96" name="MCO96">MCO96</a>
+ </td>
+ <td colspan="2">
+ Steve McConnell 1996. <i>Rapid Development.</i> Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Excellent coverage of good practice for rapid software development
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MSP97" name="MSP97">MSP97</a>
+ </td>
+ <td colspan="2">
+ User's Guide for Microsoft Project 98, Microsoft Corporation, 1997.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="OCO94" name="OCO94">OCO94</a>
+ </td>
+ <td colspan="2">
+ Fergus O'Connell 1994. <i>How to Run Successful Projects.</i> New York, NY: Prentice-Hall
+ International.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A real gem! Everything you really need to know to manage your first project, in 170 pages.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PMI96" name="PMI96">PMI96</a>
+ </td>
+ <td colspan="2">
+ <i>A Guide to the Project Management Body of Knowledge.</i> The Project Management Institute: Newton
+ Square, PA, 19073-3299, USA. 1996.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PUT92" name="PUT92">PUT92</a>
+ </td>
+ <td colspan="2">
+ Lawrence Putnam & Ware Myers 1992. <i>Measures for Excellence: Reliable Software On Time, Within
+ Budget.</i> Yourdon Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY98" name="ROY98">ROY98</a>
+ </td>
+ <td colspan="2">
+ Walker Royce 1998. <i>Software Project Management: A Unified Framework.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An indispensable companion to the RUP, this book describes the spirit of the Rational Process and its
+ underlying software economics. Full of great advice for the project manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="VOS96" name="VOS96">VOS96</a>
+ </td>
+ <td colspan="2">
+ David Vose 1996. <i>Quantitative Risk Analysis: A Guide to Monte Carlo Simulation Modeling.</i> John
+ Wiley & Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good guide to the modeling of uncertainty using Monte Carlo techniques.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WHIT97" name="WHIT97">WHIT97</a>
+ </td>
+ <td colspan="2">
+ Scott Whitmire 1997. <i>Object-Oriented Design Measurement.</i> John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good, if mathematically challenging, treatment of the theoretical basis of software measurement.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Requirement Management references" name="Requirement Management references">Requirements Management</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AND96" name="AND96">AND96</a>
+ </td>
+ <td colspan="2">
+ Stephen J. Andriole 1996. <i>Managing Systems Requirements: Methods, Tools, and Cases.</i> McGraw Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEY98" name="BEY98">BEY98</a>
+ </td>
+ <td colspan="2">
+ Hugh Beyer and Karen Holtzblatt 1998. <i>Contextual Design.</i> San Francisco, CA: Morgan Kaufmann
+ Publishers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BIT03" name="BIT03">BIT03</a>
+ </td>
+ <td colspan="2">
+ Kurt Bittner and Ian Spence 2003. <i>Use Case Modeling.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Comprehensive coverage of use case techniques and practices, including useful examples showing how
+ use-case specifications evolve over time.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COC01a" name="COC01a">COC01a</a>
+ </td>
+ <td colspan="2">
+ Alistair Cockburn 2001. <i>Writing Effective Use Cases.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Excellent guidance for those who need to write use cases. Multiple styles and techniques contrasted
+ with insight in an unbiased way. Many helpful tips to improve your use cases.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CON99" name="CON99">CON99</a>
+ </td>
+ <td colspan="2">
+ Larry Constantine and Lucy A.D. Lockwood 1999. <i>Software for Use.</i> Reading, MA: Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An excellent book on user-centric design, focusing on techniques and practical guidelines for
+ developing software that is usable.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COO99" name="COO99">COO99</a>
+ </td>
+ <td colspan="2">
+ Alan Cooper1999. <i>The Inmates are Running the Asylum.</i> Indianapolis, IN: SAMS.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DAV93" name="DAV93">DAV93</a>
+ </td>
+ <td colspan="2">
+ Alan Davis 1993. <i>Software Requirements-Objects, Functions and States.</i> Englewood Cliffs, NJ:
+ Prentice Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FIS91" name="FIS91">FIS91</a>
+ </td>
+ <td colspan="2">
+ Roger Fisher and William Ury 1991. <i>Getting to Yes-Negotiating Agreement Without Giving In, 2nd
+ Edition.</i> Penguin Books USA.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAU89" name="GAU89">GAU89</a>
+ </td>
+ <td colspan="2">
+ Donald Gause and Gerald Weinberg 1989. <i>Exploring Requirements-Quality Before Design.</i> New York,
+ NY: Dorset House.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GOU88" name="GOU88">GOU88</a>
+ </td>
+ <td colspan="2">
+ John D. Gould 1988. "How to Design Usable Systems", in Helander, Martin, ed. <i>Handbook of Computer
+ Interaction</i>, pp. 757-789, North-Holland, Amsterdam, The Netherlands.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GOU87" name="GOU87">GOU87</a>
+ </td>
+ <td colspan="2">
+ John D. Gould, Stephen J. Boies, Stephen Levy, John T. Richards and Jim Schoonard 1987. "The 1984
+ Olympic Message System: a test of behavioral principles of system design", in <i>Communications of the
+ ACM</i>, Vol. 30, No. 9, pp. 758-769.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GRA92" name="GRA92">GRA92</a>
+ </td>
+ <td colspan="2">
+ Robert Grady 1992. <i>Practical Software Metrics for Project Management and Process Improvement</i>.
+ Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%" height="28">
+ <a id="HOL96" name="HOL96">HOL96</a>
+ </td>
+ <td width="88%" colspan="2" height="28">
+ Holtzblatt, K., and H. Beyer 1996. "Contextual Design: Principles and Practice," <i>Field Methods for
+ Software and Systems Design</i>. D. Wixon and J. Ramey (Eds.), NY, NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IE830" name="IE830">IE830</a>
+ </td>
+ <td colspan="2">
+ IEEE Std 830-1993. <i>Recommended Practice for Software Requirements Specifications.</i> Software
+ Engineering Standards Committee of the IEEE Computer Society: New York, NY, 1993.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ISO13407" name="ISO13407">ISO13407</a>
+ </td>
+ <td colspan="2">
+ ISO/TC159 1999. <i>Human-centred design processes for interactive systems.</i> Report ISO 13407:1999,
+ International Organization for Standardization, Geneva, Switzerland.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KOV99" name="KOV99">KOV99</a>
+ </td>
+ <td colspan="2">
+ Benjamin L. Kovitz 1999. <i>Practical Software Requirements-A Manual of Content & Style.</i>
+ Manning Publications.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="LEF99" name="LEF99">LEF99</a>
+ </td>
+ <td colspan="2">
+ Dean Leffingwell and Don Widrig 1999. <i>Effective Requirements Management.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%" height="21">
+ <a id="MAY99" name="MAY99">MAY99</a>
+ </td>
+ <td width="88%" colspan="2" height="21">
+ Deborah J. Mayhew1999. <i>The Usability Engineering Lifecycle.</i> Morgan Kaufmann Publishers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SCH98" name="SCH98">SCH98</a>
+ </td>
+ <td colspan="2">
+ Geri Schneider and Jason P. Winters 1998. <i>Applying Use Cases-A Practical Guide.</i> Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SOM97" name="SOM97">SOM97</a>
+ </td>
+ <td colspan="2">
+ Ian Sommerville and Pete Sawyer 1997. <i>Requirements Engineering-A Good Practice Guide.</i> New York,
+ NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="THA97" name="THA97">THA97</a>
+ </td>
+ <td colspan="2">
+ Richard H. Thayer and Merlin Dorfman 1997. <i>Software Requirements Engineering, 2nd Edition.</i> IEEE
+ Computer Society Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WEI95" name="WEI95">WEI95</a>
+ </td>
+ <td colspan="2">
+ Gerald Weinberg, 1995. "Just Say No! Improving the Requirements Process", <i>American Programmer</i>,
+ October 1995.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Software Architecture references" name="Software Architecture references">Software Architecture</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0" valign="top">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BAS98" name="BAS98">BAS98</a>
+ </td>
+ <td colspan="2">
+ Len Bass, Paul Clements, and Rick Kazman 1998. <i>Software Architecture in Practice.</i> Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A handbook of software architecture, with numerous case studies.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOS00" name="BOS00">BOS00</a>
+ </td>
+ <td colspan="2">
+ Jan Bosch 2000. <i>Design and Use of Software Architecture.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BUS96" name="BUS96">BUS96</a>
+ </td>
+ <td colspan="2">
+ Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl 1996.
+ <i>Pattern-Oriented Software Architecture-A System of Patterns</i>, New York, NY: John Wiley and Sons,
+ Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Following the model of the "gang of four" book (Gamma, et al, see above) this book makes an inventory
+ of a wide range of design patterns at the level of the architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CKK02" name="CKK02">CKK02</a>
+ </td>
+ <td colspan="2">
+ Paul Clements, Rick Kazman, and Mark Klein 2002. <i>Evaluating Software Architecture</i>, Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLE02" name="CLE02">CLE02</a>
+ </td>
+ <td colspan="2">
+ Paul Clements et al. 2002. <i>Documenting Software Architectures: Views and Beyond</i>, Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLN02" name="CLN02">CLN02</a>
+ </td>
+ <td colspan="2">
+ Paul Clements and Linda Northrop 2002. <i>Software Product Lines: Practice and Patterns</i>, Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The preceding three books are from the Software Engineering Institute's architecture study group.
+ <i>Evaluating Software Architecture</i> provides useful input for architectural reviews. <i>Documenting
+ Software Architectures: Views and Beyond</i> fully embraces the concept of views and helps with
+ developing a Software Architecture document.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DIK01" name="DIK01">DIK01</a>
+ </td>
+ <td colspan="2">
+ David M. Dikel, David Kane, and James R. Wilson 2001. <i>Software Architecture - Organizational
+ Principles and Patterns</i>, Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Describes the VRAPS model of architecting: Vision, Rhythm, Anticipation, Partnering, and
+ Simplification. This is a good reference for the budding architect to put his or her role in context.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FOW97a" name="FOW97a">FOW97a</a>
+ </td>
+ <td colspan="2">
+ Martin Fowler 1997. <i>Analysis Patterns: Reusable Object Models.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAM94" name="GAM94">GAM94</a>
+ </td>
+ <td colspan="2">
+ Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides 1994. <i>Design Patterns-Elements of
+ Reusable Object-Oriented Software.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the earlier works on patterns, this book deals with patterns "in the small".
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAR93" name="GAR93">GAR93</a>
+ </td>
+ <td colspan="2">
+ David Garlan and Mary Shaw. <i>An Introduction to Software Architecture. </i> SEI Technical Report
+ CMU/SEI-94-TR-21.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HOF99" name="HOF99">HOF99</a>
+ </td>
+ <td colspan="2">
+ Christine Hofmeister, Robert Nord, and Dilip Soni 1999. <i>Applied Software Architecture.</i> Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Proposes an alternate set of architectural views and describes the corresponding process. As the views
+ are not too far from the RUP views, this book is an excellent complement to the guidance found in RUP.
+ Contains several examples of architecture from the biomedical field.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IEP1471" name="IEP1471">IEP1471</a>
+ </td>
+ <td colspan="2">
+ <i>IEEE Recommended Practice for Architectural Description</i>, IEEE Std P1471, 2000.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This standard recommends architectural description based on the concept of multiple views, of which the
+ RUP 4+1 view is an example.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC97" name="JAC97">JAC97</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Martin Griss and Patrik Jonsson, 1997. <i>Software Reuse-Architecture, Process and
+ Organization for Business Success</i>. Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great companion book to the RUP, this book offers insights on the design of components and systems of
+ interconnected system, and lays out a strategy for institutionalizing a practice of systematic reuse at
+ the corporate level.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU95" name="KRU95">KRU95</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 1995, "The 4+1 view model of architecture," <i>IEEE Software.</i> 12(6), November
+ 1995.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The origin of the 4+1 views used for architectural description in the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="LMFS96" name="LMFS96">LMFS96</a>
+ </td>
+ <td colspan="2">
+ Lockheed Martin Federal STARS (Software Technology for Adaptable, Reliable Systems) Program. Domain
+ Engineering Guidebook.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This Guidebook provides a high-level description of the Domain Engineering process in the context
+ of a real organization-the U.S. Air Force's Space and Warning Systems Center.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PW92" name="PW92">PW92</a>
+ </td>
+ <td colspan="2">
+ Dewayne E. Perry and Alexander L. Wolf. <i>Foundations for the Study of Software Architecture.</i> ACM
+ SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="REC97" name="REC97">REC97</a>
+ </td>
+ <td colspan="2">
+ Eberhardt Rechtin and Mark Maier 1997. <i>The Art of System Architecting.</i> Boca Ration, FL: CRC
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Although not specifically directed to software engineers, these two books are extremely valuable for
+ software architects: in particular, they introduce an invaluable set of heuristics and many examples of
+ architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="REC91" name="REC91">REC91</a>
+ </td>
+ <td colspan="2">
+ Eberhardt Rechtin 1991. <i>Systems Architecting: creating and building complex systems</i>. Englewood
+ Cliffs NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY91" name="ROY91">ROY91</a>
+ </td>
+ <td colspan="2">
+ Walker E. Royce and Winston Royce, "Software Architecture: Integrating Process and Technology,"
+ <i>Quest,</i> 14 (1), 1991, Redondo Beach, CA: TRW, pp.2-15.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SHA96" name="SHA96">SHA96</a>
+ </td>
+ <td colspan="2">
+ Mary Shaw and David Garlan 1996. <i>Software Architecture-Perspectives on an Emerging Discipline.</i>
+ Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good introduction to the concepts and problems of software architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WIT94" name="WIT94">WIT94</a>
+ </td>
+ <td colspan="2">
+ Bernard I. Witt, F. Terry Baker, and Everett W. Merritt 1994. <i>Software Architecture and
+ Design-Principles, Models, and Methods.</i> New York, NY: Van Nostrand Reinhold.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the first comprehensive book written on software architecture.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2>
+ <a id="Software Development Process references" name="Software Development Process references">Software Development
+ Process</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AMB99" name="AMB99">AMB99</a>
+ </td>
+ <td colspan="2">
+ Scott W. Ambler 1999. <i>More Process Patterns: Delivering Large-Scale Systems Using Object
+ Technology</i>. New York, NY: SIGS Books/Cambridge University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The companion to [AMB98].
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AMB98" name="AMB98">AMB98</a>
+ </td>
+ <td colspan="2">
+ Scott W. Ambler 1998. <i>Process Patterns: Building Large-Scale Systems Using Object Technology</i>.
+ New York, NY: SIGS Books/Cambridge University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good resource on process tailoring and applying object-oriented techniques to software engineering
+ projects.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE96" name="BOE96">BOE96</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1996, "Anchoring the Software Process," <i>IEEE Software,</i> July 1996, pp.73-82.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This article defines the four phases and the corresponding milestones.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE88" name="BOE88">BOE88</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1988, "A Spiral Model of Software Development and Enhancement," <i>Computer,</i> May
+ 1988, IEEE, pp.61-72.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This seminal article defines the principles and motivations of iterative development.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COC01" name="COC01">COC01</a>
+ </td>
+ <td colspan="2">
+ Alistair Cockburn 2001. <i>Agile Software Development</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Peers into the team dynamics, the cultures, the communications aspects of software development.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DOD94" name="DOD94">DOD94</a>
+ </td>
+ <td colspan="2">
+ <i>Software Development and Documentation,</i> MIL-STD-498, U.S. Department of Defense, December 1994.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FER01" name="FER01">FER01</a>
+ </td>
+ <td colspan="2">
+ Xavier Ferre et al. 2001, "Usability Basics for Software Developers," <i>IEEE Software,</i> January
+ 2001, pp. 22-29.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HIG00" name="HIG00">HIG00</a>
+ </td>
+ <td colspan="2">
+ James A. Highsmith 2000. <i>Adaptive Software Development: A Collaborative Approach to Managing Complex
+ Systems</i>. Dorset House.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book is a great companion book to the RUP-a fantastic and convincing plea for iterative
+ development. Very practical advice for the project manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HUM89" name="HUM89">HUM89</a>
+ </td>
+ <td colspan="2">
+ Watts S. Humphrey 1989. <i>Managing the Software Process</i>. Reading, MA: Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic book on software process and the capability maturity model developed at the Software
+ Engineering Institute.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ISO95" name="ISO95">ISO95</a>
+ </td>
+ <td colspan="2">
+ ISO/IEC 12207 <i>Information Technology-Software Life-cycle Processes.</i> ISO, Geneva, 1995, 57p.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ISO91" name="ISO91">ISO91</a>
+ </td>
+ <td colspan="2">
+ ISO 9000-3 <i>Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of
+ Software.</i> ISO, Geneva 1991.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Two key standards for software process definition and assessment.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC98" name="JAC98">JAC98</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Grady Booch, and James Rumbaugh 1998. <i>The Unified Software Development Process.</i>
+ Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This recent textbook is a more thorough description of the Unified Process and is a useful companion to
+ the RUP. Also provides examples of UML modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC97" name="JAC97">JAC97</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Martin Griss, and Patrik Jonsson 1997. <i>Software Reuse-Architecture, Process and
+ Organization for Business Success.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This textbook on software reuse is great complement to the RUP. It features also some great chapters on
+ architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JEF01" name="JEF01">JEF01</a>
+ </td>
+ <td colspan="2">
+ Ron Jeffries, Ann Anderson, and Chet Hendrickson 2001. <i>Extreme Programming Installed.</i>
+ Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book describes practical Extreme Programming techniques.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU96" name="KRU96">KRU96</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 1996. "A Rational Development Process"<i>,</i> <i>CrossTalk</i>, 9 (7), July 1996,
+ p.11-16.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Developed with Walker Royce, Sue Mickel, and a score of Rational consultants, this article describes
+ the iterative lifecycle of the Rational Process.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU91" name="KRU91">KRU91</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 1991. "Un processus de dévelopment de logiciel itératif et centré sur
+ l´architecture", <i>Proceedings of the 4th International Conference on Software Engineering, December
+ 1991</i>, Toulouse, France, EC2.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The Rational iterative process in French.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU00" name="KRU00">KRU00</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 2000. <i>The Rational Unified Process, An Introduction, Second Edition.</i> Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Indespensible as an introductory text, this "mile wide, inch deep" overview quickly introduces you to
+ the concepts, structure, content, and motivation of the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRO03" name="KRO03">KRO03</a>
+ </td>
+ <td colspan="2">
+ Per Kroll and Philippe Kruchten 2003. <i>The Rational Unified Process Made Easy, A Practitioners Guide
+ to the RUP.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A practical guide to adopting the spirit, principles and practices of the RUP. An invaluable resource
+ in helping you decide how to apply the RUP in your organization or project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCF96" name="MCF96">MCF96</a>
+ </td>
+ <td colspan="2">
+ Robert McFeeley 1996. <i>IDEAL: A User's Guide for Software Process Improvement.</i> Software
+ Engineering Institute, Pittsburgh, PA, CMU/SEI-96-HB-001.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Describes a software process improvement program model called IDEAL, a generic description of a
+ sequence of recommended steps for initiating and managing a process implementation project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PAR86" name="PAR86">PAR86</a>
+ </td>
+ <td colspan="2">
+ David L. Parnas and Paul C. Clements, "A Rational Design Process: How and Why to Fake It", <i>IEEE
+ Trans. Software Eng.,</i> Feb. 1986, pp.251-257.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PAU93" name="PAU93">PAU93</a>
+ </td>
+ <td colspan="2">
+ Mark Paulk, et al. 1993. <i>Capability Maturity Model for Software, Version 1.1.</i> Software
+ Engineering Institute, Pittsburgh, PA SEI-93-TR-024.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The original reference for the capability maturity model.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY90" name="ROY90">ROY90</a>
+ </td>
+ <td colspan="2">
+ Walker E. Royce, "TRW's Ada Process Model for Incremental Development of Large Software Systems",
+ <i>Proceedings ICSE 12, March 26-30, 1990,</i> Nice, France, IEEE, pp.2-11.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY70" name="ROY70">ROY70</a>
+ </td>
+ <td colspan="2">
+ Winston W. Royce, "Managing the Development of Large Software Systems: Concepts and Techniques",
+ <i>Proceedings, WESCON</i>, August 1970.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Testing and Quality references" name="Testing and Quality references">Testing and Quality</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BAC01a" name="BAC01a">BAC01a</a>
+ </td>
+ <td colspan="2">
+ James Bach 2001. <i>What Is Exploratory Testing? (And How It Differs from Scripted Testing).</i>
+ Software Testing and Quality Engineering Magazine, Jan 29, 2001.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This article is available online at <a
+ href="http://www.stickyminds.com/sitewide.asp?sid=582697&sqry=%2AJ%28MIXED%29%2AR%28createdate%29%2AK%28simplesite%29%2AF%28what+is+exploratory+testing%29%2A&sidx=0&sopp=10&ObjectId=2255&Function=DETAILBROWSE&ObjectType=COL"
+ target="_blank">http://www.stickyminds.com</a>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BAS87" name="BAS87">BAS87</a>
+ </td>
+ <td colspan="2">
+ BAS87 Victor R. Basili and H. Dieter Rombach 1987. <i>Tailoring the Software Process to Project Goals
+ and Environments.</i> Proceedings of the 9th International Conference on Software Engineering Software,
+ IEEE Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEI95" name="BEI95">BEI95</a>
+ </td>
+ <td colspan="2">
+ Boris Beizer 1995. <i>Black Box Testing.</i> New York, NY: John Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Various strategies to develop test cases for the functional testing of software. Dr. Beizer's writing
+ style and wit make this book easy and fun to read, with excellent, understandable examples.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BLA99" name="BLA99">BLA99</a>
+ </td>
+ <td colspan="2">
+ Rex Black 1999. <i>Managing the Testing Process.</i> Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book is a good source of information about managing system testing teams.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GLA81" name="GLA81">GLA81</a>
+ </td>
+ <td colspan="2">
+ Robert L. Glass 1981. <i>Persistent Software Errors.</i> IEEE Transactions on Software Engineering,
+ March 1981.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IE829" name="IE829">IE829</a>
+ </td>
+ <td colspan="2">
+ IEEE 829-1983 <i>Standard for Software Test Documentation.</i> Software Engineering Standards Committee
+ of the IEEE Computer Society, New York.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAN01" name="KAN01"></a>KAN01
+ </td>
+ <td colspan="2">
+ Cem Kaner, James Bach, and Bret Pettichord 2001. <i>Lessons Learned in Software Testing.</i> John Wiley
+ & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A wealth of tips and tricks that help to address a wide variety of issues faced in the testing of
+ computer software. Broad coverage of management, psychological as well as the technical aspects of
+ software testing. Valuable guidance for the novice and the expert alike.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAN99" name="KAN99"></a>KAN99
+ </td>
+ <td colspan="2">
+ Cem Kaner, Jack Falk, and Hung Quoc Nguyen 1999. <i>Testing Computer Software, 2nd Edition.</i> John
+ Wiley & Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="12%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Billed as "The best-selling software testing book of all time", this book offers a broad coverage of
+ various aspects of software testing.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MAR00" name="MAR00">MAR00</a>
+ </td>
+ <td colspan="2">
+ Brian Marick 2000. <i>Faults of Omission.</i> Software Testing and Quality Engineering Magazine,
+ March-April 2000.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="12%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This article is available online at: <a href="http://www.testing.com/writings/omissions.pdf"
+ target="_blank">http://www.testing.com/writings/omissions.pdf</a>.<br />
+ (<a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Get Adobe Reader</a>)
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MYE79" name="MYE79">MYE79</a>
+ </td>
+ <td colspan="2">
+ Glenford J. Myers 1979. <i>The Art of Software Testing</i>, John Wiley & Sons, Inc., New York.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This is one of the classic works of software testing literature. Even today this timelesss text offers
+ useful, practical, and relevent guidance.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="OST84" name="OST84">OST84</a>
+ </td>
+ <td colspan="2">
+ Thomas J. Ostrand and Elaine J. Weyuker 1984. <i>Collecting and Categorizing Software Error Data in an
+ Industrial Environment.</i> Journal of Systems and Software, Vol. 4, 1984.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br /><!-- END:mainDescription,-a8huB5Sn0Qjfe-SkZubH1w -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/resources/circleOfLife.jpg b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/resources/circleOfLife.jpg
new file mode 100644
index 0000000..3772826
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/resources/circleOfLife.jpg
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_best_practices.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_best_practices.html
new file mode 100644
index 0000000..24f003b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_best_practices.html
@@ -0,0 +1,104 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\xp_best_practices.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_best_practices.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,4.315031901943112E-306 CRC: 719341121 -->XP Best Practices<!-- END:presentationName,4.315031901943112E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-LVHbtWMGC3pAL9abD018MA CRC: 4140363797 --><p>
+ Extreme Programming is based on core values of <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">communication,
+ simplicity, feedback, and courage</a>. These are not just buzzwords: they pervade the behavior of XP practitioners and
+ the choice of XP practices.
+</p>
+<p>
+ More than anything else, XP is about people, people coming together and working together to build software. The
+ practices of XP are there to enable people to work together; the practices try never to get in the way of the human
+ enterprise of building software that meets business needs. Thus, the practices of XP, while quite disciplined, are
+ there to enable interactions among individuals, never to replace or interfere with those interactions.
+</p>
+<h3>
+ XP Practices
+</h3>
+<p>
+ <b><a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html"
+ guid="2.2937799026801584E-305">Overview</a></b>
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html"
+ guid="2.7371805612676613E-305">Planning Game</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html"
+ guid="5.762953011420275E-306">Small Releases</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html"
+ guid="2.297945473205673E-305">Customer Tests</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html"
+ guid="1.6109092258980447E-306">Simple Design</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html"
+ guid="3.876855509996079E-307">Pair Programming</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
+ guid="1.620567348185129E-306">Test Driven Development</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
+ guid="1.4410217108363206E-306">Refactoring</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html"
+ guid="4.884861766532753E-306">Metaphor</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html"
+ guid="3.193414568279561E-305">Continuous Integration</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html"
+ guid="9.300699588493279E-306">Collective Ownership</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html"
+ guid="8.8116853923311E-307">Coding Standard</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html"
+ guid="3.133529870649493E-306">Sustainable Pace</a>
+ </li>
+</ul><!-- END:mainDescription,-LVHbtWMGC3pAL9abD018MA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_roles_and_tasks.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_roles_and_tasks.html
new file mode 100644
index 0000000..b7ce0d9
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_roles_and_tasks.html
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\xp_roles_and_tasks.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_roles_and_tasks.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.967980776087095E-306 CRC: 3903331342 -->XP Roles and Tasks<!-- END:presentationName,3.967980776087095E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-c5D4uYtVcDvab8GzkO0HiQ CRC: 816026380 --><a id="XE_activities__overview_of_xp_and_rup_activities" name="XE_activities__overview_of_xp_and_rup_activities"></a>
+<div align="left">
+ <table width="75%" border="1">
+ <tbody>
+ <tr>
+ <td width="6%" rowspan="2">
+
+ </td>
+ <td align="middle" colspan="5">
+ <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" colspan="2">
+ <a class="elementLink"
+ href="./../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>
+ </td>
+ <td align="middle">
+ <a class="elementLink"
+ href="./../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>
+ </td>
+ <td align="middle" colspan="2">
+ <a class="elementLink"
+ href="./../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
+ guid="5.613949040902463E-308">XP Organization</a>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle">
+ <b>XP Roles</b>
+ </td>
+ <td align="middle" width="17%">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}.html"
+ guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">Customer</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}.html"
+ guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">Tester</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}.html"
+ guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}">Programmer</a>
+ </td>
+ <td align="middle" width="13%">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
+ guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">Tracker</a>
+ </td>
+ <td align="middle" width="12%">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">Coach</a>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<br />
+<h3>
+ XP Roles and Tasks
+</h3>
+<p>
+ XP defines a more limited set of roles and tasks than Unified Process. The XP roles usually have much broader scope
+ than Unified Process roles. There is a definite push in XP to move away from specialization where only one person on a
+ team has knowledge of specific and critical parts of the system or technology. The consequence is that the XP roles
+ usually map to more than one Unified Process role. Some Unified Process roles/tasks/artifacts do not map to anything in
+ XP as XP has a somewhat smaller scope than Unified Process.
+</p>
+<h4>
+ Definition of Roles and Tasks in Unified Process
+</h4>
+<p>
+ <b>Roles</b> are typically realized by an individual or a set of individuals working together as a team. A project team
+ member typically fulfills many different roles. <b>Roles</b> are not individuals; instead, they describe how
+ individuals behave in the business and what responsibilities these individuals have. While most roles are realized by
+ people within the organization, people outside of the development organization play an important role. A <b>role</b> is
+ an abstract definition of a set of <b>tasks</b> performed and <b>artifacts</b> generated.
+</p>
+<p>
+ <b>Roles</b> have a set of cohesive <b>tasks</b> to be performed. These <b>tasks</b> are closely related and
+ functionally coupled and are often best performed by the same individual. Tasks are closely related to
+ <b>artifacts</b>. Artifacts provide the input and output for the tasks and the mechanism by which information is
+ communicated between tasks.
+</p><!-- END:mainDescription,-c5D4uYtVcDvab8GzkO0HiQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_white_papers.html b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_white_papers.html
new file mode 100644
index 0000000..852e349
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/customcategories/xp_white_papers.html
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\customcategories\xp_white_papers.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_white_papers.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,6.505229665845286E-306 CRC: 783515979 -->XP White Papers<!-- END:presentationName,6.505229665845286E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_GqtAEsGnq12qQmyqWdHHQ CRC: 2163904846 --><p>
+ Additional white papers related to XP can be found at:
+</p>
+<p>
+ White papers relate to the <a href="http://www.objectmentor.com/processImprovement/xpRupResourceCenter/index%20">BUP XP
+ Plug-In Resource Center</a>.
+</p>
+<p>
+ White papers related to Agile methods and Object Oriented Programming at <a
+ href="http://www.objectmentor.com/resources" target="_blank">http://www.objectmentor.com/resources</a><a
+ href="http://www.objectmentor.com"></a>
+</p>
+<br />
+<br />
+<br />
+<br />
+<br /><!-- END:mainDescription,-_GqtAEsGnq12qQmyqWdHHQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/agile_software_development.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/agile_software_development.html
new file mode 100644
index 0000000..33afb60
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/agile_software_development.html
@@ -0,0 +1,97 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\agile_software_development.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: agile_software_development.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.041091673844025E-305 CRC: 66340629 -->Agile Software Development<!-- END:presentationName,1.041091673844025E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-EHSlFv7Gla5oCPGBiaZKow CRC: 1896952848 --><a id="XE_agile_software_development__process_differentiators"
+name="XE_agile_software_development__process_differentiators"></a>
+<h2>
+ <a id="Intro" name="Intro">Introduction</a>
+</h2>
+<p>
+ Extreme Programming is probably the best known and very likely the most used of what have come to be known as agile
+ software development methods. There are many software professionals working on agile methods today. There have been
+ several international conferences on agile methods, numerous papers, many websites, and quite a few books. We'll key
+ our discussion from the Agile Manifesto at <a href="http://www.agilemanifesto.org"
+ target="_blank">www.agilemanifesto.org</a>.
+</p>
+<p>
+ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have
+ come to value:
+</p>
+<h2>
+ <a id="Individuals" name="Individuals">Individuals and Interactions Over Processes and Tools</a>
+</h2>
+<p>
+ Processes and tools are very important. We wouldn't be writing this and you wouldn't be reading it were that not true.
+ The best processes and tools, we believe, are those that enable the individuals who are part of a software project to
+ do their job most effectively. To do that, the processes and tools need to facilitate the human interactions that bring
+ about understanding and cooperation. The agile methods use the smallest amount of process that's safe and the simplest
+ tools that are effective in aid of those individuals and interactions.
+</p>
+<h2>
+ <a id="Working" name="Working">Working Software Over Comprehensive Documentation</a>
+</h2>
+<p>
+ Documentation can be very important to a software project. Sometimes it's the only way to communicate ideas across
+ space and time. For an ongoing software project, however, there is a much better way to know what's going on and to
+ steer the project.
+</p>
+<p>
+ Observe the software. The software can be tested, used, and inspected, and all the answers you get are unambiguous. The
+ agile methods focus on keeping the software visible, beginning as early as possible. The best XP projects begin
+ producing tested visible software in the first couple of weeks of the project and never stop.
+</p>
+<h2>
+ <a id="Customer" name="Customer">Customer Collaboration Over Contract Negotiation</a>
+</h2>
+<p>
+ Many software projects require a contract, and all benefit from a clear understanding of what will be done. Attempts to
+ over-constrain the initial understanding, however, almost always backfire. Too often, the result can be a "letter of
+ the law" product that pleases neither the developers nor the users. Agile methods recognize that all stakeholders will
+ be learning over the course of the project. Agile projects are thus set up to facilitate learning and to take advantage
+ of it.
+</p>
+<h2>
+ <a id="Responding" name="Responding">Responding to Change Over Following a Plan</a>
+</h2>
+<p>
+ Too many changes of direction can cause a project to go out of control, costing too much or never finishing. Initial
+ plans, however, cannot know which potential changes should be accommodated and which ignored. Agile methods address
+ this issue in two ways:
+</p>
+<p>
+ First, they respond to change by planning publicly and often. Small changes are dealt with in frequent in-team small
+ planning sessions, while the big picture is published and processed by all stakeholders, again very frequently.
+</p>
+<p>
+ Second, the development techniques in the agile methods generally allow stakeholders to substitute new and better ideas
+ for earlier notions without exorbitant increases in costs.
+</p>
+<h2>
+ <a id="Summary" name="Summary">Summary</a>
+</h2>
+<p>
+ As you study Extreme Programming and as you use it, it's important to keep these agile values in mind. As you tune and
+ adjust the process to your situation, working with the values will enable you to get the best results from the least
+ effort.
+</p><!-- END:mainDescription,-EHSlFv7Gla5oCPGBiaZKow -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/coding_standard.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/coding_standard.html
new file mode 100644
index 0000000..146c11d
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/coding_standard.html
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\coding_standard.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: coding_standard.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,8.8116853923311E-307 CRC: 2456192321 -->Coding Standard<!-- END:presentationName,8.8116853923311E-307 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,--qg2qc3dqmgeB63Nx7Zndg CRC: 165786818 --><a id="XE_xp__coding_standard" name="XE_xp__coding_standard"></a><a id="XE_coding_standard__practice_of"
+name="XE_coding_standard__practice_of"></a><a id="XE_engineering_practices__coding_standard"
+name="XE_engineering_practices__coding_standard"></a>
+<h3>
+ Description
+</h3>
+<p>
+ Using a coding standard is a software development practice that has been widely accepted in the industry. The need for
+ this practice takes on added importance in XP because of the increased level of communication required by collective
+ ownership, pair programming and the constant refactoring of the code. The team should have a standard way of naming and
+ formatting things so they can understand the code quickly and know where to look at all times.
+</p>
+<p>
+ Ideally, the coding standard should be the result of team consensus. In some cases, decisions will be arbitrary
+ (placement of braces). Each item in the standard should support one or more goals, improved communication being one of
+ the most critical goals. Once the team agrees on a standard, all members of the teams are expected to follow it. Pair
+ programming and collective code ownership is sufficient to reinforce the use of the standard within the team. With
+ time, the team will use and modify the standard to develop a style that is well adapted to their environment.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Improved communication</b>: increases the ability to read each other's code.
+ </li>
+ <li>
+ <b>Refactoring support</b>: provides consistently shaped code.
+ </li>
+</ul><!-- END:mainDescription,--qg2qc3dqmgeB63Nx7Zndg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/collective_ownership.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/collective_ownership.html
new file mode 100644
index 0000000..3e8c9e4
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/collective_ownership.html
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\collective_ownership.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: collective_ownership.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,9.300699588493279E-306 CRC: 325517410 -->Collective Ownership<!-- END:presentationName,9.300699588493279E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-YP0i7TC6QNgemddcj1iE7g CRC: 3993421946 --><a id="XE_xp__collective_ownership" name="XE_xp__collective_ownership"></a><a id="XE_collective_ownership__practice_of"
+name="XE_collective_ownership__practice_of"></a><a id="XE_engineering_practices__collective_ownership"
+name="XE_engineering_practices__collective_ownership"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The practice of collective ownership states that any member of the team can change any piece of code in the system at
+ any time.
+</p>
+<p>
+ Having a good suite of tests and being able to integrate continuously is critical to ensuring that this practice works
+ well. Without the tests, it would be impossible to know that a critical piece of the system was modified improperly
+ because of inappropriate understanding. Integrating frequently and testing ensures that such problems are caught and
+ fixed quickly. Used with pair programming, collective code ownership is an effective way to spread the knowledge of the
+ system across the entire team.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Shared knowledge of the code</b>: allows programmers to become familiar with more of the code and benefit from
+ the experience of others.
+ </li>
+ <li>
+ <b>Simpler code</b>: causes complex code to be found and refactored more quickly as many pairs of eyes read the
+ same code.
+ </li>
+ <li>
+ <b>Get things done quickly</b>: removes hurdles so changes can be made by those that need them when they need them.
+ </li>
+</ul><!-- END:mainDescription,-YP0i7TC6QNgemddcj1iE7g -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/continuous_integration.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/continuous_integration.html
new file mode 100644
index 0000000..186bd1e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/continuous_integration.html
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\continuous_integration.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: continuous_integration.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.193414568279561E-305 CRC: 751312288 -->Continuous Integration<!-- END:presentationName,3.193414568279561E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-35rZhRLEVuTVI4280ncN0A CRC: 1834992545 --><a id="XE_xp__continuous_integration" name="XE_xp__continuous_integration"></a><a
+id="XE_continuous_integration__practice_of" name="XE_continuous_integration__practice_of"></a><a
+id="XE_engineering_practices__continuous_integration" name="XE_engineering_practices__continuous_integration"></a>
+<h3>
+ Description
+</h3>
+<p>
+ One of the goals of XP is to ensure that the customer can feel and touch actual progress that reflects the investment
+ to date. As the team builds the software incrementally according to the customer's priority, the new functionality is
+ continuously integrated and demonstrated to the customer.
+</p>
+<p>
+ Integration in XP can happen several times a day. As developers finish some work, they integrate what they have done.
+ Typically, integration is done on an integration machine in order to serialize the process. Integration is supported by
+ unit tests and acceptance tests. When a pair of programmers first sits at the integration machine, the current code
+ base passes all tests. They start by integrating their changes into the code and checking for conflicts. Then, they run
+ all tests. Should any test fail, the pair is responsible for fixing the code and making it pass. Since the tests were
+ all passed before, the failures are in some way related to the modifications that have made to the code. Once all the
+ tests have passed, the integration can be considered a success and another pair can now integrate its changes. The
+ integrated build can then be handed over to the customer, who can see the new functionality on a running system.
+</p>
+<p>
+ This practice obviously requires the use of tools and an environment that supports fast integration/build/test cycles.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Simplified and faster integrations</b>: reduces important conflicts associated with big bang integration and
+ insures that people are working with the latest version of the code.
+ </li>
+ <li>
+ <b>Improved feedback</b>: shows constant and demonstrable progress (it takes a running system to pass the
+ customer's acceptance tests).
+ </li>
+ <li>
+ <b>System always shippable</b>: the latest version of the system passing all tests is always available.
+ </li>
+</ul><!-- END:mainDescription,-35rZhRLEVuTVI4280ncN0A -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/customer_tests.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/customer_tests.html
new file mode 100644
index 0000000..3411634
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/customer_tests.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\customer_tests.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: customer_tests.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,2.297945473205673E-305 CRC: 713318829 -->Customer Tests<!-- END:presentationName,2.297945473205673E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-oW2j2l-rXqHeWPIgjPpbng CRC: 3945094593 --><a id="XE_xp__customer_tests" name="XE_xp__customer_tests"></a><a id="XE_customer_tests__practice_of"
+name="XE_customer_tests__practice_of"></a><a id="XE_engineering_practices__customer_tests"
+name="XE_engineering_practices__customer_tests"></a>
+<h3>
+ Description
+</h3>
+<p>
+ One of the rights in the customer bill of rights tells the customer he will be able to see progress in the form of a
+ working system that passes repeatable tests that he specifies. These tests are what we call the Customer Tests. The
+ customer specifies one or more Customer Tests for each user story in the system, describing in detail how each story is
+ expected to work. Because the tests are put into executable form and are fully automated, they tell programmers what
+ needs to be done in a unambiguous way (tests pass or fail) and allow the customer to feel confident that the system is
+ meeting his needs.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Ability to see <b>tangible and verifiable progress</b>.
+ </li>
+ <li>
+ <b>Ultimate traceability</b>: the Customer Tests are executable system requirements.
+ </li>
+ <li>
+ <b>Repeatability</b>: because they are automated, the tests can be run at any time.
+ </li>
+</ul><!-- END:mainDescription,-oW2j2l-rXqHeWPIgjPpbng -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/developer_testing.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/developer_testing.html
new file mode 100644
index 0000000..50dd56f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/developer_testing.html
@@ -0,0 +1,536 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\developer_testing.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: developer_testing.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,4.085829182735815E-305 CRC: 302200055 -->Developer Testing<!-- END:presentationName,4.085829182735815E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-aJBLg1aguP1bIWvQbJSd6w CRC: 775963661 --><a id="XE_test__developer_testing__concept_of" name="XE_test__developer_testing__concept_of"></a><a
+id="XE_design__developer_testing__concept_of" name="XE_design__developer_testing__concept_of"></a>
+<h3>
+ <a id="Introduction" name="Introduction"></a>Introduction
+</h3>
+<p>
+ The phrase "Developer Testing" is used to categorize the testing activities most appropriately performed by software
+ developers. It also includes the artifacts created by those activities. Developer Testing encompasses the work
+ traditionally thought of under the following categories: Unit Testing, much of Integration Testing, and some aspects of
+ what is most often referred to as System Testing. While Developer Testing is traditionally associated with activities
+ in the Implementation discipline, it also has a relationship to activities in the Analysis and Design discipline.
+</p>
+<p>
+ By thinking of Developer Testing in this "holistic" way, you help to mitigate some of the risk associated with the more
+ "atomistic" approach traditionally taken. In the traditional approach to Developer Testing, the effort is initially
+ focused on evaluating that all units are working independently. Late in the development life-cycle, as the development
+ work nears completion, the integrated units are assembled into a working subsystem or system and tested in this setting
+ for the first time.
+</p>
+<p>
+ This approach has a number of failings. Firstly, because it encourages a staged approach to the testing of the
+ integrated units and later subsystems, any errors identified during these tests are often found too late. This late
+ discovery typically results in the decision to take no corrective action, or it requires major rework to correct. This
+ rework is both expensive and detracts from making forward progress in other areas. This increases the risk of the
+ project being derailed or abandoned.
+</p>
+<p>
+ Secondly, creating rigid boundaries between Unit, Integration and System Test increases the probability that errors
+ spanning the boundaries will be discovered by no one. The risk is compounded when responsibility for these types of
+ tests is assigned to separate teams.
+</p>
+<p>
+ The style of developer testing recommended by iterative processes encourages the developer to focus on the
+ most valuable and appropriate tests to conduct at the given point in time. Even within the scope of a single iteration,
+ it is usually more efficient for the developer to find and correct as many of the defects in her own code as possible,
+ without the additional overhead in hand-off to a separate test group. The desired result is the early discovery of the
+ most significant software errors - regardless of whether those errors are in the independent unit, the integration
+ of the units or the working of the integrated units within a meaningful end-user scenario.
+</p>
+<h3>
+ <a id="DeveloperTestingPitfalls" name="DeveloperTestingPitfalls"></a>Pitfalls Getting Started with Developer Testing
+</h3>
+<p>
+ Many developers who begin trying to do a substantially more thorough job of testing give up the effort shortly
+ thereafter. They find that it does not seem to be yielding value. Further, some developers who begin well with
+ developer testing find that they've created an unmaintainable test suite that is eventually abandoned.
+</p>
+<p>
+ This page gives some guidelines for getting over the first hurdles and for creating a test suite that avoids the
+ maintainability trap. For more information, see <a href="../../workguid/wg_mnttstste.htm">Guidelines: Maintaining
+ Automated Test Suites</a>.
+</p>
+<h4>
+ Establish expectations
+</h4>
+<p>
+ Those who find developer testing rewarding do it. Those who view it as a chore find ways to avoid it. This is simply in
+ the nature of most developers in most industries, and treating it as a shameful lack of discipline hasn't historically
+ been successful. Therefore, as a developer you should expect testing to be rewarding and do what it takes to make it
+ rewarding.
+</p>
+<p>
+ Ideal developer testing follows a very tight edit-test loop. You make a small change to the product, such as adding a
+ new method to a class, then you immediately rerun your tests. If any test breaks, you know exactly what code is the
+ cause. This easy, steady pace of development is the greatest reward of developer testing. A long debugging session
+ should be exceptional.
+</p>
+<p>
+ Because it's not unusual for a change made in one class to break something in another, you should expect to rerun not
+ just the changed class's tests, but many tests. Ideally, you rerun the complete test suite for your component many
+ times per hour. Every time you make a significant change, you rerun the suite, watch the results, and either proceed to
+ the next change or fix the last change. Expect to spend some effort making that rapid feedback possible.
+</p>
+<h4>
+ Automate your tests
+</h4>
+<p>
+ Running tests often is not practical if tests are manual. For some components, automated tests are easy. An example
+ would be an in-memory database. It communicates to its clients through an API and has no other interface to the outside
+ world. Tests for it would look something like this:
+</p>
+<blockquote>
+<pre>
+/* Check that elements can be added at most once. */
+// Setup
+Database db = new Database();
+db.add("key1", "value1");
+// Test
+boolean result = db.add("key1", "another value");
+expect(result == false);
+</pre>
+</blockquote>
+<p>
+ The tests are different from ordinary client code in only one way: instead of believing the results of API calls, they
+ check. If the API makes client code easy to write, it makes test code easy to write. If the test code is <i>not</i>
+ easy to write, you've received an early warning that the API could be improved. Test-first design is thus consistent
+ with the iterative processes' focus on addressing important risks early.
+</p>
+<p>
+ The more tightly connected the component is to the outside world, however, the harder it will be to test. There are two
+ common cases: graphical user interfaces and back-end components.
+</p>
+<h5>
+ Graphical user interfaces
+</h5>
+<p>
+ Suppose the database in the example above receives its data via a callback from a user-interface object. The callback
+ is invoked when the user fills in some text fields and pushes a button. Testing this by manually filling in the fields
+ and pushing the button isn't something you want to do many times an hour. You must arrange a way to deliver the input
+ under programmatic control, typically by "pushing" the button in code.
+</p>
+<p>
+ Pushing the button causes some code in the component to be executed. Most likely, that code changes the state of some
+ user-interface objects. So you must also arrange a way to query those objects programmatically.
+</p>
+<h5>
+ Back-end components
+</h5>
+<p>
+ Suppose the component under test doesn't implement a database. Instead, it's a wrapper around a real, on-disk database.
+ Testing against that real database might be difficult. It might be hard to install and configure. Licenses for it might
+ be expensive. The database might slow down the tests enough that you're not inclined to run them often. In such cases,
+ it's worthwhile to "stub out" the database with a simpler component that does just enough to support the tests.
+</p>
+<p>
+ Stubs are also useful when a component that your component talks to isn't ready yet. You don't want your testing to
+ wait on someone else's code.
+</p>
+<p>
+ For more information, see <a href="../implemen/co_stubs.htm">Concepts: Stubs</a>.
+</p>
+<h4>
+ Don't write your own tools
+</h4>
+<p>
+ Developer testing seems pretty straightforward. You set up some objects, make a call through an API, check the result,
+ and announce a test failure if the results aren't as expected. It's also convenient to have some way to group tests so
+ that they can be run individually or as complete suites. Tools that support those requirements are called <i>test
+ frameworks</i>.
+</p>
+<p>
+ Developer testing <b>is</b> straightforward, and the requirements for test frameworks are not complicated. If, however,
+ you yield to the temptation of writing your own test framework, you'll spend much more time tinkering with the
+ framework than you probably expect. There are many test frameworks available, both commercial and open source, and
+ there's no reason not to use one of those.
+</p>
+<h4>
+ Do create support code
+</h4>
+<p>
+ Test code tends to be repetitive. It's common to see sequences of code like this:
+</p>
+<blockquote>
+<pre>
+// null name not allowed
+retval = o.createName("");
+expect(retval == null);
+// leading spaces not allowed
+retval = o.createName(" l");
+expect(retval == null);
+// trailing spaces not allowed
+retval = o.createName("name ");
+expect(retval == null);
+// first character may not be numeric
+retval = o.createName("5allpha");
+expect(retval == null);
+</pre>
+</blockquote>
+<p>
+ This code is created by copying one check, pasting it, then editing it to make another check.
+</p>
+<p>
+ The danger here is twofold. If the interface changes, much editing will have to be done. (In more complicated cases, a
+ simple global replacement won't suffice.) Also, if the code is at all complicated, the intent of the test can be lost
+ amid all the text.
+</p>
+<p>
+ When you find yourself repeating yourself, seriously consider factoring out the repetition into support code. Even
+ though the code above is a simple example, it's more readable and maintainable if written like this:
+</p>
+<blockquote>
+<pre>
+void expectNameRejected(MyClass o, String s) {
+ Object retval = o.createName(s);
+ expect(retval == null);
+}
+...
+// null name not allowed
+expectNameRejected(o, "");
+// leading spaces not allowed.
+expectNameRejected(o, " l");
+// trailing spaces not allowed.
+expectNameRejected(o, "name ");
+// first character may not be numeric.
+expectNameRejected(o, "5alpha");
+</pre>
+</blockquote>
+<p>
+ Developers writing tests often err on the side of too much copying-and-pasting. If you suspect yourself of that
+ tendency, it's useful to consciously err in the other direction. Resolve that you will strip your code of all duplicate
+ text.
+</p>
+<h4>
+ Write the tests first
+</h4>
+<p>
+ Writing the tests after the code is a chore. The urge is to rush through it, to finish up and move on. Writing tests
+ before the code makes testing part of a positive feedback loop. As you implement more code, you see more tests passing
+ until finally all the tests pass and you're done. People who write tests first seem to be more successful, and it takes
+ no more time. For more on putting tests first, see <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
+ guid="6.556259235358794E-306">Concept: Test-first Design</a>
+</p>
+<h4>
+ Keep the tests understandable
+</h4>
+<p>
+ You should expect that you, or someone else, will have to modify the tests later. A typical situation is that a later
+ iteration calls for a change to the component's behavior. As a simple example, suppose the component once declared a
+ square root method like this:
+</p>
+<blockquote>
+ <p>
+ <font size="+0">double sqrt(double x);</font>
+ </p>
+</blockquote>
+<p>
+ In that version, a negative argument caused <font size="+0">sqrt</font> to return NaN ("not a number" from the IEEE
+ 754-1985 <i>Standard for Binary Floating-Point Arithmetic</i>). In the new iteration, the square root method will
+ accept negative numbers and return a complex result:
+</p>
+<blockquote>
+ <p>
+ <font size="+0">Complex sqrt(double x);</font>
+ </p>
+</blockquote>
+<p>
+ Old tests for <font size="+0">sqrt</font> will have to change. That means understanding what they do, and updating them
+ so that they work with the new <font size="+0">sqrt</font>. When updating tests, you must take care not to destroy
+ their bug-finding power. One way that sometimes happens is this:
+</p>
+<blockquote>
+<pre>
+void testSQRT () {
+ // Update these tests for Complex
+ // when I have time -- bem
+ /*
+double result = sqrt(0.0);
+...
+ */
+}
+</pre>
+</blockquote>
+<p>
+ Other ways are more subtle: the tests are changed so that they actually run, but they no longer test what they were
+ originally intended to test. The end result, over many iterations, can be a test suite that is too weak to catch many
+ bugs. This is sometimes called "test suite decay". A decayed suite will be abandoned, because it's not worth the
+ upkeep.
+</p>
+<p>
+ You can't maintain a test's bug-finding power unless it's clear what <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestIdeas"
+ guid="8.834380241450745E-306">Test Ideas</a> a test implements. Test code tends to be under-commented, even though it's
+ often harder to understand the "why" behind it than product code.
+</p>
+<p>
+ Test suite decay is less likely in the direct tests for <font size="+0">sqrt</font> than in indirect tests. There will
+ be code that calls <font size="+0">sqrt</font>. That code will have tests. When <font size="+0">sqrt</font> changes,
+ some of those tests will fail. The person who changes <font size="+0">sqrt</font> will probably have to change those
+ tests. Because he's less familiar with them, and because their relationship to the change is less clear, he's more
+ likely to weaken them in the process of making them pass.
+</p>
+<p>
+ When you're creating support code for tests (as urged above), be careful: the support code should clarify, not obscure,
+ the purpose of the tests that use it. A common complaint about object-oriented programs is that there's no one place
+ where anything's done. If you look at any one method, all you discover is that it forwards its work somewhere else.
+ Such a structure has advantages, but it makes it harder for new people to understand the code. Unless they make an
+ effort, their changes are likely to be incorrect or to make the code even more complicated and fragile. The same is
+ true of test code, except that later maintainers are even less likely to take due care. You must head off the problem
+ by writing understandable tests.
+</p>
+<h4>
+ Match the test structure to the product structure
+</h4>
+<p>
+ Suppose someone has inherited your component. They need to change a part of it. They may want to examine the old tests
+ to help them in their new design. They want to update the old tests before writing the code (test-first design).
+</p>
+<p>
+ All those good intentions will go by the wayside if they can't find the appropriate tests. What they'll do is make the
+ change, see what tests fail, then fix those. That will contribute to test suite decay.
+</p>
+<p>
+ For that reason, it's important that the test suite be well structured, and that the location of tests be predictable
+ from the structure of the product. Most usually, developers arrange tests in a parallel hierarchy, with one test class
+ per product class. So if someone is changing a class named <font size="+0">Log</font>, they know the test class is
+ <font size="+0">TestLog</font>, and they know where the source file can be found.
+</p>
+<h4>
+ Let tests violate encapsulation
+</h4>
+<p>
+ You might limit your tests to interacting with your component exactly as client code does, through the same interface
+ that client code uses. However, this has disadvantages. Suppose you're testing a simple class that maintains a doubly
+ linked list:
+</p>
+<p align="center">
+ <img height="46" alt="" src="resources/dvltst-img1.gif" width="195" />
+</p>
+<p class="picturetext">
+ Fig1: Double-linked list
+</p>
+<p>
+ In particular, you're testing the <font size="+0">DoublyLinkedList.insertBefore(Object existing, Object
+ newObject)</font> method. In one of your tests, you want to insert an element in the middle of the list, then check if
+ it's been inserted successfully. The test uses the list above to create this updated list:
+</p>
+<p align="center">
+ <img height="46" alt="" src="resources/dvltst-img2.gif" width="318" />
+</p>
+<p class="picturetext">
+ Fig2: Double-linked list - item inserted
+</p>
+<p>
+ It checks the list correctness like this:
+</p>
+<blockquote>
+<pre>
+// the list is now one longer.
+expect(list.size()==3);
+// the new element is in the correct position
+expect(list.get(1)==m);
+// check that other elements are still there.
+expect(list.get(0)==a);
+expect(list.get(2)==z);
+</pre>
+</blockquote>
+<p>
+ That seems sufficient, but it's not. Suppose the list implementation is incorrect and backward pointers are not set
+ correctly. That is, suppose the updated list actually looks like this:
+</p>
+<p align="center">
+ <img height="73" alt="" src="resources/dvltst-img3.gif" width="318" />
+</p>
+<p class="picturetext">
+ Fig3: Double-linked list - fault in implementation
+</p>
+<p>
+ If <font size="+0">DoublyLinkedList.get(int index)</font> traverses the list from the beginning to the end (likely),
+ the test would miss this failure. If the class provides <font size="+0">elementBefore</font> and <font
+ size="+0">elementAfter</font> methods, checking for such failures is straightforward:
+</p>
+<blockquote>
+<pre>
+// Check that links were all updated
+expect(list.elementAfter(a)==m);
+expect(list.elementAfter(m)==z);
+expect(list.elementBefore(z)==m); //this will fail
+expect(list.elementBefore(m)==a);
+</pre>
+</blockquote>
+<p>
+ But what if it doesn't provide those methods? You could devise more elaborate sequences of method calls that will fail
+ if the suspected defect is present. For example, this would work:
+</p>
+<blockquote>
+<pre>
+// Check whether back-link from Z is correct.
+list.insertBefore(z, x);
+// If it was incorrectly not updated, X will have
+// been inserted just after A.
+expect(list.get(1)==m);
+</pre>
+</blockquote>
+<p>
+ But such a test is more work to create and is likely to be significantly harder to maintain. (Unless you write good
+ comments, it will not be at all clear why the test is doing what it's doing.) There are two solutions:
+</p>
+<ol>
+ <li>
+ Add the <font size="+0">elementBefore</font> and <font size="+0">elementAfter</font> methods to the public
+ interface. But that effectively exposes the implementation to everyone and makes future change more difficult.
+ </li>
+ <li>
+ Let the tests "look under the hood" and check pointers directly.
+ </li>
+</ol>
+<p>
+ The latter is usually the best solution, even for a simple class like <font size="+0">DoublyLinkedList</font> and
+ especially for the more complex classes that occur in your products.
+</p>
+<p>
+ Typically, tests are put in the same package as the class they test. They are given protected or friend access.
+</p>
+<h3>
+ <a id="TestDesignMistakes" name="TestDesignMistakes"></a>Characteristic Test Design Mistakes
+</h3>
+<p>
+ Each test exercises a component and checks for correct results. The design of the test-the inputs it uses and how it
+ checks for correctness-can be good at revealing defects, or it can inadvertently hide them. Here are some
+ characteristic test design mistakes.
+</p>
+<h4>
+ Failure to specify expected results in advance
+</h4>
+<p>
+ Suppose you're testing a component that converts XML into HTML. A temptation is to take some sample XML, run it through
+ the conversion, then look at the results in a browser. If the screen looks right, you "bless" the HTML by saving it as
+ the official expected results. Thereafter, a test compares the actual output of the conversion to the expected results.
+</p>
+<p>
+ This is a dangerous practice. Even sophisticated computer users are used to believing what the computer does. You are
+ likely to overlook mistakes in the screen appearance. (Not to mention that browsers are quite tolerant of misformatted
+ HTML.) By making that incorrect HTML the official expected results, you make sure that the test can never find the
+ problem.
+</p>
+<p>
+ It's less dangerous to doubly-check by looking directly at the HTML, but it's still dangerous. Because the output is
+ complicated, it will be easy to overlook errors. You'll find more defects if you write the expected output by hand
+ first.
+</p>
+<h4>
+ Failure to check the background
+</h4>
+<p>
+ Tests usually check that what should have been changed has been, but their creators often forget to check that what
+ should have been left alone has been left alone. For example, suppose a program is supposed to change the first 100
+ records in a file. It's a good idea to check that the 101<sup>st</sup> hasn't been changed.
+</p>
+<p>
+ In theory, you would check that nothing in the "background"-the entire file system, all of memory, everything reachable
+ through the network-has been left alone. In practice, you have to choose carefully what you can afford to check. But
+ it's important to make that choice.
+</p>
+<h4>
+ Failure to check persistence
+</h4>
+<p>
+ Just because the component tells you a change has been made, that doesn't mean it has actually been committed to the
+ database. You need to check the database via another route.
+</p>
+<h4>
+ Failure to add variety
+</h4>
+<p>
+ A test might be designed to check the effect of three fields in a database record, but many other fields need to be
+ filled in to execute the test. Testers will often use the same values over and over again for these "irrelevant"
+ fields. For example, they'll always use the name of their lover in a text field, or 999 in a numeric field.
+</p>
+<p>
+ The problem is that sometimes what shouldn't matter actually does. Every so often, there's a bug that depends on some
+ obscure combination of unlikely inputs. If you always use the same inputs, you stand no chance of finding such bugs. If
+ you persistently vary inputs, you might. Quite often, it costs almost nothing to use a number different than 999 or to
+ use someone else's name. When varying the values used in tests costs almost nothing and it has some potential benefit,
+ then vary. (Note: It's unwise to use names of old lovers instead of your current one if your current lover works with
+ you.)
+</p>
+<p>
+ Here's another benefit. One plausible fault is for the program to use field <i>X</i> when it should have used field
+ <i>Y</i>. If both fields contain "Dawn", the fault can't be detected.
+</p>
+<h4>
+ Failure to use realistic data
+</h4>
+<p>
+ It's common to use made-up data in tests. That data is often unrealistically simple. For example, customer names might
+ be "Mickey", "Snoopy", and "Donald". Because that data is different from what real users enter - for example, it's
+ characteristically shorter - it can miss defects real customers will see. For example, these one-word names wouldn't
+ detect that the code doesn't handle names with spaces.
+</p>
+<p>
+ It's prudent to make a slight extra effort to use realistic data.
+</p>
+<h4>
+ Failure to notice that the code does nothing at all
+</h4>
+<p>
+ Suppose you initialize a database record to zero, run a calculation that should result in zero being stored in the
+ record, then check that the record is zero. What has your test demonstrated? The calculation might not have taken place
+ at all. Nothing might have been stored, and the test couldn't tell.
+</p>
+<p>
+ That example sounds unlikely. But this same mistake can crop up in subtler ways. For example, you might write a test
+ for a complicated installer program. The test is intended to check that all temporary files are removed after a
+ successful installation. But, because of all the installer options, in that test, one particular temporary file wasn't
+ created. Sure enough, that's the one the program forgot to remove.
+</p>
+<h4>
+ Failure to notice that the code does the wrong thing
+</h4>
+<p>
+ Sometimes a program does the right thing for the wrong reasons. As a trivial example, consider this code:
+</p>
+<blockquote>
+<pre>
+if (a < b && c)
+ return 2 * x;
+else
+ return x * x;
+</pre>
+</blockquote>
+<p>
+ The logical expression is wrong, and you've written a test that causes it to evaluate incorrectly and take the wrong
+ branch. Unfortunately, purely by coincidence, the variable X has the value 2 in that test. So the result of the wrong
+ branch is accidentally correct - the same as the result the right branch would have given.
+</p>
+<p>
+ For each expected result, you should ask if there's a plausible way in which that result could be gotten for the wrong
+ reason. While it's often impossible to know, sometimes it's not.
+</p>
+<br />
+<br /><!-- END:mainDescription,-aJBLg1aguP1bIWvQbJSd6w -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/extreme_programming.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/extreme_programming.html
new file mode 100644
index 0000000..9f86810
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/extreme_programming.html
@@ -0,0 +1,250 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\extreme_programming.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: extreme_programming.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,5.2637267673584526E-306 CRC: 3579049764 -->Extreme Programming<!-- END:presentationName,5.2637267673584526E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-27sE-swoOUGtar9a0f3RPw CRC: 3142828886 --><a id="XE_xp__conceptual_process_roadmap" name="XE_xp__conceptual_process_roadmap"></a><a id="XE_roadmap__for_xp_practices"
+name="XE_roadmap__for_xp_practices"></a>
+<h3>
+ Topics
+</h3>
+<div align="left">
+ <table width="70%" border="1">
+ <tbody valign="top">
+ <tr>
+ <td width="315" height="178">
+ <ul>
+ <li>
+ <a href="#Introduction">Introduction</a>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <a href="#About">About XP</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="#Characteristics">Characteristics of an XP Project</a>
+ </li>
+ <li>
+ <a href="#Phases">Phases and Iterations</a>
+ </li>
+ <li>
+ <a href="#GettingStarted">How to Get Started</a>
+ </li>
+ </ul>
+ </td>
+ <td width="315" height="178">
+ <b>Additional Guidance:</b>
+ <ul>
+ <li>
+ Guidelines
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <a class="elementLink"
+ href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html"
+ guid="8.137126904637637E-306">Refactoring</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html"
+ guid="3.9254165491375454E-306">Test First Development</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html"
+ guid="3.85153041801319E-307">Pair Programming</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
+ guid="6.7335956461328426E-307">Planning Game</a>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <br />
+ <b>Additional Concepts:</b>
+ <ul>
+ <li>
+ <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a>
+ </li>
+ </ul>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<br />
+<h1>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h1>
+<p>
+ This roadmap provides information for getting started and applying the practices of eXtreme Programming (XP) to a
+ software development project.
+</p>
+<h3>
+ <a id="About" name="About">About XP</a>
+</h3>
+<p>
+ Extreme Programming is an instance of an <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a> method. XP is a method that is optimized for small to
+ medium-sized project teams that fit a certain profile. It promotes rapid feedback and response to continual change. It
+ is based upon the four <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">values</a>
+ of simplicity, communication, feedback, and courage and is consistent with the values of agile software development.
+</p>
+<p>
+ Extreme Programming is an instance of an agile method for developing software. It is based upon the core principle of
+ agility and consists of twelve practices that, when applied to an appropriate software development project, can produce
+ high-quality software. If you are unfamiliar with the concepts surrounding XP, you should start by reading <a
+ class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a>.
+</p>
+<h3>
+ <a id="Characteristics" name="Characteristics">Characteristics of an XP Project</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium-sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. Since XP relies heavily on
+ direct and frequent communication between the team members, the team should be co-located. An ideal project for using
+ XP would be one that has most of the following characteristics:
+</p>
+<ul>
+ <li>
+ A small to medium-sized team (fewer than 20 people on the complete team)
+ </li>
+ <li>
+ Co-located, preferably in a single area with a large common space
+ </li>
+ <li>
+ A committed, full-time, on-site customer or customer representative
+ </li>
+</ul>
+<h3>
+ <a id="Phases" name="Phases">Phases and Iterations</a>
+</h3>
+<p>
+ An XP project is one that is based on rapid feedback through short iterations and frequent releases. Unified
+ Process and XP share a fundamental belief that iterative development is the best way to deliver valuable software
+ to your customers. The concept of phases, as usually described in the Unified Process, is somewhat different. Decisions
+ described in the Unified Process phases that define milestones occur, but they are not called specifically as defining
+ phases.
+</p>
+<h3>
+ <a id="GettingStarted" name="GettingStarted">How to Get Started</a>
+</h3>
+<p>
+ This section provides a recommended way to approach XP for your project. You don't have to follow the steps as
+ specified, but if you have little experience with XP, we recommend following them as closely as possible the first
+ time.
+</p>
+<table cellspacing="2" cellpadding="1" width="91%" border="1">
+ <tbody>
+ <tr>
+ <th width="10%">
+ Step
+ </th>
+ <th align="left" width="47%">
+ Do this ...
+ </th>
+ <th align="left" width="43%">
+ in order to...
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 1
+ </td>
+ <td width="47%">
+ Familiarize yourself with the <a class="elementLink"
+ href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
+ guid="1.6390805262958034E-306">motivation</a> for using XP, the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html"
+ guid="9.251272550276345E-306">short description</a> of XP, and the <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html"
+ guid="2.2937799026801584E-305">XP Practices</a>
+ </td>
+ <td width="43%">
+ understand the fundamental principles of XP and how the practices support each other.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 2
+ </td>
+ <td width="47%">
+ Read the key concepts of <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a>
+ </td>
+ <td width="43%">
+ understand the collaborative and social aspects of XP.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 3
+ </td>
+ <td width="47%">
+ Determine if XP is appropriate for your project by reviewing <a href="#Characteristics">The Characteristics
+ of an XP Project</a>
+ </td>
+ <td width="43%">
+ decide if XP may be appropriate for your project.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 4
+ </td>
+ <td width="47%">
+ Read about the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/xp_environment,3.754748120034442E-307.html"
+ guid="3.754748120034442E-307">XP Environment</a>.
+ </td>
+ <td width="43%">
+ prepare the physical and tool environment for your team.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 5
+ </td>
+ <td width="47%">
+ Read the <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/getting_started_with_xp,1.2284921351651456E-304.html"
+ guid="1.2284921351651456E-304">Getting Started with XP</a> guidelines.
+ </td>
+ <td width="43%">
+ get suggestions on how to start an XP project.
+ </td>
+ </tr>
+ </tbody>
+</table><!-- END:mainDescription,-27sE-swoOUGtar9a0f3RPw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/metaphor_system_of_names.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/metaphor_system_of_names.html
new file mode 100644
index 0000000..16e00df
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/metaphor_system_of_names.html
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\metaphor_system_of_names.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: metaphor_system_of_names.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,4.884861766532753E-306 CRC: 2154963974 -->Metaphor (System of Names)<!-- END:presentationName,4.884861766532753E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-2OU2wQP_WNWX5zzWzx4ANw CRC: 3357931307 --><a id="XE_xp__metaphor_(system_of_names)" name="XE_xp__metaphor_(system_of_names)"></a><a
+id="XE_metaphor_(system_of_names)__practice_of" name="XE_metaphor_(system_of_names)__practice_of"></a><a
+id="XE_engineering_practices__metaphor_(system_of_names)" name="XE_engineering_practices__metaphor_(system_of_names)"></a>
+<h3>
+ Description
+</h3>
+<p>
+ This metaphor is a design overview. It is a way of defining the system using a commonly understandable vocabulary with
+ its associated relationships. It allows the whole team to talk about the structure of the software in a convenient and
+ memorable way. A good metaphor is one that all team members can understand easily, remember, and always keep in the
+ back of their minds. It provides a unifying direction that developers can follow as they build the system a small piece
+ at a time.
+</p>
+<p>
+ Metaphors are not always easy to find at the start of a project. In that case, teams can simply identify the key
+ objects and their interactions in the system (System of Names). The real metaphor might emerge later on. When everybody
+ on the team can explain quickly the system through its major objects and their interactions, the goal has been reached.
+</p>
+<p>
+ The iterative nature of XP causes the architecture of our system to evolve over time. The metaphor is not static; it
+ will change and hopefully improve over time as our understanding of the system improves.
+</p>
+<p>
+ An example of a metaphor would be something like: "It's like a subway system with passengers and stations, tickets and
+ turnstiles, etc.".
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Communication</b>: customer and developer define a common language they can use to talk about the system.
+ </li>
+ <li>
+ <b>Direction</b>: the metaphor helps guide the developers towards the solution.
+ </li>
+</ul><!-- END:mainDescription,-2OU2wQP_WNWX5zzWzx4ANw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/motivation.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/motivation.html
new file mode 100644
index 0000000..7a5d89b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/motivation.html
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\motivation.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: motivation.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.6390805262958034E-306 CRC: 3764417517 -->motivation<!-- END:presentationName,1.6390805262958034E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-nIpFvBhY9WogqrEQv4NknQ CRC: 42062863 --><p>
+ The goal of a software process is to guide the software development organization to:
+</p>
+<ol>
+ <li>
+ Get the right software done.
+ </li>
+ <li>
+ Get the software done right.
+ </li>
+ <li>
+ Get the software done quickly.
+ </li>
+ <li>
+ Get the software done frugally.
+ </li>
+</ol>
+<p>
+ There are many approaches to this problem. Some software processes are high in ceremony. They guide the developers to
+ create many artifacts. They punctuate the project with phases and sign-offs. They release infrequently, sometimes
+ solely upon project completion. There is a time and place for such processes.
+</p>
+<p>
+ On the other hand, the most important and scarce resource in any project is the time of the developers. High ceremony
+ processes fill that time with work activities that center around artifacts and reviews instead of around the core
+ artifacts of code and tests. For many projects this is an exorbitant expense.
+</p>
+<p>
+ To manage this expense, many projects need a process that uses a minimum of ceremony and concentrates on the core
+ artifacts. They need a feedback-driven process that delivers working software rapidly in quick releases.
+</p>
+<p>
+ XP is just such a low ceremony process. It is used by those teams and for those projects where ceremony is of little
+ value, but rapid feedback is of high value. Such projects tend to be small to medium sized - fewer than one or two
+ million lines of code - and involve fewer than one or two dozen developers. They tend to exist in environments of
+ intense business and or technical change. They are, of course, exceedingly common.
+</p>
+<p>
+ A lack of ceremony does not imply a lack of management. XP places a lot of emphasis on techniques for planning,
+ estimation, and schedule management. Creating, maintaining, and managing a project plan is a very big part of XP.
+</p>
+<p>
+ A lack of ceremony also does not imply a lack of discipline. XP espouses discipline for every facet of the project.
+ There is discipline for testing, integration, planning, reviewing, and for producing software with a high quality
+ internal structure. The goal is to keep the project moving and the software easy to modify, easy to extend, and easy to
+ develop.
+</p>
+<p>
+ In short, XP puts the emphasis on ensuring that the team is working on the minimum set of activities and artifacts that
+ will produce the right software, built right, built quickly and built frugally.<br />
+ <br />
+</p><!-- END:mainDescription,-nIpFvBhY9WogqrEQv4NknQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/pair_programming.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/pair_programming.html
new file mode 100644
index 0000000..7789b68
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/pair_programming.html
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\pair_programming.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: pair_programming.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.876855509996079E-307 CRC: 2480722832 -->Pair Programming<!-- END:presentationName,3.876855509996079E-307 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-n52TyFa7Reb3LOJV1JMpvg CRC: 1707449993 --><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__practice_of"
+name="XE_pair_programming__practice_of"></a><a id="XE_engineering_practices__pair_programming"
+name="XE_engineering_practices__pair_programming"></a>
+<h3>
+ Description
+</h3>
+<p>
+ All production software in XP is produced by two programmers, sitting side by side, at the same machine. This practice
+ ensures that all production code is reviewed by at least one other programmer and results in better design, better
+ testing, and better code.
+</p>
+<p>
+ Research into pair programming shows that pairing produces better code in about the same time as programmers working
+ singly.
+</p>
+<p>
+ Pairing also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of
+ everyone's specialized knowledge. Programmers learn, their skills improve, and they become more valuable to the team
+ and to the company.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Better design, code and tests.
+ </li>
+ <li>
+ Application and skill knowledge sharing across team.
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ See the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html" guid="3.85153041801319E-307">Pair
+ Programming Guidelines</a>.
+</p><!-- END:mainDescription,-n52TyFa7Reb3LOJV1JMpvg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/planning_game.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/planning_game.html
new file mode 100644
index 0000000..5b94687
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/planning_game.html
@@ -0,0 +1,120 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\planning_game.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: planning_game.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,2.7371805612676613E-305 CRC: 2201201175 -->Planning Game<!-- END:presentationName,2.7371805612676613E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-CPHs6R59_druVDY6nRjHEw CRC: 1687581123 --><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning_game__practice_of"
+name="XE_planning_game__practice_of"></a><a id="XE_engineering_practices__planning_game"
+name="XE_engineering_practices__planning_game"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The purpose of planning is to ensure that we are working on the most valuable things at all times. As much as we would
+ like to, planning is not about predicting the future. Even the best, most thought out plans need to be continually
+ refined. They require continuous and constant feedback to be useful.
+</p>
+<p>
+ XP proposes the following planning hierarchy:
+</p>
+<ul>
+ <li>
+ Projects are split into releases that typically last two to three months.
+ </li>
+ <li>
+ Releases are split into iterations that typically last two to three weeks.
+ </li>
+ <li>
+ Iterations are planned into tasks that typically last one to two days.
+ </li>
+</ul>
+<p>
+ The XP planning game has two main activities:
+</p>
+<h4>
+ Release Planning
+</h4>
+<ul>
+ <li>
+ Customer presents user stories to the team.
+ </li>
+ <li>
+ Programmers estimate the user stories.
+ </li>
+ <li>
+ Customers selects a set of user stories for the next release. The total of the estimates of the selected stories
+ cannot exceed the team's previous release velocity (how much they did the previous release).
+ </li>
+</ul>
+<h4>
+ Iteration Planning
+</h4>
+<ul>
+ <li>
+ Customer presents the user stories that will be worked on for the iteration. These stories usually come from the
+ release. Stories not in the release can be selected for the iteration, but the customer will have to push out an
+ existing story of the same size out of the iteration and the release. This is done so the team does not commit to
+ do more work than they have shown they can do in the past.
+ </li>
+ <li>
+ Programmers break down the stories into engineering tasks.
+ </li>
+ <li>
+ Programmers sign up and estimate engineering tasks.
+ </li>
+ <li>
+ Programmers do a sanity check to make sure all these tasks can be done by comparing against what was done the
+ previous iteration.
+ </li>
+ <li>
+ If there is too much to do, the customer will drop one or more user story from the iteration.
+ </li>
+ <li>
+ If there is not enough work, the customer can add one or more story to fill the iteration.
+ </li>
+</ul>
+<h3>
+ Benefits
+</h3>
+<ul class="noindent">
+ <li>
+ Provides <b>quick and meaningful feedback</b>.
+ </li>
+ <li>
+ Provides <b>lots of opportunities</b> to use that feedback <b>to steer the team to success</b>.
+ </li>
+ <li>
+ Provides <b>clear</b>, long-term <b>strategic</b> (release plan) <b>and</b> short-term <b>tactical goals</b>
+ (iteration plan).
+ </li>
+ <li>
+ <b>Allows the team to manage themselves</b> (task list).
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ See the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
+ guid="6.7335956461328426E-307">Planning Game Guidelines</a>.
+</p><!-- END:mainDescription,-CPHs6R59_druVDY6nRjHEw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/product_quality.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/product_quality.html
new file mode 100644
index 0000000..04fffdd
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/product_quality.html
@@ -0,0 +1,190 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\product_quality.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: product_quality.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.712584012051524E-306 CRC: 2674103454 -->Product Quality<!-- END:presentationName,3.712584012051524E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-nGaswirSOYturOoUWwGdRw CRC: 4244529603 --><h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ If you're serious about producing an excellent product, you face two problems:
+</p>
+<ul>
+ <li>
+ How do you know when the product is good enough?
+ </li>
+ <li>
+ If the product is not yet good enough, how do you assure that the stakeholders involved know that?
+ </li>
+</ul>
+<p>
+ The answer to the first question lets you release the product. The answer to the second question helps you avoid
+ releasing a bad product.
+</p>
+<p>
+ You might think: "I don't want to ship a merely good enough product; I want to ship a <i>great</i> product!" Let's
+ explore that. What happens when you tell your coworkers, managers, or investors that you have high quality standards
+ and intend to ship a great product? If it's early in the project cycle, they probably nod and smile. Everyone likes
+ quality. However, if it's late in the project cycle, you're under a lot of pressure to complete the project. Creating a
+ great product might require that you perform extensive testing, fix many problems (even small ones), add features, or
+ even scrap and rewrite a large part of the code. You will also have to resolve disputes over different visions of good
+ quality. Greatness is hard work. Perfection is even harder! Eventually, the people who control the project will come to
+ you and say something like: "Perfection would be nice, but we have to be practical. We're running a business. Quality
+ is good, but not quality <i>at any cost</i>. As you know, all software has bugs."
+</p>
+<p>
+ Greatness can be a motivating goal. It appeals to the pride you have in your work. But there are problems with using
+ what amounts to "if quality is good, more quality must be better" to justify the pursuit of excellence. For one thing,
+ making such an argument can portray you as a quality fanatic, rather than a balanced thinker. For another thing, it
+ ignores the cost factor. A BMW is a nice car, but it costs a lot more than a Saturn. A Saturn may not be the ultimate
+ driving experience, but it's nice for the money. In leaving out cost, the <i><b>more is better</b></i> argument also
+ ignores diminishing returns. The better your product, the harder it gets to justify further improvement. While you
+ labor to gold-plate one aspect of a product, out of necessity you must ignore other aspects of the product or even the
+ potential opportunities presented by another project. The business has to make choices every day about the best use of
+ its resources. There are factors other than quality that must be considered.
+</p>
+<p>
+ The <i><b>good enough quality</b></i> concept (GEQ) is, paradoxically, a more effective argument than <i><b>more is
+ better</b></i>, because it provides a target that is either achievable or not achievable, in which case it becomes a de
+ facto argument for canceling or rechartering the project.
+</p>
+<h3>
+ <a id="GEQParadigms" name="GEQParadigms">Paradigms of Good Enough</a>
+</h3>
+<p>
+ Most businesses practice some form of good enough reasoning about their products. The only ones that don't are those
+ who believe they have achieved perfection, because they lack the imagination and skill to see how their products might
+ be improved.
+</p>
+<p>
+ Here are some models of <i><b>good enough</b></i> that have been tried. Some of them are more effective than others,
+ depending on the situation:
+</p>
+<ul>
+ <li>
+ <b>Not too Bad</b> <i>("we're not dead yet") -</i> Our quality only has to be good enough so we can continue to
+ stay in business. Make it good enough so that we aren't successfully sued.<br />
+ <br />
+ </li>
+ <li>
+ <b>Positive Infallibility</b> <i>("anything we do is good") -</i> Our organization is the best in the world.
+ Because we're so good, anything we do is automatically good. Think about success. Don't think about failure because
+ "negative" thinking makes for poor quality.<br />
+ <br />
+ </li>
+ <li>
+ <b>Righteous Exhaustion</b> <i>("perfection or bust") -</i> No product is good enough; it's effort that counts. And
+ only our complete exhaustion will be a good enough level of effort. Business issues are not our concern. We will do
+ everything we possibly can to make it perfect. Since we'll never be finished improving, someone will have to come
+ in and pry it from our fingers if they want it. Then they will bear the blame for any quality problems, not
+ us.<br />
+ <br />
+ </li>
+ <li>
+ <b>Customer is Always Right</b> <i>("customers seem to like it") -</i> If customers like it, it must be good
+ enough. Of course, you can't please everybody all the time. And if a current or potential customer doesn't like the
+ product, it's up to them to let us know. We can't read their minds.<br />
+ <br />
+ </li>
+ <li>
+ <b>Defined Process</b> <i>("we follow a Good Process") -</i> Quality is the result of the process we use to build
+ the product. We have defined our process and we think it's a good process. Therefore, as long as we follow the
+ process, a good enough product will inevitably result.<br />
+ <br />
+ </li>
+ <li>
+ <b>Static Requirements</b> <i>("we satisfy the Requirements") -</i> We have defined quality in terms of objective,
+ quantifiable, noncontroversial goals. If we meet those goals, we have a good enough product, no matter what other
+ subjective, non-quantifiable, controversial goals might be suggested.<br />
+ <br />
+ </li>
+ <li>
+ <b>Accountability</b> <i>("we fulfill our promises") -</i> Quality is defined by contract. We promise to do certain
+ things and achieve certain goals. If we fulfill our contract, that's good enough.<br />
+ <br />
+ </li>
+ <li>
+ <b>Advocacy</b> <i>("we make every reasonable effort") -</i> We advocate excellence. Throughout the project, we
+ look for ways to prevent problems, and to find and fix the ones we couldn't prevent. If we work faithfully toward
+ excellence, that will be good enough.<br />
+ <br />
+ </li>
+ <li>
+ <b>Dynamic Tradeoff</b> <i>("we weigh many factors") -</i> With respect to our mission and the situation at hand, a
+ product is good enough when it has sufficient benefits, no critical problems, its benefits sufficiently outweigh
+ its non-critical problems, and it would cause more harm than good to continue improving it.<br />
+ <br />
+ </li>
+</ul>
+<h3>
+ <a id="IsHighQualityExpensive" name="IsHighQualityExpensive">Is High Quality Necessarily More Expensive?</a>
+</h3>
+<p>
+ Depending on a lot of factors, such as process, skill, technology, tools, environment, and culture, you may be able to
+ produce a much higher quality product for the same cost. A more testable and maintainable product will cost less to
+ improve and other costs are specifically associated with poor quality, such as support costs and costs to the customer.
+</p>
+<p>
+ The cost of quality is a complex issue and it's difficult to make broad generalizations. However, you can say with
+ certainty that you can always spend more time on much better tests, much more error handling, and more fixing or
+ rewriting of every part of the product. No matter how good you are, that costs something. And if you can't think of
+ more improvements to make, it's more likely that you've reached the upper limit of your imagination, not of quality.
+</p>
+<p>
+ In the software industry GEQ is inspired more as a response to one particular cost than any other: the cost of not
+ releasing the product <i>soon enough</i>. The specter of the market window, or the external deadline, imposes penalties
+ upon us if we can't meet the challenge. That's why the ends of projects are so often characterized by frenzied triage.
+ If you want to know what an organization really believes is good enough, and how well prepared they are for it, witness
+ the last three days of any six-month software project. See what happens when a new problem is reported on the last day.
+</p>
+<h3>
+ <a id="Quantification" name="Quantification">Wouldn't Quantification Help?</a>
+</h3>
+<p>
+ It can be tempting to reduce quality to a number, then set a numerical threshold that represents good enough quality.
+ This is a problem, because you can only measure factors that <i>relate</i> to quality. You can't measure quality
+ itself. This is partly because the word "quality" is just a label for a relationship between a person and a thing.
+ "This product is high in quality" is just another way of saying "Somebody values this product". It's a statement about
+ the product, but also a statement about people and the surrounding context. Even if the product stays the same, people
+ and situations change, so there can be no single, static, <i>true</i> measure of quality.
+</p>
+<p>
+ There are many measures you might use to get a sense of quality, even if you can't measure it completely and
+ objectively. Even so, the question of what quality is good enough requires sophisticated judgment. You can't escape
+ from the fact that, in the end, people have to think it through and make a judgment. For a simple product, that
+ judgment might be easy. For a complex, high-stakes product, it's very difficult.
+</p>
+<h3>
+ <a id="FurtherInfo" name="FurtherInfo">Further Information</a>
+</h3>
+<p>
+ To assist you with evaluating product quality, the following types of information are available for most of the
+ artifacts included in the Unified Process:
+</p>
+<ul>
+ <li>
+ Artifact Guidelines and Checkpoints: information on how to develop, evaluate, and use the artifact.
+ </li>
+ <li>
+ Templates: "models" or prototypes of the artifact, providing structure and guidance for content.<br />
+ </li>
+</ul><!-- END:mainDescription,-nGaswirSOYturOoUWwGdRw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/refactoring_xp_programming.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/refactoring_xp_programming.html
new file mode 100644
index 0000000..f4fdd0e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/refactoring_xp_programming.html
@@ -0,0 +1,96 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\refactoring_xp_programming.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: refactoring_xp_programming.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.4410217108363206E-306 CRC: 3501494639 -->Refactoring<!-- END:presentationName,1.4410217108363206E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-U8NScY6mORb4XPcNZ_mrEA CRC: 3802477967 --><a id="XE_xp__refactoring" name="XE_xp__refactoring"></a><a id="XE_refactoring__practice_of"
+name="XE_refactoring__practice_of"></a><a id="XE_engineering_practices__refactoring"
+name="XE_engineering_practices__refactoring"></a>
+<h3>
+ Description
+</h3>
+<p>
+ Refactoring is the practice of improving the design of a system without changing its behavior. Refactoring is a
+ critical practice and skill in iterative development. The programmer is either adding a new feature or refactoring. XP
+ programmers consciously choose between refactoring and adding new functionality on a minute-by-minute basis. Some
+ refactorings are trivial, such as renaming or moving things. Other refactorings allow you to exchange procedural logic
+ with polymorphism, and still larger refactorings exist to introduce design patterns.
+</p>
+<p>
+ While processes like Extreme Programming rely on refactoring to let the design emerge, the usefulness of refactoring
+ extends beyond the Agile Methodologies. As feature requests and bug fixes require changes to a system, refactoring
+ techniques allow the programmers to maintain a good design. Refactoring can also be used to improve the design of an
+ existing system.
+</p>
+<p>
+ Refactoring is not new. Developers have been refactoring for years, though only recently have people started to catalog
+ refactorings. Refactoring has become such an important part of development that professional-level Integrated
+ Development Environments (IDEs) either include built-in tools or have plug-ins to provide refactoring support.
+</p>
+<p>
+ If your system isn't being refactored as it is modified, your design deteriorates; methods become longer, classes take
+ on more responsibility, more code gets cut and pasted around your system, previously cut-and-pasted code has to be
+ modified in several places.
+</p>
+<p>
+ If your system becomes brittle and inflexible, your developers will have to spend more time and money to add features
+ or fix bugs. As the design continues to deteriorate, fixing one bug creates two more, or the cost of adding a new
+ feature out weighs the benefit of having it because so much of the system has to be modified. There are many analogies
+ to describe this battle against entropy; from cleaning as you go to design debt.
+</p>
+<p>
+ Knowing the refactorings isn't enough. Developers must be able to identify problem areas of the program design (often
+ referred to as "smells"). These are the places where refactoring can be used to improve the design of the code. Design
+ skill and experience are needed to recognize bad code smells.
+</p>
+<p>
+ Automated tests provide a safety net when making changes. The automated tests report when the functionality of the
+ system changes. Make a structural change to the software; see that the tests still pass. You can confidently refactor.
+</p>
+<p>
+ Where do all these tests come from? In XP, they are developed using <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
+ guid="1.620567348185129E-306">Test-Driven Development</a>. It is possible to refactor without tests, but you run the
+ risk of unknowingly introducing bugs or breaking existing functionality.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Allows the design to emerge over time.
+ </li>
+ <li>
+ Keeps the design from rotting.
+ </li>
+ <li>
+ Reduces cost of change.
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ See the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html"
+ guid="8.137126904637637E-306">Refactoring Guidelines</a>.
+</p><!-- END:mainDescription,-U8NScY6mORb4XPcNZ_mrEA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img1.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img1.gif
new file mode 100644
index 0000000..8082009
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img2.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img2.gif
new file mode 100644
index 0000000..381f405
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img2.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img3.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img3.gif
new file mode 100644
index 0000000..e7f17aa
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/dvltst-img3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img1.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img1.gif
new file mode 100644
index 0000000..8b22b05
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img2.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img2.gif
new file mode 100644
index 0000000..d17d10e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img2.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img3.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img3.gif
new file mode 100644
index 0000000..182076e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img4.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img4.gif
new file mode 100644
index 0000000..d06ff22
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img4.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img5.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img5.gif
new file mode 100644
index 0000000..f7fc9cd
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstfrsdsg-img5.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstids_short-catalog.pdf b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstids_short-catalog.pdf
new file mode 100644
index 0000000..d88327c
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstids_short-catalog.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidsctl-img1.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidsctl-img1.gif
new file mode 100644
index 0000000..b61b1c9
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidsctl-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidsctl-img2.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidsctl-img2.gif
new file mode 100644
index 0000000..9951dc2
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidsctl-img2.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidslst-img1.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidslst-img1.gif
new file mode 100644
index 0000000..ac8fd5f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/resources/tstidslst-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/simple_design.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/simple_design.html
new file mode 100644
index 0000000..c8480c5
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/simple_design.html
@@ -0,0 +1,133 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\simple_design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: simple_design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.6109092258980447E-306 CRC: 4110814805 -->Simple Design<!-- END:presentationName,1.6109092258980447E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-0rSxLFlmQfyKrgnqi1NKrg CRC: 63014376 --><a id="XE_xp__simple_design" name="XE_xp__simple_design"></a><a id="XE_simple_design__practice_of"
+name="XE_simple_design__practice_of"></a><a id="XE_engineering_practices__simple_design"
+name="XE_engineering_practices__simple_design"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The design strategy in XP is to create the simplest design that meets your current requirements, as reflected in the
+ current test cases. In many domains, "simplest design" is ambiguous, but it is a well-defined term in XP. A simple
+ design has these four characteristics, listed in priority order:
+</p>
+<ul>
+ <li>
+ The system runs all the tests.
+ </li>
+ <li>
+ It contains no duplicate code.
+ </li>
+ <li>
+ The code states the programmers's intent very clearly.
+ </li>
+ <li>
+ It contains the fewest possible number of classes and methods.
+ </li>
+</ul>
+<p>
+ Design in Extreme Programming is much more incremental than in any other methodology. The practice of Test-Driven
+ Development describes how the system is created in many small steps, driven by tests that programmers write. Each of
+ these tests is a probe into the design of the system, allowing the developers to explore the system as it is being
+ created. This is quite a contrast to other methodologies where design is a separate phase of either the project or the
+ iteration. In XP, design quite literally happens all the time.
+</p>
+<p>
+ It takes a tremendous amount of courage to stop designing and start coding. Almost all developers are taught that they
+ should understand everything about the system before committing that knowledge to code. The reason, they've always been
+ told, is that code is hard to change. Once it is laid on its virtual paper, changing it involves understanding the
+ hidden assumptions of the original developer, unseen couplings, months-long validation and verification procedures,
+ etc. But if code could be changed with impunity, developers could afford to defer design decisions until later,
+ understand the system incrementally, and implement in pieces.
+</p>
+<p>
+ The strategy of building software in this manner is based on the following reasoning:
+</p>
+<ul>
+ <li>
+ Given that all requirements aren't known on the first day of the project, the development style must be adjusted to
+ accommodate new understanding from customers and changes in the business climate.
+ </li>
+ <li>
+ If a design decision does not have to be made now, avoid guessing by deferring the decision until it is needed. By
+ that time, there is a better chance that enough understanding will exist to support a better decision.
+ </li>
+ <li>
+ Change happens during the lifetime of a project. Decisions made once will be changed. The software must be designed
+ and implemented in such a way that changes can be accommodated easily.
+ </li>
+ <li>
+ Designs seldom survive their first skirmish with code. The act of coding provides feedback to the developer about
+ the system. This learning must be reflected in the design. If the design is already cast before coding begins, this
+ feedback is more difficult and costly to put back into the design.
+ </li>
+</ul>
+<p>
+ Here are some guidelines to help in arriving at a simple design:
+</p>
+<ul>
+ <li>
+ Look for a simple way to solve a problem. Software is hard, so there will be plenty of time for complexity later.
+ For now, keep it simple. Simple, however, does not mean stupid. Pay attention to good design principles when
+ forming a system incrementally.
+ </li>
+ <li>
+ Resist the temptation to add infrastructure or other features that might be needed later. Chances are they won't be
+ (YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design.
+ </li>
+ <li>
+ Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep
+ implementation simple. Let the second user pay for the generality.
+ </li>
+ <li>
+ Seek out and destroy duplication. The practice of <a class="elementLink"
+ href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
+ guid="1.4410217108363206E-306">Refactoring</a> is the most powerful tool in the arsenal. It is through removing
+ duplication that new classes, methods, and larger scale systems are born.
+ </li>
+ <li>
+ Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated
+ again in less time and better than the first time by leveraging what was learned the first time.
+ </li>
+</ul>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Small initial investment</b>: There is no need to invest in frameworks or generality that might be or might not
+ be required in the future.
+ </li>
+ <li>
+ <b>Maintainability</b>: Simple design will keep the design from rotting and dying prematurely. The more complex the
+ design is, the harder it is to understand and preserve and the more rapidly it will decay.
+ </li>
+ <li>
+ <b>Flexibility</b>: Simple systems are always easier to change than more complex systems.
+ </li>
+ <li>
+ <b>Agility</b>: Simple systems are faster to change than more complex systems.
+ </li>
+</ul><!-- END:mainDescription,-0rSxLFlmQfyKrgnqi1NKrg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/small_releases.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/small_releases.html
new file mode 100644
index 0000000..76875ee
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/small_releases.html
@@ -0,0 +1,54 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\small_releases.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: small_releases.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,5.762953011420275E-306 CRC: 2279552650 -->Small Releases<!-- END:presentationName,5.762953011420275E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-vcCn_ksJo5Jw27aNZb1Cvw CRC: 609473957 --><a id="XE_xp__small_releases" name="XE_xp__small_releases"></a><a id="XE_small_releases__practice_of"
+name="XE_small_releases__practice_of"></a><a id="XE_engineering_practices__small_releases"
+name="XE_engineering_practices__small_releases"></a>
+<h3>
+ Description
+</h3>
+<p>
+ There are many developers who have spent years developing software and yet never had any of it released into use.
+ Fortunately, this situation is becoming rarer, but it still happens. There are many reasons why some software never
+ gets put into production, but often a key factor is the size of releases. Releasing software is much like integrating
+ source code changes in a project: the longer you delay it, the tougher it becomes. Releasing software into production
+ frequently is a good way of getting feedback. Users will often think of issues that they would not have without actual
+ experience using the software. Getting that feedback early enhances the overall quality of the product.
+</p>
+<p>
+ In XP, we recommend release cycles of three to four months at most.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Small releases increase feedback</b>. Discrepancies between the system that is needed and the system being
+ developed are found early.
+ </li>
+ <li>
+ Putting pieces of a system into production frequently raises the quality consciousness of the project. The
+ <b>system must consistently be good enough to ship</b>.
+ </li>
+</ul><!-- END:mainDescription,-vcCn_ksJo5Jw27aNZb1Cvw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-first_design.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-first_design.html
new file mode 100644
index 0000000..ce2c7c5
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-first_design.html
@@ -0,0 +1,333 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\test-first_design.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test-first_design.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,6.556259235358794E-306 CRC: 3904523993 -->Test-first Design<!-- END:presentationName,6.556259235358794E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-3AbfvnHrCOIQS63sEjrOew CRC: 1418035710 --><a id="XE_test__developer_testing__test-first_design" name="XE_test__developer_testing__test-first_design"></a><a
+id="XE_design__test-first_design" name="XE_design__test-first_design"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Test designs are created using information from a variety of artifacts, including design artifacts such as use case
+ realizations, design models, or classifier interfaces. Tests are executed after components are created. It's typical to
+ create the test designs just before the tests are to be executed - well after the software design artifacts are
+ created. Figure 1, following, shows an example. Here, test design begins sometime toward the end of implementation. It
+ draws on the results of component design. The arrow from Implementation to Test Execution indicates that the tests
+ can't be executed until the implementation is complete.
+</p>
+<p align="center">
+ <img height="159" alt="" src="resources/tstfrsdsg-img1.gif" width="614" />
+</p>
+<p class="picturetext">
+ Fig1: Traditionally, Test Design is performed later in the life-cycle
+</p>
+<p>
+ However, it doesn't have to be this way. Although test execution has to wait until the component has been implemented,
+ test design can be done earlier. It could be done just after the design artifact is completed. It could even be done in
+ parallel with component design, as shown here:
+</p>
+<p align="center">
+ <img height="158" alt="" src="resources/tstfrsdsg-img2.gif" width="610" />
+</p>
+<p class="picturetext">
+ Fig2: Test-first Design brings test design chronologically in-line with software design
+</p>
+<p>
+ Moving the test effort "upstream" in this way is commonly called "test-first design". What are its advantages?
+</p>
+<ol>
+ <li>
+ No matter how carefully you design software, you'll make mistakes. You might be missing a relevant fact. Or you
+ might have particular habits of thought that make it hard for you to see certain alternatives. Or you might just be
+ tired and overlook something. Having other people review your design artifacts helps. They might have the facts you
+ miss, or they might see what you overlooked. It's best if these people have a different perspective than you do; by
+ looking at the design differently, they'll see things you missed.<br />
+ <br />
+ Experience has shown that the testing perspective is an effective one. It's relentlessly concrete. During software
+ design, it's easy to think of a particular field as "displaying the title of the current customer" and move on
+ without really thinking about it. During test design, you must decide <i>specifically</i> what that field will show
+ when a customer who retired from the Navy and then obtained a law degree insists on referring to himself as
+ "Lieutenant Morton H. Throckbottle (Ret.), Esq." Is his title "Lieutenant" or "Esquire"?<br />
+ <br />
+ If test design is deferred until just before test execution, as in Figure 1, you'll probably waste money. A
+ mistake in your software design will remain uncaught until test design, when some tester says, "You know, I knew
+ this guy from the Navy...", creates the "Morton" test, and discovers the problem. Now a partially or fully complete
+ implementation has to be rewritten and a design artifact has to be updated. It would be cheaper to catch the
+ problem before implementation begins.<br />
+ </li>
+ <li>
+ Some mistakes might be caught before test design. Instead, they'll be caught by the Implementer. That's still bad.
+ Implementation must grind to a halt while the focus switches from how to implement the design to what that design
+ should be. That's disruptive even when the Implementer and Designer roles are filled by the same person; it's much
+ more disruptive when they're different people. Preventing this disruption is another way in which test-first design
+ helps improve efficiency.<br />
+ </li>
+ <li>
+ Test designs help Implementers in another way-by clarifying design. If there's a question in the Implementer's mind
+ about what the design meant, the test design might serve as a specific example of the desired behavior. That will
+ lead to fewer bugs due to Implementer misunderstanding.<br />
+ </li>
+ <li>
+ There are fewer bugs even if the question <i>wasn't</i> in the Implementer's mind - but should have been. For
+ example, there might have been an ambiguity that the Designer unconsciously interpreted one way and the Implementer
+ another. If the Implementer is working from both the design and also from specific instructions about what the
+ component is supposed to do - from test cases - the component is more likely to actually do what is required.
+ </li>
+</ol>
+<h3>
+ <a id="Examples" name="Examples">Examples</a>
+</h3>
+<p>
+ Here are some examples to give you the flavor of test-first design.
+</p>
+<p>
+ Suppose you're creating a system to replace the old "ask the secretary" method of assigning meeting rooms. One of the
+ methods of the <font size="+0">MeetingDatabase</font> class is called <font size="+0">getMeeting</font>, which has this
+ signature:
+</p>
+<blockquote>
+<pre>
+Meeting getMeeting(Person, Time);
+</pre>
+</blockquote>
+<p>
+ Given a person and a time, <font size="+0">getMeeting</font> returns the meeting that person is scheduled to be in at
+ that time. If the person isn't scheduled for anything, it returns the special <font size="+0">Meeting</font> object
+ <font size="+0">unscheduled</font>. There are some straightforward test cases:
+</p>
+<ul>
+ <li>
+ The person isn't in any meeting at the given time. Is the <font size="+0">unscheduled</font> meeting returned?
+ </li>
+ <li>
+ The person is in a meeting at that time. Does the method return the correct meeting?
+ </li>
+</ul>
+<p>
+ These test cases are unexciting, but they need to be tried eventually. They might as well be created now, by writing
+ the actual test code that will someday be run. Java code for the first test might look like this:
+</p>
+<pre>
+ // if not in a meeting at given time,
+ // expect to be unscheduled.
+ public void testWhenAvailable() {
+Person fred = new Person("fred");
+Time now = Time.now();
+MeetingDatabase db = new MeetingDatabase();
+expect(db.getMeeting(fred, now) == Meeting.unscheduled);
+ }
+</pre>
+<p>
+ But there are more interesting test ideas. For example, this method searches for a match. Whenever a method searches,
+ it's a good idea to ask what should happen if the search finds more than one match. In this case, that means asking
+ "Can a person be in two meetings at once?" Seems impossible, but asking the secretary about that case might reveal
+ something surprising. It turns out that some executives are quite often scheduled into two meetings at once. Their role
+ is to pop into a meeting, "rally the troops" for some short amount of time, and then move on. A system that didn't
+ accommodate that behavior would go at least partially unused.
+</p>
+<p>
+ This is an example of test-first design done at the implementation level catching an analysis problem. There are a few
+ things to note about that:
+</p>
+<ol>
+ <li>
+ You would hope that good use-case specification and analysis would have already discovered this requirement. In
+ that case, the problem would have been avoided "upstream" and <font size="+0">getMeeting</font> would have been
+ designed differently. (It couldn't return a meeting; it would have to return a set of meetings.) But analysis
+ always misses some problems, and it's better for them to be discovered during implementation than after
+ deployment.<br />
+ </li>
+ <li>
+ In many cases, Designers and Implementers won't have the domain knowledge to catch such problems - they won't have
+ the opportunity or time to quiz the secretary. In that case, the person designing tests for <font
+ size="+0">getMeeting</font> would ask, "is there a case in which two meetings should be returned?", think for a
+ while, and conclude that there wasn't. So test-first design doesn't catch every problem, but the mere fact of
+ asking the right kinds of questions increases the chance a problem will be found.<br />
+ </li>
+ <li>
+ Some of the same testing techniques that apply during implementation also apply to analysis. Test-first design can
+ be done by analysts as well, but that's not the topic of this page.
+ </li>
+</ol>
+<p>
+ The second of the three examples is a statechart model for a heating system.
+</p>
+<p align="center">
+ <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
+</p>
+<p class="picturetext">
+ Fig3: HVAC Statechart
+</p>
+<p>
+ A set of tests would traverse all the arcs in the statechart. One test might begin with an idle system, inject a Too
+ Hot event, fail the system during the Cooling/Running state, clear the failure, inject another Too Hot event, then run
+ the system back to the Idle state. Since that does not exercise all the arcs, more tests are needed. These kinds of
+ tests look for various kinds of implementation problems. For example, by traversing every arc, they check whether the
+ implementation has left one out. By using sequences of events that have failure paths followed by paths that should
+ successfully complete, they check whether error-handling code fails to clean up partial results that might affect later
+ computation. (For more about testing statecharts, see <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
+ guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Activity Diagrams</a>.)
+</p>
+<p>
+ The final example uses part of a design model. There's an association between a creditor and an invoice, where any
+ given creditor can have more than one invoice outstanding.
+</p>
+<p align="center">
+ <img height="45" alt="" src="resources/tstfrsdsg-img4.gif" width="186" />
+</p>
+<p class="picturetext">
+ Fig4: Association between Creditor and Invoice Classes
+</p>
+<p>
+ Tests based on this model would exercise the system when a creditor has no invoices, one invoice, and a large number of
+ invoices. A tester would also ask whether there are situations in which an invoice might need to be associated with
+ more than one creditor, or where an invoice has no creditor. (Perhaps the people who currently run the paper-based
+ system the computer system is to replace use creditor-less invoices as a way to keep track of pending work). If so,
+ that would be another problem that should have been caught in Analysis.
+</p>
+<h3>
+ <a id="WhoDoesTest-FirstDesign" name="WhoDoesTest-FirstDesign">Who does test-first design?</a>
+</h3>
+<p>
+ Test-first design can be done by either the author of the design or by someone else. It's common for the author to do
+ it. The advantage is that it reduces communication overhead. The Designer and Test Designer don't have to explain
+ things to each other. Further, a separate Test Designer would have to spend time learning the design well, whereas the
+ original Designer already knows it. Finally, many of these questions - like "what happens if the compressor fails in
+ state X?" - are natural questions to ask during both software artifact design and test design, so you might as well
+ have the same person ask them exactly once and write the answers down in the form of tests.
+</p>
+<p>
+ There are disadvantages, though. The first is that the Designer is, to some extent, blind to his or her own mistakes.
+ The test design process will reveal some of that blindness, but probably not as much as a different person would find.
+ How much of a problem this is seems to vary widely from person to person and is often related to the amount of
+ experience the Designer has.
+</p>
+<p>
+ Another disadvantage of having the same person do both software design and test design is that there's no parallelism.
+ Whereas allocating the roles to separate people will take more total effort, it will probably result in less elapsed
+ calendar time. If people are itching to move out of design and into implementation, taking time for test design can be
+ frustrating. More importantly, there's a tendency to skimp on the work in order to move on.
+</p>
+<h3>
+ <a id="CanAllTestDesignBeDoneAtComponentDesignTime" name="CanAllTestDesignBeDoneAtComponentDesignTime">Can all test
+ design be done at component design time?</a>
+</h3>
+<p>
+ No. The reason is that not all decisions are made at design time. Decisions made during implementation won't be
+ well-tested by tests created from the design. The classic example of this is a routine to sort arrays. There are many
+ different sorting algorithms with different tradeoffs. Quicksort is usually faster than an insertion sort on large
+ arrays, but often slower on small arrays. So a sorting algorithm might be implemented to use Quicksort for arrays with
+ more than 15 elements, but insertion sort otherwise. That division of labor might be invisible from design artifacts.
+ You <i>could</i> represent it in a design artifact, but the Designer might have decided that the benefit of making such
+ explicit decisions wasn't worthwhile. Since the size of the array plays no role in the design, the test design might
+ inadvertently use only small arrays, meaning that none of the Quicksort code would be tested at all.
+</p>
+<p>
+ As another example, consider this fraction of a sequence diagram. It shows a <font size="+0">SecurityManager</font>
+ calling the <font size="+0">log()</font> method of <font size="+0">StableStore</font>. In this case, though, the <font
+ size="+0">log()</font> returns a failure, which causes <font size="+0">SecurityManager</font> to call <font
+ size="+0">Connection.close()</font>.
+</p>
+<p align="center">
+ <img height="161" alt="" src="resources/tstfrsdsg-img5.gif" width="303" />
+</p>
+<p class="picturetext">
+ Fig5: SecurityManager sequence diagram instance
+</p>
+<p>
+ This is a good reminder to the Implementer. Whenever <font size="+0">log()</font> fails, the connection must be closed.
+ The question for testing to answer is whether the Implementer really did it-and did it correctly-in <i>all</i> cases or
+ just in <i>some</i>. To answer the question, the Test Designer must find all the calls to <font
+ size="+0">StableStore.log()</font> and make sure each of those call points is given a failure to handle.
+</p>
+<p>
+ It might seem odd to run such a test, given that you've just looked at all the code that calls <font
+ size="+0">StableStore.log()</font>. Can't you just check to see if it handles failure correctly?
+</p>
+<p>
+ Perhaps inspection might be enough. But error-handling code is notoriously error-prone because it often implicitly
+ depends on assumptions that the existence of the error has violated. The classic example of this is code that handles
+ allocation failures. Here's an example:
+</p>
+<blockquote>
+<pre>
+while (true) { // top level event loop
+ try {
+XEvent xe = getEvent();
+... // main body of program
+ } catch (OutOfMemoryError e) {
+emergencyRestart();
+ }
+}
+</pre>
+</blockquote>
+<p>
+ This code attempts to recover from out of memory errors by cleaning up (thus making memory available) and then
+ continuing to process events. Let's suppose that's an acceptable design. <font size="+0">emergencyRestart</font> takes
+ great care not to allocate memory. The problem is that <font size="+0">emergencyRestart</font> calls some utility
+ routine, which calls some other utility routine, which calls some other utility routine-which allocates a new object.
+ Except that there's no memory, so the whole program fails. These kinds of problems are hard to find through inspection.
+</p>
+<h3>
+ <a id="Test-FirstDesignAndRUPPhases" name="Test-FirstDesignAndRUPPhases">Test-first design and the phases
+ of Unified</a> Process
+</h3>
+<p>
+ Up to this point, we've implicitly assumed that you'd do as much test design as possible as early as possible. That is,
+ you'd derive all the tests you could from the design artifact, later adding only tests based on implementation
+ internals. That may not be appropriate in the Elaboration phase, because such complete testing may not be aligned with
+ an iteration's objectives.
+</p>
+<p>
+ Suppose an architectural prototype is being built to demonstrate product feasibility to investors. It might be based on
+ a few key use-case instances. Code should be tested to see that it supports them. But is there any harm if further
+ tests are created? For example, it might be obvious that the prototype ignores important error cases. Why not document
+ the need for that error handling by writing test cases that will exercise it?
+</p>
+<p>
+ But what if the prototype does its job and reveals that the architectural approach won't work? Then the architecture
+ will be thrown away - along with all those tests for error-handling. In that case, the effort of designing the tests
+ will have yielded no value. It would have been better to have waited, and only designed those tests needed to check
+ whether this proof-of-concept prototype really proves the concept.
+</p>
+<p>
+ This may seem a minor point, but there are strong psychological effects in play. The Elaboration phase is about
+ addressing major risks. The whole project team should be focused on those risks. Having people concentrating on minor
+ issues drains focus and energy from the team.
+</p>
+<p>
+ So where might test-first design be used successfully in the Elaboration phase? It can play an important role in
+ adequately exploring architectural risks. Considering how, precisely, the team will know if a risk has been realized or
+ avoided will add clarity to the design process and may well result in a better architecture being built the first time.
+</p>
+<p>
+ During the Construction phase, design artifacts are put into their final form. All the required use-case realizations
+ are implemented, as are the interfaces for all classes. Because the phase objective is completeness, complete
+ test-first design is appropriate. Later events should invalidate few, if any, tests.
+</p>
+<p>
+ The Inception and Transition phases typically have less focus on design activities for which testing is appropriate.
+ When it is, test-first design is applicable. For example, it could be used with candidate proof-of-concept work in
+ Inception. As with Construction and Elaboration phase testing, it should be aligned with iteration objectives.
+</p><!-- END:mainDescription,-3AbfvnHrCOIQS63sEjrOew -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-ideas_catalog.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-ideas_catalog.html
new file mode 100644
index 0000000..14b1f8b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-ideas_catalog.html
@@ -0,0 +1,479 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\test-ideas_catalog.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test-ideas_catalog.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.2384224477983028E-305 CRC: 143257589 -->Test-Ideas Catalog<!-- END:presentationName,1.2384224477983028E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-OrjIrRLW6v_XnqLUQ9GYaQ CRC: 1133080600 --><a id="XE_test-ideas_catalog__concept_of" name="XE_test-ideas_catalog__concept_of"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Much of programming involves taking things you've used over and over before, and then using them yet again in a
+ different context. Those things are typically of certain classes-data structures (such as linked lists, hash tables, or
+ relational databases) or <a href="./../../../glossary/glossary.htm#operation" target="_blank"><i>operations</i></a>
+ (such as searching, sorting, creating temporary files, or popping up a browser window). For example, two customer
+ relational databases will have many clichéd characteristics.
+</p>
+<p>
+ The interesting thing about these clichés is that they have clichéd <a href="./../../../glossary/glossary.htm#fault"
+ target="_blank"><i>faults</i></a>. People do not invent imaginative new ways to insert something incorrectly into a
+ doubly-linked list. They tend to make the same mistakes that they and others have made before. A programmer who pops up
+ a browser window might make one of these clichéd mistakes:
+</p>
+<ul>
+ <li>
+ creates a new window when one that's already open should be reused
+ </li>
+ <li>
+ fails to make an obscured or minimized browser window visible
+ </li>
+ <li>
+ uses Internet Explorer when the user has chosen a different default browser
+ </li>
+ <li>
+ fails to check whether JavaScript is enabled
+ </li>
+</ul>
+<p>
+ Since faults are clichéd, so are the <a href="./../../../glossary/glossary.htm#test_idea" target="_blank"><i>test
+ ideas</i></a> that can find them. Put these test ideas in your test-idea catalog so you can reuse them.
+</p>
+<h3>
+ <a id="HowCatalogsFindFaults" name="HowCatalogsFindFaults">How a Test-Ideas Catalog Finds Faults</a>
+</h3>
+<p>
+ One of the virtues of a catalog is that a single test idea can be useful for finding more than one underlying fault.
+ Here's an example of one idea that finds two faults.
+</p>
+<p>
+ The first fault was in a C compiler. This compiler took command-line options like "-table" or "-trace" or "-nolink".
+ The options could be abbreviated to their smallest unique form. For example, "-ta" was as good as "-table". However,
+ "-t" was not allowed, because it was ambiguous: it could mean either "-table" or "-trace".
+</p>
+<p>
+ Internally, the command-line options were stored in a table like this:
+</p>
+<div align="left">
+ <table cellspacing="0" cellpadding="2" width="25%" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ -table
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ -trace
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ -nolink
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ When an option was encountered on the command line, it was looked up in the table. It matched if it was the prefix of
+ any table entry; that is, "-t" matched "-table". After one match was found, the rest of the table was searched for
+ another match. Another match would be an error, because it would indicate ambiguity.
+</p>
+<p>
+ The code that did the searching looked like this:
+</p>
+<blockquote>
+<pre>
+for (first=0; first < size; first++) {
+ if (matches(entry[first], thing_sought)) {
+/* at least one match */
+for(dup=first+1; dup < size; dup++)
+ /* search for another */
+ if (matches(entry[dup], thing_sought))
+ /* extra match */
+ break; /* error out */
+return first;
+ }
+}
+return -1; /* Not found or ambiguity */
+</pre>
+</blockquote>
+<p>
+ Do you see the problem? It's fairly subtle.
+</p>
+<p>
+ The problem is the break statement. It's intended to break out of the outermost enclosing loop when a duplicate match
+ is found, but it really breaks out of the inner one. That has the same effect as not finding a second match: the index
+ of the first match is returned.
+</p>
+<p>
+ Notice that this fault can only be found if the option being sought for matches twice in the table, as "-t" would.
+</p>
+<p>
+ Now let's look at a second, completely different fault.
+</p>
+<p>
+ The code takes a string. It is supposed to replace the last '=' in the string with a '+'. If there is no '=', nothing
+ is done. The code uses the standard C library routine <font size="+0">strchr</font> to find the location of '='. Here's
+ the code:
+</p>
+<blockquote>
+<pre>
+ptr = strchr(string, '='); /* Find last = */
+if (ptr != NULL_CHAR)
+ *ptr = '+';
+</pre>
+</blockquote>
+<p>
+ This problem here is also somewhat subtle.
+</p>
+<p>
+ The function <font size="+0">strchr</font> returns the <i>first</i> match in the string, not the last. The correct
+ function is <font size="+0">str<b><u>r</u></b>chr</font>. The problem was most likely a typographical error. (Actually,
+ the deep underlying problem is that it's definitely unwise to put two functions that differ only by a typo into a
+ standard library.)
+</p>
+<p>
+ This fault can only be found when there are two or more equal signs in the input. That is:
+</p>
+<ul>
+ <li>
+ "a=b" would return the correct result, "a+b".
+ </li>
+ <li>
+ "noequals" would return the correct result, "noequals".
+ </li>
+ <li>
+ "a=b=c" would incorrectly return "a+b=c", not the correct "a=b+c"
+ </li>
+</ul>
+<p>
+ What's interesting and useful here is that we have two faults with completely different root causes (typographical
+ error, misunderstanding of a C construct) and different manifestations in the code (wrong function called, misuse of
+ break statement) that can be found by the <i>same</i> test idea (search for something that occurs twice).
+</p>
+<h3>
+ <a id="GoodCatalogs" name="GoodCatalogs">A Good Test-Ideas Catalog</a>
+</h3>
+<p>
+ What makes a good catalog?
+</p>
+<ul>
+ <li>
+ It contains a small set of test ideas that can find a much larger set of underlying faults.
+ </li>
+ <li>
+ It's easy to read quickly (skim). You should be able to skip test ideas that are not relevant to your situation.
+ </li>
+ <li>
+ It contains only test ideas that you will use. For example, someone who doesn't ever deal with Web browsers
+ shouldn't have to keep skipping over test ideas for programs that use Web browsers. Someone working on game
+ software will want a shorter catalog than someone working on safety-critical software. The game person can afford
+ to concentrate only on the test ideas with the highest chance of finding faults.
+ </li>
+</ul>
+<p>
+ Given these rules, it seems best to have more than one catalog. Some data and operations are common to all programming,
+ so their test ideas can be put into a catalog that all programmers can use. Others are specific to a particular domain,
+ so test ideas for them can be put into a catalog of domain-specific test ideas.
+</p>
+<p>
+ A sample catalog (<a href="./resources/tstids_short-catalog.pdf" target="_blank">tstids_short-catalog.pdf</a>) (<a
+ href="http://www.adobe.com/products/acrobat/alternate.html">Get Adobe Reader</a>), used in the following example, is a
+ good one from which to begin. <a href="../../../examples/extrnlcntrbtns/test/tstatmtch.htm">Test Ideas for Mixtures of
+ ANDs and ORs</a> provides another example.
+</p>
+<h3>
+ <a id="UsingACatalogExample" name="UsingACatalogExample">An Example of Using a Test-Ideas Catalog</a>
+</h3>
+<p>
+ Here's how you might use the sample catalog (<a href="./resources/tstids_short-catalog.pdf"
+ target="_blank">tstids_short-catalog.pdf</a>) (<a href="http://www.adobe.com/products/acrobat/alternate.html">Get
+ Acrobat Reader</a>). Suppose you're implementing this method:
+</p>
+<blockquote>
+<pre>
+void applyToCommonFiles(Directory d1,
+ Directory d2,
+ Operation op);
+</pre>
+</blockquote>
+<p>
+ <font size="+0">applyToCommonFiles</font> takes two directories as arguments. When a file in the first directory has
+ the same name as a file in the second, <font size="+0">applyToCommonFiles</font> performs some operation on that pair
+ of files. It descends subdirectories.
+</p>
+<p>
+ The method for using the catalog is to scan through it looking for major headings that match your situation. Consider
+ the test ideas under each heading to see if they are relevant, and then write those that are relevant into a <a
+ class="elementLink" href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html"
+ guid="8.834380241450745E-306">Test-Ideas List</a>.
+</p>
+<p>
+ <b>Note:</b> This step-by-step description might make using the catalog seem laborious. It takes longer to read about
+ creating the checklist than it does to actually create one.
+</p>
+<p>
+ So, in the case of <font size="+0">applyToCommonFiles</font>, you might apply the catalog in the manner described
+ throughout the rest of this section.
+</p>
+<p>
+ The first entry is for <b>Any Object</b>. Could any of the arguments be null pointers? This is a matter of the contract
+ between <font size="+0">applyToCommonFiles</font> and its callers. The contract could be that the callers will not pass
+ in a null pointer. If they do, you can't rely on th expected behavior: <font size="+0">applyToCommonFiles</font> could
+ perform any action. In such a case, no test is appropriate, since nothing <font size="+0">applyToCommonFiles</font>
+ does can be wrong. If, however, <font size="+0">applyToCommonFiles</font> is required to check for null pointers, the
+ test idea would be useful. Let's assume the latter, which gives us this starting Test-Ideas List:
+</p>
+<ul>
+ <li>
+ d1 is null (error case)
+ </li>
+ <li>
+ d2 is null (error case)
+ </li>
+ <li>
+ op is null (error case)
+ </li>
+</ul>
+<p>
+ The next catalog entry is <b>Strings</b>. The names of the files are strings, and they're compared to see if they
+ match. The idea of testing with the empty string ("") doesn't seem useful. Presumably some standard string comparison
+ routines will be used, and they will handle empty strings correctly.
+</p>
+<p>
+ But wait... If there are strings being compared, what about case? Suppose <font size="+0">d1</font> contains a file
+ named "File" and <font size="+0">d2</font> contains a file named "file". Should those files match? On UNIX, clearly
+ not. On Microsoft® Windows®, they almost certainly should. That's another test idea:
+</p>
+<ul>
+ <li>
+ Files match in the two directories, but the case of the names is different.
+ </li>
+</ul>
+<p>
+ Notice that this test idea didn't come directly from the catalog. However, the catalog drew our attention to a
+ particular aspect of the program (file names as strings), and our creativity gave us an additional idea. It's important
+ not to use the catalog too narrowly-use it as a brainstorming technique, a way of inspiring new ideas.
+</p>
+<p>
+ The next entry is <b>Collections</b>. A directory is a collection of files. Many programs that handle collections fail
+ on the empty collection. A few that handle the empty collection, or collections with many elements, fail on collections
+ with exactly one element. So these ideas are useful:
+</p>
+<ul>
+ <li>
+ d1 is empty
+ </li>
+ <li>
+ d2 is empty
+ </li>
+ <li>
+ d1 has exactly one file
+ </li>
+ <li>
+ d2 has exactly one file
+ </li>
+</ul>
+<p>
+ The next idea is to use a collection of the maximum possible size. This is useful because programs like <font
+ size="+0">applyToCommonFiles</font> are often tested with trivial little directories. Then some user comes along and
+ applies them to two huge directory trees with thousands of files in them, only to discover that the program is
+ grotesquely memory inefficient and can't handle that realistic case.
+</p>
+<p>
+ Now, testing the absolute maximum size for a directory is not important; it only needs to be as large as a user might
+ try. However, at the very least, there should be <i>some</i> test with more than three files in a directory:
+</p>
+<ul>
+ <li>
+ d1 contains very many files
+ </li>
+ <li>
+ d2 contains very many files
+ </li>
+</ul>
+<p>
+ The final test idea (duplicate elements) doesn't apply to directories of files. That is, if you have a directory with
+ two files that have the same name, you have a problem independent of <font size="+0">applyToCommonFiles</font>-your
+ file system is corrupt.
+</p>
+<p>
+ The next catalog entry is <b>Searching</b>. Those ideas can be translated into <font
+ size="+0">applyToCommonFiles</font> terms like this:
+</p>
+<ul>
+ <li>
+ d1 and d2 have no files in common (all the names are different)
+ </li>
+ <li>
+ d1 and d2 have exactly one file in common (it's alphabetically the last element in the directory)
+ </li>
+ <li>
+ d1 and d2 have more than one file in common
+ </li>
+</ul>
+<p>
+ The final test idea checks whether <font size="+0">applyToCommonFiles</font> terminates too soon. Does it return as
+ soon as it finds the first match? The parenthetical remark in the test idea before that assumes that the program will
+ fetch the list of files in a directory using some library routine that returns them, sorted alphabetically. If not, it
+ might be better to find out what the last one really is (the most recently created?) and make that be the match. Before
+ you devote a lot of time to finding out how files are ordered, though, ask yourself how likely it is that putting the
+ matching element last will make finding defects easier. Putting an element last in a collection is more useful if the
+ code explicitly steps through the collection using an index. If it's using an iterator, it's extremely unlikely that
+ the order matters.
+</p>
+<p>
+ Let's look at one more entry in the sample catalog. The <b>Linked structures</b> entry reminds us that we're comparing
+ directory <i>trees</i>, not just flat collections of files. It would be sad if <font
+ size="+0">applyToCommonFiles</font> worked only in the top-level directories, but not in the lower-level ones. Deciding
+ how to test whether <font size="+0">applyToCommonFiles</font> works in lower-level directories forces us to confront
+ the incompleteness of its description.
+</p>
+<p>
+ First, when does <font size="+0">applyToCommonFiles</font> descend into subdirectories? If the directory structure
+ looks like this
+</p>
+<p align="center">
+ <img height="162" alt="" src="resources/tstidsctl-img1.gif" width="334" />
+</p>
+<p class="picturetext">
+ Figure 1: A directory structure
+</p>
+<p>
+ does <font size="+0">applyToCommonFiles</font> descend into <font size="+0">Cdir</font>? That doesn't seem to make
+ sense. There can be no match with anything in the other directory tree. In fact, it seems as if files in subdirectories
+ can only match if the subdirectory names match. That is, suppose we have this directory structure:
+</p>
+<p align="center">
+ <img height="165" alt="" src="resources/tstidsctl-img2.gif" width="334" />
+</p>
+<p class="picturetext">
+ Figure 2: A second directory structure
+</p>
+<p>
+ The files named "File" don't match because they're in different subdirectories The subdirectories should be descended
+ only if they have the same name in both <font size="+0">d1</font> and <font size="+0">d2</font>. That leads to these
+ test ideas:
+</p>
+<ul>
+ <li>
+ some subdirectory in d1 is not found in d2 (no descent)
+ </li>
+ <li>
+ some subdirectory in d2 is not found in d1 (no descent)
+ </li>
+ <li>
+ some subdirectory appears in both d1 and d2 (descend)
+ </li>
+</ul>
+<p>
+ But that raises other questions. Should the operation (<font size="+0">op</font>) be applied to matching subdirectories
+ or just to matching files? If it's applied to the subdirectories, should it be applied before the descent or afterward?
+ That makes a difference if, for example, the operation deletes the matching file or directory. For that matter,
+ <i>should</i> the operation be allowed to modify the directory structure? And more specifically: what's the correct
+ behavior of <font size="+0">applyToCommonFiles</font> if it does? (This is the same issue that comes up with
+ iterators.)
+</p>
+<p>
+ These sorts of questions typically arise when you carefully read a method's description of creating test ideas. But
+ let's leave them aside for now. Whatever the answers are, there will have to be test ideas for them-test ideas that
+ check whether the code correctly implements the answers.
+</p>
+<p>
+ Let's return to the catalog. We still haven't considered all of its test ideas. The first one-empty (nothing in
+ structure)-asks for an empty directory. We've already got that from the <b>Collections</b> entry. We've also got the
+ <b>minimal non-empty</b> structure, which is a directory with a single element. This sort of redundancy is not
+ uncommon, but it's easy to ignore.
+</p>
+<p>
+ What about <b>a circular structure</b>? Directory structures can't be circular-a directory can't be within one of its
+ descendants or within itself... or can it? What about shortcuts (on Windows) or symbolic links (on UNIX)? If there's a
+ shortcut in <font size="+0">d1</font>'s directory tree that points back to <font size="+0">d1</font>, should <font
+ size="+0">applyToCommonFiles</font> keep descending forever? The answer could lead to one or more new test ideas:
+</p>
+<ul>
+ <li>
+ d1 is circular because of shortcuts or symbolic links
+ </li>
+ <li>
+ d2 is circular because of shortcuts or symbolic links
+ </li>
+</ul>
+<p>
+ Depending on the correct behavior, there may be more test ideas than that.
+</p>
+<p>
+ Finally, what about <b>depth greater than one</b>? Earlier test ideas will ensure that we test descending into one
+ level of subdirectory, but we should check that <font size="+0">applyToCommonFiles</font> keeps descending:
+</p>
+<ul>
+ <li>
+ descends through several levels (>1) of d1's subdirectories
+ </li>
+ <li>
+ descends through several levels (>1) of d2's subdirectories
+ </li>
+</ul>
+<h3>
+ <a id="CreatingYourOwnCatalogs" name="CreatingYourOwnCatalogs">Creating and Maintaining Your Own Test-Ideas Catalog</a>
+</h3>
+<p>
+ As mentioned previously, the generic catalog won't contain all of the test ideas you need. But <a
+ href="./../../../glossary/glossary.htm#domain" target="_blank"><i>domain</i></a>-specific catalogs haven't been
+ published outside of the companies that created them. If you want them, you'll need to build them. Here's some advice.
+</p>
+<ul>
+ <li>
+ Do not fill a catalog with your speculations about what ideas would be good for finding faults. Remember that each
+ test idea you put in the catalog costs time and money:
+ <ul>
+ <li>
+ your time to maintain the catalog
+ </li>
+ <li>
+ other programmers' time to think about the test idea
+ </li>
+ <li>
+ possibly other programmers' time to implement a test
+ </li>
+ </ul>
+ <br />
+ Add only ideas that have a demonstrated track record. You should be able to point to at least one actual fault
+ that the test idea would have caught. Ideally, the fault should be one that was missed by other testing; that is,
+ one that was reported from the field. One good way to build catalogs is to browse through your company's bug
+ database and ask questions about how each fault could have been detected earlier.
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <br />
+ <br />
+ </li>
+ <li>
+ It's unlikely to work if creating and maintaining a Test-Ideas Catalog is something you do in your spare time.
+ You'll need time specifically allocated to this task, just like for any other important one. We recommend you
+ create and maintain your Test-Ideas Catalog during <a href="wfs_imptstast.htm">Workflow Detail: Improve Test
+ Assets</a>.
+ </li>
+</ul>
+<br />
+<br /><!-- END:mainDescription,-OrjIrRLW6v_XnqLUQ9GYaQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-ideas_list.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-ideas_list.html
new file mode 100644
index 0000000..fd3f653
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test-ideas_list.html
@@ -0,0 +1,313 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\test-ideas_list.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test-ideas_list.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,8.834380241450745E-306 CRC: 3910256382 -->Test-Ideas List<!-- END:presentationName,8.834380241450745E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-3i1jvKMUGGmAYPw4dHFbEg CRC: 3519354283 --><h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Information used in designing tests is gathered from many places: design models, classifier interfaces, statecharts,
+ and code itself. At some point, this source document information must be transformed into executable tests:
+</p>
+<ul>
+ <li>
+ specific inputs given to the software under test
+ </li>
+ <li>
+ in a particular hardware and software configuration
+ </li>
+ <li>
+ initialized to a known state
+ </li>
+ <li>
+ with specific results expected
+ </li>
+</ul>
+<p>
+ It's possible to go directly from source document information to executable tests, but it's often useful to add an
+ intermediate step. In this step, test ideas are written into a <i>Test-Ideas List</i>, which is used to create
+ executable tests.
+</p>
+<h3>
+ <a id="TestIdeas" name="TestIdeas">What are Test Ideas?</a>
+</h3>
+<p>
+ A test idea (sometimes referred to as a test requirement) is a brief statement about a test that could be performed. As
+ a simple example, let's consider a function that calculates a square root and come up with some test ideas:
+</p>
+<ul>
+ <li>
+ give a number that's barely less than zero as input
+ </li>
+ <li>
+ give zero as the input
+ </li>
+ <li>
+ test a number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
+ </li>
+</ul>
+<p>
+ Each of these ideas could readily be converted into an executable test with exact descriptions of inputs and expected
+ results.
+</p>
+<p>
+ There are two advantages to this less-specific intermediate form:
+</p>
+<ul>
+ <li>
+ test ideas are more reviewable and understandable than complete tests - it's easier to understand the reasoning
+ behind them
+ </li>
+ <li>
+ test ideas support more powerful tests, as described later under the heading <a href="#TestDesignUsingTheList">Test
+ Design Using the List</a>
+ </li>
+</ul>
+<p>
+ The square root examples all describe inputs, but test ideas can describe any of the elements of an executable test.
+ For example, "print to a LaserJet IIIp" describes an aspect of the test environment to be used for a test, as does
+ "test with database full", however, these latter test ideas are very incomplete in themselves: Print <b>what</b> to the
+ printer? Do <b>what</b> with that full database? They do, however, ensure that important ideas aren't forgotten; ideas
+ that will be described in more detail later in test design.
+</p>
+<p>
+ Test ideas are often based on fault models; notions of which faults are plausible in software and how those faults
+ can best be uncovered. For example, consider boundaries. It's safe to assume the square root function can be
+ implemented something like this:
+</p>
+<blockquote>
+<pre>
+ double sqrt(double x) { if (x < 0) // signal error ...
+</pre>
+</blockquote>
+<p>
+ It's also plausible that the <font size="+0"><</font> will be incorrectly typed as <font size="+0"><=</font>.
+ People often make that kind of mistake, so it's worth checking. The fault cannot be detected with <font
+ size="+0">X</font> having the value <font size="+0">2</font>, because both the incorrect expression (<font
+ size="+0">x<=0</font>) and the correct expression (<font size="+0">x<0</font>) will take the same branch of the
+ <font size="+0">if</font> statement. Similarly, giving <font size="+0">X</font> the value -<font size="+0">5</font>
+ cannot find the fault. The only way to find it is to give <font size="+0">X</font> the value <font size="+0">0</font>,
+ which justifies the second test idea.
+</p>
+<p>
+ In this case, the fault model is explicit. In other cases, it's implicit. For example, whenever a program manipulates a
+ linked structure, it's good to test it against a circular one. It's possible that many faults could lead to a
+ mishandled circular structure. For the purposes of testing, they needn't be enumerated - it suffices to know that some
+ fault is likely enough that the test is worth running.
+</p>
+<p>
+ The following links provide information about getting test ideas from different kinds of fault models. The first two
+ are explicit fault models; the last uses implicit ones.
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
+ guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a>
+ </li>
+ <li>
+ <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_method_calls,8.5657170364036E-306.html"
+ guid="8.5657170364036E-306">Guideline: Test Ideas for Method Calls</a>
+ </li>
+ <li>
+ <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-ideas_catalog,1.2384224477983028E-305.html"
+ guid="1.2384224477983028E-305">Concept: Test-Ideas Catalog</a>
+ </li>
+</ul>
+<p>
+ These fault models can be applied to many different artifacts. For example, the first one describes what to do with
+ Boolean expressions. Such expressions can be found in code, in guard conditions, in statecharts and sequence diagrams,
+ and in natural-language descriptions of method behaviors (such as you might find in a published API).
+</p>
+<p>
+ Occasionally it's also helpful to have guidelines for specific artifacts. See <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
+ guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Flow Diagrams</a>.
+</p>
+<p>
+ A particular Test-Ideas List might contain test ideas from many fault models, and those fault models could be derived
+ from more than one artifact.
+</p>
+<h3>
+ <a id="TestDesignUsingTheList" name="TestDesignUsingTheList">Test Design Using the List</a>
+</h3>
+<p>
+ Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
+ obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is found.
+</p>
+<blockquote>
+<pre>
+ int Collection.find(String string, Boolean ignoreCase);
+</pre>
+</blockquote>
+<p>
+ Here are some test ideas for this method:
+</p>
+<ol>
+ <li>
+ match found in the first position
+ </li>
+ <li>
+ match found in the last position
+ </li>
+ <li>
+ no match found
+ </li>
+ <li>
+ two or more matches found in the collection
+ </li>
+ <li>
+ case is ignored; match found, but it wouldn't match if case was obeyed
+ </li>
+ <li>
+ case is obeyed; an exact match is found
+ </li>
+ <li>
+ case is obeyed; a string that would have matched if case were ignored is skipped
+ </li>
+</ol>
+<p>
+ It would be simple to implement these seven tests, one for each test idea. However, different test ideas can be
+ combined into a single test. For example, the following test <i>satisfies</i> test ideas 2, 6, and 7:
+</p>
+<blockquote>
+ <p>
+ Setup: collection initialized to ["dawn", "Dawn"]<br />
+ Invocation: collection.find("Dawn", false)<br />
+ Expected result: return value is 1 (it would be 0 if "dawn" were not skipped)
+ </p>
+</blockquote>
+<p>
+ Making test ideas nonspecific makes them easier to combine.
+</p>
+<p>
+ It's possible to satisfy all of the test ideas in three tests. Why would three tests that satisfy seven test ideas be
+ better than seven separate tests?
+</p>
+<ul>
+ <li>
+ When you're creating a large number of simple tests, it's common to create test N+1 by copying test N and tweaking
+ it just enough to satisfy the new test idea. The result, especially in more complex software, is that test N+1
+ probably exercises the program in almost the same way as test N. It takes almost exactly the same path through the
+ code.<br />
+ <br />
+ A smaller number of tests, each satisfying several test ideas, doesn't allow a "copy and tweak" approach. Each
+ test will be somewhat different from the last, exercising the code in different ways and taking different
+ paths.<br />
+ <br />
+ Why would that be better? If the Test-Ideas List were complete, with a test idea for every fault in the program,
+ it wouldn't matter how you wrote the tests. But the list is always missing some test ideas that could find bugs. By
+ having each test do very different things from the last one - by adding seemingly unneeded variety - you increase
+ the chance that one of the tests will stumble over a bug by sheer dumb luck. In effect, smaller, more complex tests
+ increase the chance the test will satisfy a test idea that you didn't know you needed.<br />
+ </li>
+ <li>
+ Sometimes when you're creating more complex tests, new test ideas come to mind. That happens less often with simple
+ tests, because so much of what you're doing is exactly like the last test, which dulls your mind.
+ </li>
+</ul>
+<p>
+ However, there are reasons for not creating complex tests.
+</p>
+<ul>
+ <li>
+ If each test satisfies a single test idea and the test for idea 2 fails, you immediately know the most likely
+ cause: the program doesn't handle a match in the last position. If a test satisfies ideas 2, 6, and 7, then
+ isolating the failure is harder.<br />
+ </li>
+ <li>
+ Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.<br />
+ </li>
+ <li>
+ Complex tests are more difficult to create. Constructing a test that satisfies five test ideas often takes more
+ time than constructing five tests that each satisfy one. Moreover, it's easier to make mistakes - to think you're
+ satisfying all five when you're only satisfying four.
+ </li>
+</ul>
+<p>
+ In practice, you must find a reasonable balance between complexity and simplicity. For example, the first tests you
+ subject the software to (typically the smoke tests) should be simple, easy to understand and maintain, and intended to
+ catch the most obvious problems. Later tests should be more complex, but not so complex they are not maintainable.
+</p>
+<p>
+ After you've finished a set of tests, it's good to check them against the characteristic test design mistakes discussed
+ in <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/developer_testing,4.085829182735815E-305.html#TestDesignMistakes"
+ guid="4.085829182735815E-305">Concept: Developer Testing</a>.
+</p>
+<h3>
+ <a id="UsingTestIdeasBeforeTest" name="UsingTestIdeasBeforeTest">Using Test Ideas Before Testing</a>
+</h3>
+<p>
+ A Test-Ideas List is useful for reviews and inspections of design artifacts. For example, consider this part of a
+ design model showing the association between Department and Employee classes.
+</p>
+<p align="center">
+ <img height="45" alt="" src="resources/tstidslst-img1.gif" width="223" />
+</p>
+<p class="picturetext">
+ Figure 1: Association between Department and Employee Classes
+</p>
+<p>
+ The rules for creating test ideas from such a model would ask you to consider the case where a department has many
+ employees. By walking through a design and asking "what if, at this point, the department has many employees?", you
+ might discover design or analysis errors. For example, you might realize that only one employee at a time can be
+ transferred between departments. That might be a problem if the corporation is prone to sweeping reorganizations where
+ many employees need to be transferred.
+</p>
+<p>
+ Such faults, cases where a possibility was overlooked, are called <i>faults of omission</i>. Just like the faults
+ themselves, you have probably omitted tests that detect these faults from your testing effort. For example, see <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html"
+ guid="6.191633934532389E-306">[GLA81]</a>, <a href="../../referenc.htm#OST84">[OST84]</a>, <a
+ href="../../referenc.htm#BAS87">[BAS87]</a>, <a href="../../referenc.htm#MAR00">[MAR00]</a>, and other studies that
+ show how often faults of omission escape into deployment.
+</p>
+<p>
+ The role of testing in design activities is discussed further in <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
+ guid="6.556259235358794E-306">Concept: Test-first Design</a>.
+</p>
+<h3>
+ <a id="TestIdeasTraceability" name="TestIdeasTraceability">Test Ideas and Traceability</a>
+</h3>
+<p>
+ Traceability is a matter of tradeoffs. Is its value worth the cost of maintaining it? This question needs to be
+ considered during <a href="../../activity/ac_tst_dfnasstrcnds.htm">Activity: Define Assessment and Traceability
+ Needs</a>.
+</p>
+<p>
+ When traceability is worthwhile, it's conventional to trace tests back to the artifacts that inspired them. For
+ example, you might have traceability between an API and its tests. If the API changes, you know which tests to change.
+ If the code (that implements the API) changes, you know which tests to run. If a test puzzles you, you can find the API
+ it's intended to test.
+</p>
+<p>
+ The Test-Ideas List adds another level of traceability. You can trace from a test to the test ideas it satisfies, and
+ then from the test ideas to the original artifact.
+</p>
+<br />
+<br /><!-- END:mainDescription,-3i1jvKMUGGmAYPw4dHFbEg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test_driven_development.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test_driven_development.html
new file mode 100644
index 0000000..6bb1511
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/test_driven_development.html
@@ -0,0 +1,121 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\test_driven_development.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_driven_development.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.620567348185129E-306 CRC: 2210588074 -->Test Driven Development<!-- END:presentationName,1.620567348185129E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-yaD6WKGdrZ0n0yBSpwPr4g CRC: 3777617892 --><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a
+id="XE_test_driven_development__practice_of" name="XE_test_driven_development__practice_of"></a><a
+id="XE_engineering_practices__test_driven_development" name="XE_engineering_practices__test_driven_development"></a>
+<h3>
+ Description
+</h3>
+<p>
+ Test-Driven Development is one of the core programming practices of XP. Many of us have learned over the years the
+ value of writing automated tests for our code. Many of us have also learned the difficulty of writing tests after code
+ is already in place. Test-Driven Development takes a different, extreme approach to ensure that we test all code, all
+ the time.
+</p>
+<p>
+ The practice of Test-Driven Development requires a change in how you program and in how you think. You won't write
+ tests as an afterthought. You won't be trying to see if the code you have written works. Instead, you will write tests
+ as part of the everyday, every minute way of building software. Instead of writing detailed design specifications on
+ paper, write the spec in code. Instead of first striving to perfectly design a system on paper, use tests to guide your
+ design. Instead of coding for hours at a stretch only to find that the planning went awry, use Test-Driven Development
+ to pace yourself, always assuring forward progress with the firm foundation of an ever-growing suite of running tests.
+</p>
+<p>
+ The steps:
+</p>
+<ul>
+ <li>
+ Have an idea where you are going.
+ </li>
+ <li>
+ Write a test that specifies a tiny bit of functionality.
+ </li>
+ <li>
+ Ensure that the test fails (you haven't built the functionality yet!).
+ </li>
+ <li>
+ Write only the code necessary to make the test pass.
+ </li>
+ <li>
+ Refactor the code, ensuring that it has the clear and simple design for the functionality built to date.
+ </li>
+ <li>
+ Repeat until you have the desired functionality.
+ </li>
+</ul>
+<p>
+ The rules:
+</p>
+<ul>
+ <li>
+ Test everything that can possibly break.
+ </li>
+ <li>
+ Tests come first.
+ </li>
+ <li>
+ All tests run at 100% all the time.
+ </li>
+</ul>
+<p>
+ Test-Driven Development is infectious! Developers swear by it. Developers do not seem to abandon it after giving it an
+ honest trial.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Testable modules are decoupled from other complex classes, resulting in <b>loosely coupled modules</b>. Loosely
+ coupled modules are a sign of good design.
+ </li>
+ <li>
+ Code is written so that <b>modules are testable in isolation</b>. Code written without tests in mind is often
+ highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll
+ devise ways of minimizing dependencies in your system in order to write your tests.
+ </li>
+ <li>
+ The <b>tests act as documentation,</b> providing concrete examples of how to use the module being tested.
+ </li>
+ <li>
+ The tests are the first client of your classes; they <b>show how the developer intended the class to be used</b>.
+ </li>
+ <li>
+ The <b>tests act as a safety net</b>. Notifying the programmer immediately when a side-effect defect is introduced
+ into the system.
+ </li>
+ <li>
+ <b>Development is paced</b>. You can stop at anytime with the tests describing the progress so far. Each
+ programming session gives a sense of satisfaction with getting some of the code working.
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ For more information, see <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html"
+ guid="3.9254165491375454E-306">Test Driven Development Guidelines</a>.
+</p><!-- END:mainDescription,-yaD6WKGdrZ0n0yBSpwPr4g -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/what_is_xp.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/what_is_xp.html
new file mode 100644
index 0000000..b746c16
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/what_is_xp.html
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\what_is_xp.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: what_is_xp.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,9.251272550276345E-306 CRC: 189032972 -->What is XP?<!-- END:presentationName,9.251272550276345E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-nO38_JQ9G3FQvNlAT5Agqg CRC: 3600340748 --><a id="XE_xp__what_is_it" name="XE_xp__what_is_it"></a><a id="XE_what_is__xp" name="XE_what_is__xp"></a>
+<p>
+ Kent Beck, author of <i>Extreme Programming Explained</i> [<a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#BEC00"
+ guid="6.191633934532389E-306">BEC00</a>], says, "XP is a light-weight methodology for small-to-medium-sized teams
+ developing software in the face of vague or rapidly changing requirements." Simply stated, XP is a set of <a
+ class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html"
+ guid="1.076140803519123E-306">values</a>, <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html" guid="3.036332011267074E-306">rights,</a>
+ and best <a class="elementLinkWithUserText"
+ href="./../../../xp/customcategories/xp_best_practices,4.315031901943112E-306.html"
+ guid="4.315031901943112E-306">practices</a> that support each other in incrementally developing software.
+</p>
+<p>
+ When a team is developing software with XP, the customer creates stories that describe the functionality of the
+ software. These stories are very lightweight use-cases. They are small units of functionality that require less than
+ one or two weeks to implement. Programmers estimate the stories, and, based upon those estimates, the customer decides
+ which stories to do first.
+</p>
+<p>
+ Development is done iteratively and incrementally. Every two weeks, the programming team delivers working stories to
+ the customer. Then the customer chooses another two weeks worth of work. The system grows in functionality, piece by
+ piece, steered by the customer. Progress is measured and tracked based on the observable behavior of the team.
+</p>
+<p>
+ XP relies on evolutionary design and testing techniques that maintain a high quality design while new functionality is
+ being added. These techniques avoid the mess of unmaintainable code through continuous review, an emphasis on
+ simplicity, and the backstop of nearly universal test coverage.
+</p>
+<p>
+ Programmers work on their programming tasks in pairs. The pair share a single workstation and work together to write a
+ single piece of code. Both partners are equally engaged in the writing. The keyboard moves back and forth between them
+ frequently.
+</p>
+<p>
+ XP programmers practice Test-Driven Development. In short, they write unit tests prior to writing production code.
+ However, this is done in very tiny increments. Tiny portions of a test are written first, and then just enough
+ production code is written to make those portions pass. This continues iteratively until everything that can be
+ practically tested has been tested.
+</p>
+<p>
+ XP focuses on continuous delivery of tested, running software from the first day of the project to the last. Delivery
+ of real software, combined with simple but frequent planning, provides stakeholders with a clear view of what is done
+ and what will be done. This enables the business to steer the project to an on-time shipment of the best possible
+ software that can be completed in the time available.
+</p><!-- END:mainDescription,-nO38_JQ9G3FQvNlAT5Agqg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/whole_team.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/whole_team.html
new file mode 100644
index 0000000..4dbd7b3
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/whole_team.html
@@ -0,0 +1,123 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\whole_team.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: whole_team.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,7.89591827591278E-306 CRC: 3326748077 -->Whole Team<!-- END:presentationName,7.89591827591278E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-uqrgrFY-74R1FijPLvcXoQ CRC: 4131291001 --><h3>
+ Description
+</h3>
+<p>
+ All the contributors to an XP project sit together, members of a whole team. The team shares the project goals and the
+ responsibility for achieving them. This team must include a business representative, the "Customer" who provides the
+ requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end
+ user who knows the domain and what is needed. The team will of course have programmers. The team may include testers,
+ who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to
+ define the requirements. There is commonly a coach, who helps the team keep on track and facilitates the process. There
+ may be a manager, providing resources, handling external communication and coordinating activities. None of these roles
+ is necessarily the exclusive property of just one individual. Everybody on an XP team contributes in any way that they
+ can. The best teams have no specialists, only general contributors with special skills.
+</p>
+<p>
+ Subservient in organization to the Whole Team are the teams that focus on the business decisions (<a
+ class="elementLink" href="./../../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>), the technical decisions (<a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>), and the organization that supports those teams (<a
+ class="elementLink" href="./../../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
+ guid="5.613949040902463E-308">XP Organization</a>). To create a context for clear communication, XP provides a set of
+ guidelines defining the rights of the customer and developer. These guidelines are referred to as the <a
+ class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html"
+ guid="3.036332011267074E-306">customer and a developer bill of rights</a>.
+</p>
+<div align="left">
+ <table width="75%" border="1">
+ <tbody>
+ <tr>
+ <th width="30%">
+ <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>
+ </th>
+ <th width="34%">
+ <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>
+ </th>
+ <th width="36%">
+ <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
+ guid="5.613949040902463E-308">XP Organization</a>
+ </th>
+ </tr>
+ <tr>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}.html"
+ guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">Customer</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}.html"
+ guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}">Programmer</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
+ guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">Tracker</a>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}.html"
+ guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">Tester</a>
+ </td>
+ <td align="middle">
+
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">Coach</a>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Progress visibility</b>: customer gets real feedback on a daily basis.
+ </li>
+ <li>
+ <b>Agility</b>: customer can steer team on a daily basis.
+ </li>
+ <li>
+ <b>Reduces miscommunication</b>: contact is direct and face to face, single point of contact.
+ </li>
+ <li>
+ <b>Speeds up communication</b>: customer is always available to answer questions.
+ </li>
+</ul><!-- END:mainDescription,-uqrgrFY-74R1FijPLvcXoQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_practices.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_practices.html
new file mode 100644
index 0000000..f12b707
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_practices.html
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\xp_practices.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_practices.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,2.2937799026801584E-305 CRC: 2561469900 -->XP Practices<!-- END:presentationName,2.2937799026801584E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-24MPC2FhJbx7Fr0F6QEq8A CRC: 2495656811 --><a id="XE_xp__practices_of" name="XE_xp__practices_of"></a><a id="XE_practices_in__xp" name="XE_practices_in__xp"></a>
+<p>
+ XP is a collection of guiding values and best practices. Most of these practices have been used in the industry in some
+ shape or form for a number of years. XP has simply identified them and tried to push the envelope of these practices in
+ order to get the most benefit from them. Taken individually, these practices are all fairly simple. But it is the sum
+ of all of them that provides the most benefit as they reinforce each other to address the most difficult problems teams
+ encounter when developing software.
+</p>
+<br />
+<br />
+<p>
+ <img height="540" alt="" src="./../../../xp/resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map"
+ border="0" /> <map id="xp_practices_image_map" name="xp_practices_image_map">
+ <area shape="RECT" coords="298,19,390,88"
+ href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
+ <area shape="RECT" coords="176,135,282,200"
+ href="./../../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
+ <area shape="RECT" coords="297,168,434,231"
+ href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
+ <area shape="RECT" coords="447,135,547,198"
+ href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
+ <area shape="RECT" coords="15,236,122,305"
+ href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
+ <area shape="RECT" coords="218,238,362,307"
+ href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
+ <area shape="RECT" coords="392,241,512,305"
+ href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
+ <area shape="RECT" coords="614,236,714,302"
+ href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
+ <area shape="RECT" coords="143,325,270,393"
+ href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
+ <area shape="RECT" coords="310,321,412,379"
+ href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
+ <area shape="RECT" coords="468,323,597,393"
+ href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
+ <area shape="RECT" coords="307,386,413,436"
+ href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
+ <area shape="RECT" coords="312,475,419,539"
+ href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
+ <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
+ </map>
+</p>
+<p>
+ This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
+ exemplifies the steering and control cycles of the process.
+</p>
+<p>
+ The outer red circle is called the "Circle of Life". It's what keeps an XP project going, producing tested working
+ software. The <a class="elementLink" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a>, customer members and development members, work together - preferably
+ physically together - to build the project. Using the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html"
+ guid="2.7371805612676613E-305">Planning Game</a> elements of Release Planning and Iteration Planning, they plan a
+ series of <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" guid="5.762953011420275E-306">Small
+ Releases</a> of software that demonstrably pass all the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html"
+ guid="2.297945473205673E-305">Customer Tests</a>.
+</p>
+<p>
+ The innermost blue circle describes the day to day, moment to moment, work of the XP developers. Each feature is
+ addressed with <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html"
+ guid="1.6109092258980447E-306">Simple Design</a>, ensuring that the design of the system is just right for the features
+ supported. The programmers work in <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html"
+ guid="3.876855509996079E-307">pairs</a> for all production code development, providing continuous code review and
+ valuable, team-wide understanding of the system. They build the software using <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
+ guid="1.620567348185129E-306">Test-Driven Development,</a> a technique that produces well-crafted and well-tested
+ software with a minimum of wasted effort, and the design is kept clean by the continuous improvement process of <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
+ guid="1.4410217108363206E-306">Refactoring</a>.
+</p>
+<p>
+ The middle green circle contains the important supporting practices of XP. The software is designed according to a
+ common, shared, evolving <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html"
+ guid="4.884861766532753E-306">Metaphor</a> that helps it all hang together. It is kept <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html"
+ guid="3.193414568279561E-305">continuously integrated</a> with many system builds every day, each one fully tested. The
+ team shares ownership of of all the code so that needed changes can be made by any qualified pair, not just by one
+ individual. Since everyone works on everything, the team evolves a <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" guid="8.8116853923311E-307">standard
+ way of coding</a>. Finally, XP teams work at a <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html"
+ guid="3.133529870649493E-306">sustainable pace</a> that enables them to deliver tested software on a predictable basis
+ from the first day of the project until the last.
+</p>
+<p>
+ <br />
+
+</p><!-- END:mainDescription,-24MPC2FhJbx7Fr0F6QEq8A -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_rights.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_rights.html
new file mode 100644
index 0000000..251b757
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_rights.html
@@ -0,0 +1,69 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\xp_rights.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_rights.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.036332011267074E-306 CRC: 35014668 -->XP Rights<!-- END:presentationName,3.036332011267074E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-vEvfeoyYAPDr-jfyX2QLww CRC: 4164458583 --><a id="XE_xp__bill_of_rights" name="XE_xp__bill_of_rights"></a><a id="XE_bill_of_rights__in_xp"
+name="XE_bill_of_rights__in_xp"></a>
+<h2>
+ Developer Bill of Rights
+</h2>
+<ul>
+ <li>
+ You have the right to know what is needed with clear declarations of priority.
+ </li>
+ <li>
+ You have the right to produce quality work at all times.
+ </li>
+ <li>
+ You have the right to ask for and receive help from peers, superiors, and customers.
+ </li>
+ <li>
+ You have the right to make and update your own estimates.
+ </li>
+ <li>
+ You have the right to accept responsibilities instead of having them assigned to you.
+ </li>
+</ul>
+<h2>
+ Customer Bill of Rights
+</h2>
+<ul>
+ <li>
+ You have the right to an overall plan, to know what can be accomplished when and at what cost.
+ </li>
+ <li>
+ You have the right to get the greatest possible value out of every programming week.
+ </li>
+ <li>
+ You have the right to see progress in a running system proven to work by passing repeatable tests that you specify.
+ </li>
+ <li>
+ You have the right to change your mind, to substitute functionality, and to change priorities without paying
+ exorbitant costs.
+ </li>
+ <li>
+ You have the right to be informed of schedule changes in time to choose how to reduce the scope to restore the
+ original date. You can cancel the project at any time and be left with a useful working system reflecting the
+ investment to date.
+ </li>
+</ul><!-- END:mainDescription,-vEvfeoyYAPDr-jfyX2QLww -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_sustainable_pace.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_sustainable_pace.html
new file mode 100644
index 0000000..8099d0a
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_sustainable_pace.html
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\xp_sustainable_pace.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_sustainable_pace.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.133529870649493E-306 CRC: 2128267562 -->Sustainable Pace<!-- END:presentationName,3.133529870649493E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-DoLoZOTPa_LacQ3jUG_lsg CRC: 4165477365 --><a id="XE_xp__sustainable_pace" name="XE_xp__sustainable_pace"></a><a id="XE_sustainable_pace__practice_of"
+name="XE_sustainable_pace__practice_of"></a><a id="XE_engineering_practices__sustainable_pace"
+name="XE_engineering_practices__sustainable_pace"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
+ marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
+ overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
+ impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
+ causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
+ down.
+</p>
+<p>
+ Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
+ to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
+ it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
+ iteration or a release, but it should always be an exception rather than the rule.
+</p>
+<p>
+ Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Improved predictability</b>: plans become more accurate.
+ </li>
+ <li>
+ <b>Improved product quality</b>: programmers have the time to do the right thing.
+ </li>
+ <li>
+ <b>Improved job satisfaction</b>: programmers can enjoy their work with as little stress as possible.
+ </li>
+ <li>
+ <b>Reduced time to market</b>: less time required to fix bad code and rotting design.<br />
+ <br />
+ </li>
+</ul><!-- END:mainDescription,-DoLoZOTPa_LacQ3jUG_lsg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_values.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_values.html
new file mode 100644
index 0000000..0f6a1b9
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/concepts/xp_values.html
@@ -0,0 +1,194 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\concepts\xp_values.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_values.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.076140803519123E-306 CRC: 970053097 -->XP Values<!-- END:presentationName,1.076140803519123E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-pA6XLJKgRiwDTEp_qMlQ9g CRC: 1383343231 --><a id="XE_xp__core_values" name="XE_xp__core_values"></a>
+<h2>
+ <a id="Communication" name="Communication">Communication</a>
+</h2>
+<p>
+ XP emphasizes face-to-face communication over other types of communication, such as documents. XP values documents but
+ values personal communication even more. In order to facilitate communication, XP teams:
+</p>
+<ul>
+ <li>
+ Use a common system metaphor or vocabulary.
+ </li>
+ <li>
+ Work closely with one another in an open workspace.
+ </li>
+ <li>
+ Continuously integrate the code.
+ </li>
+ <li>
+ Work closely with the business people, preferably having them in the same room.
+ </li>
+ <li>
+ Program in pairs.
+ </li>
+ <li>
+ Collectively own the code.
+ </li>
+ <li>
+ Frequently plan and report status to the customer.
+ </li>
+</ul>
+<h2>
+ <a id="Simplicity" name="Simplicity">Simplicity</a>
+</h2>
+<p>
+ XP presumes that it is better to do the simple thing today and pay a little more tomorrow if more is really needed than
+ to do a more complicated thing today that may never be used. This is a fundamental philosophy that permeates everything
+ in an XP project. If something isn't needed today, we don't do it today.
+</p>
+<p>
+ For example:
+</p>
+<ul>
+ <li>
+ We will write no document unless there is an immediate and significant need.
+ </li>
+ <li>
+ We will adopt no tool unless there is a tangible and verifiable benefit.
+ </li>
+ <li>
+ We will avoid writing infrastructure until it is needed by existing code.
+ </li>
+</ul>
+<p>
+ In order to maintain the simplicity of their software and their team structure, XP teams:
+</p>
+<ul>
+ <li>
+ Ask themselves: What is the simplest thing that can possibly work?
+ </li>
+ <li>
+ Continuously simplify and improve the design through refactoring.
+ </li>
+</ul>
+<p>
+ Some time ago, Kent Beck offered the following rules for simple design. In priority order, the code must:
+</p>
+<ol>
+ <li>
+ Run all the tests.
+ </li>
+ <li>
+ Contain no duplicate code.
+ </li>
+ <li>
+ Express all the ideas the author wants to express.
+ </li>
+ <li>
+ Minimize classes and methods.
+ </li>
+</ol>
+<h2>
+ <a id="Feedback" name="Feedback">Feedback</a>
+</h2>
+<p>
+ Feedback works at different scales in XP.
+</p>
+<p>
+ At the highest level, the customer can see the progress of the team through the working software delivered every two
+ weeks. This continuous feedback allows the customer to steer the project to success. We get concrete feedback on the
+ state of the system in the form of executable pieces of functionality that pass repeatable, automated acceptance tests.
+ These tests prevent the system from backsliding. No new release of the system can fail acceptance tests that used to
+ work.
+</p>
+<p>
+ At the programming level, programmers write unit tests for all the logic in the system to get immediate and concrete
+ feedback telling them if the code they just wrote is doing what they expected.
+</p>
+<p>
+ XP teams:
+</p>
+<ul>
+ <li>
+ Develop in small releases.
+ </li>
+ <li>
+ Develop in smaller iterations.
+ </li>
+ <li>
+ Break features and requirements into stories that fit in an iteration.
+ </li>
+ <li>
+ Break stories into even smaller tasks.
+ </li>
+ <li>
+ Write small unit tests to ensure that tasks work properly.
+ </li>
+ <li>
+ Write acceptance tests to ensure that stories work properly.
+ </li>
+ <li>
+ Track progress and communicate it to the customer frequently.
+ </li>
+</ul>
+<h2>
+ <a id="Courage" name="Courage">Courage</a>
+</h2>
+<p>
+ Perhaps a better name for this value is trust. In order to function, the members of an XP team have to have the courage
+ to trust each other, trust their customer, trust their practices, and trust themselves.
+</p>
+<p>
+ XP team members trust that they can:
+</p>
+<ul>
+ <li>
+ Stop when they are tired.
+ </li>
+ <li>
+ Let every business decision be made by the customer.
+ </li>
+ <li>
+ Ask customers to reduce the scope of a release.
+ </li>
+ <li>
+ Ask their peers or customers for help.
+ </li>
+ <li>
+ Design and implement only what is needed for today and add tomorrow what will be needed tomorrow.
+ </li>
+ <li>
+ Make changes that improve the functions or structure of the code.
+ </li>
+ <li>
+ Fix the design and retrofit existing code when the design is shown to be inadequate.
+ </li>
+ <li>
+ Throw away code.
+ </li>
+ <li>
+ Change code they did not write.
+ </li>
+ <li>
+ Change the process when it is not working.
+ </li>
+</ul>
+<p>
+ <br />
+ <br />
+</p><!-- END:mainDescription,-pA6XLJKgRiwDTEp_qMlQ9g -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/examples/test-ideas_catalog_examples.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/examples/test-ideas_catalog_examples.html
new file mode 100644
index 0000000..3830e6a
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/examples/test-ideas_catalog_examples.html
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\examples\test-ideas_catalog_examples.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test-ideas_catalog_examples.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,6.216049252606417E-306 CRC: 4096793123 -->Test-Ideas Catalog Examples<!-- END:presentationName,6.216049252606417E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,6.216049252606417E-306 CRC: 886778842 -->The example is attached below.<!-- END:briefDescription,6.216049252606417E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-HkQclhewSbkFSomo1l_LBg CRC: 3778221438 --><a id="XE_test_idea__example_catalogs_of" name="XE_test_idea__example_catalogs_of"></a><a
+id="XE_test_ideas_catalog__examples_of" name="XE_test_ideas_catalog__examples_of"></a>HTML: <a
+href="resources/tstidactl.htm" target="_blank">tstidactl.htm</a><!-- END:mainDescription,-HkQclhewSbkFSomo1l_LBg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/equivalence_class_analysis.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/equivalence_class_analysis.html
new file mode 100644
index 0000000..e5a4dd0
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/equivalence_class_analysis.html
@@ -0,0 +1,322 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\equivalence_class_analysis.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: equivalence_class_analysis.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.8491691792142673E-308 CRC: 614333630 -->Equivalence Class Analysis<!-- END:presentationName,1.8491691792142673E-308 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-c7t_eJuo1g5hpWTYTCItig CRC: 4058044177 --><a id="XE_runtime_observation_&_analysis__concept" name="XE_runtime_observation_&_analysis__concept"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Except for the most trivial of software applications, it is generally considered impossible to test all the input
+ combinations logically feasible for a software system. Therefore, selecting a good subset that has the highest
+ probability of finding the most errors, is a worthwhile and important task for testers to undertake.
+</p>
+<p>
+ Testing based on equivalence class analysis (synonyms: <i>equivalence partitioning</i>, <i>domain analysis</i>) is a
+ form of black-box test analysis that attempts to reduce the total number of potential tests to a minimal set of tests
+ that will uncover as many errors as possible [<a href="../../process/referenc.htm#MYE79">MYE79</a>]. It is a method
+ that partitions the set of inputs and outputs into a finite number of <i><a
+ href="./../../../glossary/glossary.htm#equivalence_class">equivalence classes</a></i> that enable the selection of a
+ representative test value for each class. The test that results from the representative value for a class is said to be
+ "equivalent" to the other values in the same class. If no errors were found in the test of the representative value, it
+ is reasoned that all the other "equivalent" values wouldn't identify any errors either.
+</p>
+<p>
+ The power of Equivalence Classes lies in their ability to guide the tester using a sampling strategy to reduce the
+ combinatorial explosion of potentially necessary tests. The technique provides a logical bases by which a subset of the
+ total conceivable number of tests can be selected. Here are some categories of problem areas for large numbers of tests
+ that can be benefit from the consideration of equivalence classes:
+</p>
+<ol>
+ <li>
+ Combinations of independent variables
+ </li>
+ <li>
+ Dependent variables based on hierarchical relationship
+ </li>
+ <li>
+ Dependent variables based on temporal relationship
+ </li>
+ <li>
+ Clustered relationships based on market exemplars
+ </li>
+ <li>
+ Complex relationships that can be modeled
+ </li>
+</ol>
+<h3>
+ <a id="Strategies" name="Strategies">Strategies</a>
+</h3>
+<p>
+ There are different strategies and techniques that can be used in equivalence partition testing. Here are some
+ examples:
+</p>
+<h4>
+ <a id="EquivalenceClassPartition" name="EquivalenceClassPartition">Equivalence Class Partition</a>
+</h4>
+<p>
+ Equivalence partition theory as proposed by Glenford Myers [<a href="../../process/referenc.htm#MYE79">MYE79</a>].
+ attempts to reduce the total number of test cases necessary by partitioning the input conditions into a finite number
+ of equivalence classes. Two types of equivalence classes are classified: the set of valid inputs to the program is
+ regarded as the <i>valid equivalence class</i>, and all other inputs are included in the <i>invalid equivalence
+ class</i>.
+</p>
+<p>
+ Here are a set of guidelines to identify equivalence classes:
+</p>
+<ol>
+ <li>
+ If an input condition specifies a range of values (such as, program "accepts values from 10 to 100"), then one
+ valid equivalence class (from 10 to 100) and two invalid equivalence classes are identified (less than 10 and
+ greater than 100).
+ </li>
+ <li>
+ If an input condition specifies a set of values (such as, "cloth can be many colors: RED, WHITE, BLACK, GREEN,
+ BROWN "), then one valid equivalence class (the valid values) and one invalid equivalence class (all the other
+ invalid values) are identified. Each value of the valid equivalence class should be handled distinctly.
+ </li>
+ <li>
+ If the input condition is specified as a "must be" situation (such as, "the input string must be upper case"), then
+ one valid equivalence class (uppercase characters) and one invalid equivalence (all the other input except
+ uppercase characters) class are identified.
+ </li>
+ <li>
+ Everything finished "long" before the task is done is an equivalence class. Everything done within some short time
+ interval before the program is finished is another class. Everything done just before program starts another
+ operation is another class.
+ </li>
+ <li>
+ If a program is specified to work with memory size from 64M to 256M. Then this size range is an equivalence class.
+ Any other memory size, which is greater than 256M or less than 64M, can be accepted.
+ </li>
+ <li>
+ The partition of output event lies in the inputs of the program. Even though different input equivalence classes
+ could have same type of output event, you should still treat the input equivalence classes distinctly.
+ </li>
+</ol>
+<h4>
+ <a id="BoundaryValueAnalysis" name="BoundaryValueAnalysis">Boundary Value Analysis</a>
+</h4>
+<p>
+ In each of the equivalence classes, the boundary conditions are considered to have a higher rate of success identifying
+ resulting failures than non-boundary conditions. Boundary conditions are the values at, immediately above or below the
+ boundary or "edges" of each equivalence classes.
+</p>
+<p>
+ Tests that result from boundary conditions make use of values at the minimum (min), just above minimum (min+), just
+ below the maximum (max-), and the maximum (max) of the range that needs be tested. When testing boundary values,
+ testers choose a few test cases for each equivalence class. For the relatively small sample of tests the likelihood of
+ failure discovery is high. The Tester is given some relief from the burden of testing a huge population of cases in an
+ equivalent class of values that are unlikely to produce large differences in testing results.
+</p>
+<p>
+ Some recommendations when choosing boundary values:
+</p>
+<ol>
+ <li>
+ For a floating variable, if the valid condition of it is from <code>-1.0</code> to <code>1.0</code>, test
+ <code>-1.0</code>, <code>1.0</code>, <code>-1.001</code> and <code>1.001</code>.
+ </li>
+ <li>
+ For an integer, if the valid range of input is <code>10</code> to <code>100</code>, test <code>9</code>,
+ <code>10</code>, <code>100</code>, <code>101</code>.
+ </li>
+ <li>
+ If a program expects an uppercase letter, test the boundary A and Z. Test <code>@</code> and <code>[</code> too,
+ because in ASCII code, <code>@</code> is just below A and <code>[</code> is just beyond the Z.
+ </li>
+ <li>
+ If the input or output of a program is an ordered set, pay attention on the first and the last element of the set.
+ </li>
+ <li>
+ If the sum of the inputs must be a specific number (<code>n</code>), test the program where the sum is
+ <code>n-1</code>, <code>n</code>, or <code>n+1</code>.
+ </li>
+ <li>
+ If the program accepts a list, test values in the list. All the other values are invalid.
+ </li>
+ <li>
+ When reading from or writing to a file, check the first and last characters in the file.
+ </li>
+ <li>
+ The smallest denomination of money is one cent or equivalent. If the program accepts a specific range, from a to b,
+ test a <code>-0.01</code> and b <code>+0.01</code>.
+ </li>
+ <li>
+ For a variable with multiple ranges, each range is an equivalence class. If the sub-ranges are not overlapped, test
+ the values on the boundaries, beyond the upper boundary, and below the lower boundary.
+ </li>
+</ol>
+<h4>
+ <a id="SpecialValues" name="SpecialValues">Special Values</a>
+</h4>
+<p>
+ After attempting the two previous boundary analysis strategies, an experienced tester will observe the program inputs
+ to discovery any "special value" cases, which are again potentially rich sources for uncovering software failures. Here
+ are some examples:
+</p>
+<ol>
+ <li>
+ For an integer type, zero should always be tested if it is in the valid equivalence class.
+ </li>
+ <li>
+ When testing time (hour, minute and second), 59 and 0 should always be tested as the upper and lower bound for each
+ field, no matter what constraint the input variable has. Thus, except the boundary values of the input, -1, 0, 59
+ and 60 should always be test cases.
+ </li>
+ <li>
+ When testing date (year, month and day), several test cases, such as number of days in a specific month, the number
+ of days in February in leap year, the number of days in the non-leap year, should be involved.
+ </li>
+</ol>
+<h4>
+ <a id="CategoryPartition" name="CategoryPartition">"Category-Partition" Method</a>
+</h4>
+<p>
+ <a href="#OstrandBalcer">Ostrand and Balcer</a> [16] developed a partition method that helps testers to analyze the
+ system specification, write test scripts, and manage them. Different from common strategies that mostly focuses on the
+ code, their method is based on the specification and design information too.
+</p>
+<p>
+ The main benefit of this method is its ability to expose errors before the code has been written because the input
+ source is the specification and the tests result from the analysis of that specification. Faults in the specifications
+ will be discovered early, often well before they are implemented in code.
+</p>
+<p>
+ The strategy for the "category-partition" method follows:
+</p>
+<ol>
+ <li>
+ Analyze the specification: decompose the system functionality into functional units, which can be tested
+ independently both by specification and implementation.<br />
+ From there;<br />
+ <br />
+
+ <ol>
+ <li>
+ Identify the parameters and the environment conditions that will influence the function's execution.
+ Parameters are the inputs of the function unit. Environment conditions are the system states, which will
+ effect the execution of the function unit.
+ </li>
+ <li>
+ Identify the characteristics of the parameters and the environment conditions.
+ </li>
+ <li>
+ Classify the characteristics into categories, which effect the behavior of the system.<br />
+ <br />
+ </li>
+ </ol>
+ Ambiguous, contradictory, and missing descriptions of behavior will be discovered in this stage.<br />
+ <br />
+ </li>
+ <li>
+ Partition the categories into choices: Choices are the different possible situations that might occur and not be
+ expected. They represent the same type of information in a category.<br />
+ <br />
+ </li>
+ <li>
+ Determine the relations and the constraints among choices. The choices in different categories influence with each
+ other, which also have an influence of building the test suite. Constraints are added to eliminate the
+ contradiction of between choices of different parameters and environments.<br />
+ <br />
+ </li>
+ <li>
+ Design test cases according to the categories, choices and constraint information. If a choice causes an error,
+ don't combine it with other choices to create the test case. If a choice can be "adequately" tested by one single
+ test, it is either the representative of the choice or a special value.
+ </li>
+</ol>
+<h3>
+ <a id="FurtherReading" name="FurtherReading">Further Reading and References</a>
+</h3>
+<ol>
+ <li>
+ Glenford J. Myers, The Art of Software Testing, John Wiley & Sons, Inc., New York, 1979.
+ </li>
+ <li>
+ White L. J. and Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software
+ Engineering, Vol. SE-6, No. 3, 1980.
+ </li>
+ <li>
+ Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on
+ Software Engineering, 8-4, 1992.
+ </li>
+ <li>
+ Steven J. Zeil, Faten H. Afifi and Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction
+ on Software Engineering and Methodology, 1-4, 1992.
+ </li>
+ <li>
+ BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering
+ and Methodology, 3-3, 1994.
+ </li>
+ <li>
+ Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
+ </li>
+ <li>
+ Martin R. Woodward and Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal
+ triangle, ACM Press New York, NY, 2000.
+ </li>
+ <li>
+ Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software
+ Engineering, 71-16, 2000.
+ </li>
+ <li>
+ Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley & Sons, Inc., New
+ York, 2002.
+ </li>
+ <li>
+ Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special
+ Interest Group on Software Engineering, 18-5, 1993.
+ </li>
+ <li>
+ Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM
+ Special Interest Group on Software Engineering, 1981.
+ </li>
+ <li>
+ Lori A. Clarke, Johnette Hassell, and Debra J Richardson, A system to generate test data and symbolically execute
+ programs, IEEE Transaction on Software Engineering, SE-2, 1976.
+ </li>
+ <li>
+ Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley & Sons,
+ Inc., 1995.
+ </li>
+ <li>
+ Steven J. Zeil, Faten H. Afifi and Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM
+ Transaction on Software Engineering and Methodology, 1-4, 1992.
+ </li>
+ <li>
+ William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
+ </li>
+ <li>
+ <a id="OstrandBalcer" name="OstrandBalcer">Thomas J. Ostrand and Marc J. Balcer</a>, The Category-Partition method
+ for specifying and generating functional tests, Communications of ACM 31, 1988.
+ </li>
+ <li>
+ Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley & Sons, Inc., 1999.
+ </li>
+</ol>
+<p>
+
+</p>
+<br />
+<br /><!-- END:mainDescription,-c7t_eJuo1g5hpWTYTCItig -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/open_workspace.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/open_workspace.html
new file mode 100644
index 0000000..f9f239d
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/open_workspace.html
@@ -0,0 +1,56 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\open_workspace.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: open_workspace.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.269440809144354E-305 CRC: 1744860582 -->Open Workspace<!-- END:presentationName,3.269440809144354E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-mq7aEjHjqWoRd6aWFK_Dwg CRC: 413807105 --><a id="XE_xp__open_workspace" name="XE_xp__open_workspace"></a><a id="XE_workspace__in_xp" name="XE_workspace__in_xp"></a>
+<p>
+ XP's open workspace borrows from the concept of the war room. Studies have shown that teams working tightly together in
+ close proximity achieve much greater productivity than when they are apart in their own separate offices or cubicles.
+ In XP, all members of the team, including the customer, sit in the open workspace.
+</p>
+<p>
+ The ideal XP programming environment is an open workspace filled with tables and room for pairs of people to work
+ together and maintain contact with their peers.
+</p>
+<p>
+ The open workspace should foster an environment in which programmers can focus on their problems but still hear enough
+ to jump in other conversations if they can help. It is an environment that emphasizes teamwork.
+</p>
+<p>
+ In many places in the world, businesses have "cubicle cultures." In the interests of privacy and enhanced
+ concentration, programmers often spend most of their time in their own workspace that is separated from their peers. It
+ acts as a little capsule of solitude that lets them work in "peace." While everyone needs quiet time and some privacy,
+ the bulk of software development work is best done collaboratively.
+</p>
+<p>
+ When people go into their small workspaces, they are out of the flow and exchange of information that keeps a project
+ vigorous.
+</p>
+<p>
+ In XP, team members should have some private space. They need a place where they can use a phone privately or browse
+ email, but software development should be done in an open workspace.
+</p>
+<p>
+ <br />
+
+</p><!-- END:mainDescription,-mq7aEjHjqWoRd6aWFK_Dwg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/pair_programming.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/pair_programming.html
new file mode 100644
index 0000000..694ad6f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/pair_programming.html
@@ -0,0 +1,364 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\pair_programming.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: pair_programming.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.85153041801319E-307 CRC: 2480722832 -->Pair Programming<!-- END:presentationName,3.85153041801319E-307 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-nfbUMyTTqEbCp3HDn-NjOA CRC: 975390294 --><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__in_xp"
+name="XE_pair_programming__in_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatIsPair">What is pair programming?</a>
+ </li>
+ <li>
+ <a href="#WhyPair">Why Pair Program?</a>
+ </li>
+ <li>
+ <a href="#FormingPairs">How Pairs Form</a>
+ </li>
+ <li>
+ <a href="#ChangingPairs">When to Change Partners</a>
+ </li>
+ <li>
+ <a href="#WorkingAlone">Can't I work alone?</a>
+ </li>
+ <li>
+ <a href="#Productivity">Doesn't this cut my productivity in half?</a>
+ </li>
+ <li>
+ <a href="#Hygiene">Hygiene and Etiquette Issues</a>
+ </li>
+ <li>
+ <a href="#Disabilities">Disabilities and Physical Incompatibilities</a>
+ </li>
+ <li>
+ <a href="#Distributed">Our Team is Geographically Distributed</a>
+ </li>
+ <li>
+ <a href="#BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
+ </li>
+ <li>
+ <a href="#NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
+ </li>
+ <li>
+ <a href="#Language">My Partner and I have different First Languages</a>
+ </li>
+ <li>
+ <a href="#Schedule">How do we deal with different personal schedules?</a>
+ </li>
+ <li>
+ <a href="#OddNumber">What if we have an odd number of programmers?</a>
+ </li>
+ <li>
+ <a href="#Pathologies">Pairing Pathologies</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatIsPair" name="WhatIsPair">What is pair programming?</a>
+</h3>
+<p>
+ Pair programming is a programming discipline in which all production code is written by pairs of programmers. Each pair
+ works together at a single workstation. They share the keyboard, mouse, and monitor.
+</p>
+<p>
+ The two programmers work closely together. The keyboard moves back and forth between them frequently. Both eyes are
+ locked on the screen. Both minds are immersed in the code. The code is the product of both brains, not just one. Both
+ programmers are equally engaged in writing the code, and neither can claim authorship.
+</p>
+<p>
+ Pairs are short lived. A good pairing time is four hours. Sometimes a pair may last for a day. Very rarely they might
+ last for a week. Instead, the pairs form for a few hours and then break up and reform with different partners.
+</p>
+<p>
+ During the iteration-planning meeting, each programmer signed up for tasks to complete by the end of the iteration. The
+ programmer remains responsible for those tasks. Half of the pairs he works in will be working on his tasks, and half
+ will be working on other's tasks.
+</p>
+<h3>
+ <a id="WhyPair" name="WhyPair">Why Pair Program?</a>
+</h3>
+<p>
+ Pair programming is a form of continuous code review and usually replaces the practice of code reviews and code
+ walkthroughs. The idea is that if code reviews are a good thing, then continuously reviewing the code is better.
+</p>
+<p>
+ Even though every task is the responsibility of an individual programmer, many other programmers will have worked on
+ that task with the responsible programmer. Thus, knowledge of the system spreads through the team, and no single
+ programmer can claim ownership of any part of the code. It is likely that any programmer on the team will be able to
+ work in any module in the system.
+</p>
+<p>
+ Sometimes you get stuck on ideas and can't see past them. Your pair partner can often provide the necessary nudge to
+ get you to see a different point of view.
+</p>
+<p>
+ When new people join the team, they learn by pairing. Over the course of one iteration, they will pair with everybody
+ on the team and see every part of the system currently being worked upon. This is an excellent way to train a new team
+ member.
+</p>
+<h3>
+ <a id="FormingPairs" name="FormingPairs">How Pairs Form</a>
+</h3>
+<p>
+ You come to work in the morning and attend the stand-up meeting. Then you walk up to someone and ask him if he'll help
+ you. Or perhaps someone will walk up to you and ask you to help him. The rule is: when asked, you must say yes.
+ However, you can negotiate schedule.
+</p>
+<p>
+ Pairs form naturally. Managers do not get involved with selecting pairs. Pairing is not scheduled or controlled in any
+ formal manner. The coach or another team member or the team as a whole may notice that certain team members have
+ adopted pathological pairing activities and may intervene.
+</p>
+<h3>
+ <a id="ChangingPairs" name="ChangingPairs">When to Change Partners</a>
+</h3>
+<ul>
+ <li>
+ When you get tired of your current partner.
+ </li>
+ <li>
+ When you think your current partner is too tired or distracted to help.
+ </li>
+ <li>
+ When the two of you get stuck on a concept.
+ </li>
+ <li>
+ Lunchtime.
+ </li>
+ <li>
+ Quitting time.
+ </li>
+ <li>
+ Or generally whenever you feel like it.
+ </li>
+</ul>
+<h3>
+ <a id="WorkingAlone" name="WorkingAlone">Can't I work alone?</a>
+</h3>
+<p>
+ Yes, of course. You just can't check in production code that you've written on your own.
+</p>
+<p>
+ Often we need to hide away somewhere and think some issue through without someone else breathing down our neck or
+ distracting us with news of his sister-in-law's hypoglycemia. It is perfectly OK to hide away, and every programmer
+ should have a private place to go.
+</p>
+<p>
+ When alone, it is perfectly OK to write some code to help you think through a program. However, in an XP team, you are
+ not allowed to check that code into the production environment. Instead, you can bring that code to your next pairing
+ session and walk through it with your partner. Your partner must be given every right to modify, delete, or otherwise
+ refactor it. You should help your partner become comfortable with the code and keep an open mind to every refactoring.
+</p>
+<p>
+ Often the best approach is for the two of you to review the code you wrote and then rewrite it as a pair. Remember, the
+ value of a piece of code is not actually in that code. Rather, it is in the neurons and synapses of the programmers. It
+ is always much easier to write a module the second time, and the result is always better. So, if you program alone,
+ think of the code as a rough draft that you will throw away and rewrite with your pair partner.
+</p>
+<h3>
+ <a id="Productivity" name="Productivity">Doesn't this cut my productivity in half?</a>
+</h3>
+<p>
+ Apparently not. Teams that work in pairs do not report significant loss of productivity. Indeed, they tend to report
+ that they are more productive than when they worked alone.
+</p>
+<p>
+ This anecdotal evidence is backed up by some research studies. Some of those studies can be found at <a
+ href="http://www.pairprogramming.com" target="_blank">www.pairprogramming.com</a>.
+</p>
+<p>
+ One might explain these results by viewing the programmers as two runners pacing each other. When one gets tired or
+ defocused, the other provides the motivation and inspiration to keep going. Also, the pair spends less time going down
+ dead ends and being blocked on ideas.
+</p>
+<p>
+ One thing seems clear. Typing is not the critical element. If it were, then pairing would certainly cut productivity in
+ half. It may be that pairing allows the two to think twice as quickly.
+</p>
+<h3>
+ <a id="Hygiene" name="Hygiene">Hygiene and Etiquette Issues</a>
+</h3>
+<p>
+ Hygiene and etiquette issues are bad breath, body odor, post-nasal drip, colds, rude noises, gas, motor mouths,
+ telephone-jockeys, day-traders, hypochondriacs, etc. Humans are a dirty species. Amazingly, we are usually able to get
+ along with each other's nasty little idiosyncrasies, but there are times when one person has certain habits that are
+ over the top. How do you pair with such a person?
+</p>
+<ul>
+ <li>
+ Grin and bear it, it'll only last for a couple of hours.
+ </li>
+ <li>
+ Bring breath mints.
+ </li>
+ <li>
+ Leave deodorant or gelucel on his desk.
+ </li>
+ <li>
+ Write anonymous letters to the offender.
+ </li>
+ <li>
+ Disconnect the phone.
+ </li>
+ <li>
+ Complain to your boss.
+ </li>
+ <li>
+ But, by far, the best advice is to tell your pair partner outright what bothers you.
+ </li>
+</ul>
+<h3>
+ <a id="Disabilities" name="Disabilities">Disabilities and Physical Incompatibilities</a>
+</h3>
+<ul>
+ <li>
+ Left handed vs. right handed mouse users.
+ </li>
+ <li>
+ Some people need special keyboards to control RSI or OOS.
+ </li>
+ <li>
+ Some people use Dvorak keyboards.
+ </li>
+ <li>
+ Some people need to special screens to be able to see.
+ </li>
+ <li>
+ Some people prefer a trackball to a mouse.
+ </li>
+</ul>
+<p>
+ Problems like these are pretty easy to overcome. Equip certain workstations with two keyboards, two mice, two monitors,
+ etc. Pairs don't have to work at the exact same keyboard, mouse, or monitor.
+</p>
+<p>
+ In fact, pairs don't really have to use the same workstation. They could use two completely independent workstations
+ sitting next to each other, connected with NetMeeting or some other kind of collaboration software.
+</p>
+<h3>
+ <a id="Distributed" name="Distributed">Our Team is Geographically Distributed</a>
+</h3>
+<p>
+ At best, pairing over geographical boundaries is difficult. The best approach is to split the project up into
+ sub-projects that can be done separately at each geographic location. That way the programmers at each location can
+ pair with each other and won't have to interact as much with the remote programmers.
+</p>
+<p>
+ Sometimes the project cannot be easily split amongst all the geographic sites. In that case, you can use NetMeeting or
+ other collaborative software to facilitate remote pairing. Remote pairing is possible but not as effective as local
+ pairing. When you pair locally, you have the advantage of body language, eye contact, and all the other nuances of
+ person-to-person communication to help you. When you pair remotely, you are forced to use a sub-optimal communication
+ channel.
+</p>
+<h3>
+ <a id="BossHog" name="BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
+</h3>
+<ul>
+ <li>
+ Perhaps you are outrunning him. Try to go a little slower and get him engaged.
+ </li>
+ <li>
+ Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.
+ </li>
+ <li>
+ Perhaps he thinks you aren't listening to his ideas. Make sure you talk though all ideas with him, and make sure he
+ has a chance to try as many of his ideas as you get to try of yours.
+ </li>
+ <li>
+ Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.
+ </li>
+ <li>
+ Perhaps he is just not ever going to want to pair program, no matter what. For the moment, the best you can do is
+ dissolve the pair and choose another partner. If the behavior continues, the team will have to decide what to do
+ about it. Perhaps the team will ask him to write configuration scripts or something.
+ </li>
+</ul>
+<h3>
+ <a id="NoSolution" name="NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
+</h3>
+<ul>
+ <li>
+ Gently ask him if you can drive for a while.
+ </li>
+ <li>
+ Gently ask him to describe what he is doing.
+ </li>
+ <li>
+ Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.
+ </li>
+ <li>
+ Perhaps he just can't pair program. Dissolve the pair and choose another partner. If the behavior continues, the
+ team will have to figure out what to do.
+ </li>
+</ul>
+<h3>
+ <a id="Language" name="Language">My Partner and I have different First Languages</a>
+</h3>
+<p>
+ Your only choice is to slow down and work hard to communicate. You might understand him better by writing strategic
+ notes than by talking. Work hard on helping him with pronunciation and grammar. Work hard at understanding his accent
+ and usage. It will take time, but the situation will improve. Do not give up!
+</p>
+<h3>
+ <a id="Schedule" name="Schedule">How do we deal with different personal schedules?</a>
+</h3>
+<p>
+ Some people come in early; some people stay late. How can you find pair partners if everybody has a different working
+ schedule?
+</p>
+<p>
+ Pairs only last for a few hours. All you need is enough overlap time for pairs to form and work effectively. Most
+ personal schedules allow this.
+</p>
+<p>
+ Team members may have to get creative with their scheduling to accommodate each other. Some folks may have to change
+ their schedules to make sure that others have sufficient pairing opportunity. For example, if Bill can only work in the
+ evenings, the team may decide to adopt a rotating schedule for others who can come in late one day and pair with Bill.
+</p>
+<h3>
+ <a id="OddNumber" name="OddNumber">What if we have an odd number of programmers?</a>
+</h3>
+<p>
+ Remember that pairs break up and reform frequently. The odd man out will not have to wait long before someone becomes
+ available to pair with. In the meantime, he can read his email or a trade journal or just read through some code that
+ he is unfamiliar with.
+</p>
+<h3>
+ <a id="Pathologies" name="Pathologies">Pairing Pathologies</a>
+</h3>
+<ul>
+ <li>
+ Joined at the hip. Sometimes two people decide to pair exclusively. This is not a good idea. They are missing the
+ opportunity to get the whole team's input and are isolating themselves into one part of the system. The team should
+ break them up by suggesting that they pair with others.
+ </li>
+ <li>
+ The blind leading the blind. It's not a good idea for new members of the team to pair too often with other new
+ members of the team. Newbies should pair most often with team members with more seniority.
+ </li>
+</ul>
+<p>
+ <br />
+ <br />
+</p><!-- END:mainDescription,-nfbUMyTTqEbCp3HDn-NjOA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/planning_game.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/planning_game.html
new file mode 100644
index 0000000..0672af4
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/planning_game.html
@@ -0,0 +1,294 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\planning_game.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: planning_game.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,6.7335956461328426E-307 CRC: 2201201175 -->Planning Game<!-- END:presentationName,6.7335956461328426E-307 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-85F1Tegv16godTFTKyPdww CRC: 1850717230 --><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning__in_xp" name="XE_planning__in_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#Overview">XP Planning Overview</a>
+ </li>
+ <li>
+ <a href="#Iterations">Iterations</a>
+ </li>
+ <li>
+ <a href="#Stories">User Stories</a>
+ </li>
+ <li>
+ <a href="#ReleasePlanning">Release Planning</a>
+ </li>
+ <li>
+ <a href="#IterationPlanning">Iteration Planning</a>
+ </li>
+ <li>
+ <a href="#TaskPlanning">Task Planning</a>
+ </li>
+ <li>
+ <a href="#Recovery">Recovery</a>
+ </li>
+ <li>
+ <a href="#Feedback">Feedback</a>
+ </li>
+ <li>
+ <a href="#AcceptanceTests">Acceptance Tests</a>
+ </li>
+ <li>
+ <a href="#First">How do we create budgets for the first iteration and release?</a>
+ </li>
+ <li>
+ <a href="#Velocity">How do changes in the team affect velocity?</a>
+ </li>
+</ul>
+<h3>
+ <a id="Overview" name="Overview">XP Planning Overview</a>
+</h3>
+<p>
+ An XP project is broken down into a set of two-week iterations. Each iteration follows the next in a linear sequence.
+ Executable code that passes unit tests and acceptance tests is the core deliverable beginning with the first iteration.
+</p>
+<p>
+ Planning an XP project is a continuous activity. There is no master plan that is decided upon at the start of the
+ project and that is followed until the end. An XP project is planned in detail, one iteration at a time. The plan for
+ an iteration is created at the beginning of that iteration. The plan is then checked and adjusted continuously
+ throughout the iteration.
+</p>
+<p>
+ Iterations are grouped into larger milestones called releases. A typical release spans two to three months. At the
+ beginning, the release plan is created. This is a very rough plan that tentatively describes the features that the
+ project team believes can and should be implemented during that time. The release plan is continuously updated as each
+ iteration within the release provides more data.
+</p>
+<p>
+ The overriding principle of XP planning is feedback. Every iteration provides data about the velocity of the team. That
+ data is used to continuously calibrate the plan. Measuring the results of each iteration generates a continuous stream
+ of data. The team and its managers use that data to make decisions and take actions that will improve the project
+ outcome.
+</p>
+<h3>
+ <a id="Iterations" name="Iterations">Iterations</a>
+</h3>
+<p>
+ An iteration is simply a span of time in which the team implements a set of features. In an XP project, this time is
+ typically two weeks and should never be longer than four. The team should decide how long its iterations should be and
+ then stick to that time. It is not wise to continuously change the duration of the iterations because that makes
+ determination of a team's velocity more complicated.
+</p>
+<p>
+ When an iteration is over, it is over, irrespective of how much the iteration accomplished. It is never wise to extend
+ an iteration in order to provide more time to finish the planned deliverables. The ability to plan an XP project
+ depends strongly on fixed-length iterations of consistent duration and ruthless termination of each iteration
+ irrespective of whether the planned tasks are complete to allow the velocity to be measured.
+</p>
+<h3>
+ <a id="Stories" name="Stories">User Stories</a>
+</h3>
+<p>
+ The content or scope of an XP project is described in user stories. User stories are very simple descriptions of the
+ features to be developed. Each story is typically written on a single index card and contains virtually no detail. The
+ card contains little more than the name of the feature.
+</p>
+<p>
+ Stories are the tokens of planning. When we create a release plan or an iteration plan, we select the stories we want
+ in that release or iteration and schedule them. Once a story is scheduled for an iteration, two things must happen in
+ that iteration. First, the details of the story must be fleshed out, resulting in the creation of appropriate
+ acceptance tests. Second, the story must be implemented so that it passes those acceptance tests.
+</p>
+<p>
+ In order to choose which stories to schedule for an iteration, we need to know two things: how important is the story
+ and how long will the story take to implement. The first comes from the judgment of the customers/stakeholders, and the
+ second comes from the judgment of the developers.
+</p>
+<p>
+ Developers estimate the stories. The estimate for a user story should neither be too big nor too small. Those that are
+ too big should be split into multiple stories, and those that are too small should be merged. A good guideline is to
+ keep the size of a user story between two days and a week of team effort. The customer/stakeholders and the developers
+ will negotiate over the stories, splitting and merging as necessary, until they are appropriately sized.
+</p>
+<p>
+ Estimates are written on the story cards as numbers. We refer to these numbers as story points. It doesn't matter what
+ units were originally used to create the estimates. It might have been man-days or man weeks or something else. Once
+ the estimates are made, we forget the units and simply refer to them as story points.
+</p>
+<h3>
+ <a id="ReleasePlanning" name="ReleasePlanning">Release Planning</a>
+</h3>
+<p>
+ The customer/stakeholders know what features they want completed for the next release. The developers know how much
+ they can get done in the next release. The developers give the customer/stakeholders a budget for the release based
+ upon how much the developers got done in the previous release. If the developers finished 720 story points in the last
+ release, then it is safe to say that they'll finish about 720 in this release.
+</p>
+<p>
+ The customer/stakeholders choose stories that add up to this number. They choose the stories that are most critical and
+ have the most business value. They lay them out in roughly the order in which they'd like to see them implemented. This
+ selection and ordering of the stories becomes the release plan.
+</p>
+<p>
+ Any stakeholder can look at the release plan and see about when a particular feature will be implemented. They know
+ that, if the feature is listed early, then it is likely to be completed. If a story is listed late in the plan, then
+ the risk is higher. The release plan is not static. Any time priorities change, the customer/stakeholders can change
+ the plan by reordering stories, adding new stories, removing existing stories, and so on. Thus, the release plan is
+ always changing in response to the changing business.
+</p>
+<h3>
+ <a id="IterationPlanning" name="IterationPlanning">Iteration Planning</a>
+</h3>
+<p>
+ At the beginning of each iteration, we take a half day to plan that iteration. The developers supply the
+ customer/stakeholders with a budget for the iteration based upon what they finished in the last iteration. If they got
+ 68 story points done in the last iteration, then it is safe to plan for 68 in this iteration.
+</p>
+<p>
+ The customer/stakeholders select the stories from the release plan that they feel are most important for this
+ iteration. The sum of the selected story points cannot exceed the budget given by the developers.
+</p>
+<p>
+ Though the customer/stakeholders can suggest an ordering for the stories in an iteration, the developers are not bound
+ to that ordering. The developers are free to rearrange the stories within the iteration in any manner that makes sense.
+</p>
+<p>
+ Once the iteration has begun, the customer/stakeholders cannot make arbitrary changes to the stories in that iteration.
+ Any change has to be carefully negotiated with the developers. If the customer/stakeholders want to remove a story and
+ replace it with another, they must check with the developers to see if that will fit in the iteration. If the
+ developers agree, then the change can be made. If the developers do not agree then the customer/stakeholder may decide
+ to wait until the next iteration or may decide to completely abort the current iteration and plan a new iteration.
+</p>
+<h3>
+ <a id="TaskPlanning" name="TaskPlanning">Task Planning</a>
+</h3>
+<p>
+ Once the stories have been selected for the iteration, then the developers break the stories down into programming
+ tasks. The tasks are recorded on a whiteboard or a flip chart.
+</p>
+<p>
+ Tasks are simple units of work that accomplish a particular goal within a story. One task might be to set up the
+ database schema for a story. Another might be to create the HTML pages for a story. Still another task might be to
+ write a servlet that checks passwords. A task should be on the order of a man-day of effort.
+</p>
+<p>
+ The breakdown of stories into tasks is a design activity. The developers consider how the stories will be developed and
+ whether or not there are any design options that allow the stories to share tasks.
+</p>
+<p>
+ Once the list of tasks is complete, the developers take turns signing up for the tasks. Each developer puts his or her
+ initials next to a task and then estimates that task. The estimate is typically in hours.
+</p>
+<p>
+ Each developer has a budget of hours that he keeps in the back of his head. This budget represents the number of hours
+ he believes he will have for the development of his tasks in this iteration. Each time a developer signs up for a task,
+ he deducts his estimate from that budget. When a developer's budget goes to zero, he stops signing up for tasks.
+</p>
+<p>
+ Ideally, at the end of sign up, all the tasks would have initials, and every developer's budget would be at zero. But
+ this is seldom the case. There are two much more likely scenarios:
+</p>
+<ul>
+ <li>
+ Everybody's budget is at zero, and there are tasks left. In this case, the developers need to work together to find
+ a better division of tasks. If a GUI guy signed up for a database task just to get some new experience, then
+ perhaps he should swap with someone who could do that task more quickly. If after such trading there are still
+ tasks left over, then the team has to ask the customer/stakeholder to remove some stories or tasks.
+ </li>
+ <li>
+ The tasks are all signed up, but some people still have budget left. In this case, the team needs to ask the
+ customer/stakeholders to give them a few more stories.
+ </li>
+</ul>
+<h3>
+ <a id="Recovery" name="Recovery">Recovery</a>
+</h3>
+<p>
+ On the day that marks the halfway point of the iteration, the team has another short meeting. Half the tasks should be
+ complete. More importantly, half the stories should be complete. More precisely, a set of stories whose points add up
+ to half the iteration budget should be complete. The nightmare we are trying to avoid is that the iteration ends with
+ all the stories 95% complete. We'd rather that 95% of the stories be complete.
+</p>
+<p>
+ If half the stories are not complete, then the team asks the customer to remove some stories from the iteration. This
+ same kind of check is made towards the end of the iteration. The team assesses how much they have working and how much
+ is left. If it appears that they may not complete all the promised stories, then they ask the customer/stakeholders to
+ remove some.
+</p>
+<p>
+ By the same token, if more than half the stories are complete by the midpoint, the developers ask the
+ customer/stakeholder for more work. Likewise, as the iteration gets close to the end, any idle developers should help
+ others complete their tasks. If it appears that all tasks will be completed early, the developers should ask the
+ customer/stakeholders for more stories.
+</p>
+<h3>
+ <a id="Feedback" name="Feedback">Feedback</a>
+</h3>
+<p>
+ The number of story points completed in the previous iteration is the team's current velocity. This velocity is used as
+ the budget for the next iteration. Thus we only commit to doing what we know we did in the last iteration.
+</p>
+<p>
+ The same is true for releases. When we plan the next release, we use the number of story points we finished in the
+ previous release.
+</p>
+<p>
+ Individual developers use the same technique for their task budgets. If they got 22 hours worth of tasks finished in
+ the last iteration, they should only sign up for 22 hours of tasks this time.
+</p>
+<h3>
+ <a id="AcceptanceTests" name="AcceptanceTests">Acceptance Tests</a>
+</h3>
+<p>
+ After the iteration-planning meeting is over, the customer/stakeholders must provide the developers with acceptance
+ tests for the stories that were selected for the iteration. Typically, these tests will be created with the help of the
+ Q/A or testing groups. These tests specify exactly to the developers what the stories being implemented must do, so
+ they must be given to the developers as early as possible.
+</p>
+<p>
+ Some XP teams manage to write their acceptance tests an iteration early. The Q/A or testing group works with the
+ customer/stakeholders during the current iteration to determine which stories are most likely to be selected for the
+ next iteration. Together, they define the set of acceptance tests that will be given to the developers during the next
+ iteration planning meeting. By planning ahead like this, the developers can have the acceptance tests for an
+ iteration's stories immediately.
+</p>
+<h3>
+ <a id="First" name="First">How do we create budgets for the first iteration and release?</a>
+</h3>
+<p>
+ If you have history from other projects, then make use of that. Otherwise, you have to guess. A good way to guess is to
+ spend a day or two trying to implement one or two stories. This should give you an inkling of your velocity.
+</p>
+<h3>
+ <a id="Velocity" name="Velocity">How do changes in the team affect velocity?</a>
+</h3>
+<p>
+ If the change is small, then it's probably best to allow the velocity to change by itself. If you got 52 story points
+ done last iteration, but this iteration you have a new team member, it's probably best to keep your velocity at 52 and
+ commit do doing just 52 story points in the next iteration. At the end of that iteration, you may find that you've done
+ a little more than 52, and you can adjust your velocity accordingly.
+</p>
+<p>
+ On the other hand, if 30% of the team is going on vacation for the next iteration, then it's probably wise to reduce
+ your velocity accordingly.
+</p>
+<p>
+ <br />
+
+</p><!-- END:mainDescription,-85F1Tegv16godTFTKyPdww -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/refactoring.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/refactoring.html
new file mode 100644
index 0000000..444aad4
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/refactoring.html
@@ -0,0 +1,637 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\refactoring.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: refactoring.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,8.137126904637637E-306 CRC: 3501494639 -->Refactoring<!-- END:presentationName,8.137126904637637E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dbA7zKOJY5WPZyLXErA9vw CRC: 2233627552 --><h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatIs">What is refactoring?</a>
+ </li>
+ <li>
+ <a href="#Why">Why should I refactor?</a>
+ </li>
+ <li>
+ <a href="#When">When should I refactor?</a>
+ </li>
+ <li>
+ <a href="#Example">An example of refactoring</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatIs" name="WhatIs">What is refactoring?</a>
+</h3>
+<p>
+ Refactoring is the act of improving the structure of a program without changing its behavior. Refactoring is done in
+ tiny little steps, each barely worth doing. In between each step, we run the relevant unit tests to make sure that the
+ changes we made have not broken anything. The edit/compile/test cycle is usually between 30 seconds and five minutes.
+</p>
+<h3>
+ <a id="Why" name="Why">Why should I refactor?</a>
+</h3>
+<p>
+ The purpose of refactoring is to improve the design and readability of the code. There are several specific goals:
+</p>
+<ul>
+ <li>
+ The code should pass all its tests.
+ </li>
+ <li>
+ It should be as expressive as it is possible for you to make it.
+ </li>
+ <li>
+ It should be as simple as it is possible for you to make it.
+ </li>
+ <li>
+ It should have no redundancy.
+ </li>
+</ul>
+<h3>
+ <a id="When" name="When">When should I refactor?</a>
+</h3>
+<p>
+ Refactoring is not something that we schedule. There is no line item in the schedule for it. There is no particular
+ time when we do it. Refactoring is done all the time. As you and your pair partner work on a task, such as writing
+ tests and code, you will notice that the code and tests are not as clean and simple as they could be. That is the time
+ to stop and refactor that code.
+</p>
+<p>
+ The rule is: <b>Don't let the sun set on bad code.</b>
+</p>
+<h3>
+ <a id="Example" name="Example">An Example of Refactoring</a>
+</h3>
+<p>
+ Consider the two unit tests and the <font size="3"><tt>Formatter</tt></font> class shown below. The <font
+ size="3"><tt>Formatter</tt></font> class works but is not as expressive as I'd like it to be. So I'll refactor it in
+ stages.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+ public void testCenterLine()
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ Formatter f = new Formatter();
+</pre>
+<pre>
+ f.setLineWidth(10);
+</pre>
+<pre>
+ assertEquals(" word ", f.center("word"));
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public void testOddCenterLine() throws Exception
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ Formatter f = new Formatter();
+</pre>
+<pre>
+ f.setLineWidth(10);
+</pre>
+<pre>
+ assertEquals(" hello ", f.center("hello"));
+</pre>
+<pre>
+ }
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<br />
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+ import java.util.Arrays;
+</pre>
+<pre>
+ public class Formatter
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ private int width;
+</pre>
+<pre>
+ private char spaces[];
+</pre>
+<pre>
+ public void setLineWidth(int width)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+ spaces = new char[width];
+</pre>
+<pre>
+ Arrays.fill(spaces, ' ');
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public String center(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ int remainder = 0;
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ int padding = (width - line.length()) / 2;
+</pre>
+<pre>
+ remainder = line.length() % 2;
+</pre>
+<pre>
+ b.append(spaces, 0, padding);
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ b.append(spaces, 0, padding + remainder);
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ }
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ The <font size="3"><tt>setLineWidth</tt></font> function is a little mysterious. What is this <font
+ size="3"><tt>spaces</tt></font> array and why is it being filled with blanks? By looking ahead into the <font
+ size="3"><tt>center</tt></font> function, we see that the <font size="3"><tt>spaces</tt></font> array is just a
+ convenience to allow us to move a number of blanks into a <font size="3"><tt>StringBuffer</tt></font>. I wonder if we
+ really need this convenience array.
+</p>
+<p>
+ For the moment, I'm going to pull the initialization of the array out into its own function named <font
+ size="3"><tt>buildArrayOfSpaces</tt></font>. That way, it's all in one place, and I can think about it a little more
+ clearly.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public void setLineWidth(int width)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+<b>buildArrayOfSpaces(width);</b>
+</pre>
+<pre>
+}
+</pre>
+<pre>
+private void <b>buildArrayOfSpaces(int width)</b>
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ spaces = new char[width];
+</pre>
+<pre>
+ Arrays.fill(spaces, ' ');
+</pre>
+<pre>
+}
+</pre>
+<pre>
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ I don't like the way <font size="3"><tt>center</tt></font> function is constructed. There is math scattered all through
+ it. I think we can rearrange the math to make things clearer.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public String center(String line)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+<b>int remainder = line.length() % 2;</b>
+</pre>
+<pre>
+<b>int numberOfBlanksInFront = (width - line.length()) / 2;</b>
+</pre>
+<pre>
+ <b>int numberOfBlanksAtEnd = (width - line.length()) / 2 + remainder;</b>
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksInFront</b>);
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksAtEnd</b>);
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+}
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font><br />
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ This looks good, but we can reduce the clutter by changing some of the variables into functions.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public String center(String line)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksInFront(line)</b>);
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksBehind(line)</b>);
+</pre>
+<pre>
+ return b.toString();
+}
+</pre>
+<pre>
+<b>private int numberOfBlanksBehind(String line)</b>
+</pre>
+<pre>
+<b>{</b>
+</pre>
+<pre>
+ <b>int extraBlankIfOdd = line.length() % 2;</b>
+</pre>
+<pre>
+ <b>return (width - line.length()) / 2 + extraBlankIfOdd;</b>
+</pre>
+<pre>
+<b>}</b>
+</pre>
+<pre>
+<b>private int numberOfBlanksInFront(String line)</b>
+</pre>
+<pre>
+<b>{</b>
+ <b>return (width - line.length()) / 2;</b>
+</pre>
+<pre>
+<b>}</b>
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ This makes the <font size="3"><tt>center</tt></font> function read a little better. However, the use of the <font
+ size="3"><tt>StringBuffer.append</tt></font> function is a little confusing. We might be able to improve it a little by
+ creating a more explicit function.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public String center(String line)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+<b>appendBlanks(b, numberOfBlanksInFront(line));</b>
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+<b>appendBlanks(b, numberOfBlanksBehind(line));</b>
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+}
+</pre>
+<pre>
+<strong>private void appendBlanks(StringBuffer b, int numberOfBlanks)</strong>
+</pre>
+<pre>
+<strong>{</strong>
+</pre>
+<pre>
+ <strong>b.append(spaces, 0, numberOfBlanks);</strong>
+</pre>
+<pre>
+<strong>}</strong>
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ Now we can rewrite <font size="3"><tt>appendBlanks</tt></font> to avoid using the <font size="3"><tt>spaces</tt></font>
+ array.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+import java.util.Arrays;
+</pre>
+<pre>
+public class Formatter
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ private int width;
+</pre>
+<pre>
+ public void setLineWidth(int width)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public String center(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ appendBlanks(b, numberOfBlanksInFront(line));
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ appendBlanks(b, numberOfBlanksBehind(line));
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private void appendBlanks(StringBuffer b, int numberOfBlanks)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+<b> while(numberOfBlanks-- > 0)</b>
+</pre>
+<pre>
+<b> b.append(' ');</b>
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private int numberOfBlanksBehind(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ int extraBlankIfOdd = line.length() % 2;
+</pre>
+<pre>
+ return (width - line.length()) / 2 + extraBlankIfOdd;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private int numberOfBlanksInFront(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ return (width - line.length()) / 2; }
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+}<font size="3"><b><i>Run the tests: the tests pass</i></b></font><br />
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ The names of functions like <font size="3"><tt>numberOfBlanksBehind</tt></font> imply that the reader knows that these
+ will be called from the <font size="3"><tt>center</tt></font> function. We should eliminate this implication by
+ renaming those functions.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+import java.util.Arrays;
+</pre>
+<pre>
+public class Formatter
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ private int width;
+</pre>
+<pre>
+ public void setLineWidth(int width)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public String center(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ appendBlanks(b, <b>numberOfBlanksToLeftOfCenter</b>(line));
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ appendBlanks(b, <b>numberOfBlanksToRightOfCenter</b>(line));
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private void appendBlanks(StringBuffer b, int numberOfBlanks)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ while(numberOfBlanks-- > 0)
+</pre>
+<pre>
+ b.append(' ');
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private int <b>numberOfBlanksToRightOfCenter</b>(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ int extraBlankIfOdd = line.length() % 2;
+</pre>
+<pre>
+ return (width - line.length()) / 2 + extraBlankIfOdd;
+</pre>
+<pre>
+ }
+
+ private int <b>numberOfBlanksToLeftOfCenter</b>(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ return (width - line.length()) / 2;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+}
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ And I think we are done. You might find other refactorings to do, or you might not agree with all of the refactorings
+ I've done. That's to be expected. The point is, however, that I have put a lot of effort into the readability and
+ simplicity of this class. That effort will help others understand this class and make it easier for them to change the
+ class when the time comes.
+</p><!-- END:mainDescription,-dbA7zKOJY5WPZyLXErA9vw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/md_state3.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/md_state3.gif
new file mode 100644
index 0000000..ee64962
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/md_state3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif
new file mode 100644
index 0000000..182076e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg
new file mode 100644
index 0000000..08b590c
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_driven_development_tdd.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_driven_development_tdd.html
new file mode 100644
index 0000000..0bf86e5
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_driven_development_tdd.html
@@ -0,0 +1,646 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\test_driven_development_tdd.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_driven_development_tdd.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.9254165491375454E-306 CRC: 3305150119 -->Test Driven Development (TDD)<!-- END:presentationName,3.9254165491375454E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-jc10ie6UDWUJzSDfsQExjw CRC: 606219137 --><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a id="XE_test_driven_development__in_xp"
+name="XE_test_driven_development__in_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatIs">What is TDD?</a>
+ </li>
+ <li>
+ <a href="#Java">A TDD Example in Java</a>
+ </li>
+ <li>
+ <a href="#Benefits">What are the benefits of TDD?</a>
+ </li>
+ <li>
+ <a href="#Costs">What are the costs of TDD?</a>
+ </li>
+ <li>
+ <a href="#Principles">What testing principles should I employ?</a>
+ </li>
+ <li>
+ <a href="#GUIS">How do I test GUIs?</a>
+ </li>
+ <li>
+ <a href="#Embedded">How do I test embedded systems?</a>
+ </li>
+ <li>
+ <a href="#Concurrency">How do I test concurrency?</a>
+ </li>
+ <li>
+ <a href="#Database">How do I test database transactions?</a>
+ </li>
+ <li>
+ <a href="#Servlets">How do I test servlets?</a>
+ </li>
+ <li>
+ <a href="#WebPages">How do I test web pages?</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatIs" name="WhatIs">What is TDD?</a>
+</h3>
+<p>
+ TDD is the practice of writing unit tests and production code concurrently and at a very fine level of granularity. A
+ pair of programmers first write a small portion of a unit test, and then they write just enough production code to make
+ that unit test compile and execute. Then they write a little bit more of the test and then add enough production code
+ to make that new bit compile and pass. This cycle lasts somewhere between 30 seconds and five minutes. Rarely does it
+ grow to ten minutes. In each cycle, the tests come first. Once a unit test is done, the pair goes on to the next test
+ until they run out of tests for the task they are currently working on.
+</p>
+<h3>
+ <a id="Java" name="Java">A TDD Example in Java</a>
+</h3>
+<p>
+ What follows is a simple example of test-driven development. The program we are writing is a text formatter that can
+ take arbitrary strings and can horizontally center them in a page. The first column shows the tests, and the second
+ column shows the production code. The test is always written first and compiled. If the compile fails, then production
+ code is added to make the compile succeed. Then the test is run to see if it passes. If the test fails, then production
+ code is added to make the test pass. If the test passes, then a new test is added.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+ <div align="center">
+ <font size="-1"><i><b>First we write the test</b></i></font>
+ </div>
+ </td>
+ <td>
+ <div align="center">
+ <font size="-1"><i><b>Then we write the production code</b></i></font>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ <tbody>
+ <tr>
+ <td>
+<pre>
+<font size="2">public void testCenterLine(){
+ Formatter f = new Formatter();
+}</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">does not compile</font>
+</pre>
+ </div>
+ </td>
+ <td>
+<pre>
+<font size="2">class Formatter{
+}
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#008000" size="2">compiles and passes</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+<pre>
+<font size="2">public void testCenterLine(){
+ Formatter f = new Formatter();
+ f.setLineWidth(10);
+ assertEquals(" word ", f.center("word"));
+}
+
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">does not compile</font>
+</pre>
+ </div>
+ </td>
+ <td>
+<pre>
+<font size="2">class Formatter{
+ public void setLineWidth(int width) {
+ }
+
+
+ public String center(String line) {<br />
+ return "";
+ }
+}</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">compiles and fails</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <font size="2"> </font>
+ </td>
+ <td>
+<pre>
+<font size="2">import java.util.Arrays;
+
+
+public class Formatter {
+ private int width;
+ private char spaces[];
+
+ public void setLineWidth(int width) {
+ this.width = width;
+ spaces = new char[width];
+ Arrays.fill(spaces, ' ');
+ }
+
+
+ public String center(String line) {
+ StringBuffer b = new StringBuffer();
+ int padding = width/2 - line.length();
+ b.append(spaces, 0, padding);
+ b.append(line);
+ b.append(spaces, 0, padding);
+ return b.toString();
+ }
+}
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">compiles and unexpectedly fails</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <font size="2"> </font>
+ </td>
+ <td>
+<pre>
+<font size="2">public String center(String line) {
+ StringBuffer b = new StringBuffer();
+ <b>int padding = (width - line.length()) / 2;</b>
+ b.append(spaces, 0, padding);
+ b.append(line);
+ b.append(spaces, 0, padding);
+ return b.toString();
+}
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#008000" size="2">compiles and passes</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+<pre>
+<font size="2">public void testCenterLine() {
+ Formatter f = new Formatter();
+ f.setLineWidth(10);
+ assertEquals(" word ", f.center("word"));
+}
+
+<b>public void testOddCenterLine() {
+ Formatter f = new Formatter();
+ f.setLineWidth(10);
+ assertEquals( " hello ", f.center("hello"));
+}</b>
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">compiles and fails</font>
+</pre>
+ </div>
+ </td>
+ <td>
+<pre>
+<font size="2">public String center(String line) {
+ <b>int remainder = 0;</b>
+ StringBuffer b = new StringBuffer();
+ int padding = (width - line.length()) / 2;
+ <b>remainder = line.length() % 2;</b>
+ b.append(spaces, 0, padding);
+ b.append(line);
+ b.append(spaces, 0, padding + <b>remainder</b>);
+ return b.toString();
+}
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#008000" size="2">compiles and passes</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<h3>
+ <a id="Benefits" name="Benefits">What are the benefits of TDD?</a>
+</h3>
+<ul>
+ <li>
+ <b>Test Coverage</b>. If you follow the rules of TDD, then virtually 100% of the lines of code in your production
+ program will be covered by unit tests. This does not cover 100% of the paths through the code, but it does make
+ sure that virtually every line is executed and tested.<br />
+ </li>
+ <li>
+ <b>Test Repeatability</b>. The tests can be run any time you like. This is especially useful after you've made a
+ change to the production code. You can run the tests to make sure you haven't broken anything. Having the tests to
+ back you up can give you the courage to make changes that would otherwise be too risky to make.<br />
+ </li>
+ <li>
+ <b>Documentation</b>. The tests describe your understanding of how the code should behave. They also describe the
+ API. Therefore, the tests are a form of documentation. Unit tests are typically pretty simple, so they are easy to
+ read. Moreover, they are unambiguous and executable. Finally, if the tests are run every time any change is made to
+ the code, they will never get out of date.<br />
+ </li>
+ <li>
+ <b>API Design</b>. When you write tests first, you put yourself in the position of a user of your program's API.
+ This can only help you design that API better. Your first concern, as you write the tests, is to make it easy and
+ convenient to use that API.<br />
+ </li>
+ <li>
+ <b>System Design</b>. A module that is independently testable is a module that is decoupled from the rest of the
+ system. When you write tests first, you automatically decouple the modules you are testing. This has a profoundly
+ positive effect on the overall design quality of the system.<br />
+ </li>
+ <li>
+ <b>Reduced Debugging</b>. When you move in the tiny little steps recommended by TDD, it is hardly ever necessary to
+ use the debugger. Debugging time is reduced enormously.<br />
+ </li>
+ <li>
+ <b>Your code worked a minute ago!</b> If you observe a team of developers who are practicing TDD, you will notice
+ that every pair of developer had their code working a minute ago. It doesn't matter when you make the observation!
+ A minute or so ago, each pair ran their code, and it passed all its tests. Thus, you are never very far away from
+ making the system work.<br />
+ </li>
+</ul>
+<h3>
+ <a id="Costs" name="Costs">What are the costs of TDD?</a>
+</h3>
+<ul>
+ <li>
+ Programming in tiny cycles can seem inefficient. Programmers often find it frustrating to work in increments that
+ are so small that they know the outcome of the test. It sometimes seems that such a tiny step is not worth
+ taking.<br />
+ </li>
+ <li>
+ A lot of test code is produced. It is not uncommon for the bulk of test code to exceed the bulk of production code
+ by a large amount. This code has to be maintained at a significant cost.<br />
+ </li>
+ <li>
+ A lot of time is spent keeping the tests in sync with the production code. Programmers sometimes feel that time
+ spent on keeping the tests working and well structured is time that is not being spent on the customer's
+ needs.<br />
+ </li>
+</ul>
+<h3>
+ <a id="Principles" name="Principles">What testing principles should I employ?</a>
+</h3>
+<ul>
+ <li>
+ <b>Isolation</b>. When writing a unit test for a module, consider whether you want that module to invoke other
+ modules. If not, then isolate the module with interfaces. For example, suppose you are testing a module that
+ interacts with the database. The test has nothing to do with the database; it simply tests the way that the module
+ manipulates the database. So you isolate the module from the database by creating an interface that represents the
+ database and that the module uses. Then, for the purposes of the test, you implement that interface with a test
+ stub. This kind of isolation greatly decreases the amount of coupling in the overall system.
+ </li>
+</ul>
+<p>
+ <img height="166" alt="" src="resources/xp_tdd_guid_database.jpg" width="403" />
+</p>
+<ul>
+ <li>
+ <b>Simplicity</b>. Keep your edit/compile/test cycles extremely short: less than five minutes on average. Write
+ only enough production code to make the current tests pass. Try not to write code that will make future tests pass.
+ At every edit/compile/test cycle, keep the code as simple as it can be.<br />
+ </li>
+ <li>
+ <b>Increase Generality</b>. As you add test cases, the production code should become more and more general. Always
+ try to increase generality. For example, consider the following test case:<br />
+
+ <blockquote>
+ <blockquote>
+<pre>
+ public testThreeSquared() { assertEquals(9, MyClass.square(3)); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ We might make this test pass by writing:
+ </p>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+<pre>
+ public class MyClass { public static int square(int n) { return 9; } }
+</pre>
+ </blockquote>
+ <p>
+ This conforms to the simplicity principle. If <font size="3"><tt>testThreeSquared</tt></font> were the only test
+ case that mattered, then this implementation would be correct. Of course, we know that it is incorrect, but in its
+ current form it verifies that the test case actually passes when it is supposed to. Now suppose that we add a new
+ test case:
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public testFourSquared() { assertEquals(16, MyClass.square(4)); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ We could make this pass by changing the square function as follows:
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public static int square(int n) { if (n == 3) return 9; else return 16; }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ While this would pass the test, it violates the rule to make the code more general. To make the code more general,
+ we have to return the square of the argument.
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public static int square(int n) { return n*n; }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ This solution passes all the tests, is simple, and increases the generality of the solution.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <b>Corner Cases and Boundary Conditions</b>. Corner cases and boundary conditions are implemented in the production
+ code with if statements or other similar decision structures. Don't write these statements unless you have a unit
+ test that is failing because they don't exist. For example, let's say you are calculating weekly pay for an hourly
+ employee.
+ <blockquote>
+ <blockquote>
+<pre>
+ public void testHourlyPay() { double hourlyRate = 10.00; double hoursWorked = 8; Employee e = new Employee(hourlyRate); assertEquals(80.00, e.calculatePay(hoursWorked)); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ The code that makes this pass looks like this:
+ </p>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <blockquote>
+<pre>
+ public class Employee { private double hourlyRate; public Employee(double hourlyRate) { this.hourlyRate = hourlyRate; } public double calculatePay(double hoursWorked) { return hourlyRate * hoursWorked; } }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ Now let's say we want to calculate overtime pay. Any hours over eight are charged at time-and-a-half. The first
+ thing we do is add the new failing test case:
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public void testOvertime() { double hourlyRate = 10.00; double hoursWorked = 10; Employee e = new Employee(hourlyRate); assertEquals(110.00, e.calculatePay(hoursWorked); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ <i>Then</i> we make the test case pass by changing the production code.
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public double calculatePay(double hoursWorked) { double overtimeRate = hourlyRate * 1.5; double normalHours = Math.min(hoursWorked, 8.0); double overtimeHours = hoursWorked ̵; normalHours; return (normalHours * hourlyRate) + (overtimeHours * overtimeRate); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ Avoid adding any <font size="3"><tt>if, while, for, do,</tt></font> or any other type of conditional without a
+ failing test case. Remember to add test cases for each such boundary condition.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <b>Test Anything That Could Possibly Break</b>. By the same token, don't bother to test things that cannot possibly
+ break. For example, it is usually fruitless to test simple accessors and mutators.
+ <blockquote>
+ <blockquote>
+<pre>
+ public void testAccessorAndMutator() { X x = new X(); x.setField(3); assertEquals(3, x.getField()); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ Accessors and mutators cannot reasonably break. So there's no point in testing them. Judgment clearly has to be
+ applied to use this rule. You will be tempted to avoid a necessary unit test by claiming that the code cannot
+ possibly break. You'll know you've fallen into this habit when you start finding bugs in methods you thought
+ couldn't break.
+ </p>
+ </li>
+ <li>
+ <b>Keep Test Data in the Code</b>. It is sometimes tempting to put test data into a file, especially when the input
+ to a module is a file. However, the best place for test data is in the unit test code itself. For example, assume
+ we have a function that counts the number of characters in a file. The signature for this function is:
+ <blockquote>
+ <blockquote>
+<pre>
+ public int count(String fileName).
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ In order to keep the test data in the unit test code, the test should be written this way:
+ </p>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <blockquote>
+ <blockquote>
+<pre>
+ public testCount() { File testFile = new File("testFile"); FileOutputStream fos = new FileOutputStream(testFile); PrintStream ps = new PrintStream(fos); ps.print("Oh, you Idiots!"); ps.close(); assertEquals(15, FileUtil.count("testFile")); testFile.delete(); }
+</pre>
+ </blockquote>
+ </blockquote>
+ </li>
+</ul>
+<blockquote>
+ <p>
+ This keeps all the data relevant to the test in one place.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <b>Test Pruning</b>. Sometimes you'll write tests that are useful for a time but become redundant as other tests
+ take over their role. Don't be afraid to remove old redundant tests. Keep the test suite as small as possible
+ without compromising coverage.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Keep Test Time Short</b>. The effectiveness of the tests depends upon convenience. The more convenient it is to
+ run the tests, the more often they will be run. Thus, it is very important to keep the test run time very short. In
+ a large system, this means partitioning the tests.<br />
+ <br />
+ When working on a particular module, you'll want to choose the tests that are relevant to that module and the
+ surrounding modules. Keep the test time well under a minute. Ten seconds is often too long.<br />
+ <br />
+ When checking in a module, run a test suite that tests the whole system but takes no more than 10 minutes to run.
+ This may mean you'll have to pull out some of the longer running tests.<br />
+ <br />
+ Every night, run all the tests in the system. Keep the running time small enough so that they can be run more than
+ once before morning just in case there is a problem that forces a rerun.
+ </li>
+</ul>
+<h3>
+ <a id="GUIS" name="GUIS">How do I test GUIs?</a>
+</h3>
+<p>
+ The trick to writing unit tests for GUIs is separation and decoupling. Separate the GUI code into three layers,
+ typically called <b>Model</b>, <b>View</b>, and <b>Presenter</b>:
+</p>
+<ul>
+ <li>
+ The <b>Model</b> understands the business rules of the items that are to be displayed on the screen. All relevant,
+ business-related policies are implemented in this module. Therefore, this module is easy to test based solely on
+ its inputs and outputs.<br />
+ </li>
+ <li>
+ The <b>Presenter</b> understands how the data is to be presented and how the user will interact with that data. It
+ knows that there are buttons, check boxes, text fields, etc. It knows that sometimes the buttons need to be
+ disabled (grayed), and it knows sometimes text fields are not editable. It knows, at a mechanical level, how the
+ data are displayed and how the interactions take place. However, it does not know anything about the actual GUI
+ API. For example, if you are writing a Java Swing GUI, the Presenter does not use any of the swing classes. Rather,
+ it sends messages to the View to take care of the actual display and interaction. Thus, the Presenter can be
+ tested, again, based solely on its inputs from the Model and its outputs to the View.<br />
+ </li>
+ <li>
+ The <b>View</b> understands the GUI API. It makes no policy, selection, or validation decisions. It has virtually
+ zero intelligence. It is simply a shim that ties the interface used by the Presenter to the GUI API. It can be
+ tested by writing tests that check the wiring. The tests walk through the GUI data structures, making sure that the
+ appropriate button, text fields, and check boxes have been created. The tests send events to the GUI widgets and
+ make sure the appropriate callbacks are invoked.
+ </li>
+</ul>
+<h3>
+ <a id="Embedded" name="Embedded">How do I test embedded systems?</a>
+</h3>
+<p>
+ Some software is written to control hardware. You can test this software by writing a hardware simulator. The tests set
+ the hardware simulator up into various states and then drive the system to manipulate that hardware. Finally, the tests
+ query the simulation to ensure that the hardware was driven to the correct final state.
+</p>
+<h3>
+ <a id="Concurrency" name="Concurrency">How do I test concurrency?</a>
+</h3>
+<p>
+ Some software is reentrant or concurrent. Race conditions can make the software behavior non-deterministic. There are
+ failure modes that can be both severe and strongly dependent upon timing and order of events. Software that works
+ 99.999% of the time can fail that last .001% of the time due to concurrency problems. Finding these problems is a
+ challenge.
+</p>
+<p>
+ Usually exhaustive Monte Carlo testing is used to attempt to drive the system through as many states as possible.
+</p>
+<p>
+ Once concurrency problems are discovered, tests can be written that drive the system to the failure state and then
+ prove the failure. Thereafter, the problem can be repaired, and the test remains in the test suite as a regression
+ test.
+</p>
+<h3>
+ <a id="Database" name="Database">How do I test database transactions?</a>
+</h3>
+<p>
+ Almost always the best way to do this is to create an interface that represents the database. Each test case can
+ implement that interface and pretend to be the database, supplying its own data and interpreting the calls made by the
+ module under test. This prevents test data from actually being written and read from the database. It also allows the
+ test code to force failure conditions that are otherwise hard to simulate.
+</p>
+<p>
+ See: <a href="http://c2.com/cgi/wiki?MockObject%20" target="_blank">http://c2.com/cgi/wiki?MockObject</a>
+</p>
+<h3>
+ <a id="Servlets" name="Servlets">How do I test Servlets?</a>
+</h3>
+<p>
+ Servlets are simply pipes through which form data passes into a program and HTML passes out. The trick to testing a
+ servlet is to separate the program from the pipe. Keep the servlet code as thin as possible. Put your program in plain
+ old classes that don't derive from Servlet. Then you can test those plain old classes as usual. If the servlet itself
+ is thin enough, it may be too simple to bother testing.
+</p>
+<p>
+ Of course, you can also set up your own little servlet invoker or use one of the open source versions. These programs
+ act like a web server and fire servlets for you. You pass the form data to them, and they pass the HTML back to you.
+</p>
+<p>
+ See:
+</p>
+<blockquote>
+ <a href="http://c2.com/cgi/wiki?JunitServlet" target="_blank">http://c2.com/cgi/wiki?JunitServlet</a><br />
+ <a href="http://c2.com/cgi/wiki?ServletTesting" target="_blank">http://c2.com/cgi/wiki?ServletTesting</a><br />
+ <a href="http://strutstestcase.sourceforge.net/" target="_blank">http://strutstestcase.sourceforge.net/</a>
+</blockquote>
+<h3>
+ <a id="WebPages" name="WebPages">How do I test web pages?</a>
+</h3>
+<p>
+ An HTML document is almost an XML document. There is a tool that allows you to query an HTML document as though it were
+ an XML document. That tool is called HTTPUnit. Using this tool, you can write tests that inspect the innards of an HTML
+ document without worrying about white space or formatting issues. Another tool called HTMLUnit also does something
+ similar. HTMLUnit includes support for testing HTML pages with embedded JavaScript.
+</p>
+<p>
+ See:
+</p>
+<blockquote>
+ <a href="http://httpunit.sourceforge.net/" target="_blank">http://httpunit.sourceforge.net/</a><br />
+ <a href="http://htmlunit.sourceforge.net/" target="_blank">http://htmlunit.sourceforge.net/</a><br />
+</blockquote>
+<p>
+ <br />
+
+</p><!-- END:mainDescription,-jc10ie6UDWUJzSDfsQExjw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.html
new file mode 100644
index 0000000..bd3e8ed
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.html
@@ -0,0 +1,1772 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\test_ideas_for_booleans_and_boundaries.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_ideas_for_booleans_and_boundaries.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.7150344523489172E-305 CRC: 4149143832 -->Test Ideas for Booleans and Boundaries<!-- END:presentationName,1.7150344523489172E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-FX8hDYUKOXsrQulFe9lwtw CRC: 1029290686 --><a id="XE_test__developer_testing__test_ideas__for_booleans_and_boundaries"
+name="XE_test__developer_testing__test_ideas__for_booleans_and_boundaries"></a><a
+id="XE_test-ideas__for_booleans_and_boundaries" name="XE_test-ideas__for_booleans_and_boundaries"></a><a
+id="XE_design__developer_testing__test_ideas__for_booleans_and_boundaries"
+name="XE_design__developer_testing__test_ideas__for_booleans_and_boundaries"></a>
+<h3>
+ <a id="Introduction" name="Introduction"></a>Introduction
+</h3>
+<p>
+ Test ideas are based on <a href="./../../../glossary/glossary.htm#fault_model" target="_blank">fault models</a>,
+ notions of which faults are plausible in software and how those faults can best be uncovered. This guideline shows how
+ to create test ideas from boolean and relational expressions. It first motivates the techniques by looking at code,
+ then describes how to apply them if the code hasn't been written yet or is otherwise unavailable.
+</p>
+<h3>
+ <a id="BooleanExpressions" name="BooleanExpressions"></a><b>Boolean Expressions</b>
+</h3>
+<p>
+ Consider the following code snippet, taken from an (imaginary) system for managing bomb detonation. It's part of the
+ safety system and controls whether the "detonate bomb" button push is obeyed.
+</p>
+<blockquote>
+<pre>
+if (publicIsClear || technicianClear) {
+ bomb.detonate();
+}
+</pre>
+</blockquote>
+<p>
+ The code is wrong. The <font size="+0">||</font> should be an <font size="+0">&&</font>. That mistake will have
+ bad effects. Instead of detonating the bomb when both the bomb technician and public are clear, the system will
+ detonate when <i>either</i> is clear.
+</p>
+<p>
+ What test would find this bug?
+</p>
+<p>
+ Consider a test in which the button is pushed when both the technician and public are clear. The code will allow the
+ bomb to be detonated. But-and this is important-the <i>correct</i> code (the one that uses an <font
+ size="+0">&&</font>) would do the same. So the test is useless at finding this fault.
+</p>
+<p>
+ Similarly, this incorrect code behaves correctly when both the technician and public are next to the bomb: the bomb is
+ not detonated.
+</p>
+<p>
+ To find the bug, you have to have a case in which the code as written evaluates differently than the code that should
+ have been written. For example, the public must be clear, but the bomb technician is still next to the bomb. Here are
+ all the tests in table form:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="20%">
+ <p align="center">
+ publicIsClear
+ </p>
+ </th>
+ <th scope="col" width="20%">
+ <p align="center">
+ technicianClear
+ </p>
+ </th>
+ <th scope="col" width="20%">
+ <p align="center">
+ Code as written...
+ </p>
+ </th>
+ <th scope="col" width="20%">
+ <p align="center">
+ Correct code would have...
+ </p>
+ </th>
+ <th width="20%">
+
+ </th>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">detonates</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ test is useless (for this fault)
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">detonates</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">not detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ useful test
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">detonates</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">not detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ useful test
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">does not detonate</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">not detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ test is useless (for this fault)
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The two middle tests are both useful for finding this particular fault. Note, however, that they're redundant: since
+ either will find the fault, you needn't run both.
+</p>
+<p>
+ There are other ways in which the expression might be wrong. Here are two lists of common mistakes in boolean
+ expressions. The faults on the left are all caught by the technique discussed here. The faults on the right might not
+ be. So this technique doesn't catch all the faults we might like, but it's still useful.
+</p>
+<div align="right">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="50%">
+ <p align="center">
+ <b>Faults detected</b>
+ </p>
+ </th>
+ <th scope="col" width="50%">
+ <p align="center">
+ <b>Faults possibly not detected</b>
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="50%">
+ Using wrong operator: a <font color="#ff0000"><b>||</b></font> b should be a<font
+ color="#ff0000"><b>&&</b></font>b
+ </td>
+ <td width="50%">
+ Wrong variable used: a&&<font color="#ff0000"><b>b</b></font>&&c should be a&&
+ <font color="#ff0000"><b>x</b></font>&&d
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ Negation is omitted or incorrect: a||b should be <font color="#ff0000"><b>!</b></font>a||b, or <font
+ color="#ff0000"><b>!</b></font> a||b should be a||b
+ </td>
+ <td width="50%">
+ Expression is too simple: a&&b should be a&&b<font
+ color="#ff0000"><b>&&c</b></font>
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ The expression is misparenthesized: a&&b||c should be a&&<font
+ color="#ff0000"><b>(</b></font>b||c<font color="#ff0000"><b>)</b></font>
+ </td>
+ <td width="50%">
+ Expressions with more than one of the faults in the left column
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ The expression is overly complex: a&&b<b>&&c</b> should be <font
+ size="+0">a&&b<br />
+ </font> (This fault is not so likely, but is easy to find with tests useful for other reasons.)
+ </td>
+ <td width="50%">
+
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ How are these ideas used? Suppose you're given a boolean expression like <font size="+0">a&&!b</font>. You
+ could construct a truth table like this one:
+</p>
+<div align="right">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="14%">
+ <p align="center">
+ a
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ b
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ a&&!b<br />
+ (code as written)
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ maybe it should be<br />
+ a<font color="#ff0000"><b>||</b></font>!b
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ maybe it should be<br />
+ <font color="#ff0000"><b>!</b></font>a&&!b
+ </p>
+ </th>
+ <th scope="col" width="15%">
+ <p align="center">
+ maybe it should be<br />
+ a&&b
+ </p>
+ </th>
+ <th scope="col" width="15%">
+ <p align="center">
+ ...
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">false</font>
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If you crunched through all the possibilities, you'd find that the first, second, and fourth possibilities are all
+ that's needed. The third expression will find no faults that won't be found by one of the others, so you needn't try
+ it. (As the expressions grow more complicated, the savings due to unneeded cases grow quickly.)
+</p>
+<p>
+ Of course, no one sane would build such a table. Fortunately, you don't have to. It's easy to memorize the required
+ cases for simple expressions. (See the next section.) For more complex expressions, such as <font
+ size="+0">A&&B||C</font>, see <a href="../../examples/extrnlcntrbtns/test/tstatmtch.htm" target="_blank">Test
+ Ideas for Mixtures of ANDs and ORs</a>, which lists test ideas for expressions with two or three operators. For even
+ more complex expressions, a <a href="http://www.testing.com/tools/multi/README.html" target="_blank">program</a> can be
+ used to generate test ideas.
+</p>
+<h3>
+ <a id="SimpleExpressionTables" name="SimpleExpressionTables"></a><b>Tables for Simple Boolean Expressions</b>
+</h3>
+<p>
+ If the expression is <font size="+0">A&&B</font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="50%">
+ <p align="center">
+ A
+ </p>
+ </th>
+ <th scope="col" width="50%">
+ <p align="center">
+ B
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is <font size="+0">A||B</font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="50%">
+ <p align="center">
+ A
+ </p>
+ </th>
+ <th scope="col" width="50%">
+ <p align="center">
+ B
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is <font size="+0">A<sub>1</sub> && A<sub>2</sub> && ... &&
+ A<sub>n</sub></font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1,</sub> A<sub>2</sub>, ..., and A<sub>n</sub> are all true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1</sub> is false, all the rest are true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>2</sub> is false, all the rest are true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>n</sub> is false, all the rest are true
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p align="left">
+ If the expression is <font size="+0">A<sub>1</sub> || A<sub>2</sub> || ... || A<sub>n</sub></font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1,</sub> A<sub>2</sub>, ..., and A<sub>n</sub> are all false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1</sub> is true, all the rest are false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>2</sub> is true, all the rest are false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>n</sub> is true, all the rest are false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is <font size="+0">A</font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ So, when you need to test <font size="+0">a&&!b</font>, you can apply the first table above, invert the sense
+ of b (because it's negated), and get this list of <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html" guid="8.834380241450745E-306">Test
+ Ideas</a>:
+</p>
+<ul>
+ <li>
+ A true, B false
+ </li>
+ <li>
+ A true, B true
+ </li>
+ <li>
+ A false, B false
+ </li>
+</ul>
+<h3>
+ <a id="RelationalExpressions" name="RelationalExpressions"></a><b>Relational Expressions</b>
+</h3>
+<p align="left">
+ Here's another example of code with a fault:
+</p>
+<blockquote>
+<pre>
+if (finished < required) {
+ siren.sound();
+}
+</pre>
+</blockquote>
+<p align="left">
+ The <font size="+0"><</font> should be a <font size="+0"><=</font>. Such mistakes are fairly common. As with
+ boolean expressions, you can construct a table of test values and see which ones detect the fault:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ finished
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ required
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ code as written...
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ the correct code would have...
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ 1
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ sounds the siren
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ sounded the siren
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ <font color="#ff0000">does not sound the siren</font>
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ <font color="#ff0000">sounded the siren</font>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ 1
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ does not sound the siren
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ not sounded the siren
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ More generally, the fault can be detected whenever <font size="+0">finished=required</font>. From analyses of plausible
+ faults, we can get these rules for test ideas:
+</p>
+<p>
+ If the expression is A<B or A>=B, test with
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A=B
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A slightly less than B
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is A>B or A<=B, test with
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A=B
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A slightly larger than B
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ What does "slightly" mean? If A and B are integers, A should be one less than or larger than B. If they are floating
+ point numbers, A should be a number quite close to B. (It's probably not necessary that it be the the closest floating
+ point number to B.)
+</p>
+<h3>
+ <a id="CombinedExpressions" name="CombinedExpressions"></a><b>Rules for Combined Boolean and Relational Expressions</b>
+</h3>
+<p>
+ Most relational operators occur within boolean expressions, as in this example:
+</p>
+<blockquote>
+<pre>
+if (finished < required) {
+ siren.sound();
+}
+</pre>
+</blockquote>
+<p>
+ The rules for relational expressions would lead to these test ideas:
+</p>
+<ol>
+ <li>
+ <font size="+0">finished</font> is equal to required
+ </li>
+ <li>
+ <font size="+0">finished</font> is slightly less than <font size="+0">required</font>
+ </li>
+</ol>
+<p>
+ The rules for boolean expressions would lead to these:
+</p>
+<ol>
+ <li>
+ <font size="+0">finished < required</font> should be true
+ </li>
+ <li>
+ <font size="+0">finished < required</font> should be false
+ </li>
+</ol>
+<p>
+ But if <font size="+0">finished</font> is slightly less than <font size="+0">required</font>, <font size="+0">finished
+ < required</font> is true, so there's no point in writing down the latter.
+</p>
+<p>
+ And if <font size="+0">finished</font> equals <font size="+0">required</font>, <font size="+0">finished <
+ required</font> is false, so there's no point in writing down that latter one either.
+</p>
+<p>
+ So, <b>if a relational expression contains no boolean operators (<font size="+0">&&</font> and <font
+ size="+0">||</font>), ignore the fact that it's also a boolean expression.</b>
+</p>
+<p>
+ Things are a bit more complicated with combinations of boolean and relational operators, like this one:
+</p>
+<blockquote>
+<pre>
+if (count<5 || always) {
+ siren.sound();
+}
+</pre>
+</blockquote>
+<p>
+ From the relational expression, you get:
+</p>
+<ul>
+ <li>
+ <font size="+0">count</font> slightly less than 5
+ </li>
+ <li>
+ <font size="+0">count</font> equal to 5
+ </li>
+</ul>
+<p>
+ From the boolean expression, you get:
+</p>
+<ul>
+ <li>
+ <font size="+0">count<5</font> true, always false
+ </li>
+ <li>
+ <font size="+0">count<5</font> false, always true
+ </li>
+ <li>
+ <font size="+0">count<5</font> false, always false
+ </li>
+</ul>
+<p>
+ These can be combined into three more specific test ideas. (Here, note that <font size="+0">count</font> is an
+ integer.)
+</p>
+<ol>
+ <li>
+ <font size="+0">count=4</font>, always false
+ </li>
+ <li>
+ <font size="+0">count=5</font>, always true
+ </li>
+ <li>
+ <font size="+0">count=5</font>, always false
+ </li>
+</ol>
+<p>
+ Notice that <font size="+0">count=5</font> is used twice. It might seem better to use it only once, to allow the use of
+ some other value-after all, why test <font size="+0">count</font> with 5 twice? Wouldn't it be better to try it once
+ with 5 and another time with some other value such that <font size="+0">count<5</font> is false? It would be, but
+ it's dangerous to try. That's because it's easy to make a mistake. Suppose you tried the following:
+</p>
+<ol>
+ <li>
+ <font size="+0">count=4</font>, always false
+ </li>
+ <li>
+ <font size="+0">count=5</font>, always true
+ </li>
+ <li>
+ <font size="+0"><b>count<5</b></font> <b>false</b>, <font size="+0">always</font> false
+ </li>
+</ol>
+<p>
+ Suppose that there's a fault that can <i>only</i> be caught with <font size="+0">count=5</font>. What that means is
+ that the value 5 will cause <font size="+0">count<5</font> to produce false in the second test, when the correct
+ code would have produced true. However, that false value is immediately or'd with the value of always, which is true.
+ That means the value of the whole expression is correct, even though the value of the relational subexpression was
+ wrong. The fault will go undiscovered.
+</p>
+<p>
+ The fault doesn't go undiscovered if it's the <i>other</i> count=5 that is left less specific.
+</p>
+<p>
+ Similar problems happen when the relational expression is on the right-hand side of the boolean operator.
+</p>
+<p>
+ Because it's hard to know which subexpressions have to be exact and which can be general, it's best to make them all
+ exact. The alternative is to use the <a href="http://www.testing.com/tools/multi/README.html" target="_blank">boolean
+ expression program</a> mentioned above. It produces correct test ideas for arbitrary mixed boolean-and-relational
+ expressions.
+</p>
+<h3>
+ <a id="TestIdeasWithoutCode" name="TestIdeasWithoutCode"></a><b>Test ideas without Code</b>
+</h3>
+<p>
+ As explained in <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
+ guid="6.556259235358794E-306">Concept: Test-first Design</a>, it's usually preferable to design tests before
+ implementing code. So, although the techniques are motivated by code examples, they'll usually be applied without code.
+ How?
+</p>
+<p>
+ Certain design artifacts, such as statecharts and sequence diagrams, use boolean expressions as guards. Those cases are
+ straightforward-simply add the test ideas from the boolean expressions to the artifact's test idea checklist. See <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
+ guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Activity Diagrams</a>.
+</p>
+<p>
+ The trickier case is when boolean expressions are implicit rather than explicit. That's often the case in descriptions
+ of APIs. Here's an example. Consider this method:
+</p>
+<blockquote>
+<pre>
+List matchList(Directory d1, Directory d1,
+ FilenameFilter excluder);
+</pre>
+</blockquote>
+<p>
+ The description of this method's behavior might read like this:
+</p>
+<blockquote>
+ <p>
+ Returns a List of the absolute pathnames of all files that appear in both Directories. Subdirectories are
+ descended. [...] Filenames that match the <font size="+0">excluder</font> are excluded from the returned list. The
+ excluder only applies to the top-level directories, not to filenames in subdirectories.
+ </p>
+</blockquote>
+<p>
+ The words "and" and "or" do not appear. But when is a filename included in the return list? When it appears in the
+ first directory <b>and</b> it appears in the second directory <b>and</b> it's either in a lower level directory
+ <b>or</b> it's not specifically excluded. In code:
+</p>
+<blockquote>
+<pre>
+if (appearsInFirst && appearsInSecond &&
+ (inLowerLevel || !excluded)) {
+ add to list
+}
+</pre>
+</blockquote>
+<p>
+ Here are the test ideas for that expression, given in tabular form:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ appearsInFirst
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ appearsInSecond
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ inLower
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ excluded
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<p>
+ <br />
+ The general approach for discovering implicit boolean expressions from text is to first list the actions described
+ (such as "returns a matching name"). Then write a boolean expression that describes the cases in which an action is
+ taken. Derive test ideas from all the expressions.
+</p>
+<p>
+ There's room for disagreement in that process. For example, one person might write down the boolean expression used
+ above. Another might say that there are really two distinct actions: first, the program discovers matching names, then
+ it filters them out. So, instead of one expression, there are two:
+</p>
+<dl>
+ <dt>
+ discover a match:
+ </dt>
+ <dd>
+ happens when a file is in the first directory <b>and</b> a file with the same name is in the second directory
+ </dd>
+ <dt>
+ filter a match:
+ </dt>
+ <dd>
+ happens when the matching files are in the top level <b>and</b> the name matches the <font
+ size="+0">excluder</font>
+ </dd>
+</dl>
+<p>
+ These different approaches can lead to different test ideas and thus different tests. But the differences are most
+ likely not particularly important. That is, the time spent worrying about which expression is right, and trying
+ alternatives, would be better spent on other techniques and producing more tests. If you're curious about what the
+ sorts of differences might be, read on.
+</p>
+<p>
+ The second person would get two sets of test ideas.
+</p>
+<blockquote>
+ <p>
+ test ideas about discovering a match:
+ </p>
+ <ul>
+ <li>
+ file in first directory, file in second directory (true, true)
+ </li>
+ <li>
+ file in first directory, file not in second directory (true, false)
+ </li>
+ <li>
+ file not in first directory, file in second directory (false, true)
+ </li>
+ </ul>
+ <p>
+ test ideas about filtering a match (once one has been discovered):
+ </p>
+ <ul>
+ <li>
+ matching files are in the top level, the name matches the <font size="+0">excluder</font> (true, true)
+ </li>
+ <li>
+ matching files are in the top level, the name doesn't match the <font size="+0">excluder</font> (true, false)
+ </li>
+ <li>
+ matching files are in some lower level, the name matches the <font size="+0">excluder</font> (false, true)
+ </li>
+ </ul>
+</blockquote>
+<p>
+ Suppose those two sets of test ideas are combined. The ones in the second set only matter when the file is in both
+ directories, so they can only be combined with the first idea in the first set. That gives us the following:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in first directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in second directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ in top level
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ matches excluder
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ Two of the test ideas about discovering a match do not appear in that table. We can add them like this:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in first directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in second directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ in top level
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ matches excluder
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The blank cells indicate that the columns are irrelevant.
+</p>
+<p>
+ This table now looks rather similar to the first person's table. The similarity can be emphasized by using the same
+ terminology. The first person's table has a column called "inLower", and the second person's has one called "in top
+ level". They can be converted by flipping the sense of the values. Doing that, we get this version of the second table:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th width="25%">
+ <p align="center">
+ appearsInFirst
+ </p>
+ </th>
+ <th width="25%">
+ <p align="center">
+ appearsInSecond
+ </p>
+ </th>
+ <th width="25%">
+ <p align="center">
+ inLower
+ </p>
+ </th>
+ <th width="25%">
+ <p align="center">
+ excluded
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The first three rows are identical to the first person's table. The last two differ only in that this version doesn't
+ specify values that the first does. This amounts to an assumption about the way the code was written. The first assumed
+ a complicated boolean expression:
+</p>
+<blockquote>
+<pre>
+if (appearsInFirst && appearsInSecond &&
+ (inLowerLevel || !excluded)) {
+ add to list
+}
+</pre>
+</blockquote>
+<p>
+ The second assumes nested boolean expressions:
+</p>
+<blockquote>
+<pre>
+if (appearsInFirst && appearsInSecond) {
+ // found match.
+ if (inTopLevel && excluded) {
+// filter it
+ }
+}
+</pre>
+</blockquote>
+<p>
+ The difference between the two is that the test ideas for the first detect two faults that the ideas for the second do
+ not, because those faults don't apply.
+</p>
+<ol>
+ <li>
+ In the first implementation, there can be a misparenthesization fault. Are the parentheses around the <font
+ size="+0">||</font> correct or incorrect? Since the second implementation has no <font size="+0">||</font> and no
+ parentheses, the fault cannot exist.
+ </li>
+ <li>
+ The test requirements for the first implementation check whether the second <font size="+0">&&</font>
+ should be an <font size="+0">||</font>. In the second implementation, that explicit <font
+ size="+0">&&</font> is replaced by the implicit <font size="+0">&&</font> of the nested <font
+ size="+0">if</font> statements. There's no <font size="+0">||</font>-for-<font size="+0">&&</font> fault,
+ per se. (It might be the case that the nesting is incorrect, but this technique does not address that.)<br />
+ </li>
+</ol><!-- END:mainDescription,-FX8hDYUKOXsrQulFe9lwtw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_method_calls.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_method_calls.html
new file mode 100644
index 0000000..322322f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_method_calls.html
@@ -0,0 +1,603 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\test_ideas_for_method_calls.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_ideas_for_method_calls.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,8.5657170364036E-306 CRC: 4107841560 -->Test Ideas for Method Calls<!-- END:presentationName,8.5657170364036E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-nwZMQTZtIwI5weh9c_HoYA CRC: 1767159060 --><a id="XE_test__developer_testing__test_ideas__for_method_calls"
+name="XE_test__developer_testing__test_ideas__for_method_calls"></a><a
+id="XE_design__developer_testing__test_ideas__for_method_calls"
+name="XE_design__developer_testing__test_ideas__for_method_calls"></a><a id="XE_test-ideas__for_method_calls"
+name="XE_test-ideas__for_method_calls"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Here's an example of defective code:
+</p>
+<blockquote>
+<pre>
+File file = new File(stringName);
+file.delete();
+</pre>
+</blockquote>
+<p>
+ The defect is that <font size="+0">File.delete</font> can fail, but the code doesn't check for that. Fixing it requires
+ the addition of the italicized code shown here:
+</p>
+<blockquote>
+<pre>
+File file = new File(stringName);
+<font color="#ff0000"><i><b>if (</b></i></font>file.delete()<font color="#ff0000"><i><b>== false) {...}</b></i></font>
+</pre>
+</blockquote>
+<p>
+ This guideline describes a method for detecting cases where your code does not handle the result of calling a method.
+ (Note that it assumes that the method called produces the correct result for whatever inputs you give it. That's
+ something that should be tested, but creating test ideas for the called method is a separate activity. That is, it's
+ not your job to test <font size="+0">File.delete</font>.)
+</p>
+<p>
+ The key notion is that you should create a test idea for each <i>distinct unhandled relevant result</i> of a method
+ call. To define that term, let's first look at <i>result</i>. When a method executes, it changes the state of the
+ world. Here are some examples:
+</p>
+<ul>
+ <li>
+ It might push return values on the runtime stack.
+ </li>
+ <li>
+ It might throw an exception.
+ </li>
+ <li>
+ It might change a global variable.
+ </li>
+ <li>
+ It might update a record in a database.
+ </li>
+ <li>
+ It might send data over the network.
+ </li>
+ <li>
+ It might print a message to standard output.
+ </li>
+</ul>
+<p>
+ Now let's look at <i>relevant</i>, again using some examples.
+</p>
+<ul>
+ <li>
+ Suppose the method being called prints a message to standard output. That "changes the state of the world", but it
+ cannot affect the further processing of this program. No matter what gets printed, even nothing at all, it can't
+ affect the execution of your code.
+ </li>
+ <li>
+ If the method returns true for success and false for failure, your program very likely should branch based on the
+ result. So that return value is relevant.
+ </li>
+ <li>
+ If the called method updates a database record that your code later reads and uses, the result (updating the
+ record) is relevant.
+ </li>
+</ul>
+<p>
+ (There's no absolute line between relevant and irrelevant. By calling <font size="+0">print</font>, your method might
+ cause buffers to be allocated, and that allocation might be relevant after <font size="+0">print</font> returns. It's
+ conceivable that a defect might depend on whether and what buffers were allocated. It's conceivable, but is it at all
+ plausible?)
+</p>
+<p>
+ A method might often have a very large number of results, but only some of them will be <i>distinct</i>. For example,
+ consider a method that writes bytes to disk. It might return a number less than zero to indicate failure; otherwise, it
+ returns the number of bytes written (which might be fewer than the number requested). The large number of possibilities
+ can be grouped into three distinct results:
+</p>
+<ul>
+ <li>
+ a number less than zero.
+ </li>
+ <li>
+ the number written equals the number requested
+ </li>
+ <li>
+ some bytes were written, but less than the number requested.
+ </li>
+</ul>
+<p>
+ All the values less than zero are grouped into one result because no reasonable program will make a distinction among
+ them. All of them (if, indeed, more than one is possible) should be treated as an error. Similarly, if the code
+ requested that 500 bytes be written, it doesn't matter if 34 were actually written or 340: the same thing will probably
+ be done with the unwritten bytes. (If something different should be done for some value, such as 0, that will form a
+ new distinct result.)
+</p>
+<p>
+ There's one last word in the defining term to explain. This particular testing technique is not concerned with distinct
+ results that are already <i>handled</i>. Consider, again, this code:
+</p>
+<blockquote>
+<pre>
+File file = new File(stringName);
+if (file.delete() == false) {...}
+</pre>
+</blockquote>
+<p>
+ There are two distinct results (true and false). The code handles them. It might handle them incorrectly, but test
+ ideas from <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
+ guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a> will check that. This test
+ technique is concerned with distinct results that are not specifically handled by distinct code. That might happen for
+ two reasons: you thought the distinction was irrelevant, or you simply overlooked it. Here's an example of the first
+ case:
+</p>
+<blockquote>
+<pre>
+result = m.method();
+switch (result) {
+ case FAIL:
+ case CRASH:
+ ...
+ break;
+ case DEFER:
+ ...
+ break;
+ default:
+ ...
+ break;
+}
+</pre>
+</blockquote>
+<p>
+ <font size="+0">FAIL</font> and <font size="+0">CRASH</font> are handled by the same code. It might be wise to check
+ that that's really appropriate. Here's an example of an overlooked distinction:
+</p>
+<blockquote>
+<pre>
+result = s.shutdown();
+if (result == PANIC) {
+ ...
+} else {
+ // success! Shut down the reactor.
+ ...
+}
+</pre>
+</blockquote>
+<p>
+ It turns out that shutdown can return an additional distinct result: <font size="+0">RETRY</font>. The code as written
+ treats that case the same as the success case, which is almost certainly wrong.
+</p>
+<h3>
+ <a id="FindingTestIdeas" name="FindingTestIdeas">Finding test ideas</a>
+</h3>
+<p>
+ So your goal is to think of those distinct relevant results you previously overlooked. That seems impossible: why would
+ you realize they're relevant now if you didn't earlier?
+</p>
+<p>
+ The answer is that a systematic re-examination of your code, when in a testing frame of mind and not a programming
+ frame of mind, can sometimes cause you to think new thoughts. You <i>can</i> question your own assumptions by
+ methodically stepping through your code, looking at the methods you call, rechecking their documentation, and thinking.
+ Here are some cases to watch for.
+</p>
+<h4>
+ "Impossible" cases
+</h4>
+<p>
+ Often, it will appear that error returns are impossible. Doublecheck your assumptions.
+</p>
+<p>
+ This example shows a Java implementation of a common Unix idiom for handling temporary files.
+</p>
+<blockquote>
+<pre>
+File file = new File("tempfile");
+FileOutputStream s;
+try {
+ // open the temp file.
+ s = new FileOutputStream(file);
+} catch (IOException e) {...}
+// Make sure temp file will be deleted
+file.delete();
+</pre>
+</blockquote>
+<p>
+ The goal is to make sure that a temporary file is always deleted, no matter how the program exits. You do this by
+ creating the temporary file, then immediately deleting it. On Unix, you can continue to work with the deleted file, and
+ the operating system takes care of cleaning up when the process exits. A not-painstaking Unix programmer might not
+ write the code to check for a failed deletion. Since she just successfully created the file, she must be able to delete
+ it.
+</p>
+<p>
+ This trick doesn't work on Windows. The deletion will fail because the file is open. Discovering that fact is hard: as
+ of August 2000, the Java documentation did not enumerate the situations in which <font size="+0">delete</font> could
+ fail; it merely says that it can. But-perhaps-when in "testing mode", the programmer might question her assumption.
+ Since her code is supposed to be "write once, run everywhere", she might ask a Windows programmer when <font
+ size="+0">File.delete</font> fails on Windows and so discover the awful truth.
+</p>
+<h4>
+ "Irrelevant" cases
+</h4>
+<p>
+ Another force against noticing a distinct relevant value is being already convinced that it doesn't matter. A Java
+ <font size="+0">Comparator</font>'s <font size="+0">compare</font> method returns either a number <0, 0, or a number
+ >0. Those are three distinct cases that might be tried. This code lumps two of them together:
+</p>
+<blockquote>
+<pre>
+void allCheck(Comparator c) {
+ ...
+ if (c.compare(o1, o2) <= 0) {
+ ...
+ } else {
+ ...
+ }
+</pre>
+</blockquote>
+<p>
+ But that might be wrong. The way to discover whether it is or not is to try the two cases separately, even if you
+ really believe it will make no difference. (Your beliefs are really what you're testing.) Note that you might be
+ executing the <font size="+0">then</font> case of the <font size="+0">if</font> statement more than once for other
+ reasons. Why not try one of them with the result less than 0 and one with the result exactly equal to zero?
+</p>
+<h4>
+ Uncaught exceptions
+</h4>
+<p>
+ Exceptions are a kind of distinct result. By way of background, consider this code:
+</p>
+<blockquote>
+<pre>
+void process(Reader r) {
+ ...
+ try {
+ ...
+ int c = r.read();
+ ...
+ } catch (IOException e) {
+ ...
+ }
+}
+</pre>
+</blockquote>
+<p>
+ You'd expect to check whether the handler code really does the right thing with a read failure. But suppose an
+ exception is explicitly unhandled. Instead, it's allowed to propagate upward through the code under test. In Java, that
+ might look like this:
+</p>
+<blockquote>
+<pre>
+void process(Reader r) <font color="#ff0000"><i><b>throws IOException</b></i></font> {
+ ...
+ int c = r.read();
+ ...
+}
+</pre>
+</blockquote>
+<p>
+ This technique asks you to test that case <i>even though</i> the code explicitly doesn't handle it. Why? Because of
+ this kind of fault:
+</p>
+<blockquote>
+<pre>
+void process(Reader r) throws IOException {
+ ...
+ <font color="#ff0000"><i><b>Tracker.hold(this);</b></i></font>
+ ...
+ int c = r.read();
+ ...
+ <font color="#ff0000"><i><b>Tracker.release(this);</b></i></font>
+ ...
+}
+</pre>
+</blockquote>
+<p>
+ Here, the code affects global state (through <font size="+0">Tracker.hold</font>). If the exception is thrown, <font
+ size="+0">Tracker.release</font> will never be called.
+</p>
+<p>
+ (Notice that the failure to release will probably have no obvious immediate consequences. The problem will most likely
+ not be visible until <font size="+0">process</font> is called again, whereupon the attempt to <font
+ size="+0">hold</font> the object for a second time will fail. A good article about such defects is Keith Stobie's <a
+ href="http://www.testingcraft.com/stobie-exceptions.pdf" target="_blank">"Testing for Exceptions"</a>. (<a
+ href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Get Adobe Reader</a>))
+</p>
+<h3>
+ <a id="UndiscoveredFaults" name="UndiscoveredFaults">Undiscovered faults</a>
+</h3>
+<p>
+ This particular technique does not address all defects associated with method calls. Here are two kinds that it's
+ unlikely to catch.
+</p>
+<h4>
+ Incorrect arguments
+</h4>
+<p>
+ Consider these two lines of C code, where the first line is wrong and the second line is correct.
+</p>
+<blockquote>
+<pre>
+... strncmp(s1, s2, strlen(s1)) ...
+... strncmp(s1, s2, strlen(<font color="#ff0000"><i><b>s2</b></i></font>)) ...
+</pre>
+</blockquote>
+<p>
+ <font size="+0">strncmp</font> compares two strings and returns a number less than 0 if the first one is
+ lexicographically less than the second (would come earlier in a dictionary), 0 if they're equal, and a number greater
+ than 0 if the first one is lexicographically larger. However, it only compares the number of characters given by the
+ third argument. The problem is that the length of the first string is used to limit the comparison, whereas it should
+ be the length of the second.
+</p>
+<p>
+ This technique would require three tests, one for each distinct return value. Here are three you could use:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ s1
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ s2
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ expected result
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ actual result
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "a"
+ </td>
+ <td align="middle" width="25%">
+ "bbb"
+ </td>
+ <td align="middle" width="25%">
+ <0
+ </td>
+ <td align="middle" width="25%">
+ <0
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "bbb"
+ </td>
+ <td align="middle" width="25%">
+ "a"
+ </td>
+ <td align="middle" width="25%">
+ >0
+ </td>
+ <td align="middle" width="25%">
+ >0
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "foo"
+ </td>
+ <td align="middle" width="25%">
+ "foo"
+ </td>
+ <td align="middle" width="25%">
+ =0
+ </td>
+ <td align="middle" width="25%">
+ =0
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The defect is not discovered because nothing in this technique <i>forces</i> the third argument to have any particular
+ value. What's needed is a test case like this:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>s1</b>
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>s2</b>
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>expected result</b>
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>actual result</b>
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "foo"
+ </td>
+ <td align="middle" width="25%">
+ "foo<font color="#ff0000"><i><b>d</b></i></font>"
+ </td>
+ <td align="middle" width="25%">
+ <font color="#ff0000"><i><b><0</b></i></font>
+ </td>
+ <td align="middle" width="25%">
+ =0
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ While there are techniques suitable for catching such defects, they are seldom used in practice. Your testing effort is
+ probably better spent on a rich set of tests that targets many types of defects (and that you hope catches this type as
+ a side effect).
+</p>
+<h4>
+ Indistinct results
+</h4>
+<p>
+ There's a danger that comes when you're coding - and testing - method-by-method. Here's an example. There are two
+ methods. The first, <font size="+0">connect</font>, wants to establish a network connection:
+</p>
+<blockquote>
+<pre>
+void connect() {
+ ...
+ Integer portNumber = serverPortFromUser();
+ if (portNumber == null) {
+ // pop up message about invalid port number
+ return;
+ }
+</pre>
+</blockquote>
+<p>
+ It calls <font size="+0">serverPortFromUser</font> to get a port number. That method returns two distinct values. It
+ returns a port number chosen by the user if the number chosen is valid (1000 or greater). Otherwise, it returns null.
+ If null is returned, the code under test pops up an error message and quits.
+</p>
+<p>
+ When <font size="+0">connect</font> was tested, it worked as intended: a valid port number caused a connection to be
+ established, and an invalid one led to a popup.
+</p>
+<p>
+ The code to <font size="+0">serverPortFromUser</font> is a bit more complicated. It first pops up a window that asks
+ for a string and has the standard OK and CANCEL buttons. Based on what the user does, there are four cases:
+</p>
+<ol>
+ <li>
+ If the user types a valid number, that number is returned.
+ </li>
+ <li>
+ If the number is too small (less than 1000), null is returned (so the message about invalid port number will be
+ displayed).
+ </li>
+ <li>
+ If the number is misformatted, null is again returned (and the same message is appropriate).
+ </li>
+ <li>
+ If the user clicks CANCEL, null is returned.
+ </li>
+</ol>
+<p>
+ This code also works as intended.
+</p>
+<p>
+ The combination of the two chunks of code, though, has a bad consequence: the user presses CANCEL and gets a message
+ about an invalid port number. All the code works as intended, but the overall effect is still wrong. It was tested in a
+ reasonable way, but a defect was missed.
+</p>
+<p>
+ The problem here is that <font size="+0">null</font> is one result that represents two distinct <i>meanings</i> ("bad
+ value" and "user cancelled"). Nothing in this technique forces you to notice that problem with the design of <font
+ size="+0">serverPortFromUser</font>.
+</p>
+<p>
+ Testing can help, though. When <font size="+0">serverPortFromUser</font> is tested in isolation - just to see if it
+ returns the intended value in each of those four cases - the context of use is lost. Instead, suppose it were tested
+ via <font size="+0">connect</font>. There would be four tests that would exercise both of the methods simultaneously:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ input
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ expected result
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ thought process
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ user types "1000"
+ </td>
+ <td align="middle" width="25%">
+ connection to port 1000 is opened
+ </td>
+ <td align="middle" width="25%">
+ <font size="+0">serverPortFromUser</font> returns a number, which is used.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ user types "999"
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ popup about invalid port number
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ <font size="+0">serverPortFromUser</font> returns null, which leads to popup
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ <p align="center">
+ user types "i99"
+ </p>
+ </td>
+ <td align="middle" width="25%">
+ popup about invalid port number
+ </td>
+ <td align="middle" width="25%">
+ <font size="+0">serverPortFromUser</font> returns null, which leads to popup
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ users clicks CANCEL
+ </td>
+ <td align="middle" width="25%">
+ whole connection process should be cancelled
+ </td>
+ <td align="middle" width="25%">
+ <font size="+0"><i>serverPortFromUser</i></font> <i>returns null, hey wait a minute that doesn't make
+ sense...</i>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ As is often the case, testing in a larger context reveals integration problems that escape small-scale testing. And, as
+ is also often the case, careful thought during test design reveals the problem before the test is run. (But if the
+ defect isn't caught then, it will be caught when the test is run.)<br />
+ <br />
+</p><!-- END:mainDescription,-nwZMQTZtIwI5weh9c_HoYA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.html
new file mode 100644
index 0000000..d0ae713
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.html
@@ -0,0 +1,271 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\test_ideas_for_statechart_and_flow_diagrams.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: test_ideas_for_statechart_and_flow_diagrams.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.0347051690476123E-305 CRC: 2212386246 -->Test Ideas for Statechart and Flow Diagrams<!-- END:presentationName,1.0347051690476123E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-60dp5lxFJEpUarhchGCnHw CRC: 25121526 --><a id="XE_state_machine__test_ideas_for" name="XE_state_machine__test_ideas_for"></a><a
+id="XE_test_idea__for_state_machine" name="XE_test_idea__for_state_machine"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ This guideline shows how to identify <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestIdeas"
+ guid="8.834380241450745E-306">test ideas</a> from statecharts and other design structures that consist mainly of nodes
+ connected by arcs and that show something of the possible control flows of a program. The main goal of this testing is
+ to traverse every arc in some test. If you've never exercised an arc, why do you think it will work when a customer
+ does?
+</p>
+<h3>
+ <a id="Implementation" name="Implementation">Testing the Implementation</a>
+</h3>
+<p>
+ Consider this statechart:
+</p>
+<p align="center">
+ <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
+</p>
+<p class="picturetext">
+ Fig1: HVAC Statechart
+</p>
+<p>
+ Here's a first list of test ideas:
+</p>
+<ul>
+ <li>
+ Idle state receives Too Hot event
+ </li>
+ <li>
+ Idle state receives Too Cool event
+ </li>
+ <li>
+ Cooling/Startup state receives Compressor Running event
+ </li>
+ <li>
+ Cooling/Ready state receives Fan Running event
+ </li>
+ <li>
+ Cooling/Running state receives OK event
+ </li>
+ <li>
+ Cooling/Running state receives Failure event
+ </li>
+ <li>
+ Failure state receives Failure Cleared event
+ </li>
+ <li>
+ Heating state receives OK event
+ </li>
+ <li>
+ Heating state receives Failure event
+ </li>
+</ul>
+<p>
+ These test ideas could all be exercised in a single test, or you could create several tests that each exercise a few.
+ As with all test design, strive for a balance between the ease of implementation of many simple tests and the
+ additional defect-finding power of complex tests. (See <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestDesignUsingTheList"
+ guid="8.834380241450745E-306">"test design using the list"</a> in the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html"
+ guid="8.834380241450745E-306">Concept: Test Ideas List</a> page.) If you have use case scenarios that describe certain
+ paths through the statechart, you should favor tests that take those paths.
+</p>
+<p>
+ In any case, the tests should check that all actions required by the statechart actually take place. For example, is
+ the alarm started on entry to the Failure state, then stopped upon exit?
+</p>
+<p>
+ The test should also check that the transition leads to the correct next state. That can be a difficult problem when
+ the states are invisible from the outside. The only way to detect an incorrect state is to inject some sequence of
+ events that leads to incorrect output. More precisely, you would need to construct a follow-on sequence of events whose
+ externally-visible results for the <i>correct</i> state differ from those that the same sequence would provoke from
+ each possible <i>incorrect</i> state.
+</p>
+<p>
+ In the example above, how would you know that the Failure Cleared event in the Failure state correctly led to the Idle
+ state, instead of staying in the Failure state? You might trust that the stopping of the Alarm meant that transition
+ had been made, but it might be better to check by lowering the temperature enough to make the heater start or raising
+ it enough to turn on cooling. If something happens, you're more confident that the transition was correct. If nothing
+ happens, it's likely the device stayed in the Failure state.
+</p>
+<p>
+ At the very least, determining whether the resulting state is correct complicates test design. It is often better to
+ make the state machine explicit and make its states visible to the tests.
+</p>
+<h4>
+ Other statechart constructs
+</h4>
+<p>
+ Statecharts consist of more than arcs and arrows. Here is a list of statechart constructs and the effect they have on
+ the test idea list.
+</p>
+<h5>
+ Event actions, entry actions, and exit actions
+</h5>
+<p>
+ These do not generate test ideas per se. Rather, the tests should check that the actions behave as specified. If the
+ actions represent substantial programs, those programs must be tested. The test ideas for the programs might be
+ combined with test ideas from the statechart, but it's probably more manageable to separate them. Make the decision
+ based on the effort involved and on your suspicion that there might be interactions between events. That is, if a
+ particular action on one arc cannot possibly share data with an action on another arc, there is no reason to exercise
+ the two actions in the same test (as you would if they were part of the same path through a statechart test).
+</p>
+<h5>
+ Guard conditions
+</h5>
+<p>
+ Guard conditions are boolean expressions. The test ideas for guard conditions are derived as described in <a
+ class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
+ guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a>.
+</p>
+<p>
+ In the example above, the Too Cool transition from the Idle state is guarded with [restart time >= 5 mins]. That
+ leads to two separate test ideas:
+</p>
+<ul>
+ <li>
+ Idle state receives Too Cool event when restart time is five minutes (transition taken)
+ </li>
+ <li>
+ Idle state receives Too Cool event when restart time is just less than five minutes (transition blocked)
+ </li>
+</ul>
+<p>
+ In both cases, any test that uses the test idea should check that the correct state is reached.
+</p>
+<h5>
+ Internal transitions
+</h5>
+<p>
+ An internal transition adds the same sort of ideas to a test idea list as an external transition does. It's merely that
+ the next state is the same as the original state. It would be prudent to set up the test such that the state's entry
+ and exit actions would cause an observable effect if they were incorrectly triggered.
+</p>
+<h5>
+ Nested states
+</h5>
+<p>
+ When constructing tests, set them up such that entry and exit events of the composite state have observable effects.
+ You want to notice if they're skipped.
+</p>
+<h5>
+ Concurrent substates
+</h5>
+<p>
+ Testing of concurrency falls outside of the scope of developer testing.
+</p>
+<h5>
+ Deferred events
+</h5>
+<p>
+ If you suspect an event might be handled differently depending on whether it was deferred and queued rather than
+ generated while the program was actually in the receiving state, you might test those two cases.
+</p>
+<p>
+ If the event in the receiving state has a guard condition, consider the ramifications of changes to the condition's
+ variables between the time the event is generated and the time it is received.
+</p>
+<p>
+ If more than one state can handle a deferred event, consider testing deferral to each of the possible receiving states.
+ Perhaps the implementation assumes that the "obvious" state will handle the event.
+</p>
+<h5>
+ History states
+</h5>
+<p>
+ Here is an example of a history state:
+</p>
+<p align="center">
+ <img height="211" alt="" src="resources/md_state3.gif" width="412" />
+</p>
+<p class="picturetext">
+ Fig2: History State Example
+</p>
+<p>
+ The transition into the history state represents three real transitions, and thus three test ideas:
+</p>
+<ul>
+ <li>
+ BackupUp event in Command state leads to Collecting state
+ </li>
+ <li>
+ BackupUp event in Command state leads to Copying state
+ </li>
+ <li>
+ BackupUp event in Command state leads to CleaningUp state
+ </li>
+</ul>
+<h5>
+ Chain states
+</h5>
+<p>
+ Chain states do not seem to have any implications for test design, except that they introduce more actions that need to
+ be checked.
+</p>
+<h3>
+ <a id="Design" name="Design">Testing the Design</a>
+</h3>
+<p>
+ The preceding discussion focuses on checking whether the implementation matches the design. But the design might also
+ be wrong. While examining the design to find test ideas, also check for two types of problems:
+</p>
+<p>
+ <b>Missing events.</b> The statechart shows a state's response to events <i>that the designer anticipated could arrive
+ in that state</i>. It's not unknown for designers to overlook events. For example, in this statechart (repeated from
+ the top of the page), perhaps the designer forgot that a failure can occur in the Ready substate of Cooling, not just
+ when the fan is Running.
+</p>
+<p align="center">
+ <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
+</p>
+<p class="picturetext">
+ Fig3: HVAC Statechart
+</p>
+<p>
+ For this reason, it's wise to ask, for each state, whether any of the events that apply to other states might apply to
+ this one. If you discover that one does, correct your design.
+</p>
+<p>
+ <b>Incomplete or missing guard conditions.</b> Similarly, perhaps guard conditions on one transition will suggest guard
+ conditions on others. For example, the above statechart takes care not to restart the heater too often, but there is no
+ such restriction on the cooling system. Should there be?
+</p>
+<p>
+ It is also possible that variables used on one guard condition will suggest that other guard conditions are too simple.
+</p>
+<h3>
+ <a id="Interactions" name="Interactions">Testing Interactions</a>
+</h3>
+<p>
+ Testing each arc in a graph is by no means complete testing. For example, suppose the start state initializes a
+ variable to 0, state Setter sets it to 5, and state Divider divides it into 100 (100/variable). If there's a path from
+ the start state to Divider that does not pass through Setter, you have a divide-by-zero exception. If the statechart
+ has many states, simply exercising each arc might miss that path.
+</p>
+<p>
+ Except for very simple statecharts, testing every path is infeasible. In practice, tests that are complex and
+ correspond to use case scenarios are often sufficient. If you desire stronger tests, consider requiring a path from
+ each state where a datum is given a value to each state that uses it.
+</p>
+<br />
+<br /><!-- END:mainDescription,-60dp5lxFJEpUarhchGCnHw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/xp_environment.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/xp_environment.html
new file mode 100644
index 0000000..a1d37a4
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/guidelines/xp_environment.html
@@ -0,0 +1,135 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\guidelines\xp_environment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_environment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,3.754748120034442E-307 CRC: 2138022140 -->XP Environment<!-- END:presentationName,3.754748120034442E-307 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-OuWRQbxXBGWox8SgcCr6sQ CRC: 4012676934 --><a id="XE_xp__environment" name="XE_xp__environment"></a><a id="XE_environment__in_xp" name="XE_environment__in_xp"></a>
+<p>
+ No process is an island. In other words, you can't expect to just take a process or process elements off a shelf and
+ use them without regard to their context.
+</p>
+<p>
+ XP has certain key requirements of the "environment"; the physical, organizational, and business setting where it will
+ be applied.
+</p>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#Physical">Physical Requirements</a>
+ <ul>
+ <li>
+ <a href="#OpenWorkspace">Open Workspace</a>
+ </li>
+ <li>
+ <a href="#Toolset">Uniform Toolset</a>
+ </li>
+ <li>
+ <a href="#BuildMachine">Dedicated Build Machine</a>
+ </li>
+ <li>
+ <a href="#VersionControl">Version Control Tool</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="#Org">Organizational Requirements</a>
+ </li>
+ <li>
+ <a href="#Business">Business Requirements</a>
+ </li>
+</ul>
+<h3>
+ <a id="Physical" name="Physical">Physical Requirements</a>
+</h3>
+<h4>
+ <a id="OpenWorkspace" name="OpenWorkspace">Open Workspace</a>
+</h4>
+<p>
+ One key aspect of XP is a strong focus on communication. To communicate effectively, a team should have as few physical
+ barriers to each other as possible. The ideal XP programming environment is an open workspace filled with tables and
+ room for pairs of people to work together and maintain contact with their peers. For more details, see the <a
+ class="elementLinkWithUserText" href="./../../../myxp/guidances/guidelines/open_workspace,3.269440809144354E-305.html"
+ guid="3.269440809144354E-305">open workspace guideline</a>.
+</p>
+<h4>
+ <a id="Toolset" name="Toolset">Uniform Toolset</a>
+</h4>
+<p>
+ XP works best when there are no artificial impediments to getting and giving help. If you have an open workspace with
+ five computers for production coding and each of them has a wildly different set of tools, some people will gravitate
+ to the machines that have the tools they like and feel uncomfortable moving to the machines that have unfamiliar tools.
+ Think about your own experiences. Do you feel hindered working in an unfamiliar IDE? How much does that impede you when
+ someone asks for your help. If, as a team, you adopt a uniform set of tools and keep your development machines
+ homogenous, you are making it far easier for people to give and receive help.
+</p>
+<h4>
+ <a id="BuildMachine" name="BuildMachine">Dedicated Build Machine</a>
+</h4>
+<p>
+ In XP, there are many different ways to do builds. However, the primary constraint is that all unit tests are run prior
+ to checking in any production code. In most situations, the easiest way to accomplish this is to have a dedicated build
+ machine. You can check in your code and trigger a build across the network or walk to the build machine and run the
+ build. Either way, having a dedicated machine gives you the advantage of having a common, pristine environment for your
+ builds.
+</p>
+<h4>
+ <a id="VersionControl" name="VersionControl">Version Control Tool</a>
+</h4>
+<p>
+ All software projects need version control tools; however, in XP we place a premium upon their usability. The ability
+ to be able to check out code without locking it is also valued. When a team writes pervasive unit tests and practices
+ collective code ownership, locking code for revision is often too pessimistic. It creates unncessary bottlenecks.
+</p>
+<h3>
+ <a id="Org" name="Org">Organizational Requirements</a>
+</h3>
+<p>
+ Organizations adopting XP should be able to dedicate someone to act as the customer for each XP team. The customer role
+ in XP is critical. If the person who is acting as the customer has other responsibilities, it is best if those
+ responsibilities are subordinate to being available to the rest of the team.
+</p>
+<p>
+ In addition to having an available customer, organizations practicing XP should allow teams to be self-sufficient. In
+ organizations where many functions are supported by different groups (configuration management group, deployment group,
+ QA), the different functions can impede development if there are not mechanisms to allow each team to do what it takes
+ to finalize its iterations without waiting for other teams.
+</p>
+<h3>
+ <a id="Business" name="Business">Business Requirements</a>
+</h3>
+<p>
+ XP works best in situations where organizations can take advantage of variable scope. If a business creates a fixed
+ scope contract with a fixed end date, it can be hard to discern how long it really takes for a team to sustainably
+ develop good software.
+</p>
+<p>
+ People in the organizations look at the schedule rather than the velocity data that XP produces. The result is all too
+ predictable. Software may be delivered on time, but it may also be buggy and a poor platform for future development. In
+ XP, we recognize that each team has a particular speed at which they can reliably develop software. That speed varies
+ from team to team. If a team is pushed faster than that speed, the results are often disasterous.
+</p>
+<p>
+ <br />
+ <br />
+</p><!-- END:mainDescription,-OuWRQbxXBGWox8SgcCr6sQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/practices/sustainable_pace.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/practices/sustainable_pace.html
new file mode 100644
index 0000000..2fa5737
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/practices/sustainable_pace.html
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\practices\sustainable_pace.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: sustainable_pace.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_ycm9gGZBEdqvwYzpSSc2Nw CRC: 2128267562 -->Sustainable Pace<!-- END:presentationName,_ycm9gGZBEdqvwYzpSSc2Nw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-AS84xtg2NOXfrqA6eVRzMQ CRC: 384802270 --><h3>
+ Description
+</h3>
+<p>
+ The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
+ marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
+ overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
+ impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
+ causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
+ down.
+</p>
+<p>
+ Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
+ to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
+ it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
+ iteration or a release, but it should always be an exception rather than the rule.
+</p>
+<p>
+ Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Improved predictability</b>: plans become more accurate.
+ </li>
+ <li>
+ <b>Improved product quality</b>: programmers have the time to do the right thing.
+ </li>
+ <li>
+ <b>Improved job satisfaction</b>: programmers can enjoy their work with as little stress as possible.
+ </li>
+ <li>
+ <b>Reduced time to market</b>: less time required to fix bad code and rotting design.
+ </li>
+</ul><!-- END:mainDescription,-AS84xtg2NOXfrqA6eVRzMQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/getting_started_with_xp.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/getting_started_with_xp.html
new file mode 100644
index 0000000..bbf6bf7
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/getting_started_with_xp.html
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\getting_started_with_xp.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: getting_started_with_xp.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.2284921351651456E-304 CRC: 2680077187 -->Getting Started with XP<!-- END:presentationName,1.2284921351651456E-304 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-PCk5_o83KYiPZaKUzt021A CRC: 1925316507 --><a id="XE_xp__getting started_with" name="XE_xp__getting started_with"></a><a id="XE_getting started__with_xp"
+name="XE_getting started__with_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatisXP">What is XP?</a>
+ </li>
+ <li>
+ <a href="#Start">Where do I start?</a>
+ </li>
+ <li>
+ <a href="#Providing">Providing Feedback</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatisXP" name="WhatisXP">What is XP?</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. XP is currently one of the
+ most widely used agile processes in the industry.
+</p>
+<h3>
+ <a id="Start" name="Start">Where do I start?</a>
+</h3>
+<p>
+ If you are unfamiliar with XP and want to learn more about it, we suggest you take the following steps:
+</p>
+<ul>
+ <li>
+ Get a quick <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html"
+ guid="9.251272550276345E-306">overview of XP</a>.
+ </li>
+ <li>
+ Learn what the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
+ guid="1.6390805262958034E-306">motivation behind XP</a> is.
+ </li>
+ <li>
+ Understand what <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a> means.
+ </li>
+ <li>
+ Take a tour of the <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a> and <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>.
+ </li>
+</ul>
+<h3>
+ <a id="Providing" name="Providing">Providing Feedback</a>
+</h3>
+<p>
+ As this is the first version of the XP plug-in, we are looking to the community for advice on how to make it
+ better. You can help us do this by sending us your suggestions, comments, or questions to the discussions lists (see <a
+ href="http://www.eclipse.org/epf">www.eclipse.org/epf</a> for more information).
+</p><!-- END:mainDescription,-PCk5_o83KYiPZaKUzt021A -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_and_agile_process_references.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_and_agile_process_references.html
new file mode 100644
index 0000000..1438258
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_and_agile_process_references.html
@@ -0,0 +1,248 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\xp_and_agile_process_references.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_and_agile_process_references.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,6.191633934532389E-306 CRC: 3485394907 -->XP and Agile Process References<!-- END:presentationName,6.191633934532389E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-8UKMv929ysWDBF1IOAAgsg CRC: 952887172 --><a id="XE_references__xp_bibliography_of" name="XE_references__xp_bibliography_of"></a>
+<div align="center">
+ <br />
+
+ <table width="100%" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AUE01" name="AUE01">AUE01</a>
+ </td>
+ <td colspan="2">
+ Ken Auer et al. 2001. <i>Extreme Programming Applied: Playing to Win.</i> Addison-Wesley Publishing
+ Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Experiences from pioneers in applying XP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEC00" name="BEC00">BEC00</a>
+ </td>
+ <td colspan="2">
+ Kent Beck 2000. <i>Extreme Programming Explained</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Good introduction to the fundamental ideas of XP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEC01" name="BEC01">BEC01</a>
+ </td>
+ <td colspan="2">
+ Kent Beck, Martin Fowler 2001. <i>Planning Extreme Programming</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Explains how to plan and manage an XP project.
+ </td>
+ </tr>
+ </tbody>
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COC01" name="COC01">COC01</a>
+ </td>
+ <td colspan="2">
+ Alistair Cockburn 2001. <i>Agile Software Development</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Peers into the team dynamics, the cultures, the communications aspects of software development.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FOW99" name="FOW99">FOW99</a>
+ </td>
+ <td colspan="2">
+ Martin Fowler et al. 1999. <i>Refactoring: Improving the Design of Existing Code</i> Addison-Wesley
+ Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JEF01" name="JEF01">JEF01</a>
+ </td>
+ <td colspan="2">
+ Ron Jeffries, Ann Anderson, and Chet Hendrickson 2001. <i>Extreme Programming Installed.</i>
+ Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book describes practical Extreme Programming techniques.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KER01" name="KER01">KER01</a>
+ </td>
+ <td colspan="2">
+ Norman L. Kerth, April 2001. <i>Project Retrospectives: A Handbook for Team Reviews.</i> Dorset
+ House.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ "Presents a convincing argument for the value of taking the time to study past projects and learn from
+ them [...] Kerth's sensitivity to the complex interpersonal issues surrounding project retrospectives
+ will help any facilitator, participant, or manager get the most out of these important learning
+ activities." Karl E. Wiegers, February 8, 2003.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRO03" name="KRO03">KRO03</a>
+ </td>
+ <td colspan="2">
+ Per Kroll and Philippe Kruchten 2003. <i>The Rational Unified Process Made Easy, A Practitioners Guide
+ to the RUP.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A practical guide to adopting the spirit, principles and practices of the RUP. An invaluable resource
+ in helping you decide how to apply the RUP in your organization or project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="NEW01" name="NEW01">NEW01</a>
+ </td>
+ <td colspan="2">
+ James Newkirk and Robert Martin 2001. <i>Extreme Programming in Practice.</i> Addison-Wesley Publishing
+ Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A report of experience using XP on a web project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SUC01" name="SUC01">SUC01</a>
+ </td>
+ <td colspan="2">
+ Giancarlo Succi, Michele Marchesi 2001. <i>Extreme Programming Examined.</i> Addison-Wesley Publishing
+ Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A collection of papers covering a wide variety of topics related to XP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WAK01" name="WAK01">WAK01</a>
+ </td>
+ <td colspan="2">
+ William Wake 2001. <i>Extreme Programming Explored.</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Based on the popular XPlorations website. Specific subjects are explored in detail.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div><!-- END:mainDescription,-8UKMv929ysWDBF1IOAAgsg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_artifacts.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_artifacts.html
new file mode 100644
index 0000000..5a6fdee
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_artifacts.html
@@ -0,0 +1,90 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\xp_artifacts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_artifacts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.545655831828372E-305 CRC: 992470252 -->XP Artifacts<!-- END:presentationName,1.545655831828372E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-O3LVBobhzFRt-5bytDkqqQ CRC: 2170920520 --><a id="XE_artifact__overview_of_all_xp_artifacts" name="XE_artifact__overview_of_all_xp_artifacts"></a>
+<p>
+ In the spirit of simplicity, one of the basic <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a>, the number of artifacts in XP is fairly small. Actually, in XP we don't really talk about artifacts as
+ such. Except for the production code, all other artifacts generated by the process imply work that is tangential to
+ getting to the end goal, a running product. In theory, everything else should be considered as optional. The set of
+ artifacts presented here is commonly used by XP teams to deliver software in an efficient manner. As a rule, try
+ to limit the amount of effort put on any tangential work unless it can be proved to improve the process in some
+ demonstrable way.
+</p>
+<p>
+ The XP artifacts are:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_vision,{2300FB25-7249-4481-A1BD-978240906832}.html"
+ guid="{2300FB25-7249-4481-A1BD-978240906832}">Vision</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_user_story,{21946731-4F5C-4862-8B4D-868629952B92}.html"
+ guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_customer_test,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}.html"
+ guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">Customer Test</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_release_plan,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}.html"
+ guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">Release Plan</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_metaphor,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}.html"
+ guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">Metaphor (System of Names)</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_iteration_plan,{DC18E34B-70C1-403D-84CC-1BF117A7473D}.html"
+ guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">Iteration Plan</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_coding_standard,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}.html"
+ guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">Coding Standard</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_unit_test,{D156652E-7C52-4EBD-8F23-F38169877A57}.html"
+ guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">Unit Test</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_production_code,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}.html"
+ guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
+ guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">Build</a>
+ </li>
+</ul><!-- END:mainDescription,-O3LVBobhzFRt-5bytDkqqQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_copyright.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_copyright.html
new file mode 100644
index 0000000..36080fb
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_copyright.html
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\xp_copyright.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_copyright.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_XI5PQHEPEdug-a-RuUM3Hg CRC: 481069588 -->XP Plug-in Copyright<!-- END:presentationName,_XI5PQHEPEdug-a-RuUM3Hg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-31JQsY6FjFegmq-JJZdndg CRC: 3814529338 -->Copyright (c) 2002, 2006 IBM Corporation and Object Mentor. All rights reserved. <br />
+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 <a href="http://www.eclipse.org/legal/epl-v10.html"
+target="_blank">http://www.eclipse.org/legal/epl-v10.html</a>. <br />
+Contributors: IBM Corporation and Object Mentor - initial implementation<br /><!-- END:mainDescription,-31JQsY6FjFegmq-JJZdndg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_customer_team.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_customer_team.html
new file mode 100644
index 0000000..36bee8b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_customer_team.html
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\xp_customer_team.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_customer_team.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,2.9889538140050517E-306 CRC: 3821492139 -->XP Customer Team<!-- END:presentationName,2.9889538140050517E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-mZMamrTcnR6xoZgvw9XU-A CRC: 1056296789 --><p>
+ The customer team provides the requirements, sets the priorities and steers the project. The customer team can be made
+ up of one or more business representatives from different parts of the organization. If there is more than one
+ representative, it is important that the customer team speak to the developers in one voice ("The Customer") in order
+ to keep communication focused. It is best if the customer team includes a real end user who knows the domain and what
+ is needed. There may be a manager, providing resources, handling external communication and coordinating activities.
+ The team may include testers, who help the customer define the customer acceptance tests. Analysts may also help to
+ define the requirements.
+</p>
+<p>
+ <br />
+ <br />
+</p><!-- END:mainDescription,-mZMamrTcnR6xoZgvw9XU-A -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_developer_team.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_developer_team.html
new file mode 100644
index 0000000..415eba3
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_developer_team.html
@@ -0,0 +1,32 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\xp_developer_team.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_developer_team.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,8.608243854485154E-306 CRC: 2066462259 -->XP Developer Team<!-- END:presentationName,8.608243854485154E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_11Y5NHJcC5lkqB4CeSpbg CRC: 902772222 --><p>
+ The developer team writes the software that will meet the customer's needs. The team consists of programmers, and
+ commonly a coach, who helps the team stay on track and facilitates the process.
+</p>
+<p>
+ <br />
+ <br />
+</p><!-- END:mainDescription,-_11Y5NHJcC5lkqB4CeSpbg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_organization.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_organization.html
new file mode 100644
index 0000000..655b3ef
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/supportingmaterials/xp_organization.html
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\supportingmaterials\xp_organization.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_organization.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,5.613949040902463E-308 CRC: 2696730065 -->XP Organization<!-- END:presentationName,5.613949040902463E-308 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-2nINowSo0VedqZTd4LIZIg CRC: 2130177980 --><p>
+ On all but the smallest of projects, the people involved in a software project will be part of one or more entities
+ (businesses, functional groups, governments, communities, etc.). The <a class="elementLink"
+ href="./../../../myxp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a> focus on the roles directly involved in identifying what the software needs to do (<a class="elementLink"
+ href="./../../../myxp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>) and developing that software (<a class="elementLink"
+ href="./../../../myxp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>). To support those teams, the <a class="elementLink"
+ href="./../../../myxp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole
+ Team</a> includes a third important group, the XP Organization.
+</p>
+<p>
+ The specific roles that XP identifies as part of the XP Organization are the XP Tracker and the XP Coach. The XP
+ Organization also includes all of the people who make up the infrastructure that allows the project to exist. This
+ includes management, accounting, support, facilities, etc. Because these are supporting roles, XP attempts to minimize
+ the dependence of the XP Customer Team and the XP Developer Team on the XP Organization. In XP, the goal is for the
+ whole team to be self-managing and largely self-supporting. XP does not give specific practice guidance to these other
+ roles, but does suggest that these roles also guide their practices with the <a class="elementLink"
+ href="./../../../myxp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a> of communication, simplicity, feedback, and courage.
+</p>
+<br /><!-- END:mainDescription,-2nINowSo0VedqZTd4LIZIg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/refactoring.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/refactoring.html
new file mode 100644
index 0000000..d977531
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/refactoring.html
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\whitepapers\refactoring.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: refactoring.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,1.0713784560673905E-305 CRC: 3501494639 -->Refactoring<!-- END:presentationName,1.0713784560673905E-305 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-ql_2w28A9SIIZQca3Wg-kQ CRC: 3978085959 --><address>
+ By Michael Feathers.
+</address>
+<address>
+ All Rights Reserved.
+</address>
+<p>
+ A <a href="resources/refactoring.pdf" target="_blank">PDFversion</a> of this article is available; however, you
+ must have <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to
+ view it.
+</p>
+<h3>
+ Abstract
+</h3>
+<p>
+ This paper addresses refactoring from the context of starting with legacy code, as opposed to so called "green field"
+ development. Topics covered include: Test Coverings; Inflection Points; Breaking External and Internal Dependencies.
+</p>
+<p>
+ <br />
+
+</p><!-- END:mainDescription,-ql_2w28A9SIIZQca3Wg-kQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/refactoring.pdf b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/refactoring.pdf
new file mode 100644
index 0000000..a627aed
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/refactoring.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/xppair.pdf b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/xppair.pdf
new file mode 100644
index 0000000..fe0eb9f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/xppair.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/xprefact.pdf b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/xprefact.pdf
new file mode 100644
index 0000000..187c9b1
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/resources/xprefact.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/xp_guidelines_pair_programming.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/xp_guidelines_pair_programming.html
new file mode 100644
index 0000000..03a64aa
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/xp_guidelines_pair_programming.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\whitepapers\xp_guidelines_pair_programming.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_guidelines_pair_programming.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,7.290386721197834E-306 CRC: 3935357826 -->XP Guidelines: Pair Programming<!-- END:presentationName,7.290386721197834E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-Ymu8T1hQ_QoxCaNAQhD9AA CRC: 240067785 --><a id="XE_XP__Pair_Programming" name="XE_XP__Pair_Programming"></a>
+<address>
+ By Robert C. Martin<br />
+ Object Mentor, Inc.<br />
+ <a href="http://www.objectmentor.com" target="_blank">www.objectmentor.com</a>
+</address>
+All Rights Reserved.
+<p>
+ A <a href="resources/xppair.pdf" target="_blank">PDF version</a> of this article is available, however, you must have
+ <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to view it.
+</p>
+<h3>
+ Abstract
+</h3>
+<p>
+ Pair programming is a well-tested, well accepted alternative to code reviews. More than that, it's a fundamentally
+ different way to write software. The benefits go far beyond productivity and quality, and affect such things as the
+ robustness and morale of the team.
+</p>
+<br />
+<br /><!-- END:mainDescription,-Ymu8T1hQ_QoxCaNAQhD9AA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.html b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.html
new file mode 100644
index 0000000..b217252
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.html
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\guidances\whitepapers\xp_guidelines_test-first_design_and_refactoring.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_guidelines_test-first_design_and_refactoring.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,6.334658646686929E-306 CRC: 3615366241 -->XP Guidelines: Test-first Design and Refactoring<!-- END:presentationName,6.334658646686929E-306 -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-_AgYWcSlbVBZOVcQfJuBnQ CRC: 1721413199 --><a id="XE_XP__Test-first_Design_and_Refactoring" name="XE_XP__Test-first_Design_and_Refactoring"></a>
+<address>
+ By Robert C. Martin<br />
+ Object Mentor, Inc.<br />
+ <a href="http://www.objectmentor.com" target="_blank">www.objectmentor.com</a>
+</address>
+<p>
+ All Rights Reserved.
+</p>
+<p>
+ A <a href="resources/xprefact.pdf" target="_blank">PDF version</a> of this article is available, however, you must have
+ <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to view it.
+</p>
+<h3>
+ Abstract
+</h3>
+<p>
+ This paper demonstrates the techniques of refactoring in the presence of test-first design and conveys a programming
+ attitude. A program is not done when it works; a program is done when it works <i>and</i> when it's as simple and clean
+ as possible.
+</p>
+<br />
+<br /><!-- END:mainDescription,-_AgYWcSlbVBZOVcQfJuBnQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/plugin.html b/XP/XP_baseline_EN/exported_HTML/xp/plugin.html
new file mode 100644
index 0000000..5bebb7e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/plugin.html
@@ -0,0 +1,145 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\plugin.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: plugin.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_13azwGNdEdqsrK7eslBiiA CRC: 1984245061 -->XP Roles<!-- END:presentationName,_13azwGNdEdqsrK7eslBiiA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_8NSdoGdjEdqlnYmIxoiUEQ CRC: 93292896 -->XP Team<!-- END:presentationName,_8NSdoGdjEdqlnYmIxoiUEQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_mtcquWE-EdqnIZeW8YpHcA CRC: 1676697978 -->XP Roles and Artifacts<!-- END:presentationName,_mtcquWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,_um0n8GdjEdqlnYmIxoiUEQ CRC: 515224557 -->Overview<!-- END:presentationName,_um0n8GdjEdqlnYmIxoiUEQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{90FB58E1-B403-4358-85D0-BD902528D810} CRC: 351121918 -->xp_essentials<!-- END:name,{90FB58E1-B403-4358-85D0-BD902528D810} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{90FB58E1-B403-4358-85D0-BD902528D810} CRC: 4059907453 --> This component provides the essential concepts required to understand XP. <!-- END:briefDescription,{90FB58E1-B403-4358-85D0-BD902528D810} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{BC57C7CE-BFA8-464F-9925-D27A7968B63C} CRC: 3522700040 -->xp_requirements<!-- END:name,{BC57C7CE-BFA8-464F-9925-D27A7968B63C} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{BC57C7CE-BFA8-464F-9925-D27A7968B63C} CRC: 541201536 --> This component provides guidance for defining requirements on an XP project. <!-- END:briefDescription,{BC57C7CE-BFA8-464F-9925-D27A7968B63C} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{A179D686-1E79-4CB0-97B5-103B4FBBBDEF} CRC: 118651383 -->XP Customer (Requirements)<!-- END:presentationName,{A179D686-1E79-4CB0-97B5-103B4FBBBDEF} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} CRC: 3605220974 -->xp_programming<!-- END:name,{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} CRC: 22703235 --> This component provides guidance for programming on XP projects. <!-- END:briefDescription,{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{C587F94C-90FD-4943-A4DE-68E9B6875071} CRC: 1523426180 -->XP Programmer (Implementer)<!-- END:presentationName,{C587F94C-90FD-4943-A4DE-68E9B6875071} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{796EA4CB-0038-43B8-A568-792DCC3B9F22} CRC: 2821883454 -->xp_design<!-- END:name,{796EA4CB-0038-43B8-A568-792DCC3B9F22} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{796EA4CB-0038-43B8-A568-792DCC3B9F22} CRC: 2249557768 --> This component provides guidance for how to design on an XP project. <!-- END:briefDescription,{796EA4CB-0038-43B8-A568-792DCC3B9F22} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{AB49377E-B734-45D9-A8AE-906AE216CBC7} CRC: 2615950178 -->XP Programmer (Designer)<!-- END:presentationName,{AB49377E-B734-45D9-A8AE-906AE216CBC7} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{DBE91BD5-0065-4049-AA61-058C77F1D2A3} CRC: 1794683194 -->xp_integration<!-- END:name,{DBE91BD5-0065-4049-AA61-058C77F1D2A3} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{DBE91BD5-0065-4049-AA61-058C77F1D2A3} CRC: 3824558902 --> This component provides guidance for integrating and building executables on XP projects. <!-- END:briefDescription,{DBE91BD5-0065-4049-AA61-058C77F1D2A3} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{2F4BC5DA-F706-4C38-9D38-6911C7856B10} CRC: 686878450 -->XP Programmer (Integrator)<!-- END:presentationName,{2F4BC5DA-F706-4C38-9D38-6911C7856B10} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{8367713C-3AEA-489D-B136-DB87D6340A3F} CRC: 254675677 -->xp_testing<!-- END:name,{8367713C-3AEA-489D-B136-DB87D6340A3F} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{8367713C-3AEA-489D-B136-DB87D6340A3F} CRC: 29347952 --> This component provides guidance for testing on XP projects. <!-- END:briefDescription,{8367713C-3AEA-489D-B136-DB87D6340A3F} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{9EE5F015-C409-4DD9-91AC-1A87DB833E92} CRC: 4283994040 -->XP Customer Test<!-- END:presentationName,{9EE5F015-C409-4DD9-91AC-1A87DB833E92} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{567EE050-7E62-4B63-8761-4883FF2FFF23} CRC: 1484125257 -->XP Test Analyst<!-- END:presentationName,{567EE050-7E62-4B63-8761-4883FF2FFF23} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,{45A887AB-A968-48AF-8213-4D470DA9DBCC} CRC: 3360406596 -->xp_management<!-- END:name,{45A887AB-A968-48AF-8213-4D470DA9DBCC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{45A887AB-A968-48AF-8213-4D470DA9DBCC} CRC: 2890825621 --> This component provides guidance for managing XP projects. <!-- END:briefDescription,{45A887AB-A968-48AF-8213-4D470DA9DBCC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B} CRC: 3743968883 -->XP Customer (Manager)<!-- END:presentationName,{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_ms9igWE-EdqnIZeW8YpHcA CRC: 171732258 -->xp_basic_concepts<!-- END:name,_ms9igWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/resources/circleOfLife.jpg b/XP/XP_baseline_EN/exported_HTML/xp/resources/circleOfLife.jpg
new file mode 100644
index 0000000..3772826
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/resources/circleOfLife.jpg
Binary files differ
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_coach.html b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_coach.html
new file mode 100644
index 0000000..8187328
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_coach.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\roles\xp_coach.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_coach.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6} CRC: 4280446542 -->XP Coach<!-- END:presentationName,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6} CRC: 1347373446 -->The XP Coach is a supporting role which helps a team stay on process and help the team learn.<!-- END:briefDescription,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-gAMIwaLmqX7bf6GLCqwB-g CRC: 2251890135 --><a id="XE_xp_coach__role_definition" name="XE_xp_coach__role_definition"></a><a id="Description" name="Description"></a>
+<p>
+ The <a class="PresentationName" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> role helps a team stay on
+ process and helps the team to learn. A coach brings an outside perspective to help a team see themselves more clearly.
+ The coach will help balance the needs of delivering the project while improving the use of the practices. A coach or
+ team of coaches supports the Customer Team, the Developer Team, and the Organization.
+</p>
+<p>
+ The decisions that coaches make should always stem from the XP values (communication, simplicity, feedback, and
+ courage) and usually move toward the XP practices. As such, familiarity with the values and practices is a
+ prerequisite. The coach must command the respect required to lead the respective teams. The coach must possess people
+ skills and be effective in influencing the actions of the teams.
+</p><!-- END:mainDescription,-gAMIwaLmqX7bf6GLCqwB-g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-gAMIwaLmqX7bf6GLCqwB-g CRC: 2584847598 --><a id="Skills" name="Skills"></a>
+<p>
+ The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> uses many different techniques. The coach is a mentor,
+ working side by side with team members on their tasks. The coach is a facilitator, helping achieve more effective team
+ performance. The coach is a conduit, reinforcing communication within the team and across teams.
+</p><!-- END:skills,-gAMIwaLmqX7bf6GLCqwB-g -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_customer.html b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_customer.html
new file mode 100644
index 0000000..706b624
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_customer.html
@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\roles\xp_customer.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_customer.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{3C90DD4F-CFDB-4111-922D-3B840B8942DE} CRC: 2406660688 -->XP Customer<!-- END:presentationName,{3C90DD4F-CFDB-4111-922D-3B840B8942DE} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{3C90DD4F-CFDB-4111-922D-3B840B8942DE} CRC: 39828424 -->The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built, and making sure the product actually works.<!-- END:briefDescription,{3C90DD4F-CFDB-4111-922D-3B840B8942DE} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-92rjXjWhll5LOtPc58YERg CRC: 374212800 --><a id="XE_xp_customer__role_definition" name="XE_xp_customer__role_definition"></a><a id="Description"
+name="Description"></a>
+<p>
+ The <a class="PresentationName" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">XP Customer</a> role has the
+ responsibility of defining what is the right product to build, determining the order in which features will be built
+ and making sure the product actually works.
+</p>
+<p>
+ The <a class="PresentationName" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">XP Customer</a> writes system features in
+ the form of user stories that have business value. Using the planning game, he chooses the order in which the stories
+ will be done by the development team. He also defines acceptance tests that will be run against the system to prove
+ that the system is reliable and does what is required.
+</p><!-- END:mainDescription,-92rjXjWhll5LOtPc58YERg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_programmer.html b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_programmer.html
new file mode 100644
index 0000000..5395bdb
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_programmer.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\roles\xp_programmer.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_programmer.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1} CRC: 201052234 -->XP Programmer<!-- END:presentationName,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1} CRC: 1626650219 -->The XP Programmer is responsible for implementing the code to support the user stories.<!-- END:briefDescription,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-RoFHDUeLz4UFKDuFirQp3g CRC: 418069483 --><a id="XE_xp_programmer__role_definition" name="XE_xp_programmer__role_definition"></a><!-- END:mainDescription,-RoFHDUeLz4UFKDuFirQp3g -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_system_administrator.html b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_system_administrator.html
new file mode 100644
index 0000000..9b86d14
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_system_administrator.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\roles\xp_system_administrator.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_system_administrator.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{0CB3C507-AFEE-4DA8-982B-9B93C8729910} CRC: 4155345437 -->XP Programmer (Administrator)<!-- END:presentationName,{0CB3C507-AFEE-4DA8-982B-9B93C8729910} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{0CB3C507-AFEE-4DA8-982B-9B93C8729910} CRC: 2287736509 -->The XP Programmer (Administrator) is responsible for managing the programmer environment.<!-- END:briefDescription,{0CB3C507-AFEE-4DA8-982B-9B93C8729910} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-23MZj6vLVbgbkXaptH4riQ CRC: 610718319 --><a id="XE_xp_programmer_(administrator)__role_definition" name="XE_xp_programmer_(administrator)__role_definition"></a><a
+id="Description" name="Description"></a>
+<p>
+ The <a class="PresentationName" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">XP Programmer (Administrator)</a> role
+ includes most of the traditional software development technical roles, such as designer, implementer, integrator, and
+ administrator.
+</p>
+<p>
+ In the administrator role, the programmer deals with establishing the physical working environment.
+</p><!-- END:mainDescription,-23MZj6vLVbgbkXaptH4riQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-23MZj6vLVbgbkXaptH4riQ CRC: 2680546623 --><a id="Skills" name="Skills"></a>
+<p>
+ The <a class="PresentationName" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">XP Programmer (Administrator)</a> role is
+ responsible for establishing the workspace for pair programming, including removing cubicle walls, establishing line of
+ sight with the customer, and standardizing on the development tools.
+</p><!-- END:skills,-23MZj6vLVbgbkXaptH4riQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_tester.html b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_tester.html
new file mode 100644
index 0000000..8fe2cec
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_tester.html
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\roles\xp_tester.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_tester.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{FB65D00B-8304-4CF7-9969-52CE82F503DC} CRC: 4280733514 -->XP Tester<!-- END:presentationName,{FB65D00B-8304-4CF7-9969-52CE82F503DC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{FB65D00B-8304-4CF7-9969-52CE82F503DC} CRC: 3258103593 -->The XP Tester role helps the customer define and write acceptance tests for user stories.<!-- END:briefDescription,{FB65D00B-8304-4CF7-9969-52CE82F503DC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-KfsuH9i0hVMlGV7PVIa3FQ CRC: 2438822508 --><p>
+ The primary responsibility of the XP Tester is to help the customer define and implement acceptance tests for user
+ stories. The XP Tester is also responsible for running the tests frequently and posting the results for the whole team
+ to see. As the number of tests grow, the XP Tester will likely need to create and maintain some kind of tool to make it
+ easier to define them, run them, and gather the results quickly.
+</p><!-- END:mainDescription,-KfsuH9i0hVMlGV7PVIa3FQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: skills<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:skills,-KfsuH9i0hVMlGV7PVIa3FQ CRC: 1369244389 --><p>
+ Whereas knowledge of the applications target domain is provided by the customer, the XP Tester needs to support the
+ customer by providing:
+</p>
+<ul>
+ <li>
+ Knowledge of typical software failure conditions and the test techniques that can be employed to uncover those
+ errors.
+ </li>
+ <li>
+ Knowledge of different techniques to implement and run tests, including understanding of and experience with test
+ automation.
+ </li>
+</ul><!-- END:skills,-KfsuH9i0hVMlGV7PVIa3FQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_tracker.html b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_tracker.html
new file mode 100644
index 0000000..54f789f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/roles/xp_tracker.html
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\roles\xp_tracker.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_tracker.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{D8FE277E-4F9A-47EB-855F-C451D601BBAF} CRC: 1021264295 -->XP Tracker<!-- END:presentationName,{D8FE277E-4F9A-47EB-855F-C451D601BBAF} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{D8FE277E-4F9A-47EB-855F-C451D601BBAF} CRC: 2253419770 -->The XP Tracker role measures and communicates the team's progress.<!-- END:briefDescription,{D8FE277E-4F9A-47EB-855F-C451D601BBAF} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-FIhk4OEzZl2IAVMXurpBLA CRC: 3144915614 --><a id="XE_xp_tracker__role_definition" name="XE_xp_tracker__role_definition"></a><a id="Description"
+name="Description"></a>
+<p>
+ The three basic things the <a class="PresentationName" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a>
+ will track are the release plan (user stories), the iteration plan (tasks) and the acceptance tests. The tracker can
+ also keep track of other metrics, which may help in solving problems the team is having. A good <a
+ class="PresentationName" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a> has the ability to collect the
+ information without disturbing the process significantly.
+</p><!-- END:mainDescription,-FIhk4OEzZl2IAVMXurpBLA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/adapt_and_improve_process.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/adapt_and_improve_process.html
new file mode 100644
index 0000000..f44c964
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/adapt_and_improve_process.html
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\adapt_and_improve_process.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: adapt_and_improve_process.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{F0D4C205-4A38-42AF-BE87-9A6C0C173E65} CRC: 2995995074 -->Adapt and Improve Process<!-- END:presentationName,{F0D4C205-4A38-42AF-BE87-9A6C0C173E65} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-u-Svthjtn1xLK2IwVUpk5Q CRC: 863046350 --><a id="XE_adapt_and_improve_process__activity_definition" name="XE_adapt_and_improve_process__activity_definition"></a>
+<ul>
+ <li>
+ Improve the productivity of the team.
+ </li>
+</ul><!-- END:purpose,-u-Svthjtn1xLK2IwVUpk5Q -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oNoEAGE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oNoEAGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oNoEAGE-EdqnIZeW8YpHcA CRC: 529630924 --><a id="Prep" name="Prep"></a>
+<p>
+ Teams using XP are guided by the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP Values</a>
+ through their use of the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>. The XP Practices are each best practices, but the practices also leverage the benefits of the other
+ practices to form an efficient, minimal set of practices required to deliver high quality software aligned to customer
+ needs.
+</p>
+<p>
+ In general, teams will be most effective in their use of XP if each of the practices is used as much as possible on the
+ project. In practice, this can be difficult to achieve for a number of reasons, including:
+</p>
+<ul>
+ <li>
+ Technical obstacles, such as non-OO languages and legacy code
+ </li>
+ <li>
+ Lack of skills, including basic programming skills, practice skills, domain expertise, teamwork skills
+ </li>
+ <li>
+ A complex customer environment, where a single source of prioritized stories is difficult to develop
+ </li>
+ <li>
+ Organizational obstacles, such as distributed teams, large teams, and command/control oriented cultures
+ </li>
+</ul>
+<p>
+ As the team uses XP, these obstacles affect their ability to effectively use the practices. The <a
+ class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> helps the team address how these challenges will affect
+ their use of the practices. This starts with helping the team maintain the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html#Courage"
+ guid="1.076140803519123E-306">Courage</a> to confront and remove these obstacles, clearing the way for the practices to
+ be used. In cases where the obstacles cannot be removed, the coach and the team use the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP Values</a>
+ to guide adaptation of the practices.
+</p>
+<p>
+ The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> needs to participate in communities that share best
+ practices in software development and XP. These communities will exist within large companies, in local users groups,
+ and in Internet communities.
+</p>
+<p>
+ <br />
+ <br />
+</p><!-- END:sectionDescription,_oNoEAGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/automate_acceptance_test.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/automate_acceptance_test.html
new file mode 100644
index 0000000..366c914
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/automate_acceptance_test.html
@@ -0,0 +1,72 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\automate_acceptance_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: automate_acceptance_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{E614ED93-AE72-4FD1-B459-C508CE1C536F} CRC: 3311427424 -->Automate Customer Test<!-- END:presentationName,{E614ED93-AE72-4FD1-B459-C508CE1C536F} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-fm-gBePbdl_WMsE5NxEreQ CRC: 284304686 --><a id="XE_automate_customer_test__activity_definition" name="XE_automate_customer_test__activity_definition"></a>
+<ul>
+ <li>
+ Transform the acceptance criteria of a user story into executable form.
+ </li>
+</ul><!-- END:purpose,-fm-gBePbdl_WMsE5NxEreQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oNCOIGE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oNCOIGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oNCOIGE-EdqnIZeW8YpHcA CRC: 1732889242 --><a id="Prep" name="Prep"></a>
+<p>
+ XP teams represent detailed requirements as automated customer tests. Automating the tests insures they are detailed,
+ unambiguous, and executable. Typically, each acceptance criteria is translated into at least one automated test.
+</p>
+<p>
+ There are lots of ways to do this:
+</p>
+<ul>
+ <li>
+ For a batch program reading inputs and producing outputs: create test input files, capture actual output, and
+ compare it against expected output.
+ </li>
+ <li>
+ Write functional tests as programs. You can use a unit testing framework as a base or create a little scripting
+ language the programmers can use.
+ </li>
+ <li>
+ Allow the customer to easily specify tests (spreadsheets, flat text files) and create a small tool to read the
+ input and expected output. The tool runs the input against the system and checks that the actual output matches the
+ expected output.
+ </li>
+ <li>
+ Build an input recorder to allow customers to define the tests.
+ </li>
+ <li>
+ Use simple file-based tools to check the results.
+ </li>
+</ul>
+<p>
+ It is important to build the automation simply and incrementally as you need it. It is too easy to lose control and
+ invest too much time in test automation instead of business value. Don't overdo it.
+</p><!-- END:sectionDescription,_oNCOIGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/breakdown_story.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/breakdown_story.html
new file mode 100644
index 0000000..77f15fa
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/breakdown_story.html
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\breakdown_story.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: breakdown_story.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{90DBD758-58B8-4383-94DD-312D349512BC} CRC: 573295334 -->Break down Story<!-- END:presentationName,{90DBD758-58B8-4383-94DD-312D349512BC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-umDp1nFYrMetgnJ-kUMhHw CRC: 792550486 --><a id="XE_break_down_story__activity_definition" name="XE_break_down_story__activity_definition"></a>
+<ul>
+ <li>
+ Split user stories into engineering tasks.
+ </li>
+</ul><!-- END:purpose,-umDp1nFYrMetgnJ-kUMhHw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEkOoGE-EdqnIZeW8YpHcA CRC: 1251240587 --> Understand the User Story <!-- END:name,_oEkOoGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEkOoGE-EdqnIZeW8YpHcA CRC: 1648261788 --><a id="Step1" name="Step1"></a>
+<p>
+ Breaking down user stories occurs at iteration planning. The first step in iteration planning is for the customer to go
+ over the story with the developers to ensure they understand the story. The developers can ask questions until they are
+ satisfied that they understand all aspects of the system. The details of the user stories are defined in the acceptance
+ test criteria.
+</p><!-- END:sectionDescription,_oEkOoGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEkOoWE-EdqnIZeW8YpHcA CRC: 2107401795 --> Discuss Possible Implementations <!-- END:name,_oEkOoWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEkOoWE-EdqnIZeW8YpHcA CRC: 3742682002 --><a id="Step2" name="Step2"></a>
+<p>
+ Coming up with engineering tasks for a story requires a good understanding of how the story will be implemented. The
+ team uses this time to discuss possible design alternatives or approaches.
+</p><!-- END:sectionDescription,_oEkOoWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEkOomE-EdqnIZeW8YpHcA CRC: 457044193 --> Identify Engineering Tasks <!-- END:name,_oEkOomE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEkOomE-EdqnIZeW8YpHcA CRC: 882639713 --><a id="Step3" name="Step3"></a>
+<p>
+ Once an approach has been selected by the team, the team focuses on identifying the steps that allow the team to fully
+ implement it during the following iteration.
+</p>
+<p>
+ <br />
+ <br />
+</p><!-- END:sectionDescription,_oEkOomE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_coding_standard.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_coding_standard.html
new file mode 100644
index 0000000..d9fdc5d
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_coding_standard.html
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\define_coding_standard.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: define_coding_standard.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410} CRC: 3842185346 -->Define Coding Standard<!-- END:presentationName,{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-qIbMRqe8wqKN2-HLtNUcLw CRC: 2421563188 --><a id="XE_define_coding_standard__activity_definition" name="XE_define_coding_standard__activity_definition"></a>
+<ul>
+ <li>
+ To aid clarity by making the style of code as familiar as possible.
+ </li>
+</ul><!-- END:purpose,-qIbMRqe8wqKN2-HLtNUcLw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCfyEGE-EdqnIZeW8YpHcA CRC: 3504642577 --> Write Prototypical Classes <!-- END:name,_oCfyEGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCfyEGE-EdqnIZeW8YpHcA CRC: 2200218799 --><a id="Step1" name="Step1"></a>
+<p>
+ When deciding on a coding standard, take the time to write a few classes which use a particular style. Should the curly
+ braces be flush with the indentation of the line above? Do we use tabs or spaces? Are abbreviations permitted? If so,
+ do we have a short list?
+</p><!-- END:sectionDescription,_oCfyEGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCfyEWE-EdqnIZeW8YpHcA CRC: 897499029 --> Discuss Standard <!-- END:name,_oCfyEWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCfyEWE-EdqnIZeW8YpHcA CRC: 644219774 --><a id="Step2" name="Step2"></a>
+<p>
+ The coding standard for a project should be as simple as possible. The goal is not to forbid error prone constructs,
+ but rather to make the code as communicative and uniform as possible so it can be understood and worked on readily. If
+ the team cannot reach consensus, use majority rule. Having a standard is more important than the specific details.
+</p>
+<p>
+ <br />
+
+</p><!-- END:sectionDescription,_oCfyEWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_customer_test.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_customer_test.html
new file mode 100644
index 0000000..e932481
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_customer_test.html
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\define_customer_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: define_customer_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{DCDB57BE-4233-4CF8-90CE-70D6808F92B0} CRC: 2489882610 -->Define Customer Test<!-- END:presentationName,{DCDB57BE-4233-4CF8-90CE-70D6808F92B0} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-WgE0oiE2yddCOMnfzL25Gw CRC: 3909099008 --><a id="XE_define_customer_test__activity_definition" name="XE_define_customer_test__activity_definition"></a>
+<ul>
+ <li>
+ Define the criteria under which the customer will deem a story complete.
+ </li>
+</ul><!-- END:purpose,-WgE0oiE2yddCOMnfzL25Gw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oGorMGE-EdqnIZeW8YpHcA CRC: 2118519414 -->Understand the Story <!-- END:name,_oGorMGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oGorMGE-EdqnIZeW8YpHcA CRC: 3687733086 --><a id="Step1" name="Step1"></a>
+<p>
+ Since the customer tests are automated, the customer has to be very specific about what the test will do. It is
+ impossible to do this if the customer does not understand the story in intimate detail from a user perspective. Writing
+ the customer tests will force the customer to go into all the details of the story. Stories must be testable.
+</p><!-- END:sectionDescription,_oGorMGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oGorMWE-EdqnIZeW8YpHcA CRC: 3682764237 -->Define Test Criteria <!-- END:name,_oGorMWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oGorMWE-EdqnIZeW8YpHcA CRC: 2822317541 --><a id="Step2" name="Step2"></a>
+<p>
+ Once the story is well understood and selected for the iteration, the automated customer tests are written. If the
+ customer team includes testers, the customer could communicate the test criteria to the tester. This can be verbal or
+ written. The criterion describes the tests for the normal and exceptional behavior of the system.<br />
+
+</p><!-- END:sectionDescription,_oGorMWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_iteration_plan.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_iteration_plan.html
new file mode 100644
index 0000000..be74e63
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_iteration_plan.html
@@ -0,0 +1,117 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\define_iteration_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: define_iteration_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{849E3635-6FCD-4FAD-A007-CA34B9998622} CRC: 3214991301 -->Define Iteration<!-- END:presentationName,{849E3635-6FCD-4FAD-A007-CA34B9998622} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-BWG5zUGb8c25kuLJ3ck8ng CRC: 2315263251 --><a id="XE_define_iteration__activity_definition" name="XE_define_iteration__activity_definition"></a>
+<ul>
+ <li>
+ Establish what can be built during the iteration, given the team's constraints.
+ </li>
+ <li>
+ Allow the team to manage itself at the task level.
+ </li>
+</ul><!-- END:purpose,-BWG5zUGb8c25kuLJ3ck8ng -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQSWcGE-EdqnIZeW8YpHcA CRC: 2986107745 -->Preconditions <!-- END:name,_oQSWcGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQSWcGE-EdqnIZeW8YpHcA CRC: 3005087812 --><a id="PreCond" name="PreCond"></a>
+<p>
+ The steps for this activity are part of XP iteration planning. In order for this activity to be successful, the
+ following preconditions should be met:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ The customer understands the user stories very well.
+ </div>
+ </li>
+ <li>
+ The customer has defined acceptance criteria for the stories.
+ </li>
+ <li>
+ All team members that will be involved in developing the stories should be present.
+ </li>
+</ul><!-- END:sectionDescription,_oQSWcGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQSWcWE-EdqnIZeW8YpHcA CRC: 715572452 -->Customer Presents the User Stories <!-- END:name,_oQSWcWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQSWcWE-EdqnIZeW8YpHcA CRC: 1366691347 --><a id="Step1" name="Step1"></a>
+<p>
+ The customer selects a list of user stories that he would like included in the next iteration. The stories typically
+ come from the release plan but may also include new stories that were not originally planned. The customer explains the
+ stories and the acceptance test criteria to the developers.
+</p><!-- END:sectionDescription,_oQSWcWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQSWcmE-EdqnIZeW8YpHcA CRC: 3296749530 -->Developers Break Down Stories <!-- END:name,_oQSWcmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQSWcmE-EdqnIZeW8YpHcA CRC: 1272042533 --><a id="Step2" name="Step2"></a>
+<p>
+ The developers discuss how to implement the story and break it down into engineering tasks. Tasks should include
+ everything necessary to get the story to pass the customer's acceptance test.
+</p><!-- END:sectionDescription,_oQSWcmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQSWc2E-EdqnIZeW8YpHcA CRC: 3979252062 -->Developers Sign Up and Estimate <!-- END:name,_oQSWc2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQSWc2E-EdqnIZeW8YpHcA CRC: 2956126981 --><a id="Step3" name="Step3"></a>
+<p>
+ The developers sign up for all the tasks. The developers put estimates only for the tasks they have personally signed
+ up for.
+</p><!-- END:sectionDescription,_oQSWc2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQSWdGE-EdqnIZeW8YpHcA CRC: 268450428 -->Customer Adjusts Iteration Plan <!-- END:name,_oQSWdGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQSWdGE-EdqnIZeW8YpHcA CRC: 2643306202 --><a id="Step4" name="Step4"></a>
+<p>
+ If the sum of all the task estimates is greater than the sum of all the tasks done by the team during the last
+ iteration, the customer must remove some work in order to respect the team's iteration velocity.
+</p><!-- END:sectionDescription,_oQSWdGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_release_plan.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_release_plan.html
new file mode 100644
index 0000000..309ce02
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/define_release_plan.html
@@ -0,0 +1,127 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\define_release_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: define_release_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{D755C076-8E63-4A24-89AA-A7D64E368B90} CRC: 2596175540 -->Define Release<!-- END:presentationName,{D755C076-8E63-4A24-89AA-A7D64E368B90} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-7gEOFFavlkSqwIoTNrvfJA CRC: 3028788379 --><a id="XE_define_release__activity_definition" name="XE_define_release__activity_definition"></a>
+<ul>
+ <li>
+ To estimate the content and delivery date for a release of the product.
+ </li>
+</ul><!-- END:purpose,-7gEOFFavlkSqwIoTNrvfJA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOauMGE-EdqnIZeW8YpHcA CRC: 1265947154 -->Preparation <!-- END:name,_oOauMGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOauMGE-EdqnIZeW8YpHcA CRC: 859093163 --><a id="Prep" name="Prep"></a>
+<p>
+ The steps for this activity are part of XP release planning. In order for this activity to be successful, the following
+ preconditions should be met:
+</p>
+<ul>
+ <li>
+ The customer has enough user stories at present to fill at least one release.
+ </li>
+ <li>
+ The customer understands the user stories very well.
+ </li>
+ <li>
+ The customer has defined acceptance criteria for the stories.
+ </li>
+ <li>
+ All team members that will be involved in developing the stories should be present.
+ </li>
+</ul><!-- END:sectionDescription,_oOauMGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOauMWE-EdqnIZeW8YpHcA CRC: 715572452 -->Customer Presents the User Stories <!-- END:name,_oOauMWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOauMWE-EdqnIZeW8YpHcA CRC: 1157842194 --><a id="Step1" name="Step1"></a>
+<p>
+ The customer describes each story to the team and explains the conditions under which the story is going to be
+ considered complete.
+</p><!-- END:sectionDescription,_oOauMWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOauMmE-EdqnIZeW8YpHcA CRC: 1516629642 -->Developers Estimate the User Stories <!-- END:name,_oOauMmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOauMmE-EdqnIZeW8YpHcA CRC: 412997780 --><a id="Step2" name="Step2"></a>
+<p>
+ The developers discuss each story and come up with an estimate based on their experience. High-level design discussions
+ take place as developers try to understand the story and discuss different ways of implementing it. In some cases, the
+ team will not be able to provide a reasonable estimate:
+</p>
+<ul>
+ <li>
+ They do not understand the story: the team should be asking more questions to the customer.
+ </li>
+ <li>
+ The story is too big: the developers don't have a good grasp of the scope. It should be broken down into smaller
+ stories.
+ </li>
+ <li>
+ They don't know how to do it: they will need to do some research first.
+ </li>
+</ul>
+<p>
+ Be careful to avoid analysis paralysis. The first few times the team estimates stories, it may take as long as an hour
+ to estimate a story. The second story should take less time. Your goal should be to be able to estimate a story in only
+ a few minutes.
+</p>
+<p>
+ As a rule of thumb, story estimates should not exceed the iteration length based on a pair of people dedicated to the
+ story. When stories exceed the iteration length, the customer splits the story.
+</p><!-- END:sectionDescription,_oOauMmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOg00GE-EdqnIZeW8YpHcA CRC: 4185167809 -->Customer Prioritizes Stories <!-- END:name,_oOg00GE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOg00GE-EdqnIZeW8YpHcA CRC: 1740353020 --><a id="Step3" name="Step3"></a>
+<p>
+ Once all the stories have an estimated cost, the customer can prioritize the stories into the release plan.The customer
+ organizes stories into iterations and sequences of iterations into releases. The sum of all story points in each
+ iteration cannot exceed the team's velocity. At the beginning of the project, you will have to guess the team's
+ velocity. Try one third of the ideal programmer time available in an iteration. After a few iterations, revisit the
+ plan and use the team's measured velocity. See more on release planning in the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
+ guid="6.7335956461328426E-307">planning game guideline</a>.
+</p><!-- END:sectionDescription,_oOg00GE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/develop_xp_vision.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/develop_xp_vision.html
new file mode 100644
index 0000000..9d15cac
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/develop_xp_vision.html
@@ -0,0 +1,129 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\develop_xp_vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: develop_xp_vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D} CRC: 2887983663 -->Define Vision<!-- END:presentationName,{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-W67fNE0rT1c2PM-20yXbrw CRC: 3266563031 --><a id="XE_define_vision__activity_definition" name="XE_define_vision__activity_definition"></a>
+<ul>
+ <li>
+ The Vision defines the stakeholder's view of the product being developed specified in terms of the stakeholder's
+ key needs and features.
+ </li>
+</ul><!-- END:purpose,-W67fNE0rT1c2PM-20yXbrw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oB58MGE-EdqnIZeW8YpHcA CRC: 3076507154 -->Gain Agreement on the Problem Being Solved <!-- END:name,_oB58MGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oB58MGE-EdqnIZeW8YpHcA CRC: 2696114523 --><a id="Gain" name="Step1"></a>
+<p>
+ One of the simplest ways to gain agreement on the definition of the problem is to write it down and see if everyone
+ agrees.
+</p>
+<p>
+ Ask the group: What is the problem?
+</p>
+<p>
+ It is very common to rush headlong into defining the solution rather than taking time to first understand the problem.
+ Write down the problem and see if you can get everyone to agree on the definition.
+</p>
+<p>
+ Then ask the group again: What is the problem, really?
+</p>
+<p>
+ Search for root causes or the "problem behind the problem". The real problem is often hiding behind what is perceived
+ as a problem. Don't accept the first statement of a problem. Continue to ask "why?" to find out what the problem
+ "really" is. Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate
+ the underlying problem. In such cases, it can be beneficial to explore the benefits of the solution and then try to
+ find the problems being solved by those benefits. You can then explore whether or not those problems are "real"
+ problems in the organization.
+</p><!-- END:sectionDescription,_oB58MGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oB58MWE-EdqnIZeW8YpHcA CRC: 1972005572 -->Identify Stakeholders <!-- END:name,_oB58MWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oB58MWE-EdqnIZeW8YpHcA CRC: 3081152004 --><a id="Identify" name="Step2"></a>
+<ul>
+ <li>
+ Who are the users of the system?
+ </li>
+ <li>
+ Who is the economic buyer for the system?
+ </li>
+ <li>
+ Who else will be affected by the output that the system produces?
+ </li>
+ <li>
+ Who will evaluate and bless the system when it is delivered and deployed?
+ </li>
+ <li>
+ Are there any other internal or external users of the system whose needs must be addressed?
+ </li>
+ <li>
+ Who will maintain the new system?
+ </li>
+ <li>
+ Is there anyone else?
+ </li>
+ <li>
+ Okay, is there anyone else?
+ </li>
+</ul><!-- END:sectionDescription,_oB58MWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oB58MmE-EdqnIZeW8YpHcA CRC: 1550591641 -->Define the Primary Features of the System <!-- END:name,_oB58MmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oB58MmE-EdqnIZeW8YpHcA CRC: 1655924198 --><a id="Define" name="Step3"></a>
+<p>
+ What primary features of the system allow the stakeholders to solve their problems? This should be a list of very
+ high-level features.<br />
+</p><!-- END:sectionDescription,_oB58MmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oB58M2E-EdqnIZeW8YpHcA CRC: 59390185 -->Communicate the Vision <!-- END:name,_oB58M2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oB58M2E-EdqnIZeW8YpHcA CRC: 531123922 --><a id="Com" name="Step4"></a>
+<p>
+ Once agreed upon by the stakeholders, the vision is communicated clearly to all project team members. When the project
+ starts, XP teams often write up the vision on one of the whiteboards in the team's open workspace so it can easily be
+ seen by all team members. After a short time, the team usually internalizes the vision and no longer needs the
+ reminder.
+</p><!-- END:sectionDescription,_oB58M2E-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/estimate_task.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/estimate_task.html
new file mode 100644
index 0000000..3d9126b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/estimate_task.html
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\estimate_task.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: estimate_task.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{EC483990-8129-4AE3-893C-0F7406C128DA} CRC: 2091979249 -->Estimate Task<!-- END:presentationName,{EC483990-8129-4AE3-893C-0F7406C128DA} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-9EbmL3qGJ_TemB83cJublQ CRC: 1680590692 --><a id="XE_estimate_task__activity_definition" name="XE_estimate_task__activity_definition"></a>
+<ul>
+ <li>
+ Provide a fine-grain estimate that will be used in iteration planning.
+ </li>
+</ul><!-- END:purpose,-9EbmL3qGJ_TemB83cJublQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCfyEmE-EdqnIZeW8YpHcA CRC: 2976963306 -->Understand the Task <!-- END:name,_oCfyEmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCfyEmE-EdqnIZeW8YpHcA CRC: 3024041433 --><a id="Step1" name="Step1"></a>
+<p>
+ Task breakdown of a user story is done at iteration planning by the whole team. Since all team members are present,
+ they should have a fairly good understanding of the tasks. If not, the team is there to help them.
+</p><!-- END:sectionDescription,_oCfyEmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCfyE2E-EdqnIZeW8YpHcA CRC: 940775082 -->Give an Estimate Based on Experience <!-- END:name,_oCfyE2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCfyE2E-EdqnIZeW8YpHcA CRC: 2716501752 --><a id="Step3" name="Step2"></a>
+<p>
+ The person giving the estimate can use his personal experience to give an estimate based on a similar task he has done
+ before. If the experience is not there, other team members can help by providing their input based on their own
+ experience. Very often, pairs will form for specific tasks at this stage. The most important aspect to keep in mind is
+ that the person responsible for the task is the one giving the estimate.
+</p><!-- END:sectionDescription,_oCfyE2E-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/estimate_user_story.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/estimate_user_story.html
new file mode 100644
index 0000000..4d30e0e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/estimate_user_story.html
@@ -0,0 +1,98 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\estimate_user_story.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: estimate_user_story.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{23A924D3-5989-40DD-86A9-9D8FCFB8AE52} CRC: 81155209 -->Estimate User Story<!-- END:presentationName,{23A924D3-5989-40DD-86A9-9D8FCFB8AE52} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-Z9xFd9JTnJuNN5S27p06UQ CRC: 1055660372 --><a id="XE_estimate_user_story__activity_definition" name="XE_estimate_user_story__activity_definition"></a>
+<ul>
+ <li>
+ Provide a high-level estimate that will be used in release planning.
+ </li>
+</ul><!-- END:purpose,-Z9xFd9JTnJuNN5S27p06UQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEqVQGE-EdqnIZeW8YpHcA CRC: 1251240587 --> Understand the User Story <!-- END:name,_oEqVQGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEqVQGE-EdqnIZeW8YpHcA CRC: 1827737621 --><a id="Step1" name="Step1"></a>
+<p>
+ To provide an estimate that is fairly accurate, the developers need to have a good grasp of the story. During release
+ planning, the customer describes each user story and presents acceptance test criteria. The developers can ask
+ questions until they are satisfied that they understand the most important aspects of what the customer is asking for.
+ Avoid analysis paralysis; there are many stories.
+</p><!-- END:sectionDescription,_oEqVQGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEqVQWE-EdqnIZeW8YpHcA CRC: 2107401795 --> Discuss Possible Implementations <!-- END:name,_oEqVQWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEqVQWE-EdqnIZeW8YpHcA CRC: 713643052 --><a id="Step2" name="Step2"></a>
+<p>
+ Sometimes the team can just estimate the story from their gut. Other times the story may not quite fit prior
+ experiences, and the team may have to explore potential design alternatives. Do not settle on a specific design. If
+ competing ideas take about the same amount of time, pick an estimate and move on to the next story. Avoid analysis
+ paralysis; there are many stories.
+</p>
+<p>
+ When there is deep uncertainty, the team can request the time to do some research (spike) in order to give a more
+ realistic estimate.
+</p><!-- END:sectionDescription,_oEqVQWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEqVQmE-EdqnIZeW8YpHcA CRC: 875500262 --> Give an Estimate Based on Experience <!-- END:name,_oEqVQmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEqVQmE-EdqnIZeW8YpHcA CRC: 210003628 --><a id="Step3" name="Step3"></a>
+<p>
+ If the team has done similar work before, they simply extrapolate from previous work. For work the team is unfamiliar
+ with, a spike can provide just enough information to know what is possible and how long the effort is likely to last.
+ An experienced XP team can estimate most stories in a few minutes or less. Avoid analysis paralysis; there are many
+ stories.
+</p><!-- END:sectionDescription,_oEqVQmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oEqVQ2E-EdqnIZeW8YpHcA CRC: 2082778146 --> Ask the Customer to Split the Story <!-- END:name,_oEqVQ2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oEqVQ2E-EdqnIZeW8YpHcA CRC: 1190789255 --><a id="Ask" name="Ask"></a>
+<p>
+ Story estimates should not exceed the iteration duration for a pair of programmers. If the estimate is too big, have
+ the customer split the story. People are better at estimating smaller pieces of work. Long estimates tend to go over
+ budget. It would not be uncommon to take a four-week story and break it down only to discover it is four two-week
+ stories.
+</p><!-- END:sectionDescription,_oEqVQ2E-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/explain_process.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/explain_process.html
new file mode 100644
index 0000000..d3ddd57
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/explain_process.html
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\explain_process.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: explain_process.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727} CRC: 1703319097 -->Explain Process<!-- END:presentationName,{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-I3yOxhkbTu3OCbzQ0sUsyA CRC: 3416146582 --><a id="XE_explain_process__activity_definition" name="XE_explain_process__activity_definition"></a>
+<ul>
+ <li>
+ Make sure the team has a common understanding of the fundamentals.
+ </li>
+</ul><!-- END:purpose,-I3yOxhkbTu3OCbzQ0sUsyA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oNuxsGE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oNuxsGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oNuxsGE-EdqnIZeW8YpHcA CRC: 241691899 --><a id="Prep" name="Prep"></a>
+<p>
+ As a team begins to use the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>, the coach must prepare the team to use the practices effectively.
+</p>
+<p>
+ This includes the following:
+</p>
+<ul>
+ <li>
+ Teach the team about XP and ensure that the team has a common understanding of the practices.
+ </li>
+ <li>
+ Facilitate the team's decision as to how aggressively the transition to the new practices will be.
+ </li>
+ <li>
+ Facilitate a team activity to identify what obstacles they will face in using the practices effectively. Ensure
+ that the team has a plan to overcome those obstacles.
+ </li>
+ <li>
+ Facilitate a team activity to identify what constraints will require adaptation of the practices. Ensure that these
+ adaptations are understood by the <a class="elementLink"
+ href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole
+ Team</a>.
+ </li>
+</ul>
+<p>
+ Because there are many roles in the team, a coach needs to have a good understanding of the all different activities in
+ the process. In some cases, there might be more than one coach on a team to address needs. There might be a coach for
+ the developer team and one for the customer team, for example.
+</p>
+<p>
+ Use external expertise as necessary to ensure the team starts with a strong base of knowledge on which to succeed.
+</p><!-- END:sectionDescription,_oNuxsGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/implement_spike.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/implement_spike.html
new file mode 100644
index 0000000..db86586
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/implement_spike.html
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\implement_spike.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: implement_spike.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{85BE1C0E-F389-4246-BB22-9A52988018B7} CRC: 3859693007 -->Implement Spike<!-- END:presentationName,{85BE1C0E-F389-4246-BB22-9A52988018B7} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-DbsgXRUjLhsnnpioGI2b3g CRC: 3266887289 --><a id="XE_implement_spike__activity_definition" name="XE_implement_spike__activity_definition"></a>
+<ul>
+ <li>
+ Research a missing piece of information.
+ </li>
+</ul><!-- END:purpose,-DbsgXRUjLhsnnpioGI2b3g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCl4sGE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oCl4sGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCl4sGE-EdqnIZeW8YpHcA CRC: 319117512 --><a id="Prep" name="Prep"></a>
+<p>
+ A spike is an experiment. It helps the team find some bit of information it is missing in order to go forward. As such,
+ spikes are an important tool to minimize project risks.
+</p>
+<p>
+ Spikes are very often called for during the planning process when the team is unsure about how long particular stories
+ will take. In this case, the spike consists of trying out different ways of implementing the story. The team will do
+ the bare minimum to gain an understanding of how to do the story so that they can provide a reasonable estimate. Very
+ often, the code generated by spikes is literally thrown away. The value of the spike is in the information that was
+ missing, namely a good estimate in this case.
+</p>
+<p>
+ <br />
+
+</p><!-- END:sectionDescription,_oCl4sGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/improve_team_skills.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/improve_team_skills.html
new file mode 100644
index 0000000..920cae2
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/improve_team_skills.html
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\improve_team_skills.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: improve_team_skills.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{1C4325AC-17DE-4CD0-8AA0-4B210570579F} CRC: 1025171830 -->Improve Team Skills<!-- END:presentationName,{1C4325AC-17DE-4CD0-8AA0-4B210570579F} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-32JWpciwfc2e7HgQavJDkw CRC: 694350008 --><a id="XE_improve_team_skills__activity_definition" name="XE_improve_team_skills__activity_definition"></a>
+<ul>
+ <li>
+ Help the team members identify skills that need improvement and implement activities to improve those skills.
+ </li>
+</ul><!-- END:purpose,-32JWpciwfc2e7HgQavJDkw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oNuxsWE-EdqnIZeW8YpHcA CRC: 2262641835 -->General <!-- END:name,_oNuxsWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oNuxsWE-EdqnIZeW8YpHcA CRC: 3647953136 --><a id="Prep" name="Prep"></a>
+<p>
+ Teams are made up of individuals with an imperfect balance of technical expertise, domain or customer awareness, and
+ people skills. The team must continually identify and improve those skill areas that are lacking. The XP Coach helps
+ ensure that this happens.
+</p>
+<p>
+ The coach must always be aware of what difficulties the team is having in succeeding on their project. Some of these
+ will be evident, often communicated directly by the team. Some will be subtle with little awareness on the team that
+ there is a problem. To maintain this awareness, the coach must balance time spent in the trenches with the team,
+ observing specific use of the practices, with time spent reflecting on the team's capabilities, unencumbered by the
+ direct pressures of the project.
+</p>
+<p>
+ With an awareness of where the team needs improvement, the coach must help the team integrate improvement activities
+ into their work. Improvement activities need to be prioritized just as User Stories do. Different options will exist to
+ address skill improvement needs. The coach should be familiar with a wide variety of activities, courses, and games to
+ help people further their skills in a given practice. The coach acts as a conduit that connects the team with the
+ expertise required to improve a skill whether that other resource is in the organization or is an external resource.
+</p>
+<p>
+ One of the most effective tools to help the team identify areas for improvement is the Retrospective, a form of project
+ review. Techniques for this are described in Norm Kerth's book, <i>Project Retrospectives</i> [<a
+ class="elementLinkWithUserText"
+ href="./../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#KER01"
+ guid="6.191633934532389E-306">KER01</a>]. Many teams have adapted the tools from the book to perform abbreviated
+ retrospectives after each iteration in addition to the more comprehensive session held at the completion of a full
+ project.
+</p><!-- END:sectionDescription,_oNuxsWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/integrate_system.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/integrate_system.html
new file mode 100644
index 0000000..8b05f3c
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/integrate_system.html
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\integrate_system.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: integrate_system.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{70FEC254-8555-4844-AD82-68367E25F082} CRC: 3886483177 -->Integrate and Build<!-- END:presentationName,{70FEC254-8555-4844-AD82-68367E25F082} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,--tP2hgRfEkZPGYvy1y0GZQ CRC: 1359296844 --><a id="XE_integrate_and_build__activity_definition" name="XE_integrate_and_build__activity_definition"></a>
+<ul>
+ <li>
+ To produce a runnable executable of the application under development that can be used to evaluate progress and
+ provide feedback
+ </li>
+</ul><!-- END:purpose,--tP2hgRfEkZPGYvy1y0GZQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oE9QMGE-EdqnIZeW8YpHcA CRC: 851040656 --> Run All Unit Tests for the System <!-- END:name,_oE9QMGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oE9QMGE-EdqnIZeW8YpHcA CRC: 873258984 --><a id="Step1" name="Step1"></a>
+<p>
+ While you and your pair partner are working on a task, you run unit tests to make sure you are not introducing side
+ effect defects. As a system evolves, it may become impractical to run all the unit tests for the system for every
+ change made. In this case, you may choose a subset of the unit tests to run after every code change. When a task is
+ completed or you feel that you have a piece you can integrate or you are uncertain for any reason, run all of the unit
+ tests for the system.
+</p><!-- END:sectionDescription,_oE9QMGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oE9QMWE-EdqnIZeW8YpHcA CRC: 3886211169 --> Check in Code <!-- END:name,_oE9QMWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oE9QMWE-EdqnIZeW8YpHcA CRC: 2110781309 --><a id="Step2" name="Step2"></a>
+<p>
+ If all of the unit test in the system passed, check in your code and produce a system build.
+</p><!-- END:sectionDescription,_oE9QMWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/keep_process_on_track.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/keep_process_on_track.html
new file mode 100644
index 0000000..8f1f04b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/keep_process_on_track.html
@@ -0,0 +1,57 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\keep_process_on_track.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: keep_process_on_track.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{80725BC3-E2BA-4860-8F07-4A34B96FBB2A} CRC: 3886017901 -->Keep Process On Track<!-- END:presentationName,{80725BC3-E2BA-4860-8F07-4A34B96FBB2A} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-SH3UFVsPViLT3hOalbaxgA CRC: 3192811429 --><a id="XE_keep_process_on_track__activity_definition" name="XE_keep_process_on_track__activity_definition"></a>
+<ul>
+ <li>
+ Ensure the process is being used effectively towards the project goals.
+ </li>
+</ul><!-- END:purpose,-SH3UFVsPViLT3hOalbaxgA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oN04UGE-EdqnIZeW8YpHcA CRC: 2262641835 -->General <!-- END:name,_oN04UGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oN04UGE-EdqnIZeW8YpHcA CRC: 553065412 --><a id="Prep" name="Prep"></a>
+<p>
+ The <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a> needs to be very focused on the goals of the project. The development
+ practices enable the project goals to be achieved. The challenge of focusing on the project goals and focusing the
+ disciplined and effective use of the practices is a constant challenge for the team.
+</p>
+<p>
+ The <a class="elementLink" href="./../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
+ guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a> collects data and reports it to the team. This data
+ provides guidance as to whether the project is on a trajectory to meet the project goals. The data also monitors the
+ team's use of the practices.
+</p>
+<p>
+ The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> ensures that the team is collecting and using the data to
+ ensure that the project and process goals are achieved.
+</p><!-- END:sectionDescription,_oN04UGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/refactor_code.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/refactor_code.html
new file mode 100644
index 0000000..9f1eaca
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/refactor_code.html
@@ -0,0 +1,95 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\refactor_code.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: refactor_code.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{3DD335BB-45F6-49C7-B17A-90652C73A485} CRC: 290796006 -->Refactor Code<!-- END:presentationName,{3DD335BB-45F6-49C7-B17A-90652C73A485} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-IoT5LZUu3vnNFp-pwPUMHA CRC: 2293432397 --><a id="XE_refactor_code__activity_definition" name="XE_refactor_code__activity_definition"></a>
+<ul>
+ <li>
+ To keep the design of the system clear and ready for change.
+ </li>
+</ul><!-- END:purpose,-IoT5LZUu3vnNFp-pwPUMHA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCr_UGE-EdqnIZeW8YpHcA CRC: 3304100054 -->Identify Poor Design <!-- END:name,_oCr_UGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCr_UGE-EdqnIZeW8YpHcA CRC: 1713901318 --><a id="Step1" name="Step1"></a>
+<p>
+ While developing, requirements change and previous design decisions can be invalidated. A new feature is added, you get
+ it to work, but the structure and clarity of the code can degrade. You could leave it, and the design will slowly rot,
+ or you could improve the design on the spot. Refactoring is about improving the design.
+</p>
+<p>
+ A simple design has these four characteristics, listed in priority order:
+</p>
+<ul>
+ <li>
+ The system runs all the tests.
+ </li>
+ <li>
+ It contains no duplicate code.
+ </li>
+ <li>
+ The code states the programmers' intent very clearly.
+ </li>
+ <li>
+ It contains the fewest possible number of classes and methods.
+ </li>
+</ul>
+<p>
+ A good resource for gaining refactoring knowledge is Martin Fowler's book: <i>Refactoring - Improving the Design of
+ Existing Code</i> [<a class="elementLinkWithUserText"
+ href="./../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#FOW99"
+ guid="6.191633934532389E-306">FOW99</a>]. Martin discusses the idea of bad code smells, how to detect them, what harm
+ they will do to your software, and how to fix them.
+</p>
+<p>
+ During development, you should look at the code refactoring with an open mind and find its weaknesses. Clarify the
+ code; fix what needs to be fixed. As you discover these smells, you should work to eliminate them before proceeding to
+ the next test case. Save some time before you check-in your code to step back and look it over. Identify duplicate code
+ sections and places where the design intent is not clear.
+</p><!-- END:sectionDescription,_oCr_UGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oCr_UWE-EdqnIZeW8YpHcA CRC: 1447820118 -->Refactor <!-- END:name,_oCr_UWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oCr_UWE-EdqnIZeW8YpHcA CRC: 2738256427 --><a id="Step2" name="Step2"></a>
+<p>
+ Refactoring involves making changes to your code which improve its structure without modifying its behavior. Martin
+ Fowler's Refactoring book lists over sixty refactorings to handle particular code situations. The goal of each of them
+ is to reduce duplication in the code base and increase clarity. Leave your code clean, simple, and free from
+ duplication.
+</p>
+<p>
+ As the structure of your code base evolves, you choose names which aid your understanding of the functionality
+ specified by the code. This system of names becomes the vocabulary for your team's discussion of design.
+</p><!-- END:sectionDescription,_oCr_UWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/report_acceptance_test_result.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/report_acceptance_test_result.html
new file mode 100644
index 0000000..8057ba5
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/report_acceptance_test_result.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\report_acceptance_test_result.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: report_acceptance_test_result.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{52D6E875-C46B-454B-A39C-CEC21603AF5C} CRC: 1101226338 -->Report Customer Test Result<!-- END:presentationName,{52D6E875-C46B-454B-A39C-CEC21603AF5C} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-p0GGwGNG5O8Dn6O6ZzivIw CRC: 3376586802 --><a id="XE_report_customer_test_result__activity_definition" name="XE_report_customer_test_result__activity_definition"></a>
+<ul>
+ <li>
+ Provide the team with a clear understanding of progress.
+ </li>
+</ul><!-- END:purpose,-p0GGwGNG5O8Dn6O6ZzivIw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oH6dkGE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oH6dkGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oH6dkGE-EdqnIZeW8YpHcA CRC: 3446252978 --><a id="Prep" name="Prep"></a>
+<p>
+ This activity communicates to the whole team the progress they have made. As this is a major factor in motivation, XP
+ teams very often use big, visible charts to show their progress. These charts are very often placed in the open
+ workspace and visible to anyone who enters the team area.
+</p>
+<p>
+ A suitable chart would track the number of customer tests defined and running by iteration. The vertical axis is the
+ number of tests; the horizontal axis is the iteration number.
+</p><!-- END:sectionDescription,_oH6dkGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/report_project_status.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/report_project_status.html
new file mode 100644
index 0000000..b9b8a1f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/report_project_status.html
@@ -0,0 +1,88 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\report_project_status.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: report_project_status.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{ED94150E-EE14-47BF-97F5-F1EC7130EEEC} CRC: 702333934 -->Report Project Status<!-- END:presentationName,{ED94150E-EE14-47BF-97F5-F1EC7130EEEC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-WOPGmKUuYbvVeVHp0sgEgw CRC: 1586515470 --><a id="XE_report_project_status__activity_definition" name="XE_report_project_status__activity_definition"></a>
+<ul>
+ <li>
+ Communicate to stakeholders the status of the project.
+ </li>
+</ul><!-- END:purpose,-WOPGmKUuYbvVeVHp0sgEgw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOzvwGE-EdqnIZeW8YpHcA CRC: 2821216099 -->Gather the Information <!-- END:name,_oOzvwGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOzvwGE-EdqnIZeW8YpHcA CRC: 1790456290 --><a id="Step1" name="Step1"></a>
+<p>
+ The most important information about the status of the project is the updated release plan. The release plan defines
+ the current view of the release content and availability. Metrics, such as the team's velocity, can also be provided.
+ Typically, metrics are tracked for the purpose of helping the team improve some aspects of development they are having
+ problems with. These metrics can be presented as part of project status.
+</p>
+<p>
+ The velocity metric can be abused. Keep in mind that there is no valid comparison of velocities between teams. The most
+ important thing about a team's velocity is the stability of the velocity. This allows the team to predict what it can
+ accomplish.
+</p>
+<p>
+ Other meaningful metrics:
+</p>
+<ul>
+ <li>
+ Defined stories over time, overlaid with completed stories
+ </li>
+ <li>
+ Defined customer tests overlaid with running customer tests
+ </li>
+ <li>
+ Number of unit tests tracked over time
+ </li>
+ <li>
+ Unit test coverage
+ </li>
+</ul>
+<p>
+ The team's significant metrics are recorded on flip chart paper and hung in the team's open workspace.
+</p><!-- END:sectionDescription,_oOzvwGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOzvwWE-EdqnIZeW8YpHcA CRC: 2546145039 --> Communicate the Status <!-- END:name,_oOzvwWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOzvwWE-EdqnIZeW8YpHcA CRC: 650594538 --><a id="Step2" name="Step2"></a>
+<p>
+ Since outside stakeholders do not participate in the daily activities of the team, it is important that the status of
+ the project should be communicated to them as often as possible. It lowers significantly the risk of disconnect between
+ the development team and the stakeholders. It also provides the team with data they can use to improve their
+ development process. Stakeholders should come to the open workspace and view the project status that is recorded on the
+ walls of the open workspace. They can experience the progress being made by the team first hand.
+</p><!-- END:sectionDescription,_oOzvwWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/resolve_conflicts.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/resolve_conflicts.html
new file mode 100644
index 0000000..7aa196f
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/resolve_conflicts.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\resolve_conflicts.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: resolve_conflicts.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{1B23700D-02B0-476F-A3DE-6F63A5407151} CRC: 3515262353 -->Resolve Conflicts<!-- END:presentationName,{1B23700D-02B0-476F-A3DE-6F63A5407151} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-L85wOCiwe2O8D8CISEGGGg CRC: 3960961793 --><p>
+ Software projects require the coordinated efforts of many people. The <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a> leverage the ability of teams to collaborate and communicate about decisions and activities on the
+ project. Because team members are working together in an <a class="elementLink"
+ href="./../../xp/guidances/guidelines/open_workspace,3.269440809144354E-305.html" guid="3.269440809144354E-305">Open
+ Workspace</a>, interpersonal conflicts are visible, not hidden by the separation of the cubicles. One byproduct of
+ increased collaboration, communication, and feedback will be increased conflict. Unmanaged, this conflict may increase
+ the risk to the project. XP, as a process, does not try to solve all of the problems that occur on a software project,
+ it just enables the people to solve them.
+</p>
+<p>
+ The XP Coach must make sure these conflicts are managed. The coach must help the team develop an environment of
+ openness, where conflicts can be discussed and resolved. Conflicts left unresolved, like defects left undetected, are
+ usually more disruptive and ultimately costly to fix. At times, the coach will take ownership to resolve a conflict on
+ the team or across teams, but over time, the coach must ensure that the team is capable of resolving most conflicts on
+ their own.
+</p><!-- END:mainDescription,-L85wOCiwe2O8D8CISEGGGg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-L85wOCiwe2O8D8CISEGGGg CRC: 1704345964 --><a id="XE_resolve_conflicts__activity_definition" name="XE_resolve_conflicts__activity_definition"></a>
+<ul>
+ <li>
+ Prevent disagreements from reducing the team's productivity.
+ </li>
+</ul><!-- END:purpose,-L85wOCiwe2O8D8CISEGGGg -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/run_acceptance_test.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/run_acceptance_test.html
new file mode 100644
index 0000000..eaa9f84
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/run_acceptance_test.html
@@ -0,0 +1,45 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\run_acceptance_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: run_acceptance_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{D4E30732-30D3-4C75-8C69-D2F15313F1A9} CRC: 2072435102 -->Run Customer Test<!-- END:presentationName,{D4E30732-30D3-4C75-8C69-D2F15313F1A9} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-6RyabSc-ZUEtoEKb90BCbg CRC: 243862668 --><a id="XE_run_customer_test__activity_definition" name="XE_run_customer_test__activity_definition"></a>
+<ul>
+ <li>
+ Execute the automated acceptance test and gather results.
+ </li>
+</ul><!-- END:purpose,-6RyabSc-ZUEtoEKb90BCbg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oNI70GE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oNI70GE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oNI70GE-EdqnIZeW8YpHcA CRC: 578935055 --><p>
+ This task consists of running all the customer or acceptance tests to ensure that all previously completed user stories
+ are still working. A lot of XP teams run those tests on a daily basis as part of their automated daily build. Other
+ teams run those tests every time a new story is added to the pool of completed stories to ensure that a new story has
+ not caused previous ones to fail.
+</p><!-- END:sectionDescription,_oNI70GE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/setup_programmer_environment.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/setup_programmer_environment.html
new file mode 100644
index 0000000..5321f3d
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/setup_programmer_environment.html
@@ -0,0 +1,99 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\setup_programmer_environment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: setup_programmer_environment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{D3AA9FEE-AAD9-4884-BF71-425E122110A7} CRC: 2363565485 -->Setup Programmer Environment<!-- END:presentationName,{D3AA9FEE-AAD9-4884-BF71-425E122110A7} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-1rVEQRCvrcicCdhpuuIZ8w CRC: 1435063095 --><a id="XE_setup_programmer_environment__activity_definition"
+name="XE_setup_programmer_environment__activity_definition"></a>
+<ul>
+ <li>
+ To make it easy to work collaboratively and raise the communication level of the team
+ </li>
+</ul><!-- END:purpose,-1rVEQRCvrcicCdhpuuIZ8w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oPGqsGE-EdqnIZeW8YpHcA CRC: 363052505 -->Remove Cubicle Walls and Other Impediments <!-- END:name,_oPGqsGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oPGqsGE-EdqnIZeW8YpHcA CRC: 3033019023 --><a id="Step1" name="Step1"></a>
+<p>
+ In XP, we attempt to maximize communication within the team. Programmers should be able to ask quick questions to
+ other developers and overhear conversations which raise their understanding of the system. When team members are
+ segregated into offices or cubicles, there is more of a chance that islands of knowledge will grow in isolation. This
+ leads to redundant work and often work that is less integrated than if it had been done in an open space subject to the
+ contributions of overhearing team members.
+</p><!-- END:sectionDescription,_oPGqsGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oPNYYGE-EdqnIZeW8YpHcA CRC: 3446657757 -->Place Computers in Positions Comfortable for Pairing <!-- END:name,_oPNYYGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oPNYYGE-EdqnIZeW8YpHcA CRC: 2802285974 --><a id="Step2" name="Step2"></a>
+<p>
+ Standard office furniture is not designed for pair programming. In particular, desks with leg wells seem to make
+ pairing impossible. Ideally, computers should be placed on tables which have enough room for two people to sit side by
+ side and trade turns working at the keyboard. Comfort should be your guide. If you are not comfortable, you will get
+ fatigued easily and you certainly won't be doing the work you are capable of.
+</p><!-- END:sectionDescription,_oPNYYGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oPNYYWE-EdqnIZeW8YpHcA CRC: 3260909039 -->Standardize on Tools and Development Setup <!-- END:name,_oPNYYWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oPNYYWE-EdqnIZeW8YpHcA CRC: 4139936181 --><a id="Step3" name="Step3"></a>
+<p>
+ In XP, we find that work goes better when everyone is able to help everyone else. One simple thing that can get in the
+ way is computer setup. If you use an editor with one set of key bindings and another team member uses another, it will
+ be difficult for either of you to go to each other's computers and feel comfortable enough to drive. While this seems
+ like a minor point, it makes a sizable difference on how effectively a team can collaborate. In many XP teams, machines
+ are unassigned. You simply go to a free machine in the morning and check out the code that you need to start working
+ on.
+</p><!-- END:sectionDescription,_oPNYYWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oPNYYmE-EdqnIZeW8YpHcA CRC: 3816839447 -->Establish Clear Line of Sight to Customer <!-- END:name,_oPNYYmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oPNYYmE-EdqnIZeW8YpHcA CRC: 2980821077 --><a id="Step4" name="Step4"></a>
+<p>
+ To work effectively with XP, you must be able to ask questions to your customer. If you are not able to ask
+ questions and get timely answers, you are either bottlenecked on a task or tempted to guess and hope that you don't
+ have to roll back your work later. When setting up your environment, establish a clear line of sight to the customer.
+ The customer should be working in the same room as the team. If this is not possible, the customer should be no more
+ than a phone call away.
+</p><!-- END:sectionDescription,_oPNYYmE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/setup_tester_environment.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/setup_tester_environment.html
new file mode 100644
index 0000000..8651e6b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/setup_tester_environment.html
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\setup_tester_environment.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: setup_tester_environment.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC} CRC: 3336498004 -->Setup Tester Environment<!-- END:presentationName,{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-OPKuXnenD910fJyGKA99aw CRC: 3310197941 --><a id="XE_setup_tester_environment__activity_definition" name="XE_setup_tester_environment__activity_definition"></a>
+<ul>
+ <li>
+ Create a stable environment for running the customer tests.
+ </li>
+</ul><!-- END:purpose,-OPKuXnenD910fJyGKA99aw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oNI70WE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oNI70WE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oNI70WE-EdqnIZeW8YpHcA CRC: 404483452 --><a id="Prep" name="Prep"></a>
+<p>
+ Testers will need to setup some kind of hardware/software environment in order to run the customer acceptance tests.
+ The environment might require the installation of specific software test tools or the OS might require specific
+ environment settings. Try to replicate as much as possible a typical end-user environment when running the tests. Tests
+ may require setting up multiple environments (when different operating systems are used, for example).
+</p>
+<p>
+ Test environments are not only for testers; it is critical that they are made available to the programmers. Running the
+ acceptance tests is their only way to know whether or not they are through with a story and whether they have broken
+ previous stories or not.
+</p><!-- END:sectionDescription,_oNI70WE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/track_story_completion.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/track_story_completion.html
new file mode 100644
index 0000000..6a23e7e
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/track_story_completion.html
@@ -0,0 +1,52 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\track_story_completion.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: track_story_completion.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{C333BA32-CF6B-4577-9212-302893043EFF} CRC: 3117881737 -->Track Release Progress<!-- END:presentationName,{C333BA32-CF6B-4577-9212-302893043EFF} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-FxF90KOknQ5km30pP0038w CRC: 2256720635 --><a id="XE_track_release_progress__activity_definition" name="XE_track_release_progress__activity_definition"></a>
+<ul>
+ <li>
+ Track the progress of the release.
+ </li>
+</ul><!-- END:purpose,-FxF90KOknQ5km30pP0038w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOHzQGE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oOHzQGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOHzQGE-EdqnIZeW8YpHcA CRC: 439003862 --><a id="Prep" name="Prep"></a>
+<p>
+ Progress in XP is measured in user stories that are passing acceptance tests. A user story is deemed completed when and
+ only when it passes all its acceptance tests. Because customer tests are all automated, this task is actually very
+ simple since it only consists of running the automated acceptance test suite and comparing the results against the
+ plan. If 50% (weighted according to cost) of the stories pass acceptance tests, you are 50% done. Hopefully, less than
+ 50% or less of the release has elapsed. If not, it is an indication that the release plan should be revisited.
+</p>
+<p>
+ On a regular basis, the tracker presents the progress the team is making in the release. This information can be
+ presented in the form of a big, visible chart hanging in the team's open workspace. Progress is often presented as the
+ number of stories done vs. planned for the release.
+</p><!-- END:sectionDescription,_oOHzQGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/track_task_completion.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/track_task_completion.html
new file mode 100644
index 0000000..0863428
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/track_task_completion.html
@@ -0,0 +1,58 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\track_task_completion.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: track_task_completion.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C} CRC: 1488305195 -->Track Iteration Progress<!-- END:presentationName,{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-0iRnQW0M9QDTNqWNijBB5A CRC: 2628535822 --><a id="XE_track_iteration_progress__activity_definition" name="XE_track_iteration_progress__activity_definition"></a>
+<ul>
+ <li>
+ Track the progress during the iteration.
+ </li>
+</ul><!-- END:purpose,-0iRnQW0M9QDTNqWNijBB5A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oON54GE-EdqnIZeW8YpHcA CRC: 2265408975 --> General <!-- END:name,_oON54GE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oON54GE-EdqnIZeW8YpHcA CRC: 185094125 --><a id="Prep" name="Prep"></a>
+<p>
+ Ideally tracking stories is much better than tracking tasks even at the iteration level since the stories can be proved
+ to work through the acceptance tests and tasks can't. However, when there are few stories in the iteration, some teams
+ also use tasks to help them gain a sense of progress.
+</p>
+<p>
+ The tracker simply tracks how many tasks have been done during the iteration and how many are left. This information is
+ readily available during the stand-up meetings. Half way through the iteration, the team should have done about half
+ the tasks (in terms of the task cost estimates). If not, it is a sign that the iteration plan needs some tweaking. If
+ the team is not going as fast as planned, the tweaking may consist of removing one of the stories from the iteration.
+ If they are going faster than planned, then the team can ask the customer to bring a new story into the iteration. This
+ is how the team iteration velocity will fluctuate over time.
+</p>
+<p>
+ On a regular basis, the tracker presents the progress the team is making in the iteration. This information can be
+ presented in the form of a big, visible chart hanging in the team's open workspace. Progress is often presented as the
+ number of tasks or stories done vs. planned for the iteration.
+</p><!-- END:sectionDescription,_oON54GE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/update_iteration_plan.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/update_iteration_plan.html
new file mode 100644
index 0000000..7217970
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/update_iteration_plan.html
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\update_iteration_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: update_iteration_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC} CRC: 3252309485 -->Adjust Iteration Scope<!-- END:presentationName,{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-cU3MzukpGPAtw0wSS23R-g CRC: 3547937407 --><a id="XE_adjust_iteration_scope__activity_definition" name="XE_adjust_iteration_scope__activity_definition"></a>
+<ul>
+ <li>
+ To allow the customer to react to the team underestimating or over estimating the amount of work that can be
+ accomplished in the current iteration.
+ </li>
+</ul><!-- END:purpose,-cU3MzukpGPAtw0wSS23R-g -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOzvwmE-EdqnIZeW8YpHcA CRC: 2821216099 -->Gather the Information <!-- END:name,_oOzvwmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOzvwmE-EdqnIZeW8YpHcA CRC: 3596746348 --><a id="Step1" name="Step1"></a>
+<p>
+ The team is responsible for keeping track of its project. Tasks that are completed are marked on the iteration plan. If
+ anyone on the team realizes that the team is behind schedule, at any time, the customer is informed as soon as
+ possible. The customer can then decide how to change the plan. The tracker may be the first to notice that the
+ iteration is in jeopardy. An XP team is considered behind schedule if half the work is not finished halfway through the
+ iteration. Ideally, this could be measured by observing that half the customer tests pass halfway through the
+ iteration.
+</p><!-- END:sectionDescription,_oOzvwmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOzvw2E-EdqnIZeW8YpHcA CRC: 3890482022 -->Update the Plan <!-- END:name,_oOzvw2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOzvw2E-EdqnIZeW8YpHcA CRC: 3160385937 --><a id="Step2" name="Step2"></a>
+<p>
+ When it is likely that not all the stories in the release will be finished, the customer must reduce scope. Extending
+ the iteration is not an option. The customer either removes whole stories or splits stories and removes scope.
+</p>
+<p>
+ When the team has excess capacity in the iteration, the customer is informed. The customer adds additional stories to
+ fill the iteration . Customers like it when this happens.
+</p><!-- END:sectionDescription,_oOzvw2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oOzvxGE-EdqnIZeW8YpHcA CRC: 3002902895 -->Communicate the Plan <!-- END:name,_oOzvxGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oOzvxGE-EdqnIZeW8YpHcA CRC: 3491278472 --><a id="Step3" name="Step3"></a>
+<p>
+ The whole team should be made aware of any changes in the iteration plan so they can focus on the right tasks.
+</p><!-- END:sectionDescription,_oOzvxGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/update_release_plan.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/update_release_plan.html
new file mode 100644
index 0000000..ae99a9d
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/update_release_plan.html
@@ -0,0 +1,81 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\update_release_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: update_release_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{18BF87E6-5849-4091-AFE2-FC4F0C3887B1} CRC: 1353023376 -->Revise Release Plan<!-- END:presentationName,{18BF87E6-5849-4091-AFE2-FC4F0C3887B1} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-YO16TebjP7U0gkcYg7OY_A CRC: 274809210 --><a id="XE_revise_release_plan__activity_definition" name="XE_revise_release_plan__activity_definition"></a>
+<ul>
+ <li>
+ Ensure the release plan reflects our improved understanding of the coming releases.
+ </li>
+</ul><!-- END:purpose,-YO16TebjP7U0gkcYg7OY_A -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oO6dcGE-EdqnIZeW8YpHcA CRC: 2821216099 -->Gather the Information <!-- END:name,_oO6dcGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oO6dcGE-EdqnIZeW8YpHcA CRC: 3859881923 --><a id="Step1" name="Step1"></a>
+<p>
+ The most recent count of completed story points in an iteration is the team's velocity. The number of story points
+ completed in an iteration will change over time. Consequently, the team's velocity also changes. If the team's velocity
+ increases, more work can be done in each iteration. If the team's velocity decreases, less work can be done in each
+ iteration.
+</p>
+<p>
+ As the team progresses through the project, the team's understanding of the problem is improved. Customers will add new
+ stories and remove others. Programmers may need to change story estimates. Consequently, the release plan should be
+ revisited periodically (every few iterations or as needed).
+</p><!-- END:sectionDescription,_oO6dcGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oO6dcWE-EdqnIZeW8YpHcA CRC: 3890482022 -->Update the Plan <!-- END:name,_oO6dcWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oO6dcWE-EdqnIZeW8YpHcA CRC: 721263950 --><a id="Step2" name="Step2"></a>
+<p>
+ Using the most recent velocity, the latest story estimates, and the customer's most recent view of priority, a new
+ release plan is established.
+</p><!-- END:sectionDescription,_oO6dcWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oO6dcmE-EdqnIZeW8YpHcA CRC: 3002902895 -->Communicate the Plan <!-- END:name,_oO6dcmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oO6dcmE-EdqnIZeW8YpHcA CRC: 666805432 --><a id="Step3" name="Step3"></a>
+<p>
+ Once the plan is updated, it is critical that the whole team be aware of it. This is usually really easy as the whole
+ team was involved in the revision of the release plan. The plan will show the team the progress they are making
+ (morale), and they will have a clear understanding of the new target they are shooting for (team cohesion).The plan
+ must be realistic and alive.
+</p><!-- END:sectionDescription,_oO6dcmE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/write_code.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/write_code.html
new file mode 100644
index 0000000..e25f68b
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/write_code.html
@@ -0,0 +1,111 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\write_code.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: write_code.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{8F6CB99A-D2EA-44BB-8CE5-F97220D44088} CRC: 3725566187 -->Write Code<!-- END:presentationName,{8F6CB99A-D2EA-44BB-8CE5-F97220D44088} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-kNZQ2Mr_nyfmCboprjMNTg CRC: 3261426090 --><a id="XE_write_code__activity_definition" name="XE_write_code__activity_definition"></a>
+<ul>
+ <li>
+ To specify the design of the system in a way which is precise enough to allow computers to generate efficient
+ processes automatically and clear enough for people to understand during ongoing work and maintenance.
+ </li>
+</ul><!-- END:purpose,-kNZQ2Mr_nyfmCboprjMNTg -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oUbPkGE-EdqnIZeW8YpHcA CRC: 835369410 --> Get a Pair Programming Partner <!-- END:name,_oUbPkGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oUbPkGE-EdqnIZeW8YpHcA CRC: 527002794 --><a id="Step1" name="Step1"></a>
+<p>
+ Pair Programming is an Extreme Programming best practice. The basic rule regarding pair programming in XP is that all
+ production code is developed in pairs. One programmer has the responsibility to complete a task. That programmer asks
+ other programmers to pair with him to complete the task. The pairings are short term, usually less than half a day.
+ Find a partner who has experience or skill you need to complete your task. Your task may include modifying a database
+ table. Ask the person on the team most knowledgeable to help you effectively use the database API. Later, you might
+ need to display the data in a GUI window, but you have not seen that part of the GUI. Get someone who knows about it to
+ help.
+</p><!-- END:sectionDescription,_oUbPkGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oUbPkWE-EdqnIZeW8YpHcA CRC: 4082082900 --> Write Failing Test Case <!-- END:name,_oUbPkWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oUbPkWE-EdqnIZeW8YpHcA CRC: 155191086 --><a id="Step2" name="Step2"></a>
+<p>
+ When looking at an Engineering Task, you should consider how to add the capability to the system. Does the system
+ require new classes? Are there classes that would be useful? Regardless of how these decisions come out, the addition
+ of functionality requires the creation of a test case. You write the test case to demonstrate that a portion of the
+ functionality you need isn't in the system. This test case should fail.
+</p><!-- END:sectionDescription,_oUbPkWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oUbPkmE-EdqnIZeW8YpHcA CRC: 1522612366 --> Write Code to Make Tests Pass <!-- END:name,_oUbPkmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oUbPkmE-EdqnIZeW8YpHcA CRC: 2697689831 --><a id="Step3" name="Step3"></a>
+<p>
+ When you have a failing test case, you then write only the code that is necessary to satisfy the test case. Test cases
+ should have a very narrow focus. A failing test case may trigger the creation of a new class or method named in the
+ test case, or it may simply require you to add more code to existing classes and methods.
+</p><!-- END:sectionDescription,_oUbPkmE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oUbPk2E-EdqnIZeW8YpHcA CRC: 224726104 --> Refactor Immediately <!-- END:name,_oUbPk2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oUbPk2E-EdqnIZeW8YpHcA CRC: 1118730165 --><a id="Step4" name="Step4"></a>
+<p>
+ After the test case passes, go back and make the code as clean as possible. Have you added code to a method and caused
+ the method to have more than one primary job? If so, extract a method. Has a class grown too large? Consider extracting
+ a class. Have you noticed duplication? Refactor to remove it.
+</p><!-- END:sectionDescription,_oUbPk2E-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oUbPlGE-EdqnIZeW8YpHcA CRC: 2875719903 --> Repeat Until Engineering Task is Done <!-- END:name,_oUbPlGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oUbPlGE-EdqnIZeW8YpHcA CRC: 3912628763 --><a id="Step5" name="Step5"></a>
+<p>
+ The preceding three steps should be done in sequence over and over until you and your pair partner are done with the
+ engineering task. It is important to refactor as you go because refactoring, even on a micro-scale, makes additional
+ work easier.
+</p><!-- END:sectionDescription,_oUbPlGE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/tasks/write_user_story.html b/XP/XP_baseline_EN/exported_HTML/xp/tasks/write_user_story.html
new file mode 100644
index 0000000..7726356
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/tasks/write_user_story.html
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\tasks\write_user_story.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: write_user_story.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{62CFC55C-3151-46CB-8886-F3DBD552ABC4} CRC: 2275206683 -->Write User Story<!-- END:presentationName,{62CFC55C-3151-46CB-8886-F3DBD552ABC4} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-cqTu_uwmZrF3sFspx465XQ CRC: 4107200870 --><a id="XE_write_user_story__activity_definition" name="XE_write_user_story__activity_definition"></a>
+<ul>
+ <li>
+ To specify a specific behavior of the system from a user perspective.
+ </li>
+</ul><!-- END:purpose,-cqTu_uwmZrF3sFspx465XQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQZEIGE-EdqnIZeW8YpHcA CRC: 2663915158 --> Define System Behavior <!-- END:name,_oQZEIGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQZEIGE-EdqnIZeW8YpHcA CRC: 4265570140 --><a id="Step1" name="Step1"></a>
+<p>
+ A user story is a brief description of a feature of the system. Stories are small, taking only a week or two to
+ develop. The best stories provide direct business value. When stories are too big, they must be split. Consequently, it
+ may take multiple stories to provide business value. In this case, the individual stories need to demonstrate to the
+ customer that the team is making progress toward the desired business value.
+</p>
+<p>
+ There is no need for a lot of detail in the description. The details will be flushed out when the acceptance tests for
+ this story are defined. Typically, XP user stories are written on small index cards, one story per card.
+</p><!-- END:sectionDescription,_oQZEIGE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: name<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:name,_oQZEIWE-EdqnIZeW8YpHcA CRC: 3690582602 --> Define Customer Test <!-- END:name,_oQZEIWE-EdqnIZeW8YpHcA -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: sectionDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:sectionDescription,_oQZEIWE-EdqnIZeW8YpHcA CRC: 3641822092 --><a id="Step2" name="Step2"></a>
+<p>
+ Each user story will have a set of conditions or acceptance criteria to fulfill before it is considered done.
+ Basically, an acceptance criterion defines an interaction scenario between the user and the system. There is usually
+ more than one possible scenario or acceptance test criterion for a typical story. The acceptance test criteria are
+ converted into <a class="elementLinkWithUserText"
+ href="./../../xp/tasks/automate_acceptance_test,{E614ED93-AE72-4FD1-B459-C508CE1C536F}.html"
+ guid="{E614ED93-AE72-4FD1-B459-C508CE1C536F}">automated customer tests</a> when the story is being implemented.
+</p>
+<p>
+ For simplicity, the test criteria are often written natural language. However, this makes them prone to
+ misinterpretation. To address this issue, some teams provide simple tools that allow the customer to write the
+ acceptance tests criteria in a form that can be executed directly by application-specific acceptance test framework.
+ Ultimately, it is the responsibility of the customer to provide the customer tests
+</p><!-- END:sectionDescription,_oQZEIWE-EdqnIZeW8YpHcA -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_build.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_build.html
new file mode 100644
index 0000000..13b5cf9
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_build.html
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_build.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_build.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222} CRC: 2111566169 -->XP Build<!-- END:presentationName,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222} CRC: 1966375276 -->The result of the code integration and building process.<!-- END:briefDescription,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-rphHqeONv59sqZq_6FzE6Q CRC: 1276732902 --><a id="XE_xp_build__artifact_definition" name="XE_xp_build__artifact_definition"></a><a id="Purpose" name="Purpose"></a><a
+id="XE_xp_build__purpose_of" name="XE_xp_build__purpose_of"></a>
+<p>
+ The purpose of the <a class="PresentationName"
+ href="./../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
+ guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">XP Build</a> is to show demonstrable progress in a running system. Each
+ <a class="PresentationName" href="./../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
+ guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">XP Build</a> incrementally shows new functionality while insuring that
+ previous functionality has not been broken.
+</p><!-- END:purpose,-rphHqeONv59sqZq_6FzE6Q -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_coding_standard.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_coding_standard.html
new file mode 100644
index 0000000..78cd8a8
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_coding_standard.html
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_coding_standard.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_coding_standard.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED} CRC: 2456192321 -->Coding Standard<!-- END:presentationName,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED} CRC: 1024680233 -->Describes the conventions to be used when working with the programming language.<!-- END:briefDescription,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-NznKylxa2Y_MG8lACUV9Bw CRC: 30641651 --><a id="XE_coding_standard__artifact_definition" name="XE_coding_standard__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_coding_standard__purpose_of" name="XE_coding_standard__purpose_of"></a>
+<p>
+ The purpose of the <a class="PresentationName" guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">Coding Standard</a> is to
+ facilitate communication among programmers working on the same code base. The coding standard takes on added importance
+ in XP because of the pair programming and collective code ownership practices. The objective is to have all parts of
+ the code appear to have been written by the same programmer.
+</p><!-- END:purpose,-NznKylxa2Y_MG8lACUV9Bw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_customer_test.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_customer_test.html
new file mode 100644
index 0000000..f26307d
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_customer_test.html
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_customer_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_customer_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5} CRC: 4283994040 -->XP Customer Test<!-- END:presentationName,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5} CRC: 3054524919 -->Run against the system to verify that a feature has been implemented properly.<!-- END:briefDescription,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: keyConsiderations<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:keyConsiderations,-YYMUwBepQ28JU78LtraO3w CRC: 2462013909 -->As more and more customer tests are added to the system, there will be a need to organize them in some way. Typically, the
+testers and programmers will build and maintain some kind of customer test framework. As is the case for the production
+code, it is important to let the framework evolve with the needs of the application. It is very easy to go overboard when
+building a test framework.<!-- END:keyConsiderations,-YYMUwBepQ28JU78LtraO3w -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-YYMUwBepQ28JU78LtraO3w CRC: 435289206 --><a id="XE_xp_customer_test__artifact_definition" name="XE_xp_customer_test__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_customer_test__purpose_of" name="XE_xp_customer_test__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">XP Customer Test</a> demonstrates the
+ presence of the system features as defined by the customer. They are the unambiguous and detailed requirements of the
+ system.
+</p><!-- END:purpose,-YYMUwBepQ28JU78LtraO3w -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_iteration_plan.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_iteration_plan.html
new file mode 100644
index 0000000..785b4c8
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_iteration_plan.html
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_iteration_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_iteration_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{DC18E34B-70C1-403D-84CC-1BF117A7473D} CRC: 675957411 -->XP Iteration Plan<!-- END:presentationName,{DC18E34B-70C1-403D-84CC-1BF117A7473D} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{DC18E34B-70C1-403D-84CC-1BF117A7473D} CRC: 2492856119 -->Essentially a list of user stories and engineering tasks that will be worked on in the current iteration.<!-- END:briefDescription,{DC18E34B-70C1-403D-84CC-1BF117A7473D} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-45BLJONIjGn7h4z87VXqHQ CRC: 2702884176 --><p>
+ The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> contains a list of
+ stories selected to be implemented in the iteration. Each story is broken down into one or more engineering tasks.
+ These tasks are sufficiently small that an individual can grasp its scope and provide a reasonable estimate. Tasks
+ usually range from less than a day to one or two days for a single individual.
+</p>
+<p>
+ The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> is recorded on flip
+ chart paper and hung on the walls of the team's open workspace. Each story for the iteration is written on a piece of
+ flip chart paper and hung on the open workspace wall. The team brainstorms the tasks needed to complete a story. They
+ discuss the story with the customer as needed. The team will sometimes do a quick design session to help them figure
+ out the tasks for a given story. This is repeated for each story in the iteration. Once all stories have been broken
+ down, individuals sign up for tasks, recording their initials and estimate next to the task.
+</p>
+<p>
+ What makes a good <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a>:
+</p>
+<ul>
+ <li>
+ The stories have been broken down into tasks.
+ </li>
+ <li>
+ The tasks have been signed up for and given estimates.
+ </li>
+ <li>
+ Stories are removed from the plan if there is too much to do.
+ </li>
+ <li>
+ Stories are added to the plan if there is not enough to do.
+ </li>
+</ul><!-- END:mainDescription,-45BLJONIjGn7h4z87VXqHQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-45BLJONIjGn7h4z87VXqHQ CRC: 1345672945 --><a id="XE_xp_iteration_plan__artifact_definition" name="XE_xp_iteration_plan__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_iteration_plan__purpose_of" name="XE_xp_iteration_plan__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> steers the efforts
+ of the team during the iteration.<br />
+</p><!-- END:purpose,-45BLJONIjGn7h4z87VXqHQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_metaphor.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_metaphor.html
new file mode 100644
index 0000000..80f590c
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_metaphor.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_metaphor.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_metaphor.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} CRC: 2154963974 -->Metaphor (System of Names)<!-- END:presentationName,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} CRC: 4100484443 -->A commonly understood vocabulary describing the significant pieces of the system and their associated relationships.<!-- END:briefDescription,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-sQUFozEqR3Gpa5PnCjFh9Q CRC: 3752590463 --><a id="XE_metaphor_(system_of_names)__artifact_definition" name="XE_metaphor_(system_of_names)__artifact_definition"></a><a
+id="Purpose" name="Purpose"></a><a id="XE_metaphor_(system_of_names)__purpose_of"
+name="XE_metaphor_(system_of_names)__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">Metaphor (System of Names)</a> or System
+ of Names allows the team to talk about the structure of the software in a convenient and memorable way.
+</p><!-- END:purpose,-sQUFozEqR3Gpa5PnCjFh9Q -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_production_code.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_production_code.html
new file mode 100644
index 0000000..ae2ceac
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_production_code.html
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_production_code.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_production_code.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} CRC: 4285570354 -->Production Code<!-- END:presentationName,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} CRC: 2978253050 -->The executable specification of the system being built.<!-- END:briefDescription,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-f1cDEBpC5wbDTQ9ru9UbLw CRC: 1703803198 --><p>
+ This definition of <a class="PresentationName" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a>
+ encompasses hand-coded software as well as executable models. The <a class="PresentationName"
+ guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a> must be kept clean and simple, as it is the main
+ vehicle for communicating design intent to the programming team. The code has comprehensive customer and unit tests.
+ The XP practices of simple design, pair programming, refactoring, collective code ownership, test driven development,
+ and coding standard support the creation of the code.
+</p><!-- END:mainDescription,-f1cDEBpC5wbDTQ9ru9UbLw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-f1cDEBpC5wbDTQ9ru9UbLw CRC: 2915913821 --><a id="XE_production_code__artifact_definition" name="XE_production_code__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_production_code__purpose_of" name="XE_production_code__purpose_of"></a>
+<p>
+ In XP, we consider <a class="PresentationName" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a> to be
+ the most important artifact. It is the one design artifact that cannot be replaced because it is the only complete and
+ unambiguous expression of design intent. Source code is a specification. It, along with a compiler or interpreter,
+ encompasses all of the semantics necessary to produce a running process on a computer.
+</p><!-- END:purpose,-f1cDEBpC5wbDTQ9ru9UbLw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_release_plan.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_release_plan.html
new file mode 100644
index 0000000..403c7b0
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_release_plan.html
@@ -0,0 +1,37 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_release_plan.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_release_plan.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B} CRC: 709854695 -->XP Release Plan<!-- END:presentationName,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B} CRC: 1172026417 -->A list of prioritized user stories that will be implemented in the coming release(s).<!-- END:briefDescription,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-mMZ9KUhiFwBbzSFjq_tO4A CRC: 1580736997 --><a id="XE_xp_release_plan__artifact_definition" name="XE_xp_release_plan__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_release_plan__purpose_of" name="XE_xp_release_plan__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">XP Release Plan</a> is the longer term
+ project view. It organizes estimated stories into iterations and groups iterations into releases. The releases defined
+ by the customer contain enough value to deliver the software to the end users of the product. The bias in ordering
+ stories and defining releases is to deliver the most business value possible by the release date.
+</p><!-- END:purpose,-mMZ9KUhiFwBbzSFjq_tO4A -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_unit_test.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_unit_test.html
new file mode 100644
index 0000000..7040bc1
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_unit_test.html
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_unit_test.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_unit_test.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{D156652E-7C52-4EBD-8F23-F38169877A57} CRC: 2645615890 -->XP Unit Test<!-- END:presentationName,{D156652E-7C52-4EBD-8F23-F38169877A57} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{D156652E-7C52-4EBD-8F23-F38169877A57} CRC: 2105075778 -->Used to ensure that a specific functionality of a component of the system is working properly.<!-- END:briefDescription,{D156652E-7C52-4EBD-8F23-F38169877A57} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-dwfXb2dWJOQkTuLo-BTFeQ CRC: 1689109326 --><p>
+ <a class="PresentationName" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a>s are usually implemented at
+ the class level (in OO languages) and test the public interface. For every class in the system, a test class exists.
+ Popular test frameworks are available usually for free (such as JUnit, CppUnit, CppUnitLite, NUnit). These are simple
+ tools that help the developer to organize and run unit tests. These tests drive the programmer development and tell the
+ programmer that the code works as the programmer expects.
+</p><!-- END:mainDescription,-dwfXb2dWJOQkTuLo-BTFeQ -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-dwfXb2dWJOQkTuLo-BTFeQ CRC: 1909421528 --><a id="XE_xp_unit_test__artifact_definition" name="XE_xp_unit_test__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_unit_test__purpose_of" name="XE_xp_unit_test__purpose_of"></a>
+<p>
+ An <a class="PresentationName" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a> is written by developers
+ to ensure that all system components work as expected. <a class="PresentationName"
+ guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a> give the developers the confidence to modify the system
+ and feel confident that everything still works.
+</p><!-- END:purpose,-dwfXb2dWJOQkTuLo-BTFeQ -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_user_story.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_user_story.html
new file mode 100644
index 0000000..3cda5aa
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_user_story.html
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_user_story.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_user_story.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{21946731-4F5C-4862-8B4D-868629952B92} CRC: 2105306272 -->User Story<!-- END:presentationName,{21946731-4F5C-4862-8B4D-868629952B92} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{21946731-4F5C-4862-8B4D-868629952B92} CRC: 3184384656 -->A brief description of some functionality provided by the system from the point of view of a user of that system.<!-- END:briefDescription,{21946731-4F5C-4862-8B4D-868629952B92} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: mainDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:mainDescription,-rtY57MTVQrEcfTKwD3-Wvw CRC: 2369020949 --><p>
+ A <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> is only a token of past and
+ future conversation between the customer and the programmers. XP's on-site customer practice minimizes the need to
+ document extensively each story as the programmers can simply walk over and ask their questions to the customer as
+ needed. <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> details are captured
+ in automated acceptance tests that are then used to validate the implementation of the story.
+</p>
+<p>
+ It may not be necessary to write a description for all stories as the name of some of the stories might already offer
+ enough information.
+</p>
+<p>
+ What makes a good <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a>?
+</p>
+<ul>
+ <li>
+ The customer should care about it. The story should have business value in the customer's eyes so it can be
+ prioritized. Sometimes a story needs to be broken down into smaller pieces to fit into an iteration. If by itself
+ the story does not provide business value, it should at least provide demonstrable progress toward a feature with
+ business value.
+ </li>
+ <li>
+ Stories vertically slice through the product's architecture. They are not usually focused on a specific subsystem.
+ </li>
+ <li>
+ Test cases can be written to verify that the programmers have implemented it correctly.
+ </li>
+ <li>
+ It can be reasonably estimated by the developers. Stories that can't be estimated are rewritten.
+ </li>
+ <li>
+ It can be completed within one iteration. A story that does not fit in an iteration is broken down into two or more
+ smaller stories.
+ </li>
+</ul><!-- END:mainDescription,-rtY57MTVQrEcfTKwD3-Wvw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-rtY57MTVQrEcfTKwD3-Wvw CRC: 1599400112 --><a id="XE_user_story__artifact_definition" name="XE_user_story__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_user_story__purpose_of" name="XE_user_story__purpose_of"></a>
+<p>
+ A <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> represents a small piece of
+ functionality of the system being built. It is not a complete specification of a feature. It is a promise to discuss a
+ feature or a reminder of the discussion that has already taken place.
+</p><!-- END:purpose,-rtY57MTVQrEcfTKwD3-Wvw -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: representationOptions<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:representationOptions,-rtY57MTVQrEcfTKwD3-Wvw CRC: 1359127705 --><p>
+ Here are some sample stories for a typical on-line store application:
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ If the customer has entered a valid Tax Exemption ID, do not charge sales tax.
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ If the Customer ID is on the Preferred Customer list, do not charge for shipping, except for Next Day service.
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ On the System Status Page, show the number of orders in the past 24 hours, the total revenue, and list the top ten
+ items in order of quantity ordered.
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ If the delivery address of a purchase is in any of the states in the attached table, calculate, display, and charge
+ sales tax using the corresponding percentage.
+</p><!-- END:representationOptions,-rtY57MTVQrEcfTKwD3-Wvw -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_vision.html b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_vision.html
new file mode 100644
index 0000000..e78bad1
--- /dev/null
+++ b/XP/XP_baseline_EN/exported_HTML/xp/workproducts/xp_vision.html
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
+<!-- VERSION rmc:7.1.0 -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
+<!-- START NON-TRANSLATABLE -->
+<title>\xp\workproducts\xp_vision.xmi</title>
+</head>
+<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
+<body>
+Element Name: xp_vision.xmi<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: presentationName<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:presentationName,{2300FB25-7249-4481-A1BD-978240906832} CRC: 2366506918 -->XP Vision<!-- END:presentationName,{2300FB25-7249-4481-A1BD-978240906832} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: briefDescription<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:briefDescription,{2300FB25-7249-4481-A1BD-978240906832} CRC: 430978356 -->Defines the stakeholder's view of the product to be developed, specified in terms of the stakeholder's key needs and features.<!-- END:briefDescription,{2300FB25-7249-4481-A1BD-978240906832} -->
+<br/><br/><br/>
+<!-- START NON-TRANSLATABLE -->
+Attribute: purpose<br/><br/>
+<!-- END NON-TRANSLATABLE -->
+<!-- START:purpose,-ZUxMgSWqLlaO5p1r1-ug6Q CRC: 782977913 --><a id="XE_xp_vision__artifact_definition" name="XE_xp_vision__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_vision__purpose_of" name="XE_xp_vision__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{2300FB25-7249-4481-A1BD-978240906832}">XP Vision</a> consists of very high-level
+ requirements. It communicates to the team a common understanding of the project and is a gauge against which all future
+ decisions should be validated. It will guide the team during the development cycle.
+</p><!-- END:purpose,-ZUxMgSWqLlaO5p1r1-ug6Q -->
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/library/configurations/config_for_xp.xmi b/XP/XP_baseline_EN/library/configurations/config_for_xp.xmi
new file mode 100644
index 0000000..52715dd
--- /dev/null
+++ b/XP/XP_baseline_EN/library/configurations/config_for_xp.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:MethodConfiguration xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_mohucGE-EdqnIZeW8YpHcA" name="config_for_xp" guid="_mohucGE-EdqnIZeW8YpHcA" version="1.0.0">
+ <methodPluginSelection href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{35DCB3E1-2766-423E-A849-57ECD4F41A40}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6S2E-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6QGE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6RGE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6QWE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6Q2E-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6QmE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6RmE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6TGE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6TWE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6RWE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6TmE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6SGE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6R2E-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6SWE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_ms9igWE-EdqnIZeW8YpHcA"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{90FB58E1-B403-4358-85D0-BD902528D810}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{796EA4CB-0038-43B8-A568-792DCC3B9F22}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{DBE91BD5-0065-4049-AA61-058C77F1D2A3}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{45A887AB-A968-48AF-8213-4D470DA9DBCC}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{BC57C7CE-BFA8-464F-9925-D27A7968B63C}"/>
+ <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{8367713C-3AEA-489D-B136-DB87D6340A3F}"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_um0n8GdjEdqlnYmIxoiUEQ"/>
+ <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_8NSdoGdjEdqlnYmIxoiUEQ"/>
+ <defaultView xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_um0n8GdjEdqlnYmIxoiUEQ"/>
+</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/XP/XP_baseline_EN/library/library.xmi b/XP/XP_baseline_EN/library/library.xmi
new file mode 100644
index 0000000..02ce1ab
--- /dev/null
+++ b/XP/XP_baseline_EN/library/library.xmi
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI 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" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_hmtlAW96EdupM6itjmYdSQ" guid="_hmtlAW96EdupM6itjmYdSQ">
+ <subManagers xmi:id="_TOlmEGMyEdqsrK7eslBiiA" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_TOlmEGMyEdqsrK7eslBiiA"/>
+ <resourceDescriptors xmi:id="_hmtlAm96EdupM6itjmYdSQ" id="_hmtlAG96EdupM6itjmYdSQ" uri=""/>
+ <resourceDescriptors xmi:id="_1wUXkG96EdupM6itjmYdSQ" id="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" uri="xp/plugin.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodLibrary xmi:id="_hmtlAG96EdupM6itjmYdSQ" name="XP" guid="_hmtlAG96EdupM6itjmYdSQ">
+ <methodPlugins xmi:id="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{35DCB3E1-2766-423E-A849-57ECD4F41A40}"/>
+ </org.eclipse.epf.uma:MethodLibrary>
+</xmi:XMI>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/conceptual_road_maps.xmi b/XP/XP_baseline_EN/library/xp/customcategories/conceptual_road_maps.xmi
new file mode 100644
index 0000000..08649a0
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/conceptual_road_maps.xmi
@@ -0,0 +1,9 @@
+<?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" epf:version="1.0.0" xmi:id="-QcM1bn-XJLcMSggRp54YlQ" name="conceptual_road_maps,_mtDpJGE-EdqnIZeW8YpHcA" guid="-QcM1bn-XJLcMSggRp54YlQ" changeDate="2005-12-06T05:01:41.292-0800">
+ <mainDescription><p class="node">
+ &nbsp;
+</p>
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/getting_started.xmi b/XP/XP_baseline_EN/library/xp/customcategories/getting_started.xmi
new file mode 100644
index 0000000..ac36596
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/getting_started.xmi
@@ -0,0 +1,92 @@
+<?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" epf:version="1.0.0" xmi:id="-MqIvi7DInwjz8kX7QEyU3g" name="getting_started,_ms9ig2E-EdqnIZeW8YpHcA" guid="-MqIvi7DInwjz8kX7QEyU3g" changeDate="2006-03-02T14:18:20.615-0800">
+ <mainDescription><h3>
+ <a id="WhatisXP" name="WhatisXP">What is XP?</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. XP is currently one of the
+ most widely used agile processes in the industry.
+</p>
+<p>
+ <img height="540" alt="" src="resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map" border="0" />
+ <map id="xp_practices_image_map" name="xp_practices_image_map">
+ <area shape="RECT" coords="298,19,390,88"
+ href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
+ <area shape="RECT" coords="176,135,282,200"
+ href="./../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
+ <area shape="RECT" coords="297,168,434,231"
+ href="./../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
+ <area shape="RECT" coords="447,135,547,198"
+ href="./../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
+ <area shape="RECT" coords="15,236,122,305"
+ href="./../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
+ <area shape="RECT" coords="218,238,362,307"
+ href="./../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
+ <area shape="RECT" coords="392,241,512,305"
+ href="./../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
+ <area shape="RECT" coords="614,236,714,302"
+ href="./../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
+ <area shape="RECT" coords="143,325,270,393"
+ href="./../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
+ <area shape="RECT" coords="310,321,412,379"
+ href="./../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
+ <area shape="RECT" coords="468,323,597,393"
+ href="./../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
+ <area shape="RECT" coords="307,386,413,436"
+ href="./../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
+ <area shape="RECT" coords="312,475,419,539"
+ href="./../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
+ <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
+ </map>
+</p>
+<p>
+ This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
+ exemplifies the steering and control cycles of the process. For more details, see <a class="elementLinkWithType"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">Concept:
+ XP Practices</a>.
+</p>
+<h2>
+ <a id="Start" name="Start">Where do I start?</a>
+</h2>
+<p>
+ If you are unfamiliar with XP and want to learn more about it, we suggest you take the following steps:
+</p>
+<ul>
+ <li>
+ Get a quick <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html" guid="9.251272550276345E-306">overview
+ of XP</a>.
+ </li>
+ <li>
+ Learn what the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
+ guid="1.6390805262958034E-306">motivation behind XP</a> is.
+ </li>
+ <li>
+ Understand what <a class="elementLink"
+ href="./../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a> means.
+ </li>
+ <li>
+ Take a tour of the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a> and <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>.
+ </li>
+</ul>
+<p>
+ If you are familiar with XP and are interested in trying XP on your RUP project, we simply suggest you start by reading
+ the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/extreme_programming,5.2637267673584526E-306.html"
+ guid="5.2637267673584526E-306">Extreme Programming Roadmap</a>.<br />
+</p>
+<h3>
+ <a id="Who" name="Who">Who is behind the plug-in?</a>
+</h3>
+<p>
+ This plug-in is a collaboration between <a href="http://www.objectmentor.com/" target="_blank">Object Mentor Inc.</a>
+ and&nbsp;<a href="http://www.ibm.com/" target="_blank">IBM Corporation</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/guidelines_overview.xmi b/XP/XP_baseline_EN/library/xp/customcategories/guidelines_overview.xmi
new file mode 100644
index 0000000..1bd6357
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/guidelines_overview.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-8FSBtYSGN9EGWRr1N6fbPQ" name="guidelines_overview,2.0279775416255596E-305" guid="-8FSBtYSGN9EGWRr1N6fbPQ" changeDate="2005-12-06T04:35:18.106-0800">
+ <mainDescription><p>
+ <b>Guidelines</b> provide practical information about the implementation of specific activities in the process.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/key_xp_concepts.xmi b/XP/XP_baseline_EN/library/xp/customcategories/key_xp_concepts.xmi
new file mode 100644
index 0000000..b4d2e70
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/key_xp_concepts.xmi
@@ -0,0 +1,2 @@
+<?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" epf:version="1.0.0" xmi:id="-hZ1cvRhigpDb6WbQckPWcA" name="key_xp_concepts,1.9093436569802954E-305" guid="-hZ1cvRhigpDb6WbQckPWcA" changeDate="2006-11-29T17:04:06.831-0800" version="1.0.0"/>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/references.xmi b/XP/XP_baseline_EN/library/xp/customcategories/references.xmi
new file mode 100644
index 0000000..2ebe0c8
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/references.xmi
@@ -0,0 +1,3457 @@
+<?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" epf:version="1.0.0" xmi:id="-a8huB5Sn0Qjfe-SkZubH1w" name="references,_mtcqtmE-EdqnIZeW8YpHcA" guid="-a8huB5Sn0Qjfe-SkZubH1w" changeDate="2005-12-06T05:10:54.327-0800">
+ <mainDescription><a id="XE_references__bibliography_of" name="XE_references__bibliography_of"></a><a id="XE_bibliography__references_for"
+name="XE_bibliography__references_for"></a>
+<h5>
+ Topics
+</h5>
+<ul>
+ <li>
+ <a href="#Business Modeling references">Business Modeling</a>
+ </li>
+ <li>
+ <a href="#Configuration Management references">Configuration Management</a>
+ </li>
+ <li>
+ <a href="#Miscellaneous references">Miscellaneous</a>
+ </li>
+ <li>
+ <a href="#Modeling and Unified Modeling Language references">Modeling and Unified Modeling Language</a>
+ </li>
+ <li>
+ <a href="#Object-Oriented Technology references">Object-Oriented Technology</a>
+ </li>
+ <li>
+ <a href="#Project Management references">Project Management</a>
+ </li>
+ <li>
+ <a href="#Requirement Management references">Requirements Management</a>
+ </li>
+ <li>
+ <a href="#Software Architecture references">Software Architecture</a>
+ </li>
+ <li>
+ <a href="#Software Development Process references">Software Development Process</a>
+ </li>
+ <li>
+ <a href="#Testing and Quality references">Testing and Quality</a>
+ </li>
+</ul>
+<h2 align="left">
+ <a id="Business Modeling references" name="Business Modeling references">Business Modeling</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BRO95" name="BRO95">BRO95</a>
+ </td>
+ <td colspan="2">
+ Frederick P. Brooks, Jr. 1995. <i>The Mythical Man-Month-Essays on Software Engineering</i> 2nd ed.
+ Reading, MA, Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ &nbsp;
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic that should be read and re-read by everyone involved in software development. We recommend
+ this 20-year anniversary edition rather than the original 1975 edition.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLA97" name="CLA97">CLA97</a>
+ </td>
+ <td colspan="2">
+ Carl von Clausewitz 1997. <i>On War.</i> Wordsworth Editions.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the greatest books ever written on the subject of war, and applicable to the field of
+ management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CHM95" name="CHM95">CHM95</a>
+ </td>
+ <td colspan="2">
+ James Champy 1995. <i>Reengineering Management: The Mandate for New Leadership.</i> New York, NY:
+ HarperCollins.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Gives some insight into the precarious art of managing a business (re-)engineering effort.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DVP93" name="DVP93">DVP93</a>
+ </td>
+ <td colspan="2">
+ Thomas H. Davenport 1993. <i>Process Innovation-Reengineering Work through&nbsp;Information
+ Technology.</i> Boston, MA: Harvard Business School Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Solid and comprehensive introduction about how information technology enables business improvement and
+ (re-)engineering.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAO97" name="GAO97">GAO97</a>
+ </td>
+ <td colspan="2">
+ United States General Accounting Office 1997. <i>Business Process Reengineering Assessment Guide</i>.
+ <a href="http://www.gao.gov" target="_blank">http://www.gao.gov</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Describes a framework for assessing a business (re-)engineering effort.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ERI00" name="ERI00">ERI00</a>
+ </td>
+ <td colspan="2">
+ Hans-Erik Eriksson and Magnus Penker 2000. <i>Business Modeling With UML: Business Patterns at
+ Work.&nbsp;</i>New York, NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Presents a set of valuable patterns for business modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HAM93" name="HAM93">HAM93</a>
+ </td>
+ <td colspan="2">
+ Michael Hammer and James Champy 1993.&nbsp; <i>Reengineering the Corporation-A Manifesto for Business
+ Revolution.</i>&nbsp;<br />
+ New York, NY: HarperBusiness.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The book that popularized the movement of business (re-)engineering. An excellent complement to <i>The
+ Object Advantage-Business Process Reengineering with Object Technology</i> cited above<i>.&nbsp;</i>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HAR91" name="HAR91">HAR91</a>
+ </td>
+ <td colspan="2">
+ H. James Harrington 1991. <i>Business Process Improvement: The Breakthrough Strategy for Total Quality,
+ Productivity, and Competitiveness</i>. New York, NY: McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Another contributor to the topic of business (re-)engineering.<i>&nbsp;</i>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC94" name="JAC94">JAC94</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Maria Ericsson, and Agneta Jacobson 1994. <i>The Object Advantage-Business Process
+ Reengineering with Object Technology</i>. Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The basis of the Business Modeling discipline, this is the very first book that applied object
+ technology to the field of business modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAP96" name="KAP96">KAP96</a>
+ </td>
+ <td colspan="2">
+ Robert Kaplan and David Norton 1996. <i>The Balanced Scorecard</i>. Boston, MA: Harvard Business School
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Best practices for successfully implementing the Balanced Scorecard.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KOT96" name="KOT96">KOT96</a>
+ </td>
+ <td colspan="2">
+ John P. Kotter 1996. <i>Leading Change</i>. Boston, MA: Harvard Business School Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A practical, proven model for planning and managing organizational change.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MARS00" name="MARS00">MARS00</a>
+ </td>
+ <td colspan="2">
+ Chris Marshall 2000. <i>Enterprise Modeling with UML</i>. Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Describes how to create business models that facilitate the development software systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="NDL97" name="NDL97">NDL97</a>
+ </td>
+ <td colspan="2">
+ David A. Nadler and Michael L. Tushman 1999.&nbsp; <i>Competing by Design-the Power of Organizational
+ Architecture.</i> Oxford University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Defines organizational architecture and capabilities as a source of competitive advantage.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="OHM91" name="OHM91">OHM91</a>
+ </td>
+ <td colspan="2">
+ Kenichi Ohmae 1991.&nbsp; <i>The Mind of the Strategist: The Art of Japanese Business.</i> McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A crisp and practical guide to strategic management.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ODL98" name="ODL98">ODL98</a>
+ </td>
+ <td colspan="2">
+ James J. Odell 1998.&nbsp; <i>Advanced Object-Oriented Analysis &amp; Design Using UML.</i> Cambridge
+ University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Provides a good overview, among other things, on the topic of business rules.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PFE99" name="PFE99">PFE99</a>
+ </td>
+ <td colspan="2">
+ Jeffrey Pfeffer and Robert Sutton 1999.&nbsp; <i>The Knowing-Doing Gap.</i> Boston, MA: Harvard
+ Business School Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ Discusses the reasons why some organizations do not apply their own lessons learned and provides
+ pointers for how to overcome this challenge.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PLR99" name="PLR99">PLR99</a>
+ </td>
+ <td colspan="2">
+ R. Steven Player (Editor) and David Keys (Editor) 1999.&nbsp; <i>Activity-Based Management: Arthur
+ Andersen's Lessons from the ABM Battlefield.</i> Wiley Cost Management Series.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An introduction to understanding the management of costs, and how to implement activity-based costing
+ (ABC) and activity-based management (ABM) systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="POR98" name="POR98">POR98</a>
+ </td>
+ <td colspan="2">
+ Michael Porter 1998.&nbsp; <i>Competitive Strategy: Techniques for Analyzing Industries and
+ Competitors.</i> Simon &amp; Schuster, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A practical guide for the strategic planner.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROS97" name="ROS97">ROS97</a>
+ </td>
+ <td colspan="2">
+ Ron Ross 1997.&nbsp; <i>The Business Rule Book: Classifying, Defining and Modeling Rules.</i> Boston,
+ MA: Database Research Group.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ A complete handbook for the business rules analyst.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SEY98" name="SEY98">SEY98</a>
+ </td>
+ <td colspan="2">
+ Patricia Seybold 1998.&nbsp; <i>Customers.com.</i> Random House Publishing.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="1%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="150%">
+ An excellent collection of practical guidelines and case studies on the benefits of e-business and
+ (re-)engineering.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Configuration Management references" name="Configuration Management references">Configuration Management</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BER92" name="BER92">BER92</a>
+ </td>
+ <td colspan="2">
+ H. Berlack 1992. <i>Software Configuration Management.</i> New York, NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BUC93" name="BUC93">BUC93</a>
+ </td>
+ <td colspan="2">
+ J. Buckley 1993. <i>Implementing Configuration Management, Hardware, Software and Firmware.</i>&nbsp;
+ Los Alamitos, CA: IEEE Computer Science Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WHI00" name="WHI00">WHI00</a>
+ </td>
+ <td colspan="2">
+ Brian White and Geoff Glemm 2000. <i>Software Configuration Management Strategies and Rational
+ ClearCase: A Practical Introduction.</i> Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WHI91" name="WHI91">WHI91</a>
+ </td>
+ <td colspan="2">
+ David Whitgift 1991. <i>Methods and Tools for Software Configuration Management.</i>&nbsp; New York,
+ NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2>
+ <a id="Miscellaneous references" name="Miscellaneous references">Miscellaneous</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOU94" name="BOU94">BOU94</a>
+ </td>
+ <td colspan="2">
+ Serge Bouchy 1994.&nbsp; <i>L'ingénierie des systèmes informatiques évolutifs,</i> Paris, France:
+ Eyrolles, 330p.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BRO95" name="BRO95">BRO95</a>
+ </td>
+ <td colspan="2">
+ Frederick P. Brooks, Jr. 1995. <i>The Mythical Man-Month-Essays on Software Engineering</i> 2nd ed.
+ Reading, MA, Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic that should be read and re-read by everyone involved in software development. We recommend
+ this 20-year anniversary edition rather than the original 1975 edition.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="con92" name="con92">CON92</a>
+ </td>
+ <td colspan="2">
+ D. Conner 1992. <i>Managing at the Speed of Change.</i> New York, NY: Random House, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DAT99" name="DAT99">DAT99</a>
+ </td>
+ <td colspan="2">
+ C.J. Date 1999. <i>An Introduction to Database Systems.</i>&nbsp; 7th ed.&nbsp; New York, NY:
+ Addison-Wesley Publishing Company, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Excellent introduction, reference, and source of background information on Database Systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DAV95" name="DAV95">DAV95</a>
+ </td>
+ <td colspan="2">
+ Alan Davis 1995. <i>201 Principles of Software Development.</i>&nbsp; New York, NY: McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Full of good advice for every team member on a project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DEG90" name="DEG90">DEG90</a>
+ </td>
+ <td colspan="2">
+ Peter DeGrace and Leslie Stahl 1990. <i>Wicked Problems, Righteous Solutions: A Catalog of Modern
+ Software Engineering Practices.</i> Englewood Cliffs, NJ: Yourdon Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An insightful book on various process lifecycles and their origins, flaws, and strengths; useful for
+ understanding the importance of process.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DEI84" name="DEI84">DEI84</a>
+ </td>
+ <td colspan="2">
+ Harvey M. Deitel 1984. <i>An Introduction to Operating Systems.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FIS96" name="FIS96">FIS96</a>
+ </td>
+ <td colspan="2">
+ Charles Fishman 1996. <i>Johnson Space Center Shuttle Software Group, "They Write the Right
+ Stuff"</i><i>.</i> Fastcompany, Issue 6, p. 95, December, 1996.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GRA97" name="GRA97">GRA97</a>
+ </td>
+ <td colspan="2">
+ Ian Graham, et al. 1997. <i>The OPEN Process Specification</i>. Harlow, England: Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Another process model, coming from down under that shares some principles with the Rational Unified
+ Process (RUP).
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="hac97" name="hac97">HAC97</a>
+ </td>
+ <td colspan="2">
+ JoAnn T. Hackos and Dawn M. Stevens 1997. <i>Standards for Online Communication.</i> John Wiley and
+ Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ For the modern technical writer, this book has become the defacto standard. It defines a process for
+ developing user manuals, specifically focusing on how you produce online help systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HER99" name="HER99">HER99</a>
+ </td>
+ <td colspan="2">
+ Peter Herzum and Oliver Sims 1999. <i>Business Component Factory: A Comprehensive Overview of
+ Component-Based Development for the Enterprise.</i> John Wiley &amp; Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Defines and describes component-based development-from creating small components to creating
+ federations of large component-based systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM2000
+ </td>
+ <td colspan="2">
+ <i>IBM System Integrated Method.</i> International Business Machines Corporation 1998, 1999, 2000.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM99a
+ </td>
+ <td colspan="2">
+ <i>An Approach to Designing e-business Solutions.</i> International Business Machines Corporation 1999.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <a href="http://www.redbooks.ibm.com/abstracts/sg245949.html"
+ target="_blank">http://www.redbooks.ibm.com/abstracts/sg245949.html</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM99b
+ </td>
+ <td colspan="2">
+ <i>Design Considerations: From Client Server Applications to e-business Applications.</i> International
+ Business Machines Corporation 1999.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <a href="http://www.redbooks.ibm.com/abstracts/sg245503.html"
+ target="_blank">http://www.redbooks.ibm.com/abstracts/sg245503.html</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM99c
+ </td>
+ <td colspan="2">
+ <i>The Front of IBM WebSphere-Building e-business User Interfaces.</i> International Business Machines
+ Corporation 1999.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <a href="http://www.redbooks.ibm.com/abstracts/sg245488.html"
+ target="_blank">http://www.redbooks.ibm.com/abstracts/sg245488.html</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM98a
+ </td>
+ <td colspan="2">
+ <i>Architecture Description Standard: Overview.</i>&nbsp; International Business Machines Corporation
+ 1998.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ IBM98b
+ </td>
+ <td colspan="2">
+ <i>Architecture Description Standard: Semantic Specification.</i>&nbsp; International Business Machines
+ Corporation 1998.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Other relevant Web sites for the preceding IBM references are:<br />
+ <a href="http://www.redbooks.ibm.com" target="_blank">http://www.redbooks.ibm.com<br />
+ </a> <a href="http://www.ibm.com/e-business/" target="_blank">http://www.ibm.com/e-business/<br />
+ </a> <a href="http://www.ibm.com/software" target="_blank">http://www.ibm.com/software<br />
+ </a> <a href="http://www.ibm.com/developer/" target="_blank">http://www.ibm.com/developer/<br />
+ </a> <a href="http://www.ibm.com/services/" target="_blank">http://www.ibm.com/services/</a>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IBM97" name="IBM97">IBM97</a>
+ </td>
+ <td colspan="2">
+ IBM 1997. <i>Developing Object-Oriented Software</i><i>-</i><i>An Experienced- based Approach.</i>
+ Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Like the RUP, an iterative, incremental, object-oriented, scenario-driven, risk-aware process developed
+ by the IBM Object Technology Center.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IE610.12" name="IE610.12">IE610.12</a>
+ </td>
+ <td colspan="2">
+ IEEE Std 610.12-1990. <i>IEEE Standard Glossary of Software Engineering Terminology.</i> The Institute
+ of Electrical and Electronics Engineers, Inc.: New York, NY, 10017-2394, USA. 1990.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" height="23">
+ <a id="JAV03" name="JAV03">JAV03</a>
+ </td>
+ <td colspan="2">
+ JavaTM 2 Platform, Standard Edition, v 1.4.2 API Specification -
+ http://java.sun.com/j2se/1.4.2/docs/api/index.html
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="jel93" name="jel93">JEL93</a>
+ </td>
+ <td colspan="2">
+ J. Jellison 1993. <i>Overcoming Resistance: A Practical Guide to Producing Change in the
+ Workplace.</i>&nbsp; New York, NY: Simon &amp; Schuster, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAT93" name="KAT93">KAT93</a>
+ </td>
+ <td colspan="2">
+ Jon R. Katzenbach and Douglas K. Smith 1993. <i>The Wisdom of Teams.</i> New York, NY: Harper Business.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The secret of effective teams.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KET98" name="KET98">KET98</a>
+ </td>
+ <td colspan="2">
+ Nasser Kettani, et al. 1998. <i>De Merise à UML.</i> Paris, France: Editions Eyrolles.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Merise is a very popular software development methodology in France, which has been upgraded to use
+ UML. It has some similitude with the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="LEA97" name="LEA97">LEA97</a>
+ </td>
+ <td colspan="2">
+ Doug Lea 1999.&nbsp; <i>Concurrent Programming in Java.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCA95" name="MCA95">MCA95</a>
+ </td>
+ <td colspan="2">
+ Jim McCarthy 1995.&nbsp; <i>Dynamics of Software Development.</i> Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Fifty-three rules of thumb by a Microsoft development manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCO97" name="MCO97">MCO97</a>
+ </td>
+ <td colspan="2">
+ Steve McConnell 1997.&nbsp; <i>Software Project Survival Guide.</i> Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A collection of practical experience on how to deliver successful software projects.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCO93" name="MCO93">MCO93</a>
+ </td>
+ <td colspan="2">
+ Steve McConnell 1993. <i>Code Complete</i><i>-</i><i>A Practical Handbook of Software Construction.</i>
+ Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great book for the implementers and for testers looking at the implementation, integration, and test
+ aspects of the development process.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="mos98" name="mos98">MOS98</a>
+ </td>
+ <td colspan="2">
+ Microsoft 1998. The <i>Microsoft Manual of Style for Technical Publications.</i>&nbsp; Redmond, WA:
+ Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="STA97" name="STA97">STA97</a>
+ </td>
+ <td colspan="2">
+ Jennifer Stapleton 1997.&nbsp; <i>The Dynamic System Development Method.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ At 15,000 feet, the DSDM approach could be seen as an introduction to the RUP. Although they use a
+ different terminology, the two processes are very close to each other, and you can see the RUP as an
+ instance or an implementation of&nbsp; DSDM.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="TAN86" name="TAN86">TAN86</a>
+ </td>
+ <td colspan="2">
+ Andrew S. Tannenbaum 1986. <i>Operating Systems: Design and Implementation.&nbsp;</i> Upper Saddle
+ River, NJ: Prentice Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WID00" name="WID00">WID00</a>
+ </td>
+ <td colspan="2">
+ R. Max Wideman and PMForum, February, 1999 and January, 2000. <i>Wideman Comparative Glossary of
+ Project Management Terms v2.0.</i> www.pmforum.org
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This great collection of various software engineering terms and their many definitions is available
+ online at <a href="http://www.pmforum.org/library/glossary/"
+ target="_blank">http://www.pmforum.org/library/glossary/</a>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="YOU97" name="YOU97">YOU97</a>
+ </td>
+ <td colspan="2">
+ Edward Yourdon 1997. <i>Death March: Managing "Mission Impossible" Projects.</i> Upper Saddle River,
+ NJ: Prentice Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An interesting view on project troubles.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Modeling and Unified Modeling Language references"
+ name="Modeling and Unified Modeling Language references">Modeling and Unified Modeling Language</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="BOO98" name="BOO98">BOO98</a>
+ </td>
+ <td colspan="2">
+ G. Booch, J. Rumbaugh, and I. Jacobson, 1998. <i>UML User Guide</i>. Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Published at the same time as Rational Unified Process 5.1, this book is an excellent user's guide on
+ UML by its main authors.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="CHE01" name="CHE01">CHE01</a>
+ </td>
+ <td colspan="2">
+ John Cheesman and John Daniels, 2001. <i>UML Components: A Simple Process for Specifying
+ Component-Based Software</i>. Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book provides a lot of in-depth practical guidance for specifying component-based systems, at the
+ same time remaining compact and readable.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="CONA99" name="CONA99">CONA99</a>
+ </td>
+ <td colspan="2">
+ Jim Conallen, 1999. <i>Building Web Applications with UML.</i> Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good introduction to the basics of web application development in the context of the RUP. This book
+ also shows how to use the UML to model web applications and introduces a Web Application Extension to
+ the UML.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="DOUG98" name="DOUG98">DOUG98</a>
+ </td>
+ <td colspan="2">
+ Bruce Powel Douglass 1998. <i>Real-Time UML.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Using UML as the notation, this book offers good advice on the application of object-oriented
+ technology for real-time systems.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ <a id="ERI04" name="ERI04">ERI04</a>
+ </td>
+ <td colspan="2">
+ Hans-Erik Eriksson, Magnus Penker, Brian Lyons and David Fado 2004. <i>UML 2 Toolkit</i>. Indianopolis:
+ Wiley Publishing, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="ERI97" name="ERI97">ERI97</a>
+ </td>
+ <td colspan="2">
+ Hans-Erik Eriksson and Magnus Penker 1997. <i>UML Toolkit</i>. New York: John Wiley &amp; Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A more comprehensive book on UML as seen from Sweden by another pair of Rational friends.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="FOW97" name="FOW97">FOW97</a>
+ </td>
+ <td colspan="2">
+ Martin Fowler 1997. <i>UML Distilled-Applying the standard object modeling language</i>. Addison-Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A very nice little introduction to UML if you're in a hurry.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="FRA03" name="FRA03">FRA03</a>
+ </td>
+ <td colspan="2">
+ David S. Frankel 2003. <i>Model Driven Architecture: Applying MDA to Enterprise Computing.</i> John
+ Wiley &amp; Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ A foundational work on the OMG's Model Driven Architecture initiative, written by one of its principal
+ developers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="KLE03" name="KLE03">KLE03</a>
+ </td>
+ <td colspan="2">
+ Anneke Kleppe, Jos Warmer and Wim Bast 2003. <i>MDA Explained-The Model Driven
+ Architecture(TM):Practice and Promise.</i> Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ More useful insights into MDA from a practitioner's viewpoint, written by contributors to the creation
+ of MDA.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="LAR02" name="LAR02">LAR02</a>
+ </td>
+ <td colspan="2">
+ Craig Larman 2002.&nbsp; <i>Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
+ Design and the Unified Process,</i> 2nd ed. Prentice-Hall, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book is a great illustration of what happens in the Analysis &amp; Design discipline. It teaches
+ analysis and design, the use of UML, and the application of the concept of pattern in the context of
+ the Unified Process. By presenting the case study in an iterative, risk-driven, architecture-centric
+ process, Mr. Larman's advice has a realistic context. He exposes the dynamics of what really happens in
+ software development and shows the external forces at play. The design activities are connected to
+ other tasks, and they no longer appear as a purely cerebral activity of systematic transformations or
+ creative intuition.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="MEL04" name="MEL04">MEL04</a>
+ </td>
+ <td colspan="2">
+ Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise 2004. <i>MDA Distilled-Principles of
+ Model-Driven Architecture.</i> Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ Extracts and presents the essence of MDA, with an emphasis on the technology for executable models.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="MUL98" name="MUL98">MUL98</a>
+ </td>
+ <td colspan="2">
+ Pierre-Alain Muller 1998.&nbsp; <i>Instant UML.</i> Wrox Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Another short introduction to UML by a former colleague.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="NBG01" name="NBG01">NBG01</a>
+ </td>
+ <td colspan="2">
+ Eric J. Naiburg and Robert A. Maksimchuk 2001. <i>UML For Database Design</i>. New York, NY:
+ Addison-Wesley Publishing Company, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ &nbsp;
+ </td>
+ <td width="11%">
+ &nbsp;
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Application of UML to database modeling and design.&nbsp; Supported throughout by a case study.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="OMG03" name="OMG03">OMG03</a>
+ </td>
+ <td colspan="2">
+ <i>MDA Guide Version 1.0.1.</i> Object Management Group. Document omg/2003-06-01, June 2003
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ <p>
+ A specification of the concepts and terminology of Model Driven Architecture from the OMG.
+ </p>
+ <p>
+ <a href="http://www.omg.org/mda/specs.htm" target="_blank">http://www.omg.org/mda/specs.htm</a>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="QUA98" name="QUA98">QUA98</a>
+ </td>
+ <td colspan="2">
+ Terry Quatrani 1998. <i>Visual Modeling with Rational Rose and UML.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ &nbsp;
+ </td>
+ <td width="11%">
+ &nbsp;
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Provides step-by-step guidance on how to build UML models. At the same time, it follows the RUP, in
+ effect providing a small scale example.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">
+ <a id="RUM05" name="RUM05">RUM05</a>
+ </td>
+ <td colspan="2">
+ James Rumbaugh, Ivar Jacobson, Grady Booch, 2005. <i>The Unified Modeling Language Reference Manual,
+ second edition.</i> Addison-Wesley, Boston.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="RUM98" name="RUM98">RUM98</a>
+ </td>
+ <td colspan="2">
+ J. Rumbaugh, I. Jacobson, and G. Booch, 1998. <i>UML Reference Manual.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Certainly more digestible than the OMG standard; UML fully exposed by its main authors.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="UML01" name="UML01">UML01</a>
+ </td>
+ <td colspan="2">
+ <i>OMG Unified Modeling Language Specification, Version 1.4.&nbsp;</i> Rational Software Corporation,
+ 18880 Homestead Road, Cupertino, CA 95014, and Object Management Group, Inc., 492 Old Connecticut Path,
+ Framingham, MA 01701.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The latest specification of the UML. Available online at <a href="http://www.rational.com/uml"
+ target="_blank">http://www.rational.com/uml</a>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%" height="21">
+ <a id="UML04" name="UML04">UML04</a>
+ </td>
+ <td colspan="2">
+ <i>OMG Unified Modeling Language Specification, Version 2.0.&nbsp;</i> Object Management Group, Inc.,
+ Needham, MA 02494
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ </td>
+ <td width="11%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Final Adopted Specification (2003-08-02)
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="UML96" name="UML96">UML96</a>
+ </td>
+ <td colspan="2">
+ G. Booch, J. Rumbaugh, and I. Jacobson 1996. <i>The Unified Modeling Language for Object-Oriented
+ Development.</i> Documentation set, version 0.9 Addendum, Rational Software Corporation.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="11%">
+ <a id="UML95" name="UML95">UML95</a>
+ </td>
+ <td colspan="2">
+ G. Booch and J. Rumbaugh 1995. <i>Unified Method for Object-Oriented Development.</i> Documentation
+ set, version 0.8, Rational Software Corporation.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Object-Oriented Technology references" name="Object-Oriented Technology references">Object-Oriented
+ Technology</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOO93" name="BOO93">BOO93</a>
+ </td>
+ <td colspan="2">
+ Grady Booch 1993. <i>Object-Oriented Analysis and Design with Applications,</i> 2nd edition. Redwood
+ City, CA: The Benjamin/Cummings Publishing Company.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BUH96" name="BUH96">BUH96</a>
+ </td>
+ <td colspan="2">
+ R. J. A. Buhr and R. S. Casselman 1996. <i>Use Case Maps for Object-Oriented Systems.</i> Upper Saddle
+ River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book develops some other views on use cases.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC92" name="JAC92">JAC92</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, et al. 1992. <i>Object-Oriented Software Engineering-A Use Case-Driven Approach</i>,
+ Wokingham, England: Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="RUM91" name="RUM91">RUM91</a>
+ </td>
+ <td colspan="2">
+ James Rumbaugh, et al. 1991. <i>Object-Oriented Modeling and Design.</i> Upper Saddle River, NJ:
+ Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The three books above are the original roots to the object-oriented analysis and design discipline from
+ "the three amigos", just before the advent of the UML and the RUP. Despite the use of their original
+ notations, they are still the key references for OO designers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="RUM96" name="RUM96">RUM96</a>
+ </td>
+ <td colspan="2">
+ James Rumbaugh 1996. <i>OMT Insights.</i> New York: SIGS Books.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A complement to the original&nbsp; OMT book, diving into special topics: inheritance, use cases, and so
+ on.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SEL94" name="SEL94">SEL94</a>
+ </td>
+ <td colspan="2">
+ Bran Selic, Garth Gullekson, and Paul Ward 1994. <i>Real-time Object-Oriented Modeling.</i> New York,
+ NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The reference work on using object technology for the design of reactive systems by the people who have
+ brought us <i>ObjecTime Developer</i>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WIR90" name="WIR90">WIR90</a>
+ </td>
+ <td colspan="2">
+ Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener 1990. <i>Designing Object-Oriented
+ Software.</i> Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book describes the Class, Responsibility, Collaboration (CRC) approach to object-oriented software
+ development.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Project Management references" name="Project Management references">Project Management</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AMI95" name="AMI95">AMI95</a>
+ </td>
+ <td colspan="2">
+ K. Pulford, A. Kuntzmann-Combelles, and S. Shirlaw 1995. <i>A Quantitative Approach to Software
+ Management-The AMI Handbook.</i> Addison Wesley Longman.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE00" name="BOE00">BOE00</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm et al, 2000. Software Cost Estimation with COCOMO II. Upper Saddle River, NJ:
+ Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The successor to the original classic work.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE81" name="BOE81">BOE81</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1981. <i>Software Engineering Economics.</i> Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic work on software effort estimation that describes the original COCOMO estimation model.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE91" name="BOE91">BOE91</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1991. <i>Software Risk Management: Principles and Practices</i>, <i>IEEE Software,</i>
+ Jan. 1991, IEEE, pp.32-41.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Still the best little introduction to risk management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOO95" name="BOO95">BOO95</a>
+ </td>
+ <td colspan="2">
+ Grady Booch 1995. <i>Object Solutions-Managing the Object-Oriented Project.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A pragmatic book for managers of object-oriented projects; one of the sources on the underlying
+ philosophy of the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CAN01" name="CAN01">CAN01</a>
+ </td>
+ <td colspan="2">
+ Murray Cantor 2001. <i>Software Leadership.</i> Addison-Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CAR93" name="CAR93">CAR93</a>
+ </td>
+ <td colspan="2">
+ Marvin J. Carr, et al. 1993. <i>Taxonomy-Based Risk Identification,</i> Technical Report
+ CMU/SEI-93-TR-6, Pittsburgh, PA, SEI, June 1993, 24p.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Provides a source of inspiration to get started on your own list of risks.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CHA89" name="CHA89">CHA89</a>
+ </td>
+ <td colspan="2">
+ Robert Charette 1989. <i>Software Engineering Risk Analysis and Management.</i> New York, NY:
+ McGraw-Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Practical perspective on risk management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CHID94" name="CHID94">CHID94</a>
+ </td>
+ <td colspan="2">
+ Chidamber and Kemerer 1994. <i>A metrics suite for object-oriented design,</i> IEEE Transactions on
+ Software Engineering, 20(6), 1994.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the original contributions to the field of OO software metrics.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLE96" name="CLE96">CLE96</a>
+ </td>
+ <td colspan="2">
+ Robert T. Clemen 1996. <i>Making Hard Decisions: An Introduction to Decision Analysis.</i> Duxbury
+ Press.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Thorough yet accessible treatment of the fundamentals of decision analysis.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DEV95" name="DEV95">DEV95</a>
+ </td>
+ <td colspan="2">
+ Michael T. Devlin and Walker E. Royce.&nbsp; <i>Improving Software Economics in the Aerospace and
+ Defense Industry,</i> Technical Paper TP-46, Santa Clara, CA, Rational Software Corporation, 1995.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="EVA98" name="EVA98">EVA98</a>
+ </td>
+ <td colspan="2">
+ James R. Evans and David L. Olson 1998. <i>Introduction to Simulation and Risk Analysis.</i>&nbsp;
+ Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Good introduction to the use of simulation for business modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FAI94" name="FAI94">FAI94</a>
+ </td>
+ <td colspan="2">
+ Richard Fairley 1994. "Risk Management for Software Project," <i>IEEE Software,</i> 11 (3), May 1994,
+ pp.57-67
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Straightforward strategy for risk management if you have never done this before.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GIL88" name="GIL88">GIL88</a>
+ </td>
+ <td colspan="2">
+ Tom Gilb 1988. <i>Principles of Software Engineering Management.</i> Harlow, England: Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great book by a pioneer of iterative development, it's full of pragmatic advice for the project
+ manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HEND96" name="HEND96">HEND96</a>
+ </td>
+ <td colspan="2">
+ Brian Henderson-Sellers 1996. <i>Object-Oriented Metrics, Measures of Complexity.</i> Prentice Hall
+ PTR.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Good, detailed coverage of OO-specific metrics.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JON94" name="JON94">JON94</a>
+ </td>
+ <td colspan="2">
+ Capers Jones 1994. <i>Assessment and Control of Software Risks.</i> Yourdon Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An indispensable source of risks to check your list against to make sure it's is complete.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAR96" name="KAR96">KAR96</a>
+ </td>
+ <td colspan="2">
+ Dale Karolak 1996. <i>Software Engineering Risk Management.</i> Los Alamitos, CA: IEEE Computer Society
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Offers more sophisticated advice and techniques for risk management.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCO96" name="MCO96">MCO96</a>
+ </td>
+ <td colspan="2">
+ Steve McConnell 1996. <i>Rapid Development.</i> Redmond, WA: Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Excellent coverage of good practice for rapid software development
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MSP97" name="MSP97">MSP97</a>
+ </td>
+ <td colspan="2">
+ User's Guide for Microsoft Project 98, Microsoft Corporation, 1997.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="OCO94" name="OCO94">OCO94</a>
+ </td>
+ <td colspan="2">
+ Fergus O'Connell 1994. <i>How to Run Successful Projects.</i> New York, NY: Prentice-Hall
+ International.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A real gem! Everything you really need to know to manage your first project, in 170 pages.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PMI96" name="PMI96">PMI96</a>
+ </td>
+ <td colspan="2">
+ <i>A Guide to the Project Management Body of Knowledge.</i> The Project Management Institute: Newton
+ Square, PA, 19073-3299, USA. 1996.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PUT92" name="PUT92">PUT92</a>
+ </td>
+ <td colspan="2">
+ Lawrence Putnam &amp; Ware Myers 1992. <i>Measures for Excellence: Reliable Software On Time, Within
+ Budget.</i> Yourdon Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY98" name="ROY98">ROY98</a>
+ </td>
+ <td colspan="2">
+ Walker Royce 1998. <i>Software Project Management: A Unified Framework.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An indispensable companion to the RUP, this book describes the spirit of the Rational Process and its
+ underlying software economics. Full of great advice for the project manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="VOS96" name="VOS96">VOS96</a>
+ </td>
+ <td colspan="2">
+ David Vose 1996. <i>Quantitative Risk Analysis: A Guide to Monte Carlo Simulation Modeling.</i> John
+ Wiley &amp; Sons.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good guide to the modeling of uncertainty using Monte Carlo techniques.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WHIT97" name="WHIT97">WHIT97</a>
+ </td>
+ <td colspan="2">
+ Scott Whitmire 1997. <i>Object-Oriented Design Measurement.</i> John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good, if mathematically challenging, treatment of the theoretical basis of software measurement.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Requirement Management references" name="Requirement Management references">Requirements Management</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AND96" name="AND96">AND96</a>
+ </td>
+ <td colspan="2">
+ Stephen J. Andriole 1996. <i>Managing Systems Requirements: Methods, Tools, and Cases.</i> McGraw Hill.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEY98" name="BEY98">BEY98</a>
+ </td>
+ <td colspan="2">
+ Hugh Beyer and Karen Holtzblatt 1998. <i>Contextual Design.</i> San Francisco, CA: Morgan Kaufmann
+ Publishers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BIT03" name="BIT03">BIT03</a>
+ </td>
+ <td colspan="2">
+ Kurt Bittner and Ian Spence 2003. <i>Use Case Modeling.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Comprehensive coverage of use case techniques and practices, including useful examples showing how
+ use-case specifications evolve over time.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COC01a" name="COC01a">COC01a</a>
+ </td>
+ <td colspan="2">
+ Alistair Cockburn 2001. <i>Writing Effective Use Cases.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Excellent guidance for those who need to write use cases. Multiple styles and techniques contrasted
+ with insight in an unbiased way. Many helpful tips to improve your use cases.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CON99" name="CON99">CON99</a>
+ </td>
+ <td colspan="2">
+ Larry Constantine and Lucy A.D. Lockwood 1999. <i>Software for Use.</i> Reading, MA: Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ An excellent book on user-centric design, focusing on techniques and practical guidelines for
+ developing software that is usable.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COO99" name="COO99">COO99</a>
+ </td>
+ <td colspan="2">
+ Alan Cooper1999. <i>The Inmates are Running the Asylum.</i> Indianapolis, IN: SAMS.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DAV93" name="DAV93">DAV93</a>
+ </td>
+ <td colspan="2">
+ Alan Davis 1993. <i>Software Requirements-Objects, Functions and States.</i> Englewood Cliffs, NJ:
+ Prentice Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FIS91" name="FIS91">FIS91</a>
+ </td>
+ <td colspan="2">
+ Roger Fisher and William Ury 1991. <i>Getting to Yes-Negotiating Agreement Without Giving In, 2nd
+ Edition.</i> Penguin Books USA.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAU89" name="GAU89">GAU89</a>
+ </td>
+ <td colspan="2">
+ Donald Gause and Gerald Weinberg 1989. <i>Exploring Requirements-Quality Before Design.</i> New York,
+ NY: Dorset House.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GOU88" name="GOU88">GOU88</a>
+ </td>
+ <td colspan="2">
+ John D. Gould 1988. "How to Design Usable Systems", in Helander, Martin, ed. <i>Handbook of Computer
+ Interaction</i>, pp. 757-789, North-Holland, Amsterdam, The Netherlands.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GOU87" name="GOU87">GOU87</a>
+ </td>
+ <td colspan="2">
+ John D. Gould, Stephen J. Boies, Stephen Levy, John T. Richards and Jim Schoonard 1987. "The 1984
+ Olympic Message System: a test of behavioral principles of system design", in <i>Communications of the
+ ACM</i>, Vol. 30, No. 9, pp. 758-769.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GRA92" name="GRA92">GRA92</a>
+ </td>
+ <td colspan="2">
+ Robert Grady 1992. <i>Practical Software Metrics for Project Management and Process Improvement</i>.
+ Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%" height="28">
+ <a id="HOL96" name="HOL96">HOL96</a>
+ </td>
+ <td width="88%" colspan="2" height="28">
+ Holtzblatt, K., and H. Beyer 1996. "Contextual Design: Principles and Practice," <i>Field Methods for
+ Software and Systems Design</i>. D. Wixon and J. Ramey (Eds.), NY, NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IE830" name="IE830">IE830</a>
+ </td>
+ <td colspan="2">
+ IEEE Std 830-1993. <i>Recommended Practice for Software Requirements Specifications.</i> Software
+ Engineering Standards Committee of the IEEE Computer Society: New York, NY, 1993.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ISO13407" name="ISO13407">ISO13407</a>
+ </td>
+ <td colspan="2">
+ ISO/TC159 1999. <i>Human-centred design processes for interactive systems.</i> Report ISO 13407:1999,
+ International Organization for Standardization, Geneva, Switzerland.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KOV99" name="KOV99">KOV99</a>
+ </td>
+ <td colspan="2">
+ Benjamin L. Kovitz 1999. <i>Practical Software Requirements-A Manual of Content &amp; Style.</i>
+ Manning Publications.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="LEF99" name="LEF99">LEF99</a>
+ </td>
+ <td colspan="2">
+ Dean Leffingwell and Don Widrig 1999. <i>Effective Requirements Management.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%" height="21">
+ <a id="MAY99" name="MAY99">MAY99</a>
+ </td>
+ <td width="88%" colspan="2" height="21">
+ Deborah J. Mayhew1999. <i>The Usability Engineering Lifecycle.</i> Morgan Kaufmann Publishers.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SCH98" name="SCH98">SCH98</a>
+ </td>
+ <td colspan="2">
+ Geri Schneider and Jason P. Winters 1998. <i>Applying Use Cases-A Practical Guide.</i> Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SOM97" name="SOM97">SOM97</a>
+ </td>
+ <td colspan="2">
+ Ian Sommerville and Pete Sawyer 1997. <i>Requirements Engineering-A Good Practice Guide.</i> New York,
+ NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="THA97" name="THA97">THA97</a>
+ </td>
+ <td colspan="2">
+ Richard H. Thayer and Merlin Dorfman 1997. <i>Software Requirements Engineering, 2nd Edition.</i> IEEE
+ Computer Society Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WEI95" name="WEI95">WEI95</a>
+ </td>
+ <td colspan="2">
+ Gerald Weinberg, 1995. "Just Say No! Improving the Requirements Process", <i>American Programmer</i>,
+ October 1995.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Software Architecture references" name="Software Architecture references">Software Architecture</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0" valign="top">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BAS98" name="BAS98">BAS98</a>
+ </td>
+ <td colspan="2">
+ Len Bass, Paul Clements, and Rick Kazman 1998. <i>Software Architecture in Practice.</i> Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A handbook of software architecture, with numerous case studies.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOS00" name="BOS00">BOS00</a>
+ </td>
+ <td colspan="2">
+ Jan Bosch 2000. <i>Design and Use of Software Architecture.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BUS96" name="BUS96">BUS96</a>
+ </td>
+ <td colspan="2">
+ Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl 1996.
+ <i>Pattern-Oriented Software Architecture-A System of Patterns</i>, New York, NY: John Wiley and Sons,
+ Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Following the model of the "gang of four" book (Gamma, et al, see above) this book makes an inventory
+ of a wide range of design patterns at the level of the architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CKK02" name="CKK02">CKK02</a>
+ </td>
+ <td colspan="2">
+ Paul Clements, Rick Kazman, and Mark Klein 2002. <i>Evaluating Software Architecture</i>, Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLE02" name="CLE02">CLE02</a>
+ </td>
+ <td colspan="2">
+ Paul Clements et al. 2002. <i>Documenting Software Architectures: Views and Beyond</i>, Addison Wesley
+ Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="CLN02" name="CLN02">CLN02</a>
+ </td>
+ <td colspan="2">
+ Paul Clements and Linda Northrop 2002. <i>Software Product Lines: Practice and Patterns</i>, Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The preceding three books are from the Software Engineering Institute's architecture study group.
+ <i>Evaluating Software Architecture</i> provides useful input for architectural reviews. <i>Documenting
+ Software Architectures: Views and Beyond</i> fully embraces the concept of views and helps with
+ developing a Software Architecture document.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DIK01" name="DIK01">DIK01</a>
+ </td>
+ <td colspan="2">
+ David M. Dikel, David Kane, and James R. Wilson 2001. <i>Software Architecture - Organizational
+ Principles and Patterns</i>, Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Describes the VRAPS model of architecting: Vision, Rhythm, Anticipation, Partnering, and
+ Simplification. This is a good reference for the budding architect to put his or her role in context.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FOW97a" name="FOW97a">FOW97a</a>
+ </td>
+ <td colspan="2">
+ Martin Fowler 1997. <i>Analysis Patterns: Reusable Object Models.</i> Addison Wesley Longman.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAM94" name="GAM94">GAM94</a>
+ </td>
+ <td colspan="2">
+ Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides 1994. <i>Design Patterns-Elements of
+ Reusable Object-Oriented Software.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the earlier works on patterns, this book deals with patterns "in the small".
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GAR93" name="GAR93">GAR93</a>
+ </td>
+ <td colspan="2">
+ David Garlan and Mary Shaw. <i>An Introduction to Software Architecture.&nbsp;</i> SEI Technical Report
+ CMU/SEI-94-TR-21.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HOF99" name="HOF99">HOF99</a>
+ </td>
+ <td colspan="2">
+ Christine Hofmeister, Robert Nord, and Dilip Soni 1999. <i>Applied Software Architecture.</i> Addison
+ Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Proposes an alternate set of architectural views and describes the corresponding process. As the views
+ are not too far from the RUP views, this book is an excellent complement to the guidance found in RUP.
+ Contains several examples of architecture from the biomedical field.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IEP1471" name="IEP1471">IEP1471</a>
+ </td>
+ <td colspan="2">
+ <i>IEEE Recommended Practice for Architectural Description</i>, IEEE Std P1471, 2000.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This standard recommends architectural description based on the concept of multiple views, of which the
+ RUP 4+1 view is an example.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC97" name="JAC97">JAC97</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Martin Griss and Patrik Jonsson, 1997. <i>Software Reuse-Architecture, Process and
+ Organization for Business Success</i>. Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great companion book to the RUP, this book offers insights on the design of components and systems of
+ interconnected system, and lays out a strategy for institutionalizing a practice of systematic reuse at
+ the corporate level.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU95" name="KRU95">KRU95</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 1995, "The 4+1 view model of architecture," <i>IEEE Software.</i> 12(6), November
+ 1995.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The origin of the 4+1 views used for architectural description in the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="LMFS96" name="LMFS96">LMFS96</a>
+ </td>
+ <td colspan="2">
+ Lockheed Martin Federal STARS (Software Technology for Adaptable, Reliable Systems) Program. Domain
+ Engineering Guidebook.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This Guidebook provides a high-level description of the Domain Engineering&nbsp; process in the context
+ of a real organization-the U.S. Air Force's Space and Warning Systems Center.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PW92" name="PW92">PW92</a>
+ </td>
+ <td colspan="2">
+ Dewayne E. Perry and Alexander L. Wolf. <i>Foundations for the Study of Software Architecture.</i> ACM
+ SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="REC97" name="REC97">REC97</a>
+ </td>
+ <td colspan="2">
+ Eberhardt Rechtin and Mark Maier 1997. <i>The Art of System Architecting.</i> Boca Ration, FL: CRC
+ Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Although not specifically directed to software engineers, these two books are extremely valuable for
+ software architects: in particular, they introduce an invaluable set of heuristics and many examples of
+ architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="REC91" name="REC91">REC91</a>
+ </td>
+ <td colspan="2">
+ Eberhardt Rechtin 1991. <i>Systems Architecting: creating and building complex systems</i>. Englewood
+ Cliffs NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY91" name="ROY91">ROY91</a>
+ </td>
+ <td colspan="2">
+ Walker E. Royce and Winston Royce, "Software Architecture: Integrating Process and Technology,"
+ <i>Quest,</i> 14 (1), 1991, Redondo Beach, CA: TRW, pp.2-15.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SHA96" name="SHA96">SHA96</a>
+ </td>
+ <td colspan="2">
+ Mary Shaw and David Garlan 1996. <i>Software Architecture-Perspectives on an Emerging Discipline.</i>
+ Upper Saddle River, NJ: Prentice-Hall.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good introduction to the concepts and problems of software architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WIT94" name="WIT94">WIT94</a>
+ </td>
+ <td colspan="2">
+ Bernard I. Witt, F. Terry Baker, and Everett W. Merritt 1994. <i>Software Architecture and
+ Design-Principles, Models, and Methods.</i> New York, NY: Van Nostrand Reinhold.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ One of the first comprehensive book written on software architecture.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2>
+ <a id="Software Development Process references" name="Software Development Process references">Software Development
+ Process</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AMB99" name="AMB99">AMB99</a>
+ </td>
+ <td colspan="2">
+ Scott W. Ambler 1999. <i>More Process Patterns: Delivering Large-Scale Systems Using Object
+ Technology</i>. New York, NY: SIGS Books/Cambridge University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The companion to [AMB98].
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AMB98" name="AMB98">AMB98</a>
+ </td>
+ <td colspan="2">
+ Scott W. Ambler 1998. <i>Process Patterns: Building Large-Scale Systems Using Object Technology</i>.
+ New York, NY: SIGS Books/Cambridge University Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A good resource on process tailoring and applying object-oriented techniques to software engineering
+ projects.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE96" name="BOE96">BOE96</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1996, "Anchoring the Software Process," <i>IEEE Software,</i> July 1996, pp.73-82.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This article defines the four phases and the corresponding milestones.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE88" name="BOE88">BOE88</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1988, "A Spiral Model of Software Development and Enhancement," <i>Computer,</i> May
+ 1988, IEEE, pp.61-72.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This seminal article defines the principles and motivations of iterative development.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COC01" name="COC01">COC01</a>
+ </td>
+ <td colspan="2">
+ Alistair Cockburn 2001. <i>Agile Software Development</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Peers into the team dynamics, the cultures, the communications aspects of software development.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="DOD94" name="DOD94">DOD94</a>
+ </td>
+ <td colspan="2">
+ <i>Software Development and Documentation,</i> MIL-STD-498, U.S. Department of Defense, December 1994.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FER01" name="FER01">FER01</a>
+ </td>
+ <td colspan="2">
+ Xavier Ferre et al. 2001, "Usability Basics for Software Developers," <i>IEEE Software,</i> January
+ 2001, pp. 22-29.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HIG00" name="HIG00">HIG00</a>
+ </td>
+ <td colspan="2">
+ James A. Highsmith 2000. <i>Adaptive Software Development: A Collaborative Approach to Managing Complex
+ Systems</i>. Dorset House.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book is a great companion book to the RUP-a fantastic and convincing plea for iterative
+ development. Very practical advice for the project manager.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="HUM89" name="HUM89">HUM89</a>
+ </td>
+ <td colspan="2">
+ Watts S. Humphrey 1989. <i>Managing the Software Process</i>. Reading, MA: Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A classic book on software process and the capability maturity model developed at the Software
+ Engineering Institute.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ISO95" name="ISO95">ISO95</a>
+ </td>
+ <td colspan="2">
+ ISO/IEC 12207 <i>Information Technology-Software Life-cycle Processes.</i> ISO, Geneva, 1995, 57p.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ISO91" name="ISO91">ISO91</a>
+ </td>
+ <td colspan="2">
+ ISO 9000-3 <i>Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of
+ Software.</i> ISO, Geneva 1991.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Two key standards for software process definition and assessment.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC98" name="JAC98">JAC98</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Grady Booch, and James Rumbaugh 1998. <i>The Unified Software Development Process.</i>
+ Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This recent textbook is a more thorough description of the Unified Process and is a useful companion to
+ the RUP. Also provides examples of UML modeling.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JAC97" name="JAC97">JAC97</a>
+ </td>
+ <td colspan="2">
+ Ivar Jacobson, Martin Griss, and Patrik Jonsson 1997. <i>Software Reuse-Architecture, Process and
+ Organization for Business Success.</i> Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This textbook on software reuse is great complement to the RUP. It features also some great chapters on
+ architecture.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JEF01" name="JEF01">JEF01</a>
+ </td>
+ <td colspan="2">
+ Ron Jeffries, Ann Anderson, and Chet Hendrickson 2001. <i>Extreme Programming Installed.</i>
+ Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book describes practical Extreme Programming techniques.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU96" name="KRU96">KRU96</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 1996. "A Rational Development Process"<i>,</i> <i>CrossTalk</i>, 9 (7), July 1996,
+ p.11-16.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Developed with Walker Royce, Sue Mickel, and a score of Rational consultants, this article describes
+ the iterative lifecycle of the Rational Process.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU91" name="KRU91">KRU91</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 1991. "Un processus de dévelopment de logiciel itératif et centré sur
+ l´architecture", <i>Proceedings of the 4th International Conference on Software Engineering, December
+ 1991</i>, Toulouse, France, EC2.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The Rational iterative process in French.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRU00" name="KRU00">KRU00</a>
+ </td>
+ <td colspan="2">
+ Philippe Kruchten 2000. <i>The Rational Unified Process, An Introduction, Second Edition.</i> Addison
+ Wesley Longman.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Indespensible as an introductory text, this "mile wide, inch deep" overview quickly introduces you to
+ the concepts, structure, content, and motivation of the RUP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRO03" name="KRO03">KRO03</a>
+ </td>
+ <td colspan="2">
+ Per Kroll and Philippe Kruchten 2003. <i>The Rational Unified Process Made Easy, A Practitioners Guide
+ to the RUP.</i> Addison Wesley Longman.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A practical guide to adopting the spirit, principles and practices of the RUP. An invaluable resource
+ in helping you decide how to apply the RUP in your organization or project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MCF96" name="MCF96">MCF96</a>
+ </td>
+ <td colspan="2">
+ Robert McFeeley 1996. <i>IDEAL: A User's Guide for Software Process Improvement.</i> Software
+ Engineering Institute, Pittsburgh, PA, CMU/SEI-96-HB-001.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Describes a software process improvement program model called IDEAL, a generic description of a
+ sequence of recommended steps for initiating and managing a process implementation project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PAR86" name="PAR86">PAR86</a>
+ </td>
+ <td colspan="2">
+ David L. Parnas and Paul C. Clements, "A Rational Design Process: How and Why to Fake It", <i>IEEE
+ Trans. Software Eng.,</i> Feb. 1986, pp.251-257.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="PAU93" name="PAU93">PAU93</a>
+ </td>
+ <td colspan="2">
+ Mark Paulk, et al. 1993. <i>Capability Maturity Model for Software, Version 1.1.</i> Software
+ Engineering Institute, Pittsburgh, PA SEI-93-TR-024.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ The original reference for the capability maturity model.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY90" name="ROY90">ROY90</a>
+ </td>
+ <td colspan="2">
+ Walker E. Royce, "TRW's Ada Process Model for Incremental Development of Large Software Systems",
+ <i>Proceedings ICSE 12, March 26-30, 1990,</i> Nice, France, IEEE, pp.2-11.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="ROY70" name="ROY70">ROY70</a>
+ </td>
+ <td colspan="2">
+ Winston W. Royce, "Managing the Development of Large Software Systems: Concepts and Techniques",
+ <i>Proceedings, WESCON</i>, August 1970.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<h2 align="left">
+ <a id="Testing and Quality references" name="Testing and Quality references">Testing and Quality</a>
+</h2>
+<div align="center">
+ <table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BAC01a" name="BAC01a">BAC01a</a>
+ </td>
+ <td colspan="2">
+ James Bach 2001. <i>What Is Exploratory Testing? (And How It Differs from Scripted Testing).</i>
+ Software Testing and Quality Engineering Magazine, Jan 29, 2001.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This article is available online at <a
+ href="http://www.stickyminds.com/sitewide.asp?sid=582697&amp;sqry=%2AJ%28MIXED%29%2AR%28createdate%29%2AK%28simplesite%29%2AF%28what+is+exploratory+testing%29%2A&amp;sidx=0&amp;sopp=10&amp;ObjectId=2255&amp;Function=DETAILBROWSE&amp;ObjectType=COL"
+ target="_blank">http://www.stickyminds.com</a>.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BAS87" name="BAS87">BAS87</a>
+ </td>
+ <td colspan="2">
+ BAS87 Victor R. Basili and H. Dieter Rombach 1987. <i>Tailoring the Software Process to Project Goals
+ and Environments.</i> Proceedings of the 9th International Conference on Software Engineering Software,
+ IEEE Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEI95" name="BEI95">BEI95</a>
+ </td>
+ <td colspan="2">
+ Boris Beizer 1995. <i>Black Box Testing.</i> New York, NY: John Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Various strategies to develop test cases for the functional testing of software. Dr. Beizer's writing
+ style and wit make this book easy and fun to read, with excellent, understandable examples.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BLA99" name="BLA99">BLA99</a>
+ </td>
+ <td colspan="2">
+ Rex Black 1999. <i>Managing the Testing Process.</i> Microsoft Press.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book is a good source of information about managing system testing teams.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="GLA81" name="GLA81">GLA81</a>
+ </td>
+ <td colspan="2">
+ Robert L. Glass 1981. <i>Persistent Software Errors.</i> IEEE Transactions on Software Engineering,
+ March 1981.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="IE829" name="IE829">IE829</a>
+ </td>
+ <td colspan="2">
+ IEEE 829-1983 <i>Standard for Software Test Documentation.</i> Software Engineering Standards Committee
+ of the IEEE Computer Society, New York.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAN01" name="KAN01"></a>KAN01
+ </td>
+ <td colspan="2">
+ Cem Kaner, James Bach, and Bret Pettichord 2001. <i>Lessons Learned in Software Testing.</i> John Wiley
+ &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A wealth of tips and tricks that help to address a wide variety of issues faced in the testing of
+ computer software. Broad coverage of management, psychological as well as the technical aspects of
+ software testing. Valuable guidance for the novice and the expert alike.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KAN99" name="KAN99"></a>KAN99
+ </td>
+ <td colspan="2">
+ Cem Kaner, Jack Falk, and Hung Quoc Nguyen 1999. <i>Testing Computer Software, 2nd Edition.</i> John
+ Wiley &amp; Sons, Inc.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="12%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Billed as "The best-selling software testing book of all time", this book offers a broad coverage of
+ various aspects of software testing.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MAR00" name="MAR00">MAR00</a>
+ </td>
+ <td colspan="2">
+ Brian Marick 2000. <i>Faults of Omission.</i> Software Testing and Quality Engineering Magazine,
+ March-April 2000.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="12%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This article is available online at: <a href="http://www.testing.com/writings/omissions.pdf"
+ target="_blank">http://www.testing.com/writings/omissions.pdf</a>.<br />
+ (<a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Get Adobe Reader</a>)
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="MYE79" name="MYE79">MYE79</a>
+ </td>
+ <td colspan="2">
+ Glenford J. Myers 1979. <i>The Art of Software Testing</i>, John Wiley &amp; Sons, Inc., New York.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This is one of the classic works of software testing literature. Even today this timelesss text offers
+ useful, practical, and relevent guidance.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="OST84" name="OST84">OST84</a>
+ </td>
+ <td colspan="2">
+ Thomas J. Ostrand and Elaine J. Weyuker 1984. <i>Collecting and Categorizing Software Error Data in an
+ Industrial Environment.</i> Journal of Systems and Software, Vol. 4, 1984.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/resources/circleOfLife.jpg b/XP/XP_baseline_EN/library/xp/customcategories/resources/circleOfLife.jpg
new file mode 100644
index 0000000..3772826
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/resources/circleOfLife.jpg
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/resources/extreme_programming,5.2637267673584526E-306.html b/XP/XP_baseline_EN/library/xp/customcategories/resources/extreme_programming,5.2637267673584526E-306.html
new file mode 100644
index 0000000..3eb88af
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/resources/extreme_programming,5.2637267673584526E-306.html
@@ -0,0 +1,273 @@
+<html xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Concept: Extreme Programming</title>
+<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
+<meta name="element_type" content="concept">
+<meta content="description" name="filetype">
+<meta name="role" content="">
+<link type="text/css" href="./../../../css/default.css" rel="StyleSheet">
+<script src="./../../../scripts/contentpage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
+ backPath = './../../../';
+ </script>
+</head>
+<body onload="createSectionLinks('div', 'sectionHeading', './../../../images/');">
+<table width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr>
+<td valign="top"><a name="Top"></a>
+<table cellpadding="0" cellspacing="0" border="0">
+<tr>
+<td class="pageTitle">Concept: Extreme Programming</td>
+</tr>
+</table>
+<table cellspacing="0" cellpadding="0" border="0" width="100%">
+<tr>
+<td class="pageTitleSeparator"><img height="1" alt="" src="./../../../images/shim.gif"></td>
+</tr>
+</table>
+<div class="overview">
+<table cellpadding="0" cellspacing="0" border="0" width="97%">
+<tr>
+<td>
+<table cellpadding="0" cellspacing="0" border="0" class="overviewTable">
+<tr>
+<td valign="top"></td>
+</tr>
+</table>
+</td>
+</tr>
+</table>
+</div>
+<div class="sectionHeading">Main Description</div>
+<div class="sectionContent">
+<table cellpadding="0" cellspacing="0" border="0" class="sectionTable">
+<tr valign="top">
+<td class="sectionTableCell"><a id="XE_xp__conceptual_process_roadmap" name="XE_xp__conceptual_process_roadmap"></a><a id="XE_roadmap__for_xp_practices" name="XE_roadmap__for_xp_practices"></a>
+<h3>
+ Topics
+</h3>
+<div align="left">
+ <table width="70%" border="1">
+ <tbody valign="top">
+ <tr>
+ <td width="315" height="178">
+ <ul>
+ <li>
+ <a href="#Introduction">Introduction</a>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <a href="#About">About XP</a>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>
+ <br />
+ <br />
+ </p>
+ <ul>
+ <li>
+ <a href="#Characteristics">Characteristics of an XP Project</a>
+ </li>
+ <li>
+ <a href="#GettingStarted">How to Get Started</a>
+ </li>
+ <li>
+ <a href="#Phases">Phases and Iterations</a>
+ </li>
+ </ul>
+ </td>
+ <td width="315" height="178">
+ <b>Additional Guidance:</b>
+ <ul>
+ <li>
+ Guidelines
+ <ul>
+ <li>
+ <a class="elementLink" href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html" guid="8.137126904637637E-306">Refactoring</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html" guid="3.9254165491375454E-306">Test First Development</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html" guid="3.85153041801319E-307">Pair Programming</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html" guid="6.7335956461328426E-307">Planning Game</a>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <br />
+ <br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../../xp/guidances/supportingmaterials/bup_xp_plug-in_resource_center,2.315717433735515E-305.html" guid="2.315717433735515E-305">Additional XP Resources</a>
+ </li>
+ </ul>
+ <b>Additional Concepts:</b>
+ <ul>
+ <li>
+ <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a>
+ </li>
+ </ul>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<br />
+<h1>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h1>
+<p>
+ This roadmap provides information for getting started and applying the practices of eXtreme Programming (XP) to a
+ software development project. The roadmap can be used as a guide to the content delivered in the BUP XP Plug-In.
+</p>
+<h3>
+ <a id="About" name="About">About XP</a>
+</h3>
+<p>
+ Extreme Programming is an instance of an <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a> method. XP is a method that is optimized for small to
+ medium-sized project teams that fit a certain profile. It promotes rapid feedback and response to continual change. It
+ is based upon the four <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">values</a> of simplicity, communication, feedback, and courage and is consistent with the
+ values of agile software development.
+</p>
+<br />
+<p>
+ Extreme Programming is an instance of an agile method for developing software. It is based upon the core principle of
+ agility and consists of twelve practices that, when applied to an appropriate software development project, can produce
+ high-quality software. If you are unfamiliar with the concepts surrounding XP, you should start by reading <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a>.
+</p>
+<h3>
+ <a id="Characteristics" name="Characteristics">Characteristics of an XP Project</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium-sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. Since XP relies heavily on
+ direct and frequent communication between the team members, the team should be co-located. An ideal project for using
+ XP would be one that has most of the following characteristics:
+</p>
+<ul>
+ <li>
+ A small to medium-sized team (fewer than 20 people on the complete team)
+ </li>
+ <li>
+ Co-located, preferably in a single area with a large common space
+ </li>
+ <li>
+ A committed, full-time, on-site customer or customer representative
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <br />
+ </li>
+</ul>
+<h3>
+ <a id="Phases" name="Phases">Phases and Iterations</a>
+</h3>
+<p>
+ An XP project is one that is based on rapid feedback through short iterations and frequent releases. BUP and XP share a
+ fundamental belief that iterative development is the best way to deliver valuable software to your customers. The
+ concept of phases, as usually described in a BUP configuration, is somewhat different. Decisions described in the BUP
+ phases that define milestones occur, but they are not called specifically as defining phases. For a discussion of how
+ the phases are related to an XP project, see the discussion of <a class="elementLinkWithUserText" href="./../../../xp/deliveryprocesses/bup_phases_and_xp,{63BD15C5-40EF-469A-A22A-3291734B60F4}.html" guid="{63BD15C5-40EF-469A-A22A-3291734B60F4}">Phases</a>.
+</p>
+<h3>
+ <a id="GettingStarted" name="GettingStarted">How to Get Started</a>
+</h3>
+<p>
+ This section provides a recommended way to approach XP for your project. You don't have to follow the steps as
+ specified, but if you have little experience with XP, we recommend following them as closely as possible the first
+ time.
+</p>
+<table cellspacing="2" cellpadding="1" width="91%" border="1">
+ <tbody>
+ <tr>
+ <th width="10%">
+ Step
+ </th>
+ <th align="left" width="47%">
+ Do this ...
+ </th>
+ <th align="left" width="43%">
+ in order to...
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 1
+ </td>
+ <td width="47%">
+ Familiarize yourself with the <a class="elementLink" href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html" guid="1.6390805262958034E-306">motivation</a> for using XP, the <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html" guid="9.251272550276345E-306">short description</a> of XP, and the <a class="elementLink" href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP Practices</a>
+ </td>
+ <td width="43%">
+ understand the fundamental principles of XP and how the practices support each other.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 2
+ </td>
+ <td width="47%">
+ Read the key concepts of <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a>
+ </td>
+ <td width="43%">
+ understand the collaborative and social aspects of XP.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 3
+ </td>
+ <td width="47%">
+ Determine if XP is appropriate for your project by reviewing <a href="#Characteristics">The Characteristics
+ of an XP Project</a>
+ </td>
+ <td width="43%">
+ decide if XP may be appropriate for your project.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 4
+ </td>
+ <td width="47%">
+ Read about the <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/xp_environment,3.754748120034442E-307.html" guid="3.754748120034442E-307">XP Environment</a>.
+ </td>
+ <td width="43%">
+ prepare the physical and tool environment for your team.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 5
+ </td>
+ <td width="47%">
+ Read the <a class="elementLink" href="./../../../xp/guidances/supportingmaterials/getting_started_with_xp,1.2284921351651456E-304.html" guid="1.2284921351651456E-304">Getting Started with XP</a> guidelines.
+ </td>
+ <td width="43%">
+ get suggestions on how to start an XP project.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<br />
+<br />
+<br /></td>
+</tr>
+</table>
+</div>
+<table cellpadding="0" cellspacing="0" border="0" class="copyright">
+<tr>
+<td class="copyright"></td>
+</tr>
+</table>
+</td>
+</tr>
+</table>
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/resources/xp_getting_started_guidelines.htm b/XP/XP_baseline_EN/library/xp/customcategories/resources/xp_getting_started_guidelines.htm
new file mode 100644
index 0000000..983817c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/resources/xp_getting_started_guidelines.htm
@@ -0,0 +1,79 @@
+<!-- RPW META DATA START --
+<rpw name="MetaData" meta_value="anonymous" meta_name="element_type"></rpw>
+<rpw name="MetaData" meta_value="guideline" meta_name="filetype"></rpw>
+-- RPW META DATA END -->
+
+<html>
+
+<head>
+<link rel="stylesheet" href="../../../rop.css" type="text/css">
+<title>Guidelines: <rpw name="InsertPresentationName"></rpw></title>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+
+<body>
+
+<rpw name="Warning"><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b><br></rpw>
+<rpw name="Include">rpw/startBorder.rpw</rpw>
+<rpw name="Warning"><br><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b></rpw>
+
+
+<h1 class="banner"><a name="Top"></a>Guidelines: <rpw name="PresentationName">Adopting
+ XP Practices</rpw> <a name="XE_xp__adopting_practices"></a><a name="XE_adopting_practices__in_xp"></a></h1>
+<p>XP is a set of synergistic practices. Because the practices depend upon each
+ other, people often wonder where they should start. In general, we recommend
+ that you stop and consciously decide to adopt as many of the XP practices as
+ possible.</p>
+<p>However, if that induces too much stress, consider adopting the practices in
+ this order.</p>
+<p><b><a href="../../../components/pc_xp_essentials/pc_xp_integration/co_continuous_integration.htm">Establish
+ a solid build process</a></b>. If you are not able to reliably build the software
+ you are working on, you can&8217;t really go further. Once you have a reliable
+ build process, make sure that you run whatever <a href="../../../components/pc_xp_essentials/pc_xp_testing/co_customer_tests.htm">tests</a>
+ you have prior to each checking.</p>
+<p><b><a href="../../../components/pc_xp_essentials/pc_xp_programming/co_pair_program.htm">Pair
+ programming</a></b> is often a significantly different way of working for most
+ developers. It takes a little bit of time to get used to it, but as a team does,
+ they recognize that they are a much more powerful team because everyone’s
+ knowledge of the system grows rapidly. In addition, quality goes up because
+ there are two sets of eyes on all work as it is being done. When you adopt pair
+ programming, ideally you should have an <a href="../../../components/pc_xp_essentials/pc_xp_management/xp_open_workspace_guidelines.htm">open
+ workspace</a>.</p>
+<p>As your team gets started with pair programming, you should adopt the <b><a href="../../../components/pc_xp_essentials/co_planning_game.htm">Planning
+ Game</a></b>. The Planning Game will help you identify good goals for your next
+ release, iteration, and day of work. At the end of your first iteration, you
+ will have a velocity that you can use to get a sense of how long it takes you
+ do do your work. As you do your planning, talk to your customer about producing
+ acceptance tests and being available to the team.</p>
+<p>As you work together on your first iteration, try doing <a href="../../../components/pc_xp_essentials/co_test_driven_development.htm"><b>test-driven
+ development</b></a>. It will feel strange at first. If it doesn’t, you
+ are probably doing it wrong. Over time, it will feel like a more natural way
+ to develop software. Recognize that, at first, your velocity will be rather
+ low. This is a side effect of the learning process. Over the next few iterations
+ your speed will increase.</p>
+<p>As you move forward, learn how to <a href="../../../components/pc_xp_essentials/pc_xp_programming/co_refactoring.htm"><b>refactor</b></a>
+ and start to practice <a href="../../../components/pc_xp_essentials/co_collective_code_ownership.htm"><b>collective
+ code ownership</b></a>. Often collective code ownership is a little scary at
+ first, but as you pair, you will notice that everyone is learning what it takes
+ to work with the system. When people volunteer for tasks, they either volunteer
+ only for what they know how to do or for things that they can get help on from
+ a partner.</p>
+<p>Once you have a few iterations under your belt, you will be able to understand
+ how the process works and how the different practices interact and support each
+ other. Finally, listen to the feedback coming from your team. That feedback
+ is critical and can be used to improve and adapt the process to your team’s
+ particular needs and problems.</p>
+
+
+<p><br/><br/></p>
+
+<rpw name="Warning"><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b><br></rpw>
+<rpw name="Include">rpw/endBorderOmRat.rpw</rpw>
+<rpw name="Include">rpw/endBorder.rpw</rpw>
+<rpw name="Warning"><br><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b></rpw>
+
+</body>
+
+</html>
+
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/resources/xp_practices,2.2937799026801584E-305.html b/XP/XP_baseline_EN/library/xp/customcategories/resources/xp_practices,2.2937799026801584E-305.html
new file mode 100644
index 0000000..f77493f
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/resources/xp_practices,2.2937799026801584E-305.html
@@ -0,0 +1,115 @@
+<html xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>Concept: XP Practices</title>
+<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
+<meta name="element_type" content="concept">
+<meta content="description" name="filetype">
+<meta name="role" content="">
+<link type="text/css" href="./../../../css/default.css" rel="StyleSheet">
+<script src="./../../../scripts/contentpage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
+ backPath = './../../../';
+ </script>
+</head>
+<body onload="createSectionLinks('div', 'sectionHeading', './../../../images/');">
+<table width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr>
+<td valign="top"><a name="Top"></a>
+<table cellpadding="0" cellspacing="0" border="0">
+<tr>
+<td class="pageTitle">Concept: XP Practices</td>
+</tr>
+</table>
+<table cellspacing="0" cellpadding="0" border="0" width="100%">
+<tr>
+<td class="pageTitleSeparator"><img height="1" alt="" src="./../../../images/shim.gif"></td>
+</tr>
+</table>
+<div class="overview">
+<table cellpadding="0" cellspacing="0" border="0" width="97%">
+<tr>
+<td>
+<table cellpadding="0" cellspacing="0" border="0" class="overviewTable">
+<tr>
+<td valign="top"></td>
+</tr>
+</table>
+</td>
+</tr>
+</table>
+</div>
+<div class="sectionHeading">Main Description</div>
+<div class="sectionContent">
+<table cellpadding="0" cellspacing="0" border="0" class="sectionTable">
+<tr valign="top">
+<td class="sectionTableCell"><a id="XE_xp__practices_of" name="XE_xp__practices_of"></a><a id="XE_practices_in__xp" name="XE_practices_in__xp"></a>
+<p>
+ XP is a collection of guiding values and best practices. Most of these practices have been used in the industry in some
+ shape or form for a number of years. XP has simply identified them and tried to push the envelope of these practices in
+ order to get the most benefit from them. Taken individually, these practices are all fairly simple. But it is the sum
+ of all of them that provides the most benefit as they reinforce each other to address the most difficult problems teams
+ encounter when developing software.
+</p>
+<br />
+<br />
+<p>
+ <img height="540" alt="" src="./../../../xp/resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map" border="0" /> <map id="xp_practices_image_map" name="xp_practices_image_map">
+ <area shape="RECT" coords="298,19,390,88" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
+ <area shape="RECT" coords="176,135,282,200" href="./../../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
+ <area shape="RECT" coords="297,168,434,231" href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
+ <area shape="RECT" coords="447,135,547,198" href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
+ <area shape="RECT" coords="15,236,122,305" href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
+ <area shape="RECT" coords="218,238,362,307" href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
+ <area shape="RECT" coords="392,241,512,305" href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
+ <area shape="RECT" coords="614,236,714,302" href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
+ <area shape="RECT" coords="143,325,270,393" href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
+ <area shape="RECT" coords="310,321,412,379" href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
+ <area shape="RECT" coords="468,323,597,393" href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
+ <area shape="RECT" coords="307,386,413,436" href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
+ <area shape="RECT" coords="312,475,419,539" href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
+ <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
+ </map>
+</p>
+<p>
+ This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
+ exemplifies the steering and control cycles of the process.
+</p>
+<p>
+ The outer red circle is called the "Circle of Life". It's what keeps an XP project going, producing tested working
+ software. The <a class="elementLink" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole Team</a>, customer members and development members, work together--preferably
+ physically together--to build the project. Using the <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" guid="2.7371805612676613E-305">Planning Game</a> elements of Release Planning and Iteration Planning, they plan a
+ series of <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" guid="5.762953011420275E-306">Small
+ Releases</a> of software that demonstrably pass all the <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" guid="2.297945473205673E-305">Customer Tests</a>.
+</p>
+<p>
+ The innermost blue circle describes the day to day, moment to moment, work of the XP developers. Each feature is
+ addressed with <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" guid="1.6109092258980447E-306">Simple Design</a>, ensuring that the design of the system is just right for the features
+ supported. The programmers work in <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" guid="3.876855509996079E-307">pairs</a> for all production code development, providing continuous code review and
+ valuable, team-wide understanding of the system. They build the software using <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" guid="1.620567348185129E-306">Test-Driven Development,</a> a technique that produces well-crafted and well-tested
+ software with a minimum of wasted effort, and the design is kept clean by the continuous improvement process of <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" guid="1.4410217108363206E-306">Refactoring</a>.
+</p>
+<p>
+ The middle green circle contains the important supporting practices of XP. The software is designed according to a
+ common, shared, evolving <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" guid="4.884861766532753E-306">Metaphor</a> that helps it all hang together. It is kept <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" guid="3.193414568279561E-305">continuously integrated</a> with many system builds every day, each one fully tested. The
+ team shares ownership of of all the code so that needed changes can be made by any qualified pair, not just by one
+ individual. Since everyone works on everything, the team evolves a <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" guid="8.8116853923311E-307">standard
+ way of coding</a>. Finally, XP teams work at a <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" guid="3.133529870649493E-306">sustainable pace</a> that enables them to deliver tested software on a predictable basis
+ from the first day of the project until the last.
+</p>
+<p>
+ <br />
+
+</p></td>
+</tr>
+</table>
+</div>
+<table cellpadding="0" cellspacing="0" border="0" class="copyright">
+<tr>
+<td class="copyright"></td>
+</tr>
+</table>
+</td>
+</tr>
+</table>
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/xp_best_practices.xmi b/XP/XP_baseline_EN/library/xp/customcategories/xp_best_practices.xmi
new file mode 100644
index 0000000..b1d62db
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/xp_best_practices.xmi
@@ -0,0 +1,83 @@
+<?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" epf:version="1.0.0" xmi:id="-LVHbtWMGC3pAL9abD018MA" name="xp_best_practices,4.315031901943112E-306" guid="-LVHbtWMGC3pAL9abD018MA" changeDate="2006-12-01T15:22:33.700-0800" version="1.0.0">
+ <mainDescription><p>
+ Extreme Programming is based on core values of <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">communication,
+ simplicity, feedback, and courage</a>. These are not just buzzwords: they pervade the behavior of XP practitioners and
+ the choice of XP practices.
+</p>
+<p>
+ More than anything else, XP is about people, people coming together and working together to build software. The
+ practices of XP are there to enable people to work together; the practices try never to get in the way of the human
+ enterprise of building software that meets business needs. Thus, the practices of XP, while quite disciplined, are
+ there to enable interactions among individuals, never to replace or interfere with those interactions.
+</p>
+<h3>
+ XP Practices
+</h3>
+<p>
+ <b><a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html"
+ guid="2.2937799026801584E-305">Overview</a></b>
+</p>
+<ul>
+ <li>
+ <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html"
+ guid="2.7371805612676613E-305">Planning Game</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html"
+ guid="5.762953011420275E-306">Small Releases</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html"
+ guid="2.297945473205673E-305">Customer Tests</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html"
+ guid="1.6109092258980447E-306">Simple Design</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html"
+ guid="3.876855509996079E-307">Pair Programming</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
+ guid="1.620567348185129E-306">Test Driven Development</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
+ guid="1.4410217108363206E-306">Refactoring</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html"
+ guid="4.884861766532753E-306">Metaphor</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html"
+ guid="3.193414568279561E-305">Continuous Integration</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html"
+ guid="9.300699588493279E-306">Collective Ownership</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html"
+ guid="8.8116853923311E-307">Coding Standard</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html"
+ guid="3.133529870649493E-306">Sustainable Pace</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/xp_roles_and_tasks.xmi b/XP/XP_baseline_EN/library/xp/customcategories/xp_roles_and_tasks.xmi
new file mode 100644
index 0000000..fc6b18a
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/xp_roles_and_tasks.xmi
@@ -0,0 +1,94 @@
+<?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" epf:version="1.0.0" xmi:id="-c5D4uYtVcDvab8GzkO0HiQ" name="xp_roles_and_activities,3.967980776087095E-306" guid="-c5D4uYtVcDvab8GzkO0HiQ" changeDate="2006-11-29T16:43:23.824-0800" version="1.0.0">
+ <mainDescription><a id="XE_activities__overview_of_xp_and_rup_activities" name="XE_activities__overview_of_xp_and_rup_activities"></a>
+<div align="left">
+ <table width="75%" border="1">
+ <tbody>
+ <tr>
+ <td width="6%" rowspan="2">
+ &nbsp;
+ </td>
+ <td align="middle" colspan="5">
+ <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" colspan="2">
+ <a class="elementLink"
+ href="./../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>
+ </td>
+ <td align="middle">
+ <a class="elementLink"
+ href="./../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>
+ </td>
+ <td align="middle" colspan="2">
+ <a class="elementLink"
+ href="./../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
+ guid="5.613949040902463E-308">XP Organization</a>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle">
+ <b>XP Roles</b>
+ </td>
+ <td align="middle" width="17%">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}.html"
+ guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">Customer</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}.html"
+ guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">Tester</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}.html"
+ guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}">Programmer</a>
+ </td>
+ <td align="middle" width="13%">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
+ guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">Tracker</a>
+ </td>
+ <td align="middle" width="12%">
+ <a class="elementLinkWithUserText"
+ href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">Coach</a>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<br />
+<h3>
+ XP Roles and Tasks
+</h3>
+<p>
+ XP defines a more limited set of roles and tasks than Unified Process. The XP roles usually have much broader scope
+ than Unified Process roles. There is a definite push in XP to move away from specialization where only one person on a
+ team has knowledge of specific and critical parts of the system or technology. The consequence is that the XP roles
+ usually map to more than one Unified Process role. Some Unified Process roles/tasks/artifacts do not map to anything in
+ XP as XP has a somewhat smaller scope than Unified Process.
+</p>
+<h4>
+ Definition of Roles and Tasks in Unified Process
+</h4>
+<p>
+ <b>Roles</b> are typically realized by an individual or a set of individuals working together as a team. A project team
+ member typically fulfills many different roles. <b>Roles</b> are not individuals; instead, they describe how
+ individuals behave in the business and what responsibilities these individuals have. While most roles are realized by
+ people within the organization, people outside of the development organization play an important role. A <b>role</b> is
+ an abstract definition of a set of <b>tasks</b> performed and <b>artifacts</b> generated.
+</p>
+<p>
+ <b>Roles</b> have a set of cohesive&nbsp;<b>tasks</b> to be performed. These&nbsp;<b>tasks</b> are closely related and
+ functionally coupled and are often best performed by the same individual.&nbsp;Tasks are closely related to
+ <b>artifacts</b>. Artifacts provide the input and output for the&nbsp;tasks and the mechanism by which information is
+ communicated between tasks.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/customcategories/xp_white_papers.xmi b/XP/XP_baseline_EN/library/xp/customcategories/xp_white_papers.xmi
new file mode 100644
index 0000000..af9d616
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/customcategories/xp_white_papers.xmi
@@ -0,0 +1,20 @@
+<?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" epf:version="1.0.0" xmi:id="-_GqtAEsGnq12qQmyqWdHHQ" name="xp_white_papers,6.505229665845286E-306" guid="-_GqtAEsGnq12qQmyqWdHHQ" changeDate="2005-12-06T04:42:48.153-0800">
+ <mainDescription><p>
+ Additional white papers related to XP can be found at:
+</p>
+<p>
+ White papers relate to the <a href="http://www.objectmentor.com/processImprovement/xpRupResourceCenter/index%20">BUP XP
+ Plug-In Resource Center</a>.
+</p>
+<p>
+ White papers related to Agile methods and Object Oriented Programming at <a
+ href="http://www.objectmentor.com/resources" target="_blank">http://www.objectmentor.com/resources</a><a
+ href="http://www.objectmentor.com"></a>
+</p>
+<br />
+<br />
+<br />
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/agile_software_development.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/agile_software_development.xmi
new file mode 100644
index 0000000..934aba0
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/agile_software_development.xmi
@@ -0,0 +1,76 @@
+<?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" epf:version="1.0.0" xmi:id="-EHSlFv7Gla5oCPGBiaZKow" name="agile_software_development,1.041091673844025E-305" guid="-EHSlFv7Gla5oCPGBiaZKow" changeDate="2006-11-29T15:32:13.357-0800" version="1.0.0">
+ <mainDescription><a id="XE_agile_software_development__process_differentiators"
+name="XE_agile_software_development__process_differentiators"></a>
+<h2>
+ <a id="Intro" name="Intro">Introduction</a>
+</h2>
+<p>
+ Extreme Programming is probably the best known and very likely the most used of what have come to be known as agile
+ software development methods. There are many software professionals working on agile methods today. There have been
+ several international conferences on agile methods, numerous papers, many websites, and quite a few books. We'll key
+ our discussion from the Agile Manifesto at <a href="http://www.agilemanifesto.org"
+ target="_blank">www.agilemanifesto.org</a>.
+</p>
+<p>
+ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have
+ come to value:
+</p>
+<h2>
+ <a id="Individuals" name="Individuals">Individuals and Interactions Over Processes and Tools</a>
+</h2>
+<p>
+ Processes and tools are very important. We wouldn't be writing this and you wouldn't be reading it were that not true.
+ The best processes and tools, we believe, are those that enable the individuals who are part of a software project to
+ do their job most effectively. To do that, the processes and tools need to facilitate the human interactions that bring
+ about understanding and cooperation. The agile methods use the smallest amount of process that's safe and the simplest
+ tools that are effective in aid of those individuals and interactions.
+</p>
+<h2>
+ <a id="Working" name="Working">Working Software Over Comprehensive Documentation</a>
+</h2>
+<p>
+ Documentation can be very important to a software project. Sometimes it's the only way to communicate ideas across
+ space and time. For an ongoing software project, however, there is a much better way to know what's going on and to
+ steer the project.
+</p>
+<p>
+ Observe the software. The software can be tested, used, and inspected, and all the answers you get are unambiguous. The
+ agile methods focus on keeping the software visible, beginning as early as possible. The best XP projects begin
+ producing tested visible software in the first couple of weeks of the project and never stop.
+</p>
+<h2>
+ <a id="Customer" name="Customer">Customer Collaboration Over Contract Negotiation</a>
+</h2>
+<p>
+ Many software projects require a contract, and all benefit from a clear understanding of what will be done. Attempts to
+ over-constrain the initial understanding, however, almost always backfire. Too often, the result can be a "letter of
+ the law" product that pleases neither the developers nor the users. Agile methods recognize that all stakeholders will
+ be learning over the course of the project. Agile projects are thus set up to facilitate learning and to take advantage
+ of it.
+</p>
+<h2>
+ <a id="Responding" name="Responding">Responding to Change Over Following a Plan</a>
+</h2>
+<p>
+ Too many changes of direction can cause a project to go out of control, costing too much or never finishing. Initial
+ plans, however, cannot know which potential changes should be accommodated and which ignored. Agile methods address
+ this issue in two ways:
+</p>
+<p>
+ First, they respond to change by planning publicly and often. Small changes are dealt with in frequent in-team small
+ planning sessions, while the big picture is published and processed by all stakeholders, again very frequently.
+</p>
+<p>
+ Second, the development techniques in the agile methods generally allow stakeholders to substitute new and better ideas
+ for earlier notions without exorbitant increases in costs.
+</p>
+<h2>
+ <a id="Summary" name="Summary">Summary</a>
+</h2>
+<p>
+ As you study Extreme Programming and as you use it, it's important to keep these agile values in mind. As you tune and
+ adjust the process to your situation, working with the values will enable you to get the best results from the least
+ effort.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/coding_standard.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/coding_standard.xmi
new file mode 100644
index 0000000..d5f0a6b
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/coding_standard.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="--qg2qc3dqmgeB63Nx7Zndg" name="coding_standard,8.8116853923311E-307" guid="--qg2qc3dqmgeB63Nx7Zndg" changeDate="2006-11-09T16:13:06.585-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__coding_standard" name="XE_xp__coding_standard"></a><a id="XE_coding_standard__practice_of"
+name="XE_coding_standard__practice_of"></a><a id="XE_engineering_practices__coding_standard"
+name="XE_engineering_practices__coding_standard"></a>
+<h3>
+ Description
+</h3>
+<p>
+ Using a coding standard is a software development practice that has been widely accepted in the industry. The need for
+ this practice takes on added importance in XP because of the increased level of communication required by collective
+ ownership, pair programming and the constant refactoring of the code. The team should have a standard way of naming and
+ formatting things so they can understand the code quickly and know where to look at all times.
+</p>
+<p>
+ Ideally, the coding standard should be the result of team consensus. In some cases, decisions will be arbitrary
+ (placement of braces). Each item in the standard should support one or more goals, improved communication being one of
+ the most critical goals. Once the team agrees on a standard, all members of the teams are expected to follow it. Pair
+ programming and collective code ownership is sufficient to reinforce the use of the standard within the team. With
+ time, the team will use and modify the standard to develop a style that is well adapted to their environment.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Improved communication</b>: increases the ability to read each other's code.
+ </li>
+ <li>
+ <b>Refactoring support</b>: provides consistently shaped code.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/collective_ownership.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/collective_ownership.xmi
new file mode 100644
index 0000000..23cdb73
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/collective_ownership.xmi
@@ -0,0 +1,36 @@
+<?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" epf:version="1.0.0" xmi:id="-YP0i7TC6QNgemddcj1iE7g" name="collective_ownership,9.300699588493279E-306" guid="-YP0i7TC6QNgemddcj1iE7g" changeDate="2006-11-13T14:36:27.348-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__collective_ownership" name="XE_xp__collective_ownership"></a><a id="XE_collective_ownership__practice_of"
+name="XE_collective_ownership__practice_of"></a><a id="XE_engineering_practices__collective_ownership"
+name="XE_engineering_practices__collective_ownership"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The practice of collective ownership states that any member of the team can change any piece of code in the system at
+ any time.
+</p>
+<p>
+ Having a good suite of tests and being able to integrate continuously is critical to ensuring that this practice works
+ well. Without the tests, it would be impossible to know that a critical piece of the system was modified improperly
+ because of inappropriate understanding. Integrating frequently and testing ensures that such problems are caught and
+ fixed quickly. Used with pair programming, collective code ownership is an effective way to spread the knowledge of the
+ system across the entire team.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Shared knowledge of the code</b>: allows programmers to become familiar with more of the code and benefit from
+ the experience of others.
+ </li>
+ <li>
+ <b>Simpler code</b>: causes complex code to be found and refactored more quickly as many pairs of eyes read the
+ same code.
+ </li>
+ <li>
+ <b>Get things done quickly</b>: removes hurdles so changes can be made by those that need them when they need them.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/continuous_integration.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/continuous_integration.xmi
new file mode 100644
index 0000000..ed5830f
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/continuous_integration.xmi
@@ -0,0 +1,43 @@
+<?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" epf:version="1.0.0" xmi:id="-35rZhRLEVuTVI4280ncN0A" name="continuous_integration,3.193414568279561E-305" guid="-35rZhRLEVuTVI4280ncN0A" changeDate="2006-11-08T16:55:42.002-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__continuous_integration" name="XE_xp__continuous_integration"></a><a
+id="XE_continuous_integration__practice_of" name="XE_continuous_integration__practice_of"></a><a
+id="XE_engineering_practices__continuous_integration" name="XE_engineering_practices__continuous_integration"></a>
+<h3>
+ Description
+</h3>
+<p>
+ One of the goals of XP is to ensure that the customer can feel and touch actual progress that reflects the investment
+ to date. As the team builds the software incrementally according to the customer's priority, the new functionality is
+ continuously integrated and demonstrated to the customer.
+</p>
+<p>
+ Integration in XP can happen several times a day. As developers finish some work, they integrate what they have done.
+ Typically, integration is done on an integration machine in order to serialize the process. Integration is supported by
+ unit tests and acceptance tests. When a pair of programmers first sits at the integration machine, the current code
+ base passes all tests. They start by integrating their changes into the code and checking for conflicts. Then, they run
+ all tests. Should any test fail, the pair is responsible for fixing the code and making it pass. Since the tests were
+ all passed before, the failures are in some way related to the modifications that have made to the code. Once all the
+ tests have passed, the integration can be considered a success and another pair can now integrate its changes. The
+ integrated build can then be handed over to the customer, who can see the new functionality on a running system.
+</p>
+<p>
+ This practice obviously requires the use of tools and an environment that supports fast integration/build/test cycles.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Simplified and faster integrations</b>: reduces important conflicts associated with big bang integration and
+ insures that people are working with the latest version of the code.
+ </li>
+ <li>
+ <b>Improved feedback</b>: shows constant and demonstrable progress (it takes a running system to pass the
+ customer's acceptance tests).
+ </li>
+ <li>
+ <b>System always shippable</b>: the latest version of the system passing all tests is always available.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/customer_tests.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/customer_tests.xmi
new file mode 100644
index 0000000..1d9ff82
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/customer_tests.xmi
@@ -0,0 +1,31 @@
+<?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" epf:version="1.0.0" xmi:id="-oW2j2l-rXqHeWPIgjPpbng" name="customer_tests,2.297945473205673E-305" guid="-oW2j2l-rXqHeWPIgjPpbng" changeDate="2006-11-10T09:32:51.048-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__customer_tests" name="XE_xp__customer_tests"></a><a id="XE_customer_tests__practice_of"
+name="XE_customer_tests__practice_of"></a><a id="XE_engineering_practices__customer_tests"
+name="XE_engineering_practices__customer_tests"></a>
+<h3>
+ Description
+</h3>
+<p>
+ One of the rights in the customer bill of rights tells the customer he will be able to see progress in the form of a
+ working system that passes repeatable tests that he specifies. These tests are what we call the Customer Tests. The
+ customer specifies one or more Customer Tests for each user story in the system, describing in detail how each story is
+ expected to work. Because the tests are put into executable form and are fully automated, they tell programmers what
+ needs to be done in a unambiguous way (tests pass or fail) and allow the customer to feel confident that the system is
+ meeting his needs.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Ability to see <b>tangible and verifiable progress</b>.
+ </li>
+ <li>
+ <b>Ultimate traceability</b>: the Customer Tests are executable system requirements.
+ </li>
+ <li>
+ <b>Repeatability</b>: because they are automated, the tests can be run at any time.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/developer_testing.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/developer_testing.xmi
new file mode 100644
index 0000000..eda0627
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/developer_testing.xmi
@@ -0,0 +1,515 @@
+<?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" epf:version="1.0.0" xmi:id="-aJBLg1aguP1bIWvQbJSd6w" name="developer_testing,4.085829182735815E-305" guid="-aJBLg1aguP1bIWvQbJSd6w" changeDate="2006-11-13T14:42:19.105-0800" version="1.0.0">
+ <mainDescription><a id="XE_test__developer_testing__concept_of" name="XE_test__developer_testing__concept_of"></a><a
+id="XE_design__developer_testing__concept_of" name="XE_design__developer_testing__concept_of"></a>
+<h3>
+ <a id="Introduction" name="Introduction"></a>Introduction
+</h3>
+<p>
+ The phrase "Developer Testing" is used to categorize the testing activities most appropriately performed by software
+ developers. It also includes the artifacts created by those activities. Developer Testing encompasses the work
+ traditionally thought of under the following categories: Unit Testing, much of Integration Testing, and some aspects of
+ what is most often referred to as System Testing. While Developer Testing is traditionally associated with activities
+ in the Implementation discipline, it also has a relationship to activities in the Analysis and Design discipline.
+</p>
+<p>
+ By thinking of Developer Testing in this "holistic" way, you help to mitigate some of the risk associated with the more
+ "atomistic" approach traditionally taken. In the traditional approach to Developer Testing, the effort is initially
+ focused on evaluating that all units are working independently. Late in the development life-cycle, as the development
+ work nears completion, the integrated units are assembled into a working subsystem or system and tested in this setting
+ for the first time.
+</p>
+<p>
+ This approach has a number of failings. Firstly, because it encourages a staged approach to the testing of the
+ integrated units and later subsystems, any errors identified during these tests are often found too late. This late
+ discovery typically results in the decision to take no corrective action, or it requires major rework to correct. This
+ rework is both expensive and detracts from making forward progress in other areas. This increases the risk of the
+ project being derailed or abandoned.
+</p>
+<p>
+ Secondly, creating rigid boundaries between Unit, Integration and System Test increases the probability that errors
+ spanning the boundaries will be discovered by no one. The risk is compounded when responsibility for these types of
+ tests is assigned to separate teams.
+</p>
+<p>
+ The style of developer testing recommended by&nbsp;iterative processes&nbsp;encourages the developer to focus on the
+ most valuable and appropriate tests to conduct at the given point in time. Even within the scope of a single iteration,
+ it is usually more efficient for the developer to find and correct as many of the defects in her own code as possible,
+ without the additional overhead in hand-off to a separate test group. The desired result is the early discovery of the
+ most significant software errors&nbsp;- regardless of whether those errors are in the independent unit, the integration
+ of the units or the working of the integrated units within a meaningful end-user scenario.
+</p>
+<h3>
+ <a id="DeveloperTestingPitfalls" name="DeveloperTestingPitfalls"></a>Pitfalls Getting Started with Developer Testing
+</h3>
+<p>
+ Many developers who begin trying to do a substantially more thorough job of testing give up the effort shortly
+ thereafter. They find that it does not seem to be yielding value. Further, some developers who begin well with
+ developer testing find that they've created an unmaintainable test suite that is eventually abandoned.
+</p>
+<p>
+ This page gives some guidelines for getting over the first hurdles and for creating a test suite that avoids the
+ maintainability trap. For more information, see <a href="../../workguid/wg_mnttstste.htm">Guidelines: Maintaining
+ Automated Test Suites</a>.
+</p>
+<h4>
+ Establish expectations
+</h4>
+<p>
+ Those who find developer testing rewarding do it. Those who view it as a chore find ways to avoid it. This is simply in
+ the nature of most developers in most industries, and treating it as a shameful lack of discipline hasn't historically
+ been successful. Therefore, as a developer you should expect testing to be rewarding and do what it takes to make it
+ rewarding.
+</p>
+<p>
+ Ideal developer testing follows a very tight edit-test loop. You make a small change to the product, such as adding a
+ new method to a class, then you immediately rerun your tests. If any test breaks, you know exactly what code is the
+ cause. This easy, steady pace of development is the greatest reward of developer testing. A long debugging session
+ should be exceptional.
+</p>
+<p>
+ Because it's not unusual for a change made in one class to break something in another, you should expect to rerun not
+ just the changed class's tests, but many tests. Ideally, you rerun the complete test suite for your component many
+ times per hour. Every time you make a significant change, you rerun the suite, watch the results, and either proceed to
+ the next change or fix the last change. Expect to spend some effort making that rapid feedback possible.
+</p>
+<h4>
+ Automate your tests
+</h4>
+<p>
+ Running tests often is not practical if tests are manual. For some components, automated tests are easy. An example
+ would be an in-memory database. It communicates to its clients through an API and has no other interface to the outside
+ world. Tests for it would look something like this:
+</p>
+<blockquote>
+<pre>
+/* Check that elements can be added at most once. */
+// Setup
+Database db = new Database();
+db.add("key1", "value1");
+// Test
+boolean result = db.add("key1", "another value");
+expect(result == false);
+</pre>
+</blockquote>
+<p>
+ The tests are different from ordinary client code in only one way: instead of believing the results of API calls, they
+ check. If the API makes client code easy to write, it makes test code easy to write. If the test code is <i>not</i>
+ easy to write, you've received an early warning that the API could be improved. Test-first design is thus consistent
+ with the iterative processes' focus on addressing important risks early.
+</p>
+<p>
+ The more tightly connected the component is to the outside world, however, the harder it will be to test. There are two
+ common cases: graphical user interfaces and back-end components.
+</p>
+<h5>
+ Graphical user interfaces
+</h5>
+<p>
+ Suppose the database in the example above receives its data via a callback from a user-interface object. The callback
+ is invoked when the user fills in some text fields and pushes a button. Testing this by manually filling in the fields
+ and pushing the button isn't something you want to do many times an hour. You must arrange a way to deliver the input
+ under programmatic control, typically by "pushing" the button in code.
+</p>
+<p>
+ Pushing the button causes some code in the component to be executed. Most likely, that code changes the state of some
+ user-interface objects. So you must also arrange a way to query those objects programmatically.
+</p>
+<h5>
+ Back-end components
+</h5>
+<p>
+ Suppose the component under test doesn't implement a database. Instead, it's a wrapper around a real, on-disk database.
+ Testing against that real database might be difficult. It might be hard to install and configure. Licenses for it might
+ be expensive. The database might slow down the tests enough that you're not inclined to run them often. In such cases,
+ it's worthwhile to "stub out" the database with a simpler component that does just enough to support the tests.
+</p>
+<p>
+ Stubs are also useful when a component that your component talks to isn't ready yet. You don't want your testing to
+ wait on someone else's code.
+</p>
+<p>
+ For more information, see <a href="../implemen/co_stubs.htm">Concepts: Stubs</a>.
+</p>
+<h4>
+ Don't write your own tools
+</h4>
+<p>
+ Developer testing seems pretty straightforward. You set up some objects, make a call through an API, check the result,
+ and announce a test failure if the results aren't as expected. It's also convenient to have some way to group tests so
+ that they can be run individually or as complete suites. Tools that support those requirements are called <i>test
+ frameworks</i>.
+</p>
+<p>
+ Developer testing <b>is</b> straightforward, and the requirements for test frameworks are not complicated. If, however,
+ you yield to the temptation of writing your own test framework, you'll spend much more time tinkering with the
+ framework than you probably expect. There are many test frameworks available, both commercial and open source, and
+ there's no reason not to use one of those.
+</p>
+<h4>
+ Do create support code
+</h4>
+<p>
+ Test code tends to be repetitive. It's common to see sequences of code like this:
+</p>
+<blockquote>
+<pre>
+// null name not allowed
+retval = o.createName("");
+expect(retval == null);
+// leading spaces not allowed
+retval = o.createName(" l");
+expect(retval == null);
+// trailing spaces not allowed
+retval = o.createName("name ");
+expect(retval == null);
+// first character may not be numeric
+retval = o.createName("5allpha");
+expect(retval == null);
+</pre>
+</blockquote>
+<p>
+ This code is created by copying one check, pasting it, then editing it to make another check.
+</p>
+<p>
+ The danger here is twofold. If the interface changes, much editing will have to be done. (In more complicated cases, a
+ simple global replacement won't suffice.) Also, if the code is at all complicated, the intent of the test can be lost
+ amid all the text.
+</p>
+<p>
+ When you find yourself repeating yourself, seriously consider factoring out the repetition into support code. Even
+ though the code above is a simple example, it's more readable and maintainable if written like this:
+</p>
+<blockquote>
+<pre>
+void expectNameRejected(MyClass o, String s) {
+ Object retval = o.createName(s);
+ expect(retval == null);
+}
+...
+// null name not allowed
+expectNameRejected(o, "");
+// leading spaces not allowed.
+expectNameRejected(o, " l");
+// trailing spaces not allowed.
+expectNameRejected(o, "name ");
+// first character may not be numeric.
+expectNameRejected(o, "5alpha");
+</pre>
+</blockquote>
+<p>
+ Developers writing tests often err on the side of too much copying-and-pasting. If you suspect yourself of that
+ tendency, it's useful to consciously err in the other direction. Resolve that you will strip your code of all duplicate
+ text.
+</p>
+<h4>
+ Write the tests first
+</h4>
+<p>
+ Writing the tests after the code is a chore. The urge is to rush through it, to finish up and move on. Writing tests
+ before the code makes testing part of a positive feedback loop. As you implement more code, you see more tests passing
+ until finally all the tests pass and you're done. People who write tests first seem to be more successful, and it takes
+ no more time. For more on putting tests first, see <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
+ guid="6.556259235358794E-306">Concept: Test-first Design</a>
+</p>
+<h4>
+ Keep the tests understandable
+</h4>
+<p>
+ You should expect that you, or someone else, will have to modify the tests later. A typical situation is that a later
+ iteration calls for a change to the component's behavior. As a simple example, suppose the component once declared a
+ square root method like this:
+</p>
+<blockquote>
+ <p>
+ <font size="+0">double sqrt(double x);</font>
+ </p>
+</blockquote>
+<p>
+ In that version, a negative argument caused <font size="+0">sqrt</font> to return NaN ("not a number" from the IEEE
+ 754-1985 <i>Standard for Binary Floating-Point Arithmetic</i>). In the new iteration, the square root method will
+ accept negative numbers and return a complex result:
+</p>
+<blockquote>
+ <p>
+ <font size="+0">Complex sqrt(double x);</font>
+ </p>
+</blockquote>
+<p>
+ Old tests for <font size="+0">sqrt</font> will have to change. That means understanding what they do, and updating them
+ so that they work with the new <font size="+0">sqrt</font>. When updating tests, you must take care not to destroy
+ their bug-finding power. One way that sometimes happens is this:
+</p>
+<blockquote>
+<pre>
+void testSQRT () {
+ // Update these tests for Complex
+ // when I have time -- bem
+ /*
+double result = sqrt(0.0);
+...
+ */
+}
+</pre>
+</blockquote>
+<p>
+ Other ways are more subtle: the tests are changed so that they actually run, but they no longer test what they were
+ originally intended to test. The end result, over many iterations, can be a test suite that is too weak to catch many
+ bugs. This is sometimes called "test suite decay". A decayed suite will be abandoned, because it's not worth the
+ upkeep.
+</p>
+<p>
+ You can't maintain a test's bug-finding power unless it's clear what <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestIdeas"
+ guid="8.834380241450745E-306">Test Ideas</a> a test implements. Test code tends to be under-commented, even though it's
+ often harder to understand the "why" behind it than product code.
+</p>
+<p>
+ Test suite decay is less likely in the direct tests for <font size="+0">sqrt</font> than in indirect tests. There will
+ be code that calls <font size="+0">sqrt</font>. That code will have tests. When <font size="+0">sqrt</font> changes,
+ some of those tests will fail. The person who changes <font size="+0">sqrt</font> will probably have to change those
+ tests. Because he's less familiar with them, and because their relationship to the change is less clear, he's more
+ likely to weaken them in the process of making them pass.
+</p>
+<p>
+ When you're creating support code for tests (as urged above), be careful: the support code should clarify, not obscure,
+ the purpose of the tests that use it. A common complaint about object-oriented programs is that there's no one place
+ where anything's done. If you look at any one method, all you discover is that it forwards its work somewhere else.
+ Such a structure has advantages, but it makes it harder for new people to understand the code. Unless they make an
+ effort, their changes are likely to be incorrect or to make the code even more complicated and fragile. The same is
+ true of test code, except that later maintainers are even less likely to take due care. You must head off the problem
+ by writing understandable tests.
+</p>
+<h4>
+ Match the test structure to the product structure
+</h4>
+<p>
+ Suppose someone has inherited your component. They need to change a part of it. They may want to examine the old tests
+ to help them in their new design. They want to update the old tests before writing the code (test-first design).
+</p>
+<p>
+ All those good intentions will go by the wayside if they can't find the appropriate tests. What they'll do is make the
+ change, see what tests fail, then fix those. That will contribute to test suite decay.
+</p>
+<p>
+ For that reason, it's important that the test suite be well structured, and that the location of tests be predictable
+ from the structure of the product. Most usually, developers arrange tests in a parallel hierarchy, with one test class
+ per product class. So if someone is changing a class named <font size="+0">Log</font>, they know the test class is
+ <font size="+0">TestLog</font>, and they know where the source file can be found.
+</p>
+<h4>
+ Let tests violate encapsulation
+</h4>
+<p>
+ You might limit your tests to interacting with your component exactly as client code does, through the same interface
+ that client code uses. However, this has disadvantages. Suppose you're testing a simple class that maintains a doubly
+ linked list:
+</p>
+<p align="center">
+ <img height="46" alt="" src="resources/dvltst-img1.gif" width="195" />
+</p>
+<p class="picturetext">
+ Fig1: Double-linked list
+</p>
+<p>
+ In particular, you're testing the <font size="+0">DoublyLinkedList.insertBefore(Object existing, Object
+ newObject)</font> method. In one of your tests, you want to insert an element in the middle of the list, then check if
+ it's been inserted successfully. The test uses the list above to create this updated list:
+</p>
+<p align="center">
+ <img height="46" alt="" src="resources/dvltst-img2.gif" width="318" />
+</p>
+<p class="picturetext">
+ Fig2: Double-linked list - item inserted
+</p>
+<p>
+ It checks the list correctness like this:
+</p>
+<blockquote>
+<pre>
+// the list is now one longer.
+expect(list.size()==3);
+// the new element is in the correct position
+expect(list.get(1)==m);
+// check that other elements are still there.
+expect(list.get(0)==a);
+expect(list.get(2)==z);
+</pre>
+</blockquote>
+<p>
+ That seems sufficient, but it's not. Suppose the list implementation is incorrect and backward pointers are not set
+ correctly. That is, suppose the updated list actually looks like this:
+</p>
+<p align="center">
+ <img height="73" alt="" src="resources/dvltst-img3.gif" width="318" />
+</p>
+<p class="picturetext">
+ Fig3: Double-linked list - fault in implementation
+</p>
+<p>
+ If <font size="+0">DoublyLinkedList.get(int index)</font> traverses the list from the beginning to the end (likely),
+ the test would miss this failure. If the class provides <font size="+0">elementBefore</font> and <font
+ size="+0">elementAfter</font> methods, checking for such failures is straightforward:
+</p>
+<blockquote>
+<pre>
+// Check that links were all updated
+expect(list.elementAfter(a)==m);
+expect(list.elementAfter(m)==z);
+expect(list.elementBefore(z)==m); //this will fail
+expect(list.elementBefore(m)==a);
+</pre>
+</blockquote>
+<p>
+ But what if it doesn't provide those methods? You could devise more elaborate sequences of method calls that will fail
+ if the suspected defect is present. For example, this would work:
+</p>
+<blockquote>
+<pre>
+// Check whether back-link from Z is correct.
+list.insertBefore(z, x);
+// If it was incorrectly not updated, X will have
+// been inserted just after A.
+expect(list.get(1)==m);
+</pre>
+</blockquote>
+<p>
+ But such a test is more work to create and is likely to be significantly harder to maintain. (Unless you write good
+ comments, it will not be at all clear why the test is doing what it's doing.) There are two solutions:
+</p>
+<ol>
+ <li>
+ Add the <font size="+0">elementBefore</font> and <font size="+0">elementAfter</font> methods to the public
+ interface. But that effectively exposes the implementation to everyone and makes future change more difficult.
+ </li>
+ <li>
+ Let the tests "look under the hood" and check pointers directly.
+ </li>
+</ol>
+<p>
+ The latter is usually the best solution, even for a simple class like <font size="+0">DoublyLinkedList</font> and
+ especially for the more complex classes that occur in your products.
+</p>
+<p>
+ Typically, tests are put in the same package as the class they test. They are given protected or friend access.
+</p>
+<h3>
+ <a id="TestDesignMistakes" name="TestDesignMistakes"></a>Characteristic Test Design Mistakes
+</h3>
+<p>
+ Each test exercises a component and checks for correct results. The design of the test-the inputs it uses and how it
+ checks for correctness-can be good at revealing defects, or it can inadvertently hide them. Here are some
+ characteristic test design mistakes.
+</p>
+<h4>
+ Failure to specify expected results in advance
+</h4>
+<p>
+ Suppose you're testing a component that converts XML into HTML. A temptation is to take some sample XML, run it through
+ the conversion, then look at the results in a browser. If the screen looks right, you "bless" the HTML by saving it as
+ the official expected results. Thereafter, a test compares the actual output of the conversion to the expected results.
+</p>
+<p>
+ This is a dangerous practice. Even sophisticated computer users are used to believing what the computer does. You are
+ likely to overlook mistakes in the screen appearance. (Not to mention that browsers are quite tolerant of misformatted
+ HTML.) By making that incorrect HTML the official expected results, you make sure that the test can never find the
+ problem.
+</p>
+<p>
+ It's less dangerous to doubly-check by looking directly at the HTML, but it's still dangerous. Because the output is
+ complicated, it will be easy to overlook errors. You'll find more defects if you write the expected output by hand
+ first.
+</p>
+<h4>
+ Failure to check the background
+</h4>
+<p>
+ Tests usually check that what should have been changed has been, but their creators often forget to check that what
+ should have been left alone has been left alone. For example, suppose a program is supposed to change the first 100
+ records in a file. It's a good idea to check that the 101<sup>st</sup> hasn't been changed.
+</p>
+<p>
+ In theory, you would check that nothing in the "background"-the entire file system, all of memory, everything reachable
+ through the network-has been left alone. In practice, you have to choose carefully what you can afford to check. But
+ it's important to make that choice.
+</p>
+<h4>
+ Failure to check persistence
+</h4>
+<p>
+ Just because the component tells you a change has been made, that doesn't mean it has actually been committed to the
+ database. You need to check the database via another route.
+</p>
+<h4>
+ Failure to add variety
+</h4>
+<p>
+ A test might be designed to check the effect of three fields in a database record, but many other fields need to be
+ filled in to execute the test. Testers will often use the same values over and over again for these "irrelevant"
+ fields. For example, they'll always use the name of their lover in a text field, or 999 in a numeric field.
+</p>
+<p>
+ The problem is that sometimes what shouldn't matter actually does. Every so often, there's a bug that depends on some
+ obscure combination of unlikely inputs. If you always use the same inputs, you stand no chance of finding such bugs. If
+ you persistently vary inputs, you might. Quite often, it costs almost nothing to use a number different than 999 or to
+ use someone else's name. When varying the values used in tests costs almost nothing and it has some potential benefit,
+ then vary. (Note: It's unwise to use names of old lovers instead of your current one if your current lover works with
+ you.)
+</p>
+<p>
+ Here's another benefit. One plausible fault is for the program to use field <i>X</i> when it should have used field
+ <i>Y</i>. If both fields contain "Dawn", the fault can't be detected.
+</p>
+<h4>
+ Failure to use realistic data
+</h4>
+<p>
+ It's common to use made-up data in tests. That data is often unrealistically simple. For example, customer names might
+ be "Mickey", "Snoopy", and "Donald". Because that data is different from what real users enter - for example, it's
+ characteristically shorter - it can miss defects real customers will see. For example, these one-word names wouldn't
+ detect that the code doesn't handle names with spaces.
+</p>
+<p>
+ It's prudent to make a slight extra effort to use realistic data.
+</p>
+<h4>
+ Failure to notice that the code does nothing at all
+</h4>
+<p>
+ Suppose you initialize a database record to zero, run a calculation that should result in zero being stored in the
+ record, then check that the record is zero. What has your test demonstrated? The calculation might not have taken place
+ at all. Nothing might have been stored, and the test couldn't tell.
+</p>
+<p>
+ That example sounds unlikely. But this same mistake can crop up in subtler ways. For example, you might write a test
+ for a complicated installer program. The test is intended to check that all temporary files are removed after a
+ successful installation. But, because of all the installer options, in that test, one particular temporary file wasn't
+ created. Sure enough, that's the one the program forgot to remove.
+</p>
+<h4>
+ Failure to notice that the code does the wrong thing
+</h4>
+<p>
+ Sometimes a program does the right thing for the wrong reasons. As a trivial example, consider this code:
+</p>
+<blockquote>
+<pre>
+if (a &lt; b &amp;&amp; c)
+ return 2 * x;
+else
+ return x * x;
+</pre>
+</blockquote>
+<p>
+ The logical expression is wrong, and you've written a test that causes it to evaluate incorrectly and take the wrong
+ branch. Unfortunately, purely by coincidence, the variable X has the value 2 in that test. So the result of the wrong
+ branch is accidentally correct - the same as the result the right branch would have given.
+</p>
+<p>
+ For each expected result, you should ask if there's a plausible way in which that result could be gotten for the wrong
+ reason. While it's often impossible to know, sometimes it's not.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/extreme_programming.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/extreme_programming.xmi
new file mode 100644
index 0000000..6e210bb
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/extreme_programming.xmi
@@ -0,0 +1,229 @@
+<?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" epf:version="1.0.0" xmi:id="-27sE-swoOUGtar9a0f3RPw" name="extreme_programming,5.2637267673584526E-306" guid="-27sE-swoOUGtar9a0f3RPw" changeDate="2006-12-01T15:11:05.063-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__conceptual_process_roadmap" name="XE_xp__conceptual_process_roadmap"></a><a id="XE_roadmap__for_xp_practices"
+name="XE_roadmap__for_xp_practices"></a>
+<h3>
+ Topics
+</h3>
+<div align="left">
+ <table width="70%" border="1">
+ <tbody valign="top">
+ <tr>
+ <td width="315" height="178">
+ <ul>
+ <li>
+ <a href="#Introduction">Introduction</a>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <a href="#About">About XP</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="#Characteristics">Characteristics of an XP Project</a>
+ </li>
+ <li>
+ <a href="#Phases">Phases and Iterations</a>
+ </li>
+ <li>
+ <a href="#GettingStarted">How to Get Started</a>
+ </li>
+ </ul>
+ </td>
+ <td width="315" height="178">
+ <b>Additional Guidance:</b>
+ <ul>
+ <li>
+ Guidelines
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <a class="elementLink"
+ href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html"
+ guid="8.137126904637637E-306">Refactoring</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html"
+ guid="3.9254165491375454E-306">Test First Development</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html"
+ guid="3.85153041801319E-307">Pair Programming</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
+ guid="6.7335956461328426E-307">Planning Game</a>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <br />
+ <b>Additional Concepts:</b>
+ <ul>
+ <li>
+ <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a>
+ </li>
+ </ul>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<br />
+<br />
+<h1>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h1>
+<p>
+ This roadmap provides information for getting started and applying the practices of eXtreme Programming (XP) to a
+ software development project.
+</p>
+<h3>
+ <a id="About" name="About">About XP</a>&nbsp;
+</h3>
+<p>
+ Extreme Programming is an instance of an <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a> method. XP is a method that is optimized for small to
+ medium-sized project teams that fit a certain profile. It promotes rapid feedback and response to continual change. It
+ is based upon the four <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">values</a>
+ of simplicity, communication, feedback, and courage and is consistent with the values of agile software development.
+</p>
+<p>
+ Extreme Programming is an instance of an agile method for developing software. It is based upon the core principle of
+ agility and consists of twelve practices that, when applied to an appropriate software development project, can produce
+ high-quality software. If you are unfamiliar with the concepts surrounding XP, you should start by reading <a
+ class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a>.
+</p>
+<h3>
+ <a id="Characteristics" name="Characteristics">Characteristics of an XP Project</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium-sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. Since XP relies heavily on
+ direct and frequent communication between the team members, the team should be co-located. An ideal project for using
+ XP would be one that has most of the following characteristics:
+</p>
+<ul>
+ <li>
+ A small to medium-sized team (fewer than 20 people on the complete team)
+ </li>
+ <li>
+ Co-located, preferably in a single area with a large common space
+ </li>
+ <li>
+ A committed, full-time, on-site customer or customer representative
+ </li>
+</ul>
+<h3>
+ <a id="Phases" name="Phases">Phases and Iterations</a>
+</h3>
+<p>
+ An XP project is one that is based on rapid feedback through short iterations and frequent releases.&nbsp;Unified
+ Process&nbsp;and XP share a fundamental belief that iterative development is the best way to deliver valuable software
+ to your customers. The concept of phases, as usually described in the Unified Process, is somewhat different. Decisions
+ described in the Unified Process phases that define milestones occur, but they are not called specifically as defining
+ phases.
+</p>
+<h3>
+ <a id="GettingStarted" name="GettingStarted">How to Get Started</a>
+</h3>
+<p>
+ This section provides a recommended way to approach XP for your project. You don't have to follow the steps as
+ specified, but if you have little experience with XP, we recommend following them as closely as possible the first
+ time.
+</p>
+<table cellspacing="2" cellpadding="1" width="91%" border="1">
+ <tbody>
+ <tr>
+ <th width="10%">
+ Step
+ </th>
+ <th align="left" width="47%">
+ Do this ...
+ </th>
+ <th align="left" width="43%">
+ in order to...
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 1
+ </td>
+ <td width="47%">
+ Familiarize yourself with the&nbsp;<a class="elementLink"
+ href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
+ guid="1.6390805262958034E-306">motivation</a> for using XP, the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html"
+ guid="9.251272550276345E-306">short description</a> of XP, and the <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html"
+ guid="2.2937799026801584E-305">XP Practices</a>
+ </td>
+ <td width="43%">
+ understand the fundamental principles of XP and how the practices support each other.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 2
+ </td>
+ <td width="47%">
+ Read the key concepts of <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a>
+ </td>
+ <td width="43%">
+ understand the collaborative and social aspects of XP.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 3
+ </td>
+ <td width="47%">
+ Determine if XP is appropriate for your project by reviewing <a href="#Characteristics">The Characteristics
+ of an XP Project</a>
+ </td>
+ <td width="43%">
+ decide if XP may be appropriate for your project.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 4
+ </td>
+ <td width="47%">
+ Read about the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/xp_environment,3.754748120034442E-307.html"
+ guid="3.754748120034442E-307">XP Environment</a>.
+ </td>
+ <td width="43%">
+ prepare the physical and tool environment for your team.
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="10%">
+ 5
+ </td>
+ <td width="47%">
+ Read the <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/getting_started_with_xp,1.2284921351651456E-304.html"
+ guid="1.2284921351651456E-304">Getting Started with XP</a> guidelines.
+ </td>
+ <td width="43%">
+ get suggestions on how to start an XP project.
+ </td>
+ </tr>
+ </tbody>
+</table></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/metaphor_system_of_names.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/metaphor_system_of_names.xmi
new file mode 100644
index 0000000..ebb542b
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/metaphor_system_of_names.xmi
@@ -0,0 +1,40 @@
+<?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" epf:version="1.0.0" xmi:id="-2OU2wQP_WNWX5zzWzx4ANw" name="metaphor_system_of_names,4.884861766532753E-306" guid="-2OU2wQP_WNWX5zzWzx4ANw" changeDate="2006-11-08T16:24:49.021-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__metaphor_(system_of_names)" name="XE_xp__metaphor_(system_of_names)"></a><a
+id="XE_metaphor_(system_of_names)__practice_of" name="XE_metaphor_(system_of_names)__practice_of"></a><a
+id="XE_engineering_practices__metaphor_(system_of_names)" name="XE_engineering_practices__metaphor_(system_of_names)"></a>
+<h3>
+ Description
+</h3>
+<p>
+ This metaphor is a design overview. It is a way of defining the system using a commonly understandable vocabulary with
+ its associated relationships. It allows the whole team to talk about the structure of the software in a convenient and
+ memorable way. A good metaphor is one that all team members can understand easily, remember, and always keep in the
+ back of their minds. It provides a unifying direction that developers can follow as they build the system a small piece
+ at a time.
+</p>
+<p>
+ Metaphors are not always easy to find at the start of a project. In that case, teams can simply identify the key
+ objects and their interactions in the system (System of Names). The real metaphor might emerge later on. When everybody
+ on the team can explain quickly the system through its major objects and their interactions, the goal has been reached.
+</p>
+<p>
+ The iterative nature of XP causes the architecture of our system to evolve over time. The metaphor is not static; it
+ will change and hopefully improve over time as our understanding of the system improves.
+</p>
+<p>
+ An example of a metaphor would be something like: "It's like a subway system with passengers and stations, tickets and
+ turnstiles, etc.".
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Communication</b>: customer and developer define a common language they can use to talk about the system.
+ </li>
+ <li>
+ <b>Direction</b>: the metaphor helps guide the developers towards the solution.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/motivation.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/motivation.xmi
new file mode 100644
index 0000000..4a39f82
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/motivation.xmi
@@ -0,0 +1,55 @@
+<?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" epf:version="1.0.0" xmi:id="-nIpFvBhY9WogqrEQv4NknQ" name="why_xp,1.6390805262958034E-306" guid="-nIpFvBhY9WogqrEQv4NknQ" changeDate="2006-11-08T15:24:24.660-0800" version="1.0.0">
+ <mainDescription><p>
+ The goal of a software process is to guide the software development organization to:
+</p>
+<ol>
+ <li>
+ Get the right software done.
+ </li>
+ <li>
+ Get the software done right.
+ </li>
+ <li>
+ Get the software done quickly.
+ </li>
+ <li>
+ Get the software done frugally.
+ </li>
+</ol>
+<p>
+ There are many approaches to this problem. Some software processes are high in ceremony. They guide the developers to
+ create many artifacts. They punctuate the project with phases and sign-offs. They release infrequently, sometimes
+ solely upon project completion. There is a time and place for such processes.
+</p>
+<p>
+ On the other hand, the most important and scarce resource in any project is the time of the developers. High ceremony
+ processes fill that time with work activities that center around artifacts and reviews instead of around the core
+ artifacts of code and tests. For many projects this is an exorbitant expense.
+</p>
+<p>
+ To manage this expense, many projects need a process that uses a minimum of ceremony and concentrates on the core
+ artifacts. They need a feedback-driven process that delivers working software rapidly in quick releases.
+</p>
+<p>
+ XP is just such a low ceremony process. It is used by those teams and for those projects where ceremony is of little
+ value, but rapid feedback is of high value. Such projects tend to be small to medium sized - fewer than one or two
+ million lines of code - and involve fewer than one or two dozen developers. They tend to exist in environments of
+ intense business and or technical change. They are, of course, exceedingly common.
+</p>
+<p>
+ A lack of ceremony does not imply a lack of management. XP places a lot of emphasis on techniques for planning,
+ estimation, and schedule management. Creating, maintaining, and managing a project plan is a very big part of XP.
+</p>
+<p>
+ A lack of ceremony also does not imply a lack of discipline. XP espouses discipline for every facet of the project.
+ There is discipline for testing, integration, planning, reviewing, and for producing software with a high quality
+ internal structure. The goal is to keep the project moving and the software easy to modify, easy to extend, and easy to
+ develop.
+</p>
+<p>
+ In short, XP puts the emphasis on ensuring that the team is working on the minimum set of activities and artifacts that
+ will produce the right software, built right, built quickly and built frugally.<br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/pair_programming.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/pair_programming.xmi
new file mode 100644
index 0000000..61a1f07
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/pair_programming.xmi
@@ -0,0 +1,42 @@
+<?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" epf:version="1.0.0" xmi:id="-n52TyFa7Reb3LOJV1JMpvg" name="pair_programming,3.876855509996079E-307" guid="-n52TyFa7Reb3LOJV1JMpvg" changeDate="2006-11-09T16:16:04.083-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__practice_of"
+name="XE_pair_programming__practice_of"></a><a id="XE_engineering_practices__pair_programming"
+name="XE_engineering_practices__pair_programming"></a>
+<h3>
+ Description
+</h3>
+<p>
+ All production software in XP is produced by two programmers, sitting side by side, at the same machine. This practice
+ ensures that all production code is reviewed by at least one other programmer and results in better design, better
+ testing, and better code.
+</p>
+<p>
+ Research into pair programming shows that pairing produces better code in about the same time as programmers working
+ singly.
+</p>
+<p>
+ Pairing also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of
+ everyone's specialized knowledge. Programmers learn, their skills improve, and they become more valuable to the team
+ and to the company.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Better design, code and tests.
+ </li>
+ <li>
+ Application and skill knowledge sharing across team.
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ See the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html" guid="3.85153041801319E-307">Pair
+ Programming Guidelines</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/planning_game.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/planning_game.xmi
new file mode 100644
index 0000000..b4d0953
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/planning_game.xmi
@@ -0,0 +1,99 @@
+<?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" epf:version="1.0.0" xmi:id="-CPHs6R59_druVDY6nRjHEw" name="planning_game,2.7371805612676613E-305" guid="-CPHs6R59_druVDY6nRjHEw" changeDate="2006-11-13T15:39:25.183-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning_game__practice_of"
+name="XE_planning_game__practice_of"></a><a id="XE_engineering_practices__planning_game"
+name="XE_engineering_practices__planning_game"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The purpose of planning is to ensure that we are working on the most valuable things at all times. As much as we would
+ like to, planning is not about predicting the future. Even the best, most thought out plans need to be continually
+ refined. They require continuous and constant feedback to be useful.
+</p>
+<p>
+ XP proposes the following planning hierarchy:
+</p>
+<ul>
+ <li>
+ Projects are split into releases that typically last two to three months.
+ </li>
+ <li>
+ Releases are split into iterations that typically last two to three weeks.
+ </li>
+ <li>
+ Iterations are planned into tasks that typically last one to two days.
+ </li>
+</ul>
+<p>
+ The XP planning game has two main activities:
+</p>
+<h4>
+ Release Planning
+</h4>
+<ul>
+ <li>
+ Customer presents user stories to the team.
+ </li>
+ <li>
+ Programmers estimate the user stories.
+ </li>
+ <li>
+ Customers selects a set of user stories for the next release. The total of the estimates of the selected stories
+ cannot exceed the team's previous release velocity (how much they did the previous release).
+ </li>
+</ul>
+<h4>
+ Iteration Planning
+</h4>
+<ul>
+ <li>
+ Customer presents the user stories that will be worked on for the iteration. These stories usually come from the
+ release. Stories not in the release can be selected for the iteration, but the customer will have to push out an
+ existing story of the same size out of the iteration and the release. This is done so the team does not commit to
+ do more work than they have shown they can do in the past.
+ </li>
+ <li>
+ Programmers break down the stories into engineering tasks.
+ </li>
+ <li>
+ Programmers sign up and estimate engineering tasks.
+ </li>
+ <li>
+ Programmers do a sanity check to make sure all these tasks can be done by comparing against what was done the
+ previous iteration.
+ </li>
+ <li>
+ If there is too much to do, the customer will drop one or more user story from the iteration.
+ </li>
+ <li>
+ If there is not enough work, the customer can add one or more story to fill the iteration.
+ </li>
+</ul>
+<h3>
+ Benefits
+</h3>
+<ul class="noindent">
+ <li>
+ Provides <b>quick and meaningful feedback</b>.
+ </li>
+ <li>
+ Provides <b>lots of opportunities</b> to use that feedback <b>to steer the team to success</b>.
+ </li>
+ <li>
+ Provides <b>clear</b>, long-term <b>strategic</b> (release plan) <b>and</b> short-term <b>tactical goals</b>
+ (iteration plan).
+ </li>
+ <li>
+ <b>Allows the team to manage themselves</b> (task list).
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ See the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
+ guid="6.7335956461328426E-307">Planning Game Guidelines</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/product_quality.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/product_quality.xmi
new file mode 100644
index 0000000..694c958
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/product_quality.xmi
@@ -0,0 +1,169 @@
+<?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" epf:version="1.0.0" xmi:id="-nGaswirSOYturOoUWwGdRw" name="product_quality,3.712584012051524E-306" guid="-nGaswirSOYturOoUWwGdRw" changeDate="2006-11-10T10:10:29.938-0800" version="1.0.0">
+ <mainDescription><h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ If you're serious about producing an excellent product, you face two problems:
+</p>
+<ul>
+ <li>
+ How do you know when the product is good enough?
+ </li>
+ <li>
+ If the product is not yet good enough, how do you assure that the stakeholders involved know that?
+ </li>
+</ul>
+<p>
+ The answer to the first question lets you release the product. The answer to the second question helps you avoid
+ releasing a bad product.
+</p>
+<p>
+ You might think: "I don't want to ship a merely good enough product; I want to ship a <i>great</i> product!" Let's
+ explore that. What happens when you tell your coworkers, managers, or investors that you have high quality standards
+ and intend to ship a great product? If it's early in the project cycle, they probably nod and smile. Everyone likes
+ quality. However, if it's late in the project cycle, you're under a lot of pressure to complete the project. Creating a
+ great product might require that you perform extensive testing, fix many problems (even small ones), add features, or
+ even scrap and rewrite a large part of the code. You will also have to resolve disputes over different visions of good
+ quality. Greatness is hard work. Perfection is even harder! Eventually, the people who control the project will come to
+ you and say something like: "Perfection would be nice, but we have to be practical. We're running a business. Quality
+ is good, but not quality <i>at any cost</i>. As you know, all software has bugs."
+</p>
+<p>
+ Greatness can be a motivating goal. It appeals to the pride you have in your work. But there are problems with using
+ what amounts to "if quality is good, more quality must be better" to justify the pursuit of excellence. For one thing,
+ making such an argument can portray you as a quality fanatic, rather than a balanced thinker. For another thing, it
+ ignores the cost factor. A BMW is a nice car, but it costs a lot more than a Saturn. A Saturn may not be the ultimate
+ driving experience, but it's nice for the money. In leaving out cost, the <i><b>more is better</b></i> argument also
+ ignores diminishing returns. The better your product, the harder it gets to justify further improvement. While you
+ labor to gold-plate one aspect of a product, out of necessity you must ignore other aspects of the product or even the
+ potential opportunities presented by another project. The business has to make choices every day about the best use of
+ its resources. There are factors other than quality that must be considered.
+</p>
+<p>
+ The <i><b>good enough quality</b></i> concept (GEQ) is, paradoxically, a more effective argument than <i><b>more is
+ better</b></i>, because it provides a target that is either achievable or not achievable, in which case it becomes a de
+ facto argument for canceling or rechartering the project.
+</p>
+<h3>
+ <a id="GEQParadigms" name="GEQParadigms">Paradigms of Good Enough</a>
+</h3>
+<p>
+ Most businesses practice some form of good enough reasoning about their products. The only ones that don't are those
+ who believe they have achieved perfection, because they lack the imagination and skill to see how their products might
+ be improved.
+</p>
+<p>
+ Here are some models of <i><b>good enough</b></i> that have been tried. Some of them are more effective than others,
+ depending on the situation:
+</p>
+<ul>
+ <li>
+ <b>Not too Bad</b> <i>("we're not dead yet") -</i> Our quality only has to be good enough so we can continue to
+ stay in business. Make it good enough so that we aren't successfully sued.<br />
+ <br />
+ </li>
+ <li>
+ <b>Positive Infallibility</b> <i>("anything we do is good") -</i> Our organization is the best in the world.
+ Because we're so good, anything we do is automatically good. Think about success. Don't think about failure because
+ "negative" thinking makes for poor quality.<br />
+ <br />
+ </li>
+ <li>
+ <b>Righteous Exhaustion</b> <i>("perfection or bust") -</i> No product is good enough; it's effort that counts. And
+ only our complete exhaustion will be a good enough level of effort. Business issues are not our concern. We will do
+ everything we possibly can to make it perfect. Since we'll never be finished improving, someone will have to come
+ in and pry it from our fingers if they want it. Then they will bear the blame for any quality problems, not
+ us.<br />
+ <br />
+ </li>
+ <li>
+ <b>Customer is Always Right</b> <i>("customers seem to like it") -</i> If customers like it, it must be good
+ enough. Of course, you can't please everybody all the time. And if a current or potential customer doesn't like the
+ product, it's up to them to let us know. We can't read their minds.<br />
+ <br />
+ </li>
+ <li>
+ <b>Defined Process</b> <i>("we follow a Good Process") -</i> Quality is the result of the process we use to build
+ the product. We have defined our process and we think it's a good process. Therefore, as long as we follow the
+ process, a good enough product will inevitably result.<br />
+ <br />
+ </li>
+ <li>
+ <b>Static Requirements</b> <i>("we satisfy the Requirements") -</i> We have defined quality in terms of objective,
+ quantifiable, noncontroversial goals. If we meet those goals, we have a good enough product, no matter what other
+ subjective, non-quantifiable, controversial goals might be suggested.<br />
+ <br />
+ </li>
+ <li>
+ <b>Accountability</b> <i>("we fulfill our promises") -</i> Quality is defined by contract. We promise to do certain
+ things and achieve certain goals. If we fulfill our contract, that's good enough.<br />
+ <br />
+ </li>
+ <li>
+ <b>Advocacy</b> <i>("we make every reasonable effort") -</i> We advocate excellence. Throughout the project, we
+ look for ways to prevent problems, and to find and fix the ones we couldn't prevent. If we work faithfully toward
+ excellence, that will be good enough.<br />
+ <br />
+ </li>
+ <li>
+ <b>Dynamic Tradeoff</b> <i>("we weigh many factors") -</i> With respect to our mission and the situation at hand, a
+ product is good enough when it has sufficient benefits, no critical problems, its benefits sufficiently outweigh
+ its non-critical problems, and it would cause more harm than good to continue improving it.<br />
+ <br />
+ </li>
+</ul>
+<h3>
+ <a id="IsHighQualityExpensive" name="IsHighQualityExpensive">Is High Quality Necessarily More Expensive?</a>
+</h3>
+<p>
+ Depending on a lot of factors, such as process, skill, technology, tools, environment, and culture, you may be able to
+ produce a much higher quality product for the same cost. A more testable and maintainable product will cost less to
+ improve and other costs are specifically associated with poor quality, such as support costs and costs to the customer.
+</p>
+<p>
+ The cost of quality is a complex issue and it's difficult to make broad generalizations. However, you can say with
+ certainty that you can always spend more time on much better tests, much more error handling, and more fixing or
+ rewriting of every part of the product. No matter how good you are, that costs something. And if you can't think of
+ more improvements to make, it's more likely that you've reached the upper limit of your imagination, not of quality.
+</p>
+<p>
+ In the software industry GEQ is inspired more as a response to one particular cost than any other: the cost of not
+ releasing the product <i>soon enough</i>. The specter of the market window, or the external deadline, imposes penalties
+ upon us if we can't meet the challenge. That's why the ends of projects are so often characterized by frenzied triage.
+ If you want to know what an organization really believes is good enough, and how well prepared they are for it, witness
+ the last three days of any six-month software project. See what happens when a new problem is reported on the last day.
+</p>
+<h3>
+ <a id="Quantification" name="Quantification">Wouldn't Quantification Help?</a>
+</h3>
+<p>
+ It can be tempting to reduce quality to a number, then set a numerical threshold that represents good enough quality.
+ This is a problem, because you can only measure factors that <i>relate</i> to quality. You can't measure quality
+ itself. This is partly because the word "quality" is just a label for a relationship between a person and a thing.
+ "This product is high in quality" is just another way of saying "Somebody values this product". It's a statement about
+ the product, but also a statement about people and the surrounding context. Even if the product stays the same, people
+ and situations change, so there can be no single, static, <i>true</i> measure of quality.
+</p>
+<p>
+ There are many measures you might use to get a sense of quality, even if you can't measure it completely and
+ objectively. Even so, the question of what quality is good enough requires sophisticated judgment. You can't escape
+ from the fact that, in the end, people have to think it through and make a judgment. For a simple product, that
+ judgment might be easy. For a complex, high-stakes product, it's very difficult.
+</p>
+<h3>
+ <a id="FurtherInfo" name="FurtherInfo">Further Information</a>
+</h3>
+<p>
+ To assist you with evaluating product quality, the following types of information are available for most of the
+ artifacts included in the Unified Process:
+</p>
+<ul>
+ <li>
+ Artifact Guidelines and Checkpoints: information on how to develop, evaluate, and use the artifact.
+ </li>
+ <li>
+ Templates: "models" or prototypes of the artifact, providing structure and guidance for content.<br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/refactoring_xp_programming.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/refactoring_xp_programming.xmi
new file mode 100644
index 0000000..34d0dbb
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/refactoring_xp_programming.xmi
@@ -0,0 +1,75 @@
+<?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" epf:version="1.0.0" xmi:id="-U8NScY6mORb4XPcNZ_mrEA" name="refactoring_xp_programming,1.4410217108363206E-306" guid="-U8NScY6mORb4XPcNZ_mrEA" changeDate="2006-11-09T16:20:46.023-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__refactoring" name="XE_xp__refactoring"></a><a id="XE_refactoring__practice_of"
+name="XE_refactoring__practice_of"></a><a id="XE_engineering_practices__refactoring"
+name="XE_engineering_practices__refactoring"></a>
+<h3>
+ Description
+</h3>
+<p>
+ Refactoring is the practice of improving the design of a system without changing its behavior. Refactoring is a
+ critical practice and skill in iterative development. The programmer is either adding a new feature or refactoring. XP
+ programmers consciously choose between refactoring and adding new functionality on a minute-by-minute basis. Some
+ refactorings are trivial, such as renaming or moving things. Other refactorings allow you to exchange procedural logic
+ with polymorphism, and still larger refactorings exist to introduce design patterns.
+</p>
+<p>
+ While processes like Extreme Programming rely on refactoring to let the design emerge, the usefulness of refactoring
+ extends beyond the Agile Methodologies. As feature requests and bug fixes require changes to a system, refactoring
+ techniques allow the programmers to maintain a good design. Refactoring can also be used to improve the design of an
+ existing system.
+</p>
+<p>
+ Refactoring is not new. Developers have been refactoring for years, though only recently have people started to catalog
+ refactorings. Refactoring has become such an important part of development that professional-level Integrated
+ Development Environments (IDEs) either include built-in tools or have plug-ins to provide refactoring support.
+</p>
+<p>
+ If your system isn't being refactored as it is modified, your design deteriorates; methods become longer, classes take
+ on more responsibility, more code gets cut and pasted around your system, previously cut-and-pasted code has to be
+ modified in several places.
+</p>
+<p>
+ If your system becomes brittle and inflexible, your developers will have to spend more time and money to add features
+ or fix bugs. As the design continues to deteriorate, fixing one bug creates two more, or the cost of adding a new
+ feature out weighs the benefit of having it because so much of the system has to be modified. There are many analogies
+ to describe this battle against entropy; from cleaning as you go to design debt.
+</p>
+<p>
+ Knowing the refactorings isn't enough. Developers must be able to identify problem areas of the program design (often
+ referred to as "smells"). These are the places where refactoring can be used to improve the design of the code. Design
+ skill and experience are needed to recognize bad code smells.
+</p>
+<p>
+ Automated tests provide a safety net when making changes. The automated tests report when the functionality of the
+ system changes. Make a structural change to the software; see that the tests still pass. You can confidently refactor.
+</p>
+<p>
+ Where do all these tests come from? In XP, they are developed using <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
+ guid="1.620567348185129E-306">Test-Driven Development</a>. It is possible to refactor without tests, but you run the
+ risk of unknowingly introducing bugs or breaking existing functionality.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Allows the design to emerge over time.
+ </li>
+ <li>
+ Keeps the design from rotting.
+ </li>
+ <li>
+ Reduces cost of change.
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ &nbsp;See the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html"
+ guid="8.137126904637637E-306">Refactoring Guidelines</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img1.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img1.gif
new file mode 100644
index 0000000..8082009
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img2.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img2.gif
new file mode 100644
index 0000000..381f405
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img2.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img3.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img3.gif
new file mode 100644
index 0000000..e7f17aa
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/dvltst-img3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img1.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img1.gif
new file mode 100644
index 0000000..8b22b05
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img2.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img2.gif
new file mode 100644
index 0000000..d17d10e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img2.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img3.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img3.gif
new file mode 100644
index 0000000..182076e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img4.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img4.gif
new file mode 100644
index 0000000..d06ff22
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img4.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img5.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img5.gif
new file mode 100644
index 0000000..f7fc9cd
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstfrsdsg-img5.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstids_short-catalog.pdf b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstids_short-catalog.pdf
new file mode 100644
index 0000000..d88327c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstids_short-catalog.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidsctl-img1.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidsctl-img1.gif
new file mode 100644
index 0000000..b61b1c9
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidsctl-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidsctl-img2.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidsctl-img2.gif
new file mode 100644
index 0000000..9951dc2
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidsctl-img2.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidslst-img1.gif b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidslst-img1.gif
new file mode 100644
index 0000000..ac8fd5f
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/resources/tstidslst-img1.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/simple_design.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/simple_design.xmi
new file mode 100644
index 0000000..c8b3b3a
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/simple_design.xmi
@@ -0,0 +1,112 @@
+<?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" epf:version="1.0.0" xmi:id="-0rSxLFlmQfyKrgnqi1NKrg" name="simple_design,1.6109092258980447E-306" guid="-0rSxLFlmQfyKrgnqi1NKrg" changeDate="2006-11-08T16:39:05.846-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__simple_design" name="XE_xp__simple_design"></a><a id="XE_simple_design__practice_of"
+name="XE_simple_design__practice_of"></a><a id="XE_engineering_practices__simple_design"
+name="XE_engineering_practices__simple_design"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The design strategy in XP is to create the simplest design that meets your current requirements, as reflected in the
+ current test cases. In many domains, "simplest design" is ambiguous, but it is a well-defined term in XP. A simple
+ design has these four characteristics, listed in priority order:
+</p>
+<ul>
+ <li>
+ The system runs all the tests.
+ </li>
+ <li>
+ It contains no duplicate code.
+ </li>
+ <li>
+ The code states the programmers's intent very clearly.
+ </li>
+ <li>
+ It contains the fewest possible number of classes and methods.
+ </li>
+</ul>
+<p>
+ Design in Extreme Programming is much more incremental than in any other methodology. The practice of Test-Driven
+ Development describes how the system is created in many small steps, driven by tests that programmers write. Each of
+ these tests is a probe into the design of the system, allowing the developers to explore the system as it is being
+ created. This is quite a contrast to other methodologies where design is a separate phase of either the project or the
+ iteration. In XP, design quite literally happens all the time.
+</p>
+<p>
+ It takes a tremendous amount of courage to stop designing and start coding. Almost all developers are taught that they
+ should understand everything about the system before committing that knowledge to code. The reason, they've always been
+ told, is that code is hard to change. Once it is laid on its virtual paper, changing it involves understanding the
+ hidden assumptions of the original developer, unseen couplings, months-long validation and verification procedures,
+ etc. But if code could be changed with impunity, developers could afford to defer design decisions until later,
+ understand the system incrementally, and implement in pieces.
+</p>
+<p>
+ The strategy of building software in this manner is based on the following reasoning:
+</p>
+<ul>
+ <li>
+ Given that all requirements aren't known on the first day of the project, the development style must be adjusted to
+ accommodate new understanding from customers and changes in the business climate.
+ </li>
+ <li>
+ If a design decision does not have to be made now, avoid guessing by deferring the decision until it is needed. By
+ that time, there is a better chance that enough understanding will exist to support a better decision.
+ </li>
+ <li>
+ Change happens during the lifetime of a project. Decisions made once will be changed. The software must be designed
+ and implemented in such a way that changes can be accommodated easily.
+ </li>
+ <li>
+ Designs seldom survive their first skirmish with code. The act of coding provides feedback to the developer about
+ the system. This learning must be reflected in the design. If the design is already cast before coding begins, this
+ feedback is more difficult and costly to put back into the design.
+ </li>
+</ul>
+<p>
+ Here are some guidelines to help in arriving at a simple design:
+</p>
+<ul>
+ <li>
+ Look for a simple way to solve a problem. Software is hard, so there will be plenty of time for complexity later.
+ For now, keep it simple. Simple, however, does not mean stupid. Pay attention to good design principles when
+ forming a system incrementally.
+ </li>
+ <li>
+ Resist the temptation to add infrastructure or other features that might be needed later. Chances are they won't be
+ (YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design.
+ </li>
+ <li>
+ Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep
+ implementation simple. Let the second user pay for the generality.
+ </li>
+ <li>
+ Seek out and destroy duplication. The practice of <a class="elementLink"
+ href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
+ guid="1.4410217108363206E-306">Refactoring</a> is the most powerful tool in the arsenal. It is through removing
+ duplication that new classes, methods, and larger scale systems are born.
+ </li>
+ <li>
+ Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated
+ again in less time and better than the first time by leveraging what was learned the first time.
+ </li>
+</ul>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Small initial investment</b>: There is no need to invest in frameworks or generality that might be or might not
+ be required in the future.
+ </li>
+ <li>
+ <b>Maintainability</b>: Simple design will keep the design from rotting and dying prematurely. The more complex the
+ design is, the harder it is to understand and preserve and the more rapidly it will decay.
+ </li>
+ <li>
+ <b>Flexibility</b>: Simple systems are always easier to change than more complex systems.
+ </li>
+ <li>
+ <b>Agility</b>: Simple systems are faster to change than more complex systems.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/small_releases.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/small_releases.xmi
new file mode 100644
index 0000000..88f0990
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/small_releases.xmi
@@ -0,0 +1,33 @@
+<?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" epf:version="1.0.0" xmi:id="-vcCn_ksJo5Jw27aNZb1Cvw" name="small_releases,5.762953011420275E-306" guid="-vcCn_ksJo5Jw27aNZb1Cvw" changeDate="2006-11-09T15:03:57.390-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__small_releases" name="XE_xp__small_releases"></a><a id="XE_small_releases__practice_of"
+name="XE_small_releases__practice_of"></a><a id="XE_engineering_practices__small_releases"
+name="XE_engineering_practices__small_releases"></a>
+<h3>
+ Description
+</h3>
+<p>
+ There are many developers who have spent years developing software and yet never had any of it released into use.
+ Fortunately, this situation is becoming rarer, but it still happens. There are many reasons why some software never
+ gets put into production, but often a key factor is the size of releases. Releasing software is much like integrating
+ source code changes in a project: the longer you delay it, the tougher it becomes. Releasing software into production
+ frequently is a good way of getting feedback. Users will often think of issues that they would not have without actual
+ experience using the software. Getting that feedback early enhances the overall quality of the product.
+</p>
+<p>
+ In XP, we recommend release cycles of three to four months at most.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Small releases increase feedback</b>. Discrepancies between the system that is needed and the system being
+ developed are found early.
+ </li>
+ <li>
+ Putting pieces of a system into production frequently raises the quality consciousness of the project. The
+ <b>system must consistently be good enough to ship</b>.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/test-first_design.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/test-first_design.xmi
new file mode 100644
index 0000000..7e2335b
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/test-first_design.xmi
@@ -0,0 +1,312 @@
+<?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" epf:version="1.0.0" xmi:id="-3AbfvnHrCOIQS63sEjrOew" name="test-first_design,6.556259235358794E-306" guid="-3AbfvnHrCOIQS63sEjrOew" changeDate="2006-11-13T15:58:35.617-0800" version="1.0.0">
+ <mainDescription><a id="XE_test__developer_testing__test-first_design" name="XE_test__developer_testing__test-first_design"></a><a
+id="XE_design__test-first_design" name="XE_design__test-first_design"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Test designs are created using information from a variety of artifacts, including design artifacts such as use case
+ realizations, design models, or classifier interfaces. Tests are executed after components are created. It's typical to
+ create the test designs just before the tests are to be executed - well after the software design artifacts are
+ created. Figure 1, following, shows an example. Here, test design begins sometime toward the end of implementation. It
+ draws on the results of component design. The arrow from Implementation to Test Execution indicates that the tests
+ can't be executed until the implementation is complete.
+</p>
+<p align="center">
+ <img height="159" alt="" src="resources/tstfrsdsg-img1.gif" width="614" />
+</p>
+<p class="picturetext">
+ Fig1: Traditionally, Test Design is performed later in the life-cycle
+</p>
+<p>
+ However, it doesn't have to be this way. Although test execution has to wait until the component has been implemented,
+ test design can be done earlier. It could be done just after the design artifact is completed. It could even be done in
+ parallel with component design, as shown here:
+</p>
+<p align="center">
+ <img height="158" alt="" src="resources/tstfrsdsg-img2.gif" width="610" />
+</p>
+<p class="picturetext">
+ Fig2: Test-first Design brings test design chronologically in-line with software design
+</p>
+<p>
+ Moving the test effort "upstream" in this way is commonly called "test-first design". What are its advantages?
+</p>
+<ol>
+ <li>
+ No matter how carefully you design software, you'll make mistakes. You might be missing a relevant fact. Or you
+ might have particular habits of thought that make it hard for you to see certain alternatives. Or you might just be
+ tired and overlook something. Having other people review your design artifacts helps. They might have the facts you
+ miss, or they might see what you overlooked. It's best if these people have a different perspective than you do; by
+ looking at the design differently, they'll see things you missed.<br />
+ <br />
+ Experience has shown that the testing perspective is an effective one. It's relentlessly concrete. During software
+ design, it's easy to think of a particular field as "displaying the title of the current customer" and move on
+ without really thinking about it. During test design, you must decide <i>specifically</i> what that field will show
+ when a customer who retired from the Navy and then obtained a law degree insists on referring to himself as
+ "Lieutenant Morton H. Throckbottle (Ret.), Esq." Is his title "Lieutenant" or "Esquire"?<br />
+ <br />
+ If test design is deferred until just before test execution, as in Figure 1, you'll probably waste money. A
+ mistake in your software design will remain uncaught until test design, when some tester says, "You know, I knew
+ this guy from the Navy...", creates the "Morton" test, and discovers the problem. Now a partially or fully complete
+ implementation has to be rewritten and a design artifact has to be updated. It would be cheaper to catch the
+ problem before implementation begins.<br />
+ </li>
+ <li>
+ Some mistakes might be caught before test design. Instead, they'll be caught by the Implementer. That's still bad.
+ Implementation must grind to a halt while the focus switches from how to implement the design to what that design
+ should be. That's disruptive even when the Implementer and Designer roles are filled by the same person; it's much
+ more disruptive when they're different people. Preventing this disruption is another way in which test-first design
+ helps improve efficiency.<br />
+ </li>
+ <li>
+ Test designs help Implementers in another way-by clarifying design. If there's a question in the Implementer's mind
+ about what the design meant, the test design might serve as a specific example of the desired behavior. That will
+ lead to fewer bugs due to Implementer misunderstanding.<br />
+ </li>
+ <li>
+ There are fewer bugs even if the question <i>wasn't</i> in the Implementer's mind - but should have been. For
+ example, there might have been an ambiguity that the Designer unconsciously interpreted one way and the Implementer
+ another. If the Implementer is working from both the design and also from specific instructions about what the
+ component is supposed to do - from test cases - the component is more likely to actually do what is required.
+ </li>
+</ol>
+<h3>
+ <a id="Examples" name="Examples">Examples</a>
+</h3>
+<p>
+ Here are some examples to give you the flavor of test-first design.
+</p>
+<p>
+ Suppose you're creating a system to replace the old "ask the secretary" method of assigning meeting rooms. One of the
+ methods of the <font size="+0">MeetingDatabase</font> class is called <font size="+0">getMeeting</font>, which has this
+ signature:
+</p>
+<blockquote>
+<pre>
+Meeting getMeeting(Person, Time);
+</pre>
+</blockquote>
+<p>
+ Given a person and a time, <font size="+0">getMeeting</font> returns the meeting that person is scheduled to be in at
+ that time. If the person isn't scheduled for anything, it returns the special <font size="+0">Meeting</font> object
+ <font size="+0">unscheduled</font>. There are some straightforward test cases:
+</p>
+<ul>
+ <li>
+ The person isn't in any meeting at the given time. Is the <font size="+0">unscheduled</font> meeting returned?
+ </li>
+ <li>
+ The person is in a meeting at that time. Does the method return the correct meeting?
+ </li>
+</ul>
+<p>
+ These test cases are unexciting, but they need to be tried eventually. They might as well be created now, by writing
+ the actual test code that will someday be run. Java code for the first test might look like this:
+</p>
+<pre>
+ // if not in a meeting at given time,
+ // expect to be unscheduled.
+ public void testWhenAvailable() {
+Person fred = new Person("fred");
+Time now = Time.now();
+MeetingDatabase db = new MeetingDatabase();
+expect(db.getMeeting(fred, now) == Meeting.unscheduled);
+ }
+</pre>
+<p>
+ But there are more interesting test ideas. For example, this method searches for a match. Whenever a method searches,
+ it's a good idea to ask what should happen if the search finds more than one match. In this case, that means asking
+ "Can a person be in two meetings at once?" Seems impossible, but asking the secretary about that case might reveal
+ something surprising. It turns out that some executives are quite often scheduled into two meetings at once. Their role
+ is to pop into a meeting, "rally the troops" for some short amount of time, and then move on. A system that didn't
+ accommodate that behavior would go at least partially unused.
+</p>
+<p>
+ This is an example of test-first design done at the implementation level catching an analysis problem. There are a few
+ things to note about that:
+</p>
+<ol>
+ <li>
+ You would hope that good use-case specification and analysis would have already discovered this requirement. In
+ that case, the problem would have been avoided "upstream" and <font size="+0">getMeeting</font> would have been
+ designed differently. (It couldn't return a meeting; it would have to return a set of meetings.) But analysis
+ always misses some problems, and it's better for them to be discovered during implementation than after
+ deployment.<br />
+ </li>
+ <li>
+ In many cases, Designers and Implementers won't have the domain knowledge to catch such problems - they won't have
+ the opportunity or time to quiz the secretary. In that case, the person designing tests for <font
+ size="+0">getMeeting</font> would ask, "is there a case in which two meetings should be returned?", think for a
+ while, and conclude that there wasn't. So test-first design doesn't catch every problem, but the mere fact of
+ asking the right kinds of questions increases the chance a problem will be found.<br />
+ </li>
+ <li>
+ Some of the same testing techniques that apply during implementation also apply to analysis. Test-first design can
+ be done by analysts as well, but that's not the topic of this page.
+ </li>
+</ol>
+<p>
+ The second of the three examples is a statechart model for a heating system.
+</p>
+<p align="center">
+ <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
+</p>
+<p class="picturetext">
+ Fig3: HVAC Statechart
+</p>
+<p>
+ A set of tests would traverse all the arcs in the statechart. One test might begin with an idle system, inject a Too
+ Hot event, fail the system during the Cooling/Running state, clear the failure, inject another Too Hot event, then run
+ the system back to the Idle state. Since that does not exercise all the arcs, more tests are needed. These kinds of
+ tests look for various kinds of implementation problems. For example, by traversing every arc, they check whether the
+ implementation has left one out. By using sequences of events that have failure paths followed by paths that should
+ successfully complete, they check whether error-handling code fails to clean up partial results that might affect later
+ computation. (For more about testing statecharts, see <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
+ guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Activity Diagrams</a>.)
+</p>
+<p>
+ The final example uses part of a design model. There's an association between a creditor and an invoice, where any
+ given creditor can have more than one invoice outstanding.
+</p>
+<p align="center">
+ <img height="45" alt="" src="resources/tstfrsdsg-img4.gif" width="186" />
+</p>
+<p class="picturetext">
+ Fig4: Association between Creditor and Invoice Classes
+</p>
+<p>
+ Tests based on this model would exercise the system when a creditor has no invoices, one invoice, and a large number of
+ invoices. A tester would also ask whether there are situations in which an invoice might need to be associated with
+ more than one creditor, or where an invoice has no creditor. (Perhaps the people who currently run the paper-based
+ system the computer system is to replace use creditor-less invoices as a way to keep track of pending work). If so,
+ that would be another problem that should have been caught in Analysis.
+</p>
+<h3>
+ <a id="WhoDoesTest-FirstDesign" name="WhoDoesTest-FirstDesign">Who does test-first design?</a>
+</h3>
+<p>
+ Test-first design can be done by either the author of the design or by someone else. It's common for the author to do
+ it. The advantage is that it reduces communication overhead. The Designer and Test Designer don't have to explain
+ things to each other. Further, a separate Test Designer would have to spend time learning the design well, whereas the
+ original Designer already knows it. Finally, many of these questions - like "what happens if the compressor fails in
+ state X?" - are natural questions to ask during both software artifact design and test design, so you might as well
+ have the same person ask them exactly once and write the answers down in the form of tests.
+</p>
+<p>
+ There are disadvantages, though. The first is that the Designer is, to some extent, blind to his or her own mistakes.
+ The test design process will reveal some of that blindness, but probably not as much as a different person would find.
+ How much of a problem this is seems to vary widely from person to person and is often related to the amount of
+ experience the Designer has.
+</p>
+<p>
+ Another disadvantage of having the same person do both software design and test design is that there's no parallelism.
+ Whereas allocating the roles to separate people will take more total effort, it will probably result in less elapsed
+ calendar time. If people are itching to move out of design and into implementation, taking time for test design can be
+ frustrating. More importantly, there's a tendency to skimp on the work in order to move on.
+</p>
+<h3>
+ <a id="CanAllTestDesignBeDoneAtComponentDesignTime" name="CanAllTestDesignBeDoneAtComponentDesignTime">Can all test
+ design be done at component design time?</a>
+</h3>
+<p>
+ No. The reason is that not all decisions are made at design time. Decisions made during implementation won't be
+ well-tested by tests created from the design. The classic example of this is a routine to sort arrays. There are many
+ different sorting algorithms with different tradeoffs. Quicksort is usually faster than an insertion sort on large
+ arrays, but often slower on small arrays. So a sorting algorithm might be implemented to use Quicksort for arrays with
+ more than 15 elements, but insertion sort otherwise. That division of labor might be invisible from design artifacts.
+ You <i>could</i> represent it in a design artifact, but the Designer might have decided that the benefit of making such
+ explicit decisions wasn't worthwhile. Since the size of the array plays no role in the design, the test design might
+ inadvertently use only small arrays, meaning that none of the Quicksort code would be tested at all.
+</p>
+<p>
+ As another example, consider this fraction of a sequence diagram. It shows a <font size="+0">SecurityManager</font>
+ calling the <font size="+0">log()</font> method of <font size="+0">StableStore</font>. In this case, though, the <font
+ size="+0">log()</font> returns a failure, which causes <font size="+0">SecurityManager</font> to call <font
+ size="+0">Connection.close()</font>.
+</p>
+<p align="center">
+ <img height="161" alt="" src="resources/tstfrsdsg-img5.gif" width="303" />
+</p>
+<p class="picturetext">
+ Fig5: SecurityManager sequence diagram instance
+</p>
+<p>
+ This is a good reminder to the Implementer. Whenever <font size="+0">log()</font> fails, the connection must be closed.
+ The question for testing to answer is whether the Implementer really did it-and did it correctly-in <i>all</i> cases or
+ just in <i>some</i>. To answer the question, the Test Designer must find all the calls to <font
+ size="+0">StableStore.log()</font> and make sure each of those call points is given a failure to handle.
+</p>
+<p>
+ It might seem odd to run such a test, given that you've just looked at all the code that calls <font
+ size="+0">StableStore.log()</font>. Can't you just check to see if it handles failure correctly?
+</p>
+<p>
+ Perhaps inspection might be enough. But error-handling code is notoriously error-prone because it often implicitly
+ depends on assumptions that the existence of the error has violated. The classic example of this is code that handles
+ allocation failures. Here's an example:
+</p>
+<blockquote>
+<pre>
+while (true) { // top level event loop
+ try {
+XEvent xe = getEvent();
+... // main body of program
+ } catch (OutOfMemoryError e) {
+emergencyRestart();
+ }
+}
+</pre>
+</blockquote>
+<p>
+ This code attempts to recover from out of memory errors by cleaning up (thus making memory available) and then
+ continuing to process events. Let's suppose that's an acceptable design. <font size="+0">emergencyRestart</font> takes
+ great care not to allocate memory. The problem is that <font size="+0">emergencyRestart</font> calls some utility
+ routine, which calls some other utility routine, which calls some other utility routine-which allocates a new object.
+ Except that there's no memory, so the whole program fails. These kinds of problems are hard to find through inspection.
+</p>
+<h3>
+ <a id="Test-FirstDesignAndRUPPhases" name="Test-FirstDesignAndRUPPhases">Test-first design and the phases
+ of&nbsp;Unified</a> Process
+</h3>
+<p>
+ Up to this point, we've implicitly assumed that you'd do as much test design as possible as early as possible. That is,
+ you'd derive all the tests you could from the design artifact, later adding only tests based on implementation
+ internals. That may not be appropriate in the Elaboration phase, because such complete testing may not be aligned with
+ an iteration's objectives.
+</p>
+<p>
+ Suppose an architectural prototype is being built to demonstrate product feasibility to investors. It might be based on
+ a few key use-case instances. Code should be tested to see that it supports them. But is there any harm if further
+ tests are created? For example, it might be obvious that the prototype ignores important error cases. Why not document
+ the need for that error handling by writing test cases that will exercise it?
+</p>
+<p>
+ But what if the prototype does its job and reveals that the architectural approach won't work? Then the architecture
+ will be thrown away - along with all those tests for error-handling. In that case, the effort of designing the tests
+ will have yielded no value. It would have been better to have waited, and only designed those tests needed to check
+ whether this proof-of-concept prototype really proves the concept.
+</p>
+<p>
+ This may seem a minor point, but there are strong psychological effects in play. The Elaboration phase is about
+ addressing major risks. The whole project team should be focused on those risks. Having people concentrating on minor
+ issues drains focus and energy from the team.
+</p>
+<p>
+ So where might test-first design be used successfully in the Elaboration phase? It can play an important role in
+ adequately exploring architectural risks. Considering how, precisely, the team will know if a risk has been realized or
+ avoided will add clarity to the design process and may well result in a better architecture being built the first time.
+</p>
+<p>
+ During the Construction phase, design artifacts are put into their final form. All the required use-case realizations
+ are implemented, as are the interfaces for all classes. Because the phase objective is completeness, complete
+ test-first design is appropriate. Later events should invalidate few, if any, tests.
+</p>
+<p>
+ The Inception and Transition phases typically have less focus on design activities for which testing is appropriate.
+ When it is, test-first design is applicable. For example, it could be used with candidate proof-of-concept work in
+ Inception. As with Construction and Elaboration phase testing, it should be aligned with iteration objectives.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/test-ideas_catalog.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/test-ideas_catalog.xmi
new file mode 100644
index 0000000..157b36b
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/test-ideas_catalog.xmi
@@ -0,0 +1,458 @@
+<?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" epf:version="1.0.0" xmi:id="-OrjIrRLW6v_XnqLUQ9GYaQ" name="test-ideas_catalog,1.2384224477983028E-305" guid="-OrjIrRLW6v_XnqLUQ9GYaQ" changeDate="2006-12-01T16:08:47.336-0800" version="1.0.0">
+ <mainDescription><a id="XE_test-ideas_catalog__concept_of" name="XE_test-ideas_catalog__concept_of"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Much of programming involves taking things you've used over and over before, and then using them yet again in a
+ different context. Those things are typically of certain classes-data structures (such as linked lists, hash tables, or
+ relational databases) or <a href="./../../../glossary/glossary.htm#operation" target="_blank"><i>operations</i></a>
+ (such as searching, sorting, creating temporary files, or popping up a browser window). For example, two customer
+ relational databases will have many clichéd characteristics.
+</p>
+<p>
+ The interesting thing about these clichés is that they have clichéd <a href="./../../../glossary/glossary.htm#fault"
+ target="_blank"><i>faults</i></a>. People do not invent imaginative new ways to insert something incorrectly into a
+ doubly-linked list. They tend to make the same mistakes that they and others have made before. A programmer who pops up
+ a browser window might make one of these clichéd mistakes:
+</p>
+<ul>
+ <li>
+ creates a new window when one that's already open should be reused
+ </li>
+ <li>
+ fails to make an obscured or minimized browser window visible
+ </li>
+ <li>
+ uses Internet Explorer when the user has chosen a different default browser
+ </li>
+ <li>
+ fails to check whether JavaScript is enabled
+ </li>
+</ul>
+<p>
+ Since faults are clichéd, so are the <a href="./../../../glossary/glossary.htm#test_idea" target="_blank"><i>test
+ ideas</i></a> that can find them. Put these test ideas in your test-idea catalog so you can reuse them.
+</p>
+<h3>
+ <a id="HowCatalogsFindFaults" name="HowCatalogsFindFaults">How a Test-Ideas Catalog Finds Faults</a>
+</h3>
+<p>
+ One of the virtues of a catalog is that a single test idea can be useful for finding more than one underlying fault.
+ Here's an example of one idea that finds two faults.
+</p>
+<p>
+ The first fault was in a C compiler. This compiler took command-line options like "-table" or "-trace" or "-nolink".
+ The options could be abbreviated to their smallest unique form. For example, "-ta" was as good as "-table". However,
+ "-t" was not allowed, because it was ambiguous: it could mean either "-table" or "-trace".
+</p>
+<p>
+ Internally, the command-line options were stored in a table like this:
+</p>
+<div align="left">
+ <table cellspacing="0" cellpadding="2" width="25%" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ -table
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ -trace
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ -nolink
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ When an option was encountered on the command line, it was looked up in the table. It matched if it was the prefix of
+ any table entry; that is, "-t" matched "-table". After one match was found, the rest of the table was searched for
+ another match. Another match would be an error, because it would indicate ambiguity.
+</p>
+<p>
+ The code that did the searching looked like this:
+</p>
+<blockquote>
+<pre>
+for (first=0; first &lt; size; first++) {
+ if (matches(entry[first], thing_sought)) {
+/* at least one match */
+for(dup=first+1; dup &lt; size; dup++)
+ /* search for another */
+ if (matches(entry[dup], thing_sought))
+ /* extra match */
+ break; /* error out */
+return first;
+ }
+}
+return -1; /* Not found or ambiguity */
+</pre>
+</blockquote>
+<p>
+ Do you see the problem? It's fairly subtle.
+</p>
+<p>
+ The problem is the break statement. It's intended to break out of the outermost enclosing loop when a duplicate match
+ is found, but it really breaks out of the inner one. That has the same effect as not finding a second match: the index
+ of the first match is returned.
+</p>
+<p>
+ Notice that this fault can only be found if the option being sought for matches twice in the table, as "-t" would.
+</p>
+<p>
+ Now let's look at a second, completely different fault.
+</p>
+<p>
+ The code takes a string. It is supposed to replace the last '=' in the string with a '+'. If there is no '=', nothing
+ is done. The code uses the standard C library routine <font size="+0">strchr</font> to find the location of '='. Here's
+ the code:
+</p>
+<blockquote>
+<pre>
+ptr = strchr(string, '='); /* Find last = */
+if (ptr != NULL_CHAR)
+ *ptr = '+';
+</pre>
+</blockquote>
+<p>
+ This problem here is also somewhat subtle.
+</p>
+<p>
+ The function <font size="+0">strchr</font> returns the <i>first</i> match in the string, not the last. The correct
+ function is <font size="+0">str<b><u>r</u></b>chr</font>. The problem was most likely a typographical error. (Actually,
+ the deep underlying problem is that it's definitely unwise to put two functions that differ only by a typo into a
+ standard library.)
+</p>
+<p>
+ This fault can only be found when there are two or more equal signs in the input. That is:
+</p>
+<ul>
+ <li>
+ "a=b" would return the correct result, "a+b".
+ </li>
+ <li>
+ "noequals" would return the correct result, "noequals".
+ </li>
+ <li>
+ "a=b=c" would incorrectly return "a+b=c", not the correct "a=b+c"
+ </li>
+</ul>
+<p>
+ What's interesting and useful here is that we have two faults with completely different root causes (typographical
+ error, misunderstanding of a C construct) and different manifestations in the code (wrong function called, misuse of
+ break statement) that can be found by the <i>same</i> test idea (search for something that occurs twice).
+</p>
+<h3>
+ <a id="GoodCatalogs" name="GoodCatalogs">A Good Test-Ideas Catalog</a>
+</h3>
+<p>
+ What makes a good catalog?
+</p>
+<ul>
+ <li>
+ It contains a small set of test ideas that can find a much larger set of underlying faults.
+ </li>
+ <li>
+ It's easy to read quickly (skim). You should be able to skip test ideas that are not relevant to your situation.
+ </li>
+ <li>
+ It contains only test ideas that you will use. For example, someone who doesn't ever deal with Web browsers
+ shouldn't have to keep skipping over test ideas for programs that use Web browsers. Someone working on game
+ software will want a shorter catalog than someone working on safety-critical software. The game person can afford
+ to concentrate only on the test ideas with the highest chance of finding faults.
+ </li>
+</ul>
+<p>
+ Given these rules, it seems best to have more than one catalog. Some data and operations are common to all programming,
+ so their test ideas can be put into a catalog that all programmers can use. Others are specific to a particular domain,
+ so test ideas for them can be put into a catalog of domain-specific test ideas.
+</p>
+<p>
+ A sample catalog (<a href="./resources/tstids_short-catalog.pdf" target="_blank">tstids_short-catalog.pdf</a>) (<a
+ href="http://www.adobe.com/products/acrobat/alternate.html">Get Adobe Reader</a>), used in the following example, is a
+ good one from which to begin. <a href="../../../examples/extrnlcntrbtns/test/tstatmtch.htm">Test Ideas for Mixtures of
+ ANDs and ORs</a> provides another example.
+</p>
+<h3>
+ <a id="UsingACatalogExample" name="UsingACatalogExample">An Example of Using a Test-Ideas Catalog</a>
+</h3>
+<p>
+ Here's how you might use the sample catalog (<a href="./resources/tstids_short-catalog.pdf"
+ target="_blank">tstids_short-catalog.pdf</a>) (<a href="http://www.adobe.com/products/acrobat/alternate.html">Get
+ Acrobat Reader</a>). Suppose you're implementing this method:
+</p>
+<blockquote>
+<pre>
+void applyToCommonFiles(Directory d1,
+ Directory d2,
+ Operation op);
+</pre>
+</blockquote>
+<p>
+ <font size="+0">applyToCommonFiles</font> takes two directories as arguments. When a file in the first directory has
+ the same name as a file in the second, <font size="+0">applyToCommonFiles</font> performs some operation on that pair
+ of files. It descends subdirectories.
+</p>
+<p>
+ The method for using the catalog is to scan through it looking for major headings that match your situation. Consider
+ the test ideas under each heading to see if they are relevant, and then write those that are relevant into a <a
+ class="elementLink" href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html"
+ guid="8.834380241450745E-306">Test-Ideas List</a>.
+</p>
+<p>
+ <b>Note:</b> This step-by-step description might make using the catalog seem laborious. It takes longer to read about
+ creating the checklist than it does to actually create one.
+</p>
+<p>
+ So, in the case of <font size="+0">applyToCommonFiles</font>, you might apply the catalog in the manner described
+ throughout the rest of this section.
+</p>
+<p>
+ The first entry is for <b>Any Object</b>. Could any of the arguments be null pointers? This is a matter of the contract
+ between <font size="+0">applyToCommonFiles</font> and its callers. The contract could be that the callers will not pass
+ in a null pointer. If they do, you can't rely on th expected behavior: <font size="+0">applyToCommonFiles</font> could
+ perform any action. In such a case, no test is appropriate, since nothing <font size="+0">applyToCommonFiles</font>
+ does can be wrong. If, however, <font size="+0">applyToCommonFiles</font> is required to check for null pointers, the
+ test idea would be useful. Let's assume the latter, which gives us this starting Test-Ideas List:
+</p>
+<ul>
+ <li>
+ d1 is null (error case)
+ </li>
+ <li>
+ d2 is null (error case)
+ </li>
+ <li>
+ op is null (error case)
+ </li>
+</ul>
+<p>
+ The next catalog entry is <b>Strings</b>. The names of the files are strings, and they're compared to see if they
+ match. The idea of testing with the empty string ("") doesn't seem useful. Presumably some standard string comparison
+ routines will be used, and they will handle empty strings correctly.
+</p>
+<p>
+ But wait... If there are strings being compared, what about case? Suppose <font size="+0">d1</font> contains a file
+ named "File" and <font size="+0">d2</font> contains a file named "file". Should those files match? On UNIX, clearly
+ not. On Microsoft&reg; Windows&reg;, they almost certainly should. That's another test idea:
+</p>
+<ul>
+ <li>
+ Files match in the two directories, but the case of the names is different.
+ </li>
+</ul>
+<p>
+ Notice that this test idea didn't come directly from the catalog. However, the catalog drew our attention to a
+ particular aspect of the program (file names as strings), and our creativity gave us an additional idea. It's important
+ not to use the catalog too narrowly-use it as a brainstorming technique, a way of inspiring new ideas.
+</p>
+<p>
+ The next entry is <b>Collections</b>. A directory is a collection of files. Many programs that handle collections fail
+ on the empty collection. A few that handle the empty collection, or collections with many elements, fail on collections
+ with exactly one element. So these ideas are useful:
+</p>
+<ul>
+ <li>
+ d1 is empty
+ </li>
+ <li>
+ d2 is empty
+ </li>
+ <li>
+ d1 has exactly one file
+ </li>
+ <li>
+ d2 has exactly one file
+ </li>
+</ul>
+<p>
+ The next idea is to use a collection of the maximum possible size. This is useful because programs like <font
+ size="+0">applyToCommonFiles</font> are often tested with trivial little directories. Then some user comes along and
+ applies them to two huge directory trees with thousands of files in them, only to discover that the program is
+ grotesquely memory inefficient and can't handle that realistic case.
+</p>
+<p>
+ Now, testing the absolute maximum size for a directory is not important; it only needs to be as large as a user might
+ try. However, at the very least, there should be <i>some</i> test with more than three files in a directory:
+</p>
+<ul>
+ <li>
+ d1 contains very many files
+ </li>
+ <li>
+ d2 contains very many files
+ </li>
+</ul>
+<p>
+ The final test idea (duplicate elements) doesn't apply to directories of files. That is, if you have a directory with
+ two files that have the same name, you have a problem independent of <font size="+0">applyToCommonFiles</font>-your
+ file system is corrupt.
+</p>
+<p>
+ The next catalog entry is <b>Searching</b>. Those ideas can be translated into <font
+ size="+0">applyToCommonFiles</font> terms like this:
+</p>
+<ul>
+ <li>
+ d1 and d2 have no files in common (all the names are different)
+ </li>
+ <li>
+ d1 and d2 have exactly one file in common (it's alphabetically the last element in the directory)
+ </li>
+ <li>
+ d1 and d2 have more than one file in common
+ </li>
+</ul>
+<p>
+ The final test idea checks whether <font size="+0">applyToCommonFiles</font> terminates too soon. Does it return as
+ soon as it finds the first match? The parenthetical remark in the test idea before that assumes that the program will
+ fetch the list of files in a directory using some library routine that returns them, sorted alphabetically. If not, it
+ might be better to find out what the last one really is (the most recently created?) and make that be the match. Before
+ you devote a lot of time to finding out how files are ordered, though, ask yourself how likely it is that putting the
+ matching element last will make finding defects easier. Putting an element last in a collection is more useful if the
+ code explicitly steps through the collection using an index. If it's using an iterator, it's extremely unlikely that
+ the order matters.
+</p>
+<p>
+ Let's look at one more entry in the sample catalog. The <b>Linked structures</b> entry reminds us that we're comparing
+ directory <i>trees</i>, not just flat collections of files. It would be sad if <font
+ size="+0">applyToCommonFiles</font> worked only in the top-level directories, but not in the lower-level ones. Deciding
+ how to test whether <font size="+0">applyToCommonFiles</font> works in lower-level directories forces us to confront
+ the incompleteness of its description.
+</p>
+<p>
+ First, when does <font size="+0">applyToCommonFiles</font> descend into subdirectories? If the directory structure
+ looks like this
+</p>
+<p align="center">
+ <img height="162" alt="" src="resources/tstidsctl-img1.gif" width="334" />
+</p>
+<p class="picturetext">
+ Figure 1: A directory structure
+</p>
+<p>
+ does <font size="+0">applyToCommonFiles</font> descend into <font size="+0">Cdir</font>? That doesn't seem to make
+ sense. There can be no match with anything in the other directory tree. In fact, it seems as if files in subdirectories
+ can only match if the subdirectory names match. That is, suppose we have this directory structure:
+</p>
+<p align="center">
+ <img height="165" alt="" src="resources/tstidsctl-img2.gif" width="334" />
+</p>
+<p class="picturetext">
+ Figure 2: A second directory structure
+</p>
+<p>
+ The files named "File" don't match because they're in different subdirectories The subdirectories should be descended
+ only if they have the same name in both <font size="+0">d1</font> and <font size="+0">d2</font>. That leads to these
+ test ideas:
+</p>
+<ul>
+ <li>
+ some subdirectory in d1 is not found in d2 (no descent)
+ </li>
+ <li>
+ some subdirectory in d2 is not found in d1 (no descent)
+ </li>
+ <li>
+ some subdirectory appears in both d1 and d2 (descend)
+ </li>
+</ul>
+<p>
+ But that raises other questions. Should the operation (<font size="+0">op</font>) be applied to matching subdirectories
+ or just to matching files? If it's applied to the subdirectories, should it be applied before the descent or afterward?
+ That makes a difference if, for example, the operation deletes the matching file or directory. For that matter,
+ <i>should</i> the operation be allowed to modify the directory structure? And more specifically: what's the correct
+ behavior of <font size="+0">applyToCommonFiles</font> if it does? (This is the same issue that comes up with
+ iterators.)
+</p>
+<p>
+ These sorts of questions typically arise when you carefully read a method's description of creating test ideas. But
+ let's leave them aside for now. Whatever the answers are, there will have to be test ideas for them-test ideas that
+ check whether the code correctly implements the answers.
+</p>
+<p>
+ Let's return to the catalog. We still haven't considered all of its test ideas. The first one-empty (nothing in
+ structure)-asks for an empty directory. We've already got that from the <b>Collections</b> entry. We've also got the
+ <b>minimal non-empty</b> structure, which is a directory with a single element. This sort of redundancy is not
+ uncommon, but it's easy to ignore.
+</p>
+<p>
+ What about <b>a circular structure</b>? Directory structures can't be circular-a directory can't be within one of its
+ descendants or within itself... or can it? What about shortcuts (on Windows) or symbolic links (on UNIX)? If there's a
+ shortcut in <font size="+0">d1</font>'s directory tree that points back to <font size="+0">d1</font>, should <font
+ size="+0">applyToCommonFiles</font> keep descending forever? The answer could lead to one or more new test ideas:
+</p>
+<ul>
+ <li>
+ d1 is circular because of shortcuts or symbolic links
+ </li>
+ <li>
+ d2 is circular because of shortcuts or symbolic links
+ </li>
+</ul>
+<p>
+ Depending on the correct behavior, there may be more test ideas than that.
+</p>
+<p>
+ Finally, what about <b>depth greater than one</b>? Earlier test ideas will ensure that we test descending into one
+ level of subdirectory, but we should check that <font size="+0">applyToCommonFiles</font> keeps descending:
+</p>
+<ul>
+ <li>
+ descends through several levels (&gt;1) of d1's subdirectories
+ </li>
+ <li>
+ descends through several levels (&gt;1) of d2's subdirectories
+ </li>
+</ul>
+<h3>
+ <a id="CreatingYourOwnCatalogs" name="CreatingYourOwnCatalogs">Creating and Maintaining Your Own Test-Ideas Catalog</a>
+</h3>
+<p>
+ As mentioned previously, the generic catalog won't contain all of the test ideas you need. But <a
+ href="./../../../glossary/glossary.htm#domain" target="_blank"><i>domain</i></a>-specific catalogs haven't been
+ published outside of the companies that created them. If you want them, you'll need to build them. Here's some advice.
+</p>
+<ul>
+ <li>
+ Do not fill a catalog with your speculations about what ideas would be good for finding faults. Remember that each
+ test idea you put in the catalog costs time and money:
+ <ul>
+ <li>
+ your time to maintain the catalog
+ </li>
+ <li>
+ other programmers' time to think about the test idea
+ </li>
+ <li>
+ possibly other programmers' time to implement a test
+ </li>
+ </ul>
+ <br />
+ Add only ideas that have a demonstrated track record. You should be able to point to at least one actual fault
+ that the test idea would have caught. Ideally, the fault should be one that was missed by other testing; that is,
+ one that was reported from the field. One good way to build catalogs is to browse through your company's bug
+ database and ask questions about how each fault could have been detected earlier.
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <br />
+ <br />
+ </li>
+ <li>
+ It's unlikely to work if creating and maintaining a Test-Ideas Catalog is something you do in your spare time.
+ You'll need time specifically allocated to this task, just like for any other important one. We recommend you
+ create and maintain your Test-Ideas Catalog during <a href="wfs_imptstast.htm">Workflow Detail: Improve Test
+ Assets</a>.
+ </li>
+</ul>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/test-ideas_list.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/test-ideas_list.xmi
new file mode 100644
index 0000000..ebda44f
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/test-ideas_list.xmi
@@ -0,0 +1,292 @@
+<?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" epf:version="1.0.0" xmi:id="-3i1jvKMUGGmAYPw4dHFbEg" name="test-ideas_list,8.834380241450745E-306" guid="-3i1jvKMUGGmAYPw4dHFbEg" changeDate="2006-12-01T15:44:08.749-0800" version="1.0.0">
+ <mainDescription><h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Information used in designing tests is gathered from many places: design models, classifier interfaces, statecharts,
+ and code itself. At some point, this source document information must be transformed into executable tests:
+</p>
+<ul>
+ <li>
+ specific inputs given to the software under test
+ </li>
+ <li>
+ in a particular hardware and software configuration
+ </li>
+ <li>
+ initialized to a known state
+ </li>
+ <li>
+ with specific results expected
+ </li>
+</ul>
+<p>
+ It's possible to go directly from source document information to executable tests, but it's often useful to add an
+ intermediate step. In this step, test ideas are written into a <i>Test-Ideas List</i>, which is used to create
+ executable tests.
+</p>
+<h3>
+ <a id="TestIdeas" name="TestIdeas">What are Test Ideas?</a>
+</h3>
+<p>
+ A test idea (sometimes referred to as a test requirement) is a brief statement about a test that could be performed. As
+ a simple example, let's consider a function that calculates a square root and come up with some test ideas:
+</p>
+<ul>
+ <li>
+ give a number that's barely less than zero as input
+ </li>
+ <li>
+ give zero as the input
+ </li>
+ <li>
+ test a number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
+ </li>
+</ul>
+<p>
+ Each of these ideas could readily be converted into an executable test with exact descriptions of inputs and expected
+ results.
+</p>
+<p>
+ There are two advantages to this less-specific intermediate form:
+</p>
+<ul>
+ <li>
+ test ideas are more reviewable and understandable than complete tests - it's easier to understand the reasoning
+ behind them
+ </li>
+ <li>
+ test ideas support more powerful tests, as described later under the heading <a href="#TestDesignUsingTheList">Test
+ Design Using the List</a>
+ </li>
+</ul>
+<p>
+ The square root examples all describe inputs, but test ideas can describe any of the elements of an executable test.
+ For example, "print to a LaserJet IIIp" describes an aspect of the test environment to be used for a test, as does
+ "test with database full", however, these latter test ideas are very incomplete in themselves: Print <b>what</b> to the
+ printer? Do <b>what</b> with that full database? They do, however, ensure that important ideas aren't forgotten; ideas
+ that will be described in more detail later in test design.
+</p>
+<p>
+ Test ideas are often based on fault&nbsp;models; notions of which faults are plausible in software and how those faults
+ can best be uncovered. For example, consider boundaries. It's safe to assume the square root function can be
+ implemented something like this:
+</p>
+<blockquote>
+<pre>
+ double sqrt(double x) { if (x &lt; 0) // signal error ...
+</pre>
+</blockquote>
+<p>
+ It's also plausible that the <font size="+0">&lt;</font> will be incorrectly typed as <font size="+0">&lt;=</font>.
+ People often make that kind of mistake, so it's worth checking. The fault cannot be detected with <font
+ size="+0">X</font> having the value <font size="+0">2</font>, because both the incorrect expression (<font
+ size="+0">x&lt;=0</font>) and the correct expression (<font size="+0">x&lt;0</font>) will take the same branch of the
+ <font size="+0">if</font> statement. Similarly, giving <font size="+0">X</font> the value -<font size="+0">5</font>
+ cannot find the fault. The only way to find it is to give <font size="+0">X</font> the value <font size="+0">0</font>,
+ which justifies the second test idea.
+</p>
+<p>
+ In this case, the fault model is explicit. In other cases, it's implicit. For example, whenever a program manipulates a
+ linked structure, it's good to test it against a circular one. It's possible that many faults could lead to a
+ mishandled circular structure. For the purposes of testing, they needn't be enumerated - it suffices to know that some
+ fault is likely enough that the test is worth running.
+</p>
+<p>
+ The following links provide information about getting test ideas from different kinds of fault models. The first two
+ are explicit fault models; the last uses implicit ones.
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
+ guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a>
+ </li>
+ <li>
+ <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_method_calls,8.5657170364036E-306.html"
+ guid="8.5657170364036E-306">Guideline: Test Ideas for Method Calls</a>
+ </li>
+ <li>
+ <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-ideas_catalog,1.2384224477983028E-305.html"
+ guid="1.2384224477983028E-305">Concept: Test-Ideas Catalog</a>
+ </li>
+</ul>
+<p>
+ These fault models can be applied to many different artifacts. For example, the first one describes what to do with
+ Boolean expressions. Such expressions can be found in code, in guard conditions, in statecharts and sequence diagrams,
+ and in natural-language descriptions of method behaviors (such as you might find in a published API).
+</p>
+<p>
+ Occasionally it's also helpful to have guidelines for specific artifacts. See <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
+ guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Flow Diagrams</a>.
+</p>
+<p>
+ A particular Test-Ideas List might contain test ideas from many fault models, and those fault models could be derived
+ from more than one artifact.
+</p>
+<h3>
+ <a id="TestDesignUsingTheList" name="TestDesignUsingTheList">Test Design Using the List</a>
+</h3>
+<p>
+ Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
+ obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is found.
+</p>
+<blockquote>
+<pre>
+ int Collection.find(String string, Boolean ignoreCase);
+</pre>
+</blockquote>
+<p>
+ Here are some test ideas for this method:
+</p>
+<ol>
+ <li>
+ match found in the first position
+ </li>
+ <li>
+ match found in the last position
+ </li>
+ <li>
+ no match found
+ </li>
+ <li>
+ two or more matches found in the collection
+ </li>
+ <li>
+ case is ignored; match found, but it wouldn't match if case was obeyed
+ </li>
+ <li>
+ case is obeyed; an exact match is found
+ </li>
+ <li>
+ case is obeyed; a string that would have matched if case were ignored is skipped
+ </li>
+</ol>
+<p>
+ It would be simple to implement these seven tests, one for each test idea. However, different test ideas can be
+ combined into a single test. For example, the following test <i>satisfies</i> test ideas 2, 6, and 7:
+</p>
+<blockquote>
+ <p>
+ Setup: collection initialized to ["dawn", "Dawn"]<br />
+ Invocation: collection.find("Dawn", false)<br />
+ Expected result: return value is 1 (it would be 0 if "dawn" were not skipped)
+ </p>
+</blockquote>
+<p>
+ Making test ideas nonspecific makes them easier to combine.
+</p>
+<p>
+ It's possible to satisfy all of the test ideas in three tests. Why would three tests that satisfy seven test ideas be
+ better than seven separate tests?
+</p>
+<ul>
+ <li>
+ When you're creating a large number of simple tests, it's common to create test N+1 by copying test N and tweaking
+ it just enough to satisfy the new test idea. The result, especially in more complex software, is that test N+1
+ probably exercises the program in almost the same way as test N. It takes almost exactly the same path through the
+ code.<br />
+ <br />
+ A smaller number of tests, each satisfying several test ideas, doesn't allow a "copy and tweak" approach. Each
+ test will be somewhat different from the last, exercising the code in different ways and taking different
+ paths.<br />
+ <br />
+ Why would that be better? If the Test-Ideas List were complete, with a test idea for every fault in the program,
+ it wouldn't matter how you wrote the tests. But the list is always missing some test ideas that could find bugs. By
+ having each test do very different things from the last one - by adding seemingly unneeded variety - you increase
+ the chance that one of the tests will stumble over a bug by sheer dumb luck. In effect, smaller, more complex tests
+ increase the chance the test will satisfy a test idea that you didn't know you needed.<br />
+ </li>
+ <li>
+ Sometimes when you're creating more complex tests, new test ideas come to mind. That happens less often with simple
+ tests, because so much of what you're doing is exactly like the last test, which dulls your mind.
+ </li>
+</ul>
+<p>
+ However, there are reasons for not creating complex tests.
+</p>
+<ul>
+ <li>
+ If each test satisfies a single test idea and the test for idea 2 fails, you immediately know the most likely
+ cause: the program doesn't handle a match in the last position. If a test satisfies ideas 2, 6, and 7, then
+ isolating the failure is harder.<br />
+ </li>
+ <li>
+ Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.<br />
+ </li>
+ <li>
+ Complex tests are more difficult to create. Constructing a test that satisfies five test ideas often takes more
+ time than constructing five tests that each satisfy one. Moreover, it's easier to make mistakes - to think you're
+ satisfying all five when you're only satisfying four.
+ </li>
+</ul>
+<p>
+ In practice, you must find a reasonable balance between complexity and simplicity. For example, the first tests you
+ subject the software to (typically the smoke tests) should be simple, easy to understand and maintain, and intended to
+ catch the most obvious problems. Later tests should be more complex, but not so complex they are not maintainable.
+</p>
+<p>
+ After you've finished a set of tests, it's good to check them against the characteristic test design mistakes discussed
+ in <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/developer_testing,4.085829182735815E-305.html#TestDesignMistakes"
+ guid="4.085829182735815E-305">Concept: Developer Testing</a>.
+</p>
+<h3>
+ <a id="UsingTestIdeasBeforeTest" name="UsingTestIdeasBeforeTest">Using Test Ideas Before Testing</a>
+</h3>
+<p>
+ A Test-Ideas List is useful for reviews and inspections of design artifacts. For example, consider this part of a
+ design model showing the association between Department and Employee classes.
+</p>
+<p align="center">
+ <img height="45" alt="" src="resources/tstidslst-img1.gif" width="223" />
+</p>
+<p class="picturetext">
+ Figure 1: Association between Department and Employee Classes
+</p>
+<p>
+ The rules for creating test ideas from such a model would ask you to consider the case where a department has many
+ employees. By walking through a design and asking "what if, at this point, the department has many employees?", you
+ might discover design or analysis errors. For example, you might realize that only one employee at a time can be
+ transferred between departments. That might be a problem if the corporation is prone to sweeping reorganizations where
+ many employees need to be transferred.
+</p>
+<p>
+ Such faults, cases where a possibility was overlooked, are called <i>faults of omission</i>. Just like the faults
+ themselves, you have probably omitted tests that detect these faults from your testing effort. For example, see <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html"
+ guid="6.191633934532389E-306">[GLA81]</a>, &nbsp;<a href="../../referenc.htm#OST84">[OST84]</a>, <a
+ href="../../referenc.htm#BAS87">[BAS87]</a>, <a href="../../referenc.htm#MAR00">[MAR00]</a>, and other studies that
+ show how often faults of omission escape into deployment.
+</p>
+<p>
+ The role of testing in design activities is discussed further in <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
+ guid="6.556259235358794E-306">Concept: Test-first Design</a>.
+</p>
+<h3>
+ <a id="TestIdeasTraceability" name="TestIdeasTraceability">Test Ideas and Traceability</a>
+</h3>
+<p>
+ Traceability is a matter of tradeoffs. Is its value worth the cost of maintaining it? This question needs to be
+ considered during <a href="../../activity/ac_tst_dfnasstrcnds.htm">Activity: Define Assessment and Traceability
+ Needs</a>.
+</p>
+<p>
+ When traceability is worthwhile, it's conventional to trace tests back to the artifacts that inspired them. For
+ example, you might have traceability between an API and its tests. If the API changes, you know which tests to change.
+ If the code (that implements the API) changes, you know which tests to run. If a test puzzles you, you can find the API
+ it's intended to test.
+</p>
+<p>
+ The Test-Ideas List adds another level of traceability. You can trace from a test to the test ideas it satisfies, and
+ then from the test ideas to the original artifact.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/test_driven_development.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/test_driven_development.xmi
new file mode 100644
index 0000000..f33515e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/test_driven_development.xmi
@@ -0,0 +1,100 @@
+<?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" epf:version="1.0.0" xmi:id="-yaD6WKGdrZ0n0yBSpwPr4g" name="test_driven_development,1.620567348185129E-306" guid="-yaD6WKGdrZ0n0yBSpwPr4g" changeDate="2006-11-21T15:06:48.997-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a
+id="XE_test_driven_development__practice_of" name="XE_test_driven_development__practice_of"></a><a
+id="XE_engineering_practices__test_driven_development" name="XE_engineering_practices__test_driven_development"></a>
+<h3>
+ Description
+</h3>
+<p>
+ Test-Driven Development is one of the core programming practices of XP. Many of us have learned over the years the
+ value of writing automated tests for our code. Many of us have also learned the difficulty of writing tests after code
+ is already in place. Test-Driven Development takes a different, extreme approach to ensure that we test all code, all
+ the time.
+</p>
+<p>
+ The practice of Test-Driven Development requires a change in how you program and in how you think. You won't write
+ tests as an afterthought. You won't be trying to see if the code you have written works. Instead, you will write tests
+ as part of the everyday, every minute way of building software. Instead of writing detailed design specifications on
+ paper, write the spec in code. Instead of first striving to perfectly design a system on paper, use tests to guide your
+ design. Instead of coding for hours at a stretch only to find that the planning went awry, use Test-Driven Development
+ to pace yourself, always assuring forward progress with the firm foundation of an ever-growing suite of running tests.
+</p>
+<p>
+ The steps:
+</p>
+<ul>
+ <li>
+ Have an idea where you are going.
+ </li>
+ <li>
+ Write a test that specifies a tiny bit of functionality.
+ </li>
+ <li>
+ Ensure that the test fails (you haven't built the functionality yet!).
+ </li>
+ <li>
+ Write only the code necessary to make the test pass.
+ </li>
+ <li>
+ Refactor the code, ensuring that it has the clear and simple design for the functionality built to date.
+ </li>
+ <li>
+ Repeat until you have the desired functionality.
+ </li>
+</ul>
+<p>
+ The rules:
+</p>
+<ul>
+ <li>
+ Test everything that can possibly break.
+ </li>
+ <li>
+ Tests come first.
+ </li>
+ <li>
+ All tests run at 100% all the time.
+ </li>
+</ul>
+<p>
+ Test-Driven Development is infectious! Developers swear by it. Developers do not seem to abandon it after giving it an
+ honest trial.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ Testable modules are decoupled from other complex classes, resulting in <b>loosely coupled modules</b>. Loosely
+ coupled modules are a sign of good design.
+ </li>
+ <li>
+ Code is written so that <b>modules are testable in isolation</b>. Code written without tests in mind is often
+ highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll
+ devise ways of minimizing dependencies in your system in order to write your tests.
+ </li>
+ <li>
+ The <b>tests act as documentation,</b> providing concrete examples of how to use the module being tested.
+ </li>
+ <li>
+ The tests are the first client of your classes; they <b>show how the developer intended the class to be used</b>.
+ </li>
+ <li>
+ The <b>tests act as a safety net</b>. Notifying the programmer immediately when a side-effect defect is introduced
+ into the system.
+ </li>
+ <li>
+ <b>Development is paced</b>. You can stop at anytime with the tests describing the progress so far. Each
+ programming session gives a sense of satisfaction with getting some of the code working.
+ </li>
+</ul>
+<h3>
+ Related Information
+</h3>
+<p>
+ For more information, see <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html"
+ guid="3.9254165491375454E-306">Test Driven Development Guidelines</a>.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/what_is_xp.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/what_is_xp.xmi
new file mode 100644
index 0000000..9147ccc
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/what_is_xp.xmi
@@ -0,0 +1,49 @@
+<?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" epf:version="1.0.0" xmi:id="-nO38_JQ9G3FQvNlAT5Agqg" name="what_is_xp,9.251272550276345E-306" guid="-nO38_JQ9G3FQvNlAT5Agqg" changeDate="2006-11-08T15:33:57.947-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__what_is_it" name="XE_xp__what_is_it"></a><a id="XE_what_is__xp" name="XE_what_is__xp"></a>
+<p>
+ Kent Beck, author of <i>Extreme Programming Explained</i> [<a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#BEC00"
+ guid="6.191633934532389E-306">BEC00</a>], says, "XP is a light-weight methodology for small-to-medium-sized teams
+ developing software in the face of vague or rapidly changing requirements." Simply stated, XP is a set of <a
+ class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html"
+ guid="1.076140803519123E-306">values</a>, <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html" guid="3.036332011267074E-306">rights,</a>
+ and best <a class="elementLinkWithUserText"
+ href="./../../../xp/customcategories/xp_best_practices,4.315031901943112E-306.html"
+ guid="4.315031901943112E-306">practices</a> that support each other in incrementally developing software.
+</p>
+<p>
+ When a team is developing software with XP, the customer creates stories that describe the functionality of the
+ software. These stories are very lightweight use-cases. They are small units of functionality that require less than
+ one or two weeks to implement. Programmers estimate the stories, and, based upon those estimates, the customer decides
+ which stories to do first.
+</p>
+<p>
+ Development is done iteratively and incrementally. Every two weeks, the programming team delivers working stories to
+ the customer. Then the customer chooses another two weeks worth of work. The system grows in functionality, piece by
+ piece, steered by the customer. Progress is measured and tracked based on the observable behavior of the team.
+</p>
+<p>
+ XP relies on evolutionary design and testing techniques that maintain a high quality design while new functionality is
+ being added. These techniques avoid the mess of unmaintainable code through continuous review, an emphasis on
+ simplicity, and the backstop of nearly universal test coverage.
+</p>
+<p>
+ Programmers work on their programming tasks in pairs. The pair share a single workstation and work together to write a
+ single piece of code. Both partners are equally engaged in the writing. The keyboard moves back and forth between them
+ frequently.
+</p>
+<p>
+ XP programmers practice Test-Driven Development. In short, they write unit tests prior to writing production code.
+ However, this is done in very tiny increments. Tiny portions of a test are written first, and then just enough
+ production code is written to make those portions pass. This continues iteratively until everything that can be
+ practically tested has been tested.
+</p>
+<p>
+ XP focuses on continuous delivery of tested, running software from the first day of the project to the last. Delivery
+ of real software, combined with simple but frequent planning, provides stakeholders with a clear view of what is done
+ and what will be done. This enables the business to steer the project to an on-time shipment of the best possible
+ software that can be completed in the time available.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/whole_team.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/whole_team.xmi
new file mode 100644
index 0000000..31b9037
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/whole_team.xmi
@@ -0,0 +1,102 @@
+<?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" epf:version="1.0.0" xmi:id="-uqrgrFY-74R1FijPLvcXoQ" name="whole_team,7.89591827591278E-306" guid="-uqrgrFY-74R1FijPLvcXoQ" changeDate="2006-11-08T15:36:31.999-0800" version="1.0.0">
+ <mainDescription><h3>
+ Description
+</h3>
+<p>
+ All the contributors to an XP project sit together, members of a whole team. The team shares the project goals and the
+ responsibility for achieving them. This team must include a business representative, the "Customer" who provides the
+ requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end
+ user who knows the domain and what is needed. The team will of course have programmers. The team may include testers,
+ who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to
+ define the requirements. There is commonly a coach, who helps the team keep on track and facilitates the process. There
+ may be a manager, providing resources, handling external communication and coordinating activities. None of these roles
+ is necessarily the exclusive property of just one individual. Everybody on an XP team contributes in any way that they
+ can. The best teams have no specialists, only general contributors with special skills.
+</p>
+<p>
+ Subservient in organization to the Whole Team are the teams that focus on the business decisions (<a
+ class="elementLink" href="./../../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>), the technical decisions (<a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>), and the organization that supports those teams (<a
+ class="elementLink" href="./../../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
+ guid="5.613949040902463E-308">XP Organization</a>). To create a context for clear communication, XP provides a set of
+ guidelines defining the rights of the customer and developer. These guidelines are referred to as the <a
+ class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html"
+ guid="3.036332011267074E-306">customer and a developer bill of rights</a>.
+</p>
+<div align="left">
+ <table width="75%" border="1">
+ <tbody>
+ <tr>
+ <th width="30%">
+ <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>
+ </th>
+ <th width="34%">
+ <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>
+ </th>
+ <th width="36%">
+ <a class="elementLink"
+ href="./../../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
+ guid="5.613949040902463E-308">XP Organization</a>
+ </th>
+ </tr>
+ <tr>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}.html"
+ guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">Customer</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}.html"
+ guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}">Programmer</a>
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
+ guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">Tracker</a>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}.html"
+ guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">Tester</a>
+ </td>
+ <td align="middle">
+ &nbsp;
+ </td>
+ <td align="middle">
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">Coach</a>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Progress visibility</b>: customer gets real feedback on a daily basis.
+ </li>
+ <li>
+ <b>Agility</b>: customer can steer team on a daily basis.
+ </li>
+ <li>
+ <b>Reduces miscommunication</b>: contact is direct and face to face, single point of contact.
+ </li>
+ <li>
+ <b>Speeds up communication</b>: customer is always available to answer questions.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_practices.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_practices.xmi
new file mode 100644
index 0000000..9f35b80
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_practices.xmi
@@ -0,0 +1,98 @@
+<?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" epf:version="1.0.0" xmi:id="-24MPC2FhJbx7Fr0F6QEq8A" name="xp_practices,2.2937799026801584E-305" guid="-24MPC2FhJbx7Fr0F6QEq8A" changeDate="2006-11-08T15:39:14.245-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__practices_of" name="XE_xp__practices_of"></a><a id="XE_practices_in__xp" name="XE_practices_in__xp"></a>
+<p>
+ XP is a collection of guiding values and best practices. Most of these practices have been used in the industry in some
+ shape or form for a number of years. XP has simply identified them and tried to push the envelope of these practices in
+ order to get the most benefit from them. Taken individually, these practices are all fairly simple. But it is the sum
+ of all of them that provides the most benefit as they reinforce each other to address the most difficult problems teams
+ encounter when developing software.
+</p>
+<br />
+<br />
+<p>
+ <img height="540" alt="" src="./../../../xp/resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map"
+ border="0" /> <map id="xp_practices_image_map" name="xp_practices_image_map">
+ <area shape="RECT" coords="298,19,390,88"
+ href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
+ <area shape="RECT" coords="176,135,282,200"
+ href="./../../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
+ <area shape="RECT" coords="297,168,434,231"
+ href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
+ <area shape="RECT" coords="447,135,547,198"
+ href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
+ <area shape="RECT" coords="15,236,122,305"
+ href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
+ <area shape="RECT" coords="218,238,362,307"
+ href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
+ <area shape="RECT" coords="392,241,512,305"
+ href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
+ <area shape="RECT" coords="614,236,714,302"
+ href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
+ <area shape="RECT" coords="143,325,270,393"
+ href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
+ <area shape="RECT" coords="310,321,412,379"
+ href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
+ <area shape="RECT" coords="468,323,597,393"
+ href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
+ <area shape="RECT" coords="307,386,413,436"
+ href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
+ <area shape="RECT" coords="312,475,419,539"
+ href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
+ <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
+ </map>
+</p>
+<p>
+ This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
+ exemplifies the steering and control cycles of the process.
+</p>
+<p>
+ The outer red circle is called the "Circle of Life". It's what keeps an XP project going, producing tested working
+ software. The <a class="elementLink" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a>, customer members and development members, work together - preferably
+ physically together - to build the project. Using the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html"
+ guid="2.7371805612676613E-305">Planning Game</a> elements of Release Planning and Iteration Planning, they plan a
+ series of <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" guid="5.762953011420275E-306">Small
+ Releases</a> of software that demonstrably pass all the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html"
+ guid="2.297945473205673E-305">Customer Tests</a>.
+</p>
+<p>
+ The innermost blue circle describes the day to day, moment to moment, work of the XP developers. Each feature is
+ addressed with <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html"
+ guid="1.6109092258980447E-306">Simple Design</a>, ensuring that the design of the system is just right for the features
+ supported. The programmers work in <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html"
+ guid="3.876855509996079E-307">pairs</a> for all production code development, providing continuous code review and
+ valuable, team-wide understanding of the system. They build the software using <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
+ guid="1.620567348185129E-306">Test-Driven Development,</a> a technique that produces well-crafted and well-tested
+ software with a minimum of wasted effort, and the design is kept clean by the continuous improvement process of <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
+ guid="1.4410217108363206E-306">Refactoring</a>.
+</p>
+<p>
+ The middle green circle contains the important supporting practices of XP. The software is designed according to a
+ common, shared, evolving <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html"
+ guid="4.884861766532753E-306">Metaphor</a> that helps it all hang together. It is kept <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html"
+ guid="3.193414568279561E-305">continuously integrated</a> with many system builds every day, each one fully tested. The
+ team shares ownership of of all the code so that needed changes can be made by any qualified pair, not just by one
+ individual. Since everyone works on everything, the team evolves a <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" guid="8.8116853923311E-307">standard
+ way of coding</a>. Finally, XP teams work at a <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html"
+ guid="3.133529870649493E-306">sustainable pace</a> that enables them to deliver tested software on a predictable basis
+ from the first day of the project until the last.
+</p>
+<p>
+ <br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_rights.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_rights.xmi
new file mode 100644
index 0000000..fc81ae3
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_rights.xmi
@@ -0,0 +1,48 @@
+<?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" epf:version="1.0.0" xmi:id="-vEvfeoyYAPDr-jfyX2QLww" name="xp_rights,3.036332011267074E-306" guid="-vEvfeoyYAPDr-jfyX2QLww" changeDate="2006-11-08T15:44:06.238-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__bill_of_rights" name="XE_xp__bill_of_rights"></a><a id="XE_bill_of_rights__in_xp"
+name="XE_bill_of_rights__in_xp"></a>
+<h2>
+ Developer Bill of Rights
+</h2>
+<ul>
+ <li>
+ You have the right to know what is needed with clear declarations of priority.
+ </li>
+ <li>
+ You have the right to produce quality work at all times.
+ </li>
+ <li>
+ You have the right to ask for and receive help from peers, superiors, and customers.
+ </li>
+ <li>
+ You have the right to make and update your own estimates.
+ </li>
+ <li>
+ You have the right to accept responsibilities instead of having them assigned to you.
+ </li>
+</ul>
+<h2>
+ Customer Bill of Rights
+</h2>
+<ul>
+ <li>
+ You have the right to an overall plan, to know what can be accomplished when and at what cost.
+ </li>
+ <li>
+ You have the right to get the greatest possible value out of every programming week.
+ </li>
+ <li>
+ You have the right to see progress in a running system proven to work by passing repeatable tests that you specify.
+ </li>
+ <li>
+ You have the right to change your mind, to substitute functionality, and to change priorities without paying
+ exorbitant costs.
+ </li>
+ <li>
+ You have the right to be informed of schedule changes in time to choose how to reduce the scope to restore the
+ original date. You can cancel the project at any time and be left with a useful working system reflecting the
+ investment to date.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_sustainable_pace.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_sustainable_pace.xmi
new file mode 100644
index 0000000..d782e29
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_sustainable_pace.xmi
@@ -0,0 +1,44 @@
+<?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" epf:version="1.0.0" xmi:id="-DoLoZOTPa_LacQ3jUG_lsg" name="xp_sustainable_pace,3.133529870649493E-306" guid="-DoLoZOTPa_LacQ3jUG_lsg" changeDate="2006-11-09T15:07:23.389-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__sustainable_pace" name="XE_xp__sustainable_pace"></a><a id="XE_sustainable_pace__practice_of"
+name="XE_sustainable_pace__practice_of"></a><a id="XE_engineering_practices__sustainable_pace"
+name="XE_engineering_practices__sustainable_pace"></a>
+<h3>
+ Description
+</h3>
+<p>
+ The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
+ marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
+ overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
+ impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
+ causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
+ down.
+</p>
+<p>
+ Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
+ to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
+ it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
+ iteration or a release, but it should always be an exception rather than the rule.
+</p>
+<p>
+ Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Improved predictability</b>: plans become more accurate.
+ </li>
+ <li>
+ <b>Improved product quality</b>: programmers have the time to do the right thing.
+ </li>
+ <li>
+ <b>Improved job satisfaction</b>: programmers can enjoy their work with as little stress as possible.
+ </li>
+ <li>
+ <b>Reduced time to market</b>: less time required to fix bad code and rotting design.<br />
+ <br />
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_values.xmi b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_values.xmi
new file mode 100644
index 0000000..e5cb99e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/concepts/xp_values.xmi
@@ -0,0 +1,173 @@
+<?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" epf:version="1.0.0" xmi:id="-pA6XLJKgRiwDTEp_qMlQ9g" name="xp_values,1.076140803519123E-306" guid="-pA6XLJKgRiwDTEp_qMlQ9g" changeDate="2005-12-06T02:48:47.737-0800">
+ <mainDescription><a id="XE_xp__core_values" name="XE_xp__core_values"></a>
+<h2>
+ <a id="Communication" name="Communication">Communication</a>
+</h2>
+<p>
+ XP emphasizes face-to-face communication over other types of communication, such as documents. XP values documents but
+ values personal communication even more. In order to facilitate communication, XP teams:
+</p>
+<ul>
+ <li>
+ Use a common system metaphor or vocabulary.
+ </li>
+ <li>
+ Work closely with one another in an open workspace.
+ </li>
+ <li>
+ Continuously integrate the code.
+ </li>
+ <li>
+ Work closely with the business people, preferably having them in the same room.
+ </li>
+ <li>
+ Program in pairs.
+ </li>
+ <li>
+ Collectively own the code.
+ </li>
+ <li>
+ Frequently plan and report status to the customer.
+ </li>
+</ul>
+<h2>
+ <a id="Simplicity" name="Simplicity">Simplicity</a>
+</h2>
+<p>
+ XP presumes that it is better to do the simple thing today and pay a little more tomorrow if more is really needed than
+ to do a more complicated thing today that may never be used. This is a fundamental philosophy that permeates everything
+ in an XP project. If something isn't needed today, we don't do it today.
+</p>
+<p>
+ For example:
+</p>
+<ul>
+ <li>
+ We will write no document unless there is an immediate and significant need.
+ </li>
+ <li>
+ We will adopt no tool unless there is a tangible and verifiable benefit.
+ </li>
+ <li>
+ We will avoid writing infrastructure until it is needed by existing code.
+ </li>
+</ul>
+<p>
+ In order to maintain the simplicity of their software and their team structure, XP teams:
+</p>
+<ul>
+ <li>
+ Ask themselves: What is the simplest thing that can possibly work?
+ </li>
+ <li>
+ Continuously simplify and improve the design through refactoring.
+ </li>
+</ul>
+<p>
+ Some time ago, Kent Beck offered the following rules for simple design. In priority order, the code must:
+</p>
+<ol>
+ <li>
+ Run all the tests.
+ </li>
+ <li>
+ Contain no duplicate code.
+ </li>
+ <li>
+ Express all the ideas the author wants to express.
+ </li>
+ <li>
+ Minimize classes and methods.
+ </li>
+</ol>
+<h2>
+ <a id="Feedback" name="Feedback">Feedback</a>
+</h2>
+<p>
+ Feedback works at different scales in XP.
+</p>
+<p>
+ At the highest level, the customer can see the progress of the team through the working software delivered every two
+ weeks. This continuous feedback allows the customer to steer the project to success. We get concrete feedback on the
+ state of the system in the form of executable pieces of functionality that pass repeatable, automated acceptance tests.
+ These tests prevent the system from backsliding. No new release of the system can fail acceptance tests that used to
+ work.
+</p>
+<p>
+ At the programming level, programmers write unit tests for all the logic in the system to get immediate and concrete
+ feedback telling them if the code they just wrote is doing what they expected.
+</p>
+<p>
+ XP teams:
+</p>
+<ul>
+ <li>
+ Develop in small releases.
+ </li>
+ <li>
+ Develop in smaller iterations.
+ </li>
+ <li>
+ Break features and requirements into stories that fit in an iteration.
+ </li>
+ <li>
+ Break stories into even smaller tasks.
+ </li>
+ <li>
+ Write small unit tests to ensure that tasks work properly.
+ </li>
+ <li>
+ Write acceptance tests to ensure that stories work properly.
+ </li>
+ <li>
+ Track progress and communicate it to the customer frequently.
+ </li>
+</ul>
+<h2>
+ <a id="Courage" name="Courage">Courage</a>
+</h2>
+<p>
+ Perhaps a better name for this value is trust. In order to function, the members of an XP team have to have the courage
+ to trust each other, trust their customer, trust their practices, and trust themselves.
+</p>
+<p>
+ XP team members trust that they can:
+</p>
+<ul>
+ <li>
+ Stop when they are tired.
+ </li>
+ <li>
+ Let every business decision be made by the customer.
+ </li>
+ <li>
+ Ask customers to reduce the scope of a release.
+ </li>
+ <li>
+ Ask their peers or customers for help.
+ </li>
+ <li>
+ Design and implement only what is needed for today and add tomorrow what will be needed tomorrow.
+ </li>
+ <li>
+ Make changes that improve the functions or structure of the code.
+ </li>
+ <li>
+ Fix the design and retrofit existing code when the design is shown to be inadequate.
+ </li>
+ <li>
+ Throw away code.
+ </li>
+ <li>
+ Change code they did not write.
+ </li>
+ <li>
+ Change the process when it is not working.
+ </li>
+</ul>
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/examples/test-ideas_catalog_examples.xmi b/XP/XP_baseline_EN/library/xp/guidances/examples/test-ideas_catalog_examples.xmi
new file mode 100644
index 0000000..2c3a002
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/examples/test-ideas_catalog_examples.xmi
@@ -0,0 +1,6 @@
+<?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" epf:version="1.0.0" xmi:id="-HkQclhewSbkFSomo1l_LBg" name="test-ideas_catalog_examples,6.216049252606417E-306" guid="-HkQclhewSbkFSomo1l_LBg" changeDate="2005-12-06T02:48:05.726-0800">
+ <mainDescription><a id="XE_test_idea__example_catalogs_of" name="XE_test_idea__example_catalogs_of"></a><a
+id="XE_test_ideas_catalog__examples_of" name="XE_test_ideas_catalog__examples_of"></a>HTML:&nbsp;<a
+href="resources/tstidactl.htm" target="_blank">tstidactl.htm</a></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/equivalence_class_analysis.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/equivalence_class_analysis.xmi
new file mode 100644
index 0000000..85b2197
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/equivalence_class_analysis.xmi
@@ -0,0 +1,301 @@
+<?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" epf:version="1.0.0" xmi:id="-c7t_eJuo1g5hpWTYTCItig" name="equivalence_class_analysis,1.8491691792142673E-308" guid="-c7t_eJuo1g5hpWTYTCItig">
+ <mainDescription><a id="XE_runtime_observation_&amp;_analysis__concept" name="XE_runtime_observation_&amp;_analysis__concept"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Except for the most trivial of software applications, it is generally considered impossible to test all the input
+ combinations logically feasible for a software system. Therefore, selecting a good subset that has the highest
+ probability of finding the most errors, is a worthwhile and important task for testers to undertake.
+</p>
+<p>
+ Testing based on equivalence class analysis (synonyms: <i>equivalence partitioning</i>, <i>domain analysis</i>) is a
+ form of black-box test analysis that attempts to reduce the total number of potential tests to a minimal set of tests
+ that will uncover as many errors as possible [<a href="../../process/referenc.htm#MYE79">MYE79</a>]. It is a method
+ that partitions the set of inputs and outputs into a finite number of <i><a
+ href="./../../../glossary/glossary.htm#equivalence_class">equivalence classes</a></i> that enable the selection of a
+ representative test value for each class. The test that results from the representative value for a class is said to be
+ "equivalent" to the other values in the same class. If no errors were found in the test of the representative value, it
+ is reasoned that all the other "equivalent" values wouldn't identify any errors either.
+</p>
+<p>
+ The power of Equivalence Classes lies in their ability to guide the tester using a sampling strategy to reduce the
+ combinatorial explosion of potentially necessary tests. The technique provides a logical bases by which a subset of the
+ total conceivable number of tests can be selected. Here are some categories of problem areas for large numbers of tests
+ that can be benefit from the consideration of equivalence classes:
+</p>
+<ol>
+ <li>
+ Combinations of independent variables
+ </li>
+ <li>
+ Dependent variables based on hierarchical relationship
+ </li>
+ <li>
+ Dependent variables based on temporal relationship
+ </li>
+ <li>
+ Clustered relationships based on market exemplars
+ </li>
+ <li>
+ Complex relationships that can be modeled
+ </li>
+</ol>
+<h3>
+ <a id="Strategies" name="Strategies">Strategies</a>
+</h3>
+<p>
+ There are different strategies and techniques that can be used in equivalence partition testing. Here are some
+ examples:
+</p>
+<h4>
+ <a id="EquivalenceClassPartition" name="EquivalenceClassPartition">Equivalence Class Partition</a>
+</h4>
+<p>
+ Equivalence partition theory as proposed by Glenford Myers [<a href="../../process/referenc.htm#MYE79">MYE79</a>].
+ attempts to reduce the total number of test cases necessary by partitioning the input conditions into a finite number
+ of equivalence classes. Two types of equivalence classes are classified: the set of valid inputs to the program is
+ regarded as the <i>valid equivalence class</i>, and all other inputs are included in the <i>invalid equivalence
+ class</i>.
+</p>
+<p>
+ Here are a set of guidelines to identify equivalence classes:
+</p>
+<ol>
+ <li>
+ If an input condition specifies a range of values (such as, program "accepts values from 10 to 100"), then one
+ valid equivalence class (from 10 to 100) and two invalid equivalence classes are identified (less than 10 and
+ greater than 100).
+ </li>
+ <li>
+ If an input condition specifies a set of values (such as, "cloth can be many colors: RED, WHITE, BLACK, GREEN,
+ BROWN "), then one valid equivalence class (the valid values) and one invalid equivalence class (all the other
+ invalid values) are identified. Each value of the valid equivalence class should be handled distinctly.
+ </li>
+ <li>
+ If the input condition is specified as a "must be" situation (such as, "the input string must be upper case"), then
+ one valid equivalence class (uppercase characters) and one invalid equivalence (all the other input except
+ uppercase characters) class are identified.
+ </li>
+ <li>
+ Everything finished "long" before the task is done is an equivalence class. Everything done within some short time
+ interval before the program is finished is another class. Everything done just before program starts another
+ operation is another class.
+ </li>
+ <li>
+ If a program is specified to work with memory size from 64M to 256M. Then this size range is an equivalence class.
+ Any other memory size, which is greater than 256M or less than 64M, can be accepted.
+ </li>
+ <li>
+ The partition of output event lies in the inputs of the program. Even though different input equivalence classes
+ could have same type of output event, you should still treat the input equivalence classes distinctly.
+ </li>
+</ol>
+<h4>
+ <a id="BoundaryValueAnalysis" name="BoundaryValueAnalysis">Boundary Value Analysis</a>
+</h4>
+<p>
+ In each of the equivalence classes, the boundary conditions are considered to have a higher rate of success identifying
+ resulting failures than non-boundary conditions. Boundary conditions are the values at, immediately above or below the
+ boundary or "edges" of each equivalence classes.
+</p>
+<p>
+ Tests that result from boundary conditions make use of values at the minimum (min), just above minimum (min+), just
+ below the maximum (max-), and the maximum (max) of the range that needs be tested. When testing boundary values,
+ testers choose a few test cases for each equivalence class. For the relatively small sample of tests the likelihood of
+ failure discovery is high. The Tester is given some relief from the burden of testing a huge population of cases in an
+ equivalent class of values that are unlikely to produce large differences in testing results.
+</p>
+<p>
+ Some recommendations when choosing boundary values:
+</p>
+<ol>
+ <li>
+ For a floating variable, if the valid condition of it is from <code>-1.0</code> to <code>1.0</code>, test
+ <code>-1.0</code>, <code>1.0</code>, <code>-1.001</code> and <code>1.001</code>.
+ </li>
+ <li>
+ For an integer, if the valid range of input is <code>10</code> to <code>100</code>, test <code>9</code>,
+ <code>10</code>, <code>100</code>, <code>101</code>.
+ </li>
+ <li>
+ If a program expects an uppercase letter, test the boundary A and Z. Test <code>@</code> and <code>[</code> too,
+ because in ASCII code, <code>@</code> is just below A and <code>[</code> is just beyond the Z.
+ </li>
+ <li>
+ If the input or output of a program is an ordered set, pay attention on the first and the last element of the set.
+ </li>
+ <li>
+ If the sum of the inputs must be a specific number (<code>n</code>), test the program where the sum is
+ <code>n-1</code>, <code>n</code>, or <code>n+1</code>.
+ </li>
+ <li>
+ If the program accepts a list, test values in the list. All the other values are invalid.
+ </li>
+ <li>
+ When reading from or writing to a file, check the first and last characters in the file.
+ </li>
+ <li>
+ The smallest denomination of money is one cent or equivalent. If the program accepts a specific range, from a to b,
+ test a <code>-0.01</code> and b <code>+0.01</code>.
+ </li>
+ <li>
+ For a variable with multiple ranges, each range is an equivalence class. If the sub-ranges are not overlapped, test
+ the values on the boundaries, beyond the upper boundary, and below the lower boundary.
+ </li>
+</ol>
+<h4>
+ <a id="SpecialValues" name="SpecialValues">Special Values</a>
+</h4>
+<p>
+ After attempting the two previous boundary analysis strategies, an experienced tester will observe the program inputs
+ to discovery any "special value" cases, which are again potentially rich sources for uncovering software failures. Here
+ are some examples:
+</p>
+<ol>
+ <li>
+ For an integer type, zero should always be tested if it is in the valid equivalence class.
+ </li>
+ <li>
+ When testing time (hour, minute and second), 59 and 0 should always be tested as the upper and lower bound for each
+ field, no matter what constraint the input variable has. Thus, except the boundary values of the input, -1, 0, 59
+ and 60 should always be test cases.
+ </li>
+ <li>
+ When testing date (year, month and day), several test cases, such as number of days in a specific month, the number
+ of days in February in leap year, the number of days in the non-leap year, should be involved.
+ </li>
+</ol>
+<h4>
+ <a id="CategoryPartition" name="CategoryPartition">"Category-Partition" Method</a>
+</h4>
+<p>
+ <a href="#OstrandBalcer">Ostrand and Balcer</a> [16] developed a partition method that helps testers to analyze the
+ system specification, write test scripts, and manage them. Different from common strategies that mostly focuses on the
+ code, their method is based on the specification and design information too.
+</p>
+<p>
+ The main benefit of this method is its ability to expose errors before the code has been written because the input
+ source is the specification and the tests result from the analysis of that specification. Faults in the specifications
+ will be discovered early, often well before they are implemented in code.
+</p>
+<p>
+ The strategy for the "category-partition" method follows:
+</p>
+<ol>
+ <li>
+ Analyze the specification: decompose the system functionality into functional units, which can be tested
+ independently both by specification and implementation.<br />
+ From there;<br />
+ <br />
+
+ <ol>
+ <li>
+ Identify the parameters and the environment conditions that will influence the function's execution.
+ Parameters are the inputs of the function unit. Environment conditions are the system states, which will
+ effect the execution of the function unit.
+ </li>
+ <li>
+ Identify the characteristics of the parameters and the environment conditions.
+ </li>
+ <li>
+ Classify the characteristics into categories, which effect the behavior of the system.<br />
+ <br />
+ </li>
+ </ol>
+ Ambiguous, contradictory, and missing descriptions of behavior will be discovered in this stage.<br />
+ <br />
+ </li>
+ <li>
+ Partition the categories into choices: Choices are the different possible situations that might occur and not be
+ expected. They represent the same type of information in a category.<br />
+ <br />
+ </li>
+ <li>
+ Determine the relations and the constraints among choices. The choices in different categories influence with each
+ other, which also have an influence of building the test suite. Constraints are added to eliminate the
+ contradiction of between choices of different parameters and environments.<br />
+ <br />
+ </li>
+ <li>
+ Design test cases according to the categories, choices and constraint information. If a choice causes an error,
+ don't combine it with other choices to create the test case. If a choice can be "adequately" tested by one single
+ test, it is either the representative of the choice or a special value.
+ </li>
+</ol>
+<h3>
+ <a id="FurtherReading" name="FurtherReading">Further Reading and References</a>
+</h3>
+<ol>
+ <li>
+ Glenford J. Myers, The Art of Software Testing, John Wiley &amp; Sons, Inc., New York, 1979.
+ </li>
+ <li>
+ White L. J. and Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software
+ Engineering, Vol. SE-6, No. 3, 1980.
+ </li>
+ <li>
+ Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on
+ Software Engineering, 8-4, 1992.
+ </li>
+ <li>
+ Steven J. Zeil, Faten H. Afifi and Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction
+ on Software Engineering and Methodology, 1-4, 1992.
+ </li>
+ <li>
+ BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering
+ and Methodology, 3-3, 1994.
+ </li>
+ <li>
+ Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
+ </li>
+ <li>
+ Martin R. Woodward and Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal
+ triangle, ACM Press New York, NY, 2000.
+ </li>
+ <li>
+ Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software
+ Engineering, 71-16, 2000.
+ </li>
+ <li>
+ Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley &amp; Sons, Inc., New
+ York, 2002.
+ </li>
+ <li>
+ Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special
+ Interest Group on Software Engineering, 18-5, 1993.
+ </li>
+ <li>
+ Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM
+ Special Interest Group on Software Engineering, 1981.
+ </li>
+ <li>
+ Lori A. Clarke, Johnette Hassell, and Debra J Richardson, A system to generate test data and symbolically execute
+ programs, IEEE Transaction on Software Engineering, SE-2, 1976.
+ </li>
+ <li>
+ Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley &amp; Sons,
+ Inc., 1995.
+ </li>
+ <li>
+ Steven J. Zeil, Faten H. Afifi and Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM
+ Transaction on Software Engineering and Methodology, 1-4, 1992.
+ </li>
+ <li>
+ William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
+ </li>
+ <li>
+ <a id="OstrandBalcer" name="OstrandBalcer">Thomas J. Ostrand and Marc J. Balcer</a>, The Category-Partition method
+ for specifying and generating functional tests, Communications of ACM 31, 1988.
+ </li>
+ <li>
+ Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley &amp; Sons, Inc., 1999.
+ </li>
+</ol>
+<p>
+ &nbsp;
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/open_workspace.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/open_workspace.xmi
new file mode 100644
index 0000000..a5a5328
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/open_workspace.xmi
@@ -0,0 +1,35 @@
+<?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" epf:version="1.0.0" xmi:id="-mq7aEjHjqWoRd6aWFK_Dwg" name="open_workspace,3.269440809144354E-305" guid="-mq7aEjHjqWoRd6aWFK_Dwg" changeDate="2005-12-06T04:26:31.188-0800">
+ <mainDescription><a id="XE_xp__open_workspace" name="XE_xp__open_workspace"></a><a id="XE_workspace__in_xp" name="XE_workspace__in_xp"></a>
+<p>
+ XP's open workspace borrows from the concept of the war room. Studies have shown that teams working tightly together in
+ close proximity achieve much greater productivity than when they are apart in their own separate offices or cubicles.
+ In XP, all members of the team, including the customer, sit in the open workspace.
+</p>
+<p>
+ The ideal XP programming environment is an open workspace filled with tables and room for pairs of people to work
+ together and maintain contact with their peers.
+</p>
+<p>
+ The open workspace should foster an environment in which programmers can focus on their problems but still hear enough
+ to jump in other conversations if they can help. It is an environment that emphasizes teamwork.
+</p>
+<p>
+ In many places in the world, businesses have "cubicle cultures." In the interests of privacy and enhanced
+ concentration, programmers often spend most of their time in their own workspace that is separated from their peers. It
+ acts as a little capsule of solitude that lets them work in "peace." While everyone needs quiet time and some privacy,
+ the bulk of software development work is best done collaboratively.
+</p>
+<p>
+ When people go into their small workspaces, they are out of the flow and exchange of information that keeps a project
+ vigorous.
+</p>
+<p>
+ In XP, team members should have some private space. They need a place where they can use a phone privately or browse
+ email, but software development should be done in an open workspace.
+</p>
+<p>
+ <br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/pair_programming.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/pair_programming.xmi
new file mode 100644
index 0000000..927fdbc
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/pair_programming.xmi
@@ -0,0 +1,343 @@
+<?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" epf:version="1.0.0" xmi:id="-nfbUMyTTqEbCp3HDn-NjOA" name="pair_programming,3.85153041801319E-307" guid="-nfbUMyTTqEbCp3HDn-NjOA" changeDate="2006-11-09T16:44:32.495-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__in_xp"
+name="XE_pair_programming__in_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatIsPair">What is pair programming?</a>
+ </li>
+ <li>
+ <a href="#WhyPair">Why Pair Program?</a>
+ </li>
+ <li>
+ <a href="#FormingPairs">How Pairs Form</a>
+ </li>
+ <li>
+ <a href="#ChangingPairs">When to Change Partners</a>
+ </li>
+ <li>
+ <a href="#WorkingAlone">Can't I work alone?</a>
+ </li>
+ <li>
+ <a href="#Productivity">Doesn't this cut my productivity in half?</a>
+ </li>
+ <li>
+ <a href="#Hygiene">Hygiene and Etiquette Issues</a>
+ </li>
+ <li>
+ <a href="#Disabilities">Disabilities and Physical Incompatibilities</a>
+ </li>
+ <li>
+ <a href="#Distributed">Our Team is Geographically Distributed</a>
+ </li>
+ <li>
+ <a href="#BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
+ </li>
+ <li>
+ <a href="#NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
+ </li>
+ <li>
+ <a href="#Language">My Partner and I have different First Languages</a>
+ </li>
+ <li>
+ <a href="#Schedule">How do we deal with different personal schedules?</a>
+ </li>
+ <li>
+ <a href="#OddNumber">What if we have an odd number of programmers?</a>
+ </li>
+ <li>
+ <a href="#Pathologies">Pairing Pathologies</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatIsPair" name="WhatIsPair">What is pair programming?</a>
+</h3>
+<p>
+ Pair programming is a programming discipline in which all production code is written by pairs of programmers. Each pair
+ works together at a single workstation. They share the keyboard, mouse, and monitor.
+</p>
+<p>
+ The two programmers work closely together. The keyboard moves back and forth between them frequently. Both eyes are
+ locked on the screen. Both minds are immersed in the code. The code is the product of both brains, not just one. Both
+ programmers are equally engaged in writing the code, and neither can claim authorship.
+</p>
+<p>
+ Pairs are short lived. A good pairing time is four hours. Sometimes a pair may last for a day. Very rarely they might
+ last for a week. Instead, the pairs form for a few hours and then break up and reform with different partners.
+</p>
+<p>
+ During the iteration-planning meeting, each programmer signed up for tasks to complete by the end of the iteration. The
+ programmer remains responsible for those tasks. Half of the pairs he works in will be working on his tasks, and half
+ will be working on other's tasks.
+</p>
+<h3>
+ <a id="WhyPair" name="WhyPair">Why Pair Program?</a>
+</h3>
+<p>
+ Pair programming is a form of continuous code review and usually replaces the practice of code reviews and code
+ walkthroughs. The idea is that if code reviews are a good thing, then continuously reviewing the code is better.
+</p>
+<p>
+ Even though every task is the responsibility of an individual programmer, many other programmers will have worked on
+ that task with the responsible programmer. Thus, knowledge of the system spreads through the team, and no single
+ programmer can claim ownership of any part of the code. It is likely that any programmer on the team will be able to
+ work in any module in the system.
+</p>
+<p>
+ Sometimes you get stuck on ideas and can't see past them. Your pair partner can often provide the necessary nudge to
+ get you to see a different point of view.
+</p>
+<p>
+ When new people join the team, they learn by pairing. Over the course of one iteration, they will pair with everybody
+ on the team and see every part of the system currently being worked upon. This is an excellent way to train a new team
+ member.
+</p>
+<h3>
+ <a id="FormingPairs" name="FormingPairs">How Pairs Form</a>
+</h3>
+<p>
+ You come to work in the morning and attend the stand-up meeting. Then you walk up to someone and ask him if he'll help
+ you. Or perhaps someone will walk up to you and ask you to help him. The rule is: when asked, you must say yes.
+ However, you can negotiate schedule.
+</p>
+<p>
+ Pairs form naturally. Managers do not get involved with selecting pairs. Pairing is not scheduled or controlled in any
+ formal manner. The coach or another team member or the team as a whole may notice that certain team members have
+ adopted pathological pairing activities and may intervene.
+</p>
+<h3>
+ <a id="ChangingPairs" name="ChangingPairs">When to Change Partners</a>
+</h3>
+<ul>
+ <li>
+ When you get tired of your current partner.
+ </li>
+ <li>
+ When you think your current partner is too tired or distracted to help.
+ </li>
+ <li>
+ When the two of you get stuck on a concept.
+ </li>
+ <li>
+ Lunchtime.
+ </li>
+ <li>
+ Quitting time.
+ </li>
+ <li>
+ Or generally whenever you feel like it.
+ </li>
+</ul>
+<h3>
+ <a id="WorkingAlone" name="WorkingAlone">Can't I work alone?</a>
+</h3>
+<p>
+ Yes, of course. You just can't check in production code that you've written on your own.
+</p>
+<p>
+ Often we need to hide away somewhere and think some issue through without someone else breathing down our neck or
+ distracting us with news of his sister-in-law's hypoglycemia. It is perfectly OK to hide away, and every programmer
+ should have a private place to go.
+</p>
+<p>
+ When alone, it is perfectly OK to write some code to help you think through a program. However, in an XP team, you are
+ not allowed to check that code into the production environment. Instead, you can bring that code to your next pairing
+ session and walk through it with your partner. Your partner must be given every right to modify, delete, or otherwise
+ refactor it. You should help your partner become comfortable with the code and keep an open mind to every refactoring.
+</p>
+<p>
+ Often the best approach is for the two of you to review the code you wrote and then rewrite it as a pair. Remember, the
+ value of a piece of code is not actually in that code. Rather, it is in the neurons and synapses of the programmers. It
+ is always much easier to write a module the second time, and the result is always better. So, if you program alone,
+ think of the code as a rough draft that you will throw away and rewrite with your pair partner.
+</p>
+<h3>
+ <a id="Productivity" name="Productivity">Doesn't this cut my productivity in half?</a>
+</h3>
+<p>
+ Apparently not. Teams that work in pairs do not report significant loss of productivity. Indeed, they tend to report
+ that they are more productive than when they worked alone.
+</p>
+<p>
+ This anecdotal evidence is backed up by some research studies. Some of those studies can be found at <a
+ href="http://www.pairprogramming.com" target="_blank">www.pairprogramming.com</a>.
+</p>
+<p>
+ One might explain these results by viewing the programmers as two runners pacing each other. When one gets tired or
+ defocused, the other provides the motivation and inspiration to keep going. Also, the pair spends less time going down
+ dead ends and being blocked on ideas.
+</p>
+<p>
+ One thing seems clear. Typing is not the critical element. If it were, then pairing would certainly cut productivity in
+ half. It may be that pairing allows the two to think twice as quickly.
+</p>
+<h3>
+ <a id="Hygiene" name="Hygiene">Hygiene and Etiquette Issues</a>
+</h3>
+<p>
+ Hygiene and etiquette issues are bad breath, body odor, post-nasal drip, colds, rude noises, gas, motor mouths,
+ telephone-jockeys, day-traders, hypochondriacs, etc. Humans are a dirty species. Amazingly, we are usually able to get
+ along with each other's nasty little idiosyncrasies, but there are times when one person has certain habits that are
+ over the top. How do you pair with such a person?
+</p>
+<ul>
+ <li>
+ Grin and bear it, it'll only last for a couple of hours.
+ </li>
+ <li>
+ Bring breath mints.
+ </li>
+ <li>
+ Leave deodorant or gelucel on his desk.
+ </li>
+ <li>
+ Write anonymous letters to the offender.
+ </li>
+ <li>
+ Disconnect the phone.
+ </li>
+ <li>
+ Complain to your boss.
+ </li>
+ <li>
+ But, by far, the best advice is to tell your pair partner outright what bothers you.
+ </li>
+</ul>
+<h3>
+ <a id="Disabilities" name="Disabilities">Disabilities and Physical Incompatibilities</a>
+</h3>
+<ul>
+ <li>
+ Left handed vs. right handed mouse users.
+ </li>
+ <li>
+ Some people need special keyboards to control RSI or OOS.
+ </li>
+ <li>
+ Some people use Dvorak keyboards.
+ </li>
+ <li>
+ Some people need to special screens to be able to see.
+ </li>
+ <li>
+ Some people prefer a trackball to a mouse.
+ </li>
+</ul>
+<p>
+ Problems like these are pretty easy to overcome. Equip certain workstations with two keyboards, two mice, two monitors,
+ etc. Pairs don't have to work at the exact same keyboard, mouse, or monitor.
+</p>
+<p>
+ In fact, pairs don't really have to use the same workstation. They could use two completely independent workstations
+ sitting next to each other, connected with NetMeeting or some other kind of collaboration software.
+</p>
+<h3>
+ <a id="Distributed" name="Distributed">Our Team is Geographically Distributed</a>
+</h3>
+<p>
+ At best, pairing over geographical boundaries is difficult. The best approach is to split the project up into
+ sub-projects that can be done separately at each geographic location. That way the programmers at each location can
+ pair with each other and won't have to interact as much with the remote programmers.
+</p>
+<p>
+ Sometimes the project cannot be easily split amongst all the geographic sites. In that case, you can use NetMeeting or
+ other collaborative software to facilitate remote pairing. Remote pairing is possible but not as effective as local
+ pairing. When you pair locally, you have the advantage of body language, eye contact, and all the other nuances of
+ person-to-person communication to help you. When you pair remotely, you are forced to use a sub-optimal communication
+ channel.
+</p>
+<h3>
+ <a id="BossHog" name="BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
+</h3>
+<ul>
+ <li>
+ Perhaps you are outrunning him. Try to go a little slower and get him engaged.
+ </li>
+ <li>
+ Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.
+ </li>
+ <li>
+ Perhaps he thinks you aren't listening to his ideas. Make sure you talk though all ideas with him, and make sure he
+ has a chance to try as many of his ideas as you get to try of yours.
+ </li>
+ <li>
+ Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.
+ </li>
+ <li>
+ Perhaps he is just not ever going to want to pair program, no matter what. For the moment, the best you can do is
+ dissolve the pair and choose another partner. If the behavior continues, the team will have to decide what to do
+ about it. Perhaps the team will ask him to write configuration scripts or something.
+ </li>
+</ul>
+<h3>
+ <a id="NoSolution" name="NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
+</h3>
+<ul>
+ <li>
+ Gently ask him if you can drive for a while.
+ </li>
+ <li>
+ Gently ask him to describe what he is doing.
+ </li>
+ <li>
+ Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.
+ </li>
+ <li>
+ Perhaps he just can't pair program. Dissolve the pair and choose another partner. If the behavior continues, the
+ team will have to figure out what to do.
+ </li>
+</ul>
+<h3>
+ <a id="Language" name="Language">My Partner and I have different First Languages</a>
+</h3>
+<p>
+ Your only choice is to slow down and work hard to communicate. You might understand him better by writing strategic
+ notes than by talking. Work hard on helping him with pronunciation and grammar. Work hard at understanding his accent
+ and usage. It will take time, but the situation will improve. Do not give up!
+</p>
+<h3>
+ <a id="Schedule" name="Schedule">How do we deal with different personal schedules?</a>
+</h3>
+<p>
+ Some people come in early; some people stay late. How can you find pair partners if everybody has a different working
+ schedule?
+</p>
+<p>
+ Pairs only last for a few hours. All you need is enough overlap time for pairs to form and work effectively. Most
+ personal schedules allow this.
+</p>
+<p>
+ Team members may have to get creative with their scheduling to accommodate each other. Some folks may have to change
+ their schedules to make sure that others have sufficient pairing opportunity. For example, if Bill can only work in the
+ evenings, the team may decide to adopt a rotating schedule for others who can come in late one day and pair with Bill.
+</p>
+<h3>
+ <a id="OddNumber" name="OddNumber">What if we have an odd number of programmers?</a>
+</h3>
+<p>
+ Remember that pairs break up and reform frequently. The odd man out will not have to wait long before someone becomes
+ available to pair with. In the meantime, he can read his email or a trade journal or just read through some code that
+ he is unfamiliar with.
+</p>
+<h3>
+ <a id="Pathologies" name="Pathologies">Pairing Pathologies</a>
+</h3>
+<ul>
+ <li>
+ Joined at the hip. Sometimes two people decide to pair exclusively. This is not a good idea. They are missing the
+ opportunity to get the whole team's input and are isolating themselves into one part of the system. The team should
+ break them up by suggesting that they pair with others.
+ </li>
+ <li>
+ The blind leading the blind. It's not a good idea for new members of the team to pair too often with other new
+ members of the team. Newbies should pair most often with team members with more seniority.
+ </li>
+</ul>
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/planning_game.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/planning_game.xmi
new file mode 100644
index 0000000..118f700
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/planning_game.xmi
@@ -0,0 +1,273 @@
+<?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" epf:version="1.0.0" xmi:id="-85F1Tegv16godTFTKyPdww" name="planning_game,6.7335956461328426E-307" guid="-85F1Tegv16godTFTKyPdww" changeDate="2006-11-09T15:30:46.086-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning__in_xp" name="XE_planning__in_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#Overview">XP Planning Overview</a>
+ </li>
+ <li>
+ <a href="#Iterations">Iterations</a>
+ </li>
+ <li>
+ <a href="#Stories">User Stories</a>
+ </li>
+ <li>
+ <a href="#ReleasePlanning">Release Planning</a>
+ </li>
+ <li>
+ <a href="#IterationPlanning">Iteration Planning</a>
+ </li>
+ <li>
+ <a href="#TaskPlanning">Task Planning</a>
+ </li>
+ <li>
+ <a href="#Recovery">Recovery</a>
+ </li>
+ <li>
+ <a href="#Feedback">Feedback</a>
+ </li>
+ <li>
+ <a href="#AcceptanceTests">Acceptance Tests</a>
+ </li>
+ <li>
+ <a href="#First">How do we create budgets for the first iteration and release?</a>
+ </li>
+ <li>
+ <a href="#Velocity">How do changes in the team affect velocity?</a>
+ </li>
+</ul>
+<h3>
+ <a id="Overview" name="Overview">XP Planning Overview</a>
+</h3>
+<p>
+ An XP project is broken down into a set of two-week iterations. Each iteration follows the next in a linear sequence.
+ Executable code that passes unit tests and acceptance tests is the core deliverable beginning with the first iteration.
+</p>
+<p>
+ Planning an XP project is a continuous activity. There is no master plan that is decided upon at the start of the
+ project and that is followed until the end. An XP project is planned in detail, one iteration at a time. The plan for
+ an iteration is created at the beginning of that iteration. The plan is then checked and adjusted continuously
+ throughout the iteration.
+</p>
+<p>
+ Iterations are grouped into larger milestones called releases. A typical release spans two to three months. At the
+ beginning, the release plan is created. This is a very rough plan that tentatively describes the features that the
+ project team believes can and should be implemented during that time. The release plan is continuously updated as each
+ iteration within the release provides more data.
+</p>
+<p>
+ The overriding principle of XP planning is feedback. Every iteration provides data about the velocity of the team. That
+ data is used to continuously calibrate the plan. Measuring the results of each iteration generates a continuous stream
+ of data. The team and its managers use that data to make decisions and take actions that will improve the project
+ outcome.
+</p>
+<h3>
+ <a id="Iterations" name="Iterations">Iterations</a>
+</h3>
+<p>
+ An iteration is simply a span of time in which the team implements a set of features. In an XP project, this time is
+ typically two weeks and should never be longer than four. The team should decide how long its iterations should be and
+ then stick to that time. It is not wise to continuously change the duration of the iterations because that makes
+ determination of a team's velocity more complicated.
+</p>
+<p>
+ When an iteration is over, it is over, irrespective of how much the iteration accomplished. It is never wise to extend
+ an iteration in order to provide more time to finish the planned deliverables. The ability to plan an XP project
+ depends strongly on fixed-length iterations of consistent duration and ruthless termination of each iteration
+ irrespective of whether the planned tasks are complete to allow the velocity to be measured.
+</p>
+<h3>
+ <a id="Stories" name="Stories">User Stories</a>
+</h3>
+<p>
+ The content or scope of an XP project is described in user stories. User stories are very simple descriptions of the
+ features to be developed. Each story is typically written on a single index card and contains virtually no detail. The
+ card contains little more than the name of the feature.
+</p>
+<p>
+ Stories are the tokens of planning. When we create a release plan or an iteration plan, we select the stories we want
+ in that release or iteration and schedule them. Once a story is scheduled for an iteration, two things must happen in
+ that iteration. First, the details of the story must be fleshed out, resulting in the creation of appropriate
+ acceptance tests. Second, the story must be implemented so that it passes those acceptance tests.
+</p>
+<p>
+ In order to choose which stories to schedule for an iteration, we need to know two things: how important is the story
+ and how long will the story take to implement. The first comes from the judgment of the customers/stakeholders, and the
+ second comes from the judgment of the developers.
+</p>
+<p>
+ Developers estimate the stories. The estimate for a user story should neither be too big nor too small. Those that are
+ too big should be split into multiple stories, and those that are too small should be merged. A good guideline is to
+ keep the size of a user story between two days and a week of team effort. The customer/stakeholders and the developers
+ will negotiate over the stories, splitting and merging as necessary, until they are appropriately sized.
+</p>
+<p>
+ Estimates are written on the story cards as numbers. We refer to these numbers as story points. It doesn't matter what
+ units were originally used to create the estimates. It might have been man-days or man weeks or something else. Once
+ the estimates are made, we forget the units and simply refer to them as story points.
+</p>
+<h3>
+ <a id="ReleasePlanning" name="ReleasePlanning">Release Planning</a>
+</h3>
+<p>
+ The customer/stakeholders know what features they want completed for the next release. The developers know how much
+ they can get done in the next release. The developers give the customer/stakeholders a budget for the release based
+ upon how much the developers got done in the previous release. If the developers finished 720 story points in the last
+ release, then it is safe to say that they'll finish about 720 in this release.
+</p>
+<p>
+ The customer/stakeholders choose stories that add up to this number. They choose the stories that are most critical and
+ have the most business value. They lay them out in roughly the order in which they'd like to see them implemented. This
+ selection and ordering of the stories becomes the release plan.
+</p>
+<p>
+ Any stakeholder can look at the release plan and see about when a particular feature will be implemented. They know
+ that, if the feature is listed early, then it is likely to be completed. If a story is listed late in the plan, then
+ the risk is higher. The release plan is not static. Any time priorities change, the customer/stakeholders can change
+ the plan by reordering stories, adding new stories, removing existing stories, and so on. Thus, the release plan is
+ always changing in response to the changing business.
+</p>
+<h3>
+ <a id="IterationPlanning" name="IterationPlanning">Iteration Planning</a>
+</h3>
+<p>
+ At the beginning of each iteration, we take a half day to plan that iteration. The developers supply the
+ customer/stakeholders with a budget for the iteration based upon what they finished in the last iteration. If they got
+ 68 story points done in the last iteration, then it is safe to plan for 68 in this iteration.
+</p>
+<p>
+ The customer/stakeholders select the stories from the release plan that they feel are most important for this
+ iteration. The sum of the selected story points cannot exceed the budget given by the developers.
+</p>
+<p>
+ Though the customer/stakeholders can suggest an ordering for the stories in an iteration, the developers are not bound
+ to that ordering. The developers are free to rearrange the stories within the iteration in any manner that makes sense.
+</p>
+<p>
+ Once the iteration has begun, the customer/stakeholders cannot make arbitrary changes to the stories in that iteration.
+ Any change has to be carefully negotiated with the developers. If the customer/stakeholders want to remove a story and
+ replace it with another, they must check with the developers to see if that will fit in the iteration. If the
+ developers agree, then the change can be made. If the developers do not agree then the customer/stakeholder may decide
+ to wait until the next iteration or may decide to completely abort the current iteration and plan a new iteration.
+</p>
+<h3>
+ <a id="TaskPlanning" name="TaskPlanning">Task Planning</a>
+</h3>
+<p>
+ Once the stories have been selected for the iteration, then the developers break the stories down into programming
+ tasks. The tasks are recorded on a whiteboard or a flip chart.
+</p>
+<p>
+ Tasks are simple units of work that accomplish a particular goal within a story. One task might be to set up the
+ database schema for a story. Another might be to create the HTML pages for a story. Still another task might be to
+ write a servlet that checks passwords. A task should be on the order of a man-day of effort.
+</p>
+<p>
+ The breakdown of stories into tasks is a design activity. The developers consider how the stories will be developed and
+ whether or not there are any design options that allow the stories to share tasks.
+</p>
+<p>
+ Once the list of tasks is complete, the developers take turns signing up for the tasks. Each developer puts his or her
+ initials next to a task and then estimates that task. The estimate is typically in hours.
+</p>
+<p>
+ Each developer has a budget of hours that he keeps in the back of his head. This budget represents the number of hours
+ he believes he will have for the development of his tasks in this iteration. Each time a developer signs up for a task,
+ he deducts his estimate from that budget. When a developer's budget goes to zero, he stops signing up for tasks.
+</p>
+<p>
+ Ideally, at the end of sign up, all the tasks would have initials, and every developer's budget would be at zero. But
+ this is seldom the case. There are two much more likely scenarios:
+</p>
+<ul>
+ <li>
+ Everybody's budget is at zero, and there are tasks left. In this case, the developers need to work together to find
+ a better division of tasks. If a GUI guy signed up for a database task just to get some new experience, then
+ perhaps he should swap with someone who could do that task more quickly. If after such trading there are still
+ tasks left over, then the team has to ask the customer/stakeholder to remove some stories or tasks.
+ </li>
+ <li>
+ The tasks are all signed up, but some people still have budget left. In this case, the team needs to ask the
+ customer/stakeholders to give them a few more stories.
+ </li>
+</ul>
+<h3>
+ <a id="Recovery" name="Recovery">Recovery</a>
+</h3>
+<p>
+ On the day that marks the halfway point of the iteration, the team has another short meeting. Half the tasks should be
+ complete. More importantly, half the stories should be complete. More precisely, a set of stories whose points add up
+ to half the iteration budget should be complete. The nightmare we are trying to avoid is that the iteration ends with
+ all the stories 95% complete. We'd rather that 95% of the stories be complete.
+</p>
+<p>
+ If half the stories are not complete, then the team asks the customer to remove some stories from the iteration. This
+ same kind of check is made towards the end of the iteration. The team assesses how much they have working and how much
+ is left. If it appears that they may not complete all the promised stories, then they ask the customer/stakeholders to
+ remove some.
+</p>
+<p>
+ By the same token, if more than half the stories are complete by the midpoint, the developers ask the
+ customer/stakeholder for more work. Likewise, as the iteration gets close to the end, any idle developers should help
+ others complete their tasks. If it appears that all tasks will be completed early, the developers should ask the
+ customer/stakeholders for more stories.
+</p>
+<h3>
+ <a id="Feedback" name="Feedback">Feedback</a>
+</h3>
+<p>
+ The number of story points completed in the previous iteration is the team's current velocity. This velocity is used as
+ the budget for the next iteration. Thus we only commit to doing what we know we did in the last iteration.
+</p>
+<p>
+ The same is true for releases. When we plan the next release, we use the number of story points we finished in the
+ previous release.
+</p>
+<p>
+ Individual developers use the same technique for their task budgets. If they got 22 hours worth of tasks finished in
+ the last iteration, they should only sign up for 22 hours of tasks this time.
+</p>
+<h3>
+ <a id="AcceptanceTests" name="AcceptanceTests">Acceptance Tests</a>
+</h3>
+<p>
+ After the iteration-planning meeting is over, the customer/stakeholders must provide the developers with acceptance
+ tests for the stories that were selected for the iteration. Typically, these tests will be created with the help of the
+ Q/A or testing groups. These tests specify exactly to the developers what the stories being implemented must do, so
+ they must be given to the developers as early as possible.
+</p>
+<p>
+ Some XP teams manage to write their acceptance tests an iteration early. The Q/A or testing group works with the
+ customer/stakeholders during the current iteration to determine which stories are most likely to be selected for the
+ next iteration. Together, they define the set of acceptance tests that will be given to the developers during the next
+ iteration planning meeting. By planning ahead like this, the developers can have the acceptance tests for an
+ iteration's stories immediately.
+</p>
+<h3>
+ <a id="First" name="First">How do we create budgets for the first iteration and release?</a>
+</h3>
+<p>
+ If you have history from other projects, then make use of that. Otherwise, you have to guess. A good way to guess is to
+ spend a day or two trying to implement one or two stories. This should give you an inkling of your velocity.
+</p>
+<h3>
+ <a id="Velocity" name="Velocity">How do changes in the team affect velocity?</a>
+</h3>
+<p>
+ If the change is small, then it's probably best to allow the velocity to change by itself. If you got 52 story points
+ done last iteration, but this iteration you have a new team member, it's probably best to keep your velocity at 52 and
+ commit do doing just 52 story points in the next iteration. At the end of that iteration, you may find that you've done
+ a little more than 52, and you can adjust your velocity accordingly.
+</p>
+<p>
+ On the other hand, if 30% of the team is going on vacation for the next iteration, then it's probably wise to reduce
+ your velocity accordingly.
+</p>
+<p>
+ <br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/refactoring.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/refactoring.xmi
new file mode 100644
index 0000000..f82d991
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/refactoring.xmi
@@ -0,0 +1,616 @@
+<?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" epf:version="1.0.0" xmi:id="-dbA7zKOJY5WPZyLXErA9vw" name="refactoring,8.137126904637637E-306" guid="-dbA7zKOJY5WPZyLXErA9vw" changeDate="2006-11-09T16:45:22.634-0800" version="1.0.0">
+ <mainDescription><h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatIs">What is refactoring?</a>
+ </li>
+ <li>
+ <a href="#Why">Why should I refactor?</a>
+ </li>
+ <li>
+ <a href="#When">When should I refactor?</a>
+ </li>
+ <li>
+ <a href="#Example">An example of refactoring</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatIs" name="WhatIs">What is refactoring?</a>
+</h3>
+<p>
+ Refactoring is the act of improving the structure of a program without changing its behavior. Refactoring is done in
+ tiny little steps, each barely worth doing. In between each step, we run the relevant unit tests to make sure that the
+ changes we made have not broken anything. The edit/compile/test cycle is usually between 30 seconds and five minutes.
+</p>
+<h3>
+ <a id="Why" name="Why">Why should I refactor?</a>
+</h3>
+<p>
+ The purpose of refactoring is to improve the design and readability of the code. There are several specific goals:
+</p>
+<ul>
+ <li>
+ The code should pass all its tests.
+ </li>
+ <li>
+ It should be as expressive as it is possible for you to make it.
+ </li>
+ <li>
+ It should be as simple as it is possible for you to make it.
+ </li>
+ <li>
+ It should have no redundancy.
+ </li>
+</ul>
+<h3>
+ <a id="When" name="When">When should I refactor?</a>
+</h3>
+<p>
+ Refactoring is not something that we schedule. There is no line item in the schedule for it. There is no particular
+ time when we do it. Refactoring is done all the time. As you and your pair partner work on a task, such as writing
+ tests and code, you will notice that the code and tests are not as clean and simple as they could be. That is the time
+ to stop and refactor that code.
+</p>
+<p>
+ The rule is: <b>Don't let the sun set on bad code.</b>
+</p>
+<h3>
+ <a id="Example" name="Example">An Example of Refactoring</a>
+</h3>
+<p>
+ Consider the two unit tests and the <font size="3"><tt>Formatter</tt></font> class shown below. The <font
+ size="3"><tt>Formatter</tt></font> class works but is not as expressive as I'd like it to be. So I'll refactor it in
+ stages.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+ public void testCenterLine()
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ Formatter f = new Formatter();
+</pre>
+<pre>
+ f.setLineWidth(10);
+</pre>
+<pre>
+ assertEquals(" word ", f.center("word"));
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public void testOddCenterLine() throws Exception
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ Formatter f = new Formatter();
+</pre>
+<pre>
+ f.setLineWidth(10);
+</pre>
+<pre>
+ assertEquals(" hello ", f.center("hello"));
+</pre>
+<pre>
+ }
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<br />
+<br />
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+ import java.util.Arrays;
+</pre>
+<pre>
+ public class Formatter
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ private int width;
+</pre>
+<pre>
+ private char spaces[];
+</pre>
+<pre>
+ public void setLineWidth(int width)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+ spaces = new char[width];
+</pre>
+<pre>
+ Arrays.fill(spaces, ' ');
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public String center(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ int remainder = 0;
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ int padding = (width - line.length()) / 2;
+</pre>
+<pre>
+ remainder = line.length() % 2;
+</pre>
+<pre>
+ b.append(spaces, 0, padding);
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ b.append(spaces, 0, padding + remainder);
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ }
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ The <font size="3"><tt>setLineWidth</tt></font> function is a little mysterious. What is this <font
+ size="3"><tt>spaces</tt></font> array and why is it being filled with blanks? By looking ahead into the <font
+ size="3"><tt>center</tt></font> function, we see that the <font size="3"><tt>spaces</tt></font> array is just a
+ convenience to allow us to move a number of blanks into a <font size="3"><tt>StringBuffer</tt></font>. I wonder if we
+ really need this convenience array.
+</p>
+<p>
+ For the moment, I'm going to pull the initialization of the array out into its own function named <font
+ size="3"><tt>buildArrayOfSpaces</tt></font>. That way, it's all in one place, and I can think about it a little more
+ clearly.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public void setLineWidth(int width)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+<b>buildArrayOfSpaces(width);</b>
+</pre>
+<pre>
+}
+</pre>
+<pre>
+private void <b>buildArrayOfSpaces(int width)</b>
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ spaces = new char[width];
+</pre>
+<pre>
+ Arrays.fill(spaces, ' ');
+</pre>
+<pre>
+}
+</pre>
+<pre>
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ I don't like the way <font size="3"><tt>center</tt></font> function is constructed. There is math scattered all through
+ it. I think we can rearrange the math to make things clearer.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public String center(String line)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+<b>int remainder = line.length() % 2;</b>
+</pre>
+<pre>
+<b>int numberOfBlanksInFront = (width - line.length()) / 2;</b>
+</pre>
+<pre>
+ <b>int numberOfBlanksAtEnd = (width - line.length()) / 2 + remainder;</b>
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksInFront</b>);
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksAtEnd</b>);
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+}
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font><br />
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ This looks good, but we can reduce the clutter by changing some of the variables into functions.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public String center(String line)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksInFront(line)</b>);
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ b.append(spaces, 0, <b>numberOfBlanksBehind(line)</b>);
+</pre>
+<pre>
+ return b.toString();
+}
+</pre>
+<pre>
+<b>private int numberOfBlanksBehind(String line)</b>
+</pre>
+<pre>
+<b>{</b>
+</pre>
+<pre>
+ <b>int extraBlankIfOdd = line.length() % 2;</b>
+</pre>
+<pre>
+ <b>return (width - line.length()) / 2 + extraBlankIfOdd;</b>
+</pre>
+<pre>
+<b>}</b>
+</pre>
+<pre>
+<b>private int numberOfBlanksInFront(String line)</b>
+</pre>
+<pre>
+<b>{</b>
+ <b>return (width - line.length()) / 2;</b>
+</pre>
+<pre>
+<b>}</b>
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ This makes the <font size="3"><tt>center</tt></font> function read a little better. However, the use of the <font
+ size="3"><tt>StringBuffer.append</tt></font> function is a little confusing. We might be able to improve it a little by
+ creating a more explicit function.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+public String center(String line)
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+<b>appendBlanks(b, numberOfBlanksInFront(line));</b>
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+<b>appendBlanks(b, numberOfBlanksBehind(line));</b>
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+}
+</pre>
+<pre>
+<strong>private void appendBlanks(StringBuffer b, int numberOfBlanks)</strong>
+</pre>
+<pre>
+<strong>{</strong>
+</pre>
+<pre>
+ <strong>b.append(spaces, 0, numberOfBlanks);</strong>
+</pre>
+<pre>
+<strong>}</strong>
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ Now we can rewrite <font size="3"><tt>appendBlanks</tt></font> to avoid using the <font size="3"><tt>spaces</tt></font>
+ array.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+import java.util.Arrays;
+</pre>
+<pre>
+public class Formatter
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ private int width;
+</pre>
+<pre>
+ public void setLineWidth(int width)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public String center(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ appendBlanks(b, numberOfBlanksInFront(line));
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ appendBlanks(b, numberOfBlanksBehind(line));
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private void appendBlanks(StringBuffer b, int numberOfBlanks)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+<b> while(numberOfBlanks-- &gt; 0)</b>
+</pre>
+<pre>
+<b> b.append(' ');</b>
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private int numberOfBlanksBehind(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ int extraBlankIfOdd = line.length() % 2;
+</pre>
+<pre>
+ return (width - line.length()) / 2 + extraBlankIfOdd;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private int numberOfBlanksInFront(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ return (width - line.length()) / 2; }
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+}<font size="3"><b><i>Run the tests: the tests pass</i></b></font><br />
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ The names of functions like <font size="3"><tt>numberOfBlanksBehind</tt></font> imply that the reader knows that these
+ will be called from the <font size="3"><tt>center</tt></font> function. We should eliminate this implication by
+ renaming those functions.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+<pre>
+import java.util.Arrays;
+</pre>
+<pre>
+public class Formatter
+</pre>
+<pre>
+{
+</pre>
+<pre>
+ private int width;
+</pre>
+<pre>
+ public void setLineWidth(int width)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ this.width = width;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ public String center(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ StringBuffer b = new StringBuffer();
+</pre>
+<pre>
+ appendBlanks(b, <b>numberOfBlanksToLeftOfCenter</b>(line));
+</pre>
+<pre>
+ b.append(line);
+</pre>
+<pre>
+ appendBlanks(b, <b>numberOfBlanksToRightOfCenter</b>(line));
+</pre>
+<pre>
+ return b.toString();
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private void appendBlanks(StringBuffer b, int numberOfBlanks)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ while(numberOfBlanks-- &gt; 0)
+</pre>
+<pre>
+ b.append(' ');
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+ private int <b>numberOfBlanksToRightOfCenter</b>(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ int extraBlankIfOdd = line.length() % 2;
+</pre>
+<pre>
+ return (width - line.length()) / 2 + extraBlankIfOdd;
+</pre>
+<pre>
+ }
+
+ private int <b>numberOfBlanksToLeftOfCenter</b>(String line)
+</pre>
+<pre>
+ {
+</pre>
+<pre>
+ return (width - line.length()) / 2;
+</pre>
+<pre>
+ }
+</pre>
+<pre>
+}
+<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
+</pre>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ And I think we are done. You might find other refactorings to do, or you might not agree with all of the refactorings
+ I've done. That's to be expected. The point is, however, that I have put a lot of effort into the readability and
+ simplicity of this class. That effort will help others understand this class and make it easier for them to change the
+ class when the time comes.
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/Thumbs.db b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/Thumbs.db
new file mode 100644
index 0000000..f4a7efc
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/Thumbs.db
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/md_state3.gif b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/md_state3.gif
new file mode 100644
index 0000000..ee64962
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/md_state3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif
new file mode 100644
index 0000000..182076e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg
new file mode 100644
index 0000000..08b590c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_driven_development_tdd.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_driven_development_tdd.xmi
new file mode 100644
index 0000000..b4a5ead
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_driven_development_tdd.xmi
@@ -0,0 +1,625 @@
+<?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" epf:version="1.0.0" xmi:id="-jc10ie6UDWUJzSDfsQExjw" name="test_driven_development_tdd,3.9254165491375454E-306" guid="-jc10ie6UDWUJzSDfsQExjw" changeDate="2006-11-21T15:17:42.164-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a id="XE_test_driven_development__in_xp"
+name="XE_test_driven_development__in_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatIs">What is TDD?</a>
+ </li>
+ <li>
+ <a href="#Java">A TDD Example in Java</a>
+ </li>
+ <li>
+ <a href="#Benefits">What are the benefits of TDD?</a>
+ </li>
+ <li>
+ <a href="#Costs">What are the costs of TDD?</a>
+ </li>
+ <li>
+ <a href="#Principles">What testing principles should I employ?</a>
+ </li>
+ <li>
+ <a href="#GUIS">How do I test GUIs?</a>
+ </li>
+ <li>
+ <a href="#Embedded">How do I test embedded systems?</a>
+ </li>
+ <li>
+ <a href="#Concurrency">How do I test concurrency?</a>
+ </li>
+ <li>
+ <a href="#Database">How do I test database transactions?</a>
+ </li>
+ <li>
+ <a href="#Servlets">How do I test servlets?</a>
+ </li>
+ <li>
+ <a href="#WebPages">How do I test web pages?</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatIs" name="WhatIs">What is TDD?</a>
+</h3>
+<p>
+ TDD is the practice of writing unit tests and production code concurrently and at a very fine level of granularity. A
+ pair of programmers first write a small portion of a unit test, and then they write just enough production code to make
+ that unit test compile and execute. Then they write a little bit more of the test and then add enough production code
+ to make that new bit compile and pass. This cycle lasts somewhere between 30 seconds and five minutes. Rarely does it
+ grow to ten minutes. In each cycle, the tests come first. Once a unit test is done, the pair goes on to the next test
+ until they run out of tests for the task they are currently working on.
+</p>
+<h3>
+ <a id="Java" name="Java">A TDD Example in Java</a>
+</h3>
+<p>
+ What follows is a simple example of test-driven development. The program we are writing is a text formatter that can
+ take arbitrary strings and can horizontally center them in a page. The first column shows the tests, and the second
+ column shows the production code. The test is always written first and compiled. If the compile fails, then production
+ code is added to make the compile succeed. Then the test is run to see if it passes. If the test fails, then production
+ code is added to make the test pass. If the test passes, then a new test is added.
+</p>
+<table width="100%" border="1">
+ <tbody>
+ <tr>
+ <td>
+ <div align="center">
+ <font size="-1"><i><b>First we write the test</b></i></font>
+ </div>
+ </td>
+ <td>
+ <div align="center">
+ <font size="-1"><i><b>Then we write the production code</b></i></font>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+ <tbody>
+ <tr>
+ <td>
+<pre>
+<font size="2">public void testCenterLine(){
+ Formatter f = new Formatter();
+}</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">does not compile</font>
+</pre>
+ </div>
+ </td>
+ <td>
+<pre>
+<font size="2">class Formatter{
+}
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#008000" size="2">compiles and passes</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+<pre>
+<font size="2">public void testCenterLine(){
+ Formatter f = new Formatter();
+ f.setLineWidth(10);
+ assertEquals(" word ", f.center("word"));
+}
+
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">does not compile</font>
+</pre>
+ </div>
+ </td>
+ <td>
+<pre>
+<font size="2">class Formatter{
+ public void setLineWidth(int width) {
+ }
+
+
+ public String center(String line) {<br />
+ return "";
+ }
+}</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">compiles and fails</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <font size="2">&nbsp;</font>
+ </td>
+ <td>
+<pre>
+<font size="2">import java.util.Arrays;
+
+
+public class Formatter {
+ private int width;
+ private char spaces[];
+
+ public void setLineWidth(int width) {
+ this.width = width;
+ spaces = new char[width];
+ Arrays.fill(spaces, ' ');
+ }
+
+
+ public String center(String line) {
+ StringBuffer b = new StringBuffer();
+ int padding = width/2 - line.length();
+ b.append(spaces, 0, padding);
+ b.append(line);
+ b.append(spaces, 0, padding);
+ return b.toString();
+ }
+}
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">compiles and unexpectedly fails</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <font size="2">&nbsp;</font>
+ </td>
+ <td>
+<pre>
+<font size="2">public String center(String line) {
+ StringBuffer b = new StringBuffer();
+ <b>int padding = (width - line.length()) / 2;</b>
+ b.append(spaces, 0, padding);
+ b.append(line);
+ b.append(spaces, 0, padding);
+ return b.toString();
+}
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#008000" size="2">compiles and passes</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ <tr>
+ <td>
+<pre>
+<font size="2">public void testCenterLine() {
+ Formatter f = new Formatter();
+ f.setLineWidth(10);
+ assertEquals(" word ", f.center("word"));
+}
+
+<b>public void testOddCenterLine() {
+ Formatter f = new Formatter();
+ f.setLineWidth(10);
+ assertEquals( " hello ", f.center("hello"));
+}</b>
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#ff0000" size="2">compiles and fails</font>
+</pre>
+ </div>
+ </td>
+ <td>
+<pre>
+<font size="2">public String center(String line) {
+ <b>int remainder = 0;</b>
+ StringBuffer b = new StringBuffer();
+ int padding = (width - line.length()) / 2;
+ <b>remainder = line.length() % 2;</b>
+ b.append(spaces, 0, padding);
+ b.append(line);
+ b.append(spaces, 0, padding + <b>remainder</b>);
+ return b.toString();
+}
+
+</font>
+</pre>
+ <div align="center">
+<pre>
+<font color="#008000" size="2">compiles and passes</font>
+</pre>
+ </div>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<h3>
+ <a id="Benefits" name="Benefits">What are the benefits of TDD?</a>
+</h3>
+<ul>
+ <li>
+ <b>Test Coverage</b>. If you follow the rules of TDD, then virtually 100% of the lines of code in your production
+ program will be covered by unit tests. This does not cover 100% of the paths through the code, but it does make
+ sure that virtually every line is executed and tested.<br />
+ </li>
+ <li>
+ <b>Test Repeatability</b>. The tests can be run any time you like. This is especially useful after you've made a
+ change to the production code. You can run the tests to make sure you haven't broken anything. Having the tests to
+ back you up can give you the courage to make changes that would otherwise be too risky to make.<br />
+ </li>
+ <li>
+ <b>Documentation</b>. The tests describe your understanding of how the code should behave. They also describe the
+ API. Therefore, the tests are a form of documentation. Unit tests are typically pretty simple, so they are easy to
+ read. Moreover, they are unambiguous and executable. Finally, if the tests are run every time any change is made to
+ the code, they will never get out of date.<br />
+ </li>
+ <li>
+ <b>API Design</b>. When you write tests first, you put yourself in the position of a user of your program's API.
+ This can only help you design that API better. Your first concern, as you write the tests, is to make it easy and
+ convenient to use that API.<br />
+ </li>
+ <li>
+ <b>System Design</b>. A module that is independently testable is a module that is decoupled from the rest of the
+ system. When you write tests first, you automatically decouple the modules you are testing. This has a profoundly
+ positive effect on the overall design quality of the system.<br />
+ </li>
+ <li>
+ <b>Reduced Debugging</b>. When you move in the tiny little steps recommended by TDD, it is hardly ever necessary to
+ use the debugger. Debugging time is reduced enormously.<br />
+ </li>
+ <li>
+ <b>Your code worked a minute ago!</b> If you observe a team of developers who are practicing TDD, you will notice
+ that every pair of developer had their code working a minute ago. It doesn't matter when you make the observation!
+ A minute or so ago, each pair ran their code, and it passed all its tests. Thus, you are never very far away from
+ making the system work.<br />
+ </li>
+</ul>
+<h3>
+ <a id="Costs" name="Costs">What are the costs of TDD?</a>
+</h3>
+<ul>
+ <li>
+ Programming in tiny cycles can seem inefficient. Programmers often find it frustrating to work in increments that
+ are so small that they know the outcome of the test. It sometimes seems that such a tiny step is not worth
+ taking.<br />
+ </li>
+ <li>
+ A lot of test code is produced. It is not uncommon for the bulk of test code to exceed the bulk of production code
+ by a large amount. This code has to be maintained at a significant cost.<br />
+ </li>
+ <li>
+ A lot of time is spent keeping the tests in sync with the production code. Programmers sometimes feel that time
+ spent on keeping the tests working and well structured is time that is not being spent on the customer's
+ needs.<br />
+ </li>
+</ul>
+<h3>
+ <a id="Principles" name="Principles">What testing principles should I employ?</a>
+</h3>
+<ul>
+ <li>
+ <b>Isolation</b>. When writing a unit test for a module, consider whether you want that module to invoke other
+ modules. If not, then isolate the module with interfaces. For example, suppose you are testing a module that
+ interacts with the database. The test has nothing to do with the database; it simply tests the way that the module
+ manipulates the database. So you isolate the module from the database by creating an interface that represents the
+ database and that the module uses. Then, for the purposes of the test, you implement that interface with a test
+ stub. This kind of isolation greatly decreases the amount of coupling in the overall system.
+ </li>
+</ul>
+<p>
+ <img height="166" alt="" src="resources/xp_tdd_guid_database.jpg" width="403" />
+</p>
+<ul>
+ <li>
+ <b>Simplicity</b>. Keep your edit/compile/test cycles extremely short: less than five minutes on average. Write
+ only enough production code to make the current tests pass. Try not to write code that will make future tests pass.
+ At every edit/compile/test cycle, keep the code as simple as it can be.<br />
+ </li>
+ <li>
+ <b>Increase Generality</b>. As you add test cases, the production code should become more and more general. Always
+ try to increase generality. For example, consider the following test case:<br />
+
+ <blockquote>
+ <blockquote>
+<pre>
+ public testThreeSquared() { assertEquals(9, MyClass.square(3)); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ We might make this test pass by writing:
+ </p>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+<pre>
+ public class MyClass { public static int square(int n) { return 9; } }
+</pre>
+ </blockquote>
+ <p>
+ This conforms to the simplicity principle. If <font size="3"><tt>testThreeSquared</tt></font> were the only test
+ case that mattered, then this implementation would be correct. Of course, we know that it is incorrect, but in its
+ current form it verifies that the test case actually passes when it is supposed to. Now suppose that we add a new
+ test case:
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public testFourSquared() { assertEquals(16, MyClass.square(4)); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ We could make this pass by changing the square function as follows:
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public static int square(int n) { if (n == 3) return 9; else return 16; }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ While this would pass the test, it violates the rule to make the code more general. To make the code more general,
+ we have to return the square of the argument.
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public static int square(int n) { return n*n; }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ This solution passes all the tests, is simple, and increases the generality of the solution.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <b>Corner Cases and Boundary Conditions</b>. Corner cases and boundary conditions are implemented in the production
+ code with if statements or other similar decision structures. Don't write these statements unless you have a unit
+ test that is failing because they don't exist. For example, let's say you are calculating weekly pay for an hourly
+ employee.
+ <blockquote>
+ <blockquote>
+<pre>
+ public void testHourlyPay() { double hourlyRate = 10.00; double hoursWorked = 8; Employee e = new Employee(hourlyRate); assertEquals(80.00, e.calculatePay(hoursWorked)); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ The code that makes this pass looks like this:
+ </p>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <blockquote>
+<pre>
+ public class Employee { private double hourlyRate; public Employee(double hourlyRate) { this.hourlyRate = hourlyRate; } public double calculatePay(double hoursWorked) { return hourlyRate * hoursWorked; } }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ Now let's say we want to calculate overtime pay. Any hours over eight are charged at time-and-a-half. The first
+ thing we do is add the new failing test case:
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public void testOvertime() { double hourlyRate = 10.00; double hoursWorked = 10; Employee e = new Employee(hourlyRate); assertEquals(110.00, e.calculatePay(hoursWorked); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ <i>Then</i> we make the test case pass by changing the production code.
+ </p>
+ <blockquote>
+ <blockquote>
+<pre>
+ public double calculatePay(double hoursWorked) { double overtimeRate = hourlyRate * 1.5; double normalHours = Math.min(hoursWorked, 8.0); double overtimeHours = hoursWorked ̵; normalHours; return (normalHours * hourlyRate) + (overtimeHours * overtimeRate); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ Avoid adding any <font size="3"><tt>if, while, for, do,</tt></font> or any other type of conditional without a
+ failing test case. Remember to add test cases for each such boundary condition.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <b>Test Anything That Could Possibly Break</b>. By the same token, don't bother to test things that cannot possibly
+ break. For example, it is usually fruitless to test simple accessors and mutators.
+ <blockquote>
+ <blockquote>
+<pre>
+ public void testAccessorAndMutator() { X x = new X(); x.setField(3); assertEquals(3, x.getField()); }
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ Accessors and mutators cannot reasonably break. So there's no point in testing them. Judgment clearly has to be
+ applied to use this rule. You will be tempted to avoid a necessary unit test by claiming that the code cannot
+ possibly break. You'll know you've fallen into this habit when you start finding bugs in methods you thought
+ couldn't break.
+ </p>
+ </li>
+ <li>
+ <b>Keep Test Data in the Code</b>. It is sometimes tempting to put test data into a file, especially when the input
+ to a module is a file. However, the best place for test data is in the unit test code itself. For example, assume
+ we have a function that counts the number of characters in a file. The signature for this function is:
+ <blockquote>
+ <blockquote>
+<pre>
+ public int count(String fileName).
+</pre>
+ </blockquote>
+ </blockquote>
+ <p>
+ In order to keep the test data in the unit test code, the test should be written this way:
+ </p>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <blockquote>
+ <blockquote>
+<pre>
+ public testCount() { File testFile = new File("testFile"); FileOutputStream fos = new FileOutputStream(testFile); PrintStream ps = new PrintStream(fos); ps.print("Oh, you Idiots!"); ps.close(); assertEquals(15, FileUtil.count("testFile")); testFile.delete(); }
+</pre>
+ </blockquote>
+ </blockquote>
+ </li>
+</ul>
+<blockquote>
+ <p>
+ This keeps all the data relevant to the test in one place.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <b>Test Pruning</b>. Sometimes you'll write tests that are useful for a time but become redundant as other tests
+ take over their role. Don't be afraid to remove old redundant tests. Keep the test suite as small as possible
+ without compromising coverage.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Keep Test Time Short</b>. The effectiveness of the tests depends upon convenience. The more convenient it is to
+ run the tests, the more often they will be run. Thus, it is very important to keep the test run time very short. In
+ a large system, this means partitioning the tests.<br />
+ <br />
+ When working on a particular module, you'll want to choose the tests that are relevant to that module and the
+ surrounding modules. Keep the test time well under a minute. Ten seconds is often too long.<br />
+ <br />
+ When checking in a module, run a test suite that tests the whole system but takes no more than 10 minutes to run.
+ This may mean you'll have to pull out some of the longer running tests.<br />
+ <br />
+ Every night, run all the tests in the system. Keep the running time small enough so that they can be run more than
+ once before morning just in case there is a problem that forces a rerun.
+ </li>
+</ul>
+<h3>
+ <a id="GUIS" name="GUIS">How do I test GUIs?</a>
+</h3>
+<p>
+ The trick to writing unit tests for GUIs is separation and decoupling. Separate the GUI code into three layers,
+ typically called <b>Model</b>, <b>View</b>, and <b>Presenter</b>:
+</p>
+<ul>
+ <li>
+ The <b>Model</b> understands the business rules of the items that are to be displayed on the screen. All relevant,
+ business-related policies are implemented in this module. Therefore, this module is easy to test based solely on
+ its inputs and outputs.<br />
+ </li>
+ <li>
+ The <b>Presenter</b> understands how the data is to be presented and how the user will interact with that data. It
+ knows that there are buttons, check boxes, text fields, etc. It knows that sometimes the buttons need to be
+ disabled (grayed), and it knows sometimes text fields are not editable. It knows, at a mechanical level, how the
+ data are displayed and how the interactions take place. However, it does not know anything about the actual GUI
+ API. For example, if you are writing a Java Swing GUI, the Presenter does not use any of the swing classes. Rather,
+ it sends messages to the View to take care of the actual display and interaction. Thus, the Presenter can be
+ tested, again, based solely on its inputs from the Model and its outputs to the View.<br />
+ </li>
+ <li>
+ The <b>View</b> understands the GUI API. It makes no policy, selection, or validation decisions. It has virtually
+ zero intelligence. It is simply a shim that ties the interface used by the Presenter to the GUI API. It can be
+ tested by writing tests that check the wiring. The tests walk through the GUI data structures, making sure that the
+ appropriate button, text fields, and check boxes have been created. The tests send events to the GUI widgets and
+ make sure the appropriate callbacks are invoked.
+ </li>
+</ul>
+<h3>
+ <a id="Embedded" name="Embedded">How do I test embedded systems?</a>
+</h3>
+<p>
+ Some software is written to control hardware. You can test this software by writing a hardware simulator. The tests set
+ the hardware simulator up into various states and then drive the system to manipulate that hardware. Finally, the tests
+ query the simulation to ensure that the hardware was driven to the correct final state.
+</p>
+<h3>
+ <a id="Concurrency" name="Concurrency">How do I test concurrency?</a>
+</h3>
+<p>
+ Some software is reentrant or concurrent. Race conditions can make the software behavior non-deterministic. There are
+ failure modes that can be both severe and strongly dependent upon timing and order of events. Software that works
+ 99.999% of the time can fail that last .001% of the time due to concurrency problems. Finding these problems is a
+ challenge.
+</p>
+<p>
+ Usually exhaustive Monte Carlo testing is used to attempt to drive the system through as many states as possible.
+</p>
+<p>
+ Once concurrency problems are discovered, tests can be written that drive the system to the failure state and then
+ prove the failure. Thereafter, the problem can be repaired, and the test remains in the test suite as a regression
+ test.
+</p>
+<h3>
+ <a id="Database" name="Database">How do I test database transactions?</a>
+</h3>
+<p>
+ Almost always the best way to do this is to create an interface that represents the database. Each test case can
+ implement that interface and pretend to be the database, supplying its own data and interpreting the calls made by the
+ module under test. This prevents test data from actually being written and read from the database. It also allows the
+ test code to force failure conditions that are otherwise hard to simulate.
+</p>
+<p>
+ See: <a href="http://c2.com/cgi/wiki?MockObject%20" target="_blank">http://c2.com/cgi/wiki?MockObject</a>
+</p>
+<h3>
+ <a id="Servlets" name="Servlets">How do I test Servlets?</a>
+</h3>
+<p>
+ Servlets are simply pipes through which form data passes into a program and HTML passes out. The trick to testing a
+ servlet is to separate the program from the pipe. Keep the servlet code as thin as possible. Put your program in plain
+ old classes that don't derive from Servlet. Then you can test those plain old classes as usual. If the servlet itself
+ is thin enough, it may be too simple to bother testing.
+</p>
+<p>
+ Of course, you can also set up your own little servlet invoker or use one of the open source versions. These programs
+ act like a web server and fire servlets for you. You pass the form data to them, and they pass the HTML back to you.
+</p>
+<p>
+ See:
+</p>
+<blockquote>
+ <a href="http://c2.com/cgi/wiki?JunitServlet" target="_blank">http://c2.com/cgi/wiki?JunitServlet</a><br />
+ <a href="http://c2.com/cgi/wiki?ServletTesting" target="_blank">http://c2.com/cgi/wiki?ServletTesting</a><br />
+ <a href="http://strutstestcase.sourceforge.net/" target="_blank">http://strutstestcase.sourceforge.net/</a>
+</blockquote>
+<h3>
+ <a id="WebPages" name="WebPages">How do I test web pages?</a>
+</h3>
+<p>
+ An HTML document is almost an XML document. There is a tool that allows you to query an HTML document as though it were
+ an XML document. That tool is called HTTPUnit. Using this tool, you can write tests that inspect the innards of an HTML
+ document without worrying about white space or formatting issues. Another tool called HTMLUnit also does something
+ similar. HTMLUnit includes support for testing HTML pages with embedded JavaScript.
+</p>
+<p>
+ See:
+</p>
+<blockquote>
+ <a href="http://httpunit.sourceforge.net/" target="_blank">http://httpunit.sourceforge.net/</a><br />
+ <a href="http://htmlunit.sourceforge.net/" target="_blank">http://htmlunit.sourceforge.net/</a><br />
+</blockquote>
+<p>
+ <br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi
new file mode 100644
index 0000000..f506c50
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi
@@ -0,0 +1,1751 @@
+<?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" epf:version="1.0.0" xmi:id="-FX8hDYUKOXsrQulFe9lwtw" name="test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305" guid="-FX8hDYUKOXsrQulFe9lwtw" changeDate="2006-11-21T15:55:18.633-0800" version="1.0.0">
+ <mainDescription><a id="XE_test__developer_testing__test_ideas__for_booleans_and_boundaries"
+name="XE_test__developer_testing__test_ideas__for_booleans_and_boundaries"></a><a
+id="XE_test-ideas__for_booleans_and_boundaries" name="XE_test-ideas__for_booleans_and_boundaries"></a><a
+id="XE_design__developer_testing__test_ideas__for_booleans_and_boundaries"
+name="XE_design__developer_testing__test_ideas__for_booleans_and_boundaries"></a>
+<h3>
+ <a id="Introduction" name="Introduction"></a>Introduction
+</h3>
+<p>
+ Test ideas are based on <a href="./../../../glossary/glossary.htm#fault_model" target="_blank">fault models</a>,
+ notions of which faults are plausible in software and how those faults can best be uncovered. This guideline shows how
+ to create test ideas from boolean and relational expressions. It first motivates the techniques by looking at code,
+ then describes how to apply them if the code hasn't been written yet or is otherwise unavailable.
+</p>
+<h3>
+ <a id="BooleanExpressions" name="BooleanExpressions"></a><b>Boolean Expressions</b>
+</h3>
+<p>
+ Consider the following code snippet, taken from an (imaginary) system for managing bomb detonation. It's part of the
+ safety system and controls whether the "detonate bomb" button push is obeyed.
+</p>
+<blockquote>
+<pre>
+if (publicIsClear || technicianClear) {
+ bomb.detonate();
+}
+</pre>
+</blockquote>
+<p>
+ The code is wrong. The <font size="+0">||</font> should be an <font size="+0">&amp;&amp;</font>. That mistake will have
+ bad effects. Instead of detonating the bomb when both the bomb technician and public are clear, the system will
+ detonate when <i>either</i> is clear.
+</p>
+<p>
+ What test would find this bug?
+</p>
+<p>
+ Consider a test in which the button is pushed when both the technician and public are clear. The code will allow the
+ bomb to be detonated. But-and this is important-the <i>correct</i> code (the one that uses an <font
+ size="+0">&amp;&amp;</font>) would do the same. So the test is useless at finding this fault.
+</p>
+<p>
+ Similarly, this incorrect code behaves correctly when both the technician and public are next to the bomb: the bomb is
+ not detonated.
+</p>
+<p>
+ To find the bug, you have to have a case in which the code as written evaluates differently than the code that should
+ have been written. For example, the public must be clear, but the bomb technician is still next to the bomb. Here are
+ all the tests in table form:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="20%">
+ <p align="center">
+ publicIsClear
+ </p>
+ </th>
+ <th scope="col" width="20%">
+ <p align="center">
+ technicianClear
+ </p>
+ </th>
+ <th scope="col" width="20%">
+ <p align="center">
+ Code as written...
+ </p>
+ </th>
+ <th scope="col" width="20%">
+ <p align="center">
+ Correct code would have...
+ </p>
+ </th>
+ <th width="20%">
+ &nbsp;
+ </th>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">detonates</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ test is useless (for this fault)
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">detonates</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">not detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ useful test
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">detonates</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#ff0000">not detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ useful test
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">does not detonate</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ <font color="#008000">not detonated</font>
+ </p>
+ </td>
+ <td width="20%">
+ <p align="center">
+ test is useless (for this fault)
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The two middle tests are both useful for finding this particular fault. Note, however, that they're redundant: since
+ either will find the fault, you needn't run both.
+</p>
+<p>
+ There are other ways in which the expression might be wrong. Here are two lists of common mistakes in boolean
+ expressions. The faults on the left are all caught by the technique discussed here. The faults on the right might not
+ be. So this technique doesn't catch all the faults we might like, but it's still useful.
+</p>
+<div align="right">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="50%">
+ <p align="center">
+ <b>Faults detected</b>
+ </p>
+ </th>
+ <th scope="col" width="50%">
+ <p align="center">
+ <b>Faults possibly not detected</b>
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="50%">
+ Using wrong operator: a <font color="#ff0000"><b>||</b></font> b should be a<font
+ color="#ff0000"><b>&amp;&amp;</b></font>b
+ </td>
+ <td width="50%">
+ Wrong variable used: a&amp;&amp;<font color="#ff0000"><b>b</b></font>&amp;&amp;c should be a&amp;&amp;
+ <font color="#ff0000"><b>x</b></font>&amp;&amp;d
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ Negation is omitted or incorrect: a||b should be <font color="#ff0000"><b>!</b></font>a||b, or <font
+ color="#ff0000"><b>!</b></font> a||b should be a||b
+ </td>
+ <td width="50%">
+ Expression is too simple: a&amp;&amp;b should be a&amp;&amp;b<font
+ color="#ff0000"><b>&amp;&amp;c</b></font>
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ The expression is misparenthesized: a&amp;&amp;b||c should be a&amp;&amp;<font
+ color="#ff0000"><b>(</b></font>b||c<font color="#ff0000"><b>)</b></font>
+ </td>
+ <td width="50%">
+ Expressions with more than one of the faults in the left column
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ The expression is overly complex: a&amp;&amp;b<b>&amp;&amp;c</b> should be <font
+ size="+0">a&amp;&amp;b<br />
+ </font> (This fault is not so likely, but is easy to find with tests useful for other reasons.)
+ </td>
+ <td width="50%">
+ &nbsp;
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ How are these ideas used? Suppose you're given a boolean expression like <font size="+0">a&amp;&amp;!b</font>. You
+ could construct a truth table like this one:
+</p>
+<div align="right">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="100%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="14%">
+ <p align="center">
+ a
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ b
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ a&amp;&amp;!b<br />
+ (code as written)
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ maybe it should be<br />
+ a<font color="#ff0000"><b>||</b></font>!b
+ </p>
+ </th>
+ <th scope="col" width="14%">
+ <p align="center">
+ maybe it should be<br />
+ <font color="#ff0000"><b>!</b></font>a&amp;&amp;!b
+ </p>
+ </th>
+ <th scope="col" width="15%">
+ <p align="center">
+ maybe it should be<br />
+ a&amp;&amp;b
+ </p>
+ </th>
+ <th scope="col" width="15%">
+ <p align="center">
+ ...
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">false</font>
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="14%">
+ <p align="center">
+ <font color="#ff0000">true</font>
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="15%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If you crunched through all the possibilities, you'd find that the first, second, and fourth possibilities are all
+ that's needed. The third expression will find no faults that won't be found by one of the others, so you needn't try
+ it. (As the expressions grow more complicated, the savings due to unneeded cases grow quickly.)
+</p>
+<p>
+ Of course, no one sane would build such a table. Fortunately, you don't have to. It's easy to memorize the required
+ cases for simple expressions. (See the next section.) For more complex expressions, such as <font
+ size="+0">A&amp;&amp;B||C</font>, see <a href="../../examples/extrnlcntrbtns/test/tstatmtch.htm" target="_blank">Test
+ Ideas for Mixtures of ANDs and ORs</a>, which lists test ideas for expressions with two or three operators. For even
+ more complex expressions, a <a href="http://www.testing.com/tools/multi/README.html" target="_blank">program</a> can be
+ used to generate test ideas.
+</p>
+<h3>
+ <a id="SimpleExpressionTables" name="SimpleExpressionTables"></a><b>Tables for Simple Boolean Expressions</b>
+</h3>
+<p>
+ If the expression is <font size="+0">A&amp;&amp;B</font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="50%">
+ <p align="center">
+ A
+ </p>
+ </th>
+ <th scope="col" width="50%">
+ <p align="center">
+ B
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is <font size="+0">A||B</font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="50%">
+ <p align="center">
+ A
+ </p>
+ </th>
+ <th scope="col" width="50%">
+ <p align="center">
+ B
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="50%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is <font size="+0">A<sub>1</sub> &amp;&amp; A<sub>2</sub> &amp;&amp; ... &amp;&amp;
+ A<sub>n</sub></font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1,</sub> A<sub>2</sub>, ..., and A<sub>n</sub> are all true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1</sub> is false, all the rest are true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>2</sub> is false, all the rest are true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>n</sub> is false, all the rest are true
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p align="left">
+ If the expression is <font size="+0">A<sub>1</sub> || A<sub>2</sub> || ... || A<sub>n</sub></font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1,</sub> A<sub>2</sub>, ..., and A<sub>n</sub> are all false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>1</sub> is true, all the rest are false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>2</sub> is true, all the rest are false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ ...
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A<sub>n</sub> is true, all the rest are false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is <font size="+0">A</font>, test with:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ So, when you need to test <font size="+0">a&amp;&amp;!b</font>, you can apply the first table above, invert the sense
+ of b (because it's negated), and get this list of <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html" guid="8.834380241450745E-306">Test
+ Ideas</a>:
+</p>
+<ul>
+ <li>
+ A true, B false
+ </li>
+ <li>
+ A true, B true
+ </li>
+ <li>
+ A false, B false
+ </li>
+</ul>
+<h3>
+ <a id="RelationalExpressions" name="RelationalExpressions"></a><b>Relational Expressions</b>
+</h3>
+<p align="left">
+ Here's another example of code with a fault:
+</p>
+<blockquote>
+<pre>
+if (finished &lt; required) {
+ siren.sound();
+}
+</pre>
+</blockquote>
+<p align="left">
+ The <font size="+0">&lt;</font> should be a <font size="+0">&lt;=</font>. Such mistakes are fairly common. As with
+ boolean expressions, you can construct a table of test values and see which ones detect the fault:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ finished
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ required
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ code as written...
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ the correct code would have...
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ 1
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ sounds the siren
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ sounded the siren
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ <font color="#ff0000">does not sound the siren</font>
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ <font color="#ff0000">sounded the siren</font>
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ 5
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ 1
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ does not sound the siren
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ not sounded the siren
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ More generally, the fault can be detected whenever <font size="+0">finished=required</font>. From analyses of plausible
+ faults, we can get these rules for test ideas:
+</p>
+<p>
+ If the expression is A&lt;B or A&gt;=B, test with
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A=B
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A slightly less than B
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ If the expression is A&gt;B or A&lt;=B, test with
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A=B
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="100%">
+ <p align="center">
+ A slightly larger than B
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ What does "slightly" mean? If A and B are integers, A should be one less than or larger than B. If they are floating
+ point numbers, A should be a number quite close to B. (It's probably not necessary that it be the the closest floating
+ point number to B.)
+</p>
+<h3>
+ <a id="CombinedExpressions" name="CombinedExpressions"></a><b>Rules for Combined Boolean and Relational Expressions</b>
+</h3>
+<p>
+ Most relational operators occur within boolean expressions, as in this example:
+</p>
+<blockquote>
+<pre>
+if (finished &lt; required) {
+ siren.sound();
+}
+</pre>
+</blockquote>
+<p>
+ The rules for relational expressions would lead to these test ideas:
+</p>
+<ol>
+ <li>
+ <font size="+0">finished</font> is equal to required
+ </li>
+ <li>
+ <font size="+0">finished</font> is slightly less than <font size="+0">required</font>
+ </li>
+</ol>
+<p>
+ The rules for boolean expressions would lead to these:
+</p>
+<ol>
+ <li>
+ <font size="+0">finished &lt; required</font> should be true
+ </li>
+ <li>
+ <font size="+0">finished &lt; required</font> should be false
+ </li>
+</ol>
+<p>
+ But if <font size="+0">finished</font> is slightly less than <font size="+0">required</font>, <font size="+0">finished
+ &lt; required</font> is true, so there's no point in writing down the latter.
+</p>
+<p>
+ And if <font size="+0">finished</font> equals <font size="+0">required</font>, <font size="+0">finished &lt;
+ required</font> is false, so there's no point in writing down that latter one either.
+</p>
+<p>
+ So, <b>if a relational expression contains no boolean operators (<font size="+0">&amp;&amp;</font> and <font
+ size="+0">||</font>), ignore the fact that it's also a boolean expression.</b>
+</p>
+<p>
+ Things are a bit more complicated with combinations of boolean and relational operators, like this one:
+</p>
+<blockquote>
+<pre>
+if (count&lt;5 || always) {
+ siren.sound();
+}
+</pre>
+</blockquote>
+<p>
+ From the relational expression, you get:
+</p>
+<ul>
+ <li>
+ <font size="+0">count</font> slightly less than 5
+ </li>
+ <li>
+ <font size="+0">count</font> equal to 5
+ </li>
+</ul>
+<p>
+ From the boolean expression, you get:
+</p>
+<ul>
+ <li>
+ <font size="+0">count&lt;5</font> true, always false
+ </li>
+ <li>
+ <font size="+0">count&lt;5</font> false, always true
+ </li>
+ <li>
+ <font size="+0">count&lt;5</font> false, always false
+ </li>
+</ul>
+<p>
+ These can be combined into three more specific test ideas. (Here, note that <font size="+0">count</font> is an
+ integer.)
+</p>
+<ol>
+ <li>
+ <font size="+0">count=4</font>, always false
+ </li>
+ <li>
+ <font size="+0">count=5</font>, always true
+ </li>
+ <li>
+ <font size="+0">count=5</font>, always false
+ </li>
+</ol>
+<p>
+ Notice that <font size="+0">count=5</font> is used twice. It might seem better to use it only once, to allow the use of
+ some other value-after all, why test <font size="+0">count</font> with 5 twice? Wouldn't it be better to try it once
+ with 5 and another time with some other value such that <font size="+0">count&lt;5</font> is false? It would be, but
+ it's dangerous to try. That's because it's easy to make a mistake. Suppose you tried the following:
+</p>
+<ol>
+ <li>
+ <font size="+0">count=4</font>, always false
+ </li>
+ <li>
+ <font size="+0">count=5</font>, always true
+ </li>
+ <li>
+ <font size="+0"><b>count&lt;5</b></font> <b>false</b>, <font size="+0">always</font> false
+ </li>
+</ol>
+<p>
+ Suppose that there's a fault that can <i>only</i> be caught with <font size="+0">count=5</font>. What that means is
+ that the value 5 will cause <font size="+0">count&lt;5</font> to produce false in the second test, when the correct
+ code would have produced true. However, that false value is immediately or'd with the value of always, which is true.
+ That means the value of the whole expression is correct, even though the value of the relational subexpression was
+ wrong. The fault will go undiscovered.
+</p>
+<p>
+ The fault doesn't go undiscovered if it's the <i>other</i> count=5 that is left less specific.
+</p>
+<p>
+ Similar problems happen when the relational expression is on the right-hand side of the boolean operator.
+</p>
+<p>
+ Because it's hard to know which subexpressions have to be exact and which can be general, it's best to make them all
+ exact. The alternative is to use the <a href="http://www.testing.com/tools/multi/README.html" target="_blank">boolean
+ expression program</a> mentioned above. It produces correct test ideas for arbitrary mixed boolean-and-relational
+ expressions.
+</p>
+<h3>
+ <a id="TestIdeasWithoutCode" name="TestIdeasWithoutCode"></a><b>Test ideas without Code</b>
+</h3>
+<p>
+ As explained in <a class="elementLinkWithType"
+ href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
+ guid="6.556259235358794E-306">Concept: Test-first Design</a>, it's usually preferable to design tests before
+ implementing code. So, although the techniques are motivated by code examples, they'll usually be applied without code.
+ How?
+</p>
+<p>
+ Certain design artifacts, such as statecharts and sequence diagrams, use boolean expressions as guards. Those cases are
+ straightforward-simply add the test ideas from the boolean expressions to the artifact's test idea checklist. See <a
+ class="elementLinkWithUserText"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
+ guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Activity Diagrams</a>.
+</p>
+<p>
+ The trickier case is when boolean expressions are implicit rather than explicit. That's often the case in descriptions
+ of APIs. Here's an example. Consider this method:
+</p>
+<blockquote>
+<pre>
+List matchList(Directory d1, Directory d1,
+ FilenameFilter excluder);
+</pre>
+</blockquote>
+<p>
+ The description of this method's behavior might read like this:
+</p>
+<blockquote>
+ <p>
+ Returns a List of the absolute pathnames of all files that appear in both Directories. Subdirectories are
+ descended. [...] Filenames that match the <font size="+0">excluder</font> are excluded from the returned list. The
+ excluder only applies to the top-level directories, not to filenames in subdirectories.
+ </p>
+</blockquote>
+<p>
+ The words "and" and "or" do not appear. But when is a filename included in the return list? When it appears in the
+ first directory <b>and</b> it appears in the second directory <b>and</b> it's either in a lower level directory
+ <b>or</b> it's not specifically excluded. In code:
+</p>
+<blockquote>
+<pre>
+if (appearsInFirst &amp;&amp; appearsInSecond &amp;&amp;
+ (inLowerLevel || !excluded)) {
+ add to list
+}
+</pre>
+</blockquote>
+<p>
+ Here are the test ideas for that expression, given in tabular form:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ appearsInFirst
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ appearsInSecond
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ inLower
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ excluded
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div>
+<p>
+ <br />
+ The general approach for discovering implicit boolean expressions from text is to first list the actions described
+ (such as "returns a matching name"). Then write a boolean expression that describes the cases in which an action is
+ taken. Derive test ideas from all the expressions.
+</p>
+<p>
+ There's room for disagreement in that process. For example, one person might write down the boolean expression used
+ above. Another might say that there are really two distinct actions: first, the program discovers matching names, then
+ it filters them out. So, instead of one expression, there are two:
+</p>
+<dl>
+ <dt>
+ discover a match:
+ </dt>
+ <dd>
+ happens when a file is in the first directory <b>and</b> a file with the same name is in the second directory
+ </dd>
+ <dt>
+ filter a match:
+ </dt>
+ <dd>
+ happens when the matching files are in the top level <b>and</b> the name matches the <font
+ size="+0">excluder</font>
+ </dd>
+</dl>
+<p>
+ These different approaches can lead to different test ideas and thus different tests. But the differences are most
+ likely not particularly important. That is, the time spent worrying about which expression is right, and trying
+ alternatives, would be better spent on other techniques and producing more tests. If you're curious about what the
+ sorts of differences might be, read on.
+</p>
+<p>
+ The second person would get two sets of test ideas.
+</p>
+<blockquote>
+ <p>
+ test ideas about discovering a match:
+ </p>
+ <ul>
+ <li>
+ file in first directory, file in second directory (true, true)
+ </li>
+ <li>
+ file in first directory, file not in second directory (true, false)
+ </li>
+ <li>
+ file not in first directory, file in second directory (false, true)
+ </li>
+ </ul>
+ <p>
+ test ideas about filtering a match (once one has been discovered):
+ </p>
+ <ul>
+ <li>
+ matching files are in the top level, the name matches the <font size="+0">excluder</font> (true, true)
+ </li>
+ <li>
+ matching files are in the top level, the name doesn't match the <font size="+0">excluder</font> (true, false)
+ </li>
+ <li>
+ matching files are in some lower level, the name matches the <font size="+0">excluder</font> (false, true)
+ </li>
+ </ul>
+</blockquote>
+<p>
+ Suppose those two sets of test ideas are combined. The ones in the second set only matter when the file is in both
+ directories, so they can only be combined with the first idea in the first set. That gives us the following:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in first directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in second directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ in top level
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ matches excluder
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ Two of the test ideas about discovering a match do not appear in that table. We can add them like this:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in first directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ file in second directory
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ in top level
+ </p>
+ </th>
+ <th scope="col" width="25%">
+ <p align="center">
+ matches excluder
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The blank cells indicate that the columns are irrelevant.
+</p>
+<p>
+ This table now looks rather similar to the first person's table. The similarity can be emphasized by using the same
+ terminology. The first person's table has a column called "inLower", and the second person's has one called "in top
+ level". They can be converted by flipping the sense of the values. Doing that, we get this version of the second table:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th width="25%">
+ <p align="center">
+ appearsInFirst
+ </p>
+ </th>
+ <th width="25%">
+ <p align="center">
+ appearsInSecond
+ </p>
+ </th>
+ <th width="25%">
+ <p align="center">
+ inLower
+ </p>
+ </th>
+ <th width="25%">
+ <p align="center">
+ excluded
+ </p>
+ </th>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ false
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td width="25%">
+ <p align="center">
+ true
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ false
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ true
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ -
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The first three rows are identical to the first person's table. The last two differ only in that this version doesn't
+ specify values that the first does. This amounts to an assumption about the way the code was written. The first assumed
+ a complicated boolean expression:
+</p>
+<blockquote>
+<pre>
+if (appearsInFirst &amp;&amp; appearsInSecond &amp;&amp;
+ (inLowerLevel || !excluded)) {
+ add to list
+}
+</pre>
+</blockquote>
+<p>
+ The second assumes nested boolean expressions:
+</p>
+<blockquote>
+<pre>
+if (appearsInFirst &amp;&amp; appearsInSecond) {
+ // found match.
+ if (inTopLevel &amp;&amp; excluded) {
+// filter it
+ }
+}
+</pre>
+</blockquote>
+<p>
+ The difference between the two is that the test ideas for the first detect two faults that the ideas for the second do
+ not, because those faults don't apply.
+</p>
+<ol>
+ <li>
+ In the first implementation, there can be a misparenthesization fault. Are the parentheses around the <font
+ size="+0">||</font> correct or incorrect? Since the second implementation has no <font size="+0">||</font> and no
+ parentheses, the fault cannot exist.
+ </li>
+ <li>
+ The test requirements for the first implementation check whether the second <font size="+0">&amp;&amp;</font>
+ should be an <font size="+0">||</font>. In the second implementation, that explicit <font
+ size="+0">&amp;&amp;</font> is replaced by the implicit <font size="+0">&amp;&amp;</font> of the nested <font
+ size="+0">if</font> statements. There's no <font size="+0">||</font>-for-<font size="+0">&amp;&amp;</font> fault,
+ per se. (It might be the case that the nesting is incorrect, but this technique does not address that.)<br />
+ </li>
+</ol></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_method_calls.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_method_calls.xmi
new file mode 100644
index 0000000..a02f9fd
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_method_calls.xmi
@@ -0,0 +1,582 @@
+<?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" epf:version="1.0.0" xmi:id="-nwZMQTZtIwI5weh9c_HoYA" name="test_ideas_for_method_calls,8.5657170364036E-306" guid="-nwZMQTZtIwI5weh9c_HoYA" changeDate="2006-11-21T15:58:59.045-0800" version="1.0.0">
+ <mainDescription><a id="XE_test__developer_testing__test_ideas__for_method_calls"
+name="XE_test__developer_testing__test_ideas__for_method_calls"></a><a
+id="XE_design__developer_testing__test_ideas__for_method_calls"
+name="XE_design__developer_testing__test_ideas__for_method_calls"></a><a id="XE_test-ideas__for_method_calls"
+name="XE_test-ideas__for_method_calls"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ Here's an example of defective code:
+</p>
+<blockquote>
+<pre>
+File file = new File(stringName);
+file.delete();
+</pre>
+</blockquote>
+<p>
+ The defect is that <font size="+0">File.delete</font> can fail, but the code doesn't check for that. Fixing it requires
+ the addition of the italicized code shown here:
+</p>
+<blockquote>
+<pre>
+File file = new File(stringName);
+<font color="#ff0000"><i><b>if (</b></i></font>file.delete()<font color="#ff0000"><i><b>== false) {...}</b></i></font>
+</pre>
+</blockquote>
+<p>
+ This guideline describes a method for detecting cases where your code does not handle the result of calling a method.
+ (Note that it assumes that the method called produces the correct result for whatever inputs you give it. That's
+ something that should be tested, but creating test ideas for the called method is a separate activity. That is, it's
+ not your job to test <font size="+0">File.delete</font>.)
+</p>
+<p>
+ The key notion is that you should create a test idea for each <i>distinct unhandled relevant result</i> of a method
+ call. To define that term, let's first look at <i>result</i>. When a method executes, it changes the state of the
+ world. Here are some examples:
+</p>
+<ul>
+ <li>
+ It might push return values on the runtime stack.
+ </li>
+ <li>
+ It might throw an exception.
+ </li>
+ <li>
+ It might change a global variable.
+ </li>
+ <li>
+ It might update a record in a database.
+ </li>
+ <li>
+ It might send data over the network.
+ </li>
+ <li>
+ It might print a message to standard output.
+ </li>
+</ul>
+<p>
+ Now let's look at <i>relevant</i>, again using some examples.
+</p>
+<ul>
+ <li>
+ Suppose the method being called prints a message to standard output. That "changes the state of the world", but it
+ cannot affect the further processing of this program. No matter what gets printed, even nothing at all, it can't
+ affect the execution of your code.
+ </li>
+ <li>
+ If the method returns true for success and false for failure, your program very likely should branch based on the
+ result. So that return value is relevant.
+ </li>
+ <li>
+ If the called method updates a database record that your code later reads and uses, the result (updating the
+ record) is relevant.
+ </li>
+</ul>
+<p>
+ (There's no absolute line between relevant and irrelevant. By calling <font size="+0">print</font>, your method might
+ cause buffers to be allocated, and that allocation might be relevant after <font size="+0">print</font> returns. It's
+ conceivable that a defect might depend on whether and what buffers were allocated. It's conceivable, but is it at all
+ plausible?)
+</p>
+<p>
+ A method might often have a very large number of results, but only some of them will be <i>distinct</i>. For example,
+ consider a method that writes bytes to disk. It might return a number less than zero to indicate failure; otherwise, it
+ returns the number of bytes written (which might be fewer than the number requested). The large number of possibilities
+ can be grouped into three distinct results:
+</p>
+<ul>
+ <li>
+ a number less than zero.
+ </li>
+ <li>
+ the number written equals the number requested
+ </li>
+ <li>
+ some bytes were written, but less than the number requested.
+ </li>
+</ul>
+<p>
+ All the values less than zero are grouped into one result because no reasonable program will make a distinction among
+ them. All of them (if, indeed, more than one is possible) should be treated as an error. Similarly, if the code
+ requested that 500 bytes be written, it doesn't matter if 34 were actually written or 340: the same thing will probably
+ be done with the unwritten bytes. (If something different should be done for some value, such as 0, that will form a
+ new distinct result.)
+</p>
+<p>
+ There's one last word in the defining term to explain. This particular testing technique is not concerned with distinct
+ results that are already <i>handled</i>. Consider, again, this code:
+</p>
+<blockquote>
+<pre>
+File file = new File(stringName);
+if (file.delete() == false) {...}
+</pre>
+</blockquote>
+<p>
+ There are two distinct results (true and false). The code handles them. It might handle them incorrectly, but test
+ ideas from <a class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
+ guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a> will check that. This test
+ technique is concerned with distinct results that are not specifically handled by distinct code. That might happen for
+ two reasons: you thought the distinction was irrelevant, or you simply overlooked it. Here's an example of the first
+ case:
+</p>
+<blockquote>
+<pre>
+result = m.method();
+switch (result) {
+ case FAIL:
+ case CRASH:
+ ...
+ break;
+ case DEFER:
+ ...
+ break;
+ default:
+ ...
+ break;
+}
+</pre>
+</blockquote>
+<p>
+ <font size="+0">FAIL</font> and <font size="+0">CRASH</font> are handled by the same code. It might be wise to check
+ that that's really appropriate. Here's an example of an overlooked distinction:
+</p>
+<blockquote>
+<pre>
+result = s.shutdown();
+if (result == PANIC) {
+ ...
+} else {
+ // success! Shut down the reactor.
+ ...
+}
+</pre>
+</blockquote>
+<p>
+ It turns out that shutdown can return an additional distinct result: <font size="+0">RETRY</font>. The code as written
+ treats that case the same as the success case, which is almost certainly wrong.
+</p>
+<h3>
+ <a id="FindingTestIdeas" name="FindingTestIdeas">Finding test ideas</a>
+</h3>
+<p>
+ So your goal is to think of those distinct relevant results you previously overlooked. That seems impossible: why would
+ you realize they're relevant now if you didn't earlier?
+</p>
+<p>
+ The answer is that a systematic re-examination of your code, when in a testing frame of mind and not a programming
+ frame of mind, can sometimes cause you to think new thoughts. You <i>can</i> question your own assumptions by
+ methodically stepping through your code, looking at the methods you call, rechecking their documentation, and thinking.
+ Here are some cases to watch for.
+</p>
+<h4>
+ "Impossible" cases
+</h4>
+<p>
+ Often, it will appear that error returns are impossible. Doublecheck your assumptions.
+</p>
+<p>
+ This example shows a Java implementation of a common Unix idiom for handling temporary files.
+</p>
+<blockquote>
+<pre>
+File file = new File("tempfile");
+FileOutputStream s;
+try {
+ // open the temp file.
+ s = new FileOutputStream(file);
+} catch (IOException e) {...}
+// Make sure temp file will be deleted
+file.delete();
+</pre>
+</blockquote>
+<p>
+ The goal is to make sure that a temporary file is always deleted, no matter how the program exits. You do this by
+ creating the temporary file, then immediately deleting it. On Unix, you can continue to work with the deleted file, and
+ the operating system takes care of cleaning up when the process exits. A not-painstaking Unix programmer might not
+ write the code to check for a failed deletion. Since she just successfully created the file, she must be able to delete
+ it.
+</p>
+<p>
+ This trick doesn't work on Windows. The deletion will fail because the file is open. Discovering that fact is hard: as
+ of August 2000, the Java documentation did not enumerate the situations in which <font size="+0">delete</font> could
+ fail; it merely says that it can. But-perhaps-when in "testing mode", the programmer might question her assumption.
+ Since her code is supposed to be "write once, run everywhere", she might ask a Windows programmer when <font
+ size="+0">File.delete</font> fails on Windows and so discover the awful truth.
+</p>
+<h4>
+ "Irrelevant" cases
+</h4>
+<p>
+ Another force against noticing a distinct relevant value is being already convinced that it doesn't matter. A Java
+ <font size="+0">Comparator</font>'s <font size="+0">compare</font> method returns either a number &lt;0, 0, or a number
+ &gt;0. Those are three distinct cases that might be tried. This code lumps two of them together:
+</p>
+<blockquote>
+<pre>
+void allCheck(Comparator c) {
+ ...
+ if (c.compare(o1, o2) &lt;= 0) {
+ ...
+ } else {
+ ...
+ }
+</pre>
+</blockquote>
+<p>
+ But that might be wrong. The way to discover whether it is or not is to try the two cases separately, even if you
+ really believe it will make no difference. (Your beliefs are really what you're testing.) Note that you might be
+ executing the <font size="+0">then</font> case of the <font size="+0">if</font> statement more than once for other
+ reasons. Why not try one of them with the result less than 0 and one with the result exactly equal to zero?
+</p>
+<h4>
+ Uncaught exceptions
+</h4>
+<p>
+ Exceptions are a kind of distinct result. By way of background, consider this code:
+</p>
+<blockquote>
+<pre>
+void process(Reader r) {
+ ...
+ try {
+ ...
+ int c = r.read();
+ ...
+ } catch (IOException e) {
+ ...
+ }
+}
+</pre>
+</blockquote>
+<p>
+ You'd expect to check whether the handler code really does the right thing with a read failure. But suppose an
+ exception is explicitly unhandled. Instead, it's allowed to propagate upward through the code under test. In Java, that
+ might look like this:
+</p>
+<blockquote>
+<pre>
+void process(Reader r) <font color="#ff0000"><i><b>throws IOException</b></i></font> {
+ ...
+ int c = r.read();
+ ...
+}
+</pre>
+</blockquote>
+<p>
+ This technique asks you to test that case <i>even though</i> the code explicitly doesn't handle it. Why? Because of
+ this kind of fault:
+</p>
+<blockquote>
+<pre>
+void process(Reader r) throws IOException {
+ ...
+ <font color="#ff0000"><i><b>Tracker.hold(this);</b></i></font>
+ ...
+ int c = r.read();
+ ...
+ <font color="#ff0000"><i><b>Tracker.release(this);</b></i></font>
+ ...
+}
+</pre>
+</blockquote>
+<p>
+ Here, the code affects global state (through <font size="+0">Tracker.hold</font>). If the exception is thrown, <font
+ size="+0">Tracker.release</font> will never be called.
+</p>
+<p>
+ (Notice that the failure to release will probably have no obvious immediate consequences. The problem will most likely
+ not be visible until <font size="+0">process</font> is called again, whereupon the attempt to <font
+ size="+0">hold</font> the object for a second time will fail. A good article about such defects is Keith Stobie's <a
+ href="http://www.testingcraft.com/stobie-exceptions.pdf" target="_blank">"Testing for Exceptions"</a>. &nbsp; (<a
+ href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Get Adobe Reader</a>))
+</p>
+<h3>
+ <a id="UndiscoveredFaults" name="UndiscoveredFaults">Undiscovered faults</a>
+</h3>
+<p>
+ This particular technique does not address all defects associated with method calls. Here are two kinds that it's
+ unlikely to catch.
+</p>
+<h4>
+ Incorrect arguments
+</h4>
+<p>
+ Consider these two lines of C code, where the first line is wrong and the second line is correct.
+</p>
+<blockquote>
+<pre>
+... strncmp(s1, s2, strlen(s1)) ...
+... strncmp(s1, s2, strlen(<font color="#ff0000"><i><b>s2</b></i></font>)) ...
+</pre>
+</blockquote>
+<p>
+ <font size="+0">strncmp</font> compares two strings and returns a number less than 0 if the first one is
+ lexicographically less than the second (would come earlier in a dictionary), 0 if they're equal, and a number greater
+ than 0 if the first one is lexicographically larger. However, it only compares the number of characters given by the
+ third argument. The problem is that the length of the first string is used to limit the comparison, whereas it should
+ be the length of the second.
+</p>
+<p>
+ This technique would require three tests, one for each distinct return value. Here are three you could use:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ s1
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ s2
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ expected result
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ actual result
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "a"
+ </td>
+ <td align="middle" width="25%">
+ "bbb"
+ </td>
+ <td align="middle" width="25%">
+ &lt;0
+ </td>
+ <td align="middle" width="25%">
+ &lt;0
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "bbb"
+ </td>
+ <td align="middle" width="25%">
+ "a"
+ </td>
+ <td align="middle" width="25%">
+ &gt;0
+ </td>
+ <td align="middle" width="25%">
+ &gt;0
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "foo"
+ </td>
+ <td align="middle" width="25%">
+ "foo"
+ </td>
+ <td align="middle" width="25%">
+ =0
+ </td>
+ <td align="middle" width="25%">
+ =0
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ The defect is not discovered because nothing in this technique <i>forces</i> the third argument to have any particular
+ value. What's needed is a test case like this:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>s1</b>
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>s2</b>
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>expected result</b>
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ <b>actual result</b>
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ "foo"
+ </td>
+ <td align="middle" width="25%">
+ "foo<font color="#ff0000"><i><b>d</b></i></font>"
+ </td>
+ <td align="middle" width="25%">
+ <font color="#ff0000"><i><b>&lt;0</b></i></font>
+ </td>
+ <td align="middle" width="25%">
+ =0
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ While there are techniques suitable for catching such defects, they are seldom used in practice. Your testing effort is
+ probably better spent on a rich set of tests that targets many types of defects (and that you hope catches this type as
+ a side effect).
+</p>
+<h4>
+ Indistinct results
+</h4>
+<p>
+ There's a danger that comes when you're coding - and testing - method-by-method. Here's an example. There are two
+ methods. The first, <font size="+0">connect</font>, wants to establish a network connection:
+</p>
+<blockquote>
+<pre>
+void connect() {
+ ...
+ Integer portNumber = serverPortFromUser();
+ if (portNumber == null) {
+ // pop up message about invalid port number
+ return;
+ }
+</pre>
+</blockquote>
+<p>
+ It calls <font size="+0">serverPortFromUser</font> to get a port number. That method returns two distinct values. It
+ returns a port number chosen by the user if the number chosen is valid (1000 or greater). Otherwise, it returns null.
+ If null is returned, the code under test pops up an error message and quits.
+</p>
+<p>
+ When <font size="+0">connect</font> was tested, it worked as intended: a valid port number caused a connection to be
+ established, and an invalid one led to a popup.
+</p>
+<p>
+ The code to <font size="+0">serverPortFromUser</font> is a bit more complicated. It first pops up a window that asks
+ for a string and has the standard OK and CANCEL buttons. Based on what the user does, there are four cases:
+</p>
+<ol>
+ <li>
+ If the user types a valid number, that number is returned.
+ </li>
+ <li>
+ If the number is too small (less than 1000), null is returned (so the message about invalid port number will be
+ displayed).
+ </li>
+ <li>
+ If the number is misformatted, null is again returned (and the same message is appropriate).
+ </li>
+ <li>
+ If the user clicks CANCEL, null is returned.
+ </li>
+</ol>
+<p>
+ This code also works as intended.
+</p>
+<p>
+ The combination of the two chunks of code, though, has a bad consequence: the user presses CANCEL and gets a message
+ about an invalid port number. All the code works as intended, but the overall effect is still wrong. It was tested in a
+ reasonable way, but a defect was missed.
+</p>
+<p>
+ The problem here is that <font size="+0">null</font> is one result that represents two distinct <i>meanings</i> ("bad
+ value" and "user cancelled"). Nothing in this technique forces you to notice that problem with the design of <font
+ size="+0">serverPortFromUser</font>.
+</p>
+<p>
+ Testing can help, though. When <font size="+0">serverPortFromUser</font> is tested in isolation - just to see if it
+ returns the intended value in each of those four cases - the context of use is lost. Instead, suppose it were tested
+ via <font size="+0">connect</font>. There would be four tests that would exercise both of the methods simultaneously:
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ input
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ expected result
+ </th>
+ <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
+ thought process
+ </th>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ user types "1000"
+ </td>
+ <td align="middle" width="25%">
+ connection to port 1000 is opened
+ </td>
+ <td align="middle" width="25%">
+ <font size="+0">serverPortFromUser</font> returns a number, which is used.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p align="center">
+ user types "999"
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ popup about invalid port number
+ </p>
+ </td>
+ <td>
+ <p align="center">
+ <font size="+0">serverPortFromUser</font> returns null, which leads to popup
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ <p align="center">
+ user types "i99"
+ </p>
+ </td>
+ <td align="middle" width="25%">
+ popup about invalid port number
+ </td>
+ <td align="middle" width="25%">
+ <font size="+0">serverPortFromUser</font> returns null, which leads to popup
+ </td>
+ </tr>
+ <tr>
+ <td align="middle" width="25%">
+ users clicks CANCEL
+ </td>
+ <td align="middle" width="25%">
+ whole connection process should be cancelled
+ </td>
+ <td align="middle" width="25%">
+ <font size="+0"><i>serverPortFromUser</i></font> <i>returns null, hey wait a minute that doesn't make
+ sense...</i>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ <br />
+</div>
+<p>
+ As is often the case, testing in a larger context reveals integration problems that escape small-scale testing. And, as
+ is also often the case, careful thought during test design reveals the problem before the test is run. (But if the
+ defect isn't caught then, it will be caught when the test is run.)<br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi
new file mode 100644
index 0000000..68d4dbf
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi
@@ -0,0 +1,250 @@
+<?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" epf:version="1.0.0" xmi:id="-60dp5lxFJEpUarhchGCnHw" name="test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305" guid="-60dp5lxFJEpUarhchGCnHw" version="1.0.0">
+ <mainDescription><a id="XE_state_machine__test_ideas_for" name="XE_state_machine__test_ideas_for"></a><a
+id="XE_test_idea__for_state_machine" name="XE_test_idea__for_state_machine"></a>
+<h3>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h3>
+<p>
+ This guideline shows how to identify <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestIdeas"
+ guid="8.834380241450745E-306">test ideas</a> from statecharts and other design structures that consist mainly of nodes
+ connected by arcs and that show something of the possible control flows of a program. The main goal of this testing is
+ to traverse every arc in some test. If you've never exercised an arc, why do you think it will work when a customer
+ does?
+</p>
+<h3>
+ <a id="Implementation" name="Implementation">Testing the Implementation</a>
+</h3>
+<p>
+ Consider this statechart:
+</p>
+<p align="center">
+ <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
+</p>
+<p class="picturetext">
+ Fig1: HVAC Statechart
+</p>
+<p>
+ Here's a first list of test ideas:
+</p>
+<ul>
+ <li>
+ Idle state receives Too Hot event
+ </li>
+ <li>
+ Idle state receives Too Cool event
+ </li>
+ <li>
+ Cooling/Startup state receives Compressor Running event
+ </li>
+ <li>
+ Cooling/Ready state receives Fan Running event
+ </li>
+ <li>
+ Cooling/Running state receives OK event
+ </li>
+ <li>
+ Cooling/Running state receives Failure event
+ </li>
+ <li>
+ Failure state receives Failure Cleared event
+ </li>
+ <li>
+ Heating state receives OK event
+ </li>
+ <li>
+ Heating state receives Failure event
+ </li>
+</ul>
+<p>
+ These test ideas could all be exercised in a single test, or you could create several tests that each exercise a few.
+ As with all test design, strive for a balance between the ease of implementation of many simple tests and the
+ additional defect-finding power of complex tests. (See <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestDesignUsingTheList"
+ guid="8.834380241450745E-306">"test design using the list"</a> in the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html"
+ guid="8.834380241450745E-306">Concept: Test Ideas List</a> page.) If you have use case scenarios that describe certain
+ paths through the statechart, you should favor tests that take those paths.
+</p>
+<p>
+ In any case, the tests should check that all actions required by the statechart actually take place. For example, is
+ the alarm started on entry to the Failure state, then stopped upon exit?
+</p>
+<p>
+ The test should also check that the transition leads to the correct next state. That can be a difficult problem when
+ the states are invisible from the outside. The only way to detect an incorrect state is to inject some sequence of
+ events that leads to incorrect output. More precisely, you would need to construct a follow-on sequence of events whose
+ externally-visible results for the <i>correct</i> state differ from those that the same sequence would provoke from
+ each possible <i>incorrect</i> state.
+</p>
+<p>
+ In the example above, how would you know that the Failure Cleared event in the Failure state correctly led to the Idle
+ state, instead of staying in the Failure state? You might trust that the stopping of the Alarm meant that transition
+ had been made, but it might be better to check by lowering the temperature enough to make the heater start or raising
+ it enough to turn on cooling. If something happens, you're more confident that the transition was correct. If nothing
+ happens, it's likely the device stayed in the Failure state.
+</p>
+<p>
+ At the very least, determining whether the resulting state is correct complicates test design. It is often better to
+ make the state machine explicit and make its states visible to the tests.
+</p>
+<h4>
+ Other statechart constructs
+</h4>
+<p>
+ Statecharts consist of more than arcs and arrows. Here is a list of statechart constructs and the effect they have on
+ the test idea list.
+</p>
+<h5>
+ Event actions, entry actions, and exit actions
+</h5>
+<p>
+ These do not generate test ideas per se. Rather, the tests should check that the actions behave as specified. If the
+ actions represent substantial programs, those programs must be tested. The test ideas for the programs might be
+ combined with test ideas from the statechart, but it's probably more manageable to separate them. Make the decision
+ based on the effort involved and on your suspicion that there might be interactions between events. That is, if a
+ particular action on one arc cannot possibly share data with an action on another arc, there is no reason to exercise
+ the two actions in the same test (as you would if they were part of the same path through a statechart test).
+</p>
+<h5>
+ Guard conditions
+</h5>
+<p>
+ Guard conditions are boolean expressions. The test ideas for guard conditions are derived as described in <a
+ class="elementLinkWithType"
+ href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
+ guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a>.
+</p>
+<p>
+ In the example above, the Too Cool transition from the Idle state is guarded with [restart time &gt;= 5 mins]. That
+ leads to two separate test ideas:
+</p>
+<ul>
+ <li>
+ Idle state receives Too Cool event when restart time is five minutes (transition taken)
+ </li>
+ <li>
+ Idle state receives Too Cool event when restart time is just less than five minutes (transition blocked)
+ </li>
+</ul>
+<p>
+ In both cases, any test that uses the test idea should check that the correct state is reached.
+</p>
+<h5>
+ Internal transitions
+</h5>
+<p>
+ An internal transition adds the same sort of ideas to a test idea list as an external transition does. It's merely that
+ the next state is the same as the original state. It would be prudent to set up the test such that the state's entry
+ and exit actions would cause an observable effect if they were incorrectly triggered.
+</p>
+<h5>
+ Nested states
+</h5>
+<p>
+ When constructing tests, set them up such that entry and exit events of the composite state have observable effects.
+ You want to notice if they're skipped.
+</p>
+<h5>
+ Concurrent substates
+</h5>
+<p>
+ Testing of concurrency falls outside of the scope of developer testing.
+</p>
+<h5>
+ Deferred events
+</h5>
+<p>
+ If you suspect an event might be handled differently depending on whether it was deferred and queued rather than
+ generated while the program was actually in the receiving state, you might test those two cases.
+</p>
+<p>
+ If the event in the receiving state has a guard condition, consider the ramifications of changes to the condition's
+ variables between the time the event is generated and the time it is received.
+</p>
+<p>
+ If more than one state can handle a deferred event, consider testing deferral to each of the possible receiving states.
+ Perhaps the implementation assumes that the "obvious" state will handle the event.
+</p>
+<h5>
+ History states
+</h5>
+<p>
+ Here is an example of a history state:
+</p>
+<p align="center">
+ <img height="211" alt="" src="resources/md_state3.gif" width="412" />
+</p>
+<p class="picturetext">
+ Fig2: History State Example
+</p>
+<p>
+ The transition into the history state represents three real transitions, and thus three test ideas:
+</p>
+<ul>
+ <li>
+ BackupUp event in Command state leads to Collecting state
+ </li>
+ <li>
+ BackupUp event in Command state leads to Copying state
+ </li>
+ <li>
+ BackupUp event in Command state leads to CleaningUp state
+ </li>
+</ul>
+<h5>
+ Chain states
+</h5>
+<p>
+ Chain states do not seem to have any implications for test design, except that they introduce more actions that need to
+ be checked.
+</p>
+<h3>
+ <a id="Design" name="Design">Testing the Design</a>
+</h3>
+<p>
+ The preceding discussion focuses on checking whether the implementation matches the design. But the design might also
+ be wrong. While examining the design to find test ideas, also check for two types of problems:
+</p>
+<p>
+ <b>Missing events.</b> The statechart shows a state's response to events <i>that the designer anticipated could arrive
+ in that state</i>. It's not unknown for designers to overlook events. For example, in this statechart (repeated from
+ the top of the page), perhaps the designer forgot that a failure can occur in the Ready substate of Cooling, not just
+ when the fan is Running.
+</p>
+<p align="center">
+ <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
+</p>
+<p class="picturetext">
+ Fig3: HVAC Statechart
+</p>
+<p>
+ For this reason, it's wise to ask, for each state, whether any of the events that apply to other states might apply to
+ this one. If you discover that one does, correct your design.
+</p>
+<p>
+ <b>Incomplete or missing guard conditions.</b> Similarly, perhaps guard conditions on one transition will suggest guard
+ conditions on others. For example, the above statechart takes care not to restart the heater too often, but there is no
+ such restriction on the cooling system. Should there be?
+</p>
+<p>
+ It is also possible that variables used on one guard condition will suggest that other guard conditions are too simple.
+</p>
+<h3>
+ <a id="Interactions" name="Interactions">Testing Interactions</a>
+</h3>
+<p>
+ Testing each arc in a graph is by no means complete testing. For example, suppose the start state initializes a
+ variable to 0, state Setter sets it to 5, and state Divider divides it into 100 (100/variable). If there's a path from
+ the start state to Divider that does not pass through Setter, you have a divide-by-zero exception. If the statechart
+ has many states, simply exercising each arc might miss that path.
+</p>
+<p>
+ Except for very simple statecharts, testing every path is infeasible. In practice, tests that are complex and
+ correspond to use case scenarios are often sufficient. If you desire stronger tests, consider requiring a path from
+ each state where a datum is given a value to each state that uses it.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/guidelines/xp_environment.xmi b/XP/XP_baseline_EN/library/xp/guidances/guidelines/xp_environment.xmi
new file mode 100644
index 0000000..f7d9236
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/guidelines/xp_environment.xmi
@@ -0,0 +1,114 @@
+<?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" epf:version="1.0.0" xmi:id="-OuWRQbxXBGWox8SgcCr6sQ" name="xp_environment,3.754748120034442E-307" guid="-OuWRQbxXBGWox8SgcCr6sQ" changeDate="2005-12-06T04:25:25.664-0800">
+ <mainDescription><a id="XE_xp__environment" name="XE_xp__environment"></a><a id="XE_environment__in_xp" name="XE_environment__in_xp"></a>
+<p>
+ No process is an island. In other words, you can't expect to just take a process or process elements off a shelf and
+ use them without regard to their context.
+</p>
+<p>
+ XP has certain key requirements of the "environment"; the physical, organizational, and business setting where it will
+ be applied.
+</p>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#Physical">Physical Requirements</a>
+ <ul>
+ <li>
+ <a href="#OpenWorkspace">Open Workspace</a>
+ </li>
+ <li>
+ <a href="#Toolset">Uniform Toolset</a>
+ </li>
+ <li>
+ <a href="#BuildMachine">Dedicated Build Machine</a>
+ </li>
+ <li>
+ <a href="#VersionControl">Version Control Tool</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <a href="#Org">Organizational Requirements</a>
+ </li>
+ <li>
+ <a href="#Business">Business Requirements</a>
+ </li>
+</ul>
+<h3>
+ <a id="Physical" name="Physical">Physical Requirements</a>
+</h3>
+<h4>
+ <a id="OpenWorkspace" name="OpenWorkspace">Open Workspace</a>
+</h4>
+<p>
+ One key aspect of XP is a strong focus on communication. To communicate effectively, a team should have as few physical
+ barriers to each other as possible. The ideal XP programming environment is an open workspace filled with tables and
+ room for pairs of people to work together and maintain contact with their peers. For more details, see the <a
+ class="elementLinkWithUserText" href="./../../../myxp/guidances/guidelines/open_workspace,3.269440809144354E-305.html"
+ guid="3.269440809144354E-305">open workspace guideline</a>.
+</p>
+<h4>
+ <a id="Toolset" name="Toolset">Uniform Toolset</a>
+</h4>
+<p>
+ XP works best when there are no artificial impediments to getting and giving help. If you have an open workspace with
+ five computers for production coding and each of them has a wildly different set of tools, some people will gravitate
+ to the machines that have the tools they like and feel uncomfortable moving to the machines that have unfamiliar tools.
+ Think about your own experiences. Do you feel hindered working in an unfamiliar IDE? How much does that impede you when
+ someone asks for your help. If, as a team, you adopt a uniform set of tools and keep your development machines
+ homogenous, you are making it far easier for people to give and receive help.
+</p>
+<h4>
+ <a id="BuildMachine" name="BuildMachine">Dedicated Build Machine</a>
+</h4>
+<p>
+ In XP, there are many different ways to do builds. However, the primary constraint is that all unit tests are run prior
+ to checking in any production code. In most situations, the easiest way to accomplish this is to have a dedicated build
+ machine. You can check in your code and trigger a build across the network or walk to the build machine and run the
+ build. Either way, having a dedicated machine gives you the advantage of having a common, pristine environment for your
+ builds.
+</p>
+<h4>
+ <a id="VersionControl" name="VersionControl">Version Control Tool</a>
+</h4>
+<p>
+ All software projects need version control tools; however, in XP we place a premium upon their usability. The ability
+ to be able to check out code without locking it is also valued. When a team writes pervasive unit tests and practices
+ collective code ownership, locking code for revision is often too pessimistic. It creates unncessary bottlenecks.
+</p>
+<h3>
+ <a id="Org" name="Org">Organizational Requirements</a>
+</h3>
+<p>
+ Organizations adopting XP should be able to dedicate someone to act as the customer for each XP team. The customer role
+ in XP is critical. If the person who is acting as the customer has other responsibilities, it is best if those
+ responsibilities are subordinate to being available to the rest of the team.
+</p>
+<p>
+ In addition to having an available customer, organizations practicing XP should allow teams to be self-sufficient. In
+ organizations where many functions are supported by different groups (configuration management group, deployment group,
+ QA), the different functions can impede development if there are not mechanisms to allow each team to do what it takes
+ to finalize its iterations without waiting for other teams.
+</p>
+<h3>
+ <a id="Business" name="Business">Business Requirements</a>
+</h3>
+<p>
+ XP works best in situations where organizations can take advantage of variable scope. If a business creates a fixed
+ scope contract with a fixed end date, it can be hard to discern how long it really takes for a team to sustainably
+ develop good software.
+</p>
+<p>
+ People in the organizations look at the schedule rather than the velocity data that XP produces. The result is all too
+ predictable. Software may be delivered on time, but it may also be buggy and a poor platform for future development. In
+ XP, we recognize that each team has a particular speed at which they can reliably develop software. That speed varies
+ from team to team. If a team is pushed faster than that speed, the results are often disasterous.
+</p>
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/practices/sustainable_pace.xmi b/XP/XP_baseline_EN/library/xp/guidances/practices/sustainable_pace.xmi
new file mode 100644
index 0000000..d1d5b93
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/practices/sustainable_pace.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:PracticeDescription 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" epf:version="1.0.0" xmi:id="-AS84xtg2NOXfrqA6eVRzMQ" name="new_practice,_ycm9gGZBEdqvwYzpSSc2Nw" guid="-AS84xtg2NOXfrqA6eVRzMQ" changeDate="2005-12-06T02:20:39.800-0800">
+ <mainDescription><h3>
+ Description
+</h3>
+<p>
+ The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
+ marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
+ overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
+ impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
+ causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
+ down.
+</p>
+<p>
+ Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
+ to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
+ it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
+ iteration or a release, but it should always be an exception rather than the rule.
+</p>
+<p>
+ Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
+</p>
+<h3>
+ Benefits
+</h3>
+<ul>
+ <li>
+ <b>Improved predictability</b>: plans become more accurate.
+ </li>
+ <li>
+ <b>Improved product quality</b>: programmers have the time to do the right thing.
+ </li>
+ <li>
+ <b>Improved job satisfaction</b>: programmers can enjoy their work with as little stress as possible.
+ </li>
+ <li>
+ <b>Reduced time to market</b>: less time required to fix bad code and rotting design.
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:PracticeDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/getting_started_with_xp.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/getting_started_with_xp.xmi
new file mode 100644
index 0000000..0b79c1e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/getting_started_with_xp.xmi
@@ -0,0 +1,65 @@
+<?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" epf:version="1.0.0" xmi:id="-PCk5_o83KYiPZaKUzt021A" name="getting_started_with_xp,1.2284921351651456E-304" guid="-PCk5_o83KYiPZaKUzt021A" changeDate="2006-11-08T15:14:04.387-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp__getting started_with" name="XE_xp__getting started_with"></a><a id="XE_getting started__with_xp"
+name="XE_getting started__with_xp"></a>
+<h3>
+ Topics
+</h3>
+<ul>
+ <li>
+ <a href="#WhatisXP">What is XP?</a>
+ </li>
+ <li>
+ <a href="#Start">Where do I start?</a>
+ </li>
+ <li>
+ <a href="#Providing">Providing Feedback</a>
+ </li>
+</ul>
+<h3>
+ <a id="WhatisXP" name="WhatisXP">What is XP?</a>
+</h3>
+<p>
+ Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high
+ quality software within a predictable schedule and budget and with a minimum of overhead. XP is currently one of the
+ most widely used agile processes in the industry.
+</p>
+<h3>
+ <a id="Start" name="Start">Where do I start?</a>
+</h3>
+<p>
+ If you are unfamiliar with XP and want to learn more about it, we suggest you take the following steps:
+</p>
+<ul>
+ <li>
+ Get a quick <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html"
+ guid="9.251272550276345E-306">overview of XP</a>.
+ </li>
+ <li>
+ Learn what the <a class="elementLinkWithUserText"
+ href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
+ guid="1.6390805262958034E-306">motivation behind XP</a> is.
+ </li>
+ <li>
+ Understand what <a class="elementLink"
+ href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
+ guid="1.041091673844025E-305">Agile Software Development</a> means.
+ </li>
+ <li>
+ Take a tour of the <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a> and <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>.
+ </li>
+</ul>
+<h3>
+ <a id="Providing" name="Providing">Providing Feedback</a>
+</h3>
+<p>
+ As this is the first version of the XP plug-in, we are looking to the community for advice on how to make&nbsp;it
+ better. You can help us do this by sending us your suggestions, comments, or questions to the discussions lists (see <a
+ href="http://www.eclipse.org/epf">www.eclipse.org/epf</a> for more information).
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/resources/CRsym_obj.gif b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/resources/CRsym_obj.gif
new file mode 100644
index 0000000..d1f6a31
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/resources/CRsym_obj.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_and_agile_process_references.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_and_agile_process_references.xmi
new file mode 100644
index 0000000..ead1c07
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_and_agile_process_references.xmi
@@ -0,0 +1,227 @@
+<?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" epf:version="1.0.0" xmi:id="-8UKMv929ysWDBF1IOAAgsg" name="xp_and_agile_process_references,6.191633934532389E-306" guid="-8UKMv929ysWDBF1IOAAgsg" changeDate="2006-11-29T16:47:27.124-0800" version="1.0.0">
+ <mainDescription><a id="XE_references__xp_bibliography_of" name="XE_references__xp_bibliography_of"></a>
+<div align="center">
+ <br />
+
+ <table width="100%" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="AUE01" name="AUE01">AUE01</a>
+ </td>
+ <td colspan="2">
+ Ken Auer et al. 2001. <i>Extreme Programming Applied: Playing to Win.</i> Addison-Wesley Publishing
+ Co.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Experiences from pioneers in applying XP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEC00" name="BEC00">BEC00</a>
+ </td>
+ <td colspan="2">
+ Kent Beck 2000. <i>Extreme Programming Explained</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Good introduction to the fundamental ideas of XP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BEC01" name="BEC01">BEC01</a>
+ </td>
+ <td colspan="2">
+ Kent Beck, Martin Fowler 2001. <i>Planning Extreme Programming</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Explains how to plan and manage an XP project.
+ </td>
+ </tr>
+ </tbody>
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="COC01" name="COC01">COC01</a>
+ </td>
+ <td colspan="2">
+ Alistair Cockburn 2001. <i>Agile Software Development</i> Addison-Wesley Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Peers into the team dynamics, the cultures, the communications aspects of software development.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="FOW99" name="FOW99">FOW99</a>
+ </td>
+ <td colspan="2">
+ Martin Fowler et al. 1999. <i>Refactoring: Improving the Design of Existing Code</i> Addison-Wesley
+ Publishing Co.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="JEF01" name="JEF01">JEF01</a>
+ </td>
+ <td colspan="2">
+ Ron Jeffries, Ann Anderson, and Chet Hendrickson 2001. <i>Extreme Programming Installed.</i>
+ Addison-Wesley.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ This book describes practical Extreme Programming techniques.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KER01" name="KER01">KER01</a>
+ </td>
+ <td colspan="2">
+ Norman L. Kerth, April 2001. <i>Project Retrospectives: A Handbook for Team Reviews.</i> Dorset
+ House.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ "Presents a convincing argument for the value of taking the time to study past projects and learn from
+ them [...] Kerth's sensitivity to the complex interpersonal issues surrounding project retrospectives
+ will help any facilitator, participant, or manager get the most out of these important learning
+ activities." Karl E. Wiegers, February 8, 2003.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="KRO03" name="KRO03">KRO03</a>
+ </td>
+ <td colspan="2">
+ Per Kroll and Philippe Kruchten 2003. <i>The Rational Unified Process Made Easy, A Practitioners Guide
+ to the RUP.</i> Addison Wesley Longman.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A practical guide to adopting the spirit, principles and practices of the RUP. An invaluable resource
+ in helping you decide how to apply the RUP in your organization or project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="NEW01" name="NEW01">NEW01</a>
+ </td>
+ <td colspan="2">
+ James Newkirk and Robert Martin 2001. <i>Extreme Programming in Practice.</i> Addison-Wesley Publishing
+ Co.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A report of experience using XP on a web project.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="SUC01" name="SUC01">SUC01</a>
+ </td>
+ <td colspan="2">
+ Giancarlo Succi, Michele Marchesi 2001. <i>Extreme Programming Examined.</i> Addison-Wesley Publishing
+ Co.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A collection of papers covering a wide variety of topics related to XP.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="WAK01" name="WAK01">WAK01</a>
+ </td>
+ <td colspan="2">
+ William Wake 2001. <i>Extreme Programming Explored.</i> Addison-Wesley Publishing Co.&nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ Based on the popular XPlorations website. Specific subjects are explored in detail.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ </td>
+ </tr>
+ </tbody>
+ </table>
+</div></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_artifacts.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_artifacts.xmi
new file mode 100644
index 0000000..f7bff54
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_artifacts.xmi
@@ -0,0 +1,69 @@
+<?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" epf:version="1.0.0" xmi:id="-O3LVBobhzFRt-5bytDkqqQ" name="xp_artifacts,1.545655831828372E-305" guid="-O3LVBobhzFRt-5bytDkqqQ" changeDate="2006-11-29T16:45:12.644-0800" version="1.0.0">
+ <mainDescription><a id="XE_artifact__overview_of_all_xp_artifacts" name="XE_artifact__overview_of_all_xp_artifacts"></a>
+<p>
+ In the spirit of simplicity, one of the basic <a class="elementLink"
+ href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a>, the number of artifacts in XP is fairly small. Actually, in XP we don't really talk about artifacts as
+ such. Except for the production code, all other artifacts generated by the process imply work that is tangential to
+ getting to the end goal, a running product. In theory, everything else should be considered as optional. The set of
+ artifacts presented&nbsp;here is commonly used by XP teams to deliver software in an efficient manner. As a rule, try
+ to limit the amount of effort put on any tangential work unless it can be proved to improve the process in some
+ demonstrable way.
+</p>
+<p>
+ The XP artifacts are:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_vision,{2300FB25-7249-4481-A1BD-978240906832}.html"
+ guid="{2300FB25-7249-4481-A1BD-978240906832}">Vision</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_user_story,{21946731-4F5C-4862-8B4D-868629952B92}.html"
+ guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_customer_test,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}.html"
+ guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">Customer Test</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_release_plan,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}.html"
+ guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">Release Plan</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_metaphor,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}.html"
+ guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">Metaphor (System of Names)</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_iteration_plan,{DC18E34B-70C1-403D-84CC-1BF117A7473D}.html"
+ guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">Iteration Plan</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_coding_standard,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}.html"
+ guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">Coding Standard</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_unit_test,{D156652E-7C52-4EBD-8F23-F38169877A57}.html"
+ guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">Unit Test</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_production_code,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}.html"
+ guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a>
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
+ guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">Build</a>
+ </li>
+</ul></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_copyright.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_copyright.xmi
new file mode 100644
index 0000000..c9c9c7e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_copyright.xmi
@@ -0,0 +1,8 @@
+<?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" epf:version="1.0.0" xmi:id="-31JQsY6FjFegmq-JJZdndg" name=",_XI5PQHEPEdug-a-RuUM3Hg" guid="-31JQsY6FjFegmq-JJZdndg" changeDate="2006-11-10T15:05:13.550-0800">
+ <mainDescription>Copyright (c) 2002, 2006 IBM Corporation and Object Mentor. All rights reserved. <br />
+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 <a href="http://www.eclipse.org/legal/epl-v10.html"
+target="_blank">http://www.eclipse.org/legal/epl-v10.html</a>. <br />
+Contributors: IBM Corporation and Object Mentor - initial implementation<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_customer_team.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_customer_team.xmi
new file mode 100644
index 0000000..01bcd67
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_customer_team.xmi
@@ -0,0 +1,16 @@
+<?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" epf:version="1.0.0" xmi:id="-mZMamrTcnR6xoZgvw9XU-A" name="xp_customer_team,2.9889538140050517E-306" guid="-mZMamrTcnR6xoZgvw9XU-A" changeDate="2005-12-06T02:43:10.832-0800">
+ <mainDescription><p>
+ The customer team provides the requirements, sets the priorities and steers the project. The customer team can be made
+ up of one or more business representatives from different parts of the organization. If there is more than one
+ representative, it is important that the customer team speak to the developers in one voice ("The Customer") in order
+ to keep communication focused. It is best if the customer team includes a real end user who knows the domain and what
+ is needed. There may be a manager, providing resources, handling external communication and coordinating activities.
+ The team may include testers, who help the customer define the customer acceptance tests. Analysts may also help to
+ define the requirements.
+</p>
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_developer_team.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_developer_team.xmi
new file mode 100644
index 0000000..dc97e3c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_developer_team.xmi
@@ -0,0 +1,11 @@
+<?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" epf:version="1.0.0" xmi:id="-_11Y5NHJcC5lkqB4CeSpbg" name="xp_developer_team,8.608243854485154E-306" guid="-_11Y5NHJcC5lkqB4CeSpbg" changeDate="2005-12-06T02:43:06.686-0800">
+ <mainDescription><p>
+ The developer team writes the software that will meet the customer's needs. The team consists of programmers, and
+ commonly a coach, who helps the team stay on track and facilitates the process.
+</p>
+<p>
+ <br />
+ <br />
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_organization.xmi b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_organization.xmi
new file mode 100644
index 0000000..a8a5898
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/supportingmaterials/xp_organization.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="-2nINowSo0VedqZTd4LIZIg" name="xp_organization,5.613949040902463E-308" guid="-2nINowSo0VedqZTd4LIZIg" changeDate="2005-12-06T03:12:10.223-0800">
+ <mainDescription><p>
+ On all but the smallest of projects, the people involved in a software project will be part of one or more entities
+ (businesses, functional groups, governments, communities, etc.). The <a class="elementLink"
+ href="./../../../myxp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a> focus on the roles directly involved in identifying what the software needs to do (<a class="elementLink"
+ href="./../../../myxp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
+ guid="2.9889538140050517E-306">XP Customer Team</a>) and developing that software (<a class="elementLink"
+ href="./../../../myxp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
+ guid="8.608243854485154E-306">XP Developer Team</a>). To support those teams, the <a class="elementLink"
+ href="./../../../myxp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole
+ Team</a> includes a third important group, the XP Organization.
+</p>
+<p>
+ The specific roles that XP identifies as part of the XP Organization are the XP Tracker and the XP Coach. The XP
+ Organization also includes all of the people who make up the infrastructure that allows the project to exist. This
+ includes management, accounting, support, facilities, etc. Because these are supporting roles, XP attempts to minimize
+ the dependence of the XP Customer Team and the XP Developer Team on the XP Organization. In XP, the goal is for the
+ whole team to be self-managing and largely self-supporting. XP does not give specific practice guidance to these other
+ roles, but does suggest that these roles also guide their practices with the <a class="elementLink"
+ href="./../../../myxp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
+ Values</a> of communication, simplicity, feedback, and courage.
+</p>
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/whitepapers/refactoring.xmi b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/refactoring.xmi
new file mode 100644
index 0000000..c3268ae
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/refactoring.xmi
@@ -0,0 +1,25 @@
+<?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" epf:version="1.0.0" xmi:id="-ql_2w28A9SIIZQca3Wg-kQ" name="refactoring,1.0713784560673905E-305" guid="-ql_2w28A9SIIZQca3Wg-kQ" changeDate="2006-11-10T15:40:03.134-0800" version="1.0.0">
+ <mainDescription><address>
+ By&nbsp;Michael Feathers.
+</address>
+<address>
+ All Rights Reserved.
+</address>
+<p>
+ A&nbsp;<a href="resources/refactoring.pdf" target="_blank">PDFversion</a> of this article is available; however, you
+ must have <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to
+ view it.
+</p>
+<h3>
+ Abstract
+</h3>
+<p>
+ This paper addresses refactoring from the context of starting with legacy code, as opposed to so called "green field"
+ development. Topics covered include: Test Coverings; Inflection Points; Breaking External and Internal Dependencies.
+</p>
+<p>
+ <br />
+ &nbsp;
+</p></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/refactoring.pdf b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/refactoring.pdf
new file mode 100644
index 0000000..a627aed
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/refactoring.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/xppair.pdf b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/xppair.pdf
new file mode 100644
index 0000000..fe0eb9f
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/xppair.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/xprefact.pdf b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/xprefact.pdf
new file mode 100644
index 0000000..187c9b1
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/resources/xprefact.pdf
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/guidances/whitepapers/xp_guidelines_pair_programming.xmi b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/xp_guidelines_pair_programming.xmi
new file mode 100644
index 0000000..94ce18c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/xp_guidelines_pair_programming.xmi
@@ -0,0 +1,24 @@
+<?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" epf:version="1.0.0" xmi:id="-Ymu8T1hQ_QoxCaNAQhD9AA" name="rup_xp_guidelines_pair_programming,7.290386721197834E-306" guid="-Ymu8T1hQ_QoxCaNAQhD9AA" changeDate="2006-11-29T15:10:56.067-0800" version="1.0.0">
+ <mainDescription><a id="XE_XP__Pair_Programming" name="XE_XP__Pair_Programming"></a>
+<address>
+ By Robert C. Martin<br />
+ Object Mentor, Inc.<br />
+ <a href="http://www.objectmentor.com" target="_blank">www.objectmentor.com</a>
+</address>
+All Rights Reserved.&nbsp;
+<p>
+ A <a href="resources/xppair.pdf" target="_blank">PDF version</a> of this article is available, however, you must have
+ <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to view it.
+</p>
+<h3>
+ Abstract
+</h3>
+<p>
+ Pair programming is a well-tested, well accepted alternative to code reviews. More than that, it's a fundamentally
+ different way to write software. The benefits go far beyond productivity and quality, and affect such things as the
+ robustness and morale of the team.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi
new file mode 100644
index 0000000..866b1c2
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi
@@ -0,0 +1,26 @@
+<?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" epf:version="1.0.0" xmi:id="-_AgYWcSlbVBZOVcQfJuBnQ" name="xp_guidelines_test-first_design_and_refactoring,6.334658646686929E-306" guid="-_AgYWcSlbVBZOVcQfJuBnQ" changeDate="2006-11-29T15:11:30.669-0800" version="1.0.0">
+ <mainDescription><a id="XE_XP__Test-first_Design_and_Refactoring" name="XE_XP__Test-first_Design_and_Refactoring"></a>
+<address>
+ By Robert C. Martin<br />
+ Object Mentor, Inc.<br />
+ <a href="http://www.objectmentor.com" target="_blank">www.objectmentor.com</a>
+</address>
+<p>
+ All Rights Reserved.
+</p>
+<p>
+ A <a href="resources/xprefact.pdf" target="_blank">PDF version</a> of this article is available, however, you must have
+ <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to view it.
+</p>
+<h3>
+ Abstract&nbsp;
+</h3>
+<p>
+ This paper demonstrates the techniques of refactoring in the presence of test-first design and conveys a programming
+ attitude. A program is not done when it works; a program is done when it works <i>and</i> when it's as simple and clean
+ as possible.
+</p>
+<br />
+<br /></mainDescription>
+</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/XP_baseline_EN/library/xp/plugin.xmi b/XP/XP_baseline_EN/library/xp/plugin.xmi
new file mode 100644
index 0000000..afc849c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/plugin.xmi
@@ -0,0 +1,451 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
+ <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_TOlmEGMyEdqsrK7eslBiiA" guid="_TOlmEGMyEdqsrK7eslBiiA">
+ <resourceDescriptors xmi:id="_TOlmEWMyEdqsrK7eslBiiA" id="-MqIvi7DInwjz8kX7QEyU3g" uri="customcategories/getting_started.xmi"/>
+ <resourceDescriptors xmi:id="_TPioUGMyEdqsrK7eslBiiA" id="-hZ1cvRhigpDb6WbQckPWcA" uri="customcategories/key_xp_concepts.xmi"/>
+ <resourceDescriptors xmi:id="_TPou8GMyEdqsrK7eslBiiA" id="-LVHbtWMGC3pAL9abD018MA" uri="customcategories/xp_best_practices.xmi"/>
+ <resourceDescriptors xmi:id="_TQBJcGMyEdqsrK7eslBiiA" id="-QcM1bn-XJLcMSggRp54YlQ" uri="customcategories/conceptual_road_maps.xmi"/>
+ <resourceDescriptors xmi:id="_TQHQEGMyEdqsrK7eslBiiA" id="-8FSBtYSGN9EGWRr1N6fbPQ" uri="customcategories/guidelines_overview.xmi"/>
+ <resourceDescriptors xmi:id="_TQNWsGMyEdqsrK7eslBiiA" id="-_GqtAEsGnq12qQmyqWdHHQ" uri="customcategories/xp_white_papers.xmi"/>
+ <resourceDescriptors xmi:id="_TQNWsWMyEdqsrK7eslBiiA" id="-a8huB5Sn0Qjfe-SkZubH1w" uri="customcategories/references.xmi"/>
+ <resourceDescriptors xmi:id="_Teo0QGMyEdqsrK7eslBiiA" id="-c5D4uYtVcDvab8GzkO0HiQ" uri="customcategories/xp_roles_and_tasks.xmi"/>
+ <resourceDescriptors xmi:id="_TgcyIGMyEdqsrK7eslBiiA" id="-W67fNE0rT1c2PM-20yXbrw" uri="tasks/develop_xp_vision.xmi"/>
+ <resourceDescriptors xmi:id="_Tgo_YGMyEdqsrK7eslBiiA" id="-ZUxMgSWqLlaO5p1r1-ug6Q" uri="workproducts/xp_vision.xmi"/>
+ <resourceDescriptors xmi:id="_TgvGAGMyEdqsrK7eslBiiA" id="-U8NScY6mORb4XPcNZ_mrEA" uri="guidances/concepts/refactoring_xp_programming.xmi"/>
+ <resourceDescriptors xmi:id="_Tg1MoGMyEdqsrK7eslBiiA" id="--qg2qc3dqmgeB63Nx7Zndg" uri="guidances/concepts/coding_standard.xmi"/>
+ <resourceDescriptors xmi:id="_Tg7TQGMyEdqsrK7eslBiiA" id="-n52TyFa7Reb3LOJV1JMpvg" uri="guidances/concepts/pair_programming.xmi"/>
+ <resourceDescriptors xmi:id="_ThBZ4GMyEdqsrK7eslBiiA" id="-ql_2w28A9SIIZQca3Wg-kQ" uri="guidances/whitepapers/refactoring.xmi"/>
+ <resourceDescriptors xmi:id="_Th-cIGMyEdqsrK7eslBiiA" id="-qIbMRqe8wqKN2-HLtNUcLw" uri="tasks/define_coding_standard.xmi"/>
+ <resourceDescriptors xmi:id="_Th-cIWMyEdqsrK7eslBiiA" id="-9EbmL3qGJ_TemB83cJublQ" uri="tasks/estimate_task.xmi"/>
+ <resourceDescriptors xmi:id="_TiEiwGMyEdqsrK7eslBiiA" id="-DbsgXRUjLhsnnpioGI2b3g" uri="tasks/implement_spike.xmi"/>
+ <resourceDescriptors xmi:id="_TiQwAGMyEdqsrK7eslBiiA" id="-IoT5LZUu3vnNFp-pwPUMHA" uri="tasks/refactor_code.xmi"/>
+ <resourceDescriptors xmi:id="_TiW2oGMyEdqsrK7eslBiiA" id="-dbA7zKOJY5WPZyLXErA9vw" uri="guidances/guidelines/refactoring.xmi"/>
+ <resourceDescriptors xmi:id="_Ti1XwGMyEdqsrK7eslBiiA" id="-nfbUMyTTqEbCp3HDn-NjOA" uri="guidances/guidelines/pair_programming.xmi"/>
+ <resourceDescriptors xmi:id="_TjHroGMyEdqsrK7eslBiiA" id="-NznKylxa2Y_MG8lACUV9Bw" uri="workproducts/xp_coding_standard.xmi"/>
+ <resourceDescriptors xmi:id="_TjNyQGMyEdqsrK7eslBiiA" id="-HkQclhewSbkFSomo1l_LBg" uri="guidances/examples/test-ideas_catalog_examples.xmi"/>
+ <resourceDescriptors xmi:id="_TjT44GMyEdqsrK7eslBiiA" id="-0rSxLFlmQfyKrgnqi1NKrg" uri="guidances/concepts/simple_design.xmi"/>
+ <resourceDescriptors xmi:id="_TjZ_gGMyEdqsrK7eslBiiA" id="-2OU2wQP_WNWX5zzWzx4ANw" uri="guidances/concepts/metaphor_system_of_names.xmi"/>
+ <resourceDescriptors xmi:id="_TjgGIGMyEdqsrK7eslBiiA" id="-umDp1nFYrMetgnJ-kUMhHw" uri="tasks/breakdown_story.xmi"/>
+ <resourceDescriptors xmi:id="_Tj-nQGMyEdqsrK7eslBiiA" id="-Z9xFd9JTnJuNN5S27p06UQ" uri="tasks/estimate_user_story.xmi"/>
+ <resourceDescriptors xmi:id="_TkEt4GMyEdqsrK7eslBiiA" id="-sQUFozEqR3Gpa5PnCjFh9Q" uri="workproducts/xp_metaphor.xmi"/>
+ <resourceDescriptors xmi:id="_TkK0gGMyEdqsrK7eslBiiA" id="-35rZhRLEVuTVI4280ncN0A" uri="guidances/concepts/continuous_integration.xmi"/>
+ <resourceDescriptors xmi:id="_TkQ7IGMyEdqsrK7eslBiiA" id="--tP2hgRfEkZPGYvy1y0GZQ" uri="tasks/integrate_system.xmi"/>
+ <resourceDescriptors xmi:id="_TkXBwGMyEdqsrK7eslBiiA" id="-rphHqeONv59sqZq_6FzE6Q" uri="workproducts/xp_build.xmi"/>
+ <resourceDescriptors xmi:id="_TkdIYGMyEdqsrK7eslBiiA" id="-oW2j2l-rXqHeWPIgjPpbng" uri="guidances/concepts/customer_tests.xmi"/>
+ <resourceDescriptors xmi:id="_TkjPAGMyEdqsrK7eslBiiA" id="-nGaswirSOYturOoUWwGdRw" uri="guidances/concepts/product_quality.xmi"/>
+ <resourceDescriptors xmi:id="_TkpVoGMyEdqsrK7eslBiiA" id="-3i1jvKMUGGmAYPw4dHFbEg" uri="guidances/concepts/test-ideas_list.xmi"/>
+ <resourceDescriptors xmi:id="_Tk7pgGMyEdqsrK7eslBiiA" id="-WgE0oiE2yddCOMnfzL25Gw" uri="tasks/define_customer_test.xmi"/>
+ <resourceDescriptors xmi:id="_TlCXMGMyEdqsrK7eslBiiA" id="-c7t_eJuo1g5hpWTYTCItig" uri="guidances/guidelines/equivalence_class_analysis.xmi"/>
+ <resourceDescriptors xmi:id="_TlOkcGMyEdqsrK7eslBiiA" id="-p0GGwGNG5O8Dn6O6ZzivIw" uri="tasks/report_acceptance_test_result.xmi"/>
+ <resourceDescriptors xmi:id="_TlUrEGMyEdqsrK7eslBiiA" id="-KfsuH9i0hVMlGV7PVIa3FQ" uri="roles/xp_tester.xmi"/>
+ <resourceDescriptors xmi:id="_TokMUGMyEdqsrK7eslBiiA" id="-fm-gBePbdl_WMsE5NxEreQ" uri="tasks/automate_acceptance_test.xmi"/>
+ <resourceDescriptors xmi:id="_ToqS8GMyEdqsrK7eslBiiA" id="-6RyabSc-ZUEtoEKb90BCbg" uri="tasks/run_acceptance_test.xmi"/>
+ <resourceDescriptors xmi:id="_TowZkGMyEdqsrK7eslBiiA" id="-OPKuXnenD910fJyGKA99aw" uri="tasks/setup_tester_environment.xmi"/>
+ <resourceDescriptors xmi:id="_To2gMGMyEdqsrK7eslBiiA" id="-YYMUwBepQ28JU78LtraO3w" uri="workproducts/xp_customer_test.xmi"/>
+ <resourceDescriptors xmi:id="_To8m0GMyEdqsrK7eslBiiA" id="-gAMIwaLmqX7bf6GLCqwB-g" uri="roles/xp_coach.xmi"/>
+ <resourceDescriptors xmi:id="_TpCtcGMyEdqsrK7eslBiiA" id="-DoLoZOTPa_LacQ3jUG_lsg" uri="guidances/concepts/xp_sustainable_pace.xmi"/>
+ <resourceDescriptors xmi:id="_TpI0EGMyEdqsrK7eslBiiA" id="-u-Svthjtn1xLK2IwVUpk5Q" uri="tasks/adapt_and_improve_process.xmi"/>
+ <resourceDescriptors xmi:id="_TpO6sGMyEdqsrK7eslBiiA" id="-I3yOxhkbTu3OCbzQ0sUsyA" uri="tasks/explain_process.xmi"/>
+ <resourceDescriptors xmi:id="_TpVBUGMyEdqsrK7eslBiiA" id="-32JWpciwfc2e7HgQavJDkw" uri="tasks/improve_team_skills.xmi"/>
+ <resourceDescriptors xmi:id="_TpbH8GMyEdqsrK7eslBiiA" id="-SH3UFVsPViLT3hOalbaxgA" uri="tasks/keep_process_on_track.xmi"/>
+ <resourceDescriptors xmi:id="_TphOkGMyEdqsrK7eslBiiA" id="-L85wOCiwe2O8D8CISEGGGg" uri="tasks/resolve_conflicts.xmi"/>
+ <resourceDescriptors xmi:id="_TpnVMGMyEdqsrK7eslBiiA" id="-FIhk4OEzZl2IAVMXurpBLA" uri="roles/xp_tracker.xmi"/>
+ <resourceDescriptors xmi:id="_Tptb0GMyEdqsrK7eslBiiA" id="-FxF90KOknQ5km30pP0038w" uri="tasks/track_story_completion.xmi"/>
+ <resourceDescriptors xmi:id="_TpzicGMyEdqsrK7eslBiiA" id="-0iRnQW0M9QDTNqWNijBB5A" uri="tasks/track_task_completion.xmi"/>
+ <resourceDescriptors xmi:id="_Tp5pEGMyEdqsrK7eslBiiA" id="-vcCn_ksJo5Jw27aNZb1Cvw" uri="guidances/concepts/small_releases.xmi"/>
+ <resourceDescriptors xmi:id="_Tp_vsGMyEdqsrK7eslBiiA" id="-7gEOFFavlkSqwIoTNrvfJA" uri="tasks/define_release_plan.xmi"/>
+ <resourceDescriptors xmi:id="_TqF2UGMyEdqsrK7eslBiiA" id="-85F1Tegv16godTFTKyPdww" uri="guidances/guidelines/planning_game.xmi"/>
+ <resourceDescriptors xmi:id="_TqSDkGMyEdqsrK7eslBiiA" id="-WOPGmKUuYbvVeVHp0sgEgw" uri="tasks/report_project_status.xmi"/>
+ <resourceDescriptors xmi:id="_TqYKMGMyEdqsrK7eslBiiA" id="-cU3MzukpGPAtw0wSS23R-g" uri="tasks/update_iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_TqeQ0GMyEdqsrK7eslBiiA" id="-YO16TebjP7U0gkcYg7OY_A" uri="tasks/update_release_plan.xmi"/>
+ <resourceDescriptors xmi:id="_TqkXcGMyEdqsrK7eslBiiA" id="-mMZ9KUhiFwBbzSFjq_tO4A" uri="workproducts/xp_release_plan.xmi"/>
+ <resourceDescriptors xmi:id="_TqqeEGMyEdqsrK7eslBiiA" id="-23MZj6vLVbgbkXaptH4riQ" uri="roles/xp_system_administrator.xmi"/>
+ <resourceDescriptors xmi:id="_TqwksGMyEdqsrK7eslBiiA" id="-1rVEQRCvrcicCdhpuuIZ8w" uri="tasks/setup_programmer_environment.xmi"/>
+ <resourceDescriptors xmi:id="_Tq8x8GMyEdqsrK7eslBiiA" id="-OuWRQbxXBGWox8SgcCr6sQ" uri="guidances/guidelines/xp_environment.xmi"/>
+ <resourceDescriptors xmi:id="_TrC4kGMyEdqsrK7eslBiiA" id="-92rjXjWhll5LOtPc58YERg" uri="roles/xp_customer.xmi"/>
+ <resourceDescriptors xmi:id="_TsAh4GMyEdqsrK7eslBiiA" id="-CPHs6R59_druVDY6nRjHEw" uri="guidances/concepts/planning_game.xmi"/>
+ <resourceDescriptors xmi:id="_TsGogGMyEdqsrK7eslBiiA" id="-BWG5zUGb8c25kuLJ3ck8ng" uri="tasks/define_iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_TsMvIGMyEdqsrK7eslBiiA" id="-cqTu_uwmZrF3sFspx465XQ" uri="tasks/write_user_story.xmi"/>
+ <resourceDescriptors xmi:id="_TsS1wGMyEdqsrK7eslBiiA" id="-45BLJONIjGn7h4z87VXqHQ" uri="workproducts/xp_iteration_plan.xmi"/>
+ <resourceDescriptors xmi:id="_TslJoGMyEdqsrK7eslBiiA" id="-f1cDEBpC5wbDTQ9ru9UbLw" uri="workproducts/xp_production_code.xmi"/>
+ <resourceDescriptors xmi:id="_TsrQQGMyEdqsrK7eslBiiA" id="-YP0i7TC6QNgemddcj1iE7g" uri="guidances/concepts/collective_ownership.xmi"/>
+ <resourceDescriptors xmi:id="_TsxW4GMyEdqsrK7eslBiiA" id="-yaD6WKGdrZ0n0yBSpwPr4g" uri="guidances/concepts/test_driven_development.xmi"/>
+ <resourceDescriptors xmi:id="_Ts3dgGMyEdqsrK7eslBiiA" id="-RoFHDUeLz4UFKDuFirQp3g" uri="roles/xp_programmer.xmi"/>
+ <resourceDescriptors xmi:id="_Ts9kIGMyEdqsrK7eslBiiA" id="-aJBLg1aguP1bIWvQbJSd6w" uri="guidances/concepts/developer_testing.xmi"/>
+ <resourceDescriptors xmi:id="_TtV-oGMyEdqsrK7eslBiiA" id="-3AbfvnHrCOIQS63sEjrOew" uri="guidances/concepts/test-first_design.xmi"/>
+ <resourceDescriptors xmi:id="_TtiL4GMyEdqsrK7eslBiiA" id="-OrjIrRLW6v_XnqLUQ9GYaQ" uri="guidances/concepts/test-ideas_catalog.xmi"/>
+ <resourceDescriptors xmi:id="_Tt6mYGMyEdqsrK7eslBiiA" id="-Ymu8T1hQ_QoxCaNAQhD9AA" uri="guidances/whitepapers/xp_guidelines_pair_programming.xmi"/>
+ <resourceDescriptors xmi:id="_TuAtAGMyEdqsrK7eslBiiA" id="-_AgYWcSlbVBZOVcQfJuBnQ" uri="guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi"/>
+ <resourceDescriptors xmi:id="_TuGzoGMyEdqsrK7eslBiiA" id="-kNZQ2Mr_nyfmCboprjMNTg" uri="tasks/write_code.xmi"/>
+ <resourceDescriptors xmi:id="_TuM6QGMyEdqsrK7eslBiiA" id="-jc10ie6UDWUJzSDfsQExjw" uri="guidances/guidelines/test_driven_development_tdd.xmi"/>
+ <resourceDescriptors xmi:id="_TurbYGMyEdqsrK7eslBiiA" id="-nwZMQTZtIwI5weh9c_HoYA" uri="guidances/guidelines/test_ideas_for_method_calls.xmi"/>
+ <resourceDescriptors xmi:id="_TvD14GMyEdqsrK7eslBiiA" id="-60dp5lxFJEpUarhchGCnHw" uri="guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi"/>
+ <resourceDescriptors xmi:id="_TvQDIGMyEdqsrK7eslBiiA" id="-FX8hDYUKOXsrQulFe9lwtw" uri="guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi"/>
+ <resourceDescriptors xmi:id="_TxcbgGMyEdqsrK7eslBiiA" id="-rtY57MTVQrEcfTKwD3-Wvw" uri="workproducts/xp_user_story.xmi"/>
+ <resourceDescriptors xmi:id="_TxiiIGMyEdqsrK7eslBiiA" id="-dwfXb2dWJOQkTuLo-BTFeQ" uri="workproducts/xp_unit_test.xmi"/>
+ <resourceDescriptors xmi:id="_Tx68oGMyEdqsrK7eslBiiA" id="-PCk5_o83KYiPZaKUzt021A" uri="guidances/supportingmaterials/getting_started_with_xp.xmi"/>
+ <resourceDescriptors xmi:id="_TyBDQGMyEdqsrK7eslBiiA" id="-nO38_JQ9G3FQvNlAT5Agqg" uri="guidances/concepts/what_is_xp.xmi"/>
+ <resourceDescriptors xmi:id="_TyNQgGMyEdqsrK7eslBiiA" id="-nIpFvBhY9WogqrEQv4NknQ" uri="guidances/concepts/motivation.xmi"/>
+ <resourceDescriptors xmi:id="_TyT-MGMyEdqsrK7eslBiiA" id="-EHSlFv7Gla5oCPGBiaZKow" uri="guidances/concepts/agile_software_development.xmi"/>
+ <resourceDescriptors xmi:id="_TygLcGMyEdqsrK7eslBiiA" id="-pA6XLJKgRiwDTEp_qMlQ9g" uri="guidances/concepts/xp_values.xmi"/>
+ <resourceDescriptors xmi:id="_TymSEGMyEdqsrK7eslBiiA" id="-24MPC2FhJbx7Fr0F6QEq8A" uri="guidances/concepts/xp_practices.xmi"/>
+ <resourceDescriptors xmi:id="_TysYsGMyEdqsrK7eslBiiA" id="-vEvfeoyYAPDr-jfyX2QLww" uri="guidances/concepts/xp_rights.xmi"/>
+ <resourceDescriptors xmi:id="_TzK50GMyEdqsrK7eslBiiA" id="-27sE-swoOUGtar9a0f3RPw" uri="guidances/concepts/extreme_programming.xmi"/>
+ <resourceDescriptors xmi:id="_TzXHEGMyEdqsrK7eslBiiA" id="-mq7aEjHjqWoRd6aWFK_Dwg" uri="guidances/guidelines/open_workspace.xmi"/>
+ <resourceDescriptors xmi:id="_TzdNsGMyEdqsrK7eslBiiA" id="-8UKMv929ysWDBF1IOAAgsg" uri="guidances/supportingmaterials/xp_and_agile_process_references.xmi"/>
+ <resourceDescriptors xmi:id="_T0mdMGMyEdqsrK7eslBiiA" id="-_11Y5NHJcC5lkqB4CeSpbg" uri="guidances/supportingmaterials/xp_developer_team.xmi"/>
+ <resourceDescriptors xmi:id="_T0sj0GMyEdqsrK7eslBiiA" id="-mZMamrTcnR6xoZgvw9XU-A" uri="guidances/supportingmaterials/xp_customer_team.xmi"/>
+ <resourceDescriptors xmi:id="_T0yqcGMyEdqsrK7eslBiiA" id="-O3LVBobhzFRt-5bytDkqqQ" uri="guidances/supportingmaterials/xp_artifacts.xmi"/>
+ <resourceDescriptors xmi:id="_GkS58GZBEdqvwYzpSSc2Nw" id="-uqrgrFY-74R1FijPLvcXoQ" uri="guidances/concepts/whole_team.xmi"/>
+ <resourceDescriptors xmi:id="_MhXf4GZCEdqvwYzpSSc2Nw" id="-AS84xtg2NOXfrqA6eVRzMQ" uri="guidances/practices/sustainable_pace.xmi"/>
+ <resourceDescriptors xmi:id="_7IA_sGZHEdqvwYzpSSc2Nw" id="-2nINowSo0VedqZTd4LIZIg" uri="guidances/supportingmaterials/xp_organization.xmi"/>
+ <resourceDescriptors xmi:id="_-s6MEHEPEdug-a-RuUM3Hg" id="-31JQsY6FjFegmq-JJZdndg" uri="guidances/supportingmaterials/xp_copyright.xmi"/>
+ </org.eclipse.epf.uma.resourcemanager:ResourceManager>
+ <org.eclipse.epf.uma:MethodPlugin xmi:id="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" name="xp" guid="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" changeDate="2006-11-08T14:45:47.271-0800" copyrightStatement="_XI5PQHEPEdug-a-RuUM3Hg">
+ <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6QGE-EdqnIZeW8YpHcA" name="Content" guid="_mhU6QGE-EdqnIZeW8YpHcA">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6QWE-EdqnIZeW8YpHcA" name="Categories" guid="_mhU6QWE-EdqnIZeW8YpHcA">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6QmE-EdqnIZeW8YpHcA" name="Domains" guid="_mhU6QmE-EdqnIZeW8YpHcA"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6Q2E-EdqnIZeW8YpHcA" name="Disciplines" guid="_mhU6Q2E-EdqnIZeW8YpHcA"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6RGE-EdqnIZeW8YpHcA" name="RoleSets" guid="_mhU6RGE-EdqnIZeW8YpHcA">
+ <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_13azwGNdEdqsrK7eslBiiA" name="xp_roles" guid="_13azwGNdEdqsrK7eslBiiA" presentationName="XP Roles" roles="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6} {3C90DD4F-CFDB-4111-922D-3B840B8942DE} {08A6AF28-69B1-42DC-A957-2E6CDCB436C1} {0CB3C507-AFEE-4DA8-982B-9B93C8729910} {D8FE277E-4F9A-47EB-855F-C451D601BBAF} {FB65D00B-8304-4CF7-9969-52CE82F503DC}"/>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6RWE-EdqnIZeW8YpHcA" name="WP Types" guid="_mhU6RWE-EdqnIZeW8YpHcA"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6RmE-EdqnIZeW8YpHcA" name="Tools" guid="_mhU6RmE-EdqnIZeW8YpHcA"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6R2E-EdqnIZeW8YpHcA" name="StandardCategories" guid="_mhU6R2E-EdqnIZeW8YpHcA"/>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6SGE-EdqnIZeW8YpHcA" name="CustomCategories" guid="_mhU6SGE-EdqnIZeW8YpHcA" reusedPackages="_ms9igWE-EdqnIZeW8YpHcA _mhU6SGE-EdqnIZeW8YpHcA {45A887AB-A968-48AF-8213-4D470DA9DBCC} {90FB58E1-B403-4358-85D0-BD902528D810} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} {8367713C-3AEA-489D-B136-DB87D6340A3F} {DBE91BD5-0065-4049-AA61-058C77F1D2A3} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6SWE-EdqnIZeW8YpHcA" name="Hidden" guid="_mhU6SWE-EdqnIZeW8YpHcA" reusedPackages="_mhU6SGE-EdqnIZeW8YpHcA">
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mhU6SmE-EdqnIZeW8YpHcA" name="Custom Categories" guid="_mhU6SmE-EdqnIZeW8YpHcA" categorizedElements="_ms9ig2E-EdqnIZeW8YpHcA _mtDpJGE-EdqnIZeW8YpHcA _mtcqtmE-EdqnIZeW8YpHcA _mtcquWE-EdqnIZeW8YpHcA _um0n8GdjEdqlnYmIxoiUEQ _8NSdoGdjEdqlnYmIxoiUEQ"/>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_ms9ig2E-EdqnIZeW8YpHcA" name="getting_started" guid="_ms9ig2E-EdqnIZeW8YpHcA" presentationName="Getting Started" variabilityType="replaces" categorizedElements="1.2284921351651456E-304 1.9093436569802954E-305 4.315031901943112E-306 2.0279775416255596E-305 6.505229665845286E-306 _8NSdoGdjEdqlnYmIxoiUEQ">
+ <presentation xmi:id="-MqIvi7DInwjz8kX7QEyU3g" href="uma://-MqIvi7DInwjz8kX7QEyU3g#-MqIvi7DInwjz8kX7QEyU3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="1.9093436569802954E-305" name="key_xp_concepts" guid="1.9093436569802954E-305" briefDescription="The following concepts are a good starting point to introduce the "spirit" of XP." presentationName="Key XP Concepts" categorizedElements="9.251272550276345E-306 1.6390805262958034E-306 1.041091673844025E-305 1.076140803519123E-306 2.2937799026801584E-305 3.036332011267074E-306">
+ <presentation xmi:id="-hZ1cvRhigpDb6WbQckPWcA" href="uma://-hZ1cvRhigpDb6WbQckPWcA#-hZ1cvRhigpDb6WbQckPWcA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="4.315031901943112E-306" name="xp_best_practices" guid="4.315031901943112E-306" presentationName="XP Best Practices" categorizedElements="3.133529870649493E-306 5.762953011420275E-306 9.300699588493279E-306 2.7371805612676613E-305 3.876855509996079E-307 1.4410217108363206E-306 1.620567348185129E-306 2.297945473205673E-305 3.193414568279561E-305 1.6109092258980447E-306 4.884861766532753E-306 8.8116853923311E-307 7.89591827591278E-306">
+ <presentation xmi:id="-LVHbtWMGC3pAL9abD018MA" href="uma://-LVHbtWMGC3pAL9abD018MA#-LVHbtWMGC3pAL9abD018MA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mtDpJGE-EdqnIZeW8YpHcA" name="conceptual_road_maps" guid="_mtDpJGE-EdqnIZeW8YpHcA" presentationName="Conceptual Roadmap" variabilityType="replaces" categorizedElements="5.2637267673584526E-306">
+ <presentation xmi:id="-QcM1bn-XJLcMSggRp54YlQ" href="uma://-QcM1bn-XJLcMSggRp54YlQ#-QcM1bn-XJLcMSggRp54YlQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="2.0279775416255596E-305" name="guidelines_overview" guid="2.0279775416255596E-305" presentationName="Guidelines Overview" categorizedElements="3.754748120034442E-307 3.269440809144354E-305 3.85153041801319E-307 8.137126904637637E-306 3.9254165491375454E-306 6.7335956461328426E-307">
+ <presentation xmi:id="-8FSBtYSGN9EGWRr1N6fbPQ" href="uma://-8FSBtYSGN9EGWRr1N6fbPQ#-8FSBtYSGN9EGWRr1N6fbPQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="6.505229665845286E-306" name="xp_white_papers" guid="6.505229665845286E-306" presentationName="XP White Papers" categorizedElements="7.290386721197834E-306 6.334658646686929E-306 1.0713784560673905E-305">
+ <presentation xmi:id="-_GqtAEsGnq12qQmyqWdHHQ" href="uma://-_GqtAEsGnq12qQmyqWdHHQ#-_GqtAEsGnq12qQmyqWdHHQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mtcqtmE-EdqnIZeW8YpHcA" name="references" guid="_mtcqtmE-EdqnIZeW8YpHcA" presentationName="References" variabilityType="replaces" categorizedElements="6.191633934532389E-306">
+ <presentation xmi:id="-a8huB5Sn0Qjfe-SkZubH1w" href="uma://-a8huB5Sn0Qjfe-SkZubH1w#-a8huB5Sn0Qjfe-SkZubH1w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mtcquWE-EdqnIZeW8YpHcA" name="xp_basic_roles_artifacts" guid="_mtcquWE-EdqnIZeW8YpHcA" presentationName="XP Roles and Artifacts" categorizedElements="3.967980776087095E-306 1.545655831828372E-305"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="3.967980776087095E-306" name="xp_roles_and_tasks" guid="3.967980776087095E-306" presentationName="XP Roles and Tasks" categorizedElements="5.613949040902463E-308">
+ <presentation xmi:id="-c5D4uYtVcDvab8GzkO0HiQ" href="uma://-c5D4uYtVcDvab8GzkO0HiQ#-c5D4uYtVcDvab8GzkO0HiQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_um0n8GdjEdqlnYmIxoiUEQ" name="overview" guid="_um0n8GdjEdqlnYmIxoiUEQ" presentationName="Overview" categorizedElements="_ms9ig2E-EdqnIZeW8YpHcA _mtDpJGE-EdqnIZeW8YpHcA _mtcqtmE-EdqnIZeW8YpHcA"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_8NSdoGdjEdqlnYmIxoiUEQ" name="xp_team" guid="_8NSdoGdjEdqlnYmIxoiUEQ" presentationName="XP Team" categorizedElements="_13azwGNdEdqsrK7eslBiiA _mtcquWE-EdqnIZeW8YpHcA"/>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6S2E-EdqnIZeW8YpHcA" name="CoreContent" guid="_mhU6S2E-EdqnIZeW8YpHcA">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{90FB58E1-B403-4358-85D0-BD902528D810}" name="xp_essentials" guid="{90FB58E1-B403-4358-85D0-BD902528D810}" briefDescription=" This component provides the essential concepts required to understand XP. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {45A887AB-A968-48AF-8213-4D470DA9DBCC} {BC57C7CE-BFA8-464F-9925-D27A7968B63C} {8367713C-3AEA-489D-B136-DB87D6340A3F} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{BC57C7CE-BFA8-464F-9925-D27A7968B63C}" name="xp_requirements" guid="{BC57C7CE-BFA8-464F-9925-D27A7968B63C}" briefDescription=" This component provides guidance for defining requirements on an XP project. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {BC57C7CE-BFA8-464F-9925-D27A7968B63C}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{A179D686-1E79-4CB0-97B5-103B4FBBBDEF}" name="xp_customer_req" guid="{A179D686-1E79-4CB0-97B5-103B4FBBBDEF}" presentationName="XP Customer (Requirements)" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" responsibleFor="{2300FB25-7249-4481-A1BD-978240906832}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" name="develop_xp_vision" guid="{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" presentationName="Define Vision" performedBy="{A179D686-1E79-4CB0-97B5-103B4FBBBDEF}" output="{2300FB25-7249-4481-A1BD-978240906832}">
+ <presentation xmi:id="-W67fNE0rT1c2PM-20yXbrw" href="uma://-W67fNE0rT1c2PM-20yXbrw#-W67fNE0rT1c2PM-20yXbrw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{2300FB25-7249-4481-A1BD-978240906832}" name="xp_vision" guid="{2300FB25-7249-4481-A1BD-978240906832}" briefDescription="Defines the stakeholder's view of the product to be developed, specified in terms of the stakeholder's key needs and features." presentationName="XP Vision" variabilityType="extends">
+ <presentation xmi:id="-ZUxMgSWqLlaO5p1r1-ug6Q" href="uma://-ZUxMgSWqLlaO5p1r1-ug6Q#-ZUxMgSWqLlaO5p1r1-ug6Q"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C}" name="xp_programming" guid="{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C}" briefDescription=" This component provides guidance for programming on XP projects. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{C587F94C-90FD-4943-A4DE-68E9B6875071}" name="xp_implementer" guid="{C587F94C-90FD-4943-A4DE-68E9B6875071}" presentationName="XP Programmer (Implementer)" variabilityType="contributes" variabilityBasedOnElement="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" conceptsAndPapers="1.4410217108363206E-306 8.8116853923311E-307 3.876855509996079E-307 1.0713784560673905E-305" responsibleFor="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.4410217108363206E-306" name="refactoring_xp_programming" guid="1.4410217108363206E-306" presentationName="Refactoring">
+ <presentation xmi:id="-U8NScY6mORb4XPcNZ_mrEA" href="uma://-U8NScY6mORb4XPcNZ_mrEA#-U8NScY6mORb4XPcNZ_mrEA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="8.8116853923311E-307" name="coding_standard" guid="8.8116853923311E-307" presentationName="Coding Standard">
+ <presentation xmi:id="--qg2qc3dqmgeB63Nx7Zndg" href="uma://--qg2qc3dqmgeB63Nx7Zndg#--qg2qc3dqmgeB63Nx7Zndg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.876855509996079E-307" name="pair_programming" guid="3.876855509996079E-307" presentationName="Pair Programming">
+ <presentation xmi:id="-n52TyFa7Reb3LOJV1JMpvg" href="uma://-n52TyFa7Reb3LOJV1JMpvg#-n52TyFa7Reb3LOJV1JMpvg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Whitepaper" xmi:id="1.0713784560673905E-305" name="refactoring" guid="1.0713784560673905E-305" presentationName="Refactoring">
+ <presentation xmi:id="-ql_2w28A9SIIZQca3Wg-kQ" href="uma://-ql_2w28A9SIIZQca3Wg-kQ#-ql_2w28A9SIIZQca3Wg-kQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" name="define_coding_standard" guid="{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" presentationName="Define Coding Standard" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}" output="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" optionalInput="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">
+ <presentation xmi:id="-qIbMRqe8wqKN2-HLtNUcLw" href="uma://-qIbMRqe8wqKN2-HLtNUcLw#-qIbMRqe8wqKN2-HLtNUcLw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{EC483990-8129-4AE3-893C-0F7406C128DA}" name="estimate_task" guid="{EC483990-8129-4AE3-893C-0F7406C128DA}" presentationName="Estimate Task" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}">
+ <presentation xmi:id="-9EbmL3qGJ_TemB83cJublQ" href="uma://-9EbmL3qGJ_TemB83cJublQ#-9EbmL3qGJ_TemB83cJublQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{85BE1C0E-F389-4246-BB22-9A52988018B7}" name="implement_spike" guid="{85BE1C0E-F389-4246-BB22-9A52988018B7}" presentationName="Implement Spike" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}" output="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} {D156652E-7C52-4EBD-8F23-F38169877A57}" optionalInput="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} {21946731-4F5C-4862-8B4D-868629952B92}">
+ <presentation xmi:id="-DbsgXRUjLhsnnpioGI2b3g" href="uma://-DbsgXRUjLhsnnpioGI2b3g#-DbsgXRUjLhsnnpioGI2b3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{3DD335BB-45F6-49C7-B17A-90652C73A485}" name="refactor_code" guid="{3DD335BB-45F6-49C7-B17A-90652C73A485}" presentationName="Refactor Code" guidelines="8.137126904637637E-306 3.85153041801319E-307" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}" mandatoryInput="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" output="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} {D156652E-7C52-4EBD-8F23-F38169877A57}" optionalInput="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} {D156652E-7C52-4EBD-8F23-F38169877A57}">
+ <presentation xmi:id="-IoT5LZUu3vnNFp-pwPUMHA" href="uma://-IoT5LZUu3vnNFp-pwPUMHA#-IoT5LZUu3vnNFp-pwPUMHA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="8.137126904637637E-306" name="refactoring" guid="8.137126904637637E-306" presentationName="Refactoring">
+ <presentation xmi:id="-dbA7zKOJY5WPZyLXErA9vw" href="uma://-dbA7zKOJY5WPZyLXErA9vw#-dbA7zKOJY5WPZyLXErA9vw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.85153041801319E-307" name="pair_programming" guid="3.85153041801319E-307" presentationName="Pair Programming">
+ <presentation xmi:id="-nfbUMyTTqEbCp3HDn-NjOA" href="uma://-nfbUMyTTqEbCp3HDn-NjOA#-nfbUMyTTqEbCp3HDn-NjOA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" name="xp_coding_standard" guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" briefDescription="Describes the conventions to be used when working with the programming language." presentationName="Coding Standard" examples="6.216049252606417E-306">
+ <presentation xmi:id="-NznKylxa2Y_MG8lACUV9Bw" href="uma://-NznKylxa2Y_MG8lACUV9Bw#-NznKylxa2Y_MG8lACUV9Bw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="6.216049252606417E-306" name="test-ideas_catalog_examples" guid="6.216049252606417E-306" briefDescription="The example is attached below." presentationName="Test-Ideas Catalog Examples">
+ <presentation xmi:id="-HkQclhewSbkFSomo1l_LBg" href="uma://-HkQclhewSbkFSomo1l_LBg#-HkQclhewSbkFSomo1l_LBg"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{796EA4CB-0038-43B8-A568-792DCC3B9F22}" name="xp_design" guid="{796EA4CB-0038-43B8-A568-792DCC3B9F22}" briefDescription=" This component provides guidance for how to design on an XP project. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" name="xp_designer" guid="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" presentationName="XP Programmer (Designer)" variabilityType="contributes" variabilityBasedOnElement="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" conceptsAndPapers="1.6109092258980447E-306 4.884861766532753E-306" responsibleFor="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.6109092258980447E-306" name="simple_design" guid="1.6109092258980447E-306" presentationName="Simple Design">
+ <presentation xmi:id="-0rSxLFlmQfyKrgnqi1NKrg" href="uma://-0rSxLFlmQfyKrgnqi1NKrg#-0rSxLFlmQfyKrgnqi1NKrg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="4.884861766532753E-306" name="metaphor_system_of_names" guid="4.884861766532753E-306" presentationName="Metaphor (System of Names)">
+ <presentation xmi:id="-2OU2wQP_WNWX5zzWzx4ANw" href="uma://-2OU2wQP_WNWX5zzWzx4ANw#-2OU2wQP_WNWX5zzWzx4ANw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{90DBD758-58B8-4383-94DD-312D349512BC}" name="breakdown_story" guid="{90DBD758-58B8-4383-94DD-312D349512BC}" presentationName="Break down Story" performedBy="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
+ <presentation xmi:id="-umDp1nFYrMetgnJ-kUMhHw" href="uma://-umDp1nFYrMetgnJ-kUMhHw#-umDp1nFYrMetgnJ-kUMhHw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{23A924D3-5989-40DD-86A9-9D8FCFB8AE52}" name="estimate_user_story" guid="{23A924D3-5989-40DD-86A9-9D8FCFB8AE52}" presentationName="Estimate User Story" performedBy="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
+ <presentation xmi:id="-Z9xFd9JTnJuNN5S27p06UQ" href="uma://-Z9xFd9JTnJuNN5S27p06UQ#-Z9xFd9JTnJuNN5S27p06UQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}" name="xp_metaphor" guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}" briefDescription="A commonly understood vocabulary describing the significant pieces of the system and their associated relationships." presentationName="Metaphor (System of Names)">
+ <presentation xmi:id="-sQUFozEqR3Gpa5PnCjFh9Q" href="uma://-sQUFozEqR3Gpa5PnCjFh9Q#-sQUFozEqR3Gpa5PnCjFh9Q"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{DBE91BD5-0065-4049-AA61-058C77F1D2A3}" name="xp_integration" guid="{DBE91BD5-0065-4049-AA61-058C77F1D2A3}" briefDescription=" This component provides guidance for integrating and building executables on XP projects. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {DBE91BD5-0065-4049-AA61-058C77F1D2A3}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{2F4BC5DA-F706-4C38-9D38-6911C7856B10}" name="xp_integrator" guid="{2F4BC5DA-F706-4C38-9D38-6911C7856B10}" presentationName="XP Programmer (Integrator)" variabilityType="contributes" variabilityBasedOnElement="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" conceptsAndPapers="3.193414568279561E-305" responsibleFor="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.193414568279561E-305" name="continuous_integration" guid="3.193414568279561E-305" presentationName="Continuous Integration">
+ <presentation xmi:id="-35rZhRLEVuTVI4280ncN0A" href="uma://-35rZhRLEVuTVI4280ncN0A#-35rZhRLEVuTVI4280ncN0A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{70FEC254-8555-4844-AD82-68367E25F082}" name="integrate_system" guid="{70FEC254-8555-4844-AD82-68367E25F082}" presentationName="Integrate and Build" performedBy="{2F4BC5DA-F706-4C38-9D38-6911C7856B10}" output="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" optionalInput="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">
+ <presentation xmi:id="--tP2hgRfEkZPGYvy1y0GZQ" href="uma://--tP2hgRfEkZPGYvy1y0GZQ#--tP2hgRfEkZPGYvy1y0GZQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" name="xp_build" guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" briefDescription="The result of the code integration and building process." presentationName="XP Build" variabilityType="extends">
+ <presentation xmi:id="-rphHqeONv59sqZq_6FzE6Q" href="uma://-rphHqeONv59sqZq_6FzE6Q#-rphHqeONv59sqZq_6FzE6Q"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{8367713C-3AEA-489D-B136-DB87D6340A3F}" name="xp_testing" guid="{8367713C-3AEA-489D-B136-DB87D6340A3F}" briefDescription=" This component provides guidance for testing on XP projects. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {8367713C-3AEA-489D-B136-DB87D6340A3F}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{9EE5F015-C409-4DD9-91AC-1A87DB833E92}" name="xp_customer_tst" guid="{9EE5F015-C409-4DD9-91AC-1A87DB833E92}" presentationName="XP Customer Test" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" conceptsAndPapers="2.297945473205673E-305 3.712584012051524E-306 8.834380241450745E-306" responsibleFor="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="2.297945473205673E-305" name="customer_tests" guid="2.297945473205673E-305" presentationName="Customer Tests">
+ <presentation xmi:id="-oW2j2l-rXqHeWPIgjPpbng" href="uma://-oW2j2l-rXqHeWPIgjPpbng#-oW2j2l-rXqHeWPIgjPpbng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.712584012051524E-306" name="product_quality" guid="3.712584012051524E-306" presentationName="Product Quality">
+ <presentation xmi:id="-nGaswirSOYturOoUWwGdRw" href="uma://-nGaswirSOYturOoUWwGdRw#-nGaswirSOYturOoUWwGdRw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="8.834380241450745E-306" name="test-ideas_list" guid="8.834380241450745E-306" presentationName="Test-Ideas List">
+ <presentation xmi:id="-3i1jvKMUGGmAYPw4dHFbEg" href="uma://-3i1jvKMUGGmAYPw4dHFbEg#-3i1jvKMUGGmAYPw4dHFbEg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{DCDB57BE-4233-4CF8-90CE-70D6808F92B0}" name="define_customer_test" guid="{DCDB57BE-4233-4CF8-90CE-70D6808F92B0}" presentationName="Define Customer Test" guidelines="1.8491691792142673E-308" performedBy="{9EE5F015-C409-4DD9-91AC-1A87DB833E92}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
+ <presentation xmi:id="-WgE0oiE2yddCOMnfzL25Gw" href="uma://-WgE0oiE2yddCOMnfzL25Gw#-WgE0oiE2yddCOMnfzL25Gw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="1.8491691792142673E-308" name="equivalence_class_analysis" guid="1.8491691792142673E-308" presentationName="Equivalence Class Analysis">
+ <presentation xmi:id="-c7t_eJuo1g5hpWTYTCItig" href="uma://-c7t_eJuo1g5hpWTYTCItig#-c7t_eJuo1g5hpWTYTCItig"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{567EE050-7E62-4B63-8761-4883FF2FFF23}" name="xp_test_analyst" guid="{567EE050-7E62-4B63-8761-4883FF2FFF23}" presentationName="XP Test Analyst" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{52D6E875-C46B-454B-A39C-CEC21603AF5C}" name="report_acceptance_test_result" guid="{52D6E875-C46B-454B-A39C-CEC21603AF5C}" presentationName="Report Customer Test Result" performedBy="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" optionalInput="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">
+ <presentation xmi:id="-p0GGwGNG5O8Dn6O6ZzivIw" href="uma://-p0GGwGNG5O8Dn6O6ZzivIw#-p0GGwGNG5O8Dn6O6ZzivIw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" name="xp_tester" guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" briefDescription="The XP Tester role helps the customer define and write acceptance tests for user stories." presentationName="XP Tester">
+ <presentation xmi:id="-KfsuH9i0hVMlGV7PVIa3FQ" href="uma://-KfsuH9i0hVMlGV7PVIa3FQ#-KfsuH9i0hVMlGV7PVIa3FQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{E614ED93-AE72-4FD1-B459-C508CE1C536F}" name="automate_acceptance_test" guid="{E614ED93-AE72-4FD1-B459-C508CE1C536F}" presentationName="Automate Customer Test" performedBy="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" output="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">
+ <presentation xmi:id="-fm-gBePbdl_WMsE5NxEreQ" href="uma://-fm-gBePbdl_WMsE5NxEreQ#-fm-gBePbdl_WMsE5NxEreQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{D4E30732-30D3-4C75-8C69-D2F15313F1A9}" name="run_acceptance_test" guid="{D4E30732-30D3-4C75-8C69-D2F15313F1A9}" presentationName="Run Customer Test" performedBy="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" optionalInput="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">
+ <presentation xmi:id="-6RyabSc-ZUEtoEKb90BCbg" href="uma://-6RyabSc-ZUEtoEKb90BCbg#-6RyabSc-ZUEtoEKb90BCbg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC}" name="setup_tester_environment" guid="{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC}" presentationName="Setup Tester Environment" performedBy="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">
+ <presentation xmi:id="-OPKuXnenD910fJyGKA99aw" href="uma://-OPKuXnenD910fJyGKA99aw#-OPKuXnenD910fJyGKA99aw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}" name="xp_customer_test" guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}" briefDescription="Run against the system to verify that a feature has been implemented properly." presentationName="XP Customer Test" variabilityType="extends">
+ <presentation xmi:id="-YYMUwBepQ28JU78LtraO3w" href="uma://-YYMUwBepQ28JU78LtraO3w#-YYMUwBepQ28JU78LtraO3w"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{45A887AB-A968-48AF-8213-4D470DA9DBCC}" name="xp_management" guid="{45A887AB-A968-48AF-8213-4D470DA9DBCC}" briefDescription=" This component provides guidance for managing XP projects. " reusedPackages="{45A887AB-A968-48AF-8213-4D470DA9DBCC} {90FB58E1-B403-4358-85D0-BD902528D810} {BC57C7CE-BFA8-464F-9925-D27A7968B63C}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}" name="xp_coach" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}" briefDescription="The XP Coach is a supporting role which helps a team stay on process and help the team learn." presentationName="XP Coach" variabilityType="extends" conceptsAndPapers="3.133529870649493E-306">
+ <presentation xmi:id="-gAMIwaLmqX7bf6GLCqwB-g" href="uma://-gAMIwaLmqX7bf6GLCqwB-g#-gAMIwaLmqX7bf6GLCqwB-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.133529870649493E-306" name="xp_sustainable_pace" guid="3.133529870649493E-306" presentationName="Sustainable Pace">
+ <presentation xmi:id="-DoLoZOTPa_LacQ3jUG_lsg" href="uma://-DoLoZOTPa_LacQ3jUG_lsg#-DoLoZOTPa_LacQ3jUG_lsg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{F0D4C205-4A38-42AF-BE87-9A6C0C173E65}" name="adapt_and_improve_process" guid="{F0D4C205-4A38-42AF-BE87-9A6C0C173E65}" presentationName="Adapt and Improve Process" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
+ <presentation xmi:id="-u-Svthjtn1xLK2IwVUpk5Q" href="uma://-u-Svthjtn1xLK2IwVUpk5Q#-u-Svthjtn1xLK2IwVUpk5Q"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727}" name="explain_process" guid="{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727}" presentationName="Explain Process" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
+ <presentation xmi:id="-I3yOxhkbTu3OCbzQ0sUsyA" href="uma://-I3yOxhkbTu3OCbzQ0sUsyA#-I3yOxhkbTu3OCbzQ0sUsyA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{1C4325AC-17DE-4CD0-8AA0-4B210570579F}" name="improve_team_skills" guid="{1C4325AC-17DE-4CD0-8AA0-4B210570579F}" presentationName="Improve Team Skills" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
+ <presentation xmi:id="-32JWpciwfc2e7HgQavJDkw" href="uma://-32JWpciwfc2e7HgQavJDkw#-32JWpciwfc2e7HgQavJDkw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{80725BC3-E2BA-4860-8F07-4A34B96FBB2A}" name="keep_process_on_track" guid="{80725BC3-E2BA-4860-8F07-4A34B96FBB2A}" presentationName="Keep Process On Track" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
+ <presentation xmi:id="-SH3UFVsPViLT3hOalbaxgA" href="uma://-SH3UFVsPViLT3hOalbaxgA#-SH3UFVsPViLT3hOalbaxgA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{1B23700D-02B0-476F-A3DE-6F63A5407151}" name="resolve_conflicts" guid="{1B23700D-02B0-476F-A3DE-6F63A5407151}" presentationName="Resolve Conflicts" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
+ <presentation xmi:id="-L85wOCiwe2O8D8CISEGGGg" href="uma://-L85wOCiwe2O8D8CISEGGGg#-L85wOCiwe2O8D8CISEGGGg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" name="xp_tracker" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" briefDescription="The XP Tracker role measures and communicates the team's progress." presentationName="XP Tracker" variabilityType="extends">
+ <presentation xmi:id="-FIhk4OEzZl2IAVMXurpBLA" href="uma://-FIhk4OEzZl2IAVMXurpBLA#-FIhk4OEzZl2IAVMXurpBLA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{C333BA32-CF6B-4577-9212-302893043EFF}" name="track_story_completion" guid="{C333BA32-CF6B-4577-9212-302893043EFF}" presentationName="Track Release Progress" performedBy="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
+ <presentation xmi:id="-FxF90KOknQ5km30pP0038w" href="uma://-FxF90KOknQ5km30pP0038w#-FxF90KOknQ5km30pP0038w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C}" name="track_task_completion" guid="{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C}" presentationName="Track Iteration Progress" performedBy="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">
+ <presentation xmi:id="-0iRnQW0M9QDTNqWNijBB5A" href="uma://-0iRnQW0M9QDTNqWNijBB5A#-0iRnQW0M9QDTNqWNijBB5A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" name="xp_customer_man" guid="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" presentationName="XP Customer (Manager)" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" conceptsAndPapers="5.762953011420275E-306" responsibleFor="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}"/>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="5.762953011420275E-306" name="small_releases" guid="5.762953011420275E-306" presentationName="Small Releases">
+ <presentation xmi:id="-vcCn_ksJo5Jw27aNZb1Cvw" href="uma://-vcCn_ksJo5Jw27aNZb1Cvw#-vcCn_ksJo5Jw27aNZb1Cvw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{D755C076-8E63-4A24-89AA-A7D64E368B90}" name="define_release_plan" guid="{D755C076-8E63-4A24-89AA-A7D64E368B90}" presentationName="Define Release" guidelines="6.7335956461328426E-307" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" output="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" optionalInput="{2300FB25-7249-4481-A1BD-978240906832}">
+ <presentation xmi:id="-7gEOFFavlkSqwIoTNrvfJA" href="uma://-7gEOFFavlkSqwIoTNrvfJA#-7gEOFFavlkSqwIoTNrvfJA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="6.7335956461328426E-307" name="planning_game" guid="6.7335956461328426E-307" presentationName="Planning Game">
+ <presentation xmi:id="-85F1Tegv16godTFTKyPdww" href="uma://-85F1Tegv16godTFTKyPdww#-85F1Tegv16godTFTKyPdww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{ED94150E-EE14-47BF-97F5-F1EC7130EEEC}" name="report_project_status" guid="{ED94150E-EE14-47BF-97F5-F1EC7130EEEC}" presentationName="Report Project Status" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}">
+ <presentation xmi:id="-WOPGmKUuYbvVeVHp0sgEgw" href="uma://-WOPGmKUuYbvVeVHp0sgEgw#-WOPGmKUuYbvVeVHp0sgEgw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC}" name="update_iteration_plan" guid="{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC}" presentationName="Adjust Iteration Scope" guidelines="6.7335956461328426E-307" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" output="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" optionalInput="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">
+ <presentation xmi:id="-cU3MzukpGPAtw0wSS23R-g" href="uma://-cU3MzukpGPAtw0wSS23R-g#-cU3MzukpGPAtw0wSS23R-g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{18BF87E6-5849-4091-AFE2-FC4F0C3887B1}" name="update_release_plan" guid="{18BF87E6-5849-4091-AFE2-FC4F0C3887B1}" presentationName="Revise Release Plan" guidelines="6.7335956461328426E-307" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" output="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" optionalInput="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">
+ <presentation xmi:id="-YO16TebjP7U0gkcYg7OY_A" href="uma://-YO16TebjP7U0gkcYg7OY_A#-YO16TebjP7U0gkcYg7OY_A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" name="xp_release_plan" guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" briefDescription="A list of prioritized user stories that will be implemented in the coming release(s)." presentationName="XP Release Plan" variabilityType="extends">
+ <presentation xmi:id="-mMZ9KUhiFwBbzSFjq_tO4A" href="uma://-mMZ9KUhiFwBbzSFjq_tO4A#-mMZ9KUhiFwBbzSFjq_tO4A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}" name="xp_system_administrator" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}" briefDescription="The XP Programmer (Administrator) is responsible for managing the programmer environment." presentationName="XP Programmer (Administrator)" variabilityType="extends">
+ <presentation xmi:id="-23MZj6vLVbgbkXaptH4riQ" href="uma://-23MZj6vLVbgbkXaptH4riQ#-23MZj6vLVbgbkXaptH4riQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{D3AA9FEE-AAD9-4884-BF71-425E122110A7}" name="setup_programmer_environment" guid="{D3AA9FEE-AAD9-4884-BF71-425E122110A7}" presentationName="Setup Programmer Environment" guidelines="3.754748120034442E-307" performedBy="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">
+ <presentation xmi:id="-1rVEQRCvrcicCdhpuuIZ8w" href="uma://-1rVEQRCvrcicCdhpuuIZ8w#-1rVEQRCvrcicCdhpuuIZ8w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.754748120034442E-307" name="xp_environment" guid="3.754748120034442E-307" presentationName="XP Environment">
+ <presentation xmi:id="-OuWRQbxXBGWox8SgcCr6sQ" href="uma://-OuWRQbxXBGWox8SgcCr6sQ#-OuWRQbxXBGWox8SgcCr6sQ"/>
+ </contentElements>
+ </childPackages>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" name="xp_customer" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" briefDescription="The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built, and making sure the product actually works." presentationName="XP Customer" conceptsAndPapers="2.7371805612676613E-305" responsibleFor="{DC18E34B-70C1-403D-84CC-1BF117A7473D} {21946731-4F5C-4862-8B4D-868629952B92}">
+ <presentation xmi:id="-92rjXjWhll5LOtPc58YERg" href="uma://-92rjXjWhll5LOtPc58YERg#-92rjXjWhll5LOtPc58YERg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="2.7371805612676613E-305" name="planning_game" guid="2.7371805612676613E-305" presentationName="Planning Game">
+ <presentation xmi:id="-CPHs6R59_druVDY6nRjHEw" href="uma://-CPHs6R59_druVDY6nRjHEw#-CPHs6R59_druVDY6nRjHEw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{849E3635-6FCD-4FAD-A007-CA34B9998622}" name="define_iteration_plan" guid="{849E3635-6FCD-4FAD-A007-CA34B9998622}" presentationName="Define Iteration" guidelines="6.7335956461328426E-307" performedBy="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" output="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" optionalInput="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">
+ <presentation xmi:id="-BWG5zUGb8c25kuLJ3ck8ng" href="uma://-BWG5zUGb8c25kuLJ3ck8ng#-BWG5zUGb8c25kuLJ3ck8ng"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{62CFC55C-3151-46CB-8886-F3DBD552ABC4}" name="write_user_story" guid="{62CFC55C-3151-46CB-8886-F3DBD552ABC4}" presentationName="Write User Story" performedBy="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" output="{21946731-4F5C-4862-8B4D-868629952B92}" optionalInput="{2300FB25-7249-4481-A1BD-978240906832}">
+ <presentation xmi:id="-cqTu_uwmZrF3sFspx465XQ" href="uma://-cqTu_uwmZrF3sFspx465XQ#-cqTu_uwmZrF3sFspx465XQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" name="xp_iteration_plan" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" briefDescription="Essentially a list of user stories and engineering tasks that will be worked on in the current iteration." presentationName="XP Iteration Plan" variabilityType="extends">
+ <presentation xmi:id="-45BLJONIjGn7h4z87VXqHQ" href="uma://-45BLJONIjGn7h4z87VXqHQ#-45BLJONIjGn7h4z87VXqHQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" name="xp_production_code" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" briefDescription="The executable specification of the system being built." presentationName="Production Code" variabilityType="extends" conceptsAndPapers="9.300699588493279E-306 1.620567348185129E-306">
+ <presentation xmi:id="-f1cDEBpC5wbDTQ9ru9UbLw" href="uma://-f1cDEBpC5wbDTQ9ru9UbLw#-f1cDEBpC5wbDTQ9ru9UbLw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="9.300699588493279E-306" name="collective_ownership" guid="9.300699588493279E-306" presentationName="Collective Ownership">
+ <presentation xmi:id="-YP0i7TC6QNgemddcj1iE7g" href="uma://-YP0i7TC6QNgemddcj1iE7g#-YP0i7TC6QNgemddcj1iE7g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.620567348185129E-306" name="test_driven_development" guid="1.620567348185129E-306" presentationName="Test Driven Development">
+ <presentation xmi:id="-yaD6WKGdrZ0n0yBSpwPr4g" href="uma://-yaD6WKGdrZ0n0yBSpwPr4g#-yaD6WKGdrZ0n0yBSpwPr4g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" name="xp_programmer" guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" briefDescription="The XP Programmer is responsible for implementing the code to support the user stories." presentationName="XP Programmer" conceptsAndPapers="1.620567348185129E-306 9.300699588493279E-306 4.085829182735815E-305 6.556259235358794E-306 8.834380241450745E-306 1.2384224477983028E-305 7.290386721197834E-306 6.334658646686929E-306" responsibleFor="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} {D156652E-7C52-4EBD-8F23-F38169877A57}">
+ <presentation xmi:id="-RoFHDUeLz4UFKDuFirQp3g" href="uma://-RoFHDUeLz4UFKDuFirQp3g#-RoFHDUeLz4UFKDuFirQp3g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="4.085829182735815E-305" name="developer_testing" guid="4.085829182735815E-305" presentationName="Developer Testing">
+ <presentation xmi:id="-aJBLg1aguP1bIWvQbJSd6w" href="uma://-aJBLg1aguP1bIWvQbJSd6w#-aJBLg1aguP1bIWvQbJSd6w"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="6.556259235358794E-306" name="test-first_design" guid="6.556259235358794E-306" presentationName="Test-first Design">
+ <presentation xmi:id="-3AbfvnHrCOIQS63sEjrOew" href="uma://-3AbfvnHrCOIQS63sEjrOew#-3AbfvnHrCOIQS63sEjrOew"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.2384224477983028E-305" name="test-ideas_catalog" guid="1.2384224477983028E-305" presentationName="Test-Ideas Catalog">
+ <presentation xmi:id="-OrjIrRLW6v_XnqLUQ9GYaQ" href="uma://-OrjIrRLW6v_XnqLUQ9GYaQ#-OrjIrRLW6v_XnqLUQ9GYaQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Whitepaper" xmi:id="7.290386721197834E-306" name="xp_guidelines_pair_programming" guid="7.290386721197834E-306" presentationName="XP Guidelines: Pair Programming">
+ <presentation xmi:id="-Ymu8T1hQ_QoxCaNAQhD9AA" href="uma://-Ymu8T1hQ_QoxCaNAQhD9AA#-Ymu8T1hQ_QoxCaNAQhD9AA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Whitepaper" xmi:id="6.334658646686929E-306" name="xp_guidelines_test-first_design_and_refactoring" guid="6.334658646686929E-306" presentationName="XP Guidelines: Test-first Design and Refactoring">
+ <presentation xmi:id="-_AgYWcSlbVBZOVcQfJuBnQ" href="uma://-_AgYWcSlbVBZOVcQfJuBnQ#-_AgYWcSlbVBZOVcQfJuBnQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{8F6CB99A-D2EA-44BB-8CE5-F97220D44088}" name="write_code" guid="{8F6CB99A-D2EA-44BB-8CE5-F97220D44088}" presentationName="Write Code" guidelines="3.9254165491375454E-306 3.85153041801319E-307 8.5657170364036E-306 1.0347051690476123E-305 1.7150344523489172E-305" examples="6.216049252606417E-306" performedBy="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" output="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" optionalInput="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED} {DC18E34B-70C1-403D-84CC-1BF117A7473D} {7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">
+ <presentation xmi:id="-kNZQ2Mr_nyfmCboprjMNTg" href="uma://-kNZQ2Mr_nyfmCboprjMNTg#-kNZQ2Mr_nyfmCboprjMNTg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.9254165491375454E-306" name="test_driven_development_tdd" guid="3.9254165491375454E-306" presentationName="Test Driven Development (TDD)">
+ <presentation xmi:id="-jc10ie6UDWUJzSDfsQExjw" href="uma://-jc10ie6UDWUJzSDfsQExjw#-jc10ie6UDWUJzSDfsQExjw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="8.5657170364036E-306" name="test_ideas_for_method_calls" guid="8.5657170364036E-306" presentationName="Test Ideas for Method Calls">
+ <presentation xmi:id="-nwZMQTZtIwI5weh9c_HoYA" href="uma://-nwZMQTZtIwI5weh9c_HoYA#-nwZMQTZtIwI5weh9c_HoYA"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="1.0347051690476123E-305" name="test_ideas_for_statechart_and_flow_diagrams" guid="1.0347051690476123E-305" presentationName="Test Ideas for Statechart and Flow Diagrams">
+ <presentation xmi:id="-60dp5lxFJEpUarhchGCnHw" href="uma://-60dp5lxFJEpUarhchGCnHw#-60dp5lxFJEpUarhchGCnHw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="1.7150344523489172E-305" name="test_ideas_for_booleans_and_boundaries" guid="1.7150344523489172E-305" presentationName="Test Ideas for Booleans and Boundaries">
+ <presentation xmi:id="-FX8hDYUKOXsrQulFe9lwtw" href="uma://-FX8hDYUKOXsrQulFe9lwtw#-FX8hDYUKOXsrQulFe9lwtw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{21946731-4F5C-4862-8B4D-868629952B92}" name="xp_user_story" guid="{21946731-4F5C-4862-8B4D-868629952B92}" briefDescription="A brief description of some functionality provided by the system from the point of view of a user of that system." presentationName="User Story" variabilityType="extends">
+ <presentation xmi:id="-rtY57MTVQrEcfTKwD3-Wvw" href="uma://-rtY57MTVQrEcfTKwD3-Wvw#-rtY57MTVQrEcfTKwD3-Wvw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{D156652E-7C52-4EBD-8F23-F38169877A57}" name="xp_unit_test" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}" briefDescription="Used to ensure that a specific functionality of a component of the system is working properly." presentationName="XP Unit Test" conceptsAndPapers="1.620567348185129E-306 4.085829182735815E-305 6.556259235358794E-306" guidelines="8.5657170364036E-306 1.0347051690476123E-305 1.7150344523489172E-305 1.8491691792142673E-308" examples="6.216049252606417E-306">
+ <presentation xmi:id="-dwfXb2dWJOQkTuLo-BTFeQ" href="uma://-dwfXb2dWJOQkTuLo-BTFeQ#-dwfXb2dWJOQkTuLo-BTFeQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Practice" xmi:id="_ycm9gGZBEdqvwYzpSSc2Nw" name="sustainable_pace" guid="_ycm9gGZBEdqvwYzpSSc2Nw" presentationName="Sustainable Pace" contentReferences="3.133529870649493E-306">
+ <presentation xmi:id="-AS84xtg2NOXfrqA6eVRzMQ" href="uma://-AS84xtg2NOXfrqA6eVRzMQ#-AS84xtg2NOXfrqA6eVRzMQ"/>
+ </contentElements>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_ms9igWE-EdqnIZeW8YpHcA" name="xp_basic_concepts" guid="_ms9igWE-EdqnIZeW8YpHcA" reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} _ms9igWE-EdqnIZeW8YpHcA {45A887AB-A968-48AF-8213-4D470DA9DBCC}">
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="9.251272550276345E-306" name="what_is_xp" guid="9.251272550276345E-306" presentationName="What is XP?">
+ <presentation xmi:id="-nO38_JQ9G3FQvNlAT5Agqg" href="uma://-nO38_JQ9G3FQvNlAT5Agqg#-nO38_JQ9G3FQvNlAT5Agqg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.6390805262958034E-306" name="motivation" guid="1.6390805262958034E-306" presentationName="motivation">
+ <presentation xmi:id="-nIpFvBhY9WogqrEQv4NknQ" href="uma://-nIpFvBhY9WogqrEQv4NknQ#-nIpFvBhY9WogqrEQv4NknQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.041091673844025E-305" name="agile_software_development" guid="1.041091673844025E-305" presentationName="Agile Software Development">
+ <presentation xmi:id="-EHSlFv7Gla5oCPGBiaZKow" href="uma://-EHSlFv7Gla5oCPGBiaZKow#-EHSlFv7Gla5oCPGBiaZKow"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.076140803519123E-306" name="xp_values" guid="1.076140803519123E-306" presentationName="XP Values">
+ <presentation xmi:id="-pA6XLJKgRiwDTEp_qMlQ9g" href="uma://-pA6XLJKgRiwDTEp_qMlQ9g#-pA6XLJKgRiwDTEp_qMlQ9g"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="2.2937799026801584E-305" name="xp_practices" guid="2.2937799026801584E-305" presentationName="XP Practices">
+ <presentation xmi:id="-24MPC2FhJbx7Fr0F6QEq8A" href="uma://-24MPC2FhJbx7Fr0F6QEq8A#-24MPC2FhJbx7Fr0F6QEq8A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.036332011267074E-306" name="xp_rights" guid="3.036332011267074E-306" presentationName="XP Rights">
+ <presentation xmi:id="-vEvfeoyYAPDr-jfyX2QLww" href="uma://-vEvfeoyYAPDr-jfyX2QLww#-vEvfeoyYAPDr-jfyX2QLww"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="5.2637267673584526E-306" name="extreme_programming" guid="5.2637267673584526E-306" presentationName="Extreme Programming">
+ <presentation xmi:id="-27sE-swoOUGtar9a0f3RPw" href="uma://-27sE-swoOUGtar9a0f3RPw#-27sE-swoOUGtar9a0f3RPw"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.269440809144354E-305" name="open_workspace" guid="3.269440809144354E-305" presentationName="Open Workspace">
+ <presentation xmi:id="-mq7aEjHjqWoRd6aWFK_Dwg" href="uma://-mq7aEjHjqWoRd6aWFK_Dwg#-mq7aEjHjqWoRd6aWFK_Dwg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="6.191633934532389E-306" name="xp_and_agile_process_references" guid="6.191633934532389E-306" presentationName="XP and Agile Process References">
+ <presentation xmi:id="-8UKMv929ysWDBF1IOAAgsg" href="uma://-8UKMv929ysWDBF1IOAAgsg#-8UKMv929ysWDBF1IOAAgsg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="8.608243854485154E-306" name="xp_developer_team" guid="8.608243854485154E-306" presentationName="XP Developer Team">
+ <presentation xmi:id="-_11Y5NHJcC5lkqB4CeSpbg" href="uma://-_11Y5NHJcC5lkqB4CeSpbg#-_11Y5NHJcC5lkqB4CeSpbg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="2.9889538140050517E-306" name="xp_customer_team" guid="2.9889538140050517E-306" presentationName="XP Customer Team">
+ <presentation xmi:id="-mZMamrTcnR6xoZgvw9XU-A" href="uma://-mZMamrTcnR6xoZgvw9XU-A#-mZMamrTcnR6xoZgvw9XU-A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="1.545655831828372E-305" name="xp_artifacts" guid="1.545655831828372E-305" presentationName="XP Artifacts">
+ <presentation xmi:id="-O3LVBobhzFRt-5bytDkqqQ" href="uma://-O3LVBobhzFRt-5bytDkqqQ#-O3LVBobhzFRt-5bytDkqqQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="7.89591827591278E-306" name="whole_team" guid="7.89591827591278E-306" presentationName="Whole Team">
+ <presentation xmi:id="-uqrgrFY-74R1FijPLvcXoQ" href="uma://-uqrgrFY-74R1FijPLvcXoQ#-uqrgrFY-74R1FijPLvcXoQ"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="5.613949040902463E-308" name="xp_organization" guid="5.613949040902463E-308" presentationName="XP Organization">
+ <presentation xmi:id="-2nINowSo0VedqZTd4LIZIg" href="uma://-2nINowSo0VedqZTd4LIZIg#-2nINowSo0VedqZTd4LIZIg"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="1.2284921351651456E-304" name="getting_started_with_xp" guid="1.2284921351651456E-304" presentationName="Getting Started with XP">
+ <presentation xmi:id="-PCk5_o83KYiPZaKUzt021A" href="uma://-PCk5_o83KYiPZaKUzt021A#-PCk5_o83KYiPZaKUzt021A"/>
+ </contentElements>
+ <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_XI5PQHEPEdug-a-RuUM3Hg" name="xp_copyright" guid="_XI5PQHEPEdug-a-RuUM3Hg" presentationName="XP Plug-in Copyright" shapeicon="xp/guidances/supportingmaterials/resources/CRsym_obj.gif" nodeicon="xp/guidances/supportingmaterials/resources/CRsym_obj.gif">
+ <presentation xmi:id="-31JQsY6FjFegmq-JJZdndg" href="uma://-31JQsY6FjFegmq-JJZdndg#-31JQsY6FjFegmq-JJZdndg"/>
+ </contentElements>
+ </childPackages>
+ </childPackages>
+ <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mhU6TGE-EdqnIZeW8YpHcA" name="CapabilityPatterns" guid="_mhU6TGE-EdqnIZeW8YpHcA"/>
+ </methodPackages>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mhU6TWE-EdqnIZeW8YpHcA" name="DeliveryProcesses" guid="_mhU6TWE-EdqnIZeW8YpHcA"/>
+ <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mhU6TmE-EdqnIZeW8YpHcA" name="ProcessContributions" guid="_mhU6TmE-EdqnIZeW8YpHcA"/>
+ </org.eclipse.epf.uma:MethodPlugin>
+</xmi:XMI>
diff --git a/XP/XP_baseline_EN/library/xp/resources/about.htm b/XP/XP_baseline_EN/library/xp/resources/about.htm
new file mode 100644
index 0000000..a867e55
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/resources/about.htm
@@ -0,0 +1,76 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<html>
+<!--
+ Copyright (c) 2002, 2006 IBM Corporation and Object Mentor.
+ 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 and Object Mentor - initial implementation
+-->
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
+ <title>About</title>
+<script src="scripts/common.js" type="text/javascript" language="JavaScript"></script>
+ <style type="text/css">
+ body {
+ margin: 8px;
+ }
+ </style>
+</head>
+
+<body>
+<img src="epf.ico" width="16" height="16" alt="about icon" border="0"/><br />
+<br />
+<span class="pop">XP Plug-in for EPF Composer<br />
+Version 0.1<br />
+<br />
+Copyright (c) 2002, 2006 IBM Corporation and Object Mentor. All rights reserved. <br>
+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 <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.
+<br>
+Contributors: IBM Corporation and Object Mentor - initial implementation</span><br />
+<br />
+ <table summary="" border="0" cellspacing="0" cellpadding="0">
+ <tr>
+ <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonbody" colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ <tr>
+ <td class="buttonbody" colspan="4" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ <tr>
+ <td class="buttonshadow"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ <tr>
+ <td class="buttonbody" colspan="2" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonbody"><a class="button" href="javascript:self.close();"><span class="buttontxt"> Close </span></a></td>
+ <td class="buttonbody" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonshadow" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ <tr>
+ <td class="buttonbody"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ <tr>
+ <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonbody"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonbody"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonshadow"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ <tr>
+ <td colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td class="buttonshadow"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ <td colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
+ </tr>
+ </table>
+
+</body>
+</html>
diff --git a/XP/XP_baseline_EN/library/xp/resources/banner.gif b/XP/XP_baseline_EN/library/xp/resources/banner.gif
new file mode 100644
index 0000000..308266d
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/resources/banner.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/resources/circleOfLife.jpg b/XP/XP_baseline_EN/library/xp/resources/circleOfLife.jpg
new file mode 100644
index 0000000..3772826
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/resources/circleOfLife.jpg
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/resources/process.gif b/XP/XP_baseline_EN/library/xp/resources/process.gif
new file mode 100644
index 0000000..8f9a085
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/resources/process.gif
Binary files differ
diff --git a/XP/XP_baseline_EN/library/xp/resources/spscreen.htm b/XP/XP_baseline_EN/library/xp/resources/spscreen.htm
new file mode 100644
index 0000000..b233aa4
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/resources/spscreen.htm
@@ -0,0 +1,34 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+
+<!-- RPW META DATA START --
+
+
+-- RPW META DATA END -->
+
+<html>
+
+<head>
+<link rel="StyleSheet" href="rop.css" type="text/css"/>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
+<title>Splash Screen</title>
+</head>
+
+<body>
+
+
+
+<p align="center"> </p>
+<h2 align="center">Please wait while the tree browser is being loaded...<br/></h2>
+<!--
+<p align="center"> </p>
+<p align="center"><img src="images/splash.gif" alt="Welcome to the Eclipse Process Framework"/></p>
+<br/>
+-->
+<br/>
+
+
+</body>
+
+</html>
diff --git a/XP/XP_baseline_EN/library/xp/roles/xp_coach.xmi b/XP/XP_baseline_EN/library/xp/roles/xp_coach.xmi
new file mode 100644
index 0000000..ea49307
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/roles/xp_coach.xmi
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-gAMIwaLmqX7bf6GLCqwB-g" name="xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}" guid="-gAMIwaLmqX7bf6GLCqwB-g" changeDate="2006-11-09T13:28:38.381-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp_coach__role_definition" name="XE_xp_coach__role_definition"></a><a id="Description" name="Description"></a>
+<p>
+ The <a class="PresentationName" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> role helps a team stay on
+ process and helps the team to learn. A coach brings an outside perspective to help a team see themselves more clearly.
+ The coach will help balance the needs of delivering the project while improving the use of the practices. A coach or
+ team of coaches supports the Customer Team, the Developer Team, and the Organization.
+</p>
+<p>
+ The decisions that coaches make should always stem from the XP values (communication, simplicity, feedback, and
+ courage) and usually move toward the XP practices. As such, familiarity with the values and practices is a
+ prerequisite. The coach must command the respect required to lead the respective teams. The coach must possess people
+ skills and be effective in influencing the actions of the teams.
+</p></mainDescription>
+ <skills><a id="Skills" name="Skills"></a>
+<p>
+ The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> uses many different techniques. The coach is a mentor,
+ working side by side with team members on their tasks. The coach is a facilitator, helping achieve more effective team
+ performance. The coach is a conduit, reinforcing communication within the team and across teams.
+</p></skills>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/XP_baseline_EN/library/xp/roles/xp_customer.xmi b/XP/XP_baseline_EN/library/xp/roles/xp_customer.xmi
new file mode 100644
index 0000000..c45f444
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/roles/xp_customer.xmi
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-92rjXjWhll5LOtPc58YERg" name="xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" guid="-92rjXjWhll5LOtPc58YERg" changeDate="2006-11-13T11:52:45.927-0800" version="1.0.0">
+ <mainDescription><a id="XE_xp_customer__role_definition" name="XE_xp_customer__role_definition"></a><a id="Description"
+name="Description"></a>
+<p>
+ The <a class="PresentationName" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">XP Customer</a> role has the
+ responsibility of defining what is the right product to build, determining the order in which features will be built
+ and making sure the product actually works.
+</p>
+<p>
+ The <a class="PresentationName" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">XP Customer</a> writes system features in
+ the form of user stories that have business value. Using the planning game, he chooses the order in which the stories
+ will be done by the development team. He also defines acceptance tests that will be run against the system to prove
+ that the system is reliable and does what is required.
+</p></mainDescription>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/XP_baseline_EN/library/xp/roles/xp_programmer.xmi b/XP/XP_baseline_EN/library/xp/roles/xp_programmer.xmi
new file mode 100644
index 0000000..d72f7c1
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/roles/xp_programmer.xmi
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-RoFHDUeLz4UFKDuFirQp3g" name="xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" guid="-RoFHDUeLz4UFKDuFirQp3g">
+ <mainDescription><a id="XE_xp_programmer__role_definition" name="XE_xp_programmer__role_definition"></a></mainDescription>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/XP_baseline_EN/library/xp/roles/xp_system_administrator.xmi b/XP/XP_baseline_EN/library/xp/roles/xp_system_administrator.xmi
new file mode 100644
index 0000000..939d820
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/roles/xp_system_administrator.xmi
@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-23MZj6vLVbgbkXaptH4riQ" name="xp_system_administrator,{0CB3C507-AFEE-4DA8-982B-9B93C8729910}" guid="-23MZj6vLVbgbkXaptH4riQ" version="1.0.0">
+ <mainDescription><a id="XE_xp_programmer_(administrator)__role_definition" name="XE_xp_programmer_(administrator)__role_definition"></a><a
+id="Description" name="Description"></a>
+<p>
+ The <a class="PresentationName" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">XP Programmer (Administrator)</a> role
+ includes most of the traditional software development technical roles, such as designer, implementer, integrator, and
+ administrator.
+</p>
+<p>
+ In the administrator role, the programmer deals with establishing the physical working environment.
+</p></mainDescription>
+ <skills><a id="Skills" name="Skills"></a>
+<p>
+ The <a class="PresentationName" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">XP Programmer (Administrator)</a> role is
+ responsible for establishing the workspace for pair programming, including removing cubicle walls, establishing line of
+ sight with the customer, and standardizing on the development tools.
+</p></skills>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/XP_baseline_EN/library/xp/roles/xp_tester.xmi b/XP/XP_baseline_EN/library/xp/roles/xp_tester.xmi
new file mode 100644
index 0000000..5f83389
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/roles/xp_tester.xmi
@@ -0,0 +1,23 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-KfsuH9i0hVMlGV7PVIa3FQ" name="xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}" guid="-KfsuH9i0hVMlGV7PVIa3FQ" version="1.0.0">
+ <mainDescription><p>
+ The primary responsibility of the XP Tester is to help the customer define and implement acceptance tests for user
+ stories. The XP Tester is also responsible for running the tests frequently and posting the results for the whole team
+ to see. As the number of tests grow, the XP Tester will likely need to create and maintain some kind of tool to make it
+ easier to define them, run them, and gather the results quickly.
+</p></mainDescription>
+ <skills><p>
+ Whereas knowledge of the applications target domain is provided by the customer, the XP Tester needs to support the
+ customer by providing:
+</p>
+<ul>
+ <li>
+ Knowledge of typical software failure conditions and the test techniques that can be employed to uncover those
+ errors.
+ </li>
+ <li>
+ Knowledge of different techniques to implement and run tests, including understanding of and experience with test
+ automation.
+ </li>
+</ul></skills>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/XP_baseline_EN/library/xp/roles/xp_tracker.xmi b/XP/XP_baseline_EN/library/xp/roles/xp_tracker.xmi
new file mode 100644
index 0000000..095f36e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/roles/xp_tracker.xmi
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:RoleDescription 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" epf:version="1.0.0" xmi:id="-FIhk4OEzZl2IAVMXurpBLA" name="xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" guid="-FIhk4OEzZl2IAVMXurpBLA" version="1.0.0">
+ <mainDescription><a id="XE_xp_tracker__role_definition" name="XE_xp_tracker__role_definition"></a><a id="Description"
+name="Description"></a>
+<p>
+ The three basic things the <a class="PresentationName" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a>
+ will track are the release plan (user stories), the iteration plan (tasks) and the acceptance tests. The tracker can
+ also keep track of other metrics, which may help in solving problems the team is having. A good <a
+ class="PresentationName" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a> has the ability to collect the
+ information without disturbing the process significantly.
+</p></mainDescription>
+</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/adapt_and_improve_process.xmi b/XP/XP_baseline_EN/library/xp/tasks/adapt_and_improve_process.xmi
new file mode 100644
index 0000000..370063c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/adapt_and_improve_process.xmi
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-u-Svthjtn1xLK2IwVUpk5Q" name="adapt_and_improve_process,{F0D4C205-4A38-42AF-BE87-9A6C0C173E65}" guid="-u-Svthjtn1xLK2IwVUpk5Q" version="1.0.0">
+ <sections xmi:id="_oNoEAGE-EdqnIZeW8YpHcA" name=" General " guid="_oNoEAGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ Teams using XP are guided by the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP Values</a>
+ through their use of the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>. The XP Practices are each best practices, but the practices also leverage the benefits of the other
+ practices to form an efficient, minimal set of practices required to deliver high quality software aligned to customer
+ needs.
+</p>
+<p>
+ In general, teams will be most effective in their use of XP if each of the practices is used as much as possible on the
+ project. In practice, this can be difficult to achieve for a number of reasons, including:
+</p>
+<ul>
+ <li>
+ Technical obstacles, such as non-OO languages and legacy code
+ </li>
+ <li>
+ Lack of skills, including basic programming skills, practice skills, domain expertise, teamwork skills
+ </li>
+ <li>
+ A complex customer environment, where a single source of prioritized stories is difficult to develop
+ </li>
+ <li>
+ Organizational obstacles, such as distributed teams, large teams, and command/control oriented cultures
+ </li>
+</ul>
+<p>
+ As the team uses XP, these obstacles affect their ability to effectively use the practices. The <a
+ class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> helps the team address how these challenges will affect
+ their use of the practices. This starts with helping the team maintain the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html#Courage"
+ guid="1.076140803519123E-306">Courage</a> to confront and remove these obstacles, clearing the way for the practices to
+ be used. In cases where the obstacles cannot be removed, the coach and the team use the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP Values</a>
+ to guide adaptation of the practices.
+</p>
+<p>
+ The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> needs to participate in communities that share best
+ practices in software development and XP. These communities will exist within large companies, in local users groups,
+ and in Internet communities.
+</p>
+<p>
+ <br />
+ <br />
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_adapt_and_improve_process__activity_definition" name="XE_adapt_and_improve_process__activity_definition"></a>
+<ul>
+ <li>
+ Improve the productivity of the team.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/automate_acceptance_test.xmi b/XP/XP_baseline_EN/library/xp/tasks/automate_acceptance_test.xmi
new file mode 100644
index 0000000..8266bcc
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/automate_acceptance_test.xmi
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-fm-gBePbdl_WMsE5NxEreQ" name="automate_acceptance_test,{E614ED93-AE72-4FD1-B459-C508CE1C536F}" guid="-fm-gBePbdl_WMsE5NxEreQ" version="1.0.0">
+ <sections xmi:id="_oNCOIGE-EdqnIZeW8YpHcA" name=" General " guid="_oNCOIGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ XP teams represent detailed requirements as automated customer tests. Automating the tests insures they are detailed,
+ unambiguous, and executable. Typically, each acceptance criteria is translated into at least one automated test.
+</p>
+<p>
+ There are lots of ways to do this:
+</p>
+<ul>
+ <li>
+ For a batch program reading inputs and producing outputs: create test input files, capture actual output, and
+ compare it against expected output.
+ </li>
+ <li>
+ Write functional tests as programs. You can use a unit testing framework as a base or create a little scripting
+ language the programmers can use.
+ </li>
+ <li>
+ Allow the customer to easily specify tests (spreadsheets, flat text files) and create a small tool to read the
+ input and expected output. The tool runs the input against the system and checks that the actual output matches the
+ expected output.
+ </li>
+ <li>
+ Build an input recorder to allow customers to define the tests.
+ </li>
+ <li>
+ Use simple file-based tools to check the results.
+ </li>
+</ul>
+<p>
+ It is important to build the automation simply and incrementally as you need it. It is too easy to lose control and
+ invest too much time in test automation instead of business value. Don't overdo it.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_automate_customer_test__activity_definition" name="XE_automate_customer_test__activity_definition"></a>
+<ul>
+ <li>
+ Transform the acceptance criteria of a user story into executable form.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/breakdown_story.xmi b/XP/XP_baseline_EN/library/xp/tasks/breakdown_story.xmi
new file mode 100644
index 0000000..783732e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/breakdown_story.xmi
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-umDp1nFYrMetgnJ-kUMhHw" name="breakdown_story,{90DBD758-58B8-4383-94DD-312D349512BC}" guid="-umDp1nFYrMetgnJ-kUMhHw" version="1.0.0">
+ <sections xmi:id="_oEkOoGE-EdqnIZeW8YpHcA" name=" Understand the User Story " guid="_oEkOoGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ Breaking down user stories occurs at iteration planning. The first step in iteration planning is for the customer to go
+ over the story with the developers to ensure they understand the story. The developers can ask questions until they are
+ satisfied that they understand all aspects of the system. The details of the user stories are defined in the acceptance
+ test criteria.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oEkOoWE-EdqnIZeW8YpHcA" name=" Discuss Possible Implementations " guid="_oEkOoWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Coming up with engineering tasks for a story requires a good understanding of how the story will be implemented. The
+ team uses this time to discuss possible design alternatives or approaches.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oEkOomE-EdqnIZeW8YpHcA" name=" Identify Engineering Tasks " guid="_oEkOomE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ Once an approach has been selected by the team, the team focuses on identifying the steps that allow the team to fully
+ implement it during the following iteration.
+</p>
+<p>
+ <br />
+ <br />
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_break_down_story__activity_definition" name="XE_break_down_story__activity_definition"></a>
+<ul>
+ <li>
+ Split user stories into engineering tasks.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/define_coding_standard.xmi b/XP/XP_baseline_EN/library/xp/tasks/define_coding_standard.xmi
new file mode 100644
index 0000000..437ff72
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/define_coding_standard.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-qIbMRqe8wqKN2-HLtNUcLw" name="define_coding_standard,{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" guid="-qIbMRqe8wqKN2-HLtNUcLw" version="1.0.0">
+ <sections xmi:id="_oCfyEGE-EdqnIZeW8YpHcA" name=" Write Prototypical Classes " guid="_oCfyEGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ When deciding on a coding standard, take the time to write a few classes which use a particular style. Should the curly
+ braces be flush with the indentation of the line above? Do we use tabs or spaces? Are abbreviations permitted? If so,
+ do we have a short list?
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oCfyEWE-EdqnIZeW8YpHcA" name=" Discuss Standard " guid="_oCfyEWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ The coding standard for a project should be as simple as possible. The goal is not to forbid error prone constructs,
+ but rather to make the code as communicative and uniform as possible so it can be understood and worked on readily. If
+ the team cannot reach consensus, use majority rule. Having a standard is more important than the specific details.
+</p>
+<p>
+ <br />
+ &nbsp;
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_define_coding_standard__activity_definition" name="XE_define_coding_standard__activity_definition"></a>
+<ul>
+ <li>
+ To aid clarity by making the style of code as familiar as possible.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/define_customer_test.xmi b/XP/XP_baseline_EN/library/xp/tasks/define_customer_test.xmi
new file mode 100644
index 0000000..33b87e1
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/define_customer_test.xmi
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-WgE0oiE2yddCOMnfzL25Gw" name="define_customer_test,{DCDB57BE-4233-4CF8-90CE-70D6808F92B0}" guid="-WgE0oiE2yddCOMnfzL25Gw" version="1.0.0">
+ <sections xmi:id="_oGorMGE-EdqnIZeW8YpHcA" name="Understand the Story " guid="_oGorMGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ Since the customer tests are automated, the customer has to be very specific about what the test will do. It is
+ impossible to do this if the customer does not understand the story in intimate detail from a user perspective. Writing
+ the customer tests will force the customer to go into all the details of the story. Stories must be testable.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oGorMWE-EdqnIZeW8YpHcA" name="Define Test Criteria " guid="_oGorMWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Once the story is well understood and selected for the iteration, the automated customer tests are written. If the
+ customer team includes testers, the customer could communicate the test criteria to the tester. This can be verbal or
+ written. The criterion describes the tests for the normal and exceptional behavior of the system.<br />
+ &nbsp;
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_define_customer_test__activity_definition" name="XE_define_customer_test__activity_definition"></a>
+<ul>
+ <li>
+ Define the criteria under which the customer will deem a story complete.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/define_iteration_plan.xmi b/XP/XP_baseline_EN/library/xp/tasks/define_iteration_plan.xmi
new file mode 100644
index 0000000..7d63cdd
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/define_iteration_plan.xmi
@@ -0,0 +1,61 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-BWG5zUGb8c25kuLJ3ck8ng" name="define_iteration_plan,{849E3635-6FCD-4FAD-A007-CA34B9998622}" guid="-BWG5zUGb8c25kuLJ3ck8ng" version="1.0.0">
+ <sections xmi:id="_oQSWcGE-EdqnIZeW8YpHcA" name="Preconditions " guid="_oQSWcGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="PreCond" name="PreCond"></a>
+<p>
+ The steps for this activity are part of XP iteration planning. In order for this activity to be successful, the
+ following preconditions should be met:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ The customer understands the user stories very well.
+ </div>
+ </li>
+ <li>
+ The customer has defined acceptance criteria for the stories.
+ </li>
+ <li>
+ All team members that will be involved in developing the stories should be present.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_oQSWcWE-EdqnIZeW8YpHcA" name="Customer Presents the User Stories " guid="_oQSWcWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ The customer selects a list of user stories that he would like included in the next iteration. The stories typically
+ come from the release plan but may also include new stories that were not originally planned. The customer explains the
+ stories and the acceptance test criteria to the developers.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oQSWcmE-EdqnIZeW8YpHcA" name="Developers Break Down Stories " guid="_oQSWcmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ The developers discuss how to implement the story and break it down into engineering tasks. Tasks should include
+ everything necessary to get the story to pass the customer's acceptance test.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oQSWc2E-EdqnIZeW8YpHcA" name="Developers Sign Up and Estimate " guid="_oQSWc2E-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ The developers sign up for all the tasks. The developers put estimates only for the tasks they have personally signed
+ up for.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oQSWdGE-EdqnIZeW8YpHcA" name="Customer Adjusts Iteration Plan " guid="_oQSWdGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step4" name="Step4"></a>
+<p>
+ If the sum of all the task estimates is greater than the sum of all the tasks done by the team during the last
+ iteration, the customer must remove some work in order to&nbsp;respect the team's iteration velocity.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_define_iteration__activity_definition" name="XE_define_iteration__activity_definition"></a>
+<ul>
+ <li>
+ Establish what can be built during the iteration, given the team's constraints.
+ </li>
+ <li>
+ Allow the team to manage itself at the task level.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/define_release_plan.xmi b/XP/XP_baseline_EN/library/xp/tasks/define_release_plan.xmi
new file mode 100644
index 0000000..39fc546
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/define_release_plan.xmi
@@ -0,0 +1,78 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-7gEOFFavlkSqwIoTNrvfJA" name="define_release_plan,{D755C076-8E63-4A24-89AA-A7D64E368B90}" guid="-7gEOFFavlkSqwIoTNrvfJA" version="1.0.0">
+ <sections xmi:id="_oOauMGE-EdqnIZeW8YpHcA" name="Preparation " guid="_oOauMGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ The steps for this activity are part of XP release planning. In order for this activity to be successful, the following
+ preconditions should be met:
+</p>
+<ul>
+ <li>
+ The customer has enough user stories at present to fill at least one release.
+ </li>
+ <li>
+ The customer understands the user stories very well.
+ </li>
+ <li>
+ The customer has defined acceptance criteria for the stories.
+ </li>
+ <li>
+ All team members that will be involved in developing the stories should be present.
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_oOauMWE-EdqnIZeW8YpHcA" name="Customer Presents the User Stories " guid="_oOauMWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ The customer describes each story to the team and explains the conditions under which the story is going to be
+ considered complete.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oOauMmE-EdqnIZeW8YpHcA" name="Developers Estimate the User Stories " guid="_oOauMmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ The developers discuss each story and come up with an estimate based on their experience. High-level design discussions
+ take place as developers try to understand the story and discuss different ways of implementing it. In some cases, the
+ team will not be able to provide a reasonable estimate:
+</p>
+<ul>
+ <li>
+ They do not understand the story: the team should be asking more questions&nbsp;to the customer.
+ </li>
+ <li>
+ The story is too big: the developers don't have a good grasp of the scope. It should be broken down into smaller
+ stories.
+ </li>
+ <li>
+ They don't know how to do it: they will need to do some research first.
+ </li>
+</ul>
+<p>
+ Be careful to avoid analysis paralysis. The first few times the team estimates stories, it may take as long as an hour
+ to estimate a story. The second story should take less time. Your goal should be to be able to estimate a story in only
+ a few minutes.
+</p>
+<p>
+ As a rule of thumb, story estimates should not exceed the iteration length based on a pair of people dedicated to the
+ story. When stories exceed the iteration length, the customer splits the story.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oOg00GE-EdqnIZeW8YpHcA" name="Customer Prioritizes Stories " guid="_oOg00GE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ Once all the stories have an estimated cost, the customer can prioritize the stories into the release plan.The customer
+ organizes stories into iterations and sequences of iterations into releases. The sum of all story points in each
+ iteration cannot exceed the team's velocity. At the beginning of the project, you will have to guess the team's
+ velocity. Try one third of the ideal programmer time available in an iteration. After a few iterations, revisit the
+ plan and use the team's measured velocity. See more on release planning in the <a class="elementLinkWithUserText"
+ href="./../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
+ guid="6.7335956461328426E-307">planning game guideline</a>.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_define_release__activity_definition" name="XE_define_release__activity_definition"></a>
+<ul>
+ <li>
+ To estimate the content and delivery date for a release of the product.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/develop_xp_vision.xmi b/XP/XP_baseline_EN/library/xp/tasks/develop_xp_vision.xmi
new file mode 100644
index 0000000..64a3858
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/develop_xp_vision.xmi
@@ -0,0 +1,80 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-W67fNE0rT1c2PM-20yXbrw" name="develop_xp_vision,{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" guid="-W67fNE0rT1c2PM-20yXbrw" changeDate="2005-12-02T08:56:23.177-0800" version="1.0.0">
+ <sections xmi:id="_oB58MGE-EdqnIZeW8YpHcA" name="Gain Agreement on the Problem Being Solved " guid="_oB58MGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Gain" name="Step1"></a>
+<p>
+ One of the simplest ways to gain agreement on the definition of the problem is to write it down and see if everyone
+ agrees.
+</p>
+<p>
+ Ask the group: What is the problem?
+</p>
+<p>
+ It is very common to rush headlong into defining the solution rather than taking time to first understand the problem.
+ Write down the problem and see if you can get everyone to agree on the definition.
+</p>
+<p>
+ Then ask the group again: What is the problem, really?
+</p>
+<p>
+ Search for root causes or the "problem behind the problem". The real problem is often hiding behind what is perceived
+ as a problem. Don't accept the first statement of a problem. Continue to ask "why?" to find out what the problem
+ "really" is. Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate
+ the underlying problem. In such cases, it can be beneficial to explore the benefits of the solution and then try to
+ find the problems being solved by those benefits. You can then explore whether or not those problems are "real"
+ problems in the organization.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oB58MWE-EdqnIZeW8YpHcA" name="Identify Stakeholders " guid="_oB58MWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Identify" name="Step2"></a>
+<ul>
+ <li>
+ Who are the users of the system?
+ </li>
+ <li>
+ Who is the economic buyer for the system?
+ </li>
+ <li>
+ Who else will be affected by the output that the system produces?
+ </li>
+ <li>
+ Who will evaluate and bless the system when it is delivered and deployed?
+ </li>
+ <li>
+ Are there any other internal or external users of the system whose needs must be addressed?
+ </li>
+ <li>
+ Who will maintain the new system?
+ </li>
+ <li>
+ Is there anyone else?
+ </li>
+ <li>
+ Okay, is there anyone else?
+ </li>
+</ul></sectionDescription>
+ </sections>
+ <sections xmi:id="_oB58MmE-EdqnIZeW8YpHcA" name="Define the Primary Features of the System " guid="_oB58MmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Define" name="Step3"></a>
+<p>
+ What primary features of the system allow the stakeholders to solve their problems? This should be a list of very
+ high-level features.<br />
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oB58M2E-EdqnIZeW8YpHcA" name="Communicate the Vision " guid="_oB58M2E-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Com" name="Step4"></a>
+<p>
+ Once agreed upon by the stakeholders, the vision is communicated clearly to all project team members. When the project
+ starts, XP teams often write up the vision on one of the whiteboards in the team's open workspace so it can easily be
+ seen by all team members. After a short time, the team usually internalizes the vision and no longer needs the
+ reminder.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_define_vision__activity_definition" name="XE_define_vision__activity_definition"></a>
+<ul>
+ <li>
+ The Vision defines the stakeholder's view of the product being developed specified in terms of the stakeholder's
+ key needs and features.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/estimate_task.xmi b/XP/XP_baseline_EN/library/xp/tasks/estimate_task.xmi
new file mode 100644
index 0000000..132fb8c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/estimate_task.xmi
@@ -0,0 +1,25 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-9EbmL3qGJ_TemB83cJublQ" name="estimate_task,{EC483990-8129-4AE3-893C-0F7406C128DA}" guid="-9EbmL3qGJ_TemB83cJublQ" version="1.0.0">
+ <sections xmi:id="_oCfyEmE-EdqnIZeW8YpHcA" name="Understand the Task " guid="_oCfyEmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ Task breakdown of a user story is done at iteration planning by the whole team. Since all team members are present,
+ they should have a fairly good understanding of the tasks. If not, the team is there to help them.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oCfyE2E-EdqnIZeW8YpHcA" name="Give an Estimate Based on Experience " guid="_oCfyE2E-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step2"></a>
+<p>
+ The person giving the estimate can use his personal experience to give an estimate based on a similar task he has done
+ before. If the experience is not there, other team members can help by providing their input based on their own
+ experience. Very often, pairs will form for specific tasks at this stage. The most important aspect to keep in mind is
+ that the person responsible for the task is the one giving the estimate.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_estimate_task__activity_definition" name="XE_estimate_task__activity_definition"></a>
+<ul>
+ <li>
+ Provide a fine-grain estimate that will be used in iteration planning.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/estimate_user_story.xmi b/XP/XP_baseline_EN/library/xp/tasks/estimate_user_story.xmi
new file mode 100644
index 0000000..6134cb5
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/estimate_user_story.xmi
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-Z9xFd9JTnJuNN5S27p06UQ" name="estimate_user_story,{23A924D3-5989-40DD-86A9-9D8FCFB8AE52}" guid="-Z9xFd9JTnJuNN5S27p06UQ" version="1.0.0">
+ <sections xmi:id="_oEqVQGE-EdqnIZeW8YpHcA" name=" Understand the User Story " guid="_oEqVQGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ To provide an estimate that is fairly accurate, the developers need to have a good grasp of the story. During release
+ planning, the customer describes each user story and presents acceptance test criteria. The developers can ask
+ questions until they are satisfied that they understand the most important aspects of what the customer is asking for.
+ Avoid analysis paralysis; there are many stories.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oEqVQWE-EdqnIZeW8YpHcA" name=" Discuss Possible Implementations " guid="_oEqVQWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Sometimes the team can just estimate the story from their gut. Other times the story may not quite fit prior
+ experiences, and the team may have to explore potential design alternatives. Do not settle on a specific design. If
+ competing ideas take about the same amount of time, pick an estimate and move on to the next story. Avoid analysis
+ paralysis; there are many stories.
+</p>
+<p>
+ When there is deep uncertainty, the team can request the time to do some research (spike) in order to give a more
+ realistic estimate.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oEqVQmE-EdqnIZeW8YpHcA" name=" Give an Estimate Based on Experience " guid="_oEqVQmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ If the team has done similar work before, they simply extrapolate from previous work. For work the team is unfamiliar
+ with, a spike can provide just enough information to know what is possible and how long the effort is likely to last.
+ An experienced XP team can estimate most stories in a few minutes or less. Avoid analysis paralysis; there are many
+ stories.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oEqVQ2E-EdqnIZeW8YpHcA" name=" Ask the Customer to Split the Story " guid="_oEqVQ2E-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Ask" name="Ask"></a>
+<p>
+ Story estimates should not exceed the iteration duration for a pair of programmers. If the estimate is too big, have
+ the customer split the story. People are better at estimating smaller pieces of work. Long estimates tend to go over
+ budget. It would not be uncommon to take a four-week story and break it down only to discover it is four two-week
+ stories.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_estimate_user_story__activity_definition" name="XE_estimate_user_story__activity_definition"></a>
+<ul>
+ <li>
+ Provide a high-level estimate that will be used in release planning.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/explain_process.xmi b/XP/XP_baseline_EN/library/xp/tasks/explain_process.xmi
new file mode 100644
index 0000000..c2e560c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/explain_process.xmi
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-I3yOxhkbTu3OCbzQ0sUsyA" name="explain_process,{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727}" guid="-I3yOxhkbTu3OCbzQ0sUsyA" version="1.0.0">
+ <sections xmi:id="_oNuxsGE-EdqnIZeW8YpHcA" name=" General " guid="_oNuxsGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ As a team begins to use the <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a>, the coach must prepare the team to use the practices effectively.
+</p>
+<p>
+ This includes the following:
+</p>
+<ul>
+ <li>
+ Teach the team about XP and ensure that the team has a common understanding of the practices.
+ </li>
+ <li>
+ Facilitate the team's decision as to how aggressively the transition to the new practices will be.
+ </li>
+ <li>
+ Facilitate a team activity to identify what obstacles they will face in using the practices effectively. Ensure
+ that the team has a plan to overcome those obstacles.
+ </li>
+ <li>
+ Facilitate a team activity to identify what constraints will require adaptation of the practices. Ensure that these
+ adaptations are understood by the <a class="elementLink"
+ href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole
+ Team</a>.
+ </li>
+</ul>
+<p>
+ Because there are many roles in the team, a coach needs to have a good understanding of the all different activities in
+ the process. In some cases, there might be more than one coach on a team to address needs. There might be a coach for
+ the developer team and one for the customer team, for example.
+</p>
+<p>
+ Use external expertise as necessary to ensure the team starts with a strong base of knowledge on which to succeed.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_explain_process__activity_definition" name="XE_explain_process__activity_definition"></a>
+<ul>
+ <li>
+ Make sure the team has a common understanding of the fundamentals.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/implement_spike.xmi b/XP/XP_baseline_EN/library/xp/tasks/implement_spike.xmi
new file mode 100644
index 0000000..3e8478e
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/implement_spike.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-DbsgXRUjLhsnnpioGI2b3g" name="implement_spike,{85BE1C0E-F389-4246-BB22-9A52988018B7}" guid="-DbsgXRUjLhsnnpioGI2b3g" version="1.0.0">
+ <sections xmi:id="_oCl4sGE-EdqnIZeW8YpHcA" name=" General " guid="_oCl4sGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ A spike is an experiment. It helps the team find some bit of information it is missing in order to go forward. As such,
+ spikes are an important tool to minimize project risks.
+</p>
+<p>
+ Spikes are very often called for during the planning process when the team is unsure about how long particular stories
+ will take. In this case, the spike consists of trying out different ways of implementing the story. The team will do
+ the bare minimum to gain an understanding of how to do the story so that they can provide a reasonable estimate. Very
+ often, the code generated by spikes is literally thrown away. The value of the spike is in the information that was
+ missing, namely a good estimate in this case.
+</p>
+<p>
+ <br />
+ &nbsp;
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_implement_spike__activity_definition" name="XE_implement_spike__activity_definition"></a>
+<ul>
+ <li>
+ Research a missing piece of information.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/improve_team_skills.xmi b/XP/XP_baseline_EN/library/xp/tasks/improve_team_skills.xmi
new file mode 100644
index 0000000..dc4de2a
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/improve_team_skills.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-32JWpciwfc2e7HgQavJDkw" name="improve_team_skills,{1C4325AC-17DE-4CD0-8AA0-4B210570579F}" guid="-32JWpciwfc2e7HgQavJDkw" version="1.0.0">
+ <sections xmi:id="_oNuxsWE-EdqnIZeW8YpHcA" name="General " guid="_oNuxsWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ Teams are made up of individuals with an imperfect balance of technical expertise, domain or customer awareness, and
+ people skills. The team must continually identify and improve those skill areas that are lacking. The XP Coach helps
+ ensure that this happens.
+</p>
+<p>
+ The coach must always be aware of what difficulties the team is having in succeeding on their project. Some of these
+ will be evident, often communicated directly by the team. Some will be subtle with little awareness on the team that
+ there is a problem. To maintain this awareness, the coach must balance time spent in the trenches with the team,
+ observing specific use of the practices, with time spent reflecting on the team's capabilities, unencumbered by the
+ direct pressures of the project.
+</p>
+<p>
+ With an awareness of where the team needs improvement, the coach must help the team integrate improvement activities
+ into their work. Improvement activities need to be prioritized just as User Stories do. Different options will exist to
+ address skill improvement needs. The coach should be familiar with a wide variety of activities, courses, and games to
+ help people further their skills in a given practice. The coach acts as a conduit that connects the team with the
+ expertise required to improve a skill whether that other resource is in the organization or is an external resource.
+</p>
+<p>
+ One of the most effective tools to help the team identify areas for improvement is the Retrospective, a form of project
+ review. Techniques for this are described in Norm Kerth's book, <i>Project Retrospectives</i> [<a
+ class="elementLinkWithUserText"
+ href="./../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#KER01"
+ guid="6.191633934532389E-306">KER01</a>]. Many teams have adapted the tools from the book to perform abbreviated
+ retrospectives after each iteration in addition to the more comprehensive session held at the completion of a full
+ project.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_improve_team_skills__activity_definition" name="XE_improve_team_skills__activity_definition"></a>
+<ul>
+ <li>
+ Help the team members identify skills that need improvement and implement activities to improve those skills.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/integrate_system.xmi b/XP/XP_baseline_EN/library/xp/tasks/integrate_system.xmi
new file mode 100644
index 0000000..6a05e47
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/integrate_system.xmi
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="--tP2hgRfEkZPGYvy1y0GZQ" name="integrate_system,{70FEC254-8555-4844-AD82-68367E25F082}" guid="--tP2hgRfEkZPGYvy1y0GZQ" version="1.0.0">
+ <sections xmi:id="_oE9QMGE-EdqnIZeW8YpHcA" name=" Run All Unit Tests for the System " guid="_oE9QMGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ While you and your pair partner are working on a task, you run unit tests to make sure you are not introducing side
+ effect defects. As a system evolves, it may become impractical to run all the unit tests for the system for every
+ change made. In this case, you may choose a subset of the unit tests to run after every code change. When a task is
+ completed or you feel that you have a piece you can integrate or you are uncertain for any reason, run all of the unit
+ tests for the system.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oE9QMWE-EdqnIZeW8YpHcA" name=" Check in Code " guid="_oE9QMWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ If all of the unit test in the system passed, check in your code and produce a system build.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_integrate_and_build__activity_definition" name="XE_integrate_and_build__activity_definition"></a>
+<ul>
+ <li>
+ To produce a runnable executable of the application under development that can be used to evaluate progress and
+ provide feedback
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/keep_process_on_track.xmi b/XP/XP_baseline_EN/library/xp/tasks/keep_process_on_track.xmi
new file mode 100644
index 0000000..8f17756
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/keep_process_on_track.xmi
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-SH3UFVsPViLT3hOalbaxgA" name="keep_process_on_track,{80725BC3-E2BA-4860-8F07-4A34B96FBB2A}" guid="-SH3UFVsPViLT3hOalbaxgA" version="1.0.0">
+ <sections xmi:id="_oN04UGE-EdqnIZeW8YpHcA" name="General " guid="_oN04UGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ The <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
+ guid="7.89591827591278E-306">Whole Team</a> needs to be very focused on the goals of the project. The development
+ practices enable the project goals to be achieved. The challenge of focusing on the project goals and focusing the
+ disciplined and effective use of the practices is a constant challenge for the team.
+</p>
+<p>
+ The <a class="elementLink" href="./../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
+ guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a> collects data and reports it to the team. This data
+ provides guidance as to whether the project is on a trajectory to meet the project goals. The data also monitors the
+ team's use of the practices.
+</p>
+<p>
+ The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
+ guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> ensures that the team is collecting and using the data to
+ ensure that the project and process goals are achieved.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_keep_process_on_track__activity_definition" name="XE_keep_process_on_track__activity_definition"></a>
+<ul>
+ <li>
+ Ensure the process is being used effectively towards the project goals.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/refactor_code.xmi b/XP/XP_baseline_EN/library/xp/tasks/refactor_code.xmi
new file mode 100644
index 0000000..639937b
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/refactor_code.xmi
@@ -0,0 +1,60 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-IoT5LZUu3vnNFp-pwPUMHA" name="refactor_code,{3DD335BB-45F6-49C7-B17A-90652C73A485}" guid="-IoT5LZUu3vnNFp-pwPUMHA" version="1.0.0">
+ <sections xmi:id="_oCr_UGE-EdqnIZeW8YpHcA" name="Identify Poor Design " guid="_oCr_UGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ While developing, requirements change and previous design decisions can be invalidated. A new feature is added, you get
+ it to work, but the structure and clarity of the code can degrade. You could leave it, and the design will slowly rot,
+ or you could improve the design on the spot. Refactoring is about improving the design.
+</p>
+<p>
+ A simple design has these four characteristics, listed in priority order:
+</p>
+<ul>
+ <li>
+ The system runs all the tests.
+ </li>
+ <li>
+ It contains no duplicate code.
+ </li>
+ <li>
+ The code states the programmers' intent very clearly.
+ </li>
+ <li>
+ It contains the fewest possible number of classes and methods.
+ </li>
+</ul>
+<p>
+ A good resource for gaining refactoring knowledge is Martin Fowler's book: <i>Refactoring - Improving the Design of
+ Existing Code</i> [<a class="elementLinkWithUserText"
+ href="./../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#FOW99"
+ guid="6.191633934532389E-306">FOW99</a>]. Martin discusses the idea of bad code smells, how to detect them, what harm
+ they will do to your software, and how to fix them.
+</p>
+<p>
+ During development, you should look at the code refactoring with an open mind and find its weaknesses. Clarify the
+ code; fix what needs to be fixed. As you discover these smells, you should work to eliminate them before proceeding to
+ the next test case. Save some time before you check-in your code to step back and look it over. Identify duplicate code
+ sections and places where the design intent is not clear.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oCr_UWE-EdqnIZeW8YpHcA" name="Refactor " guid="_oCr_UWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Refactoring involves making changes to your code which improve its structure without modifying its behavior. Martin
+ Fowler's Refactoring book lists over sixty refactorings to handle particular code situations. The goal of each of them
+ is to reduce duplication in the code base and increase clarity. Leave your code clean, simple, and free from
+ duplication.
+</p>
+<p>
+ As the structure of your code base evolves, you choose names which aid your understanding of the functionality
+ specified by the code. This system of names becomes the vocabulary for your team's discussion of design.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_refactor_code__activity_definition" name="XE_refactor_code__activity_definition"></a>
+<ul>
+ <li>
+ To keep the design of the system clear and ready for change.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/report_acceptance_test_result.xmi b/XP/XP_baseline_EN/library/xp/tasks/report_acceptance_test_result.xmi
new file mode 100644
index 0000000..6063b10
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/report_acceptance_test_result.xmi
@@ -0,0 +1,21 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-p0GGwGNG5O8Dn6O6ZzivIw" name="report_acceptance_test_result,{52D6E875-C46B-454B-A39C-CEC21603AF5C}" guid="-p0GGwGNG5O8Dn6O6ZzivIw" version="1.0.0">
+ <sections xmi:id="_oH6dkGE-EdqnIZeW8YpHcA" name=" General " guid="_oH6dkGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ This activity communicates to the whole team the progress they have made. As this is a major factor in motivation, XP
+ teams very often use big, visible charts to show their progress. These charts are very often placed in the open
+ workspace and visible to anyone who enters the team area.
+</p>
+<p>
+ A suitable chart would track the number of customer tests defined and running by iteration. The vertical axis is the
+ number of tests; the horizontal axis is the iteration number.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_report_customer_test_result__activity_definition" name="XE_report_customer_test_result__activity_definition"></a>
+<ul>
+ <li>
+ Provide the team with a clear understanding of progress.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/report_project_status.xmi b/XP/XP_baseline_EN/library/xp/tasks/report_project_status.xmi
new file mode 100644
index 0000000..5fa5970
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/report_project_status.xmi
@@ -0,0 +1,53 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-WOPGmKUuYbvVeVHp0sgEgw" name="report_project_status,{ED94150E-EE14-47BF-97F5-F1EC7130EEEC}" guid="-WOPGmKUuYbvVeVHp0sgEgw" version="1.0.0">
+ <sections xmi:id="_oOzvwGE-EdqnIZeW8YpHcA" name="Gather the Information " guid="_oOzvwGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ The most important information about the status of the project is the updated release plan. The release plan defines
+ the current view of the release content and availability. Metrics, such as the team's velocity, can also be provided.
+ Typically, metrics are tracked for the purpose of helping the team improve some aspects of development they are having
+ problems with. These metrics can be presented as part of project status.
+</p>
+<p>
+ The velocity metric can be abused. Keep in mind that there is no valid comparison of velocities between teams. The most
+ important thing about a team's velocity is the stability of the velocity. This allows the team to predict what it can
+ accomplish.
+</p>
+<p>
+ Other meaningful metrics:
+</p>
+<ul>
+ <li>
+ Defined stories over time, overlaid with completed stories
+ </li>
+ <li>
+ Defined customer tests overlaid with running customer tests
+ </li>
+ <li>
+ Number of unit tests tracked over time
+ </li>
+ <li>
+ Unit test coverage
+ </li>
+</ul>
+<p>
+ The team's significant metrics are recorded on flip chart paper and hung in the team's open workspace.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oOzvwWE-EdqnIZeW8YpHcA" name=" Communicate the Status " guid="_oOzvwWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Since outside stakeholders do not participate in the daily activities of the team, it is important that the status of
+ the project should be communicated to them as often as possible. It lowers significantly the risk of disconnect between
+ the development team and the stakeholders. It also provides the team with data they can use to improve their
+ development process. Stakeholders should come to the open workspace and view the project status that is recorded on the
+ walls of the open workspace. They can experience the progress being made by the team first hand.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_report_project_status__activity_definition" name="XE_report_project_status__activity_definition"></a>
+<ul>
+ <li>
+ Communicate to stakeholders the status of the project.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/resolve_conflicts.xmi b/XP/XP_baseline_EN/library/xp/tasks/resolve_conflicts.xmi
new file mode 100644
index 0000000..08602f7
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/resolve_conflicts.xmi
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-L85wOCiwe2O8D8CISEGGGg" name="resolve_conflicts,{1B23700D-02B0-476F-A3DE-6F63A5407151}" guid="-L85wOCiwe2O8D8CISEGGGg" changeDate="2006-11-09T14:20:06.801-0800" version="1.0.0">
+ <mainDescription><p>
+ Software projects require the coordinated efforts of many people. The <a class="elementLink"
+ href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
+ Practices</a> leverage the ability of teams to collaborate and communicate about decisions and activities on the
+ project. Because team members are working together in an <a class="elementLink"
+ href="./../../xp/guidances/guidelines/open_workspace,3.269440809144354E-305.html" guid="3.269440809144354E-305">Open
+ Workspace</a>, interpersonal conflicts are visible, not hidden by the separation of the cubicles. One byproduct of
+ increased collaboration, communication, and feedback will be increased conflict. Unmanaged, this conflict may increase
+ the risk to the project. XP, as a process, does not try to solve all of the problems that occur on a software project,
+ it just enables the people to solve them.
+</p>
+<p>
+ The XP Coach must make sure these conflicts are managed. The coach must help the team develop an environment of
+ openness, where conflicts can be discussed and resolved. Conflicts left unresolved, like defects left undetected, are
+ usually more disruptive and ultimately costly to fix. At times, the coach will take ownership to resolve a conflict on
+ the team or across teams, but over time, the coach must ensure that the team is capable of resolving most conflicts on
+ their own.
+</p></mainDescription>
+ <purpose><a id="XE_resolve_conflicts__activity_definition" name="XE_resolve_conflicts__activity_definition"></a>
+<ul>
+ <li>
+ Prevent disagreements from reducing the team's productivity.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/run_acceptance_test.xmi b/XP/XP_baseline_EN/library/xp/tasks/run_acceptance_test.xmi
new file mode 100644
index 0000000..d965c78
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/run_acceptance_test.xmi
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-6RyabSc-ZUEtoEKb90BCbg" name="run_acceptance_test,{D4E30732-30D3-4C75-8C69-D2F15313F1A9}" guid="-6RyabSc-ZUEtoEKb90BCbg" version="1.0.0">
+ <sections xmi:id="_oNI70GE-EdqnIZeW8YpHcA" name=" General " guid="_oNI70GE-EdqnIZeW8YpHcA">
+ <sectionDescription><p>
+ This task consists of running all the customer or acceptance tests to ensure that all previously completed user stories
+ are still working. A lot of XP teams run those tests on a daily basis as part of their automated daily build. Other
+ teams run those tests every time a new story is added to the pool of completed stories to ensure that a new story has
+ not caused previous ones to fail.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_run_customer_test__activity_definition" name="XE_run_customer_test__activity_definition"></a>
+<ul>
+ <li>
+ Execute the automated acceptance test and gather results.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/setup_programmer_environment.xmi b/XP/XP_baseline_EN/library/xp/tasks/setup_programmer_environment.xmi
new file mode 100644
index 0000000..cba62e8
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/setup_programmer_environment.xmi
@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-1rVEQRCvrcicCdhpuuIZ8w" name="setup_programmer_environment,{D3AA9FEE-AAD9-4884-BF71-425E122110A7}" guid="-1rVEQRCvrcicCdhpuuIZ8w" version="1.0.0">
+ <sections xmi:id="_oPGqsGE-EdqnIZeW8YpHcA" name="Remove Cubicle Walls and Other Impediments " guid="_oPGqsGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ In XP, we attempt to maximize communication within the team. Programmers should be able to ask quick questions&nbsp;to
+ other developers and overhear conversations which raise their understanding of the system. When team members are
+ segregated into offices or cubicles, there is more of a chance that islands of knowledge will grow in isolation. This
+ leads to redundant work and often work that is less integrated than if it had been done in an open space subject to the
+ contributions of overhearing team members.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oPNYYGE-EdqnIZeW8YpHcA" name="Place Computers in Positions Comfortable for Pairing " guid="_oPNYYGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Standard office furniture is not designed for pair programming. In particular, desks with leg wells seem to make
+ pairing impossible. Ideally, computers should be placed on tables which have enough room for two people to sit side by
+ side and trade turns working at the keyboard. Comfort should be your guide. If you are not comfortable, you will get
+ fatigued easily and you certainly won't be doing the work you are capable of.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oPNYYWE-EdqnIZeW8YpHcA" name="Standardize on Tools and Development Setup " guid="_oPNYYWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ In XP, we find that work goes better when everyone is able to help everyone else. One simple thing that can get in the
+ way is computer setup. If you use an editor with one set of key bindings and another team member uses another, it will
+ be difficult for either of you to go to each other's computers and feel comfortable enough to drive. While this seems
+ like a minor point, it makes a sizable difference on how effectively a team can collaborate. In many XP teams, machines
+ are unassigned. You simply go to a free machine in the morning and check out the code that you need to start working
+ on.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oPNYYmE-EdqnIZeW8YpHcA" name="Establish Clear Line of Sight to Customer " guid="_oPNYYmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step4" name="Step4"></a>
+<p>
+ To work effectively with XP, you must be able to ask questions&nbsp;to your customer. If you are not able to ask
+ questions and get timely answers, you are either bottlenecked on a task or tempted to guess and hope that you don't
+ have to roll back your work later. When setting up your environment, establish a clear line of sight to the customer.
+ The customer should be working in the same room as the team. If this is not possible, the customer should be no more
+ than a phone call away.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_setup_programmer_environment__activity_definition"
+name="XE_setup_programmer_environment__activity_definition"></a>
+<ul>
+ <li>
+ To make it easy to work collaboratively and raise the communication level of the team
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/setup_tester_environment.xmi b/XP/XP_baseline_EN/library/xp/tasks/setup_tester_environment.xmi
new file mode 100644
index 0000000..4379353
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/setup_tester_environment.xmi
@@ -0,0 +1,23 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-OPKuXnenD910fJyGKA99aw" name="setup_tester_environment,{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC}" guid="-OPKuXnenD910fJyGKA99aw" version="1.0.0">
+ <sections xmi:id="_oNI70WE-EdqnIZeW8YpHcA" name=" General " guid="_oNI70WE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ Testers will need to setup some kind of hardware/software environment in order to run the customer acceptance tests.
+ The environment might require the installation of specific software test tools or the OS might require specific
+ environment settings. Try to replicate as much as possible a typical end-user environment when running the tests. Tests
+ may require setting up multiple environments (when different operating systems are used, for example).
+</p>
+<p>
+ Test environments are not only for testers; it is critical that they are made available to the programmers. Running the
+ acceptance tests is their only way to know whether or not they are through with a story and whether they have broken
+ previous stories or not.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_setup_tester_environment__activity_definition" name="XE_setup_tester_environment__activity_definition"></a>
+<ul>
+ <li>
+ Create a stable environment for running the customer tests.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/track_story_completion.xmi b/XP/XP_baseline_EN/library/xp/tasks/track_story_completion.xmi
new file mode 100644
index 0000000..4264a58
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/track_story_completion.xmi
@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-FxF90KOknQ5km30pP0038w" name="track_story_completion,{C333BA32-CF6B-4577-9212-302893043EFF}" guid="-FxF90KOknQ5km30pP0038w" version="1.0.0">
+ <sections xmi:id="_oOHzQGE-EdqnIZeW8YpHcA" name=" General " guid="_oOHzQGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ Progress in XP is measured in user stories that are passing acceptance tests. A user story is deemed completed when and
+ only when it passes all its acceptance tests. Because customer tests are all automated, this task is actually very
+ simple since it only consists of running the automated acceptance test suite and comparing the results against the
+ plan. If 50% (weighted according to cost) of the stories pass acceptance tests, you are 50% done. Hopefully, less than
+ 50% or less of the release has elapsed. If not, it is an indication that the release plan should be revisited.
+</p>
+<p>
+ On a regular basis, the tracker presents the progress the team is making in the release. This information can be
+ presented in the form of a big, visible chart hanging in the team's open workspace. Progress is often presented as the
+ number of stories done vs. planned for the release.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_track_release_progress__activity_definition" name="XE_track_release_progress__activity_definition"></a>
+<ul>
+ <li>
+ Track the progress of the release.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/track_task_completion.xmi b/XP/XP_baseline_EN/library/xp/tasks/track_task_completion.xmi
new file mode 100644
index 0000000..6a70108
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/track_task_completion.xmi
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-0iRnQW0M9QDTNqWNijBB5A" name="track_task_completion,{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C}" guid="-0iRnQW0M9QDTNqWNijBB5A" version="1.0.0">
+ <sections xmi:id="_oON54GE-EdqnIZeW8YpHcA" name=" General " guid="_oON54GE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Prep" name="Prep"></a>
+<p>
+ Ideally tracking stories is much better than tracking tasks even at the iteration level since the stories can be proved
+ to work through the acceptance tests and tasks can't. However, when there are few stories in the iteration, some teams
+ also use tasks to help them gain a sense of progress.
+</p>
+<p>
+ The tracker simply tracks how many tasks have been done during the iteration and how many are left. This information is
+ readily available during the stand-up meetings. Half way through the iteration, the team should have done about half
+ the tasks (in terms of the task cost estimates). If not, it is a sign that the iteration plan needs some tweaking. If
+ the team is not going as fast as planned, the tweaking may consist of removing one of the stories from the iteration.
+ If they are going faster than planned, then the team can ask the customer to bring a new story into the iteration. This
+ is how the team iteration velocity will fluctuate over time.
+</p>
+<p>
+ On a regular basis, the tracker presents the progress the team is making in the iteration. This information can be
+ presented in the form of a big, visible chart hanging in the team's open workspace. Progress is often presented as the
+ number of tasks or stories done vs. planned for the iteration.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_track_iteration_progress__activity_definition" name="XE_track_iteration_progress__activity_definition"></a>
+<ul>
+ <li>
+ Track the progress during the iteration.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/update_iteration_plan.xmi b/XP/XP_baseline_EN/library/xp/tasks/update_iteration_plan.xmi
new file mode 100644
index 0000000..8b5b49b
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/update_iteration_plan.xmi
@@ -0,0 +1,38 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-cU3MzukpGPAtw0wSS23R-g" name="update_iteration_plan,{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC}" guid="-cU3MzukpGPAtw0wSS23R-g" version="1.0.0">
+ <sections xmi:id="_oOzvwmE-EdqnIZeW8YpHcA" name="Gather the Information " guid="_oOzvwmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ The team is responsible for keeping track of its project. Tasks that are completed are marked on the iteration plan. If
+ anyone on the team realizes that the team is behind schedule, at any time, the customer is informed as soon as
+ possible. The customer can then decide how to change the plan. The tracker may be the first to notice that the
+ iteration is in jeopardy. An XP team is considered behind schedule if half the work is not finished halfway through the
+ iteration. Ideally, this could be measured by observing that half the customer tests pass halfway through the
+ iteration.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oOzvw2E-EdqnIZeW8YpHcA" name="Update the Plan " guid="_oOzvw2E-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ When it is likely that not all the stories in the release will be finished, the customer must reduce scope. Extending
+ the iteration is not an option. The customer either removes whole stories or splits stories and removes scope.
+</p>
+<p>
+ When the team has excess capacity in the iteration, the customer is informed. The customer adds additional stories to
+ fill the iteration . Customers like it when this happens.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oOzvxGE-EdqnIZeW8YpHcA" name="Communicate the Plan " guid="_oOzvxGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ The whole team should be made aware of any changes in the iteration plan so they can focus on the right tasks.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_adjust_iteration_scope__activity_definition" name="XE_adjust_iteration_scope__activity_definition"></a>
+<ul>
+ <li>
+ To allow the customer to react to the team underestimating or over estimating the amount of work that can be
+ accomplished in the current iteration.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/update_release_plan.xmi b/XP/XP_baseline_EN/library/xp/tasks/update_release_plan.xmi
new file mode 100644
index 0000000..1d2b2c4
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/update_release_plan.xmi
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-YO16TebjP7U0gkcYg7OY_A" name="update_release_plan,{18BF87E6-5849-4091-AFE2-FC4F0C3887B1}" guid="-YO16TebjP7U0gkcYg7OY_A" version="1.0.0">
+ <sections xmi:id="_oO6dcGE-EdqnIZeW8YpHcA" name="Gather the Information " guid="_oO6dcGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ The most recent count of completed story points in an iteration is the team's velocity. The number of story points
+ completed in an iteration will change over time. Consequently, the team's velocity also changes. If the team's velocity
+ increases, more work can be done in each iteration. If the team's velocity decreases, less work can be done in each
+ iteration.
+</p>
+<p>
+ As the team progresses through the project, the team's understanding of the problem is improved. Customers will add new
+ stories and remove others. Programmers may need to change story estimates. Consequently, the release plan should be
+ revisited periodically (every few iterations or as needed).
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oO6dcWE-EdqnIZeW8YpHcA" name="Update the Plan " guid="_oO6dcWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Using the most recent velocity, the latest story estimates, and the customer's most recent view of priority, a new
+ release plan is established.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oO6dcmE-EdqnIZeW8YpHcA" name="Communicate the Plan " guid="_oO6dcmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ Once the plan is updated, it is critical that the whole team be aware of it. This is usually really easy as the whole
+ team was involved in the revision of the release plan. The plan will show the team the progress they are making
+ (morale), and they will have a clear understanding of the new target they are shooting for (team cohesion).The plan
+ must be realistic and alive.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_revise_release_plan__activity_definition" name="XE_revise_release_plan__activity_definition"></a>
+<ul>
+ <li>
+ Ensure the release plan reflects our improved understanding of the coming releases.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/write_code.xmi b/XP/XP_baseline_EN/library/xp/tasks/write_code.xmi
new file mode 100644
index 0000000..08b902a
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/write_code.xmi
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-kNZQ2Mr_nyfmCboprjMNTg" name="write_code,{8F6CB99A-D2EA-44BB-8CE5-F97220D44088}" guid="-kNZQ2Mr_nyfmCboprjMNTg" version="1.0.0">
+ <sections xmi:id="_oUbPkGE-EdqnIZeW8YpHcA" name=" Get a Pair Programming Partner " guid="_oUbPkGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ Pair Programming is an Extreme Programming best practice. The basic rule regarding pair programming in XP is that all
+ production code is developed in pairs. One programmer has the responsibility to complete a task. That programmer asks
+ other programmers to pair with him to complete the task. The pairings are short term, usually less than half a day.
+ Find a partner who has experience or skill you need to complete your task. Your task may include modifying a database
+ table. Ask the person on the team most knowledgeable to help you effectively use the database API. Later, you might
+ need to display the data in a GUI window, but you have not seen that part of the GUI. Get someone who knows about it to
+ help.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oUbPkWE-EdqnIZeW8YpHcA" name=" Write Failing Test Case " guid="_oUbPkWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ When looking at an Engineering Task, you should consider how to add the capability to the system. Does the system
+ require new classes? Are there classes that would be useful? Regardless of how these decisions come out, the addition
+ of functionality requires the creation of a test case. You write the test case to demonstrate that a portion of the
+ functionality you need isn't in the system. This test case should fail.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oUbPkmE-EdqnIZeW8YpHcA" name=" Write Code to Make Tests Pass " guid="_oUbPkmE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step3" name="Step3"></a>
+<p>
+ When you have a failing test case, you then write only the code that is necessary to satisfy the test case. Test cases
+ should have a very narrow focus. A failing test case may trigger the creation of a new class or method named in the
+ test case, or it may simply require you to add more code to existing classes and methods.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oUbPk2E-EdqnIZeW8YpHcA" name=" Refactor Immediately " guid="_oUbPk2E-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step4" name="Step4"></a>
+<p>
+ After the test case passes, go back and make the code as clean as possible. Have you added code to a method and caused
+ the method to have more than one primary job? If so, extract a method. Has a class grown too large? Consider extracting
+ a class. Have you noticed duplication? Refactor to remove it.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oUbPlGE-EdqnIZeW8YpHcA" name=" Repeat Until Engineering Task is Done " guid="_oUbPlGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step5" name="Step5"></a>
+<p>
+ The preceding three steps should be done in sequence over and over until you and your pair partner are done with the
+ engineering task. It is important to refactor as you go because refactoring, even on a micro-scale, makes additional
+ work easier.
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_write_code__activity_definition" name="XE_write_code__activity_definition"></a>
+<ul>
+ <li>
+ To specify the design of the system in a way which is precise enough to allow computers to generate efficient
+ processes automatically and clear enough for people to understand during ongoing work and maintenance.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/tasks/write_user_story.xmi b/XP/XP_baseline_EN/library/xp/tasks/write_user_story.xmi
new file mode 100644
index 0000000..687e662
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/tasks/write_user_story.xmi
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:TaskDescription 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" epf:version="1.0.0" xmi:id="-cqTu_uwmZrF3sFspx465XQ" name="write_user_story,{62CFC55C-3151-46CB-8886-F3DBD552ABC4}" guid="-cqTu_uwmZrF3sFspx465XQ" version="1.0.0">
+ <sections xmi:id="_oQZEIGE-EdqnIZeW8YpHcA" name=" Define System Behavior " guid="_oQZEIGE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step1" name="Step1"></a>
+<p>
+ A user story is a brief description of a feature of the system. Stories are small, taking only a week or two to
+ develop. The best stories provide direct business value. When stories are too big, they must be split. Consequently, it
+ may take multiple stories to provide business value. In this case, the individual stories need to demonstrate to the
+ customer that the team is making progress toward the desired business value.
+</p>
+<p>
+ There is no need for a lot of detail in the description. The details will be flushed out when the acceptance tests for
+ this story are defined. Typically, XP user stories are written on small index cards, one story per card.
+</p></sectionDescription>
+ </sections>
+ <sections xmi:id="_oQZEIWE-EdqnIZeW8YpHcA" name=" Define Customer Test " guid="_oQZEIWE-EdqnIZeW8YpHcA">
+ <sectionDescription><a id="Step2" name="Step2"></a>
+<p>
+ Each user story will have a set of conditions or acceptance criteria to fulfill before it is considered done.
+ Basically, an acceptance criterion defines an interaction scenario between the user and the system. There is usually
+ more than one possible scenario or acceptance test criterion for a typical story. The acceptance test criteria are
+ converted into <a class="elementLinkWithUserText"
+ href="./../../xp/tasks/automate_acceptance_test,{E614ED93-AE72-4FD1-B459-C508CE1C536F}.html"
+ guid="{E614ED93-AE72-4FD1-B459-C508CE1C536F}">automated customer tests</a> when the story is being implemented.
+</p>
+<p>
+ For simplicity, the test criteria are often written natural language. However, this makes them prone to
+ misinterpretation. To address this issue, some teams provide simple tools that allow the customer to write the
+ acceptance tests criteria in a form that can be executed directly by application-specific acceptance test framework.
+ Ultimately, it is the responsibility of the customer to provide the customer tests
+</p></sectionDescription>
+ </sections>
+ <purpose><a id="XE_write_user_story__activity_definition" name="XE_write_user_story__activity_definition"></a>
+<ul>
+ <li>
+ To specify a specific behavior of the system from a user perspective.
+ </li>
+</ul></purpose>
+</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_build.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_build.xmi
new file mode 100644
index 0000000..94f0f81
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_build.xmi
@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-rphHqeONv59sqZq_6FzE6Q" name="xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" guid="-rphHqeONv59sqZq_6FzE6Q" changeDate="2006-11-08T16:52:31.958-0800" version="1.0.0">
+ <purpose><a id="XE_xp_build__artifact_definition" name="XE_xp_build__artifact_definition"></a><a id="Purpose" name="Purpose"></a><a
+id="XE_xp_build__purpose_of" name="XE_xp_build__purpose_of"></a>
+<p>
+ The purpose of the <a class="PresentationName"
+ href="./../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
+ guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">XP Build</a> is to show demonstrable progress in a running system. Each
+ <a class="PresentationName" href="./../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
+ guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">XP Build</a> incrementally shows new functionality while insuring that
+ previous functionality has not been broken.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_coding_standard.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_coding_standard.xmi
new file mode 100644
index 0000000..56152aa
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_coding_standard.xmi
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-NznKylxa2Y_MG8lACUV9Bw" name="xp_coding_standard,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" guid="-NznKylxa2Y_MG8lACUV9Bw" changeDate="2006-11-09T16:10:06.935-0800" version="1.0.0">
+ <purpose><a id="XE_coding_standard__artifact_definition" name="XE_coding_standard__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_coding_standard__purpose_of" name="XE_coding_standard__purpose_of"></a>
+<p>
+ The purpose of the <a class="PresentationName" guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">Coding Standard</a> is to
+ facilitate communication among programmers working on the same code base. The coding standard takes on added importance
+ in XP because of the pair programming and collective code ownership practices. The objective is to have all parts of
+ the code appear to have been written by the same programmer.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_customer_test.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_customer_test.xmi
new file mode 100644
index 0000000..a8c9449
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_customer_test.xmi
@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-YYMUwBepQ28JU78LtraO3w" name="xp_customer_test,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}" guid="-YYMUwBepQ28JU78LtraO3w" changeDate="2006-11-10T09:27:13.845-0800" version="1.0.0">
+ <keyConsiderations>As more and more customer tests are added to the system, there will be a need to organize them in some way. Typically, the
+testers and programmers will build and maintain some kind of customer test framework. As is the case for the production
+code, it is important to let the framework evolve with the needs of the application. It is very easy to go overboard when
+building a test framework.</keyConsiderations>
+ <purpose><a id="XE_xp_customer_test__artifact_definition" name="XE_xp_customer_test__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_customer_test__purpose_of" name="XE_xp_customer_test__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">XP Customer Test</a> demonstrates the
+ presence of the system features as defined by the customer. They are the unambiguous and detailed requirements of the
+ system.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_iteration_plan.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_iteration_plan.xmi
new file mode 100644
index 0000000..bfe636c
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_iteration_plan.xmi
@@ -0,0 +1,40 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-45BLJONIjGn7h4z87VXqHQ" name="xp_iteration_plan,{DC18E34B-70C1-403D-84CC-1BF117A7473D}" guid="-45BLJONIjGn7h4z87VXqHQ" changeDate="2006-11-13T13:17:43.002-0800" version="1.0.0">
+ <mainDescription><p>
+ The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> contains a list of
+ stories selected to be implemented in the iteration. Each story is broken down into one or more engineering tasks.
+ These tasks are sufficiently small that an individual can grasp its scope and provide a reasonable estimate. Tasks
+ usually range from less than a day to one or two days for a single individual.
+</p>
+<p>
+ The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> is recorded on flip
+ chart paper and hung on the walls of the team's open workspace. Each story for the iteration is written on a piece of
+ flip chart paper and hung on the open workspace wall. The team brainstorms the tasks needed to complete a story. They
+ discuss the story with the customer as needed. The team will sometimes do a quick design session to help them figure
+ out the tasks for a given story. This is repeated for each story in the iteration. Once all stories have been broken
+ down, individuals sign up for tasks, recording their initials and estimate next to the task.
+</p>
+<p>
+ What makes a good <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a>:
+</p>
+<ul>
+ <li>
+ The stories have been broken down into tasks.
+ </li>
+ <li>
+ The tasks have been signed up for and given estimates.
+ </li>
+ <li>
+ Stories are removed from the plan if there is too much to do.
+ </li>
+ <li>
+ Stories are added to the plan if there is not enough to do.
+ </li>
+</ul></mainDescription>
+ <purpose><a id="XE_xp_iteration_plan__artifact_definition" name="XE_xp_iteration_plan__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_iteration_plan__purpose_of" name="XE_xp_iteration_plan__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> steers the efforts
+ of the team during the iteration.<br />
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_metaphor.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_metaphor.xmi
new file mode 100644
index 0000000..cfa7c32
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_metaphor.xmi
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-sQUFozEqR3Gpa5PnCjFh9Q" name="xp_metaphor,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}" guid="-sQUFozEqR3Gpa5PnCjFh9Q" changeDate="2006-11-08T16:23:13.847-0800" version="1.0.0">
+ <purpose><a id="XE_metaphor_(system_of_names)__artifact_definition" name="XE_metaphor_(system_of_names)__artifact_definition"></a><a
+id="Purpose" name="Purpose"></a><a id="XE_metaphor_(system_of_names)__purpose_of"
+name="XE_metaphor_(system_of_names)__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">Metaphor (System of Names)</a> or System
+ of Names allows the team to talk about the structure of the software in a convenient and memorable way.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_production_code.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_production_code.xmi
new file mode 100644
index 0000000..473ee39
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_production_code.xmi
@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-f1cDEBpC5wbDTQ9ru9UbLw" name="xp_production_code,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" guid="-f1cDEBpC5wbDTQ9ru9UbLw" changeDate="2006-11-13T13:21:51.018-0800" version="1.0.0">
+ <mainDescription><p>
+ This definition of <a class="PresentationName" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a>
+ encompasses hand-coded software as well as executable models. The <a class="PresentationName"
+ guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a> must be kept clean and simple, as it is the main
+ vehicle for communicating design intent to the programming team. The code has comprehensive customer and unit tests.
+ The XP practices of simple design, pair programming, refactoring, collective code ownership, test driven development,
+ and coding standard support the creation of the code.
+</p></mainDescription>
+ <purpose><a id="XE_production_code__artifact_definition" name="XE_production_code__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_production_code__purpose_of" name="XE_production_code__purpose_of"></a>
+<p>
+ In XP, we consider <a class="PresentationName" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a> to be
+ the most important artifact. It is the one design artifact that cannot be replaced because it is the only complete and
+ unambiguous expression of design intent. Source code is a specification. It, along with a compiler or interpreter,
+ encompasses all of the semantics necessary to produce a running process on a computer.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_release_plan.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_release_plan.xmi
new file mode 100644
index 0000000..c627fa1
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_release_plan.xmi
@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-mMZ9KUhiFwBbzSFjq_tO4A" name="xp_release_plan,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" guid="-mMZ9KUhiFwBbzSFjq_tO4A" changeDate="2005-12-02T07:44:11.027-0800" version="1.0.0">
+ <purpose><a id="XE_xp_release_plan__artifact_definition" name="XE_xp_release_plan__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_release_plan__purpose_of" name="XE_xp_release_plan__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">XP Release Plan</a> is the longer term
+ project view. It organizes estimated stories into iterations and groups iterations into releases. The releases defined
+ by the customer contain enough value to deliver the software to the end users of the product. The bias in ordering
+ stories and defining releases is to deliver the most business value possible by the release date.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_unit_test.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_unit_test.xmi
new file mode 100644
index 0000000..1db0e19
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_unit_test.xmi
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-dwfXb2dWJOQkTuLo-BTFeQ" name="xp_unit_test,{D156652E-7C52-4EBD-8F23-F38169877A57}" guid="-dwfXb2dWJOQkTuLo-BTFeQ" changeDate="2006-11-13T13:57:02.728-0800" version="1.0.0">
+ <mainDescription><p>
+ <a class="PresentationName" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a>s are usually implemented at
+ the class level (in OO languages) and test the public interface. For every class in the system, a test class exists.
+ Popular test frameworks are available usually for free (such as JUnit, CppUnit, CppUnitLite, NUnit). These are simple
+ tools that help the developer to organize and run unit tests. These tests drive the programmer development and tell the
+ programmer that the code works as the programmer expects.
+</p></mainDescription>
+ <purpose><a id="XE_xp_unit_test__artifact_definition" name="XE_xp_unit_test__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_unit_test__purpose_of" name="XE_xp_unit_test__purpose_of"></a>
+<p>
+ An <a class="PresentationName" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a> is written by developers
+ to ensure that all system components work as expected. <a class="PresentationName"
+ guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a> give the developers the confidence to modify the system
+ and feel confident that everything still works.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_user_story.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_user_story.xmi
new file mode 100644
index 0000000..e5afb80
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_user_story.xmi
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-rtY57MTVQrEcfTKwD3-Wvw" name="xp_user_story,{21946731-4F5C-4862-8B4D-868629952B92}" guid="-rtY57MTVQrEcfTKwD3-Wvw" changeDate="2006-11-13T14:28:55.298-0800" version="1.0.0">
+ <mainDescription><p>
+ A <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> is only a token of past and
+ future conversation between the customer and the programmers. XP's on-site customer practice minimizes the need to
+ document extensively each story as the programmers can simply walk over and ask their questions to the customer as
+ needed. <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> details are captured
+ in automated acceptance tests that are then used to validate the implementation of the story.
+</p>
+<p>
+ It may not be necessary to write a description for all stories as the name of some of the stories might already offer
+ enough information.
+</p>
+<p>
+ What makes a good <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a>?
+</p>
+<ul>
+ <li>
+ The customer should care about it. The story should have business value in the customer's eyes so it can be
+ prioritized. Sometimes a story needs to be broken down into smaller pieces to fit into an iteration. If by itself
+ the story does not provide business value, it should at least provide demonstrable progress toward a feature with
+ business value.
+ </li>
+ <li>
+ Stories vertically slice through the product's architecture. They are not usually focused on a specific subsystem.
+ </li>
+ <li>
+ Test cases can be written to verify that the programmers have implemented it correctly.
+ </li>
+ <li>
+ It can be reasonably estimated by the developers. Stories that can't be estimated are rewritten.
+ </li>
+ <li>
+ It can be completed within one iteration. A story that does not fit in an iteration is broken down into two or more
+ smaller stories.
+ </li>
+</ul></mainDescription>
+ <purpose><a id="XE_user_story__artifact_definition" name="XE_user_story__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_user_story__purpose_of" name="XE_user_story__purpose_of"></a>
+<p>
+ A <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> represents a small piece of
+ functionality of the system being built. It is not a complete specification of a feature. It is a promise to discuss a
+ feature or a reminder of the discussion that has already taken place.
+</p></purpose>
+ <representationOptions><p>
+ Here are some sample stories for a typical on-line store application:
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ If the customer has entered a valid Tax Exemption ID, do not charge sales tax.
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ If the Customer ID is on the Preferred Customer list, do not charge for shipping, except for Next Day service.
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ On the System Status Page, show the number of orders in the past 24 hours, the total revenue, and list the top ten
+ items in order of quantity ordered.
+</p>
+<p>
+ --------------------------------------------------------------------------------<br />
+ If the delivery address of a purchase is in any of the states in the attached table, calculate, display, and charge
+ sales tax using the corresponding percentage.
+</p></representationOptions>
+</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/XP_baseline_EN/library/xp/workproducts/xp_vision.xmi b/XP/XP_baseline_EN/library/xp/workproducts/xp_vision.xmi
new file mode 100644
index 0000000..892bb7d
--- /dev/null
+++ b/XP/XP_baseline_EN/library/xp/workproducts/xp_vision.xmi
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<org.eclipse.epf.uma:ArtifactDescription 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" epf:version="1.0.0" xmi:id="-ZUxMgSWqLlaO5p1r1-ug6Q" name="xp_vision,{2300FB25-7249-4481-A1BD-978240906832}" guid="-ZUxMgSWqLlaO5p1r1-ug6Q" changeDate="2006-11-10T08:46:22.508-0800" version="1.0.0">
+ <purpose><a id="XE_xp_vision__artifact_definition" name="XE_xp_vision__artifact_definition"></a><a id="Purpose"
+name="Purpose"></a><a id="XE_xp_vision__purpose_of" name="XE_xp_vision__purpose_of"></a>
+<p>
+ The <a class="PresentationName" guid="{2300FB25-7249-4481-A1BD-978240906832}">XP Vision</a> consists of very high-level
+ requirements. It communicates to the team a common understanding of the project and is a gauge against which all future
+ decisions should be validated. It will guide the team during the development cycle.
+</p></purpose>
+</org.eclipse.epf.uma:ArtifactDescription>
