| <?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="-pszgT2UQY1AzlzJLFM1S5g" name="construction_phase_iteration,_RQi0AdONEdyqlogshP8l4g" guid="-pszgT2UQY1AzlzJLFM1S5g" version="7.2.0"> |
| <mainDescription><p> |
| The architecture should be stable when the Construction 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 that it provides more predictability in Construction, which allows the project manager to focus |
| on team efficiency and cost reduction. |
| </p> |
| <p> |
| Functionality is continuously implemented, tested, and integrated, resulting in builds that are more and more complete |
| and stable. You may deploy a beta or prerelease 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 following table summarizes the&nbsp;Construction phase objectives and&nbsp;what activities address each objective: |
| </p> |
| <p align="center"> |
| <strong>Construction 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"> |
| Iteratively develop a complete product that is ready to transition to the user community<br /> |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/identify_and_refine_requirements_7FA6CB14.html" guid="_xxcpgdOEEdyqlogshP8l4g">Identify and Refine Requirements</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"> |
| Minimize development costs and achieve some degree of parallelism<br /> |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/plan_manage_iteration_F9713A62.html" guid="_oZgCsdOEEdyqlogshP8l4g">Plan and Manage Iteration</a><br /> |
| </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> |
| </tbody> |
| </table></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-ZgdHcIUeC0fczWjxdRhZmQ" name="system_wide_requirements,_AQJYp9OOEdyqlogshP8l4g" guid="-ZgdHcIUeC0fczWjxdRhZmQ"> |
| <keyConsiderations><ul>
 |
| <li>
 |
| When you document system-wide requirements, ensure that the needs of all of the stakeholders are represented. In
 |
| particular, include the needs of those who are responsible for maintaining or supporting the system after it is
 |
| delivered.
 |
| </li>
 |
| <li>
 |
| Typically, there are some overlaps and gray areas between system-wide requirements and other requirements work
 |
| products. For example, the authorization behavior of a system can be specified as use cases or as statements within
 |
| system-wide requirements. The overall driving need is that no important requirements are missed or duplicated, and
 |
| that there is an agreed upon approach for capturing and processing every type of requirement.
 |
| </li>
 |
| <li>
 |
| System-wide requirements originate from many places. Documenting the source of the requirement is particularly
 |
| important when you separate externally mandated requirements.
 |
| </li>
 |
| <li>
 |
| Requirements are often thought of as "Qualitative" (specifying a quality or desirable characteristic) versus
 |
| "Quantitative" (specifying a quantity). Qualitative requirements can sometimes be elaborated into quantitative
 |
| requirements.
 |
| </li>
 |
| <li>
 |
| A good quality requirement is one that you can verify, either through testing or some other objective evaluation.
 |
| </li>
 |
| <li>
 |
| You must evaluate system-wide requirements for cost, schedule impact, and level of contribution to business goals.
 |
| Based on your evaluation, the system-wide requirements should be iteratively challenged, defended, and amended.
 |
| </li>
 |
| </ul></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-LXsJtWauw8OXFBPA5LtlUw" name="glossary,_AQJYqdOOEdyqlogshP8l4g" guid="-LXsJtWauw8OXFBPA5LtlUw"> |
| <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> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-M0XmBkehezZMI-pmbjQ9SA" name="detail_use_case_scenarios,_AVhA0NOOEdyqlogshP8l4g" guid="-M0XmBkehezZMI-pmbjQ9SA"> |
| <keyConsiderations><p>
 |
| To avoid unnecessary rework, only those use-case scenarios that are scheduled for implementation in the near term (in
 |
| the next iteration or two)&nbsp;must be detailed.&nbsp;
 |
| </p>
 |
| <p>
 |
| Not all use-case scenarios require detailing.
 |
| </p></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-p2uRMHIOQI2c6fLh6CUIbw" name="detail_system_wide_requirements,_AVhA0dOOEdyqlogshP8l4g" guid="-p2uRMHIOQI2c6fLh6CUIbw"> |
| <keyConsiderations>To avoid unnecessary rework, only those requirements that are scheduled for implementation in the near term (in the next
 |
| iteration or two)&nbsp;must be detailed.</keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-nIF2UE5rqiDXuJIzOZcQuA" name="create_test_cases,_AVhA0tOOEdyqlogshP8l4g" guid="-nIF2UE5rqiDXuJIzOZcQuA"> |
| <keyConsiderations><p>
 |
| Develop test cases in parallel with requirements so that Analysts and Stakeholders can agree with the specific
 |
