FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: SYSTEMS AND METHODS FOR QUALITY MONITORING
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Nirmal Building. 9th Floor. Nariman Point.
SERVICES LIMITED Indian Mumbai 400021, Maharashtra, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter relates, in general, to quality monitoring and, in
particular, to quality monitoring of software tools and data repositories.
BACKGROUND
[0002] In many organizations, such as banking and financial institutions, various
software tools are used to automate business processes of the organizations. In due course of time, the users of a software tool may face various issues in utilizing the functionalities provided by the software tool. The issues faced by the users, while using the software tool, may be broadly classified into file related issues, rules related issues, and data related issues.
[0003] For example, issues relating to the software tool may broadly be classified as
code related issues or data related issues. Code related issues relate to inherent bugs or errors in design of the software tool itself. These issues result in wrong functionality or wrong results being generated by the software tool. Rectification may involve redesigning or rewriting of the tool code. On the other hand, data related issues are related to the form, content and usage of data, and may be related to rules or files. The file related issues can be further categorized into two categories, namely file transfer related issues and file content related issues. Examples of file transfer related issues include errors in transferring files leading to errors in uploading/downloading of data, lost records, junk characters getting inserted, improper parsing and transformation, errors in extraction of data, etc. File content related issues may be incorrect/ invalid format of the file, incorrect attributes and properties of the file, corrupted or empty or junk data in the file, data duplication, data redundancy, incorrect or invalid data, etc. Further, rules related issues may also arise in a software tool. The rules related issues usually occur due to incorrect interpretation of business rules or processes; incorrect implementation of business rules or processes in the software tool and so on.
SUMMARY
[0004] This summary is provided to introduce concepts related to systems and
methods of quality monitoring and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject

matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, the method comprises receiving an input indicative of
an issue with at least one software tool and ascertaining whether the issue is a data related issue, wherein the ascertaining comprises analyzing the issue. The method further comprises determining if the issue is a change request, on ascertaining the issue to be a data related issue and resolving the issue based in part on the analyzing and the determination.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying
figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1 illustrates a network environment implementing a quality monitoring
system, according to an embodiment of the present subject matter.
Fig. 2 illustrates an exemplary method of quality monitoring, according to an embodiment of the present subject matter.
DETAILED DESCRIPTION
[0008] In the present document, the word "exemplary" is used herein to mean "serving
as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
[0009] Systems and methods for quality monitoring are described herein. The systems
and methods can be implemented in a variety of computing systems. Examples of such computing systems include, but are not restricted to, mainframe computers, workstations, personal computers, desktop computers, minicomputers, servers, multiprocessor systems, laptops, network servers, and the like.

[0010] Conventionally a software tool is used to automate the various business
processes associated with the operations of an organization. Examples of such software tools include enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, and supply chain management (SCM) systems. The software tools are usually associated with various data repositories that store various types of data, such as enterprise data and customer data. However, in due course of time, the users of the software tools may face various issues or problems while utilizing the various functionalities provided by the software tool. For example, the software tool may generate an error while processing a request or command of the user. In another example, the software tool may generate an unexpected result or an erroneous result while processing a request or command of the user.
[0011] On encountering any issue with the functionalities provided by the software
tool, the user usually reports the issue to a helpdesk for example, by raising a ticket. The helpdesk performs a quick analysis of the cause of the issue and develops and deploys a patch or a quick fix so as to resolve the issue. The helpdesk conducts a preliminary investigation to detect the cause of an issue and based on the investigation offers various solutions to the user to resolve the issue. The helpdesk usually develops the patch or the fix without an in-depth analysis due to scarcity of time and resources. For example, a banking and financial institution would ideally want the software tools to be functional all the time especially during the business hours. Since downtime of the software tool results in high losses in terms of revenue and business opportunities, the helpdesk usually does not perform an elaborate analysis so as to determine the root cause for the issue, as the analysis is time consuming, and develops a temporary on-demand solution to resolve the issue.
[0012] For example, say if there is an issue in capturing the names of customers of the
financial institution. This would affect the compliance of the financial institution with various know your customer (KYC) regulations and other anti-money laundering activity regulation. Further, the issue relating to capturing the names of customers may affect a large number of transactions since the number of transactions during business hours is usually high. If the number of such transactions is significant, the financial institution may stop transactions till the issue is resolved. As mentioned earlier, owing to the urgency of such situations, the helpdesk usually attempts to resolve the issue by developing a quick fix or a patch. However,

