Project process backtracking method and system based on timeline and graph database

Abstract

The invention provides a project process backtracking method and system based on a timeline and a graph database, and aims to solve the problems of difficult data backtracking, complex integration and lack of full-process visualization caused by tool chain splitting of an enterprise IT team. The method comprises the following steps: accessing heterogeneous DevOps tool data through a plug-in mechanism; modeling the accessed original data, defining a relationship among a data field, a filtering rule and a data object, and constructing a graph database; data visualization is achieved based on a graph database and a timeline, data can be inquired through an object and relation mode, and the data relation evolution process is traced back through a timeline. According to the method, an existing tool chain does not need to be transformed, full-process data association and visualization are achieved through fusion of the graph database and the timeline, the project problem backtracking efficiency and the data credibility are improved, and the method is suitable for process tracing and influence analysis of the full life cycle of software development.

Description

Technical Field

[0001] The present application relates to the technical field of software development process management, and in particular to a project process backtracking method and system based on a timeline and graph database. Background Art

[0002] Currently, enterprise IT teams commonly face complex and fragmented tool chains during project development. Different functional roles utilize specialized tools, such as test management tools, requirements management tools, code management tools, pipeline tools, and product management tools. Data from these various tools is stored independently, creating data silos. When teams conduct development activities based on requirements and versions, any issues that arise and need to be located require cross-toolchain data tracing.

[0003] However, the openness of different tools varies widely. If data synchronization is achieved through processes between tools, it can easily lead to the formation of a complex data synchronization network, which is not only difficult to maintain and expand, but also fails to fundamentally address the issues of unclear data models and low data credibility. While data integration and synchronization between tool chains can alleviate the problem of data silos to a certain extent, the need to combine multiple tools and long links for related information query and analysis often requires additional development, and full-process data visualization is impossible. These issues seriously affect the efficiency and accuracy of project problem identification and hinder the smooth progress of enterprise IT project development. Summary of the Invention

[0004] The present application provides a project process backtracking method and system based on a timeline and graph database to solve the problems existing in related technologies. The technical solution is as follows:

[0005] In a first aspect, an embodiment of the present application provides a project process backtracking method based on a timeline and a graph database, comprising: Access heterogeneous DevOps tool data through a plug-in mechanism. The heterogeneous DevOps tools include test management tools, requirement management tools, code management tools, pipeline tools, and product management tools. Model the incoming raw data, define data fields, filtering rules, and relationships between data objects, and build a graph database; Data visualization is achieved based on graph databases and timelines. Data can be queried through objects and relationships, and the evolution of data relationships can be traced back through the timeline.

[0006] In one embodiment, accessing heterogeneous DevOps tool data through a plug-in mechanism includes: Automatically or manually trigger data acquisition through plug-ins; Writing data to the heterogeneous DevOps tool via a plug-in; Access relational and non-relational database data through plug-in processing.

[0007] In one embodiment, modeling the received raw data includes: Define the name and data type of the data field through interface operations; Filter data according to preset conditions; Establish associations between data objects based on original data fields; Map the raw data into a graph database structure.

[0008] In one embodiment, mapping the original data into a graph database structure includes: Generate triplet relationship network of requirements, code and test cases based on Neo4j engine; Set the creator and modification time metadata properties for graph database nodes.

[0009] In one embodiment, the data visualization based on the graph database and the timeline includes: Retrieve data in object and relational formats using Cypher queries; Render the query results into a data graph view with switchable styles; Generate a timeline using a time type field. Drag the timeline to reproduce the process of establishing data relationships. Traverse the graph database with a single node as the origin to generate a data impact link graph.

[0010] In one embodiment, traversing the graph database with a single node as the origin includes: Receive the node identifier input by the user; Traversing the relationship network related to the node based on the Dijkstra algorithm; The associated nodes and relationship edges are highlighted in the interface.

