blob: 0a44854c6b28aa3eca8e7b0bffeded7d4412325b [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" 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; 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;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;