<?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="-TQ9RjtJTg0MR2efBfgHiIA" guid="-TQ9RjtJTg0MR2efBfgHiIA"/>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-mtOCZ9R7aI3MfGjZONQv9g" guid="-mtOCZ9R7aI3MfGjZONQv9g"/>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-zGhm1HDpCKkeAXLoRUrHXA" guid="-zGhm1HDpCKkeAXLoRUrHXA"/>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-dzM5cRaXm0v_-cjJNmReSQ" guid="-dzM5cRaXm0v_-cjJNmReSQ"/>
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-BN72ggQo2vifgzMrr3hX3A" guid="-BN72ggQo2vifgzMrr3hX3A">
    <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Most activities during a typical iteration in Elaboration phase happen in parallel. Essentially, the main objectives&#xD;
    for Elaboration are related to better understanding the requirements, creating and establishing a baseline for the&#xD;
    architecture for the system, and mitigating top-priority risks.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The activities performed in a typical iteration during&amp;nbsp;the Elaboration phase are described below.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Manage iteration&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This activity is performed throughout the project lifecycle. The goal of this activity is to identify risks and issues&#xD;
    early enough that they can be mitigated, to establish the goals for the iteration, and to support the development team&#xD;
    in reaching these goals.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>project manager&lt;/a> and the team launche the iteration, allocating work items to team&#xD;
    members (some project teams will prefer to have members volunteer to perform work). The project manager collaborates&#xD;
    with the team to break down the work items into development tasks to perform in that iteration. This provides a more&#xD;
    accurate estimate of time to spend on what can be realistically achieved.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As the iteration runs, the project manager performs monitoring and control of&amp;nbsp;the project by regularly checking&#xD;
    the status of work completed, the work to do next, and issues blocking the progress&lt;strong>.&lt;/strong> In some projects,&#xD;
    this checking occurs in daily meetings, which allows for a&amp;nbsp;more precise&amp;nbsp;understanding of how the work in an&#xD;
    iteration is progressing. As needed, the&amp;nbsp;team makes corrections to achieve what was planned. The overall idea is&#xD;
    that risks and issues are identified and managed throughout the iteration. and everyone knows the project status.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The prioritization of work for a given iteration takes place. Project manager,&amp;nbsp;&lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/stakeholder.html&quot; guid=&quot;_dTa6gMAYEdqX-s4mWhkyqQ&quot;>stakeholders&lt;/a>, and the remaining team members agree on what is supposed to be&#xD;
    developed during that iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As in any other iteration assessment, demonstration of implemented functionality planned for that iteration is the key&#xD;
    success criterion. During iteration assessments in Elaboration, though, keep the phase objectives in mind. As&#xD;
    Elaboration iterations are performed, an executable architecture evolves, and you establish a baseline at the end of&#xD;
    the phase. In addition, requirements are better understood and detailed. Essential risks, including the architectural&#xD;
    ones, have been mitigated. These results&amp;nbsp;help the project manager produce more accurate estimates for the project&#xD;
    schedule and cost.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Manage requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This activity is repeated throughout the project lifecycle. The goal of this activity is to understand and prioritize&#xD;
    stakeholder needs and associated requirements for the system, and also to capture these in a form that supports&#xD;
    effective communication and collaboration between the stakeholders and development team.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    During the Elaboration phase, requirements can still be captured and outlined as customer needs arise. The&#xD;
    prioritization of requirements determines when new requirements are going to be implemented. High-risk, architecturally&#xD;
    significant requirements are detailed to the extent necessary to be able to use that information as input to&#xD;
    architecture and development activities in the current iteration, plus in planning for the next iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/test_case-2.html&quot; guid=&quot;_0ZS-0MlgEdmt3adZL5Dmdw&quot;>Test cases&lt;/a> describe which&amp;nbsp;requirements are being tested&amp;nbsp;in that iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Note:&lt;br />&#xD;
    &lt;br />&#xD;
    &lt;/strong> The emphasis on finding, outlining and detailing requirements varies from phase to phase. Iterations in&#xD;
    Inception and early Elaboration tend to focus more on identifying and outlining requirements in general and on&#xD;
    detailing high-priority and architecturally significant requirements. During iterations in late Elaboration and early&#xD;
    Construction, the remaining requirements are usually outlined and detailed.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Define the architecture&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This activity is repeated in each iteration in the Elaboration phase. The main&amp;nbsp;goal of this activity is&amp;nbsp;to&#xD;
    propose an &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/architecture.html&quot; guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;>architecture&lt;/a> that addresses the requirements with high architectural risks, thus&#xD;
    providing a solid, yet resilient, foundation on which to build the system functionality.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/roles/architect.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>architect&lt;/a> analyzes the architectural constraints, identifies available assets to&#xD;
    build the system, defines how the system will be structured, and identifies the initial abstractions and mechanisms&#xD;
    that must be provided by the architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Throughout all of the iterations, the architect:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Identifies commonalities between different requirements to leverage reuse&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defines strategies for achieving requirements related to quality&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Captures and communicates architectural decisions&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Develop solution for requirement within context&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This activity is instantiated multiple times, in parallel, for each development task planned for that iteration. The&#xD;
    main goal of this activity is an executable system that provides the incremental quality and functionality for the&#xD;
    specified requirements within the specified context.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As the requirements planned for the iteration are broken down into development tasks, these are assigned by the project&#xD;
    managers to &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/developer.html&quot; guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;>developers&lt;/a> (some project teams prefer to have team members sign up for development&#xD;
    tasks themselves).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The solution to be developed is for a particular requirement within a context, which reflects the idea of breaking down&#xD;
    requirements into development tasks. As an example, a particular use-case scenario within the context of database&#xD;
    access could be assigned to a developer; whereas, the same scenario within the user interface and business logic&#xD;
    contexts could be assigned to a different developer. In this example, more than one developer is working on a&#xD;
    particular piece of functionality to be delivered in a particular iteration. As they develop the requirement within the&#xD;
    context they were assigned to, they perform&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/developer_test.html&quot; guid=&quot;_0YuXEclgEdmt3adZL5Dmdw&quot;>tests&lt;/a> and integrate their work to create &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/build.html&quot; guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;>builds&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Validate build&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This activity is repeated throughout the project lifecycle. The main goal of this activity is to validate the current&#xD;
    increment of the system against the requirements allocated to it.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The intent is to validate that the high-priority requirements implemented reflect a robust architecture so that&#xD;
    remaining requirements can be implemented on top of that architecture. As developer develop the solution for the&#xD;
    requirements in a given iteration, the integrated source code is unit-tested. Then, a separate &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/tester.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;>tester&lt;/a> conducts system-level testing in parallel with development to make sure that&#xD;
    the solution, which is continuously being integrated, matches what is specified in the requirements. Then, the tester&#xD;
    defines what techniques to use, what the data input is, what &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/guidelines/test_suite.html&quot; guid=&quot;_0aDz0MlgEdmt3adZL5Dmdw&quot;>test suites&lt;/a> to create. As tests are performed, defects found are reported and added&#xD;
    to the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/work_items_list.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>work items list&lt;/a>, so they can be prioritized and assigned to team members.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Ongoing tasks&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This activity includes tasks that happen throughout the iteration on an ongoing basis but are not necessarily part of a&#xD;
    plan. For example, at any time, &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/any_role.html&quot; guid=&quot;_0dsWoMlgEdmt3adZL5Dmdw&quot;>any role&lt;/a> in&#xD;
    the project team can issue a &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/concepts/change_requests.html&quot; guid=&quot;_6jdvECb3Edqh1LYUOGRh2A&quot;>change request&lt;/a>, either because there are requests for enhancements, or defects are&#xD;
    found. These change requests are part of the work items list and are prioritized and assigned to team members. Anyone&#xD;
    can be assigned to make changes that develop enhancements or fix defects.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &amp;nbsp;&#xD;
&lt;/h4></mainDescription>
  </org.eclipse.epf.uma:ProcessDescription>
</xmi:XMI>