[0011] In a second aspect, an embodiment of the present application provides a project process backtracking system based on a timeline and a graph database, which is used to implement a project process backtracking method based on a timeline and a graph database, including: DevOps data access module, configured to access heterogeneous DevOps tool data through a plug-in mechanism; A data modeling module is configured to model the raw data and build a graph database; The data visualization module is configured to implement data visualization query and backtracking based on the graph database and timeline.

[0012] In one embodiment, the DevOps data access module includes: Data acquisition unit, configured to automatically or manually trigger data acquisition from heterogeneous DevOps tools; a data writing unit configured to write the processed data into the heterogeneous DevOps tool; The database access unit is configured to access relational databases and non-relational databases.

[0013] In one embodiment, the data modeling module includes: A field definition unit is configured to define data fields through interface operations; a data filtering unit configured to filter data according to preset conditions; A relationship establishment unit configured to define association relationships between data objects; The graph database construction unit is configured to map the original data into a graph database structure.

[0014] In one embodiment, the data visualization module includes: A query unit configured to receive Cypher query statements and retrieve data; A graph rendering unit configured to generate a data graph view with switchable styles; A timeline control unit configured to generate a timeline and reproduce the evolution of data relationships; The link analysis unit is configured to generate an impact link based on a single node traversal of the graph database.

[0015] The above summary is for illustrative purposes only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments and features described above, further aspects, embodiments and features of the present application will be readily apparent by reference to the accompanying drawings and the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. In the accompanying drawings, unless otherwise specified, the same reference numerals throughout multiple drawings represent the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that the following drawings only illustrate certain embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, other relevant drawings can also be obtained based on these drawings without paying creative work.

[0017] Figure 1 This is a schematic diagram of the steps of a project process backtracking method based on a timeline and a graph database according to an embodiment of the present application; Figure 2This is a functional architecture diagram of a project process backtracking system based on a timeline and graph database according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] Hereinafter, only certain exemplary embodiments are briefly described. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and description are to be regarded as illustrative in nature and not restrictive.

[0019] This application discloses a project process backtracking method based on timeline and graph database, the flow chart of which is as follows Figure 1 As shown, the following steps are included:

[0020] Step 1: Access heterogeneous DevOps tool data through the plug-in mechanism; including the following steps S101-S103:

[0021] S101. Plug-in development and adaptation Develop corresponding plug-ins for heterogeneous DevOps tools, including test management tools, requirements management tools, code management tools, pipeline tools, and product management tools. Each plug-in must include data reading and writing interfaces, with interface parameters matched to the corresponding tool's data format to ensure accurate parsing and generation of tool-readable data.

[0022] S102. Trigger mechanism configuration Develop a trigger condition configuration interface, where users can perform the following operations: Select automatic trigger conditions, such as setting the data update frequency (hourly, daily, etc.) or triggering data acquisition when a specific field (such as requirement status, code submission version) changes; Configure a manual trigger button, and users can immediately start the data acquisition process by clicking the button.

[0023] S103. Database access configuration Develop a database connection configuration module that supports users to enter the connection address, port, account, password and other information of relational databases (such as MySQL, Oracle) and non-relational databases (such as MongoDB, Redis). The system uses this information to establish a connection with the database and realize data access.

[0024] Step 2: Model the raw data received, define data fields, filtering rules, and relationships between data objects, and build a graph database; this includes the following steps S201-S204:

[0025] S201. Data field definition Provides a data field definition interface. Users can select the required fields from the original data obtained from the data access module by dragging and dropping, set the field name and data type (such as string, integer, date, etc.) on the interface, and click the Save button after completion. The system will record the field definition information.

[0026] S202.Data filtering settings Develop a data filtering rule configuration interface, where users can add filtering conditions, such as setting ranges for numeric fields and keyword matching for string fields. Each time a condition is added, the interface displays the filtered data set in real time. Users can adjust the conditions based on the preview results until they obtain the desired data.

