A change tracking system (CTS) is a software tool for tracking and managing changes in issues (customer feedback, trouble tickets) and/or bugs (hardware/software defects).  It acts as a central repository, or database, of the issues and their related changes.  This database can be accessed by users in a distributed environment.  IBM® Rational® ClearQuest® is one such tool and there are many others, such as RMTrack and ikon Scorpion.  The changes to be managed are termed “change requests.”  Each change request has a number of attributes such as the product it is filed against, the status of the change request (unconfirmed, assigned, resolved, etc.),  who is assigned to work on it, severity, and more.  A history is kept for each change request, which describes each change that has been made to it.  While the CTS maintains a record of changes that have been made to change requests, it does not detect social patterns in that data.  A CTS is an excellent tool for keeping track of issues, reporting on issues and detecting and reporting patterns in issues but it does not provide any information on the patterns in the resolution of the issues. 
The IEEE (Institute of Electrical and Electronics Engineers) defines Software Configuration Management (SCM) as “the process of identifying and defining components in a system, controlling the release and change throughout the life cycle, recording and reporting the status of components and change requests, and verifying the completeness and correctness of system components.” [ IEEE-729] SCM systems provide a repository of code that comprises one or more software applications.  Such systems maintain a version history for each file in the repository.  The repositories provide the ability to manage and synchronize multiple simultaneous changes to the code by developers and multiple versions of each product. 
While SCM systems maintain histories of source code changes, they do not maintain a history of the stimulus and/or process that goes along with those changes.  This stimulus is recorded in the CTS.  Combination CTS/SCM (CTSCM) systems integrate change tracking and software configuration management into one system.  In such systems, each time a developer makes a change to the code, they indicate the stimulus for that change.  Typically, this is done by indicating the change request that is being addressed during the code check-in process, for example, “Fix Bug 20488.”  Such linkages between systems are often referred to as “traceability” linkages.  While CTS/SCM systems maintain traceability links among SCM and CTS systems, they do not derive social patterns from that historical data. 
Orthogonal Defect Classification (ODC) is a software tool that analyses change requests, producing a mathematical model that can predict where new defects are likely to appear.  Analysis of the ODC data is a valuable diagnostic method for evaluating changes and/or defects in software applications.  In ODC, software developers attach additional attributes to change requests.  These attributes enable ODC to produce a product profile.  This profile can be used to generate an expected signature for the product going forward.  When we see deviations from this expected signature in the future, we know we need to investigate further. 
The above-described systems focus solely on managing the technology processes and have neglected the human component of the change tracking cycle.  With non-transactional processes such as issue management, people interact and collaborate via e-mail, LANs or the Internet to influence the process.  The social interaction among these users of a change tracking system can have an impact on how expediently issues are resolved. 
Therefore, there is a need for a system to overcome the aforementioned shortcomings by bridging the gap between the technological and the social issues affecting change tracking