If the user does not provide a target issue id list, then the "seed" spreadsheets contain information about all files changed by two or more different commits. 


In DV8, hotspots are defined as groups of frequently modified or bug-prone files within a given time range. DV8 extracts the design relationship between these files so that users can analyze whether design defects cause the high maintenance cost of these files.


After executing the "Analyze Software" function, DV8 stores all analysis results in the "Hotspot" folder. Now we elaborate on the hotspot analysis results.  


The seed-group folder contains a list of files that have been modified for various reasons. If the user's input contains a list of issue IDs, such as bug ticket IDs, this file lists the filegroups that multiple target issues have modified. If the user's input does not include a target ID list, this file lists the filegroups that multiple commits have modified. By default, DV8 considers files that have been changed because of two or more bug issues as "seed files". The user can modify this threshold using DV8 console commands. In this sample project, seven files were altered due to multiple bug fixes. We call these files seeds because they usually violate the single responsibility principle and are core files within design flaws. These seed files frequently propagate errors to multiple other files. 


The seed-hotspot folder contains the DSMs composed of these core files only. In the sample project shown below, DV8 found only one hotspot, indicating that these seven files are related. This phenomenon is consistent with our research results: the more error-prone or change-prone a file is, the more likely it is connected to other files.  



For each hotspot, DV8 automatically generates three matrices: a matrix that contains only structural information (*-structure-dsm.dv8-dsm), a matrix that contains only co-change information (*-history-dsm.dv8-dsm), and a matrix that combines the two (*-merged-dsm.dv8-dsm).  Users can open these files with the DV8 viewer and observe their relationships.


To analyze the impact of these core files on other files, DV8 also generates a set of Change Hotspots, including all files that have design relations with the core files. In this sample project, there are 361 other files connected to these seven core files. We can open this matrix and analyze the design anti-patterns within it. These 361 files exhibit all six anti-patterns. 


These files list the basic information of hotspots and their maintenance costs. As an example, the following form displays the data of this hotspot with 361 files.



The data in column C is the proportion of files with high bug rates in this filegroup. Among these 361 files, about 2% of the files showed high bug rates.


The data in column D is the proportion of all the project's buggy files covered by the filegroup. Cell D2 is 100%, indicating that all files in the system that are bug-prone are contained in this filegroup. 


Columns E, F, G, and H respectively list the number of bugs, the number of lines of code modified for bug-fixes,  the number of modifications, and the lines of changed code in this filegroup.


Columns I, J, K, L, M show the proportions of these values ​​to the total maintenance cost. 


These data show that although this hotspot only involves about 28% of the files in the system, it is responsible for about 72% of all bug-related changes and 54.3% of all bug-related lines of code. 


Taking hotspots as design debt, these two ROI spreadsheets quantify their debt and calculate the expected return on investment (ROI) after refactoring.