the quick fix or the patch developed by the helpdesk is usually a case to case basis solution and is not intended for long term usage. For example, the user may face a slightly different issue, such as improper capturing of the account number of customers. For the same, the helpdesk would again perform a quick analysis of the cause of the issue, develop a patch or a quick fix and deploy the same so as to resolve the issue.
[0013] Moreover, at regular time intervals, a data quality management team may
check the integrity and correctness of the data generated or used by the software tools. For the same, the data quality management team may identify the issues faced by the users which were caused due to data related problems, such as inconsistency in the data of the organization, data duplication, data redundancy, incorrect or invalid data and junk values present in the data. Based on the identification, the data quality management team may suggest changes in the data structure or data format so as to minimize the issues faced by the users and reduce downtime of the software tools. The data quality management team may also analyze the impact of the suggested changes across the various modules of the software tool before actual implementation of the suggested changes. However, as mentioned earlier, an in-depth analysis of the issue is time consuming. Hence, by the time the data quality management team develops a solution to resolve the issue; the context of the issue may have drastically changed. For example, for a financial institution, the requirements from the software tools are very dynamic and may change frequently due to changes in political or economic scenario, natural calamities, and new regulatory compliances. Further, the financial institution may also change existing business processes or introduce new business processes so as to enhance revenue generation. Thus the solution developed by the data quality management team may no longer be relevant. Thus conventional quality monitoring solutions fail to promptly provide a relevant solution that is based on in-depth analysis of the issue.
[0014J The present subject matter describes systems and methods for quality
monitoring. It should be appreciated by those skilled in the art that though the systems and methods for quality monitoring are described in the context of providing quality support for software tools and data quality management, the same should not be construed as a limitation. For example, the systems and methods for quality monitoring may be implemented for various other purposes, such as for optimizing support provided by call centers, detection of

circular trading or insider trading in capital market operations, ensuring the highest system availability for online trading, and optimizing inventory of a retail chain.
[0015] In one implementation, the method of quality monitoring includes receiving an
issue from a user using a software tool. In one example, the issue may be indicative of the problem faced by the user while utilizing any functionality provided by the software tool. The issue may be received in various formats, such as a ticket, a message, an assistance request, a request on an interactive voice response system (IVRS) and so on.
[0016] The received issue is initially analyzed. In one example, the received issue may
be analyzed based on pre-configured analysis rules so as to determine whether the issue relates to a data related problem. In another implementation, a data support team may also analyze the issue so as to determine the cause of the issue. For example, the issue may be caused due to invalid data, incorrect format of data, junk values in data, incorrect file attributes, incorrect permissions to access a file, data duplication and so on. If, in the initial analysis, it is determined that the issue pertains to a data related issue, it is further determined whether the issue relates to a change request. If the issue pertains to a change request, such as change in the format of data, the impact of the change is analyzed.
[0017] As would be known to those skilled in the art, the same data repository may be
used by multiple software tools. Hence any change made in the data repository may have an impact on the functionalities of one or more software tools associated with the data repository. The impact analysis may be done to ascertain that the functionalities of other software tools are not adversely affected. The impact analysis may be in the form of a report which may be indicative of the targeted state of the data repository; the software tools and/ or the processes which may get affected by the proposed changes; and detailed description of any new processes which may need to be followed after implementation of the changes. The report may further include governance processes associated with the changes and a time-bound roadmap to implement the changes. Based on the impact analysis one or more fixes or patches may be developed to implement the change. The fixes or patches may then be tested and deployed to implement the change.

[0018] If the issue is determined not to be a change request, an analysis is done to
determine the root cause of the issue. Based on the analysis, adequate fixes and patches may be developed and deployed to correct the issue. In one implementation, the development of fixes and patches follows the software development lifecycle of requirement, design, development, testing and deployment. Once, the fixes and patches have been deployed, user feedback may be obtained to determine if the issue has been resolved. The method, as described, integrates support to be provided for software tools as well as management of data quality. For example, the issues faced by the user and as reported to the helpdesk may be used by the data quality management to identify issues in the data stored in the data repository. In said example, once the issue is received by the helpdesk, the data quality management team may also be notified of the same. Further, the initial analysis of the helpdesk may also be made available to the data quality management team so as to expedite the in-depth analysis of the issue. For example, the helpdesk may identify certain issues, such as data duplication or junk characters in the data. Based on the inputs of the helpdesk and the reports of the issues faced by the user, the data quality management team may work in parallel so as to determine and resolve the root cause of the issue thus saving time and costs involved.
[0019J As explained above, conventionally the helpdesk. which offers supports for the
software tools, and the data quality management team, which monitors the quality of data, work independently and a lot of effort made by the helpdesk during the initial analysis of the issues or the quality of data is duplicated by the data quality management team thus resulting in redundancy. Further, since the data quality management team and the helpdesk work independently, it becomes difficult to implement long term goals and objectives for data quality management. However, it will be apparent that present subject matter provides for inter operability between the helpdesk and the data quality management team to avoid replication of effort. For example, the issues reported to the helpdesk and the subsequent analysis done by the helpdesk may be made available to the data quality management team so as to reduce time and costs involved in the initial analysis of the quality of data by the data quality management team. In one implementation of the present subject matter, the application support system(s), the change management system(s), and the data quality management system(s) may be integrated together so that the issued identified, analyzed and

resolved by any one of the systems may be made available to the other systems so as to reduce time and costs in identification and analysis of the issues.
[0020] Further, in one embodiment, the measures taken by the data quality
management team in the past may be used to develop patches or fixes in the future. In said embodiment, say the data quality management team may have performed an in-depth analysis so as to determine the root cause of improper capturing of the names of customers. The same analysis may be used by the helpdesk as reference, if an issue pertaining to improper capturing of data is reported in future. Further in an illustration, a financial institution may have customers across various sections, such as savings account, current account, recurring and fixed deposits, credit and debit cards, mutual funds and stocks, etc. Consider a scenario where, while operating a software tool, a user fails to validate the account details, such as transaction details and current balance, of a customer and raises a ticket. In the analysis of the ticket, the root cause of the inconsistency may be identified as the inconsistency in the data format provided by two different sections of the financial institution, and the patches and fixes may be developed accordingly. If a similar ticket relating to the data inconsistency is received again, the analysis may be performed in a time efficient way, if the previous analysis is referred to. Further, it would also become easier to identify if the issue is caused at the source or data entry level or at the data extraction and transform level or at the data validation state.
[0021] Thus, the systems and methods for quality monitoring reduce time, costs and
risks involved in identifying and resolving issues faced while operating a software tool. In the said method, the analysis performed by the data quality management team and the subsequent corrective measure or recommendations made by the data quality management team may be used by the helpdesk while developing the fixes or patches for resolving an issue thus reducing downtime of a software tool. These and other features of the present subject matter would be described in greater detail in conjunction with the following figures. While aspects of described systems and methods for the quality monitoring can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).

[0022] Fig. 1 illustrates a network environment 100 implementing a quality
monitoring system 102, according to an embodiment of the present subject matter. In said embodiment, the network environment 100 includes the quality monitoring system 102 designed to provide quality monitoring of software tools and data repositories. In one implementation, the quality monitoring system 102 may be included within an existing information technology infrastructure or an existing software tool of an organization. For example, the quality monitoring system 102 may be interfaced with the existing application support system(s), change management system(s), data quality management system(s) of the organization.
[0023] The quality monitoring system 102 may be implemented in a variety of
computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the quality monitoring system 102 may be accessed by users through one or
more client devices 104-1, 104-2, 104-3 104-N, collectively referred to as client devices
104. Examples of the client devices 104 include, but are not limited to, a desktop computer, a portable computer, a mobile phone, a handheld device, a workstation. As shown in the figure, such client devices 104 are communicatively coupled to the quality monitoring system 102 through a network 106 for facilitating one or more end users to access and operate the quality monitoring system 102.
[0024] In one example, various computing systems 107-1, 107-2, 107-3.... 107-N,
such as a enterprise resource planning (ERP) system, a customer relationship management (CRM) system, an account management system and a supply chain management (SCM) system, henceforth collectively referred to as the application servers 107 and singularly referred to as the application server 107, may be connected to the network 106. The application server 107 may be implemented in form of a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. The application servers 107 may be configured to host and run various software tools used by the organization to conduct its business and/ or automate business processes. It should be appreciated by those skilled in the art that the application servers may be configured lor dedicatedly hosting a single software tool or may be configured to host and run multiple

software tools. Further, a single software tool may be hosted in multiple application servers 107 so as to distribute the load on the application servers 107 using conventionally known load balancing techniques or to provide redundancy in case of failure of an application server 107. The client devices 104 may communicate with the application servers 107 either directly or through the network 106.
|0025] Each of the application servers 107 comprises their respective data. For
example, the application server 107 hosting the CRM system may comprise client related data, while the ERP system may comprise enterprise resource related data. This data may either be stored in a local memory component of each of the application servers 107 or may be present in an external data store (not shown in figure) that may be coupled to the respective application server 107 either directly or through the network 106.
[0026] The network 106 may be a wireless network, wired network or a combination
thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.
[0027] In one implementation, the quality monitoring system 102 includes a
processor(s) 108, input-output (I/O) interface(s) 110, and a memory 112. The processor(s) 108 are electronically coupled to the memory 112. The processor(s) 108 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 108 are configured to fetch and execute computer-readable instructions stored in the memory 112.
[0028J The I/O interface(s) 110 may include a variety of software and hardware
interfaces, for example, a web interface, a graphical user interface, etc., allowing the quality

monitoring system 102 to interact with the client devices 104. Further, the I/O interface(s) 110 may enable the quality monitoring system 102 to communicate with other computing devices, such as web servers and external data servers (not shown in figure). The I/O interface(s) 110 can facilitate multiple communications within a wide variety of networks and protocol types. including wired networks, for example LAN, cable, etc.. and wireless networks, such as WLAN, cellular, or satellite. The I/O interface(s) 110 may include one or more ports for connecting the quality monitoring system 102 to a number of devices to or to another server.
[0029] The memory 112 can include any computer-readable medium known in the art
including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g., EPROM, flash memory, etc.). In one embodiment, the memory 112 includes module(s) 114 and program data 116. The module(s) 114 further include an issue tracking module 118. an analysis module 120, a change monitoring module 122, and other module(s) 124. It will be appreciated that such modules may be represented as a single module or a combination of different modules. Additionally, the memory 112 further includes data 116 that serves, amongst other things, as a repository for storing data fetched processed, received and generated by one or more of the module(s) 114. The data 116 includes, for example, application support rules 126, data quality management rules 128, henceforth interchangeably referred to as DQM rules 128 and other data 130. Additionally, the aforementioned data can be organized using data models, such as relational or hierarchical data models.
[0030] As explained previously, each of the application servers 107 comprises their
respective data which may either be stored in a local memory component of each of the application servers 107 or may be present in an external data store. In one example depicted in the figure, it may be considered that data associated with the application server 107-1 is stored in a data repository 132. The data repository 132 is coupled to the quality monitoring system 102. In one implementation, the data repository 132 may be an integral part of the quality monitoring system 102.
[0031] The data repository 132 may store various data generated and/ or used by the
application servers 107 for providing various functionalities of the application servers 107. In said example, the application servers 107 communicate with the data repository 132 over the