[0027] S203. Object relationship definition The interface displays all data source objects with defined fields. Users can create relationships between different objects by dragging and dropping lines. For example, you can connect the "Requirement ID" field in the requirements management tool to the "Related Requirement ID" field in the code management tool to define a relationship between the two objects.

[0028] S204. Graph database construction After the user completes the above configuration on the data modeling interface, click the "Build Graph Database" button. The system will automatically process the original data according to the defined fields, filtering rules, and object relationships, and import the processed data into the graph database to form a structured graph data model.

[0029] Step 3: Data visualization is achieved based on the graph database and timeline. Data can be queried through objects and relationships, and the evolution of data relationships can be traced back through the timeline. This includes the following steps S301-S305:

[0030] S301. Query statement generation Develop a query interface. All data objects and relationship types are listed on the left side of the interface. Users can check objects and relationships and set query conditions (such as time range, status, etc.). The corresponding query statement is automatically generated on the right side of the interface, and users can directly use the statement to query.

[0031] S302. Data screening and result display After clicking the query button, the system executes the query statement and displays the results in the center area of ​​the interface. Users can further narrow the data range by setting secondary filtering conditions (such as the specific value of a field) in the results area. The filtered results are updated in real time.

[0032] S303. Data graph view rendering After filtering the query results, click the "Generate Graph" button and the system will render the results into a default graph view. Users can select different styles such as tree and ring in the graph style menu at the top of the interface. Clicking it will instantly switch the graph view.

[0033] S304. Timeline configuration and operation Below the graph view, users select a time type field (such as creation time) from the drop-down menu, and the system automatically generates a corresponding timeline. Drag the slider on the timeline to display all data and relationships at that point in time in real time. Click the "Autoplay" button to automatically scroll the timeline, and the graph will dynamically display the generation process of data and relationships.

[0034] S305. Node Impact Link Query In the graph view, the user clicks on any node (such as a code submission), right-clicks and selects the "View Impact Link" option. The system traverses the graph database, finds all data and relationships related to the node, and renders the relationship network in a new interface window. The user can view detailed impact links by zooming and panning.

[0035] See also Figure 2 , Figure 2 This is a functional architecture diagram of a project process backtracking system based on a timeline and graph database according to an embodiment of the present application.

[0036] This application discloses a project process backtracking system based on a timeline and graph database, which includes the following modules:

[0037] 1. DevOps Data Access Module: This module is used to access heterogeneous DevOps tool data through a plug-in mechanism. The DevOps Data Access Module includes:

[0038] Data acquisition unit: configured to automatically or manually trigger data acquisition from heterogeneous DevOps tools; Automatic triggering can retrieve data from heterogeneous DevOps tools at user-preset intervals (e.g., every 30 minutes, every hour). It can also be triggered based on specific events (e.g., code submissions, requirement status changes). When these events occur, the data acquisition process is automatically initiated, ensuring timely access to the latest data. Manual triggering allows users to proactively initiate data acquisition requests when needed through the system's provided interface (e.g., clicking the "Get Data Now" button). This allows data acquisition from specific DevOps tools or within a specific time period, meeting users' data acquisition needs in special scenarios.

[0039] Data writing unit: configured to write the processed data into the heterogeneous DevOps tool; It organizes data that has undergone system processing (such as format conversion, verification, and supplemental information) and accurately writes it to the corresponding heterogeneous DevOps tools according to the data formats and interface specifications required by these tools. It supports both batch and single-line write modes. Batch writes improve the processing efficiency of large amounts of data, while single-line writes are suitable for individual data updates with high real-time requirements. It also provides write result verification, prompts if a write fails, and supports retries.

[0040] Database access unit: configured to access relational databases and non-relational databases.

[0041] For relational databases (such as MySQL and Oracle), by adapting to their database drivers and query languages, a stable connection is established, enabling the reading of structured data (such as data in requirement tables and test case tables) and supporting data filtering and extraction. For non-relational databases (such as MongoDB and Redis), data access is achieved based on their data storage characteristics and access protocols. Unstructured or semi-structured data (such as log data and document data) can be obtained and converted into a format that the system can process.

