<?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>&lt;h3&gt; Introduction &lt;/h3&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; The activities performed in a typical iteration during&amp;nbsp;the 
  Elaboration phase are described below. &lt;/p&gt;
&lt;h4&gt; Manage iteration &lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; 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; 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. &lt;/p&gt;
&lt;p&gt; As the iteration runs, the project manager performs 
  monitoring and control of&amp;nbsp;the project  by regularly checking the 
  status of work completed, the work to do 
  next, and issues blocking the progress&lt;strong&gt;. 
  &lt;/strong&gt;In some projects, this checking occurs 
  in daily meetings, which allows for a&amp;nbsp;more precise&amp;nbsp;understanding 
  of how the work in an iteration is progressing. As 
  needed, the&amp;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.&lt;/p&gt;
&lt;p&gt;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,_dTa6gMAYEdqX-s4mWhkyqQ.html&quot; guid=&quot;_dTa6gMAYEdqX-s4mWhkyqQ&quot;&gt;stakeholders&lt;/a&gt;, 
  and the remaining team members agree on what is supposed to be developed during 
  that iteration.&lt;/p&gt;
&lt;p&gt;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&amp;nbsp;help the project manager produce more accurate estimates 
  for the project schedule and cost.&lt;/p&gt;
&lt;h4&gt; Manage requirements &lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; 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.&lt;/p&gt;
&lt;p&gt;&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0ZS-0MlgEdmt3adZL5Dmdw&quot;&gt;Test 
  cases&lt;/a&gt; describe which&amp;nbsp;requirements are being tested&amp;nbsp;in that iteration. 
&lt;/p&gt;
&lt;p&gt; &lt;strong&gt;Note: &lt;br /&gt;
  &lt;br/&gt;
  &lt;/strong&gt;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. &lt;/p&gt;
&lt;h4&gt; Define the architecture &lt;/h4&gt;
&lt;p&gt; This activity is repeated in each iteration in the 
  Elaboration phase. The main&amp;nbsp;goal of this activity is&amp;nbsp;to propose an 
  &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;&gt;architecture&lt;/a&gt; 
  that addresses the requirements with high architectural risks, thus providing 
  a solid, yet resilient, foundation on which to build the system functionality.&lt;/p&gt;
&lt;p&gt; The &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/roles/architect,_0X9iEMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;&gt;architect&lt;/a&gt; 
  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. &lt;/p&gt;
&lt;p&gt; Throughout all of the iterations, the architect: &lt;/p&gt;
&lt;ul&gt;
    
  &lt;li&gt; Identifies commonalities between different requirements to leverage reuse 
  &lt;/li&gt;
  &lt;li&gt; Defines strategies for achieving requirements related 
    to quality&lt;/li&gt;
  &lt;li&gt; Captures and communicates architectural decisions &lt;/li&gt;
&lt;/ul&gt;
&lt;h4&gt; Develop solution for requirement within context&lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; As the requirements planned for the iteration are broken down into development 
  tasks, these are assigned by the project managers 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; 
  (some project teams prefer to have team members sign up for development tasks 
  themselves). &lt;/p&gt;
&lt;p&gt; 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&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/developer_test,_0YuXEclgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YuXEclgEdmt3adZL5Dmdw&quot;&gt;tests&lt;/a&gt; 
  and integrate their work to create &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;&gt;builds&lt;/a&gt;. 
&lt;/p&gt;
&lt;h4&gt; Validate build &lt;/h4&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;p&gt; 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 
  &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/tester,_0ZM4MclgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;&gt;tester&lt;/a&gt; 
  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 &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/guidelines/test_suite,_0aDz0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0aDz0MlgEdmt3adZL5Dmdw&quot;&gt;test 
  suites&lt;/a&gt; to create. As tests are performed, defects found are reported and 
  added to 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;, so they can be prioritized and assigned to team members. &lt;/p&gt;
&lt;h4&gt; Ongoing tasks &lt;/h4&gt;
&lt;p&gt; 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, &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0dsWoMlgEdmt3adZL5Dmdw&quot;&gt;any 
  role&lt;/a&gt; in the project team can issue a &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.html&quot; guid=&quot;_6jdvECb3Edqh1LYUOGRh2A&quot;&gt;change 
  request&lt;/a&gt;, 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. &lt;/p&gt;
&lt;h4&gt;&amp;nbsp; &lt;/h4&gt;</mainDescription>
  </org.eclipse.epf.uma:ProcessDescription>
</xmi:XMI>