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