[0042] 2. Data Modeling Module: This module is used to model raw data and build a graph database. The data modeling module includes:

[0043] Field definition unit: used to define data fields through interface operations; A visual user interface is provided, allowing users to define attributes such as field names (e.g., "Requirement Number," "Code Submitter"), data types (e.g., string, integer, date, Boolean), required fields, and field length limits for different data objects (e.g., requirements, code submissions, test cases, etc.). Defined fields can be modified, deleted, and queried, while field definitions are validated (e.g., to avoid duplicate field names) to ensure they meet data modeling requirements.

[0044] Data filtering unit: configured to filter data according to preset conditions; The system allows users to set various filtering conditions through the interface (such as a requirement status of "Completed", code submission time within a certain time period, test case execution result of "Failed", etc.). These conditions can be single conditions or combinations of multiple conditions (associated through the logical operators "AND", "OR", and "NOT"). After data is accessed, the raw data is screened according to the preset filtering conditions, eliminating data that does not meet the conditions (such as invalid data, redundant data, and erroneous data). Only data that meets the requirements is retained for subsequent processing, improving data quality.

[0045] Relationship establishment unit: configuration used to define the relationship between data objects; Based on raw data fields, users can define relationships between different data objects (e.g., "association" between requirements and code submissions, "coverage" between code submissions and test cases) through interface operations (e.g., dragging and dropping data objects, selecting associated fields). Defined relationships can be stored and managed, with the ability to view a list of established relationships, modify, or delete them, ensuring that the relationships between data objects accurately reflect actual business logic.

[0046] Graph database construction unit: configured to map raw data into a graph database structure.

[0047] Based on defined data fields and relationships between data objects, raw data is converted into nodes and edges in a graph database, with data objects serving as nodes and relationships between objects serving as edges. Attributes are added to nodes and edges (such as node creation time, modification person, and edge association strength). Leveraging the features of graph database engines (such as Neo4j), the data storage structure is optimized, improving query and traversal efficiency within the graph database and ensuring the accuracy and completeness of data mapping.

[0048] 3. Data Visualization Module: This module is used to implement data visualization query and backtracking based on graph databases and timelines. The data visualization module includes:

[0049] Query unit: configured to receive Cypher query statements and retrieve data; It provides a Cypher query input interface, supporting syntax highlighting, auto-completion, and syntax validation to help users write queries correctly. After receiving the Cypher query statement entered by the user, it sends it to the graph database to execute the query operation. It can parse and process the query results, extracting node, edge, and related attribute information, and pass the processed results to the subsequent visualization unit.

[0050] Graph rendering unit: configured to generate data graph views with switchable styles; Receives the result data from the query unit and generates a data graph view based on the node and edge information in the data. It supports switching between multiple graph styles, such as force-directed graphs (which can display the natural association state between nodes), hierarchical graphs (which can display node relationships by level), and ring graphs (suitable for displaying associations with a central node). Users can choose the appropriate style based on their needs. It also supports operations such as zooming, panning, and dragging nodes on the graph to facilitate detailed viewing.

[0051] Timeline control unit: configured to generate a timeline and reproduce the evolution of data relationships; Extract time-type fields from the graph database data (such as node creation time and relationship establishment time) and use them as the basis to generate a timeline, which marks key time points and corresponding event summaries. Users can drag the slider on the timeline or click a time point. The system will filter out nodes and relationships that existed before the selected time point and display them in the graph view, hiding nodes and relationships added after the selected time point. This reproduces the state of the data relationships at that point in time and clearly shows the evolution of data relationships over time.

[0052] Link analysis unit: configured to generate an influence link based on a single node traversal of the graph database.

