Activity: Verify Changes in Build

Roles and Activities > Developer Role Set > Integrator > Verify Changes in Build

Purpose The purpose of having a standard, documented change control process is to ensure that changes are made within a project in a consistent manner and the appropriate stakeholders are informed of the state of the product, changes to it and the cost and schedule impact of these changes.
Steps Resolve Change Request Verify Changes in Test Build Verify Changes in Release Build
Input Artifacts: Change Request	Resulting Artifacts: Change Request
Frequency: Once a configuration item has been baselined and entered into the configuration management system, all requests to changes to it should go through the official change request management process.
Role: Integrator
Tool Mentors Reporting Review and Work Status Using Rational ClearQuest
More Information: Change Request Management

Workflow Details:

Configuration & Change Management

Manage Change Requests

Resolve Change Request

The Assigned role performs the set of activities defined within the appropriate section of the process (e.g., requirements, analysis & design, implementation, produce user-support materials, design test, etc.) to make the changes requested. These activities will include all normal review and unit test activities as described within the normal development process. The CR will then be marked as Resolved. This signifies that the resolution of this CR is complete and is now ready for verification.

Verify Changes in Test Build

After the changes are Resolved by the assigned role (analyst, developer, tester, tech writer, and so on), the changes are placed into a test queue to be assigned to a tester and Verified in a test build of the product. A CR that has been Verified in a test build is ready to be included in a release. A CR that fails testing in either a test build or a release build will be placed in the Test Failed state. The owner automatically gets changed to the role who resolved the CR.

Verify Changes in Release Build

Once the resolved changes have been Verified in a test build of the product, the CR is placed into a release queue to be verified against a release build of the product, produce release notes, etc. and Close the CR.

A Closed CR no longer requires attention. This is the final state a CR can be assigned. Only the CCB Review Admin has the authority to close a CR. When a CR is Closed, the submitter will receive an email notification with the final disposition of the CR. A CR may be Closed: 1) after its Verified resolution is validated in a release build, 2) when its Rejected state is confirmed, or 3) when it is confirmed as a Duplicate of an existing CR. In the latter case, the submitter will be informed of the duplicate CR and will be added to that CR for future notifications (see the definitions of states "Rejected" and "Duplicate" for more details). If the submitter wishes to contest a closing, the CR must be updated and re-Submitted for CCB review.

Typical states that a Change Request may pass through are shown in Concepts: Change Request Management)

Rational Unified Process