Data processing method and device based on software research and development process and electronic equipment

Abstract

The invention discloses a data processing method and device based on a software research and development process and electronic equipment. Relates to the field of software engineering and artificial intelligence. The method comprises the following steps: acquiring a plurality of performance indexes in a software research and development process; performing anomaly detection on the plurality of performance indexes by adopting an anomaly detection strategy to obtain a detection result; under the condition that the detection result indicates that an abnormal index exists in the multiple performance indexes, a root cause for generating the abnormal index and supporting evidence are determined through the diagnosis agent, and the supporting evidence comprises evidence for supporting the accuracy of the root cause; and generating an exception analysis result of the software research and development process based on the root cause and the support evidence. According to the method and the device, the technical problem of poor analysis effect due to manual causal analysis of abnormal performance indexes in a software research and development process by adopting artificial experts in related technologies is solved.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and artificial intelligence, and more specifically, to a data processing method, apparatus, and electronic device based on the software development process. Background Technology

[0002] In the field of software engineering, industry frameworks such as Capability Maturity Model Integration (CMMI) are widely adopted to improve delivery efficiency and product quality. CMMI's high maturity levels, namely Level 4 (Quantitative Management) and Level 5 (Optimizing), require organizations to go beyond simple process definition and compliance, achieving data-driven quantitative understanding and continuous optimization. Its core idea lies in establishing Process Performance Baselines (PPBs) through statistical methods, monitoring process stability, and identifying and eliminating the root causes of problems when significant deviations occur through Cause-and-Effect Analysis and Resolution (CAR) practices, thereby achieving the goal of continuous improvement. The technical means employed in related technologies are mainly divided into two categories, but both have serious shortcomings, as detailed below:

[0003] The first category is manual causal analysis based on human experts. When abnormalities are detected in process performance indicators (such as defect density and delivery cycle), a team of experts is formed to conduct root cause analysis (RCA) through meetings, brainstorming, etc. However, in today's increasingly complex and fast-paced software development environment, manual RCA is lengthy, slow, and the analysis results rely on the expert's experience, making it prone to cognitive biases and inaccurate conclusions. In addition, the software development toolchain generates a huge amount of data, which cannot be fully analyzed manually. Finally, in the data collection stage, the metric definitions are not clear, and the data is scattered in silos and cannot be correlated. Therefore, manual analysis based on this data is unreliable.

[0004] The second category is software engineering performance measurement dashboards, which visualize key performance indicators (KPIs). However, dashboards typically display dozens of metrics but lack effective guidance and in-depth analysis, leading to a "data overload" dilemma where users spend a significant amount of time tracking data but rarely gain actionable insights. This easily fosters "vanity metrics" and undesirable behaviors (Goodhard's Law), not only failing to improve processes but also introducing more risks. It fails to inform decision-makers whether the former is a cause of the latter, nor can it quantify the likelihood of such a causal relationship. It requires reliance on guesswork or manual process analysis to uncover the truth.

[0005] In summary, manual causal analysis methods in related technologies are too slow, subjective, and unscalable to cope with the data deluge of modern software development; while performance dashboards fail to reveal root causes and may even negatively impact organizational culture and engineering practices due to misuse of metrics.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This invention provides a data processing method, apparatus, and electronic device based on the software development process, to at least solve the technical problem in related technologies where manual causal analysis of abnormal performance indicators in the software development process by human experts yields poor results.

[0008] According to one aspect of the present invention, a data processing method based on a software development process is provided, comprising: acquiring multiple performance indicators in the software development process; performing anomaly detection on the multiple performance indicators using an anomaly detection strategy to obtain detection results; when the detection results indicate that there are anomalies among the multiple performance indicators, determining the root cause and supporting evidence for the anomalies by means of a diagnostic agent, wherein the supporting evidence includes evidence supporting the accuracy of the root cause; and generating anomaly analysis results for the software development process based on the root cause and the supporting evidence.

[0009] According to another aspect of the present invention, a data processing apparatus based on a software development process is also provided, comprising: an acquisition unit for acquiring multiple performance indicators during the software development process; a detection unit for performing anomaly detection on the multiple performance indicators using an anomaly detection strategy to obtain detection results; a determination unit for determining, through a diagnostic agent, the root cause and supporting evidence for the anomaly indicators when the detection results indicate the presence of an anomaly indicator among the multiple performance indicators, wherein the supporting evidence includes evidence supporting the accuracy of the root cause; and a generation unit for generating anomaly analysis results of the software development process based on the root cause and the supporting evidence.

[0010] According to another aspect of the present invention, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the data processing method based on the software development process described above by executing the executable instructions.

[0011] According to another aspect of the present invention, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program controls the device where the computer-readable storage medium is located to execute the data processing method based on the software development process described above when the computer program is running.

[0012] This invention employs the following method: acquiring multiple performance indicators during the software development process; using an anomaly detection strategy to detect anomalies in these indicators and obtaining detection results; when the detection results indicate the presence of anomalies among the performance indicators, a diagnostic agent is used to determine the root cause and supporting evidence for the anomalies, including evidence supporting the accuracy of the root cause; based on the root cause and supporting evidence, an anomaly analysis result for the software development process is generated. This solves the technical problem in related technologies where manual causal analysis of anomaly performance indicators during software development by human experts yields poor results. This invention utilizes an intelligent agent to analyze the root cause and supporting evidence for anomalies in the software development process, avoiding the low efficiency and accuracy of causal analysis of anomaly performance indicators by human experts in related technologies, thereby improving the efficiency and accuracy of causal analysis of anomalies in the software development process. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0014] Figure 1 This is a flowchart of an optional data processing method based on the software development process according to an embodiment of the present invention;

[0015] Figure 2 This is a schematic diagram of an optional galaxy model according to an embodiment of the present invention;

[0016] Figure 3 This is a schematic diagram of an optional data processing system based on the software development process according to an embodiment of the present invention;

[0017] Figure 4 This is a processing flowchart of an optional data processing system based on the software development process according to an embodiment of the present invention;

[0018] Figure 5 This is a schematic diagram of a root cause analysis loop based on the ReAct framework for an optional diagnostic agent according to an embodiment of the present invention;

[0019] Figure 6This is a schematic diagram of an optional data processing device based on a software development process according to an embodiment of the present invention. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] For ease of description, some terms or nouns involved in the various embodiments of the present invention will be explained below.

[0023] IPOS (Intelligent Process Optimization System): The system name disclosed in this invention refers to the Intelligent Process Optimization System, which can be used to execute the data processing method based on the software development process provided in this application.

[0024] CMMI (Capability Maturity Model Integration): An industry-standard model for process improvement. This invention primarily focuses on practices at its high maturity levels (Levels 4 and 5).

[0025] MPM (Managing Performance and Measurement): A key practice domain of the CMMI High Maturity Level, focusing on the quantitative measurement and management of process performance.

[0026] CAR (Causal Analysis and Resolution): A core practice area of ​​CMMI Level 5, designed to identify and resolve the root causes of problems to prevent their recurrence.

[0027] SPC (Statistical Process Control): A technique that uses statistical methods to monitor and control process quality; the core tool is the control chart.

[0028] Common cause variation: inherent, stable, and random fluctuations in a process.