[0053] The system receives a single node identifier (such as a node ID or name) from the user and, starting with that node, uses a graph traversal algorithm (such as Dijkstra's algorithm) to traverse the graph database, finding all nodes and relationships directly and indirectly associated with that node. Based on the closeness of the connections and the order of the paths, it generates influence links originating from that node and highlights these links in a special style (e.g., different colors and line thicknesses) in the graph view, allowing users to intuitively understand the scope and path of influence of a node on other nodes.

[0054] The above-described embodiments merely illustrate several implementations of the present invention. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, and all such variations and improvements fall within the scope of protection of the present invention.

Claims

1. A project process backtracking method based on timeline and graph database, characterized in that: include: Access heterogeneous DevOps tool data through a plug-in mechanism. The heterogeneous DevOps tools include test management tools, requirement management tools, code management tools, pipeline tools, and product management tools. Model the incoming raw data, define data fields, filtering rules, and relationships between data objects, and build a graph database; Data visualization is achieved based on graph databases and timelines. Data can be queried through objects and relationships, and the evolution of data relationships can be traced back through the timeline.

2. The project process backtracking method based on timeline and graph database according to claim 1 is characterized in that: The plug-in mechanism for accessing heterogeneous DevOps tool data includes: Automatically or manually trigger data acquisition through plug-ins; Writing data to the heterogeneous DevOps tool via a plug-in; Access relational and non-relational database data through plug-in processing.

3. The project process backtracking method based on timeline and graph database according to claim 1 is characterized in that: The modeling of the accessed original data includes: Define the name and data type of the data field through interface operations; Filter data according to preset conditions; Establish associations between data objects based on original data fields; Map the raw data into a graph database structure.

4. The project process backtracking method based on timeline and graph database according to claim 3 is characterized in that: Mapping the original data into a graph database structure includes: Generate triplet relationship network of requirements, code and test cases based on Neo4j engine; Set the creator and modification time metadata properties for graph database nodes.

5. The project process backtracking method based on timeline and graph database according to claim 1 is characterized in that: The data visualization based on the graph database and timeline includes: Retrieve data in object and relational formats using Cypher queries; Render the query results into a data graph view with switchable styles; Generate a timeline using a time type field. Drag the timeline to reproduce the process of establishing data relationships. Traverse the graph database with a single node as the origin to generate a data impact link graph.

6. The project process backtracking method based on timeline and graph database according to claim 5 is characterized in that: The traversal of the graph database with a single node as the origin includes: Receive the node identifier input by the user; Traversing the relationship network related to the node based on the Dijkstra algorithm; The associated nodes and relationship edges are highlighted in the interface.

7. A project process backtracking system based on a timeline and a graph database, used to implement the project process backtracking method based on a timeline and a graph database according to any one of claims 1 to 6, characterized in that: include: DevOps data access module, configured to access heterogeneous DevOps tool data through a plug-in mechanism; A data modeling module is configured to model the raw data and build a graph database; The data visualization module is configured to implement data visualization query and backtracking based on the graph database and timeline.

8. The project process backtracking system based on timeline and graph database according to claim 7 is characterized in that: The DevOps data access module includes: Data acquisition unit, configured to automatically or manually trigger data acquisition from heterogeneous DevOps tools; a data writing unit configured to write the processed data into the heterogeneous DevOps tool; The database access unit is configured to access relational databases and non-relational databases.

9. The project process backtracking system based on timeline and graph database according to claim 7 is characterized in that: The data modeling module includes: A field definition unit is configured to define data fields through interface operations; a data filtering unit configured to filter data according to preset conditions; A relationship establishment unit configured to define association relationships between data objects; The graph database construction unit is configured to map the original data into a graph database structure.

10. The project process backtracking system based on timeline and graph database according to claim 7, characterized in that: The data visualization module includes: A query unit configured to receive Cypher query statements and retrieve data; A graph rendering unit configured to generate a data graph view with switchable styles; A timeline control unit configured to generate a timeline and reproduce the evolution of data relationships; The link analysis unit is configured to generate an impact link based on a single node traversal of the graph database.

Images