| conditions of satisfaction for each requirement. The test cases act as acceptance criteria by expanding on the intent
 |
| of the system&nbsp;through actual scenarios of use.&nbsp;This allows team members to measure progress in terms of
 |
| passing test cases.&nbsp;
 |
| </p></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-vyRUbVNrluvyfjsHPKp2fw" name="test_case,_AVhA1NOOEdyqlogshP8l4g" guid="-vyRUbVNrluvyfjsHPKp2fw"> |
| <refinedDescription><p>
 |
| A test case specifies the conditions that must be validated to enable an assessment of aspects of the system under
 |
| test. A test case is more formal than a test idea; typically, a test case takes the form of a specification. In less
 |
| formal environments, you can create test cases by identifying a unique ID, name, associated test data, and expected
 |
| results.
 |
| </p>
 |
| <p>
 |
| Test cases can be derived from many sources, and typically include a subset of the requirements (such as use cases,
 |
| performance characteristics, and reliability concerns) and other types of quality attributes. For more information on
 |
| types of tests and their relationships to quality test attributes, see <a class="elementLinkWithType"
 |
| href="./../../core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts_CAE80710.html"
 |
| guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Testing Qualitative Requirements</a>.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-fkv_x4ovUGtM8VsssQ3kdg" name="work_items_list,_4DFEYZigEeGlkdGl1HQlDA" guid="-fkv_x4ovUGtM8VsssQ3kdg"> |
| <keyConsiderations><p>
 |
| Work Items should contain estimates. See guidelines on managing work items and agile estimation.
 |
| </p></keyConsiderations> |
| <refinedDescription><p>
 |
| This artifact provides a focal point for the entire team:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| It provides one list containing all requests for additional capabilities or enhancement for that application. Note
 |
| that some of these requests may never be implemented, or be implemented in later projects.
 |
| </li>
 |
| <li>
 |
| It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list
 |
| is prioritized separately.
 |
| </li>
 |
| <li>
 |
| It provides one place to go to for the development team to understand what&nbsp;micro-increments&nbsp;need to be
 |
| delivered, get references to material required to carry out the work, and report progress made.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| These are the typical work items that go on this list:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Use cases (and references to use-case specifications)
 |
| </li>
 |
| <li>
 |
| System-wide requirements
 |
| </li>
 |
| <li>
 |
| Changes and enhancement requests
 |
| </li>
 |
| <li>
 |
| Defects
 |
| </li>
 |
| <li>
 |
| Development tasks
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Work items can be very large in scope, especially when capturing requests for enhancements, such as "Support Financial
 |
| Planning" for a personal finance application. To allow the application to be developed in micro-increments, work items
 |
| are analyzed and broken down into smaller work items so that they can be assigned to an iteration, such as a use-case
 |
| scenario for&nbsp;"Calculate Net Worth". Further breakdown may be required to identify suitable tasks to be assigned to
 |
| developers, such as "Develop UI for Calculate Net Worth". This means that work items often have parent/child
 |
| relationships, where the lowest level is a specification and tracking device for micro-increments.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-mx51ATVqsnhmw5TcEQIYYw" name="plan_deployment,_DZttwJlXEeGlkdGl1HQlDA" guid="-mx51ATVqsnhmw5TcEQIYYw"> |
| <refinedDescription><p>
 |
| Because a Deployment Engineer is responsible for accepting the results of one or more Development Teams 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="-noiWjBdDPWJmSF3l73Ti7Q" name="deployment_engineer,_DZttwZlXEeGlkdGl1HQlDA" guid="-noiWjBdDPWJmSF3l73Ti7Q"> |
| <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="-f_uaW-2HSuS-3uC5Ni_BYw" name="deployment_plan,_DZttxZlXEeGlkdGl1HQlDA" guid="-f_uaW-2HSuS-3uC5Ni_BYw"> |
| <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="-FcJEVCc4jEBKZPGYLseZkQ" name="backout_plan,_DaTjoplXEeGlkdGl1HQlDA" guid="-FcJEVCc4jEBKZPGYLseZkQ"> |
| <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="-M8RcfIWzEdq2ZYUeLZoX4Q" name="release_communications,_DaTjpZlXEeGlkdGl1HQlDA" guid="-M8RcfIWzEdq2ZYUeLZoX4Q"> |
| <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="-9OywHIlNMFgKcxL-epLd3g" name="release,_DaTjqJlXEeGlkdGl1HQlDA" guid="-9OywHIlNMFgKcxL-epLd3g"> |
| <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> |