[0029] Special cause variation: Variation caused by a specific, unexpected, and attributable event, which is a signal that requires investigation and intervention.

[0030] Data Warehouse: A central data repository used for reporting and data analysis, integrating data from one or more heterogeneous data sources.

[0031] Galaxy Schema: Also known as Fact Constellation Schema, it is a logical data warehouse model that includes multiple fact tables sharing one or more dimension tables.

[0032] Bayesian Network (BN): A probabilistic graphical model that represents a set of variables and their conditional dependencies, suitable for causal inference and root cause analysis.

[0033] Large Language Model (LLM): A deep learning model trained on large-scale data, possessing powerful natural language understanding, reasoning, and generation capabilities.

[0034] Intelligent agent: An autonomous software entity that can perceive the environment, make decisions and perform actions.

[0035] ReAct (Reason+Act): An advanced framework for intelligent agents that solves complex problems by interleaving thought processes and actions.

[0036] DORA Metrics: A set of key metrics for measuring software delivery performance, including deployment frequency, change lead time, change failure rate, and mean recovery time.

[0037] It should be noted that the user information (including but not limited to user device information, user personal information, etc.), the collected information and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this invention are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, they do not violate public order and good morals, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0038] Example 1

[0039] According to an embodiment of the present invention, an optional data processing method based on a software development process is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0040] Figure 1 This is a flowchart of an optional data processing method based on the software development process according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0041] Step S101: Obtain multiple performance indicators during the software development process.

[0042] In this embodiment, multiple performance metrics can be obtained from the engineering data warehouse. The engineering data warehouse can include all data from the software development process. Various types of data involved in the software development process can be collected through various software engineering tools (e.g., project management systems, source code management systems, CI / CD (continuous integration / continuous delivery) tools, code quality scanning tools, etc.). For example, data can be continuously extracted from various heterogeneous software engineering toolchains (such as project management systems, source code management systems, CI / CD tools, code quality scanning tools, etc.) through ETL (extract, transform, load) or ELT pipelines, and then cleaned, transformed, and integrated to form a centralized, historical data storage.

[0043] In one alternative example, a galaxy pattern can be used for data storage in an engineering data warehouse.

[0044] Step S102: An anomaly detection strategy is used to detect anomalies in multiple performance indicators and obtain the detection results.

[0045] The aforementioned anomaly detection strategies may include: Statistical Process Control (SPC), using SPC control charts to detect anomalies in multiple performance indicators; and may also include: Exponentially Weighted Moving Average (EWMA) charts or Cumulative Sum (CUSUM) charts, machine learning-based anomaly detection models (e.g., Isolation Forest, One-Class SVM, or prediction models based on Recurrent Neural Networks (RNN / LSTM) that detect anomalies by the deviation between predicted and actual values), to obtain detection results.

[0046] The following explanation uses Statistical Process Control (SPC) as an example to illustrate an anomaly detection strategy: It can continuously monitor the time series data of key performance indicators (such as cycle time, defect density, etc., corresponding to multiple performance indicators), and use control charts to distinguish between "common cause variation" (inherent, random fluctuations in the system) and "special cause variation" (significant deviations caused by specific, attributable events) in the process. Performance indicators with special cause variation can be identified as anomalies.

[0047] In one alternative example, a monitoring agent can be invoked to call the statistical sentinel module, which uses statistical process control to detect the presence of anomalies. If anomalies are found, an anomaly event object containing information such as the anomaly indicator, time, and context can be generated.

[0048] Step S103: If the detection results indicate that there are abnormal indicators among multiple performance indicators, the diagnostic agent determines the root cause and supporting evidence for the abnormal indicators. The supporting evidence includes evidence supporting the accuracy of the root cause.

[0049] When the test results indicate that there are abnormal indicators among multiple performance indicators, an abnormal event object containing information such as the abnormal indicator, time, and context can be generated. Then, the abnormal event object is input into the diagnostic agent to perform root cause analysis on the abnormal indicator.

[0050] The tools in the aforementioned target tool set may include: causal reasoning tools and R&D process retrieval tools. In this embodiment, the diagnostic agent can select and call tools in the target tool set to perform anomaly cause analysis and collect supporting evidence.

[0051] Step S104: Based on the root causes and supporting evidence, generate anomaly analysis results for the software development process.

[0052] In this embodiment, the suggestion agent can query the internal organizational process assets and knowledge base to generate specific and actionable improvement suggestions. The root cause, supporting evidence and improvement suggestions can form the anomaly analysis results.

[0053] In one alternative example, an alerting / reporting agent can be used to push the final analysis results (packaged into a structured “process improvement case file”) to the relevant parties (e.g., project managers or those in charge of the software development process) through appropriate channels (such as automatically creating tasks in project management tools).

[0054] Through the above steps, this embodiment utilizes intelligent agents to analyze the root causes and supporting evidence of abnormal indicators generated during the software development process. This avoids the low efficiency and accuracy of causal analysis of abnormal performance indicators in software development processes performed by human experts, as is common in related technologies. Therefore, it achieves the technical effect of improving the efficiency and accuracy of causal analysis of abnormal indicators in the software development process. Furthermore, it solves the technical problem of poor analysis results when using human experts to perform manual causal analysis of abnormal performance indicators in software development processes.

[0055] Optionally, in the data processing method based on the software development process provided in this embodiment, the root cause and supporting evidence of the abnormal indicators are determined by a diagnostic agent, including: obtaining the time information associated with the abnormal indicators and the context information of the abnormal indicators; performing structured processing on the abnormal indicators, time information, and context information to obtain abnormal event objects; and determining the root cause and supporting evidence by calling tools in a target tool set through the diagnostic agent based on the abnormal event objects. The types of tools in the target tool set include at least one of the following: causal reasoning tools and development process retrieval tools. The causal reasoning tools are used to call causal inference strategies, and the development process retrieval tools are used to retrieve data in the software development process.

[0056] When the detection results indicate the presence of an abnormal indicator among multiple performance metrics, visual and contextual information associated with the abnormal indicator can be obtained to generate an abnormal event object containing information such as the abnormal indicator, time, and context.

[0057] In this embodiment, the example of "DORA indicator anti-pattern - abnormally high change failure rate" is used for illustration:

[0058] For example, during the automated optimization of the development process for product "Product-X", a typical DORA (Domain-Oriented Relationship) anti-pattern was detected at a certain point in time: Over the past week, the deployment frequency (DF) of product "Product-X" remained at a high level of 1.5 times per day, but its change failure rate (CFR) abnormally surged to 22%, significantly exceeding the 15% statistical control limit (UCL) set by the development organization. This is a dangerous signal (i.e., an anomaly), meaning that the team sacrificed quality assurance activities in pursuit of delivery speed. The following section details how to analyze this anomaly.

[0059] Step 1: Continuous Monitoring and Anomaly Detection: The monitoring agent continuously calls the statistical sentinel module. For the ratio-based metric "Change Failure Rate," the statistical sentinel module is configured with a P-Chart for monitoring. The control limits of the P-Chart can be dynamically adjusted based on the daily deployment frequency (sample size). When the latest calculated weekly CFR value is 22%, this data point exceeds the dynamic upper control limit of the P-Chart (15%), constituting a clear "Special Cause Variation" signal (i.e., an anomaly indicator).

