In my post today, I’m continuing with the “Develop and Test the Change” process in the MOF Change and Configuration SMF. This process starts after a change request has been approved and scheduled Service Manager. See my previous post about approving and scheduling the change .
Figure 1 shows the high-level MOF Change and Configuration Management service management function (SMF) processes.
Figure 1. MOF Change and Configuration Management SMF diagram
After a change request has been approved, testing and development of the change begins. Files attached to the change request and knowledge articles about can be especially useful during this process. For example, end-users, analysts, or change owners have included technical, design, or requirements information with the change request. Also, planning information captured on the Change Request Planning tab such as the implementation plan, risk assessment plan, test plan, and backout plan are gathered and recorded.
Most change development and test activities equate to manual activities in Service Manager, similar to a checklist. Activities not started are Active . As the change is developed and tested, you mark each step in the process from Ready to Complete as you go. The last step of approving the change request after development and testing is a review, or voting, activity—the go or no-go decision.
Figure 2. Develop and Test the Change diagram
Figure 3. Change Request form, Activities Tab
Figure 4. Change Request form, Planning Tab
Process 5: Develop and Test the Change – Use manual activities to record developmental and testing steps
1. Design the change—Ensure that you gather and record change design information on the Change Request Planning tab. Such information includes the change implementation plan, risk assessment plan, test plan, and backout plan if necessary. Recorded information should ensure that any usage scenarios, operational requirements, and design information satisfy the design of the change to build and test the change. When complete, you can mark the Change Development manual activity as Complete .
2. Identify configuration dependencies—Ensure that you identify all configuration items that might be affected by the change. If needed, you can associate other work items like change requests, incidents, and problems using the Related Items tab. More than likely the change affects computers, services, and people. You can also associate those items to the change request on the Related Items tab. Miscellaneous other information pertinent to the change are also recorded on the tab such as knowledge articles and attached files.
3. Build and test the change—Using your captured implementation, risk assessment, test, and backout plans, you can build and test the change in a lab or test environment, as necessary. When complete and satisfactory results have been met, you can mark the Change Testing manual activity Complete .
4. Review the readiness of the change—If the change appears ready for implementation, you can vote Approve for the Approve Change Deployment review activity.
5. Update the RFC—Although change reviewers and owners update the change request throughout its life, ensuring that up-to-date status of each manual and review activity is recorded is especially import during the development and testing process.
In my next blog post I’ll cover the next process: release the change.
Note : This blog post and diagrams apply to a preliminarily version of Service Manager. This information might change in subsequent versions of Service Manager.