network 106. In another example, the application servers 107 may be connected directly with the data repository 132. It would be appreciated by those skilled in the art that the application servers 107 and the data repository 132 may be implemented in the same computing system or different computing systems. The data repository 132 may be storing data in various formats, such as relational tables, object oriented relational tables, indexed tables.
[0032] In operation, the users may use functionalities provided by the software tools
hosted by the application servers 107 by using the client devices 104. In case the user faces an
issue while using any of the software tools, the user may raise a ticket using the client device
104. The ticket may be received by the issue tracking module 118, henceforth also referred to
as the ITM 118. The ITM 118 may be configured to generate a unique identification code for
each ticket. An initial analysis may be performed by a helpdesk using the analysis module
120. In one example, the ITM 118 may generate a form or a template so as to facilitate the
helpdesk team to provide as inputs various details pertaining to the issue, such as problem
faced by the user; time of occurrence of the issue; operating conditions like operating system,
application software, etc., used by the user; business process the issue pertains to and initial
diagnosis report. In one implementation, the analysis module 120 may be configured to
retrieve various rules from the application support rules 126 so as to determine if the issue is a
data related issue. In one example, the rules for determining that the issue is a data related
issue may be based on phrases that describe an issue. For example, user may be given a
choice of typical phrases that describe a sub-type of issue like, null value for an attribute.
Based on the user selection, the analysis module 120 may be configured to determine if it is a
data related issue. In another example, the user may be provided with various categories and
sub-categories for categorizing the issue as a data related issue. In said example, the
categories may include a high level category of the issue and multiple subsequent granular
levels. In one embodiment, these rules can be configured in a workflow engine with
predesigned screens and drop-down boxes for selection of rules.
[0033] As explained previously, the data related issue may be caused due to data
duplication, data inconsistency, junk values in the data, erroneous format of data and so on. If the analysis module 120 determines the issue not to be a data related issue, the issue may be escalated to a software management team for further action. In case, the analysis module 120