[0060] Step 2: Triggering and Activating the Diagnostic Process: After the monitoring agent captures this "out-of-control signal," it immediately creates a structured "abnormal event object" with the following content:

[0061] { "event_id": "E-001", "timestamp": "2025-05-20T10:00:00Z", "product": "Product-X", "metric": "ChangeFailureRate", "value": 0.22, "ucl":0.15, "context": {"DeploymentFrequency": 1.5}}.

[0062] Where event_id represents the event ID, timestamp represents the time information, product represents the product, metric represents the performance metric, value represents the metric value, and context represents the context information.

[0063] Subsequently, the monitoring agent can use this object as input to activate the diagnostic agent and issue an initial instruction to it: "Investigate the root cause of the abnormally high failure rate of product 'Product-X' changes."

[0064] The tool types in the aforementioned target tool set include at least one of the following: causal reasoning tools and R&D process retrieval tools. Causal reasoning tools can be used to invoke causal inference strategies, and R&D process retrieval tools can be used to retrieve data during the software R&D process. For example, principle reasoning tools can be used to invoke causal investigation modules. Invoking causal investigation modules can utilize Bayesian networks to perform causal probability analysis. The goal is to answer "Why did this anomaly occur?", that is, to move from correlation analysis to causal inference.

[0065] The causal investigation module can pre-build a Bayesian network model where nodes represent various metrics (corresponding to performance metrics such as defect density, code complexity, and test coverage), and directed edges represent the causal relationships learned based on domain expert knowledge and historical data. When an anomalous signal (e.g., observing an abnormally high "defect density" value) is received as evidence input, the module can perform probabilistic inference, calculating the posterior probability of all other potential cause nodes in the network under that evidence. Finally, it outputs a list of potential root causes sorted by probability, such as {'excessive code complexity': 0.75, 'insufficient test coverage': 0.15}, providing decision-makers with quantitative, data-supported diagnostic conclusions.

[0066] It should be noted that Bayesian networks are used for causal inference in this embodiment of the invention. As an alternative, other causal discovery or causal inference algorithms can also be used, such as: (1) Granger Causality: For time series data, Granger causality can be applied to determine whether a time series is a useful factor in predicting another time series. (2) Structural Equation Modeling (SEM): SEM is a statistical method that can analyze causal relationships between variables, and can also be used to construct and verify causal models between software engineering indicators. (3) Causal Forests: As a machine learning method, causal forests can be used to estimate the effects of heterogeneous treatments, and are suitable for analyzing the impact of specific interventions (such as introducing new testing procedures) on performance indicators. Its purpose is consistent with the causal investigation module in this embodiment, that is, to mine causal relationships from data, and its output causal relationship graph or probability model can be called by subsequent agents to achieve the same function.

[0067] Step 3: Investigation of the root causes of automation based on an agent working framework (such as the ReAct framework).

[0068] After receiving a task, the diagnostic agent can initiate an investigation loop within the base agent's working framework. For example, the diagnostic agent can select and execute tools from the target tool set to determine the root cause and supporting evidence. For instance, it can call the R&D process retrieval tool to retrieve collected evidence or call the principle reasoning tool from the target tool set. The collected evidence is then analyzed using a Bayesian network to determine the root cause and supporting evidence.

[0069] It should be noted that in this embodiment, the diagnostic agent can be driven by the ReAct framework. Alternatively, other agent architectures or LLM invocation strategies can be used to drive the diagnostic agent, such as LLM function calling and planning agents. For LLM function calling: many related technologies' LLM (Large Language Model) have built-in function calling functionality. The diagnostic agent's toolset can be defined as a set of API functions, which can be called directly by the LLM generating structured JSON objects. Similar goals can be achieved on certain well-defined subtasks. For planning agents: more complex planning algorithms can be used, allowing the agent to generate a complete, multi-step action plan before taking action, and then execute it step by step. For example, using prompting strategies such as Plan-and-Solve.

[0070] Optionally, in the data processing method based on the software development process provided in this embodiment, based on the abnormal event object, the diagnostic agent calls tools in the target toolset to determine the root cause and supporting evidence, including: a first step, based on the abnormal event object, predicting the cause of the abnormal indicator and predicting the next action of the diagnostic agent to obtain a prediction result, wherein the next action of the diagnostic agent includes: selecting the tool to be executed from the target toolset; a second step, based on the prediction result, selecting the tool to be executed from the target toolset through the diagnostic agent and executing the tool to query evidence supporting the cause predicted in the first step; a third step, parsing the output result of the second step through the diagnostic agent; feeding the result returned by the third step back to the first step, and repeating the first, second and third steps until the diagnostic agent determines the root cause and supporting evidence.

[0071] The diagnostic agent described above can perform the following steps:

[0072] a. Reasoning (corresponding to the first step): The diagnostic agent (driven by LLM) first generates an internal reasoning text, i.e., the "thinking" process, based on the received anomalous event object and built-in domain knowledge (e.g., the DORA indicator anti-pattern knowledge base, i.e., the first knowledge base). This thinking process forms an initial hypothesis and plans the next steps to verify the hypothesis.

[0073] b. Action (corresponding to step two): Based on the results of the "thinking," the diagnostic agent can select the most suitable tool from its predefined set of target tools and execute it. This tool may be an internal call (such as calling the causal investigation module run_causal_analysis) or an external query (such as querying the project management system or source code management system via API).

[0074] c. Observation (corresponding to step three): The diagnostic agent can receive and analyze the results returned after executing the "action." This result will serve as new evidence and be input into the "thinking" phase of the next cycle.

[0075] This "think-act-observe" cycle can continue until the diagnostic agent has collected enough evidence to determine the root cause of the anomaly with high confidence, or to determine that the cause cannot be found. The ReAct framework makes the AI ​​investigation process flexible, intelligent, completely transparent, and auditable, fully recording the reasoning logic at each step.

[0076] The following example illustrates the issue of "DORA indicator anti-pattern – abnormally high change failure rate". The specific process for "Step 3: Root cause investigation of automation based on an agent-based working framework (e.g., the ReAct framework)" is as follows:

[0077] Cycle 1: Initial Hypotheses and Data Collection

[0078] Thought (corresponding to the first step): The diagnostic agent first reasoned: "A pattern of high deployment frequency (DF) and high change failure rate (CFR) has been detected. This is a typical 'speed versus quality' anti-pattern. According to the built-in knowledge base (i.e., the first knowledge base), the knowledge may have taken shortcuts in the release process, such as sacrificing code review or testing. The primary task is to obtain the specific deployment events that led to the failure in order to narrow down the scope of the investigation."

[0079] The Action (corresponding to the second step) can intelligently select and execute the tool query_incident_db(product='Product-X', time_window='past_7_days', status='failed_deployment'). This tool can query the Fact_Incidents (production incident fact table) and Fact_Deployments (deployment fact table) fact tables in the data warehouse.

[0080] Observation (corresponding to step 3): The tool returned two specific failed deployment records and their associated pull request IDs:

[0081] {"deployment_id": "D123", "pr_id": "PR-456", "fail_reason": "Integration test failed..."};

