# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 4 Exploring and Assessing Issue Handling Processes
### Issue Handling Model (IHM)
Similarly, the functions \(\delta_{1}\) and \(\delta_{2}\) specify the absolute and relative values of issues handled in the considered state, while \(in(v_{j})\) is the set of all edges entering node \(v_{j}\). We can also introduce external graph edges related to the direct delivery of issues by reporters to a specified state. They can be modelled by adding an external state \(v_{ext}\) or a set of such states, e.g., corresponding to specified reporters. Depending upon the analysis goal, we can assume various restrictions on considered issues:  
_Issue classes_--issues of a specified type, priority, or severity, generated by a subset of reporters, etc. ;  
_Issue handling times_--issues reported after a fixed time moment, handled within a specified time, Scrum sprint, or program version, etc. We can also generate reduced graphs/models by deleting specified states (e.g., related to a lower number of handled issues, beyond the interest of studies, etc. ), merging/aggregating states or edges (e.g., merging diverse resolution states into one), and eliminating edges with flows below some threshold (e.g., 5%). With different forms of these functions, we can concentrate on different aspects of graph visualization (global or local perspective). These can characterize issue flow capacity, timing features, project actor activities, issue commenting patterns, issue processing patterns (path structures), etc. The IHM facilitates correlating issue report details stored in the database with structural features of the IHM. The observation granularity can be adjusted to global (aggregated) or local perspectives. The introduced IHM and the analysis methodology support finding desirable issue handling patterns and identifying anomalous behaviours. These studies can be formalized using regular expressions, defined using quality profiles, and supported by appropriate algorithms/tools. As an illustration, we present two IHM graphs. Graph nodes represent issue handling states, and the specified numbers denote the numbers of handled issues in the states and edges. Figure 2 presents an IHM graph relevant to bug handling in the commercial project P1. Issue processing starts in the _New_ state, and most issues are further moved to the _In Progress_ (1315 issues) or _To be Tested_ states (245), etc. The final state is _VerifiedClosed_ (1595). This is a relatively complex graph with 12 nodes, and it involves some processing loops (e.g., _New, To be Tested, New_). The reduced graph that skips edges handling less than 10% of the issues comprises seven states (_New, In progress, Review, Need Info, To be Tested, Roepened, Verified/closed_). For the issues _New Feature, Task, User Story_, the IHM graph is more complex (21 states) and reduces to nine states by eliminating edges handling less than 10% of the issues. For comparison, Figure 3 presents an IHM graph for the MongDB project covering only bug issues with major priority and nodes covering over 20% of the issues. It shows a dominant issue handling path. The full graph is more complex, involving 20 states. Graph analysis including issue handling paths are discussed in Sections 4.3 and 5. Figure 3: IHM graph of the MongoDB project covering major bug issues reduced to state nodes covering more than 20% of issues. Figure 2: IHM graph for handling software bugs in the commercial project P1. Algorithms for IHM graph analysis are adapted to their complexity, characterized by the following parameters: \(\left|\left.V\right|\right.\)--the number of nodes; \(\left.\left|\left.E\right|\right.\right.\)--the number of edges (graph size); \(d(G)=\left|\left.E\right|\right./(\left|\left.V\right|\right.\)*\(\left.\left|\left.V\right|\right.-1)\right)\(\left.\right)--graph density; and \(indeg(V)\) and \(outdeg(V)\)--the number of entering and leaving edges of the node, respectively.