<?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>&lt;h3&gt; Introduction&amp;nbsp; &lt;/h3&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; The activities performed in a typical iteration during 
  the&amp;nbsp;Transition phase are described below. &lt;/p&gt;
&lt;h4&gt; Manage iteration &lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; Similar to other phases, this is an activity led by the &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;&gt;project 
  manager&lt;/a&gt; (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&amp;nbsp;while delivering 
  the product to the end users. &lt;/p&gt;
&lt;p&gt;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&lt;em&gt;,&lt;/em&gt; and &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html&quot; guid=&quot;_dTa6gMAYEdqX-s4mWhkyqQ&quot;&gt;stakeholders'&lt;/a&gt; 
  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 
  &lt;strong&gt; &lt;/strong&gt;projects. The project is then closed.&lt;/p&gt;
&lt;h4&gt;Ongoing tasks &lt;/h4&gt;
&lt;p&gt; Submission of change requests during the Transition phase &lt;strong&gt;&lt;/strong&gt;works&amp;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 &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;&gt;work 
  items list&lt;/a&gt; and allocated to a future release, when a new software development 
  lifecycle begins. In that case, requirements will be outlined and detailed accordingly. 
&lt;/p&gt;
&lt;p&gt; However, defects are typically dealt with during the Transition phase,&amp;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. &lt;/p&gt;
&lt;h4&gt; Develop solution for requirement within context&lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; 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 &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;&gt;developers&lt;/a&gt;. 
&lt;/p&gt;
&lt;h4&gt; Validate build &lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; 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 &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/capabilitypatterns/test,_0nz79clgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0nz79clgEdmt3adZL5Dmdw&quot;&gt;tests&lt;/a&gt; 
  to accept the release. &lt;/p&gt;
&lt;h4&gt;</mainDescription>
  </org.eclipse.epf.uma:ProcessDescription>
</xmi:XMI>