This document discusses using case-based reasoning (CBR) to improve productivity for IT maintenance and support projects. It describes how CBR involves solving new problems by retrieving similar past cases, reusing the solutions from those cases, revising as needed, and retaining the new solution. The document argues CBR has advantages over other knowledge management techniques for maintenance projects, which involve troubleshooting unpredictable issues under tight time constraints. It proposes using a modified CBR approach combining it with other methods like analytic hierarchy process to further improve productivity for IT support teams.

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. 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. 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. 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. 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. 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. 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. 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 < http://www.dfki.uni-kl.de/~aabecker/Mosbach/Bergmann-CBR-Survey.pdf>.

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 <http://www.aacsb.edu/resources/globalization/.../cases/indian-it-
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
<http://www.infosys.com/CRM/idea-center/Documents/six-sigma-approach.pdf>.
[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
<http://www.nasscom.org/indian-itbpo-industry>.
[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
<http://www.cs.auckland.ac.nz/~ian/CBR/cbr01.pdf>.
[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. 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.