determines the issue to be a data related issue, the analysis module 120 may be configured to notify a data support team and/ or a data quality management team of the same, for example, through an e-mail notification module (not shown in figure). In one example, the analysis module 120 may be further configured to determine if the data related issue is a change request. If the data related issue is determined not to be a change request, the data quality support team may develop one or more patches and fixes to resolve the issue. In one implementation, the analysis module 120 may be further configured to test the developed patches and/ or fixes and subsequently deploy the same.
[0034] In case, the data related issue is determined to be a change request, the analysis
module 120 may be further configured to notify a data quality management team of the same. In one implementation, the data quality management team may use the change monitoring module 122 to analyze the impact of the changes. In one implementation, the change monitoring module 122 may be configured to analyze and determine the impact of the proposed changes. For example, the user may have requested for a change in the format in which the date is stored in the data repository 132. As would be understood by those skilled in the art, the same data may be used by various software tools hosted by the application servers 107. Thus, changing the format of data to ensure compliance with a software tool may affect the functionality of other software tools. The change monitoring module 122 may be configured to determine the impact of the change on the operation of the various software tools. For example, a proposed change may result in changes in the existing processes or may need new processes to be defined. Further, the change monitoring module 122 may determine the number of files to be reformatted, the number of screens to be redesigned, and the number of applications to be modified. Accordingly, the change monitoring module 122 may also generate a time bound roadmap for implementation of the changes.
[0035] Based on the determined impact, the data quality management team may
develop various fixes and patches so as to implement the change and resolve the issue. In another implementation, the analysis module 120 may be configured to assess the data quality of the data repository 132 based on various rules defined as the DQM rules 128. In one example, the analysis module 120 may be configured to analyze the quality of the data based on various data quality parameters, such as data accessibility, data security, relevancy of the

