OpenUP/OpenUP_PT/library/openup_basic/capabilitypatterns/construction_phase_iteration/content.xmi - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?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>
	<?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><h3>
	Introduction
	</h3>
	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&nbsp;emphasis on how activities&nbsp;address the phase objectives,
	though.
	<p>
	The <a href="./../../openup_basic/workproducts/architecture,_0XAf0MlgEdmt3adZL5Dmdw.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> 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 <a class="elementlinkwithusertext" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project manager</a> to focus on team efficiency and cost reduction.
	</p>
	<p>
	Functionality is continuously implemented, tested, and integrated, resulting in <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
	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.
	</p>
	<p>
	The activities performed in a typical iteration during&nbsp;Construction phase are described after the following
	introductions to each activity.
	</p>
	<h4>
	Manage iteration
	</h4>
	<p>
	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.
	</p>
	<p>
	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&nbsp;development.
	</p>
	<p>
	The prioritization of work for a given iteration (existing change requests and possibly a few remaining requirements)
	takes place. project manager,&nbsp;<a class="elementlinkwithusertext" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">stakeholders</a>, and the remaining team members agree on what is supposed to be
	developed during that iteration.
	</p>
	<p>
	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.
	</p>
	<h4>
	Manage requirements
	</h4>
	<p>
	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.
	</p>
	<p>
	During Inception, most requirements are captured. The high-risk requirements are detailed, implemented, and validated
	(through a working architecture) during Elaboration.
	</p>
	<p>
	During the Construction phase, requirements management demands less time from the <a class="elementlinkwithusertext" href="./../../openup_basic/roles/analyst,_0VxJsMlgEdmt3adZL5Dmdw.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">analyst</a>.
	There still may be low-risk requirements to be detailed or refined, but in a way that can be assigned to <a class="elementlinkwithusertext" href="./../../openup_basic/roles/developer,_0YDosMlgEdmt3adZL5Dmdw.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
	</p>
	<p>
	<a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case,_0ZS-0MlgEdmt3adZL5Dmdw.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test cases</a> describe which&nbsp;requirements are being tested&nbsp;in that iteration.
	</p>
	<h4>
	Develop solution
	</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>
	The architecture &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.
	</p>
	<p>
	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),&nbsp;thus allowing&nbsp;parallel development. <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ.html" guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous integration</a> allows functionality to be added to the code base constantly,
	which helps the achievement of more and more complete <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
	of the software.
	</p>
	<h4>
	Validate build
	</h4>
	<p>
	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.
	</p>
	<p>
	Similarly to Elaboration, this activity happens in parallel with the <a class="elementLinkWithUserText" href="./../../openup_basic/capabilitypatterns/develop_solution,_h2-iAfimEdmugcVr9AdHjQ.html" guid="_h2-iAfimEdmugcVr9AdHjQ">develop solution</a> activity. The intent is to validate that a stable beta release is
	achieved and that users can perform acceptance tests.
	</p>
	<h4>
	Ongoing tasks
	</h4>
	<p>
	Similarly to any other phase, <a class="elementlinkwithusertext" href="./../../openup_basic/roles/any_role,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any role</a> on
	the team can submit <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/change_requests,_fnZj0NVXEdqy9sbRhejO5Q.html" guid="_fnZj0NVXEdqy9sbRhejO5Q">change requests</a>. The software being developed is achieving beta quality by this
	point; therefore, defects of high priority&nbsp;are generally&nbsp;addressed during Construction iterations&nbsp;and
	Transition iterations. Enhancement requests can be planned for either subsequent Transition iterations or a next
	release of the product.
	</p></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><h3> Introduction </h3>
	<p> Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform
	a goal-based planning and management. Work is assigned to developers and work
	progress is tracked&nbsp;based on the goals to be achieved using
	the designed, unit-tested, and&nbsp;integrated&nbsp;source code. </p>
	<h4> Context of what is being developed </h4>
	<p> 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&nbsp;may focus&nbsp;on a layer (such as the user interface, business
	logic, or&nbsp;database access),&nbsp;on a component, and so on. </p>
	<p> Whether a context is specified or not, the developer's
	responsibility is to create a design and implementation for that requirement,
	then to&nbsp;write and run unit tests against the implementation to make sure
	the&nbsp;implementation works as designed, both as a unit&nbsp;and&nbsp;integrated
	into the code base. </p>
	<h4> Overview of workflow </h4>
	<p> To accommodate major changes or&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.
	</p>
	<p> In any case, there is no strict sequence for how writing code and creating
	or running &nbsp;developer tests should happen, because they can happen in parallel.&nbsp;You
	may choose to create and run developer tests before the actual code is created
	or the reverse sequence.</p></mainDescription>
	<purpose><ul>
	<li> <strong>For developers: </strong>To create a solution for the requirement
	assigned to them </li>
	<li> <strong>For project managers: </strong>To have a goal-based way of assigning
	work and tracking project status </li>
	</ul></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><h3>
	Introduction
	</h3>
	<p>
	Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
	is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
	unit-tested, and&nbsp;integrated&nbsp;source code.
	</p>
	<h4>
	Context of what is being developed
	</h4>
	<p>
	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&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
	or&nbsp;database access),&nbsp;on a component, and so on.
	</p>
	<p>
	Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
	requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
	works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
	</p>
	<h4>
	Overview of workflow
	</h4>
	<p>
	To accommodate major changes or&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.
	</p>
	<p>
	In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
	happen, because they can happen in parallel.&nbsp;You may choose to create and run developer tests before the actual
	code is created or the reverse sequence.
	</p></mainDescription>
	<purpose><ul>
	<li>
	For developers: To create a solution for the requirement assigned to them
	</li>
	<li>
	For project managers: To have a goal-based way of assigning work and tracking project status
	</li>
	</ul></purpose>
	<usageNotes><p>
	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.&nbsp;Optionally, the word
	<strong>Solution</strong> may be suppressed, then you can instantiate the pattern this way:
	</p>
	<blockquote>
	<p align="left">
	Develop <font face="Courier New, Courier, mono">requirement_name</font> (within <font face="Courier New, Courier, mono">context_name</font> context)
	</p>
	</blockquote>
	<p>
	If&nbsp;a context&nbsp;is specified, there will be one instance of this pattern for each requirement&nbsp;for each
	context.
	</p>
	<blockquote>
	<p>
	<strong>Example</strong>
	</p>
	<ol>
	<li>
	Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">user interface</font> context)
	</li>
	<li>
	Develop <font face="Courier New, Courier, mono">scenario 1</font> (within <font face="Courier New, Courier, mono">business logic and DB access</font> context)
	</li>
	<li>
	Develop <font face="Courier New, Courier, mono">scenario 2</font>
	</li>
	<li>
	Develop <font face="Courier New, Courier, mono">supplemental requirement 1</font>
	</li>
	</ol>
	</blockquote>
	<p>
	Note that there are four instances of this pattern in the preceding example:
	</p>
	<ul>
	<li>
	The first two are related to the same requirement (scenario 1) but within two different contexts
	</li>
	<li>
	The last two are related to different requirements, with no context specified.
	</li>
	</ul></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><h3>
	Introduction
	</h3>
	<p>
	Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work
	is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed,
	unit-tested, and&nbsp;integrated&nbsp;source code.
	</p>
	<h4>
	Context of what is being developed
	</h4>
	<p>
	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&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic,
	or&nbsp;database access),&nbsp;on a component, and so on.
	</p>
	<p>
	Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that
	requirement, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation
	works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base.
	</p>
	<h4>
	Overview of workflow
	</h4>
	<p>
	To accommodate major changes or&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.
	</p>
	<p>
	In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should
	happen, because they can happen in parallel.&nbsp;You may choose to create developer tests and run them before the actual
	code is created or the reverse sequence.
	</p></mainDescription>
	<purpose><ul>
	<li>
	For developers: To create a solution for the requirement assigned to them
	</li>
	<li>
	For project managers: To have a goal-based way of assigning work and tracking project status
	</li>
	</ul></purpose>
	</org.eclipse.epf.uma:ActivityDescription>
	</xmi:XMI>