| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0"> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="-np5opRV1lFI1-STOvbIHxQ" guid="-np5opRV1lFI1-STOvbIHxQ"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="-QDJDn4UQ16RuW3eUw5Od-Q" guid="-QDJDn4UQ16RuW3eUw5Od-Q"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="-CQw8MDwZufSscoT_i8rXCA" guid="-CQw8MDwZufSscoT_i8rXCA"/> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-P77zVL7pDd6au5_9EtGSKw" guid="-P77zVL7pDd6au5_9EtGSKw"> |
| <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.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.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 projects. The
 |
| project is then closed.
 |
| </p>
 |
| <h4>
 |
| Ongoing tasks
 |
| </h4>
 |
| <p>
 |
| Submission of change requests during the Transition phase 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.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.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-2.html" guid="_0nz79clgEdmt3adZL5Dmdw">tests</a> to accept the release.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| </xmi:XMI> |