data, data consistency, data integrity, and so on. Based on the analysis, the analysis module 120 may be further configured to generate suggestions and/ or changes so as to enhance the quality of the data.
[0036] Thus the quality monitoring system 102 reduces costs, time and risks invoked
in quality monitoring of the software tools and the data repositories. Further, when an issue is logged into with the ITM 118, identified as a data related issue by the analysis module 120, the ITM 118 may be configured to generate a notification to the data quality management team. The ITM 118 may be further configured to provide a detailed description of the issue and the details of the analysis of the issue to the data quality management team so as to save costs involved in identifying issues while assessing data quality. Further, in one implementation, the ITM may generate the template or the form, in which the helpdesk may provide the detailed description of the issue, in a format which is comprehendible by one or more data quality management tools used by the data quality management team. The quality monitoring system 102 thus integrates support provided for software tools and data quality management, and saves costs and time involved in quality monitoring by reducing duplication of efforts in identification and subsequent resolving of issues.
[0037] Fig. 2 illustrates an exemplary method of quality monitoring implemented by
the quality monitoring system 102, according to an embodiment of the present subject matter. The method 200 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method 200 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0038] The order in which the method 200 is described is not intended to be construed
as a limitation, and any number of the described method blocks can be combined in any order to implement the method 200 or alternative methods. Additionally, individual blocks may be deleted from the method 200 without departing from the spirit and scope of the subject matter

