| <?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="-TceMuWXdZ1TV2gERYKpA5g" name="elaboration_phase_iteration,_aUsVEdONEdyqlogshP8l4g" guid="-TceMuWXdZ1TV2gERYKpA5g" version="7.2.0"> |
| <mainDescription><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 of the |
| architecture for the system, and mitigating top-priority risks. |
| </p> |
| <p> |
| The following table summarizes the&nbsp;Elaboration phase objectives and&nbsp;what activities address each objective: |
| </p> |
| <p align="center"> |
| <strong>Elaboration phase objectives and activities</strong> |
| </p> |
| <table cellspacing="0" cellpadding="0" width="648" align="center" border="1"> |
| <tbody> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| <p style="TEXT-ALIGN: justify"> |
| <b>Phase objectives</b> |
| </p> |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <b>Activities that address objectives</b> |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| Get a more detailed understanding of the requirements |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/identify_and_refine_requirements_7FA6CB14.html" guid="_xxcpgdOEEdyqlogshP8l4g">Identify and Refine Requirements</a> |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| Design, implement, validate, and baseline an architecture |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/develop_architecture_C7BBA35B.html" guid="_KaeNsdOFEdyqlogshP8l4g">Develop the Architecture</a> |
| </p> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/develop_solution_4FBB0E6E.html" guid="_RXGoodOFEdyqlogshP8l4g">Develop Solution Increment</a> |
| </p> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/test_solution_D16D88FC.html" guid="_buG4sdOFEdyqlogshP8l4g">Test Solution</a> |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| Mitigate essential risks, and produce accurate schedule and cost estimates |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/plan_manage_iteration_F9713A62.html" guid="_oZgCsdOEEdyqlogshP8l4g">Plan and Manage Iteration</a><br /> |
| </td> |
| </tr> |
| </tbody> |
| </table></mainDescription> |
| <alternatives>There will be iterations when projects risks are being addressed by creating software, but they may not be architecturally |
| significant. In this case, <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/develop_solution_4FBB0E6E.html" guid="_RXGoodOFEdyqlogshP8l4g">Develop Solution Increment</a> will be performed outside the context of the architecture. For the most part, Develop Solution will |
| be performed in the context of <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/develop_architecture_C7BBA35B.html" guid="_KaeNsdOFEdyqlogshP8l4g">Develop the Architecture</a> during the Elaboration phase.</alternatives> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-n6Q-ulwXte8wbHfbdgJuXQ" name="plan_deployment,_oaBE0JigEeGlkdGl1HQlDA" guid="-n6Q-ulwXte8wbHfbdgJuXQ"> |
| <refinedDescription><p>
 |
| Because a Deployment Engineer is responsible for accepting the results of one or more development team members and deploying those
 |
| integrated releases into the production environment, it is important for all parties to agree on the details of a
 |
| particular release. The Deployment Plan documents, in one place, all the information that will be consumed by the
 |
| Deployment Engineer before and during the deployment to production of a particular release package.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-oaP9Gj-2L1Z-5iu6I7YuQA" name="deployment_engineer,_oaBE0ZigEeGlkdGl1HQlDA" guid="-oaP9Gj-2L1Z-5iu6I7YuQA"> |
| <refinedDescription><p>
 |
| A Deployment Engineer&nbsp;assists the&nbsp;Deployment Manager who is responsible to senior management for the
 |
| successful deployment of integrated or stand-alone releases into production. This team member role is critical to the
 |
| safety of the production environment and helps prevent the introduction of bad or untested code into production&nbsp;on
 |
| which the organization's internal and external Customers depend. Deployment Engineers support the Deployment Manager in
 |
| the mission to continually lead, facilitate, and coordinate synchronized releases by using the program to
 |
| maximize value delivered to their program Customers.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-2H5-pLUbe_1EU9a_K7G8lg" name="deployment_plan,_oaK10JigEeGlkdGl1HQlDA" guid="-2H5-pLUbe_1EU9a_K7G8lg"> |
| <refinedDescription><p>
 |
| The Deployment Plan should contain the unique instructions for deploying a particular version of a product. By "unique
 |
| instructions" we mean those things that are not part of a Deployment Engineer's normal procedures. Rather, they often
 |
| are specific procedures and timing constraints that a Deployment Engineer should be aware of as they are rolling out a
 |
| particular release.
 |
| </p>
 |
| <p>
 |
| While&nbsp;a draft version of the&nbsp;Deployment Plan is typically developed by a development team, the Deployment
 |
| Engineer is responsible for its contents and existence.&nbsp;A Deployment Plan&nbsp;normally consists of the following
 |
| sections:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The scope of the release and a general overview of the capabilities to be deployed
 |
| </li>
 |
| <li>
 |
| The timing and dependencies for deploying components to various nodes
 |
| </li>
 |
| <li>
 |
| The risks or issues associated with the release based on a risk assessment
 |
| </li>
 |
| <li>
 |
| The customer organization, stakeholders, and End User community that will be impacted by the release
 |
| </li>
 |
| <li>
 |
| The person or persons who have the authority to approve the release as "ready for production"
 |
| </li>
 |
| <li>
 |
| The development team members responsible for delivering the release package to the Deployment Manager, along with
 |
| contact information
 |
| </li>
 |
| <li>
 |
| The approach for transitioning the release package to the Deployment Engineer, including appropriate communications
 |
| protocols and escalation procedures
 |
| </li>
 |
| <li>
 |
| The success criteria for this deployment; in other words, how will the Deployment Engineer know that the release is
 |
