| <?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><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:ProcessDescription xmi:id="-YC_Vv98UTCGK7Yql7krX0w" guid="-YC_Vv98UTCGK7Yql7krX0w"> |
| <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.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.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.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.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.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.html" guid="_0YDosMlgEdmt3adZL5Dmdw">developers</a>.
 |
| </p>
 |
| <p>
 |
| <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/test_case-2.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.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.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-2.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.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any role</a> on
 |
| the team can submit <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/guidelines/change_requests-2.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> |
| </xmi:XMI> |
