Using Collision Detection
When you select Functions > Collision Detection from the navigation pane of a change request, the Collision Detection dialog box opens. From here, you can view and resolve collisions between change requests.
This topic provides the following information:
Handling a collision
The following sequence describes the actions that change coordinators perform when a collection is detected in a change request:
- The assigned Change Coordinator notifies the Change Coordinators for the other colliding change requests.
- All of the change coordinators conduct an investigation into the nature of their own changes and share their findings.
- The change coordinators agree to either ignore the collision or reschedule their individual change requests to resolve the collision.
For more information, read about the Ignored state in the Collision states table. - 4. The change coordinators update the status of the collision in their individual change requests.
Note
Functional areas of the Collision Detection dialog box
The Collision Detection dialog box consists of two sections:
The Include Collision State section in the upper half of the dialog box provides check boxes that you to can use to select all of the collisions that are in a particular collision state at that moment. For more information, see Collision states.
Note
The collision state check boxes are not a way to filter the collisions that are displayed in the lower half of the dialog box. For information about using these check boxes, see Resetting all collisions in a change request.
The Identified Collisions section in the lower half of the dialog box lists all of the collisions for the change request. It displays the affected CI, the related change request ID, the scheduled start and end dates, and the ID and scheduled start and end dates of the colliding change requests. Collisions are removed from the list only when they no longer exist—that is, when a schedule conflict no longer exists..
Note
BMC recommends that you run an impact simulation in BMC Atrium Impact Simulator to detect CI dependencies before you use the Collision Detection feature in BMC Change Management. Saving the simulation automatically relates all dependent CIs to your change request, which ensures that any collisions are detected. For more information, see Viewing the impact of CIs on change requests.
CI collisions detected with change requests
Collision states
The following states apply to collisions in the Collision Detection dialog box:
Collision state | Text color | Meaning |
|---|---|---|
None Found | Green | (Release Management only) The change request was checked for collisions and none were found. When running Collision Detection from a release, changes with no scheduled start or end dates will have a collision state of None Found. Note: If you try to set this collision state in a change request, it reverts to Detected the next time you view the change request. |
Detected | Red | This the the default initial state when a new collision is detected. No action has been taken yet. If you are not the Change Coordinator for the current change request or the colliding Change Request, notify one of them about the collision. |
Ignored | Purple | The collision was investigated and is being ignored. You can continue working on the change request. Colliding change requests can co-exist without requiring a change of schedule if the Change Coordinator or Change Manager decides that the natures of the change requests do not conflict—that is, if the implementation of a change request does not impede or undo the implementation of another change request. In this situation, you can ignore the collision. For example, consider a server that hosts a number of virtual machines. User A submits a change request for an operating system upgrade on one of the virtual machines. User B submits a change request to set up one more virtual machine on the server. The server and its virtual machines are dependent CIs and both changes are scheduled to be implemented during the same period of time. However, adding another virtual machine will not negatively impact the operating system upgrade on the existing virtual machine, and neither change prevents other users from accessing the remaining virtual machines remotely. Additionally, both changes can be implemented simultaneously, so the Change Coordinator can choose to ignore the collision and might even assign tasks for both change requests to the same IT personnel. |
Investigating | Orange | The collision is being investigated. Consult the Change Coordinator for the current change request before taking any action. |
Resolved | Blue | The collision has been resolved. You can continue working on the change request. Note: A schedule conflict still exist between two change requests when a Resolved collision appears in the Collision Detection dialog box. A collision is removed from the list if the Change Coordinator takes action and the collision ceases to exist. |
(clear) | None | (Release Management only) Collision detection has not been run against this change request since it was created. Note: If you try to set this collision state in a change request, it reverts to Detected the next time you view the change request. |
None | None | This state appears only against Activity records in the Manifest table. Collision detection does not apply to Activities. |
Changing the state of a collision
- Open the request.
- Click the Relationships tab on the change form or the Manifest tab on the release form.
- Choose one of the following options:
- For Change Requests—Functions > Collision Detection
- For Release Requests—Functions > Collision Detection
- For the colliding change, select the new state from the menu in the Collision column. For example, if the schedule conflict no longer exists, change Detected to Resolved.
- Click Save and close the Collision Detection dialog box.
Resetting all collisions in a change request
- Open the request.
- Click the Relationships tab on the change form or the Manifest tab on the release form.
- Choose one of the following options to access the Collision Detection dialog box:
- For Change Requests—Functions > Collision Detection
- For Release Requests—Functions > Collision Detection
In the Include Collision State section of the dialog box, select collision states (for example, Detected) when you run the tool. For example, if you select Detected, any records that were previously flagged as Detected are included in the reset operation.
- Click Identify Collisions.
The collisions that were in the states that you selected are updated to the Detected state. - Click Save and close the Collision Detection dialog box.
Comments
Typo above, search for "...check boxes that you to can use...", should be "...check boxes that you can use..."
Log in or register to comment.