Software Engineering is an evolving phenomenon with a permanent base. Generally, changes are inevitable. Change management is the most predominant feature of the development process in the software industry. Change management means managing the process of required changes as well as managing all artifacts of an evolving software system. During the maintenance of the software project, major part of the cost of the project are spent for requirement analysis, design, coding and testing; the remaining fund will not suffice the provision of support for software maintenance issues. As change is unavoidable during the project evolution, it is well known that managing software changes are very difficult, complicated and time consuming. This paper presents the definition of software maintenance, activities involved in the software configuration management, how the change management process works and the role of change request form in change management has been explained. Issues related to the change control process have been identified.
Keywords - Software maintenance, Configuration management, Change control, Change request form.
I. INTRODUCTION
Software maintenance is a very important phase in the software development life cycle. Once the software is delivered and installed, the users will begin to report the new software errors. They may also demand modifications and additions to the existing software projects. During the maintenance of an existing project , maximum part of the cost of the project are spend for requirement analysis, design, coding and testing, the remaining funding will not be enough to provide support for software maintenance issues. The funding will not sufficient for rework effort.
This paper contain about the definition of software maintenance, activities involved in the software configuration management, how the change management process works and the role of change request form in
change management has been explained. Some of the issues related the change control process has been identified, and proposal has been given to improve the efficiency of the project.
II. LITERATURE SURVEY ON SOFTWARE MAINTAINANCE AND SOFTWARE CONFIGURATION MANAGEMENT.
The IEEE Standard defines "Software maintenance as the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment" [1]. According to Kassem, Software maintenance encompasses all activities related to software enhancements performed after the software is deployed [2]. Software Configuration management (SCM) is a critical element of the software maintenance process [1]. The IEEE Standard for Software configuration management Plans is concerned with the activity of planning for Software configuration management (SCM) [3]. SCM activities include the identification and establishment of baselines; the review, approval, and control of changes; the tracking and reporting of such changes; the audits and reviews of the evolving software product; and the control of interface documentation and project supplier SCM[3][4]. As per Pressman, SCM is a set of activities that have been developed to manage change throughout the life cycle of computer software [4]. Change is inevitable when computer software is built. According to Pressman, Change Management is also called software configuration management (SCM), is a set of activities are developed to a) identify change b) control change c) ensure that change is being properly implemented , & d) report changes to others who have an interest [4].
Change Request Form
CM014F
Amendment Sheet
Version No.
Release Date
Modified by
Date
Reviewed by
Date
Authorized by
Date
1.0
20.07.2004
SEPG
Chandini
SEPG
18.02.2004
20.07.2004
1.1
02.11.2004
QMG
Ashwin R
SEPG
02.11.2004
02.11.2004
BASE TEMPLATE DETAILS
Template ID
CM014F
Template Name
Change Request Form
Template Version
1.2
Template Release Date
25.05.2005
Figure 1) Configuration Identification - Base lined
III. SOFTWARE CONFIGURATION MANAGEMENT
Software configuration is defined as a tool for tracking and controlling the development and evolution of a complex software system [2]. Software configuration Management provides a framework for managing change in a proper manner [5]. Activities of the Software configuration management plan involves
1) Configuration Identification
2) Configuration control
3) Configuration Status Accounting
4) Configuration Audit and reviews
5) Interface control
6) Subcontractor /Vender control [2][3][9].
Base lining is the process by which a given set of items formally become openly available in a standard location to the people who are authorized to use it. The Collection of work products (files) is identified as a configuration and given a configuration Id. Each of the individual files is associated with this Configuration Id, given unique version number and stored in a standard location as a unique file. Base line template is shown if figure 1. After the Base line process gets over, and then the next step moves to configuration control process.
IV. CONFIGURATION CONTROL PROCESS:
Configuration control or Change control process is subdivided into
a) Making a change request
b) Reviewing and authorizing the change
c) Carrying out the change
d) Reflecting the change in other related products [5][6].
The fig 2) shows the steps involved in the software change request management procedure.
Software user
Project manager
Project staff
Configuration manager
Change request
Analysed and evaluated
Change request report
Project prioritize and generate service order
Generate change status report
Service order
New Version
PerformChange
Approval Report
Project approval
l
Figure 2) A Change request procedure
Making a change request
A change request represents a documented request for a change management of the activities in a change process which is one of core activity in a software process [8]. This change request form contains the Project Name, Request No, Request By, Request date, problem reported date, name of the customer, Problem Reported Date, Reported By, RTT ID or issue id, Nature of the change or problem, Priority Level, Change Request Decision, Module(s), Affected Items, Effort Estimate, Solution Approved (PL), Status, Closed on. Required fields will be filled and submitted to the Configuration control board (CCB). Template of a change request form has been given below in the figure 3).
Product& Project ID/Name:
Request No. :
Request By :
Request Date :
Problem Reported Date
Customer :
RTT ID
Brief Description/Nature of the change or problem
Priority /Severity Level
Show stopper
High
Medium
Low
Change Request Decision:
Accept
Postpone
Reject
Module(s)
Affected Items
Job Assigned to :
1
2
3
Effort Estimate (Person Days) :
Solution Approved (PL) :
Status
Closed on
Fig 3) Template of a Change request form
Project ID
Project Name
CR No
Date
Requested By
Change Description
Module Name
Priority
Accepted/ Rejected
Approved / Rejected By
Assigned To
Severity
Affected Items
RTT Id.
Estimated Effort (hrs)
Actual Effort (hrs)
Estimated Start Date
Estimated End Date
Price Quoted
Actual start
Date
Actual End Date
Remarks
Figure 4) Change request Log
Reviewing and authorizing the change
Once the change request is complete, the process moves on to the reviews/approving authority associated with the items and configurations. After the client submits a change request form, the project manager evaluates the change request. Results of the evaluation are documented as a change request report (Change request Log), which is used to make a final decision on the status approval by the configuration manager or the director of information technology unit. Change control records usually cover: identification of the item/entity being changed, a description of the change, identification of the affected documents, signatures of the approvers, approval date, and effective date. Configuration control board (CCB) is responsible for making decisions. CCB will authorize level of authorities to approve the change request. If the change request is approved by configuration manager (considered as higher level), the project manager (next level) will prioritize the change request. After completion of the change implementation, a software status report will be produced and a new version will be available. The Change request Log (Figure 4) will give the clear details of all the information needed.
Carrying out the change
Once the change request has been approved, the next step is to make the actual change. In a multiuser data base system, when two are more users are concurrently trying to update the same record, then it will be a problem. Such updates must maintain the ACID property. ACID stands for Atomicity, Consistency, Isolation and durability. The mechanisms to ensure the above properties of updates are Workspaces.
d) Reflecting the change in other related products
Re-base lining is the next process in the configuration control process. It is essential to communicate the new baseline information to people likely to be affected by the component or product being base lined. The same level of communication will also be needed when an item is re-base lined. All the users of a given item or component should be made to use the latest version of an item to reduce inconsistencies and maintenance overheads.
Change Request Form
CM014F
Amendment Sheet
Version No.
Release Date
Modified by
Date
Reviewed by
Date
Authorized by
Date
1.0
20.07.2004
SEPG
Chandini
SEPG
18.02.2004
20.07.2004
1.1
02.11.2004
QMG
Ashwin R
SEPG
02.11.2004
02.11.2004
1.2
25.05.2005
Harisubbashini23.05.2005
NA
NA
BASE TEMPLATE DETAILS
Template ID
CM014F
Template Name
Change Request Form
Template Version
1.2
Template Release Date
25.05.2005
Figure 6) Configuration Identification Re-Base lined
V. COMMON ISSUES RELATED TO THE CHANGE CONTROL SYSTEM:
Poor Communication - Lack of communication between departments, failure to follow up or escalate change requests, and delayed or unsuitable notification of changes made by suppliers are some of the communication-related issues that impact the change control process. To discuss about the changes, most of the companies using a paper-based change control system are likely to rely on face-to-face exchanges, such as change control board meetings. The effectiveness of these meetings depends on their frequency and the availability of members to meet as emergency changes arise.
Poor Turnaround - Timeliness can build or break a product's chances of succeeding in the market. Companies that rely on a manual system to generate data and to route and track submissions and change orders are likely to have poor turnaround for change implementation because the system requires more time and effort. Delays may also result because of failure to recognize the urgency of a change and absence of a contingency plan for certain types of changes.
Ineffective Documentation - A manual system makes it more difficult to update documentation, including revision history, and to find/retrieve necessary data to support a change. The proposed change may be delayed when an outdated record does not show revision history, or testing may be duplicated because documentation has not been updated with results of a previous testing.
Training not integrated with Change - Adequate training of personnel is a must. When training control is not connected to the rest of the quality process, keeping training current with procedures that have changed can be difficult. Training tasks can easily fall through the cracks if employees are not as alert in seeking them.
To solve the above mentioned issues related to the change control process, communication between the various departments should be improved, Change request should be properly prioritized, Systemized documentation should be implemented, and adequate training should be given to the software maintainers.
VI CONCLUSION:
In this Internet world, consumers universal have become more aware about product quality. In response, manufacturers are changing their company philosophy. Customer satisfaction and continuous development of product quality have become the objectives not only of regulatory bodies, but manufacturers themselves. At the operational level, the focus is moving from detection to prevention. Companies recognize that it's their primary responsibility to determine if a proposed change could significantly affect safety or effectiveness of a product. Manufacturers increasingly realize that effective change control is integral to continuous quality improvement, which can ultimately help them increase customer satisfaction and prevent product recalls, product liability actions, and regulatory violations. The change management is only found in the software industry environment, gaining access to company data is difficult. The authorization of the organization is required together with the cooperation of management. The examination of IT change request forms is typical of the kind of information needed for our data collection. Change request records and change request forms are the primary focus of unit analysis identified in our case studies. Some of the issues related the change control process has been identified, and proposal has been given to improve the efficiency of the project.
