<?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="-OC3td1csl7lqV15vimYOaw" guid="-OC3td1csl7lqV15vimYOaw"/>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-C3RmtvThtego5U5cOk8uCA" guid="-C3RmtvThtego5U5cOk8uCA"/>
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-239OBD2wagT2qp8fuPWcHQ" guid="-239OBD2wagT2qp8fuPWcHQ">
    <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
Iterations in Construction phase have a work breakdown structure (WBS) similar to iterations in the Elaboration phase, with
activities happening in parallel. There is a different&amp;nbsp;emphasis on how activities&amp;nbsp;address the phase objectives,
though. 
&lt;p&gt;
    The &lt;a href=&quot;./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;&gt;architecture&lt;/a&gt; is expected to be stable when this phase starts, allowing the remaining
    requirements to be implemented on top of it. Another advantage of validating the architecture and eliminating as many
    risks as possible during Elaboration is to provide more predictability in Construction, which allows 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; to focus on team efficiency and cost reduction.
&lt;/p&gt;
&lt;p&gt;
    Functionality is continuously implemented, tested, and integrated, resulting in &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;&gt;builds&lt;/a&gt;
    that are more and more complete and stable. A beta or prerelease may be deployed to a sampling of the intended audience
    at the end of Construction. Delivery of the actual release is the main focus of the next phase.
&lt;/p&gt;
&lt;p&gt;
    The activities performed in a typical iteration during&amp;nbsp;Construction phase are described after the following
    introductions to each activity.
&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 to mitigate them, to establish the goals for the iteration, and to support the development team in
    reaching these goals.
&lt;/p&gt;
&lt;p&gt;
    Similarly to other phases, the project manager (supported by the team) launches the iteration, allocates work, tracks
    status, and handles issues and risks. Although the high-priority and architecturally significant risks were mitigated
    during Elaboration, new risks may appear during Construction, such as not having the right amount of resources to
    obtain the desired degree of parallel&amp;nbsp;development.
&lt;/p&gt;
&lt;p&gt;
    The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements)
    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;
    At the end of the iteration, the team performs an iteration assessment. The goal is to conduct a retrospective review
    of the iteration that is ending. As part of this assessment, the objectives for the Construction phase are expected to
    be demonstrated by the beta-quality release of the software, thus supporting the possibility of transitioning the
    software to its end users.
&lt;/p&gt;
&lt;h4&gt;
    Manage requirements
&lt;/h4&gt;
&lt;p&gt;
    This activity is repeated throughout the lifecycle. The goal of this activity is to understand and prioritize
    stakeholder needs and associated requirements for the system, as well as to capture these in a form that will support
    effective communication and collaboration between the stakeholders and the development team.
&lt;/p&gt;
&lt;p&gt;
    During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated
    (through a working architecture) during Elaboration.
&lt;/p&gt;
&lt;p&gt;
    During the Construction phase, requirements management demands less time from the &lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0VxJsMlgEdmt3adZL5Dmdw&quot;&gt;analyst&lt;/a&gt;.
    There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned 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;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;h4&gt;
    Develop solution
&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;
    The architecture &amp;nbsp;was proposed and a baseline established at the end of Elaboration. Critical requirements were
    expected to be implemented, tested, and integrated as part of the baseline architecture. As the remaining requirements
    are implemented during Construction, the Architect identifies commonalities among solutions being developed by the
    various developers and leverages reuse where possible. Some degree of refactoring of the architecture may be needed to
    accommodate putting common pieces together.
&lt;/p&gt;
&lt;p&gt;
    A pattern similar to the Elaboration phase happens during Construction when it comes to breaking down requirements into
    development tasks and assigning each requirement within a context to a developer. Requirements at this stage are mostly
    of medium-to-low level of risk, but usually they represent the largest slice from the total amount of requirements to
    be implemented in a project. Thus, it is expected that this activity is repeated, or instantiated, multiple times (once
    per requirement within context),&amp;nbsp;thus allowing&amp;nbsp;parallel development. &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/guidelines/continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ.html&quot; guid=&quot;_i8bUEL6cEdqti4GwqTkbsQ&quot;&gt;Continuous integration&lt;/a&gt; allows functionality to be added to the code base constantly,
    which helps the achievement of more and more complete &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0YuXEMlgEdmt3adZL5Dmdw&quot;&gt;builds&lt;/a&gt;
    of the software.
&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;
    Similarly to Elaboration, this activity happens in parallel with the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/capabilitypatterns/develop_solution,_h2-iAfimEdmugcVr9AdHjQ.html&quot; guid=&quot;_h2-iAfimEdmugcVr9AdHjQ&quot;&gt;develop solution&lt;/a&gt; activity. The intent is to validate that a stable beta release is
    achieved and that users can perform acceptance tests.
&lt;/p&gt;
&lt;h4&gt;
    Ongoing tasks