| successful so it can report success
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-r0AuJYtQwfZHI7WFZFRAVg" name="backout_plan,_oanhw5igEeGlkdGl1HQlDA" guid="-r0AuJYtQwfZHI7WFZFRAVg"> |
| <refinedDescription><p>
 |
| While someone on the development team normally authors a draft version of the Backout Plan, the Deployment Engineer is
 |
| ultimately responsible for its contents and existence. A Backout Plan typically answers the following questions:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Under what circumstances will a rollback be required? Or conversely, under what circumstances will the deployment
 |
| be considered a success?
 |
| </li>
 |
| <li>
 |
| What is the time period within which a rollback can take place?
 |
| </li>
 |
| <li>
 |
| Which authorizing agent will make the decision to revert?
 |
| </li>
 |
| <li>
 |
| Who will perform the rollback and how soon after the decision has been made will the rollback be performed?
 |
| </li>
 |
| <li>
 |
| What procedures (manual and automated) will be followed to execute the rollback?
 |
| </li>
 |
| <li>
 |
| What other contingency measures or available workarounds should be considered?
 |
| </li>
 |
| <li>
 |
| What is the expected time required to perform a reversion?
 |
| </li>
 |
| <li>
 |
| What are the communication procedures required in the event of a backout?
 |
| </li>
 |
| <li>
 |
| Has the Backout Plan been successfully tested?
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-dklyw-kN1blOVTzIdtlryg" name="release_communications,_oanhxpigEeGlkdGl1HQlDA" guid="-dklyw-kN1blOVTzIdtlryg"> |
| <refinedDescription><p>
 |
| Sometimes, depending on the product user base, separate communiques might need to be prepared for each stakeholder
 |
| group. In that case, this artifact should specify the different groups to which communications are directed, the method
 |
| of communication (e.g., email, text or pager message, bulletin, newsletter, phone message, etc.). All communiques
 |
| should be prepared in advance so that it is a matter of disseminating information when the release to production has
 |
| been determined to be successful.
 |
| </p>
 |
| <p>
 |
| Also included in this artifact is a listing of the responsible parties who will execute the communications when a
 |
| successful release has been declared (normally the Deployment Engineer), as well as the timing and dependencies of the
 |
| communiques.
 |
| </p>
 |
| <p>
 |
| While there is no prescribed format for the Release Communications artifact, each communique should indicate the
 |
| preferred delivery mechanisms (e.g., beeper notification, telephone calls, a posting to an internal release website,
 |
| live or pre-recorded presentations by senior management, etc.) and generally answer the following questions:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Who are the parties (Stakeholders) that are interested in knowing that a release to production has taken place?
 |
| </li>
 |
| <li>
 |
| What specifically (features, functions, components) has been placed into production?
 |
| </li>
 |
| <li>
 |
| Why is this release valuable to stakeholders and what business purpose does it serve?
 |
| </li>
 |
| <li>
 |
| Where is the product available (on which platforms, geographical locations, business units, etc.)?
 |
| </li>
 |
| <li>
 |
| How can the stakeholders access the system and under what circumstances?
 |
| </li>
 |
| <li>
 |
| When was the product released (or when will it be released if the release date is in the future)?
 |
| </li>
 |
| </ul></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-waTDcdCVwbWvHp6f1prjPQ" name="release,_oanhyZigEeGlkdGl1HQlDA" guid="-waTDcdCVwbWvHp6f1prjPQ"> |
| <refinedDescription><p>
 |
| A Release consists of integrated, compiled code that runs cleanly, independently, and in its entirety. This is an
 |
| important rule because in order to be released or even "potentially shippable," a Release increment must be able to
 |
| stand on its own, otherwise it is not shippable. Releases&nbsp;can be created at either the program or team level.
 |
| </p>
 |
| <p>
 |
| There are three potential uses for a Release:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>It is not used outside of the program:</strong> It has been produced to minimize risks linked to technology
 |
| and a program's capability to integrate components and to produce a Build. This situation usually happens at the
 |
| beginning of a new product lifecycle.
 |
| </li>
 |
| <li>
 |
| <strong>It is used by Beta Customers and the Program Manager:</strong> It allows End Users to test it in a Beta
 |
| test environment, which provides immediate feedback and reduces risks associated with user interface ergonomics.
 |
| Customer feedback will influence the Program Backlog for later consideration.
 |
| </li>
 |
| <li>
 |
| <strong>It is deployed or shipped and used by End Users:</strong> This result provides immediate value to the End
 |
| Users.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| In many organizations, a program Release typically is timeboxed to 2 to 3 months of development effort and 2 to 4 weeks
 |
| of hardening which results in a scheduled release approximately every 90 days. Releases for individual Development
 |
| Teams usually occur more often than those for programs, but there are no hard and fast rules regarding how often
 |
| releases should be scheduled. The only requirement is that working software should be delivered "frequently" by both
 |
| development teams and programs. Although the example timeframe described above is arbitrary, empirical evidence
 |
| suggests it is about right for most companies and fits nicely into quarterly planning cycles.
 |
| </p>
 |
| <p>
 |
| Each Release has a set of release objectives and a projected delivery date; it also has a planned number of Sprint/Iterations.
 |
| For example, a brief description of a release might be: "The goal of Release 2 is to provide B2B scheduling capability
 |
| for the Ordering and Logistics Department. The Release is targeted for June 31 and will consist of five 2-week Feature
 |
| Development Sprint/Iterations and&nbsp;one 2-week Release Sprint/Iteration."
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| </xmi:XMI> |