described herein. Furthermore, the method 200 can be implemented in any suitable hardware, software, firmware, or combination thereof. The method 200 is presently provided for quality monitoring.
[0039] It should further be appreciated by those skilled in the art that the steps
depicted in the method 200 may be carried out by helpdesk personnel using an application
support tool or by a data quality management team using a data quality management tool.
Further, the data quality management team and the help desk may utilize the method 200 in
parallel using an inter operable system, such as the quality monitoring system 102.
[0040] At block 202, an issue faced by a user while using the functionalities of a
software tool is received. In one example, the issue tracking module 118 may be configured to receive issues from the users. In one implementation, the users may report an issue faced while using a software tool by various means, such as by raising a ticket; by sending a message, for example, an e-mail; and so on. The issue may be related to an error or incorrect result encountered while using the software tool. Generally the issues may be broadly classified as file related issues, rules related issues, and data related issues as explained previously.
[0041] As shown in block 204, the issue is analyzed. In one implementation, a
helpdesk personnel may perform an analysis using an application support tool. In another implementation, the data quality management team may use a data quality management tool to perform the analysis. In yet another implementation, the helpdesk personnel and the data quality management team may use an interoperable system, such as the quality monitoring system 102, to perform the analysis. In another example, the analysis module 120 may be configured to analyze the issue based on preconfigured rules and classify the issue based on the characteristics of the issue. For example, an issue may be pertaining to incorrect file attributes, junk characters in data, unexpected or erroneous results and so on. As illustrated in block 206, it is determined whether the issue is a data related issue. In one implementation, the analysis module 120 may be configured to determine if the issue is a data related issue based on pre-defined rules. If, at block 206, the issue is determined not to be a data related issue, then the analysis module 120 may be configured to escalate the issue to a software management team for further action and as shown in block 222, a report may be generated

indicative of the same. If, at block 206, the issue is determined to be a data related issue, as shown in block 208, it is determined if the issue is a change request. In one example, the analysis module 120 may be configured to determine whether an issue is a change request based on pre-configured rules.
[0042] If at block 208, the issue is determined to be a change request then, as depicted
in block 210, the impact of the requested change is analyzed. In one implementation, the change monitoring module 122 may be configured to determine the impact of the requested change on the operations of the various software tools hosted by the application servers 107. For example, the change monitoring module 122 may determine the number of files to be reformatted, the number of screens to be redesigned, and the number of applications to be modified. In said implementation, the change monitoring module 122 may be configured to generate a report indicative of the targeted state of the data repository; the software tools and/ or the processes which may get affected by the proposed changes; and detailed description of any new processes which may need to be followed after implementation of the changes. The change monitoring module 122 may also generate governance processes associated with the changes and a time-bound roadmap to implement the changes. Based on the determination, as shown in block 212, a patch may be developed to implement the change. In one implementation, the analysis module 120 may be configured to generate patches to implement the requested change based in part on rules retrieved from the application support rules 126.
[0043] If at block 208, the issue is determined not to be a change request then, as
depicted in block 214, the root cause of the issue may be determined. In one implementation, the analysis module 120 may be configured to determine the cause of the issue based in part on rules retrieved from the application support rules 126. Based on the determination, as depicted in block 216, a patch may be developed to resolve the issue. In one implementation, the analysis module 120 may be configured to generate patches to resolve the issue based in part on rules retrieved from the application support rules 126.
[0044] As shown in block 218, the patches developed in either the block 212 or the
block 216 is deployed. In one implementation, the analysis module 120 may be configured to test the developed patches and then deploy the patch so as to resolve the issue. As shown in

