| <?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1"> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-kpXvvHptrggypeoQEamfhw" name="initiate_project,_eWxZgdOEEdyqlogshP8l4g" guid="-kpXvvHptrggypeoQEamfhw" version="7.2.0"> |
| <mainDescription><p> |
| This activity takes place at the beginning of the first iteration, when the project starts. The goal of this activity |
| is to establish the vision for both the project and the project plan at a high level of granularity. |
| </p> |
| <p> |
| The people in the roles involved at this time collaborate to perform this activity: |
| </p> |
| <ul> |
| <li> |
| The <a class="elementlinkwithusertext" href="./../../core.default.role_def.base/roles/analyst_39D7C49B.html" guid="_0VxJsMlgEdmt3adZL5Dmdw">Analyst</a> and <a class="elementlinkwithusertext" href="./../../core.default.role_def.base/roles/stakeholder_9FFD4106.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a> roles work together to define the <a class="elementLinkWithUserText" href="./../../core.tech.common.extend_supp/workproducts/vision_2E71B03C.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">vision</a> |
| for the project, capturing the customer needs and features for the system under development. Needs and features are |
| captured to the extent required to reach agreement about the scope of the project. |
| </li> |
| <li> |
| The project manager (collaborating and reaching agreement with the development team and stakeholders) proposes a |
| high-level <a class="elementLinkWithUserText" href="./../../practice.mgmt.two_level_project_planning.base/workproducts/project_plan_1CDBB7E4.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">project plan</a> that includes the <a class="elementLinkWithUserText" href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">milestones</a> for the four phases, and time-boxed iterations for each phase. This |
| plan, along with the allocation of staff to the project, evolves throughout the phases and defines the pace of the |
| project. |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-Y4gn4laxnFk1PUA3-GebOg" name="develop_technical_vision,_sopKYNOJEdyqlogshP8l4g" guid="-Y4gn4laxnFk1PUA3-GebOg"> |
| <keyConsiderations><p>
 |
| Use-case modeling&nbsp;is one technique that can prove useful in defining the system boundaries and system behavior.
 |
| </p></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-z5wrOi6JXS768g53hKiYaA" name="vision,_soyUVNOJEdyqlogshP8l4g" guid="-z5wrOi6JXS768g53hKiYaA"> |
| <keyConsiderations><p>
 |
| It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make
 |
| the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important
 |
| features and avoiding details of requirements.
 |
| </p>
 |
| <p>
 |
| Projects that focus on product development might extend the marketing section and include a more detailed product
 |
| position statement that is based on their needs and research.
 |
| </p></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-9AN0xXBZYxIDPOg2N3IC6Q" name="plan_the_project,_t7pDUNOJEdyqlogshP8l4g" guid="-9AN0xXBZYxIDPOg2N3IC6Q"> |
| <keyConsiderations><p>
 |
| Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of
 |
| the project. Make adjustments as&nbsp;necessary.
 |
| </p></keyConsiderations> |
| <refinedDescription>Developing the project plan provides an opportunity for the team to agree on project scope, objectives, initial timeframe,
 |
| and deliverables. It allows the team to begin demonstrating self-organization by defining success criteria and work
 |
| practices to be used. Collaboration and consensus by all key project participants is the goal, but the role responsible for
 |
| this task must ensure that everybody is committed to the plan.</refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-ZCPNs3ExxsjnNFRTVybQyA" name="project_plan,_4ypNIO-YEdyEMtC_IfEALw" guid="-ZCPNs3ExxsjnNFRTVybQyA"> |
| <keyConsiderations>Create and update the project plan in planning sessions that involve the whole team and appropriate project stakeholders in
 |
| order to make sure that everybody agrees with it.</keyConsiderations> |
| <refinedDescription><p>
 |
| This artifact describes how the project is organized, and identifies what practices will be followed. Additionally, it
 |
| defines the parameters for tracking project progress, and specifies the high-level objectives of the iterations and
 |
| their milestones.
 |
| </p>
 |
| <p>
 |
| The project plan allows stakeholders and other team members to understand the big picture and, roughly, when to expect
 |
| a certain level of functionality be available.&nbsp;Update the plan&nbsp;as often as necessary, usually at the end of
 |
| each iteration, in order to reflect changing priorities and needs, as well as record the lessons learned from the
 |
| project.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-LpEiAis-mzd1_RcJIRimLA" name="glossary,_OpsH8GpmEd24CboUCnKL3A" guid="-LpEiAis-mzd1_RcJIRimLA"> |
| <keyConsiderations><p>
 |
| Although listed as an <i>output from</i> and an <i>input to</i> tasks associated with the requirements discipline, this
 |
| artifact can be updated at any time and by any role as new terms are identified. The terms defined should be used
 |
| according to the recorded definitions in all project documentation so that all stakeholders can clearly see that terms
 |
| are being used consistently.
 |
| </p>
 |
| <p>
 |
| One of the primary decisions when developing&nbsp;this artifact&nbsp;is whether to have all terms in a single glossary
 |
| or to maintain terms in several glossaries, business terms artifacts, or models.&nbsp;If terms are defined in multiple
 |
| places, you need to communicate all of those sources to the team and decide which take precedence.
 |
| </p>
 |
| <p>
 |
| It may be important, even in small projects, to reference and use existing broader glossaries, business terms
 |
| artifacts, or data models, where they exist.
 |
| </p>
 |
| <p>
 |
| Industry- and organization-wide glossaries may be referenced, and compliance with such specific chosen standards may be
 |
| required.
 |
| </p></keyConsiderations> |
| <refinedDescription><p>
 |
| This artifact&nbsp;helps you avoid miscommunication by providing two essential resources:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| A central location to look for terms and abbreviations that are new to development team members
 |
| </li>
 |
| <li>
 |
| Definitions of terms that are used in specific ways within the domain
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Definitions for the glossary terms come from several sources, such as requirements documents, specifications, and
 |
| discussions with stakeholders and domain experts.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| </xmi:XMI> |