[0082] {"deployment_id": "D125", "pr_id": "PR-459", "fail_reason": "Production environment performance issues..."}.

[0083] Cycle 2: Investigate the first failure case in depth:

[0084] Thought: Diagnostic agent analysis observations: "The first failure case (D123) was directly caused by a test failure and is associated with PR-456. This is a strong signal of an internal quality problem. I should first investigate PR-456 in depth, examining its size, complexity, and the quality of the review process, which are key indicators of whether the review was rushed."

[0085] Action: The diagnostic agent executes the tool get_pr_metrics(pr_id='PR-456'). This tool can aggregate data related to the PR from tables such as Fact_PullRequests and Fact_Commits in the data warehouse.

[0086] Observation: The tool returned detailed metrics for PR-456.

[0087] {"lines_of_code_changed": 850, "files_changed": 25, "cyclomatic_complexity_increase": 40, "review_time_minutes": 15, "reviewers": 1}.

[0088] Loop 3: Call the causal investigation module to perform probability inference:

[0089] Thought: The diagnostic agent reasoned again: "The observations are critical. PR-456 is a massive (850 lines of code) and highly complex (cyclomatic complexity increased by 40) change, yet its review time was only 15 minutes, and there was only one reviewer. It was almost certainly a rushed and ineffective review. This evidence strongly supports my initial hypothesis. To obtain stronger, quantitative causal evidence, the causal investigation module will now be invoked, with these observations as evidence input."

[0090] Action: The agent executes run_causal_analysis(anomaly_event={'metric': 'CFR', 'value': 0.22}, evidence={'pr_size': 'very_high', 'pr_complexity': 'high', 'pr_review_time': 'very_low'}).

[0091] Observation: After receiving evidence, the causal investigation module (based on a Bayesian network) performs probabilistic inference and returns the posterior probability distribution of the potential root cause.

[0092] {'Inadequate_Code_Review_Process': 0.82, 'Insufficient_Test_Automation': 0.15, 'Developer_Skill_Gap': 0.03}.

[0093] Cycle 4: Comprehensive Analysis and Final Diagnosis

[0094] Thought: The diagnostic agent synthesizes all the information: "Now I have qualitative evidence (the metric from PR-456) and quantitative evidence (the probability output of the Bayesian network). The probability of 'insufficient code review process' is as high as 82%, and it perfectly matches the objective data of the specific case PR-456. I have collected a sufficiently strong chain of evidence to form a final conclusion."

[0095] Action: The diagnostic agent executes Finish ("Root cause identified: To maintain a high deployment frequency, the team's code review process for large, complex changes was insufficient, leading to a failure of the quality control gate. Key evidence: PR-456, directly related to deployment failure D123, has a massive amount of code changes (850 lines) and high complexity (cyclomatic complexity +40), but the review time was only 15 minutes. The causal inference model confirms this as the main driving factor with a confidence level of 82%.").

[0096] The diagnostic agent can perform root cause analysis in steps one, two, and three based on prompts. In one optional example, the prompts for the diagnostic agent could be: "You are a professional software development process diagnostic expert. Your task is to analyze a given anomaly, use available tools to conduct an in-depth investigation, and find the root cause. Anomaly: {……}, Available tools: {……}, History: {……}. Please reason and act according to the following format:"

[0097] Thought: [Your analytical approach and next steps];

[0098] Action: [Tool Name (parameter1='value1', parameter2='value2')];

[0099] Observation: Analyze the result returned after executing "Action" to determine if the root cause has been found. If the root cause is not found, use the result returned after "Action" as new evidence for the Tought in the next iteration. If the root cause has been found and a final diagnosis is ready, use:

[0100] Thought: [Summary and Analysis];

[0101] Observation: Finish(diagnosis='your final diagnosis').

[0102] Optionally, in the data processing method based on the software development process provided in this embodiment, the method of predicting the cause of abnormal indicators based on abnormal event objects by using a diagnostic agent includes: querying a first knowledge base based on the abnormal event objects to obtain query results, wherein the first knowledge base includes: indicator patterns of performance indicators, the causes of indicator patterns, and the required analysis indicators associated with the indicator patterns, and the indicator patterns include: indicator status; and predicting the cause of abnormal indicators based on the query results.

[0103] The first knowledge base mentioned above may include: performance indicator patterns, the reasons for generating indicator patterns, and the required analysis indicators associated with the indicator patterns. In an optional example, the data in the first knowledge base is shown in Table 1.

[0104] Table 1

[0105]

[0106] In this embodiment, the diagnostic agent can query the first knowledge base to obtain query results. For example, for an indicator pattern where high deployment frequency (DF) and high change failure rate (CFR) coexist, querying the first knowledge base can determine that the potential root cause may be the sacrifice of code review or testing. Key investigation indicators include PR review time and PR size. At this time, data retrieval and analysis can be performed on investigation indicators such as PR review time and PR size.

[0107] Optionally, in the data processing method based on the software development process provided in this embodiment, obtaining multiple performance indicators in the software development process further includes: extracting data generated during the software development process from multiple software engineering tools to obtain a target dataset, wherein the software engineering tools include: tools for managing the software development process; preprocessing the target dataset to obtain a processed target dataset; and determining multiple performance indicators based on the processed target dataset.

[0108] The aforementioned software engineering tools may include tools for managing the software development process, such as project management systems, source code management systems, CI / CD tools, code quality scanning tools, etc.

[0109] In this embodiment, data can be continuously extracted from various heterogeneous software engineering toolchains (such as project management systems, source code management systems, CI / CD tools, code quality scanning tools, etc.) through ETL (Extract, Transform, Load) or ELT pipelines to obtain the target dataset. The data in the target dataset is then cleaned, transformed, and integrated to form a centralized, historical dataset (corresponding to the processed target dataset). Subsequently, performance metrics can be extracted from the processed target dataset to obtain multiple performance metrics.

[0110] Optionally, in the data processing method based on the software development process provided in this embodiment, after preprocessing the target dataset to obtain the processed target dataset, the method further includes: determining a data storage strategy, wherein the data storage strategy includes one of the following: adopting a galaxy-pattern data warehouse or a data lake warehouse integrated architecture; and storing the processed target dataset based on the data storage strategy.

[0111] The aforementioned data storage strategies may include: a data warehouse using a galaxy model and an integrated data lake warehouse architecture. The integrated data lake warehouse architecture combines the flexibility of a data lake with the management characteristics of a data warehouse. Like the galaxy model data warehouse, it can also achieve unified storage and management of multi-source heterogeneous data and provide support for upper-level analysis.

[0112] The following explanation uses a data warehouse employing a galaxy schema as an example:

[0113] The logical model of a data warehouse can adopt the galaxy pattern (also known as the fact constellation pattern). Figure 2 This is a schematic diagram of an optional galaxy model according to an embodiment of the present invention, such as... Figure 2 As shown, unlike the star schema in related technologies which contains only a central fact table, the galaxy schema in this embodiment can contain multiple fact tables, representing different core business processes or events in the software development lifecycle. For example, it can construct Fact_Commits (code commit fact table), Fact_PullRequests (pull request fact table), Fact_Deployments (deployment fact table), Fact_Defects (defect fact table), and Fact_Incidents (production incident fact table). These fact tables can share one or more common dimension tables, such as Dim_Time (time dimension), Dim_Project (project dimension), Dim_Developer (developer dimension), etc. This galaxy schema architecture can accurately map the complex, many-to-many relationships between events in software development (e.g., a commit triggers a build, a deployment may cause an incident), thereby supporting in-depth correlation analysis queries across different business processes, such as analyzing "what type of code change is associated with the highest production change failure rate," which is difficult to achieve efficiently with a star schema containing a single fact table.

