Maximizing Productivity for Maintenance and Support Project in IT Using CBR
Abhijit Chaudhuri
Assistant Consulta...
support service, they need to compete continuously with peer organizations to win new contract or
renew an existing one (A...
Process Implementation: This is planning of the maintenance procedure and needed
organizational interfaces during the plan...
problems (April et al., 2005; Yeo, 2002). Issues are resolved by contractor companies providing the
maintenance and suppor...
Figure 2. Sources of software maintenance-management information (Grady, 1987)
4. Case Based Reasoning is Problem-Solving
Figure 3. The CBR Cycle: a. Conventional (Asmodt & Plaza, 1994)
b. Enhanced (Watson, 2013)
For example, Fred – a novice co...
Can handle poorly understood domains (for example, many aspects of software engineering) since
solutions are based upon wh...
to in the future. It is much efficient than noting the errors in word document or spread-sheet, as here a
structured entry...
[13] Das, S., Lutters, W.G. and Seaman, C.G., “Understanding documentation value in software
maintenance”, Proc. 1st ACM S...
Abhijit Chaudhuri is Assistant Consultant at Tata Consultancy
Services Ltd., Kolkata. He has about 13 years of IT experien...
Upcoming SlideShare
Loading in …5

Abhijit chaudhuri


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Abhijit chaudhuri

  1. 1. Maximizing Productivity for Maintenance and Support Project in IT Using CBR Technique Abhijit Chaudhuri Assistant Consultant, Tata Consultancy Services Ltd Abstract: Indian IT (information technology) industry mostly earns from maintenance and support projects outsourced by non-IT industries such as banking, travel, insurance, manufacturing etc those use information system as the operating backbone of the organization. Maintenance and support not only incur 50-80% of total project cost, but also is responsible for business success of these client organizations. Hence in order to stay in growing competitive market and maintain profit margin, IT companies must increase their efficiency such that the earned service fee is higher than the staffing cost. If service level agreements (SLA) to be met along with minimum turn-around time (TAT) and customer satisfaction, support team’s problem-solving efficiency is a key factor. Support projects pose multifaceted problems due to several interfaces and dynamic nature as they evolve over years as per client’s changing requirements. A few-week long conventional transition phase and / or knowledge sharing session are inadequate to identify and prototype all possible issues and performance of team slows down due to trial and error approach. In systems engineering, criticality of a defect is given by its severity of impact, frequency and probability of detection. The third factor i.e. detection of the nature of the problem can be addressed by the basic logic that a problem can be worked out from previously solved similar problems or cases. In this regard, case-based reasoning (CBR) is a recognized tool and it has many advantages over other knowledge based systems. This research proposes CBR and its various modifications for productivity increase in maintenance and support projects. Keywords: Defect solving, IT, Maintenance and support, SLA, TAT 1. Introduction Currently IT & BPO industry contributes to about 7.5% of India’s GDP, out of which 69% comes from foreign market. In financial year of 2012, revenues generated from IT services was around 50.4% of the total industry resulting in accumulation of USD 50.8 billion (NASCOM, 2013). Among various types of IT services, namely, (1) consulting, (2) development and integration, (3) IT management and (4) process management, last two types are generally covered under maintenance and support – commonly known as support. It contributes more than 60% of the total revenue (Arora et al., 2001) and the services typically involve ongoing operation of IT infrastructure, software application, help- desk operation, running IT-enabled business processes for clients, etc (Ghemawat & Altman, 2007). Non-IT industries such as banking, travel, insurance, manufacturing etc those use information system as the operating backbone of the organization usually outsource the maintenance and support part to IT companies (Ahmed, 2006; Yeo, 2002). Similar to any other product, project or system, lifecycle of IT projects also has maintenance as the longest phase in which the particular software or system needs to perform its designated task. Usually support and maintenance activities are expected to consume almost 50 to 80% of the entire project total lifecycle cost. Moreover, it is responsible for business success of these client organizations. As there are many companies eager to provide
  2. 2. support service, they need to compete continuously with peer organizations to win new contract or renew an existing one (Asundi & Sarkar, 2005). Maintenance contracts are signed usually for three to five years in duration and many contracts are renewed if the client is satisfied with the contractor’s service (Arora & Gramdella, 2004; Jain 2010). If service level agreements (SLA) to be met along with minimum turn-around time (TAT) for a demanding customer, the support team should be highly competent. But an overstaffed team can reduce the profit margin for contractor and on the contrary an understaffed team may lead to missing of SLA clauses and even a service contract. Moreover, an understaffed team is overworked and in the long run, de-motivation leads to high employee turn-over rate that in turn costs to the contractor. Hence, to achieve a win-win situation in a maintenance and support project, more than the mere size of the team, but their problem-solving efficiency is a critical factor. By analyzing the unique features of maintenance projects, this paper proposes case-based reasoning (CBR) and its various modifications with many advantages over other conventional knowledge based systems for increasing the productivity of support team. 2. Characteristics of Maintenance & Support Projects Software maintenance is primarily the modification of a software product after delivery to rectify faults, to enhance performance or other attributes, or to adapt the product to a modified functional requirement while keeping the primary role of the product intact (Basili et al., 1996). As per IEEE ISO/IEC 14764 (ISO & IEEE, 2006), a delivered product requires maintenance and support and the process can be divided into following phases (Figure 1). Figure 1. Overview of Maintenance Process (ISO & IEEE, 2006)
  3. 3. Process Implementation: This is planning of the maintenance procedure and needed organizational interfaces during the planning phase of development work. Problem and Modification Analysis: This phase is after transition phase, when modification is needed. Here modification requests and problem reports are analyzed, alternative solutions are developed, selected options are approved and entire process is documented. Modification Implementation: The approved modification solution is implemented and tested. Maintenance Review/Acceptance: The results from the previous phase are tested to for the project required output and correctness. If accepted, project moves to next phase, else it returns to problem and modification analysis phase. This is iterated unless satisfactory results are obtained. Migration: A system may need modification to adapt or to migrate to a new environment. In this phase, actions for migration are planned and documented for the same. Retirement: At the end of its useful life, a software product is retired or closed after accepting its functional obsolescence in terms of cost for operating / upgrading, cost and technical quality (ease of maintenance, modularity, standardization etc). In order to retire a software product, the maintainer should determine the actions needed. Maintenance in general can be of mainly three types, namely (ISO & IEEE, 2006): Corrective / reactive: to correct problems as they appear during operation. Preventive: to detect and correct latent faults before they become operational faults. Predictive: mainly used for enhancement. Can be of two types: o Perfective: to detect and correct latent faults before they are diagnosed as failures. It is mostly refinement such as enhancement for users, improvement of program documentation and recoding to improve performance, maintainability or other relevant attributes. o Adaptive: to uphold usability in a changed environment to counteract functional obsolescence, such as up gradation. Among these types, the corrective or reactive maintenance is least desirable, but in reality they are unavoidable. This type of work may appear randomly and may disrupt a mission-critical application of the client leading to business loss in terms of revenue or reputation. Hence, corrective maintenance works are also critical for the maintenance and support team where 90-95% SLA requirements must be fulfilled. Moreover, unlike other project activities, corrective maintenance works don’t have an assigned duration or deadline – they must be carried out ASAP (as soon as possible) with least possible TAT. These unique features of maintenance projects are discussed by Abran & Nguyenkim (1993) as: Workflow is managed by queue management techniques instead of project management techniques. Modification requests is mainly trouble-shooting and not a planned activity, hence the requests appear randomly and cannot be planned or budgeted in the annual planning. Unlike change requests in a project, these modification requests don’t need senior level approval and are handled at the operational level by a small support team. The workload for maintenance work is aligned to user services and responsibility for the application. Priorities are dynamic and depend on the context. That means, a particular job can be halted or deferred temporarily if a more urgent job such as corrective maintenance work appears in the work list. 3. Importance of Documentation in Trouble-shooting Compared to other high-tech projects, information systems show higher failure rates and the cause may not always be technical, but can also be perceived organization alignment problems and process
  4. 4. problems (April et al., 2005; Yeo, 2002). Issues are resolved by contractor companies providing the maintenance and support. Here the service contract can be of two types, namely, unit rate and fixed fee. In the first case, clients are billed for man-hour which is sometimes inflated. Hence this traditional contracting method is largely replaced by fixed-fee contracts where for certain amount of revenue and the contract period, 24x7 support is provided as per SLA. SLA specifies TAT within which a support request should be responded and resolved. Less time is assigned for issues with high criticality value given by financial impact, work outage, number of clients / users affected, etc (Asundi & Sarkar, 2005). Hence, in this context, it is more profitable for the service provider company to have a support team as small as possible but with high problem-solving efficiency. There is always time constraint especially because the team often needs to work on poorly designed and coded software - developed primarily from outsourced components (Ahmed, 2006; April et al., 2005). As a result, insufficient or haphazard documentation of ‘lesson learned’ remain as an inherent drawback of support projects. However, it is impossible to have a constant team throughout the project life-cycle and relying solely on the expert knowledge of a veteran team member can be a suicidal idea. However, in reality such members are used as source of information either for the documents they created (for illustration, extension or contextualization) and even for the missing documents they should have prepared (Das et al., 2007). While dealing with such projects for about 9 years, the author realized that knowledge acquisition for projects which have constantly evolved over years as per client’s changing requirements are inherently dynamic and most overwhelming task in a maintenance project. Hence a conventional knowledge sharing session spanning usually over two weeks with a departing team member is inadequate because it is not feasible to identify and prototype all possible issues. As a result, the learning process slows down due to trial and error approach. It significantly affects the motivation of the new team, may cause missing of SLA or even in worst case, loss of a contract. From this discussion, it is evident that it is must to convert the team member’s tacit subjective knowledge into organizational knowledge in the form of objective information through proper documentation. Looking at various types of information (Figure 2), it can be inferred that written information can replace expert knowledge to a great extent provided it follows a proper format and allows timely retrieval of knowledge (not information) for similar new issues.
  5. 5. Figure 2. Sources of software maintenance-management information (Grady, 1987) 4. Case Based Reasoning is Problem-Solving Historical data or past experience is commonly used for problem solving. In the absence of quantifiable inputs, straight-forward methods such as statistical regression or Software Lifecycle Management (SLIM) technique (QSM, 2000) are preferably replaced by various machine learning tools such as artificial neural network, rule indication or analogy through case based reasoning or CBR (Kadoda et al., 2000). Compared to other techniques, CBR has the advantage of replication of human thinking on case-by-case basis while selecting a particular strategy for a particular problem especially for loosely-defined unstructured issues (Belecheanu et al., 2003). Since its inception in 1980’s at Yale University, case based reasoning (CBR) has been used in various domain of problem solving including projects in information technology (IT). It is a data-mining technique that remembers similar situations applied to solve previous problems. It uses the information and knowledge from such situations to solve a new problem (Aamodt & Plaza, 1994). A clear model for problem-solving is not needed. Instead CBR focuses on establishing cases and helps in easy development of a model by defining key attributes that express cases. It also allows simple maintenance and control of a vast amount of information by using a database technique (Kim et al., 2004). 4.A. Four Steps or 4Rs of CBR CBR can be describes as a cyclic process comprising "the 4R’s": Retrieve, Reuse, Revise and Retain (Aamodt & Plaza, 1994), this process is schematically shown in Figure 3a and illustrated through a simple example. Later, researchers have tried to enhance this 4R model. For example, additional steps of review and restore have been proposed by Berghofer and Iglezaki (2001) or review and refine by Watson (2013) as illustrated in Figure 3b. Retrieve: investigates and extracts the most similar previous case from a case base. Reuse: reuses the information and knowledge from the retrieved case to solve the new problem. Revise: analyzes degree of similarity between the new and the retrieved case. If the retrieved case cannot solve the new problem, the retrieved case is revised. Retain: stores in the case base the proposed solution for future problem solving
  6. 6. Figure 3. The CBR Cycle: a. Conventional (Asmodt & Plaza, 1994) b. Enhanced (Watson, 2013) For example, Fred – a novice cook wants to make blueberry pancakes. He can recall (retrieve) only one relevant experience of making successful plain pancakes. He must adapt (reuse) his retrieved solution and add the blueberries. Say in first attempt, Fred adds blueberries to the batter. But it turns blue- which is not desirable. So Fred revises his method and adds blueberries only after the batter has been spread into the pan. Fred records (retains) this successful new recipe. Now he has enriched experience and he is better prepared for similar pan-cake making jobs. The core of CBR is built on the case-base or a warehouse of completed cases or memory. Any new problem commonly known as target case is dealt as a case and codified in terms of the features those can describe the problem best. Based on these features or problem definition, similar cases are retrieved from the case-base. Retrieval process may use different parameters for different cases including manual preference, nearest values, nearest specification, most frequent, most recent, object-oriented similarity, fuzzy similarity etc (Berghofer & Iglezaki, 2001). More similarity means more successful case retrieval. After measuring similarity with the new case, each retrieved cases are ranked in decreasing order of similarity. Solutions from the nearest cases are reused along with some adaptive revisions to derive solution for this new case. Once this target case is solved, it is retained in the case-base. This is how the case-base develops over time just like humans gain expert knowledge (Shepperd, 2002). 4.B. Advantages of CBR CBR is argued to offer a number of advantages over many other knowledge management techniques (Bergmann, 2000; Shepperd, 2002): Reduces several of problems associated with knowledge acquisition and categorization. Deals with only problems that actually occur, leaving aside possible problems to generative or algorithmic systems. Documents failures, hence users can identify potentially high risk situations. Uses the existing database, hence reduces effort in problem solving.
  7. 7. Can handle poorly understood domains (for example, many aspects of software engineering) since solutions are based upon what has actually happened in contradiction to hypothesized models. Better user acceptance as people are more willing to accept solutions which are considered more trust-worthy as derived from similar real cases. Requires less maintenance compared to other knowledge-based systems. Grows with time and that’s why can adapt to a changing environment. But it should be remembered that CBR offers only ‘good’ solution and not the best or optimum one. Retrieved cases must not be blindly reused – the revision is critical. However, due to obvious advantages over other knowledge based tools, CBR has been extensively used in various domains. For example: in estimating software project effort in early stage (Benner et al., 2012; Kirsopp et al., 2002). Yang and Wang (2009) applied the CBR in managing information-system project as a recommender mechanism by offering preferences from previous cases to help project managers develop new project plans. 4.C. Modification of CBR Because of its capability to handle various issues, CBR has been a focus of research interest and many noteworthy works have been done to improve its performance by combining it with other standard methods. Kim et al. (2004) found that when combined with analytic hierarchy process (AHP), CBR gives less error. However, the main limitation of this approach lies with uncertainty and imprecision of human intervention for relative weighing of attributes. Similarly other methods such as generic algorithm (Kim & Kim, 2012), multiple regression analysis (Jin et al.,2012) has improved the performance of conventional CBR. 5. Application of CBR in Maintenance Project Due to confidentiality, the detailes of project or client are not disclosed, but the real problem is described clearly for illustration. In two projects involving a big manufacturing plant in one case and a major bank in another, it was observed that when the main web portal had issues involving many users, the blame usually came to the group involved in maintaining that portal. While experience showed that in most cases, the portals got data feeds from other applications, which malfunctioned and caused the error. In some cases the application was multi-tired and some of the layers which caused the problem were maintained by other support groups and the said layer was presented to the mother application as a black-box. It took considerable time and effort to pinpoint the source of the problem and take corrective action. In the case of the application which took feed from other applications, it received no data for a certain day. As a result, errors appeared for the next tier application receiving the feed while it tried to process data with blank input. The reported error looked weird and the support group could not identify it initially. The issue was solved after several conference calls among all support groups, while only one group was responsible for the particular error. It is nothing but wastage of valuable resource. This could have easily been avoided had there been a CBR case-base. The support group could have referred to it to match the pattern of the problem saving valuable time and reduce customer impact. Even if the exact error was not entered in the case base or not reported earlier, it could have indicated that when none of the systems that are intrinsically part of the portal had issues, one needs to look at a certain system which feeds it. There can be more than one such systems and one needs to identify which one needs to be investigated in case of which error. Just not missing feed, sometimes bad, irrelevant or out-of-the-range data also caused the problem. Any new error or problem could have been put in the repository as they were encountered, so as to build a knowledge base to be referred
  8. 8. to in the future. It is much efficient than noting the errors in word document or spread-sheet, as here a structured entry of case features and systematic search are adopted. 6. Conclusion The unique requirements of maintenance and support project along with their impact on business success of contractor organization are delineated. As we can see, a CBR case-base can vastly improve efficiency of support groups otherwise handling complex projects on trial and error basis. This will decrease the turn around time significantly and reduce customer impact. This will also translate in saving cost of support and reduce loss of business for client due to reduced downtime. This will ensure repeat business for the organization providing support and will guarantee more profitability for both organizations. Finally, adaptation of CBR in maintenance and support projects can be extended to other business activities and in turn will add value to organizational process assets. References [1] Aamodt, A., and Plaza, E., “Case-based reasoning: foundational issues. Methodological variations and system approaches”, AI Communications, 7(1), 1994, pp. 39–59. [2] Abran A. and Nguyenkim, H., “Measurement of the maintenance process from a demand-based perspective”, Journal of Software Maintenance: Research and Practice, 5(2), 1993, pp. 63-90. [3] Ahmed, R.E., “Software maintenance outsourcing: Issues and strategies”, Computers and Electrical Engineering, 32 (6), 2006, pp. 449–453. [4] April, A., Huffman Hayes, J., Abran, A. and Dumke, R., “Software maintenance maturity model (SMmm): The software maintenance process model”, Journal of Software Maintenance and Evolution: Research and Practice, 17 (3), 2005, pp. 197–223. [5] Asundi, J. and Sarkar, S., “Staffing software maintenance and support projects”, Proc. 38th Hawaii International Conference on System Sciences, Big Island, Hawaii, 2005. [6] Arora, A., Arunachalam, V.S., Asundi, J.M. and Fernandes, R., “The Indian software services industry”, Research Policy, 30(8), 2001, pp.1267-1287. [7] Arora, A. and Gramdella, A., “The globalization of the software industry: Perspectives and opportunities for developed and developing countries”, NBER Working Paper Series, NATIONAL BUREAU OF ECONOMIC RESEARCH, Cambridge, MA, 2004. [8] Basili, V., Briand, L., Condon, S., Kim, Y.M., Melo, W.L. and Valen, J.D., “Understanding and predicting the process of software maintenance releases”, Proc. 18th International Conference on Software Engineering, Berlin, Germany, 1996. [9] Belecheanu, R., Pawar, K., Barson, R., Bredehorst, B. and Weber, F., "The application of case based reasoning to support new product development decisions", Journal of Manufacturing Technology Management, 14 (1), 2003, pp.36-45. [10] Bener, A., Keung, J.W., Menzies,T. and Kocaguneli, E. "Exploiting the essential assumptions of analogy-based effort estimation”, IEEE Transactions on Software Engineering, 38 (2), 2012, pp. 425-438. [11] Berghofer, T.R. and Iglezakis, I. “Six steps in case based reasoning: Towards a maintenance methodology for case based reasoning systems”, In Professionelles Wissensmanagement .Erfahrungen und Visionen (Includes Proceedings of the 9th German Workshop on Case.Based Reasoning, GWCBR 2001). Ed. H.P. Schnurr, S. Staab, R. Studer, G. Stumme and Y. Sure, Aachen, Germany, Shaker.Verlag, 2001, pp. 198.208. [12] Bergmann R., “Introduction to case-based reasoning”, University of Kaiserslautern, 2000, Web. 19 June 2013 <>.
  9. 9. [13] Das, S., Lutters, W.G. and Seaman, C.G., “Understanding documentation value in software maintenance”, Proc. 1st ACM Symposium on Computer Human Interaction for Management of Information Technology (CHIMIT’07), Cambridge, MA, USA, 2007. [14] Ghemawat, P. and Altman, S.A., “Industry case study: The Indian IT services industry in 2007, 2007, Web. 19 June 2013 < industry.pdf>. [15] Grady, R.B., “Measuring and managing software maintenance”, IEEE, Software, 4(5), 1987, pp. 35-45. [16] ISO and EEE, ISO/IEC 14764 IEEE Standard 14764-2006 International Standard: Software Engineering - Software Life Cycle Processes - Maintenance, ISO, Geneva, 2006. [17] Jain, M., “Six Sigma approach: Key to enhance productivity and customer delight in a support project”, Infosys White Paper, Infosys, 2010, Web. 19 June 2013 <>. [18] Jin, R.Z., Cho, K.M., Hyun, C.T. and Son, M.J., “MRA-based revised CBR model for cost prediction in the early stage of construction projects”, Expert Systems with Applications, 39(5), 2012, pp. 5214–5222. [19] Kadoda, G., Cartwright, M. and Shepperd, M. "On configuring a case-based reasoning software project prediction system," Proc. UKCBR5 - 5th UK CBR Workshop, Cambridge, UK, 2000. [20] Kim, G., An, S., and Kang, K., “Comparison of construction cost estimating models based on regression analysis, neural networks, and case-based reasoning”, Building and Environment, 39(10), 2004, pp. 1235–1242. [21] Kim, K.J. and Kim, K., “Preliminary cost estimation model using case-based reasoning and genetic algorithms”, Journal of Computing in Civil Engineering, 24 (6), 2010, pp. 499–505. [22] Kirsopp, C., Shepperd, M. and Hart, J., “Search heuristics, case-based reasoning and software project effort prediction”, Proc. GECCO 2002: Genetic and Evolutionary Computation Conference. 2002, New York, 2002. [23] NASCOM. “Indian IT-BPO Industry”, NASCOM, 2013, Web. 19 June 2013 <>. [24] QSM: Software Lifecycle Management (SLIM) Training Version 2.02, Quantitative Software Management®, Inc. McLean, Virginia, USA, 2000. [25] Shepperd, M. Technical report TR02-08: Case-based reasoning and software engineering, Bournemouth University, UK, 2002. [26] Watson, I. “Case-based reasoning 1”, University of Auckland, 2013, Web. 19 June 2013 <>. [27] Yang, H.l. and Wang, C.S., “Recommender system for software project planning one application of revised CBR algorithm”, Expert Systems with Applications: An International Journal, 36 (5), 2009, pp. 8938-8945. [28] Yeo. K.T., “Critical failure factors in information system projects”, International Journal of Project Management, 20 (3), 2002, pp. 241–246. Author Profile
  10. 10. Abhijit Chaudhuri is Assistant Consultant at Tata Consultancy Services Ltd., Kolkata. He has about 13 years of IT experience in various roles, focusing on web-based applications’ development, support and consulting. He is experienced in managing large and complex development and maintenance projects in various domains, including both Microsoft and Sun/Oracle Technologies. He has managed diverse teams with conflicting interests across multiple geographic locations, has been an effective player in customer management. His business domains include banking and finance, manufacturing, revenue & taxation and e-commerce.