| <?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="_mtb_BfL5Edm6Nvont3uinw" guid="_mtb_BfL5Edm6Nvont3uinw"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_B_L5Edm6Nvont3uinw" guid="_mtb_B_L5Edm6Nvont3uinw"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CfL5Edm6Nvont3uinw" guid="_mtb_CfL5Edm6Nvont3uinw"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_CvL5Edm6Nvont3uinw" guid="_mtb_CvL5Edm6Nvont3uinw"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_BvL5Edm6Nvont3uinw" guid="_mtb_BvL5Edm6Nvont3uinw"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="_mtb_C_L5Edm6Nvont3uinw" guid="_mtb_C_L5Edm6Nvont3uinw"/> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="_mtb_BPL5Edm6Nvont3uinw" guid="_mtb_BPL5Edm6Nvont3uinw"> |
| <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,_0a0o0MlgEdmt3adZL5Dmdw.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,_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>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,_0ZS-0MlgEdmt3adZL5Dmdw.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,_0XAf0MlgEdmt3adZL5Dmdw.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,_0X9iEMlgEdmt3adZL5Dmdw.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,_0YDosMlgEdmt3adZL5Dmdw.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,_0YuXEclgEdmt3adZL5Dmdw.html" guid="_0YuXEclgEdmt3adZL5Dmdw">tests</a> |
| and integrate their work to create <a class="elementLinkWithUserText" href="./../../openup_basic/workproducts/build,_0YuXEMlgEdmt3adZL5Dmdw.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,_0ZM4MclgEdmt3adZL5Dmdw.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,_0aDz0MlgEdmt3adZL5Dmdw.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,_rGNWsCbSEdqh1LYUOGRh2A.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,_0dsWoMlgEdmt3adZL5Dmdw.html" guid="_0dsWoMlgEdmt3adZL5Dmdw">any |
| role</a> in the project team can issue a <a class="elementLinkWithUserText" href="./../../openup_basic/guidances/concepts/change_requests,_6jdvECb3Edqh1LYUOGRh2A.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> |