[0114] Optionally, in the data processing method based on the software development process provided in this embodiment, the anomaly detection strategy includes: a statistical process control strategy. This strategy is used to detect anomalies in multiple performance indicators to obtain detection results. Specifically, it includes: determining the control chart associated with each performance indicator based on a second knowledge base, wherein the second knowledge base includes the association between the type of performance indicator and the type of control chart used by the statistical process control strategy; and using the statistical process control strategy to perform anomaly detection on each performance indicator based on the control chart associated with each performance indicator to obtain detection results.

[0115] The second knowledge base mentioned above includes: the relationship between the types of performance indicators and the types of control charts used in statistical process control strategies, and the relationship between an optional performance indicator (such as the measurement indicator in Table 2) and the control chart, as shown in Table 2.

[0116] Table 2

[0117]

[0118] In this embodiment, the most suitable control chart type and outlier detection rule for each performance indicator can be intelligently selected based on Table 2. For example, for right-skewed periodic time data, the system will automatically select the single-value moving range chart (I-MR Chart) and only enable the "rule" that is least sensitive to the distribution pattern (a single data point exceeding the ±3 standard deviation control limit). This effectively avoids a large number of false alarms generated when traditional SPC methods are applied in this field, ensuring that only statistically significant deviation signals are passed to the next layer, greatly improving the system's signal-to-noise ratio and analysis efficiency.

[0119] Optionally, in the data processing method based on the software development process provided in this embodiment, the types of anomaly analysis results include: an analysis report; generating anomaly analysis results of the software development process based on root causes and supporting evidence, including: generating improvement suggestions through a suggestion agent based on root causes and supporting evidence, wherein the suggestion agent is used to determine improvement suggestions through a third knowledge base, wherein the third knowledge base includes: improvement suggestions corresponding to different anomaly causes; and generating an analysis report based on the analysis process of improvement suggestions and anomaly indicators.

[0120] Taking "DORA Inverse Pattern – Abnormally High Change Failure Rate" as an example, the diagnostic agent can pass supporting evidence and root causes to the recommendation agent. Upon receiving the root cause "Inadequate_Code_Review_Process," the recommendation agent can query its internal knowledge base (corresponding to the third knowledge base). The third knowledge base stores best practices related to CMMI practice domains, allowing it to find a matching improvement strategy and concretize and actionable it. Finally, the alerting / reporting agent can integrate all the outputs of the entire analysis process—the problem statement, root cause, key evidence in the ReAct loop (corresponding to supporting evidence), and improvement suggestions generated by the recommendation agent—into a complete "Process Improvement Case File" (corresponding to the analysis report). This file can be automatically pushed to the project management system, creating a new task of type "CAR (Cause and Effect Analysis and Resolution)," and assigning it to the project manager of "Product-X" and the organization's EPG (Engineering Process Group) leader.

[0121] The improved case study file automatically generated by IPOS is as follows:

[0122] 1. Problem Statement:

[0123] Over the past week, the change failure rate for the 'Product-X' project reached 22%, significantly exceeding the statistical control limit of 15%, constituting a special cause bias. During the same period, the project's deployment frequency remained high at 1.5 times per day, exhibiting a typical 'high speed, low stability' risk pattern.

[0124] 2. Summary of Causal Analysis:

[0125] Root cause 1: Insufficient implementation of code review processes for large and complex changes (confidence level: 82%).

[0126] Root cause 2: Insufficient coverage of automated integration tests (confidence level: 15%).

[0127] 3. Key supporting evidence:

[0128] Evidence A (related to PR-456): {"Number of lines of code changed": 850, "Number of files changed": 25, "Review duration": "15 minutes", "Number of reviewers": 1};

[0129] Evidence B (Causal Model Output): {"Root Cause": "Insufficient Review", "Posterior Probability": 0.82}.

[0130] 4. Actionable improvement suggestions:

[0131] Recommendation: Configure automated pipeline rules for the 'Product-X' codebase. When a pull request (PR) involves more than 300 lines of code changes or an increase in cyclomatic complexity of more than 20, it must be approved by at least two senior engineers before it can be merged.

[0132] Relevant CMMI Practices: This recommendation aims to strengthen the implementation of the 'Process and Product Quality Assurance (PPQA)' and 'Verification (VER)' practice domains.

[0133] This embodiment enables the automatic and intelligent transformation of massive, multi-source R&D performance data into improvement suggestions with deep causal insights and actionable results, thereby truly achieving automated and intelligent optimization of the software development process.

[0134] Example 2

[0135] Embodiment 2 of the present invention provides an optional data processing system based on the software development process, which can be used to execute the data processing method based on the software development process provided in Embodiment 1.

[0136] The core of this system lies in constructing a closed-loop system that integrates data integration, multi-stage intelligent analysis, and automated workflow orchestration. This transforms the core improvement cycle from MPM to CAR advocated by the CMMI High Maturity Level from a manually driven, periodic activity into an automated, continuously running intelligent process. The specific correspondence between the system's core modules and the CMM V3.0 High Maturity Practice Domains is shown in Table 3.

[0137] Table 3

[0138]

[0139] The following will elaborate on this from two aspects: system architecture and methodology:

[0140] (I) System Architecture:

[0141] Figure 3 This is a schematic diagram of an optional data processing system based on the software development process according to an embodiment of the present invention, such as... Figure 3 As shown, the system mainly includes three core modules: a data integration and modeling module, a hybrid analysis engine module, and an intelligent agent orchestration and execution module.

[0142] 1. Data Integration and Modeling Module:

[0143] This module forms the foundation of the entire system. Its core function is to break down data silos, a common problem in software development, and provide a unified, reliable, and high-quality data source for all subsequent analyses. It mainly consists of a dedicated engineering data warehouse.

[0144] (1) Engineering Data Warehouse: This data warehouse continuously extracts data from various heterogeneous software engineering toolchains (such as project management systems, source code management systems, CI / CD tools, code quality scanning tools, etc.) through ETL (extract, transform, load) or ELT pipelines, and cleans, transforms and integrates the data to form a centralized and historical data storage.

[0145] (2) Galaxy Schema Logical Architecture: A key technology in this embodiment is that the logical model of the data warehouse adopts the galaxy schema (also known as the factual constellation schema). For example... Figure 2As shown, unlike the star schema in related technologies which contains only a central fact table, this embodiment uses a galaxy schema containing multiple fact tables. These fact tables represent different core business processes or events in the software development lifecycle. For example, it can construct Fact_Commits (code commit fact table), Fact_PullRequests (pull request fact table), Fact_Deployments (deployment fact table), Fact_Defects (defect fact table), and Fact_Incidents (production incident fact table). These fact tables can share one or more common dimension tables, such as Dim_Time (time dimension), Dim_Project (project dimension), Dim_Developer (developer dimension), etc. This architecture can accurately map the complex, many-to-many relationships between events in software development (e.g., a commit triggers a build, a deployment may cause an incident), thereby supporting in-depth correlation analysis queries across different business processes. For example, analyzing "what type of code change is associated with the highest production change failure rate," which is difficult to achieve efficiently with a star schema containing a single fact table.

