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