&lt;/h4&gt;
&lt;p&gt;
    Similarly to any other phase, &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; on
    the team can submit &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html&quot; guid=&quot;_fnZj0NVXEdqy9sbRhejO5Q&quot;&gt;change requests&lt;/a&gt;. The software being developed is achieving beta quality by this
    point; therefore, defects of high priority&amp;nbsp;are generally&amp;nbsp;addressed during Construction iterations&amp;nbsp;and
    Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next
    release of the product.
&lt;/p&gt;</mainDescription>
  </org.eclipse.epf.uma:ProcessDescription>
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"/>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"/>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-y0fMHq2z6qGyUlEC8ptYCQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-y0fMHq2z6qGyUlEC8ptYCQ">
    <mainDescription>&lt;h3&gt; Introduction &lt;/h3&gt;
&lt;p&gt; Project managers use this Capability Pattern&amp;nbsp;as a way to&amp;nbsp;perform 
  a goal-based planning and management. Work is assigned to developers and work 
  progress is tracked&amp;nbsp;based on the goals to be achieved using 
  the designed, unit-tested, and&amp;nbsp;integrated&amp;nbsp;source code. &lt;/p&gt;
&lt;h4&gt; Context of what is being developed &lt;/h4&gt;
&lt;p&gt; A context can be specified when a requirement is assigned to be developed, 
  thus specifying how broadly a requirement is to be developed in a iteration. 
  Development&amp;nbsp;may focus&amp;nbsp;on a layer (such as the user interface, business 
  logic, or&amp;nbsp;database access),&amp;nbsp;on a component, and so on. &lt;/p&gt;
&lt;p&gt; Whether a context is specified or not, the developer's 
  responsibility is to create a design and implementation for that requirement, 
  then to&amp;nbsp;write and run unit tests against the implementation to make sure 
  the&amp;nbsp;implementation works as designed, both as a unit&amp;nbsp;and&amp;nbsp;integrated 
  into the code base. &lt;/p&gt;
&lt;h4&gt; Overview of workflow &lt;/h4&gt;
&lt;p&gt; To accommodate major changes or&amp;nbsp;major functionality to be developed, 
  architecture may have to be refined. Small changes and functionality may reflect 
  changes on the design only, with no need to refine the architecture. For trivial 
  changes and functionality to be developed, only the source code may be affected. 
  &lt;/p&gt;
&lt;p&gt; In any case, there is no strict sequence for how writing code and creating 
  or running &amp;nbsp;developer tests should happen, because they can happen in parallel.&amp;nbsp;You 
  may choose to create and run developer tests before the actual code is created 
  or the reverse sequence.&lt;/p&gt;</mainDescription>
    <purpose>&lt;ul&gt;
  &lt;li&gt; &lt;strong&gt;For developers: &lt;/strong&gt;To create a solution for the requirement 
    assigned to them &lt;/li&gt;
  &lt;li&gt; &lt;strong&gt;For project managers: &lt;/strong&gt;To have a goal-based way of assigning 
    work and tracking project status &lt;/li&gt;
&lt;/ul&gt;</purpose>
  </org.eclipse.epf.uma:ActivityDescription>
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-q-X9OHGNRjU5gIyWVibSGQ" version="1.0.0">
    <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
&lt;p&gt;
    Project managers use this Capability Pattern&amp;nbsp;as a way to&amp;nbsp;perform a goal-based planning and management. Work
    is assigned to developers and work progress is tracked&amp;nbsp;based on the goals to be achieved using the designed,
    unit-tested, and&amp;nbsp;integrated&amp;nbsp;source code.
&lt;/p&gt;
&lt;h4&gt;
    Context of what is being developed
&lt;/h4&gt;
&lt;p&gt;
    A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
    to be developed in a iteration. Development&amp;nbsp;may focus&amp;nbsp;on a layer (such as the user interface, business logic,
    or&amp;nbsp;database access),&amp;nbsp;on a component, and so on.
&lt;/p&gt;
&lt;p&gt;
    Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
    requirement, then to&amp;nbsp;write and run unit tests against the implementation to make sure the&amp;nbsp;implementation
    works as designed, both as a unit&amp;nbsp;and&amp;nbsp;integrated into the code base.
&lt;/p&gt;
&lt;h4&gt;
    Overview of workflow
&lt;/h4&gt;
&lt;p&gt;
    To accommodate major changes or&amp;nbsp;major functionality to be developed, architecture may have to be refined. Small
    changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
    changes and functionality to be developed, only the source code may be affected.
&lt;/p&gt;
&lt;p&gt;
    In any case, there is no strict sequence for how writing code and creating or running &amp;nbsp;developer tests should
    happen, because they can happen in parallel.&amp;nbsp;You may choose to create and run developer tests before the actual
    code is created or the reverse sequence.
&lt;/p&gt;</mainDescription>
    <purpose>&lt;ul&gt;
    &lt;li&gt;
        For developers: To create a solution for the requirement assigned to them
    &lt;/li&gt;
    &lt;li&gt;
        For project managers: To have a goal-based way of assigning work and tracking project status
    &lt;/li&gt;