[0146] 2. Hybrid Analysis Engine Module:

[0147] This module is the "brain" of the system, capable of performing analytical tasks from anomaly detection to root cause diagnosis. It employs the concept of an "analysis funnel," consisting of three progressively functioning sub-modules to balance efficiency and depth of analysis.

[0148] (1) Submodule 2a: The Statistical Sentinel:

[0149] Core technology: Statistical Process Control (SPC).

[0150] Function: As the first line of defense for the analytics engine, this module continuously monitors time-series data of key performance indicators (such as cycle time, defect density, etc.) in the data warehouse. It uses control charts to scientifically distinguish between "common cause variation" (inherent, random fluctuations in the system) and "specific cause variation" (significant deviations caused by specific, attributable events) in the process.

[0151] Key technologies: Addressing the prevalent non-normal and skewed distribution characteristics of software engineering data (e.g., most tasks have short cycles, while a few have extremely long cycles), this module incorporates statistical intelligence. It can automatically diagnose data distribution and intelligently select the most appropriate control chart type and anomaly detection rules. For example, for right-skewed periodic time data, the system automatically selects an I-MR chart and only uses the "rule" least sensitive to distribution shape (a single data point exceeding ±3 standard deviation control limits). This effectively avoids the large number of false alarms generated by traditional SPC methods in this field, ensuring that only statistically significant deviation signals are passed to the next layer, greatly improving the system's signal-to-noise ratio and analysis efficiency.

[0152] (2) Submodule 2b: Causal Investigator:

[0153] Core technology: Bayesian Networks (BNs).

[0154] Function: This module is activated when the Statistical Sentinel module detects a "Special Cause Variation" and issues an alert. Its goal is to answer "Why did this anomaly occur?", that is, to move from correlation analysis to causal inference.

[0155] Key Technology: The system pre-constructs a Bayesian network model where nodes represent various metrics (such as defect density, code complexity, and test coverage), and directed edges represent the causal relationships learned based on domain expert knowledge and historical data. When an anomalous signal (e.g., observing an abnormally high "defect density" value) is received as evidence input, the module performs probabilistic inference, calculating the posterior probability of all other potential cause nodes in the network under that evidence. Ultimately, it outputs a list of potential root causes sorted by probability, such as {'excessive code complexity': 0.75, 'insufficient test coverage': 0.15}, providing decision-makers with quantitative, data-supported diagnostic conclusions.

[0156] (3) Submodule 2c: The Reasoning Synthesizer:

[0157] Core technology: Large Language Model (LLM).

[0158] Function: As the final layer of the analytics engine, this module is responsible for transforming the structured, digitized information output by the first two modules (i.e., statistical anomalies and probabilistic root cause lists) into human-readable, contextualized natural language descriptions. It integrates all the information to generate a problem summary, a potential business impact assessment, and preliminary improvement recommendations.

[0159] 3. Agent Orchestration and Execution Module:

[0160] This module is the "central nervous system" of the system, responsible for automatically scheduling and executing the entire "monitoring-diagnosis-recommendation" workflow.

[0161] Key technologies: This module adopts a multi-agent system architecture, where multiple specialized agents, each with its own specific function, collaborate to complete tasks. It mainly includes:

[0162] Monitoring agent: Continuously calls the statistics sentinel module and triggers the diagnostic process upon detecting anomalies.

[0163] The diagnostic agent is the core of the entire workflow, responsible for performing root cause analysis. It doesn't perform direct calculations but acts as an intelligent "commander," using a high-level reasoning framework to determine which tools to invoke (such as...). Figure 3 The toolset shown is used to collect evidence and conduct analysis.

[0164] Recommendation Agent: After diagnosing the root cause, this agent is responsible for querying internal organizational process assets and knowledge bases to generate specific, actionable improvement recommendations.

[0165] Alert / Report Agent: Responsible for pushing the final analysis results (packaged into a structured "process improvement case file") to relevant stakeholders through appropriate channels (such as automatically creating tasks in project management tools).

[0166] (II) Method and Flow:

[0167] Figure 4 This is a processing flowchart of an optional data processing system based on the software development process according to an embodiment of the present invention, such as... Figure 4 As shown, the method disclosed in this embodiment is an automated, iterative process, specifically including the following steps:

[0168] Step S1: Continuous monitoring and anomaly detection:

[0169] The system's monitoring agent periodically or in real-time invokes the statistical sentinel module in the hybrid analytics engine. The statistical sentinel module retrieves time-series data of key performance indicators from the data warehouse of the data integration and modeling module, and analyzes it using an SPC control chart configured to adapt to the data characteristics. If a data point exhibits "special cause variation" (e.g., exceeding control limits or displaying a non-random pattern), it is determined that an anomaly has occurred.

[0170] Step S2: Trigger and activate the diagnostic process:

[0171] Once an anomaly is detected, the monitoring agent will generate an "anomaly event object" containing information such as anomaly indicators, time, and context. Using this as input, the diagnostic agent in the agent orchestration and execution module will be activated, and the root cause analysis (RCA) process will be initiated.

[0172] Step S3: Investigation into the root causes of automation based on the ReAct framework:

[0173] The core steps of this embodiment are executed by a diagnostic agent. This agent operates using the ReAct (Reason+Act) framework. Figure 5 This is a schematic diagram of an optional diagnostic agent based on the ReAct framework according to an embodiment of the present invention, such as... Figure 5 As shown, this framework is an iterative loop process, as detailed below:

[0174] a. Reasoning (Thought): The diagnostic agent (driven by LLM) first generates an internal reasoning text, i.e., a "thinking" process, based on the received anomalous events and built-in domain knowledge (e.g., the DORA indicator anti-pattern knowledge base). This thinking process can form an initial hypothesis and plan the next steps to verify the hypothesis.

[0175] b. Action: Based on the results of "thinking", the agent selects the most suitable tool from its predefined toolset and executes it. This tool may be an internal call (such as calling the causal analysis module run_causal_analysis) or an external query (such as querying the project management system or source code management system via API).

[0176] c. Observation: The agent receives and analyzes the results returned after executing the "action." This result will serve as new evidence and be input into the "thinking" phase of the next cycle.

[0177] This "think-act-observe" cycle can continue until the diagnostic agent has collected enough evidence to determine the root cause of the anomaly with high confidence, or to determine that the cause cannot be found. The advantage of the ReAct framework is that it makes the AI ​​investigation process flexible, intelligent, and completely transparent and auditable because it fully records the reasoning logic of each step.

[0178] Step S4: Generate Improvement Recommendations: The diagnostic agent can pass the finally identified root cause and its supporting evidence to the recommendation agent. The recommendation agent accesses a knowledge base containing the organization's historical solutions, best practices, and CMMI requirements to generate one or more specific, context-sensitive, and actionable improvement recommendations.

