25-08-2017, 09:32 PM
Software Change Management -The way of Managing Change in Enterprise Software System
Software Change Management -The way of Managing Change in Enterprise Software System.docx (Size: 119.99 KB / Downloads: 18)
Abstract: Enterprise systems are software systems that provide core services used across the institution and on which other applications often are dependent [3]. This software evolves over time and this leads to change. Hence there should be an effective software change management process to coordinate those changes so that they can enhance- not hinder-your software. In this paper I have discussed about what software change management is and how the change management process can be carried out.
Keywords: Change Management, Enterprise system, Change Control Process, SCM, CRF, CAB, RFC
I. INTRODUCTION
Changes are inevitable when software is built. A software application goes through different phases before it is finally released in the market. These phases include design, development, testing and implementation. Even though the software application has gone through these phases, it’s still never finished. This is because the client or customer will want to make changes to it. It could be adding a new field, new group with different access rights or upgrade. Once the software is put into use, new requirements emerge and existing requirements change as the business running that software changes. Because of which parts of the software may have to be modified to correct the errors found in the operation, improve its performance or other non-functional characteristics. If the changes are not analyzed before it is made then it may lead to confusion among software engineers who are working on a project. Every software engineer has to be concerned with how the changes are made to the software
In modern enterprises, software system automates wide variety of processes. Changes made to software are, in effect, changes made to business processes themselves. Even with best planning and project control, software systems will experience a significant amount of change. Software changes thus require careful management just as business process change does, as the two are inextricably linked.
II. WHAT IS SCM?
Software Change Management (SCM) is the process of selecting which changes to encourage, which to allow, and which to prevent, according to the criteria such as schedule and cost [2]. It is a set of activities that have been developed to manage change throughout the life cycle of computer software [1]. This includes management of changes to software in development, changes to software in production and changes to associated artifacts like requirements, models and test cases. Everyone involved in the software process is involved with change management to some extent, but specialized support positions are sometimes created to manage the SCM process.
It has two main goals:
• Supporting the processing of changes
• Enabling the traceability of changes
The key goal of Change Management Process is to ensure that all parties affected by a particular change understand the impact of the impending change. Because most of the system are interrelated to each other, so change made to one part of the system may affect the other. Change Management identifies all the affected system and process before the change is implemented so that adverse affect can be minimized. Change Management helps to make changes to the system in a controlled way.
III. ORIGIN OF CHANGE
A variety of issues drive software change. Understanding the origin of change is the first step in prioritizing them. The changes can originate from various sources including customers, end users, the project team or the test team.
• Changes from customers and end users would normally be changes in their requirements. Software is built based on the requirements of the customers and these will change as the customer gets better idea of what they really need.
• Changes from project team would be design changes. As the users requirements changes the design of software will also undergo change.
• The testing team could request code changes. Once the testing team starts testing the code they may find certain errors or bugs in the system. Hence they request the programmer to do modifications to the existing code or sometimes may even ask the code to be changed completely or to be removed.
• Technology also has an immense impact on the software change. As the technology changes, the users would want their software developed based on the changed technology. This results in changing the software, as the software has to be upgraded to meet the new technology requirements. For example, if a software was developed using C++ and as the technology changed the company wanted the code to be written in java so that the code which caused problems like the use of pointers and multiple inheritance can be eliminated then the whole software had to be changed according to the requirements.
IV. SCM PROCESS
Like any task, changes also follow a life cycle, or change process, that we must track. The change control has a set of six steps-
1. The customer or client submits the change request by describing the change request in change request form.
2. The change manager then records and categorizes that request. Categorization is made based on importance, impact and complexity.
Change can be broadly classified into:
The priority of change is noted
3. If the change request is accepted, a development team will be assigned. If the change request is rejected, that fact is documented and communicated to the client.
4. The team responsible for the change creates a detailed plan for its design and implementation, as well as a plan for rolling back the change if it is unsuccessful.
5. The team implements the change and reviews it.
6. If the client is satisfied that the change was implemented satisfactorily, the change request is closed. If the client is not satisfied, the project is reassessed and steps may be repeated.
The pseudo-code given below defines a process which may be used to manage software system changes:
V. IMPLEMENTATION
Microsoft’s Exchange 2000 Server is a corporate email messaging system released in November 2000 as a replacement for Exchange 5.5.
Exchange 2000 integrates with Windows 2000 Server’s Active Directory, allowing support staff a single management point to administer Exchange and its components.
The Microsoft Exchange Server is a complex system that manages communication and information shared between users. The Exchange Server is a client/server architecture, meaning that the client-the user-that wants to send a message connects to his or her account on the server, composes the message, and then sends it. The message then reaches the server and is stored in appropriate location in the database.
Change Management in Exchange:
The first step in change management is to define the change the type i.e. categorize the change. In Exchange theses changes could be:
• Applying service packs.
• Adding new servers
• Adding new users
• Adding new administrative group
• Changing backup and restore procedure
• Changing other existing system
Numerous parties are involved in Exchange Change Management. For instance, examining the following major change, i.e. upgrading all servers, can help in understanding how the various parties would typically interact with each other.
Step 1- Request for change is submitted to the change manager
Everybody in the organization should be authorized to submit a request for change (RFC).
Step 2- Change Manager Assesses the request
The change manager receives the RFC and records it in the change management log. The manager examines the RFC to see if it is a complete and practical proposal. If in any way the manager feels that the requested change is not feasible, he returns it back to the person who submitted the RFC.
After the change request is accepted and relevant information is gathered, the change manger prioritizes the change.
In this case, upgrading the server hardware is categorized as medium priority change and belongs to major change category. After this the change manager makes note of the priority and category in the change management log.
At this stage, if the RFC is assessed as a minor change or standard change, the change manager would probably pass the RFC directly to the change owner responsible for implementing the change. If the RFC is considered to be a significant or major change, it will be passed to a delegated team that will prepare implementation options for consideration in the next stage.
Step 3- Change is passed to IT Executive committee for approval
The IT executive committee has the responsibility of approving the major change in the organization. It will consist of senior member of IT staff in the organization. This committee will decide whether the hardware upgrade is required or not.
Step 4- Change is passed to Change Advisory Board for scheduling
The Change Advisory Board(CAB) consists of a core group of individuals, people who are familiar with business requirements, the user community, IT system technology and the organization’s application development, testing and support staffs.
Typically the CAB includes the release, capacity, configuration, network, security and system administration managers. In addition, the change manager appoints others who have expertise relevant to the particular RFC and representative from the group affected by the change. In this case, the expertise with Exchange and hardware is very important. The change manager may also decide to appoint an OEM vendor representative to the change advisory board.
The change advisory board determines the hardware upgrade schedule, according to IT executive committee recommendation. The CAB is also responsible for monitoring the changes and it ensures that all authorized changes are coordinated and scheduled to eliminate the possibility of one change negatively affecting another change.
Step 5- Change is passed to the Change owner
The change owner is responsible for planning and implementing the hardware upgrade once it has been approved and scheduled by the change management process. The change owner will provide feedback to the change advisory board, change manager and perhaps the change initiator during the implementation. Change manager involved in this stage monitors what change owner is doing.
After the upgrade is complete, the change owner will help the change manager and change initiator to assess the impact of change.
Minor changes would pass through a significantly simpler path, involving the change owner.
Step 6- Change Process Evaluation
After the change is implemented, the entire change management process from receipt of RFC till the implementation must be evaluated. This is done by conducting personnel interviews and reviewing documentation. The main objective is to assess the effectiveness of the change process. Unsuccessfully implemented changes should also be evaluated so that problems can be identified and corrected before further changes are initiated