&lt;/ul&gt;</purpose>
    <usageNotes>&lt;p&gt;
    This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each
    requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to
    be assigned to a developer, and it should be renamed to include the actual requirement name.&amp;nbsp;Optionally, the word
    &lt;strong&gt;Solution&lt;/strong&gt; may be suppressed, then you can instantiate the pattern this way:
&lt;/p&gt;
&lt;blockquote&gt;
    &lt;p align=&quot;left&quot;&gt;
        Develop &lt;font face=&quot;Courier New, Courier, mono&quot;&gt;requirement_name&lt;/font&gt; (within &lt;font         face=&quot;Courier New, Courier, mono&quot;&gt;context_name&lt;/font&gt; context)
    &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    If&amp;nbsp;a context&amp;nbsp;is specified, there will be one instance of this pattern for each requirement&amp;nbsp;for each
    context.
&lt;/p&gt;
&lt;blockquote&gt;
    &lt;p&gt;
        &lt;strong&gt;Example&lt;/strong&gt;
    &lt;/p&gt;
    &lt;ol&gt;
        &lt;li&gt;
            Develop &lt;font face=&quot;Courier New, Courier, mono&quot;&gt;scenario 1&lt;/font&gt; (within &lt;font             face=&quot;Courier New, Courier, mono&quot;&gt;user interface&lt;/font&gt; context)
        &lt;/li&gt;
        &lt;li&gt;
            Develop &lt;font face=&quot;Courier New, Courier, mono&quot;&gt;scenario 1&lt;/font&gt; (within &lt;font             face=&quot;Courier New, Courier, mono&quot;&gt;business logic and DB access&lt;/font&gt; context)
        &lt;/li&gt;
        &lt;li&gt;
            Develop &lt;font face=&quot;Courier New, Courier, mono&quot;&gt;scenario 2&lt;/font&gt;
        &lt;/li&gt;
        &lt;li&gt;
            Develop &lt;font face=&quot;Courier New, Courier, mono&quot;&gt;supplemental requirement 1&lt;/font&gt;
        &lt;/li&gt;
    &lt;/ol&gt;
&lt;/blockquote&gt;
&lt;p&gt;
    Note that there are four instances of this pattern in the preceding example:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        The first two are related to the same requirement (scenario 1) but within two different contexts
    &lt;/li&gt;
    &lt;li&gt;
        The last two are related to different requirements, with no context specified.
    &lt;/li&gt;
&lt;/ul&gt;</usageNotes>
  </org.eclipse.epf.uma:ProcessDescription>
  <org.eclipse.epf.uma:ActivityDescription xmi:id="-q-X9OHGNRjU5gIyWVibSGQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="-q-X9OHGNRjU5gIyWVibSGQ" version="1.0.0">
    <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
&lt;p&gt;
    Project managers use this Capability Pattern&amp;nbsp;as a way to&amp;nbsp;perform a goal-based planning and management. Work
    is assigned to developers and work progress is tracked&amp;nbsp;based on the goals to be achieved using the designed,
    unit-tested, and&amp;nbsp;integrated&amp;nbsp;source code.
&lt;/p&gt;
&lt;h4&gt;
    Context of what is being developed
&lt;/h4&gt;
&lt;p&gt;
    A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is
    to be developed in a iteration. Development&amp;nbsp;may focus&amp;nbsp;on a layer (such as the user interface, business logic,
    or&amp;nbsp;database access),&amp;nbsp;on a component, and so on.
&lt;/p&gt;
&lt;p&gt;
    Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
    requirement, then to&amp;nbsp;write and run unit tests against the implementation to make sure the&amp;nbsp;implementation
    works as designed, both as a unit&amp;nbsp;and&amp;nbsp;integrated into the code base.
&lt;/p&gt;
&lt;h4&gt;
    Overview of workflow
&lt;/h4&gt;
&lt;p&gt;
    To accommodate major changes or&amp;nbsp;major functionality to be developed, architecture may have to be refined. Small
    changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial
    changes and functionality to be developed, only the source code may be affected.
&lt;/p&gt;
&lt;p&gt;
    In any case, there is no strict sequence for how writing code and creating or running &amp;nbsp;developer tests should
    happen, because they can happen in parallel.&amp;nbsp;You may choose to create developer tests and run them before the actual
    code is created or the reverse sequence.
&lt;/p&gt;</mainDescription>
    <purpose>&lt;ul&gt;
    &lt;li&gt;
        For developers: To create a solution for the requirement assigned to them
    &lt;/li&gt;
    &lt;li&gt;
        For project managers: To have a goal-based way of assigning work and tracking project status
    &lt;/li&gt;
&lt;/ul&gt;</purpose>
  </org.eclipse.epf.uma:ActivityDescription>
</xmi:XMI>