[0179] Step S5: Generate and deliver the intelligence report; The alerting / reporting agent integrates and formats the outputs of the entire analysis process—including the problem statement, root cause, chain of evidence, and improvement recommendations—into a structured "process improvement case file." This file is then automatically delivered to the designated project manager or process improvement lead through a pre-defined channel, for example, by creating a new CAR task in the project management system and using this file as its detailed description.

[0180] By combining the above system architecture and methodology, this embodiment constructs an intelligent system capable of autonomously identifying problems, diagnosing root causes, and proposing improvement suggestions, effectively solving various drawbacks of related technologies.

[0181] It should be noted that, to avoid the time-consuming and labor-intensive manual causal analysis process in related technologies, which heavily relies on expert resources and has long response cycles, this embodiment can fully automate the core improvement cycle from MPM to CAR in CMMI through an automated workflow involving multiple intelligent agents. From detecting anomaly signals to generating an executable improvement report, the entire process requires no manual intervention, reducing the analysis task that originally took days or even weeks to the minute level, achieving end-to-end automation, and greatly improving the response speed and processing capability for process issues.

[0182] To avoid the inherently passive nature of dashboards and manual analysis modes in related technologies, which typically involve post-event analysis only after a problem has already caused significant impact (such as a production accident), this embodiment utilizes Statistical Process Control (SPC) as a "sentinel." This allows for real-time monitoring of process stability and immediate warnings when statistically significant early deviations (i.e., "specific cause variation") occur. This statistically-based proactive detection capability enables intervention at the nascent stage of a problem, thereby shifting from a reactive, "firefighting" approach to proactive, "preventative" management.

[0183] To avoid performance dashboards in related technologies only displaying the "correlation" of indicators without revealing the underlying "causality," thus forcing decision-makers to act based on guesswork, this embodiment introduces a Bayesian network-based causal investigation module. This module enables deep probabilistic reasoning after anomaly identification, outputting a ranked list of potential root causes with correlation confidence levels. This allows improvement measures to directly address the crux of the problem, solving the fundamental pain point of "knowing what but not why," and ensuring that decisions are truly based on data and scientific inference.

[0184] To avoid the "black box" nature of many AI systems in related technologies, which makes them difficult to trust and adopt, this embodiment employs the ReAct framework for the diagnostic agent. Its "think-act-observe" cycle is fully recorded, forming a clear, human-readable reasoning chain. Users can clearly see how the system forms hypotheses, collects evidence, and ultimately draws conclusions step by step. This inherent transparency and explainability greatly enhances user trust in the system's analysis results, facilitates human review and supervision, solves the credibility problem of AI in critical decision-making scenarios, and achieves an explainable, traceable, and trustworthy AI decision-making process.

[0185] To avoid the negative effects of "Goodhard's Law"—that is, actions that compromise overall value in pursuit of metric optimization—this embodiment systematically circumvents this risk. First, it analyzes interconnected "constellations of metrics" (such as the DORA metric), rather than isolated metrics. Second, its built-in knowledge base includes the ability to identify "anti-patterns" (such as high deployment frequency accompanied by high change failure rates), proactively alerting users to pseudo-optimization behaviors that sacrifice quality for speed. By shifting the focus of analysis from judging the "good or bad" numbers of individuals or teams to diagnosing the health of the "system," it enables truly valuable, balanced, and systematic process improvements, avoiding the pitfalls of metric misuse and "Goodhard's Law."

[0186] Example 3

[0187] Embodiment 3 of the present invention provides an optional data processing device based on the software development process, wherein each implementation unit in the data processing device corresponds to each implementation step in Embodiment 1.

[0188] Figure 6 This is a schematic diagram of an optional data processing apparatus based on a software development process according to an embodiment of the present invention, such as... Figure 6 As shown, the data processing device includes: an acquisition unit 61, a detection unit 62, a determination unit 63, and a generation unit 64.

[0189] Among them, the acquisition unit 61 is used to acquire multiple performance indicators during the software development process;

[0190] The detection unit 62 is used to perform anomaly detection on multiple performance indicators using anomaly detection strategies and obtain detection results;

[0191] The determination unit 63 is used to determine the root cause and supporting evidence of the abnormal indicators by means of a diagnostic agent when the detection results indicate that there are abnormal indicators among multiple performance indicators. The supporting evidence includes evidence of the accuracy of the root cause.

[0192] Generation unit 64 is used to generate anomaly analysis results for the software development process based on root causes and supporting evidence.

[0193] In the data processing device based on the software development process provided in this embodiment, multiple performance indicators in the software development process can be acquired by the acquisition unit 61, and an anomaly detection strategy can be used by the detection unit 62 to detect anomalies in the multiple performance indicators to obtain detection results. When the detection results indicate the presence of anomalies among the multiple performance indicators, the determination unit 63 uses a diagnostic agent to determine the root cause and supporting evidence for the anomalies. The supporting evidence includes evidence supporting the accuracy of the root cause. Based on the root cause and supporting evidence, the generation unit 64 generates an anomaly analysis result for the software development process. This solves the technical problem in related technologies where manual causal analysis of anomaly performance indicators in the software development process using human experts yields poor results. In this embodiment, by using an intelligent agent to analyze the root cause and supporting evidence of anomalies in the software development process, the inefficiency and low accuracy of causal analysis of anomaly performance indicators in the software development process using human experts in related technologies are avoided. This achieves the technical effect of improving the efficiency and accuracy of causal analysis of anomalies in the software development process.

[0194] Optionally, the determining unit includes: an acquisition subunit for acquiring time information associated with the abnormal indicator and context information of the abnormal indicator; a first processing subunit for performing structured processing on the abnormal indicator, time information, and context information to obtain an abnormal event object; and a first determining subunit for determining the root cause and supporting evidence based on the abnormal event object by calling tools in the target tool set through a diagnostic agent, wherein the tool types in the target tool set include at least one of the following: a causal reasoning tool and a development process retrieval tool, wherein the causal reasoning tool is used to call a causal inference strategy, and the development process retrieval tool is used to retrieve data in the software development process.

[0195] Optionally, the first determining subunit includes: a first processing module, used in the first step, based on the abnormal event object, predicting the cause of the abnormal indicator and the next action of the diagnostic agent through a diagnostic agent, and obtaining a prediction result, wherein the next action of the diagnostic agent includes: selecting a tool to be executed from the target toolset; a second processing module, used in the second step, based on the prediction result, using the diagnostic agent to select a tool to be executed from the target toolset and execute the tool to query evidence supporting the cause predicted in the first step; a third processing module, used in the third step, using the diagnostic agent to parse the output result of the second step; and a fourth processing module, used to feed back the result returned by the third step to the first step, and repeat the first, second, and third steps until the diagnostic agent determines the root cause and supporting evidence.

[0196] Optionally, the first processing module includes: a query submodule, used to query a first knowledge base based on the abnormal event object through a diagnostic agent to obtain query results, wherein the first knowledge base includes: the indicator pattern of the performance indicator, the reason for the generation of the indicator pattern, and the required analysis indicators associated with the indicator pattern, and the indicator pattern includes: indicator status; and a prediction submodule, used to predict the reason for the generation of the abnormal indicator based on the query results.