block 220, it is determined whether the issue has been resolved or not. In one implementation. the analysis module 120 may be configured to request user feedback so as to determine whether the issue has been resolved or not. If, at block 220, the issue has been determined to have been resolved then, as shown in block 222, a report may be generated indicating the actions taken to resolve the issue. In one implementation, the analysis module 120 may be configured to generate the report. The report may include details of the analysis performed, the patches developed, the feedback or comments of the user as well as the data quality management team and the data support team. If, at block 220, the issue has been determined to have not been resolved then the above steps may be repeated till the issue is resolved.
|0045] Thus the quality monitoring system 102 facilitates quality monitoring of
software tools hosted by application servers 107 and data stored in data repositories, such as the data repository 132. The systems and method for quality monitoring as described in the present subject matter are generic and platform independent and thus can be used for various types of systems. For example, by appropriate modification, as would be understood by those skilled in the art, the quality monitoring system 102 may be used in capital markets, banking and financial institutions, travel and tourism industry, healthcare systems and so on.

I/We claim:
1. A method for monitoring quality of software tools, the method comprising:
receiving an input indicative of an issue with at least one software tool;
ascertaining whether the issue is a data related issue, wherein the ascertaining comprises analyzing the issue;
determining if the issue is a change request, on ascertaining the issue to be a data related issue; and
resolving the issue based in part on the analyzing.
2. The method as claimed in claim 1, wherein the analyzing is based on pre-configured rules, and wherein the resolving is based in part on the pre-configured rules.
3. The method as claimed in claim 1, wherein the method further comprises generating a report indicative of an impact of the change request on at least one process associated with the at least one software tool when the issue is determined to be a change request.
4. The method as claimed in claim 3, wherein the report is indicative of at least one of a targeted state of the at least one software tool, a targeted state of a data repository associated with the at least one software tool, definition of at least one new process, definition of at least one governance process associated with the change request and a time-bound roadmap to implement the change request.
5. The method as claimed in claim 3, wherein the method further comprises developing at least one of a patch and a fix so as to implement the change request.
6. The method as claimed in claim 5, wherein the method further comprises deploying the at least one of a patch and a fix so as to implement the change.

7. The method as claimed in claim 5, wherein the method further comprises determining whether the issue has been resolved based in part on user feedback.
8. The method as claimed in claim 1, wherein, on determining the issue not to be a change request, the method further comprises
determining a root cause for the issue based on pre-configured rules; and developing the at least one of a patch and a fix so as to resolve the issue based on the root cause.
9. The method as claimed in claim 8, the method further comprises:
deploying at least one of a patch and a fix so as to resolve the issue; and determining whether the issue has been resolved based in part on user feedback.
10. A quality monitoring system (102) comprising:
a processor (108); and
a memory (112) coupled to the processor (108), the memory (112) comprising, an issue tracking module (118) configured to:
receive input indicative of an issue with at least one software tool; an analysis module (120) configured to:
ascertain whether the issue is a data related issue based in part on at least one application support rule (126);
determine if the issue is a change request, on ascertaining the issue to be a data related issue; and
resolve the issue based in part on the at least one application support rule (126) and the determination.
11. The quality monitoring system (102) as claimed in claim 10, wherein the analysis module
(120) is further configured to notify at least one of a data quality management team and a
data support team of the issue.

12. The quality monitoring system (102) as claimed in claim 10, wherein the analysis module
(120) is further configured to:
deploy the at least one of a patch and a fix so as to resolve the issue; and determine whether the issue has been resolved based in part on user feedback.
13. The quality monitoring system (102) as claimed in claim 10 further comprising a change monitoring module (122) configured to generate a report indicative of an impact of a change pertaining to the issue on at least one process associated with the at least one software tool.
14. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
receiving an input indicative of an issue with at least one software tool;
ascertaining whether the issue is a data related issue based on pre-configured rules;
determining if the issue is a change request, on ascertaining the issue to be a data related issue; and
resolving the issue based in part on pre-configured rules and the determination.