A Framework for Software Maintenance and Support Phase Zafar Nasir and Abu Zafar Abbasi Department of Computer Science National University of Computer & Emerging Sciences Karachi, Pakistan {zafar.nasir, abuzafar.abbasi}@nu.edu.pk Abstract Software maintenance is one of the major concerns of software development and maintenance organizations. Over the years, the cost of maintenance has become the critical factor in decision making pertaining to long term viability of business and information systems. Software maintenance has strong bearing with overall software development life cycle. Depending upon the abilities of project team in the overall software development environment, a good software maintenance process would reduce the cost involved in terms of money, manpower, resources and time. In this paper we have discussed a simple but comprehensive framework for software maintenance and support phase. Based upon the guidelines of the proposed framework for software maintenance could be easily manageable and also become cost-effective. Keywords- software maintenance, framework, procedures, software support, process model I. INTRODUCTION Software organizations that rely on developing and maintaining software are facing new, globally competitive market. With the increase in competition among vendors all over the world, the customer is expecting the services and product of high quality, with little cost and complemented by top support service. Maintaining software is not an easy task, it requires the proper management system within the organization. The organization software maintenance system has to fulfill the needs like technical measure of the domain as well as optimum quality service, with maximize strategic impact and minimum cost of maintenance activities. To achieve above, organization would require continuous process improvement of processes for software maintenance. However, the software maintenance is noteworthy activity as the 75 percent of system s lifespan cost occupy by maintenance [2]. The term software maintenance bears a significantly different meaning with its counterpart i.e. hardware or machine maintenance. The software neither wears out nor deteriorates with time nor needed repair as does the hardware. Software maintenance implies the changes or upgradations required from clients after delivery of product due to observed bugs or requirement of some new functionality. Although the software maintenance phase starts after the delivery of product to the client, it covers a major portion of the cost, effort and time involved in the project. Broadly speaking software maintenance covers all the work made on a software system after it is delivered or becomes operational spreading to corrective changes, adapting to new requirements, improving existing functions, and enhancing application with new functions [3]. Formally we may define software maintenance as, Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment. [6] However, it may be noted that software maintenance is not just bug fixing but rather involves planning of post delivery operations, supportability, and logistics even in the development and testing phase. There is a strong relationship between software maintenance and project cost and effort estimation. A good software maintenance process could significantly reduce the maintenance cost to the organization as well make it more easily manageable. In overall software organization context, the development process and maintenance process share common tasks. High level relation between them is shown in figure 1 [5]. The information from development process is always required in maintenance process as in the case of software configuration where the continuous switching between this two processes take place. After the issue is reported and before the action is taken, the team evaluates and classifies it as Change request, Bug fix, Assistance, or Installation. After classification of logs, the development team is notified about the logged request. Evaluation is done by development team to identify the impact on the code and architecture of system. After approval of request, code and other artifacts are modified and update is provided to client. CUSTOMER USERS Services Agreement Management Services DEVELOPMENT TEAM Evaluation Solutions Problem Resolution/Communication SOFTWARE MAINTENANCE Contracts SUPPLIERS Figure 1. Relationship between Software Maintenace & Stakeholders 978-1-4244-8003-6/10/$26.00 2010 IEEE
The rest of the paper is organized as follows: Section II highlights the issues in software maintenance, section III describes our proposed framework, section IV describes a case study based on our proposed framework followed by conclusions in section V. II. ISSUES IN SOFTWARE MAINTENANCE A. Impact Analysis Impact analysis requires comprehensive examination of the impact of the changes or upgradations on the existing system. Maintainer must have comprehensive knowledge of the system structure and architecture. They utilize this knowledge to identify potential area or amount of work needed to cater the required changes and come up with timeline and estimates required to achieve the required change. Following are objective of Impact analysis: Determine the scope of the change Come up with estimate of resource required to achieve the work Examine the cost and benefit of change Classify the complexity of the change and communicate to others. The impact analysis is a key issue in software maintainability and has direct effect on cost of maintenance. B. Complex code and Architecture Maintenance cost shoots up when software is obliged to change. Sometime the changes requested by user when system does not meet their requirement, and sometime due to bugs the unanticipated fault occur in software program. All the change, either to fix bug or the addition of functionality is turn out to be tricky and complicated if architecture and code is complex. There is quantifiable cost correlated with the time spent on learning and understanding of the product. The research performed on large systems has indicated that the number of changes applied to the system and the complexity of the code both associate positively to the maintenance cost [1]. C. Lack of Understanding One of the essential tasks in modifying system is the understanding of system. The maintainer must know how system is used and developed. In fact the programmer takes majority of their time in understanding of the system before they start change. According to Parikh [2], The software maintenance is the world in which developers use up half of all their time. In that world, the main objective of the development is to develop new functionality. The major professional challenge is to understand the system. D. Undefined Process and Procedure for Maintenance It is a fact that most of the organizations do not have defined processes and standards for software maintenance. This is the most neglected area which results in more cost and time in maintenance phase. E. Involvement of Senior Staff It is important to have senior management commitment on maintenance to provide special services to customer. The inability of senior management comprehend the need and requirements of software maintenance undermines the customer relationship and increases the maintenance cost also. F. Maintenance Cost Estimation Software maintenance is an expensive phase in the software project life cycle and require careful assessment and estimation in order to come up with a viable project. Failing to do so sometimes cost much higher than anticipated also jeopardizing the organization reputation and customer relation. One of the examples of estimation of maintenance problem is Y2K bug; the bug that is considered as most expensive bug in the history of computer era. However the bug was rectified but required high cost and effort to prevent it. For example Nokia have spent around 75 million Euros for that purpose. G. Improper User Training At times it happened that software firm deployed the software without having any proper plan for user training which results in cost ineffective and unsatisfactory experience. Unless users don t know how to use the new or updated product, they would tend to make and report such bugs and errors that could have been resolved otherwise. So there comes requirement of a proper training process to ensure that users have received training to correctly and efficiently operate the software. H. Dependency on Outside Supplier At times, the software organization and their software maintenance department depend upon third party vendors, suppliers and outsourcers for specific services. For example, a supplier that customizes an ERP software. Sometime organization contracts with persons or even autonomous organizations that become part of maintenance team and provide their expertise when required. To offer quality maintenance service to client, maintainer must build good relationship with all suppliers and manage them professionally to achieve satisfactory performance. I. Lack of Documentation Documentation is considered as the most important artifact in software maintenance, especially for legacy systems where there is the requirement of migration to new platform. It has been proven that documentation assists to understand the system if it is exercised correctly. The maintenance team will not able to understand the design of system properly if there is lack of documentation and resulted in consumption of time before they could do some useful work. J. Measuring Maintenance and Support Service An organization must keep eye on evaluation of maintenance and support service. It will help them to improve the service and measure customer satisfaction.
Organization must conduct surveys and distribute questionnaire or any mechanism to obtain customer feedback about their product and maintenance services. K. Motivation of Support personal Maintenance is usually provided when there are bugs or failures occurred in the system. Lot of pressure is exerted on support personal as this is directly related to customer s satisfaction. Therefore support personal considers themselves as the second line staff and there are many instances where support personal is not appreciated like sale personal. Study shows that highly motivated maintenance team can really deliver results and organization must include maintenance cost as the part of product cost. III. A FRAMEWORK FOR SOFTWARE MAINTENANCE Most of the organizations do not have well-defined standards and procedure for the maintenance process [4]. Process management in software maintenance is the most unfocused area. Question arise why there is lack of interest in process and procedure of software maintenance. The researchers say that maintenance is the post delivery activity of software development process, hence given the least privilege. Based on the source of maintenance request, activities are managed through different processes. The source of maintenance can be project manager, users or operations department. We propose a software maintenance process that is easily manageable and in effect cost-effective also. It underlines the procedures, documents and roles associated with stakeholders of software maintenance process. A. System for Maintenance The purpose of this system is to streamline and document working relationship and procedures between customer support department and development teams. This system identifies the role of each stake holder, evaluates the change requests, perform impact analysis, implement the required changes, perform post change testing, versioning and documentation. Each customer complaint or change request must pass through this system so that it may be effectively managed and addresses. The key functionalities of such system are listed below: Receiving and logging customer calls related to maintenance Prioritizing and categorizing issues Assignment of issues to customer support engineers and/or developers Procedure for issue-fixes and minor enhancements. Procedure for issue evaluation and classification Procedure for issue closure Procedure for issue escalation To identify common recurring issues and close them for all clients Gauge and improve customer support by providing internal statistical and management reports on average issue response time Procedure for handling Change Requests Procedure for operating the Tracker System Providing an yearly report to the client about the issues/enhancements during the maintenance period Procedure for Code Versioning The key procedures are described below: B. Issue Logging Procedure Software maintenance related issues may be received in various forms including but not limited to: Direct phone call by the customer Email by the customer Demo of the issue by the client Issue communicated indirectly Developers must ensure that no issues are directly taken from customers bypassing maintenance department. In case if a customer directly calls a developer and reports an issue, developer should inform customer politely to send a formal email so that issue can be formally tracked. In addition Developer should share such reporting with customer support coordinator. In all cases, the maintenance department will log the call in a Issue Tracking System with all relevant details, and later inform the customer with an issue ID in the following format: PA - CA - Date - Issue # Product Abbreviation Client Abbreviation dd-mm-yyy Figure 2. Issue ID format Issue Number The additional information recorded in the Issue Tracking System other than the issue ID would be: Issue Reported by Issue Reporting Date and Time o Reporting date of issue will be the date when it is logged Brief description of the reported problem Expected time of problem fixing o If any information required to analyze the problem is missing, Customer Support should inform the customer that no tentative closing date will be issued till the time all the information is received and evaluation is performed. Also the aging of the issue will be considered from the point when customer has provided the required information. Issue Category (discussed in next section) C. Issue Evaluation and Classification Procedure Evaluation of an issue is the most critical aspect of maintenance and support life cycle. After an issue is
reported and before any action is taken the Customer Support team is responsible to evaluate the issue and classify it as one of following: Change Request Bug Fix (Source code update is required) Assistance Organization Internal Client Installation Server Migration Updation Required In case issue is classified as a general technical support call, maintainer should respond to customers queries over the phone or by mail using its knowledge base (Maintenance personnel, some formal trouble shooting guide) within reasonable time (immediately over the phone, or next day over the mail). If the issue is categorized as a configuration problem it should be discussed with the development team in case of insufficient training on particular product. However the prime resource for such problems should be from maintenance support and a resource from the development team can be assigned with maintainer for training purposes. In case of change requests the development will be done on the commitment expressed in CRF hence approval of CRF is mandatory. Evaluation of an issue will be carried out by a maintainer. A maintainer is responsible to analyze the issue, request logs from customer and in case of bug fixes try to pin point the problem. The goal of evaluation is that maintenance department provides Level 1 and Level 2 support of all issues. D. Change Request Procedure Change requests must be propagated to the Maintenance Department. The maintenance department will evaluate the change request and determine the feasibility of the change from the following perspectives: Does the change detract significantly from the standard operating procedure of the product? Does the change introduce any unacceptable security risk? Will the change introduce any instability in the system? If they determine that the change can be performed without impacting the quality of the product, then a further analysis will be done to determine the time and effort required for the change. All change requests will be undertaken once confirmation is received from the customer. The change request workflow for maintenance is shown in figure 3. In case the Maintenance department determines that the requested change is not practicable, the requested change will be declined and the client will be informed about the reasons for the decision. Figure 3. Change Request Management Workflow
Maintenance department logs the received Change Request (CR) in should be in some Tracking tool that is received via telephone, visit or email and notifies the Client about CR logging via email. Any CR received by Business Development (BD) or any other department is to be forwarded to maintenance department. Concerned Team Lead (TL) is notified about the logged CR. Evaluation of CR is done by the Team Lead (decline /accept / man-days efforts) and forwarded to maintenance department. Maintenance department in turns forwards it to BD. Business Department finalizes the financial impact of the CR and informs maintenance department. Maintenance department prepares the Change Request Form (CRF) and informs the customer to seek approval for the timelines and cost estimate. On approval, the Customer sends signed CRF back to maintenance department. In case a response against the CRF is not received, reminder (emails &/or call) needed to be sent to the client. After approval, a delivery date is provided to the Client. Before deployment, the validation phase is carried out. The assigned engineer is responsible to enter his comments after carrying out the testing. To ensure that the CRF has been tested, another developer or Senior developer would need to enter his Reviewed By comments, only after which the CRF can be sent to the Client. Incase his/her comments have not been entered, the update/patch would not be sent by the Maintenance Department. The acceptance of the CR maybe received via email (soft copy) or a hard copy to Maintenance Department. Once the CRF has been closed, assigned Support Engineer informs Finance, Business Department & Corporate Department about the formal closure of the CR. The CR status is set as closed and as per the payment terms, the invoice is raised. Response will be provided for CR evaluations and documenting the CRF, which will include the TL evaluation and BD time for cost evaluation E. Activities after Issue Closure 1) Probable cause analysis: If an issue has been resolved simply by restarting of the software or rebooting of the machine, a detailed post-issue analysis must be performed to identify the root cause of the problem. The call must not be closed until complete analysis and root cause has been determined. 2) Impact analysis: For all issues, an impact analysis must be performed to determine whether any other customer installations may be under threat of a similar incidence. If it is determined that one or more sites may be vulnerable to such an incidence, then an internal call must be logged to take proactive corrective measure for all such installations. 3) Sign off The Sign-Off form shall be filled by the maintainer which is signed by the Client Personnel. The details of the Sign- Off form shall be as follows Issue ID Issue Summary Severity Level Person assigned Activity Summary A brief description of the activity to be performed by the CSE/SE like deploying update patch or modifications required in a file. Expected time required Starting time Ending time Start time Completion time Client Personnel Client and CSE/SE Comments Client and CSE/SE Signatures This document is then kept in a physical file so as to keep the record of the activity performed respective to the issue of the client. IV. CASE STUDY We have tested the proposed framework in one of leading vendors of Pakistan in e-banking. They have developed complex switch, card production system and other e- banking systems. The company maintains 15 software systems ranging from the size of 10 thousand line of source code to 100 thousand line of source code. Many these products have been maintained over the years and frequently produce new releases. Of these product 60 percent is written in C, 30 percent in.net and 10 percent in proprietary fourth generation language. Most of these systems run on Linux and UNIX workstation, 10 percent run on ATM and CDMs. A. Data Collection Technique Following are the form used to collect the data to estimate maintenance cost: Customer Survey Form Customer Sign-off Form Release Log Change Request Form B. PVCS Tracker To ensure that information is recorded in an organized and systematic way in the PVCS Tracker by any personnel assigned to an issue logged in the tracker. Following is the procedure is applicable to anyone who is to use the PVCS Tracker and to ensure that all the work
done by the individual is recorded in the relevant fields of the PVCS Tracker. The CSD shall log an issue and fill in all the relevant details for logging an issue and shall assign it to a CSE or an SE whatever the case may be. The assigned CSE or SE shall then from there on feed in all the work done by him/her in the relevant fields of the PVCS Tracker. All concerned personnel shall have the PVCS Tracker open at all times during working hours so that any notification for an issue is not left unattended. C. Quantitative Analysis This section contains the result of data collected. The data consist of 10 complete releases of 5 products. The effect on per release is from 1000 hours to 2000 hours. Change in release from 1000 LOC to 5000 LOC. The mean effort distribution on different change requests is shown in figure 4. In our experience with the software development company, enhancements are more than correction showing that error corrections are relatively small changes while the enhancements are relative bigger changes in functionality of system. V. CONCLUSION Estimating the cost of maintenance is fairly complex due to correlation between core system and the changes applied to it. We have presented a customized taskoriented framework in this research paper to manage the processes for software maintenance. The framework includes procedures, tasks and activities that blend the software maintenance process to become more cost effective. The case study was performed at a local software house, where the model was validated. This has helped us to understand as to why efforts increase on application of changed processes. We believe that a more cost effective and comprehensive model can be developed by combining the presented quantitative approach with suitable reliability growth models. REFERENCES Figure 4. Effort Distribution on the Basis of Maintenance Types [1] Linda Brice, John Connell, Alam, A methodology for minimizing maintenance Cost, In proceedings of AFIPS Joint Computer Conferences, pp. 113-121, 1983 [2] Parikh G, Tutorial on software maintenance, IEEE, New York, 1983 [3] Alain April, Jane Huffman Hayes,, Alain Abran, and Reiner Dumke, Software maintenance maturity model, 2004 [4] Khaled M. Khan et al, Task and method of software maintenance, A process oriented framework, Austrilian Journal of Information Suystems, Vol 9, No. 1, pp 51-60, 2001 [5] Hunt B Tuner, McRitchie, Software maintenance implications on cost and schedule, In proceedings of Aerospace conference, 2008 [6] IEEE Std. 610.12, Standard Glossary of Software Engineering Terminology, IEEE Computer Society Press, Los Alamitos, CA, 1990