[0197] Optionally, the acquisition unit includes: an extraction subunit for extracting data generated during the software development process from multiple software engineering tools to obtain a target dataset, wherein the software engineering tools include tools for managing the software development process; a second processing subunit for preprocessing the target dataset to obtain a processed target dataset; and a second determination subunit for determining multiple performance metrics based on the processed target dataset.

[0198] Optionally, the acquisition unit further includes: a third determining subunit, used to determine a data storage strategy after preprocessing the target dataset to obtain the processed target dataset, wherein the data storage strategy includes one of the following: a data warehouse adopting a galaxy pattern or a data lake warehouse integrated architecture; and a storage subunit, used to store the processed target dataset based on the data storage strategy.

[0199] Optionally, the anomaly detection strategy includes a statistical process control strategy, and the detection unit includes: a fourth determination subunit, used to determine the control chart associated with each performance indicator based on a second knowledge base, wherein the second knowledge base includes: the association between the type of performance indicator and the type of control chart used by the statistical process control strategy; and a detection subunit, used to perform anomaly detection on each performance indicator based on the control chart associated with each performance indicator and using the statistical process control strategy to obtain the detection result.

[0200] Optionally, the type of anomaly analysis result includes: an analysis report. The generation unit includes: a first generation subunit, used to generate improvement suggestions based on the root cause and supporting evidence through a suggestion agent, wherein the suggestion agent is used to determine the improvement suggestions through a third knowledge base, wherein the third knowledge base includes: improvement suggestions corresponding to different anomaly causes; and a second generation subunit, used to generate an analysis report based on the analysis process of improvement suggestions and anomaly indicators.

[0201] The aforementioned data processing device based on the software development process may also include a processor and a memory. The aforementioned acquisition unit 61, detection unit 62, determination unit 63 and generation unit 64 are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0202] The aforementioned processor contains a kernel that retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, intelligent agents can be used to analyze the root causes and supporting evidence of anomalous indicators generated during the software development process. This avoids the inefficiency and low accuracy of using human experts to perform causal analysis on anomalous performance indicators in related technologies, thus achieving the technical effect of improving the efficiency and accuracy of causal analysis of anomalous indicators in the software development process.

[0203] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0204] According to another aspect of the present invention, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the data processing method based on the software development process described above by executing the executable instructions.

[0205] According to another aspect of the present invention, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program controls the device where the computer-readable storage medium is located to execute the data processing method based on the software development process described above when the computer program is running.

[0206] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0207] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms. The units described as separate components may or may not be physically separate; the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0209] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0210] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0211] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data processing method based on the software development process, characterized in that, include: Obtain multiple performance metrics during the software development process; An anomaly detection strategy was used to detect anomalies in multiple performance indicators, and the detection results were obtained. If the detection results indicate that there are abnormal indicators among the multiple performance indicators, the diagnostic agent determines the root cause and supporting evidence for the abnormal indicators, wherein the supporting evidence includes evidence supporting the accuracy of the root cause. Based on the aforementioned root causes and supporting evidence, anomaly analysis results for the software development process are generated.

2. The data processing method according to claim 1, characterized in that, By using a diagnostic agent, the root cause and supporting evidence for the aforementioned abnormal indicators are determined, including: Obtain the time information associated with the abnormal indicator and the context information of the abnormal indicator; The abnormal indicators, the time information, and the context information are structured to obtain an abnormal event object; Based on the abnormal event object, the diagnostic agent invokes tools from the target toolset to determine the root cause and supporting evidence. The tools in the target toolset include at least one of the following types: causal reasoning tools and R&D process retrieval tools. The causal reasoning tools are used to invoke causal inference strategies, and the R&D process retrieval tools are used to retrieve data from the software R&D process.

3. The data processing method according to claim 2, characterized in that, Based on the anomalous event object, the diagnostic agent invokes tools from the target toolset to determine the root cause and supporting evidence, including: The first step is to predict the cause of the abnormal indicators and the next action of the diagnostic agent based on the abnormal event object, and obtain the prediction result. The next action of the diagnostic agent includes: selecting the tool to be executed from the target toolset. The second step involves, based on the prediction results, selecting the tool to be executed from the target toolset through the diagnostic agent, and executing the tool to query evidence supporting the cause predicted in the first step. The third step involves analyzing the output of the second step using the diagnostic agent. The result returned by the third step is fed back to the first step, and the first step, the second step, and the third step are repeated until the diagnostic agent determines the root cause and the supporting evidence.

4. The data processing method according to claim 3, characterized in that, Based on the abnormal event object, the diagnostic agent predicts the cause of the abnormal indicator, including: Based on the abnormal event object, the diagnostic agent queries the first knowledge base to obtain the query results. The first knowledge base includes: the indicator pattern of the performance indicator, the reason for the generation of the indicator pattern, and the required analysis indicators associated with the indicator pattern. The indicator pattern includes: indicator status. The cause of the abnormal indicator is predicted based on the query results.

5. The data processing method according to claim 1, characterized in that, Obtaining multiple performance metrics during the software development process also includes: Data generated during the software development process is extracted from multiple software engineering tools to obtain a target dataset, wherein the software engineering tools include tools for managing the software development process; The target dataset is preprocessed to obtain the processed target dataset; Based on the processed target dataset, several performance metrics are determined.

6. The data processing method according to claim 5, characterized in that, After preprocessing the target dataset to obtain the processed target dataset, the process further includes: Determine a data storage strategy, wherein the data storage strategy includes one of the following: a data warehouse using a galaxy model or an integrated data lake warehouse architecture; Based on the data storage strategy, the processed target dataset is stored.

7. The data processing method according to claim 1, characterized in that, The anomaly detection strategy includes: a statistical process control strategy, which uses the anomaly detection strategy to detect anomalies in multiple performance indicators and obtain detection results, including: Based on the second knowledge base, a control chart associated with each performance indicator is determined, wherein the second knowledge base includes: the association between the type of the performance indicator and the type of control chart used by the statistical process control strategy; Based on the control chart associated with each performance indicator, the statistical process control strategy is used to perform anomaly detection on each performance indicator to obtain the detection result.

8. The data processing method according to claim 1, characterized in that, The types of anomaly analysis results include: analysis reports, which generate anomaly analysis results for the software development process based on the root causes and supporting evidence, including: Based on the root cause and the supporting evidence, an improvement suggestion is generated by a suggestion agent, wherein the suggestion agent is used to determine the improvement suggestion through a third knowledge base, wherein the third knowledge base includes: improvement suggestions corresponding to different anomaly causes; The analysis report is generated based on the improvement suggestions and the analysis process of the abnormal indicators.

9. A data processing device based on the software development process, characterized in that, include: The acquisition unit is used to acquire multiple performance metrics during the software development process. The detection unit is used to perform anomaly detection on multiple performance indicators using an anomaly detection strategy and obtain detection results. The determining unit is configured to, when the detection result indicates that there is an abnormal indicator among the multiple performance indicators, determine the root cause and supporting evidence for the abnormal indicator through a diagnostic agent, wherein the supporting evidence includes evidence supporting the accuracy of the root cause. The generation unit is used to generate anomaly analysis results of the software development process based on the root cause and the supporting evidence.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the data processing method based on the software development process as described in any one of claims 1 to 8.

Images