Workload assessment method and device

Abstract

The invention discloses a workload assessment method and device. The method comprises the steps of obtaining code submission data and work daily report data; analyzing the code submission data to obtain a first key index; analyzing the daily work report data to obtain a second key index; inputting the first key index and the second key index into an evaluation model to obtain an evaluation result; screening a business rule corresponding to the code submission data and the work daily report data from a business rule base, and identifying the business rule as a target business rule; and evaluating the evaluation result according to the target business rule to obtain a final evaluation result. According to the method and the device, the code submission data and the work daily report data are comprehensively evaluated only through the business rule and the evaluation model, so that an accurate evaluation result can be obtained, and a manual review process is avoided. Therefore, the workload can be accurately evaluated, and the labor cost can be effectively reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a workload evaluation method and device. Background Art

[0002] In the software development process of large enterprises, the progress and quality management of software projects are crucial. To ensure that projects can be delivered on time, developer workload estimation is one of the core tasks in project management.

[0003] Currently, many large enterprises rely on traditional methods to assess developer workload, such as line-of-code counting and manual code review. While simple and easy to implement, the first method, which measures workload by counting the number of lines of code written, often overlooks the quality, complexity, and completeness of the code's functionality, and therefore fails to fully reflect the developer's actual workload. The second method, which relies on manual code review, can improve assessment accuracy to a certain extent, but it requires significant labor costs.

[0004] Therefore, how to accurately assess workload while reducing labor costs has become an urgent problem that needs to be solved in this field. Summary of the Invention

[0005] The present application provides a workload assessment method and apparatus, the purpose of which is to accurately assess workload while reducing labor costs.

[0006] In order to achieve the above objectives, this application provides the following technical solutions:

[0007] A workload assessment method, comprising:

[0008] Obtain code submission data and daily work data;

[0009] Analyze the code submission data to obtain first key indicators; the first key indicators include at least submission frequency, code change amount, code complexity and code quality;

[0010] Analyze the daily work data to obtain a second key indicator; the second key indicator includes at least a task number, a task type identification, and a task completion status;

[0011] Inputting the first key indicator and the second key indicator into an evaluation model to obtain an evaluation result; the evaluation result indicates whether the workload meets the standard;

[0012] Filtering business rules corresponding to the code submission data and the work daily data from a business rule library and marking them as target business rules;

[0013] The evaluation results are evaluated according to the target business rules to obtain a final evaluation result.

[0014] Optionally, before collecting code submission data and daily workday data, the process further includes:

[0015] Collect original code submission data and original work daily data;

[0016] Extracting the original code submission data using a code library to obtain key information;

[0017] Performing data preprocessing on the key information to obtain code submission data;

[0018] Cleaning the original daily work data to obtain daily work data;

[0019] The code submission data and the work daily data are stored in a log data table.

[0020] Optionally, analyzing the daily workday data to obtain a second key indicator includes:

[0021] Obtain prompt information; the prompt information includes task number identification information, task type identification information and task completion status identification information;

[0022] Inputting the prompt information and the daily work data into an analysis model to obtain an analysis result;

[0023] A second key indicator is extracted from the analysis result.

[0024] Optionally, the training process of the evaluation model includes:

[0025] Obtain sample data; the sample data includes sample code submission data and sample work daily data;

[0026] Analyzing the sample data to obtain key sample indicators;

[0027] Performing data preprocessing on the sample key indicators to obtain preprocessed sample key indicators;

[0028] Inputting the preprocessed sample key indicators into the evaluation model to obtain sample evaluation results;

[0029] Calculating a loss function between a true evaluation result corresponding to the sample data and the sample evaluation result;

[0030] When the loss function does not converge, adjusting the model parameters of the evaluation model, and returning to the step of inputting the preprocessed sample key indicators into the evaluation model to obtain the sample evaluation results;

[0031] When the loss function converges, it is determined that the evaluation model training is completed.

[0032] Optionally, performing data preprocessing on the sample key indicators to obtain preprocessed sample key indicators includes:

[0033] Standardizing the numerical indicators in the sample key indicators to obtain standardized sample key indicators;

[0034] Encoding the categorical indicators in the standardized sample key indicators to obtain encoded sample key indicators;

[0035] Filling missing values ​​in the encoded sample key indicators to obtain preprocessed sample key indicators.

[0036] A workload assessment device, comprising:

[0037] Acquisition unit, used to obtain code submission data and daily work data;

[0038] A first analysis unit is configured to analyze the code submission data to obtain a first key indicator; the first key indicator includes at least submission frequency, code change amount, code complexity, and code quality;

[0039] A second analysis unit is configured to analyze the daily work data to obtain a second key indicator; the second key indicator includes at least a task number, a task type identification, and a task completion status;

[0040] A first evaluation unit is configured to input the first key indicator and the second key indicator into an evaluation model to obtain an evaluation result; the evaluation result indicates whether the workload meets the standard;

[0041] A screening unit, configured to screen out business rules corresponding to the code submission data and the daily work report data from a business rule library, and mark them as target business rules;

[0042] The second evaluation unit is configured to evaluate the evaluation result according to the target business rule to obtain a final evaluation result.

[0043] Optionally, also include:

[0044] Collection unit, used to collect original code submission data and original work daily data;

[0045] An extraction unit, configured to extract the original code submission data using a code library to obtain key information;

[0046] A preprocessing unit, configured to perform data preprocessing on the key information to obtain code submission data;

[0047] a cleaning unit, configured to clean the original daily work data to obtain daily work data;

[0048] The storage unit is used to store the code submission data and the work daily data in a log data table.

[0049] Optionally, the second analysis unit is specifically configured to:

[0050] Obtain prompt information; the prompt information includes task number identification information, task type identification information and task completion status identification information;

[0051] Inputting the prompt information and the daily work data into an analysis model to obtain an analysis result;

[0052] A second key indicator is extracted from the analysis result.

[0053] Optionally, also include:

[0054] A data acquisition unit, configured to acquire sample data; the sample data includes sample code submission data and sample work daily data;

[0055] A third analysis unit is used to analyze the sample data to obtain key indicators of the sample;

[0056] A data preprocessing unit, configured to perform data preprocessing on the sample key indicators to obtain preprocessed sample key indicators;

[0057] A third evaluation unit is used to input the preprocessed sample key indicators into the evaluation model to obtain a sample evaluation result;

[0058] A calculation unit, configured to calculate a loss function between a true evaluation result corresponding to the sample data and the sample evaluation result;

[0059] a return unit, configured to adjust the model parameters of the evaluation model when the loss function fails to converge, and return to the step of inputting the preprocessed sample key indicators into the evaluation model to obtain a sample evaluation result;

[0060] A determination unit is used to determine that the evaluation model training is completed when the loss function converges.

[0061] Optionally, the data preprocessing unit is specifically used to:

[0062] Standardizing the numerical indicators in the sample key indicators to obtain standardized sample key indicators;

[0063] Encoding the categorical indicators in the standardized sample key indicators to obtain encoded sample key indicators;

[0064] Filling missing values ​​in the encoded sample key indicators to obtain preprocessed sample key indicators.

[0065] The technical solution provided by this application obtains code submission data and daily work data; analyzes the code submission data to obtain a first key indicator; analyzes the daily work data to obtain a second key indicator; inputs the first key indicator and the second key indicator into the evaluation model to obtain an evaluation result; filters out business rules corresponding to the code submission data and daily work data from the business rule library and identifies them as target business rules; evaluates the evaluation results according to the target business rules to obtain a final evaluation result. In this application, it is only necessary to comprehensively evaluate the code submission data and daily work data through business rules and evaluation models to obtain accurate evaluation results, eliminating the process of manual review. This not only accurately evaluates the workload, but also effectively reduces labor costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0067] Figure 1 A flowchart of a workload evaluation method provided in an embodiment of the present application;

[0068] Figure 2 A flowchart of a data storage method provided in an embodiment of the present application;

[0069] Figure 3 A data collection flow chart provided in an embodiment of the present application;

[0070] Figure 4 A schematic diagram of a workload assessment system provided in an embodiment of the present application;

[0071] Figure 5 A schematic diagram of the architecture of a workload assessment device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0072] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0073] In this application, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0074] like Figure 1 FIG. 1 is a flowchart of a workload evaluation method provided in an embodiment of the present application, comprising the following steps:

[0075] S101: Obtain code submission data and daily work data.

[0076] Among them, code submission data and daily work data can be obtained from the log data table.

[0077] Optionally, before step S101, it is necessary to collect initial data in advance and process it, and then store the processed data in the log data table so that it can be queried quickly and accurately from the log data table later. Therefore, another embodiment of the present application provides a data storage method, such as Figure 2 As shown, the following steps are included:

[0078] S201: Collect original code submission data and original work daily data.

[0079] The original code submission data refers to the code data submitted by the developer, and the original work daily report data refers to the work daily report text.

[0080] It should be noted that you can use batch programs to complete daily data collection work (that is, collect original code submission data and original workday data) on a scheduled basis, or you can directly configure Git Hook or scheduled tasks in the target code repository (such as Git, SVN) to complete data collection work through Git Hook or scheduled tasks.

[0081] Specifically, the original daily work report data is connected to the existing daily report management system. Through the interface of the daily report management system, the daily work report data submitted by developers is automatically obtained on a regular basis. The daily report list (i.e., the original daily work report data) can also be obtained on a regular basis through the REST (Representational State Transfer) API.

[0082] S202: Extract the original code submission data using the code library to obtain key information.

[0083] Among them, key information includes but is not limited to hash, author, timestamp, and diff content.

[0084] It can be understood that after extracting key information from the original code submission data, the key information is stored in an intermediate message queue (such as Kafka), and the intermediate message queue sends the key information to the back-end data processing program, thereby completing data processing (that is, data preprocessing and data cleaning).

[0085] S203: Preprocess the key information to obtain code submission data.

[0086] Among them, data preprocessing is performed on the key information. Specifically, some unimportant or invalid submission records and submissions generated when merging multiple branches in the key information are eliminated, and the processed data is processed into standardized fields to obtain code submission data.

[0087] Specifically, the code submission data may be stored in an original data table.

[0088] S204: Clean the original daily work data to obtain daily work data.

[0089] Among them, the original daily work data is cleaned, that is, HTML tags, escape characters and other operations are removed, and then the original daily work data after removal is extracted using a large-scale model to obtain the corresponding indicators (i.e. daily work data).

[0090] S205: Store the code submission data and daily work data into the log data table.

[0091] In order to better Figure 2 For an explanation of the contents shown, see Figure 3 , a data collection flow chart is shown. When the collection operation is triggered, the original code submission data is obtained from the target code repository, the original code submission data is preprocessed or cleaned to obtain the code submission data, and the code submission data is stored in the original data table (i.e. Figure 3The original workday data is pulled from the daily report list using the REST API. This data is cleansed to obtain the workday data. The code submission data and workday data are stored in the log data table. The log data table and the original data table constitute the original data lake, from which data is subsequently retrieved for indicator calculation and evaluation.

[0092] S102: Analyze the code submission data to obtain a first key indicator.

[0093] Among them, the first key indicator includes at least submission frequency, code change amount, code complexity and code quality.

[0094] Submission frequency refers to the number of submissions per day, reflecting work activity. Calculate the average time between submissions to identify work rhythm.

[0095] The code change volume refers to the number of lines of code added, modified, or deleted in each commit. Analyze the scale of the code changes to assess the workload.

[0096] Code complexity refers to the cyclomatic complexity of each submission. Tools can be used to calculate the cyclomatic complexity of each submission, evaluate the complexity of the code, and indirectly reflect the difficulty of development.

[0097] Code quality refers to the compliance, omissions, and other results of the code. Code quality tools can be used to obtain the compliance, omissions, and other results of the code as code quality indicators.

[0098] S103: Analyze the daily workday data to obtain the second key indicator.

[0099] Among them, the second key indicator includes at least task number, task type identification and task completion status.

[0100] Task number refers to the task number described in the daily report, which measures the workload.

[0101] Task type identification refers to the task type (such as coding, testing, document writing), to understand the diversity of work content.

[0102] Task completion status describes the status of task completion and determines task progress. It also identifies unfinished or deferred tasks and assesses work efficiency.

[0103] Optionally, in another embodiment of the present application, the specific implementation of step S103 includes process A1 to process A3.

[0104] A1: Get prompt information.

[0105] The prompt information includes task number identification information, task type identification information and task completion status identification information.

[0106] The task number identification information is: Please read the following daily report content, count the number of tasks mentioned therein, and number the tasks.

[0107] To identify the task type, please read the following daily report and, based on the task number, identify the type of each task (such as code writing, functional testing, document writing, requirements pre-research, etc.).

[0108] To identify the task completion status, please read the following daily report and, based on the task number, determine the completion status of each task (not started, in progress, or completed).

[0109] A2: Input the prompt information and daily work data into the analysis model to obtain the analysis results.

[0110] The analysis results include at least the task number, task type identification and task completion status.

[0111] Optionally, the analysis model includes but is not limited to the Qwen model.

[0112] It is understandable that the prompt information and daily work data are input into the analysis model so that the analysis model performs text analysis to obtain analysis results.

[0113] A3: Extract the second key indicator from the analysis results.

[0114] Specifically, the second key indicator may be converted into a structured format (eg, JSON format) and stored in a database system.

[0115] In addition, to ensure the comparability between different indicators (including the first key indicator and the second key indicator), it is necessary to standardize each indicator. Specifically, the Z-score standardization or Min-Max normalization method is used to convert each indicator to a unified scale.

[0116] S104: Input the first key indicator and the second key indicator into the evaluation model to obtain an evaluation result.

[0117] Among them, the evaluation result indicates whether the workload meets the standards. If the workload meets the standards, it means that the code submission data and the daily work data are approved and qualified. If the workload does not meet the standards, it means that the code submission data and the daily work data are unqualified.

[0118] Optionally, evaluation models include but are not limited to random forests.

[0119] Optionally, in another embodiment of the present application, the specific implementation of step S104 includes processes B1 to B7.

[0120] B1: Obtain sample data.

[0121] The sample data includes sample code submission data and sample daily work data.

[0122] Optionally, the sample data may be historical code submission data and historical workday data.

[0123] B2: Analyze the sample data to obtain key indicators of the sample.

[0124] Among them, the sample key indicators include submission frequency, code change amount, code complexity, number of tasks, task type identification, task completion status and task number.

[0125] B3: Perform data preprocessing on the sample key indicators to obtain preprocessed sample key indicators.

[0126] Among them, data preprocessing of key sample indicators can improve data quality, remove noise and redundant information, and ensure data accuracy and consistency.

[0127] Optionally, in another embodiment of the present application, the specific implementation of process B3 includes processes C1 to C3.

[0128] C1: Standardize the numerical indicators in the sample key indicators to obtain the standardized sample key indicators.

[0129] It can be understood that standardizing the numerical indicators in the sample key indicators, that is, standardizing the numerical features so that they have the same scale, thereby obtaining the standardized sample key indicators.

[0130] C2: Encode the categorical indicators in the standardized sample key indicators to obtain the encoded sample key indicators.

[0131] It can be understood that encoding is performed on the categorical indicators in the standardized sample key indicators, that is, converting the categorical features into numerical representations. Common encoding methods include one-hot encoding and label encoding. One-hot encoding converts categorical features into binary vectors, while label encoding converts categorical features into integer values. Through these encoding processes, the encoded sample key features are obtained.

[0132] C3: Fill missing values ​​in the encoded sample key indicators to obtain the preprocessed sample key indicators.

[0133] Among them, the missing values ​​of the encoded sample key indicators are filled with the mean, or the missing values ​​of the sample key indicators are deleted to ensure the integrity of the data.

[0134] Furthermore, in the development workload assessment scenario, the majority of sample data indicates qualified workload approval, with only a very small number indicating unqualified workload approval. Due to the severe data imbalance (the majority of qualified samples are qualified, while the minority are unqualified), directly training the model using the default random forest algorithm will tend to favor qualified samples, resulting in high precision but very low recall for unqualified samples, thus compromising the model's effectiveness.

[0135] To avoid this, the paper mentions the use of the SMOTE algorithm (Synthetic Minority Over-sampling Technique) to generate new "unqualified" samples in the feature space, thereby making the training data more balanced. This data oversampling method helps the model better learn the characteristics of the minority class ("unqualified" samples), avoid bias towards the majority class during training, and improve the model's recall rate for the minority class, thereby improving the overall model performance.

[0136] B4: Input the preprocessed sample key indicators into the evaluation model to obtain the sample evaluation results.

[0137] Among them, the sample evaluation results include whether the workload corresponding to the sample data meets the standards.

[0138] It's important to note that in development effort assessment tasks, there are complex, nonlinear relationships between the features involved. For example, the relationship between code complexity and code size is such that when code complexity is low, more code may be required to achieve the same evaluation criteria. Furthermore, the input data may contain outliers and noise.

[0139] Since this task does not require very high prediction accuracy, we chose to use Random Forest for classification. Random Forest is an ensemble learning method that improves model accuracy and robustness by constructing multiple decision trees and performing voting or averaging. This algorithm can handle high-dimensional data, effectively analyze the impact of multiple features, and provide an assessment of the importance of each feature to the decision, which helps understand how the model makes decisions. Random Forest is also highly resistant to interference and outliers and noise, making it a good choice for complex real-world problems.

[0140] B5: Calculate the loss function between the true evaluation result corresponding to the sample data and the sample evaluation result.

[0141] Optionally, the mean square error between the true evaluation result corresponding to the sample data and the sample evaluation result can be used as the loss function.

[0142] B6: When the loss function does not converge, adjust the model parameters of the evaluation model and return to the execution process B4.

[0143] It should be noted that if the loss function does not converge, it means that the loss function does not decrease with the increase of training steps. At this time, the model parameters in the evaluation model are adjusted and the execution process B4 is returned until the loss function converges.

[0144] B7: When the loss function converges, the evaluation model training is determined to be complete.

[0145] It can be understood that if the loss function converges, that is, the loss function gradually decreases with the increase of training steps, and eventually tends to be stable or no longer changes significantly, it means that the evaluation model training is completed at this time.

[0146] It's important to note that in stratified cross-validation, the sample dataset is divided into multiple subsets. Each time the model is trained, a portion of the data is used as the validation set, and the remaining data is used as the training set. This ensures that the class distribution in each subset is similar to that of the original dataset, reducing bias caused by uneven data partitioning. This approach can effectively improve model accuracy and generalization.

[0147] In addition, after the model training is completed, it is necessary to use the accuracy, precision, recall rate and F1 score indicators to comprehensively evaluate the classification performance of the model. If the classification performance does not meet the requirements, it is necessary to continue training until the classification performance reaches the standard.

[0148] It's important to emphasize that deploying a trained model to a production environment, combined with a rules engine, enables real-time assessment and early warning of developer workload. The model's output can be used to assist project managers with task allocation and resource scheduling, identify overloaded or underloaded personnel, and make appropriate adjustments, thus providing a quantitative basis for performance evaluation.

[0149] S105: Filter out business rules corresponding to the code submission data and the daily work data from the business rule library, and mark them as target business rules.

[0150] Among them, business rules include: code submission rules (such as the frequency of code submission), daily work report rules (such as the work content that must be submitted every day, task progress, working time records, etc.), performance evaluation rules (such as evaluating developers' work performance based on the number and quality of submitted code, completed tasks, etc.), and resource scheduling rules (assigning tasks or adjusting resources based on developers' workload, skill level, etc.).

[0151] S106: Evaluate the evaluation results according to the target business rules to obtain a final evaluation result.

[0152] The final assessment results include operational recommendations, such as generating warnings and adjusting assessment levels.

[0153] For example, in development team management, the project manager wants to ensure the defect rate is below 3% and requires daily work reports to be submitted before 10:00 PM. At the same time, a quality alert mechanism is configured: if the number of defects fixed that day falls below the expected number (assuming 5), an alert is triggered. These requirements can be converted into quantifiable metrics and thresholds (i.e., business rules), defined as conditions in the rule engine, and then configured in the Drools rule engine framework.

[0154] In addition, to better illustrate the above content, see Figure 4 A workload assessment system is shown, comprising a data acquisition module, an indicator calculation module, a machine learning assessment module, and a rule engine module. The data acquisition module collects and preprocesses raw code submission data and raw daily workday data, storing them in a log data table. The indicator calculation module extracts a first key indicator from the code submission data and a second key indicator from the daily workday data. The machine learning assessment module inputs the first and second key indicators into an assessment model to generate an assessment result. The rule engine module evaluates the assessment result according to business rules to obtain the final assessment result.

[0155] Furthermore, the rules engine's responsibilities within the entire system include business rule management, decision execution, and flexible configuration. Specifically, business rule management centrally manages business logic, including evaluation criteria, anomaly detection rules, and alert conditions. Decision execution processes evaluation results based on the rules and generates corresponding action recommendations or alerts. Flexible configuration allows business personnel to dynamically adjust and configure rules through a graphical interface or configuration files. Rule expressions are defined in a structured format (such as JSON) and include conditional objects (trigger conditions, such as fields, operators, and values), execution objects (post-trigger actions, such as generating alerts or adjusting evaluation results), and priorities (ensuring that high-priority rules are executed first).

[0156] In summary, simply by comprehensively evaluating code submission data and daily workday data using business rules and evaluation models, accurate evaluation results can be obtained, eliminating the need for manual review. This not only allows for accurate workload assessment but also effectively reduces labor costs.

[0157] like Figure 5 As shown, it is a schematic diagram of the architecture of a workload evaluation device provided in an embodiment of the present application, and the evaluation device includes: an acquisition unit 100, a first analysis unit 200, a second analysis unit 300, a first evaluation unit 400, a screening unit 500 and a second evaluation unit 600.

[0158] The acquisition unit 100 is used to acquire code submission data and daily work data.

[0159] The first analysis unit 200 is used to analyze the code submission data to obtain the first key indicators; the first key indicators at least include submission frequency, code change amount, code complexity and code quality.

[0160] The second analysis unit 300 is used to analyze the daily work data to obtain the second key indicators; the second key indicators at least include task number, task type identification and task completion status.

[0161] The second analysis unit 300 is specifically used to: obtain prompt information; the prompt information includes task number identification information, task type identification information and task completion status identification information; input the prompt information and work daily data into the analysis model to obtain analysis results; extract the second key indicator from the analysis results.

[0162] The first evaluation unit 400 is used to input the first key indicator and the second key indicator into the evaluation model to obtain an evaluation result; the evaluation result indicates whether the workload meets the requirements.

[0163] The screening unit 500 is used to screen out business rules corresponding to the code submission data and the work daily data from the business rule library and mark them as target business rules.

[0164] The second evaluation unit 600 is configured to evaluate the evaluation result according to the target business rule to obtain a final evaluation result.

[0165] In summary, simply by comprehensively evaluating code submission data and daily workday data using business rules and evaluation models, accurate evaluation results can be obtained, eliminating the need for manual review. This not only allows for accurate workload assessment but also effectively reduces labor costs.

[0166] Combine Figure 5 The evaluation device further comprises:

[0167] The collection unit is used to collect original code submission data and original work daily data.

[0168] The extraction unit is used to extract the original code submission data using the code library to obtain key information.

[0169] The preprocessing unit is used to preprocess the key information to obtain code submission data.

[0170] The cleaning unit is used to clean the original daily work data to obtain the daily work data.

[0171] The storage unit is used to store code submission data and daily work data in the log data table.

[0172] Combine Figure 5 The evaluation device further comprises:

[0173] The data acquisition unit is used to acquire sample data; the sample data includes sample code submission data and sample daily work data.

[0174] The third analysis unit is used to analyze the sample data to obtain key indicators of the sample.

[0175] The data preprocessing unit is used to perform data preprocessing on the sample key indicators to obtain the preprocessed sample key indicators.

[0176] The data preprocessing unit is specifically used to: standardize the numerical indicators in the sample key indicators to obtain the standardized sample key indicators; encode the categorical indicators in the standardized sample key indicators to obtain the encoded sample key indicators; fill the missing values ​​of the encoded sample key indicators to obtain the preprocessed sample key indicators.

[0177] The third evaluation unit is used to input the preprocessed sample key indicators into the evaluation model to obtain the sample evaluation results.

[0178] The calculation unit is used to calculate the loss function between the true evaluation result corresponding to the sample data and the sample evaluation result.

[0179] The return unit is used to adjust the model parameters of the evaluation model when the loss function has not converged, and return to the step of inputting the preprocessed sample key indicators into the evaluation model to obtain the sample evaluation results.

[0180] The determination unit is used to determine that the evaluation model training is completed when the loss function converges.

[0181] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The system and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Ordinary technicians in this field can understand and implement it without expending creative work.

[0182] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0183] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A workload evaluation method, characterized in that: include: Obtain code submission data and daily work data; Analyzing the code submission data to obtain a first key indicator; The first key indicator includes at least submission frequency, code change volume, code complexity and code quality; Analyze the daily work data to obtain a second key indicator; the second key indicator includes at least a task number, a task type identification, and a task completion status; Inputting the first key indicator and the second key indicator into an evaluation model to obtain an evaluation result; the evaluation result indicates whether the workload meets the standard; Filtering business rules corresponding to the code submission data and the work daily data from a business rule library and marking them as target business rules; The evaluation results are evaluated according to the target business rules to obtain a final evaluation result.

2. The method according to claim 1, characterized in that Before the code is collected to submit data and daily work data, it also includes: Collect original code submission data and original work daily data; Extracting the original code submission data using a code library to obtain key information; Performing data preprocessing on the key information to obtain code submission data; Cleaning the original daily work data to obtain daily work data; The code submission data and the work daily data are stored in a log data table.

3. The method according to claim 1, characterized in that The second key indicator obtained by analyzing the daily workday data includes: Obtain prompt information; the prompt information includes task number identification information, task type identification information and task completion status identification information; Inputting the prompt information and the daily work data into an analysis model to obtain an analysis result; A second key indicator is extracted from the analysis result.

4. The method according to claim 1, wherein The training process of the evaluation model includes: Obtain sample data; the sample data includes sample code submission data and sample work daily data; Analyzing the sample data to obtain key sample indicators; Performing data preprocessing on the sample key indicators to obtain preprocessed sample key indicators; Inputting the preprocessed sample key indicators into the evaluation model to obtain sample evaluation results; Calculating a loss function between a true evaluation result corresponding to the sample data and the sample evaluation result; When the loss function does not converge, adjusting the model parameters of the evaluation model, and returning to the step of inputting the preprocessed sample key indicators into the evaluation model to obtain the sample evaluation results; When the loss function converges, it is determined that the evaluation model training is completed.

5. The method according to claim 4, characterized in that The data preprocessing of the sample key indicators to obtain preprocessed sample key indicators includes: Standardizing the numerical indicators in the sample key indicators to obtain standardized sample key indicators; Encoding the categorical indicators in the standardized sample key indicators to obtain encoded sample key indicators; Filling missing values ​​in the encoded sample key indicators to obtain preprocessed sample key indicators.

6. A workload assessment device, characterized in that: include: Acquisition unit, used to obtain code submission data and daily work data; A first analyzing unit, configured to analyze the code submission data to obtain a first key indicator; The first key indicator includes at least submission frequency, code change volume, code complexity and code quality; A second analysis unit is configured to analyze the daily work data to obtain a second key indicator; the second key indicator includes at least a task number, a task type identification, and a task completion status; A first evaluation unit is configured to input the first key indicator and the second key indicator into an evaluation model to obtain an evaluation result; the evaluation result indicates whether the workload meets the standard; A screening unit, configured to screen out business rules corresponding to the code submission data and the daily work report data from a business rule library, and mark them as target business rules; The second evaluation unit is configured to evaluate the evaluation result according to the target business rule to obtain a final evaluation result.

7. The device according to claim 6, characterized in that Also includes: Collection unit, used to collect original code submission data and original work daily data; An extraction unit, configured to extract the original code submission data using a code library to obtain key information; A preprocessing unit, configured to perform data preprocessing on the key information to obtain code submission data; a cleaning unit, configured to clean the original daily work data to obtain daily work data; The storage unit is used to store the code submission data and the work daily data in a log data table.

8. The device according to claim 6, characterized in that The second analysis unit is specifically configured to: Obtain prompt information; the prompt information includes task number identification information, task type identification information and task completion status identification information; Inputting the prompt information and the daily work data into an analysis model to obtain an analysis result; A second key indicator is extracted from the analysis result.

9. The device according to claim 6, characterized in that Also includes: A data acquisition unit, configured to acquire sample data; the sample data includes sample code submission data and sample work daily data; A third analysis unit is used to analyze the sample data to obtain key indicators of the sample; A data preprocessing unit, configured to perform data preprocessing on the sample key indicators to obtain preprocessed sample key indicators; A third evaluation unit is used to input the preprocessed sample key indicators into the evaluation model to obtain a sample evaluation result; A calculation unit, configured to calculate a loss function between a true evaluation result corresponding to the sample data and the sample evaluation result; a return unit, configured to adjust the model parameters of the evaluation model when the loss function fails to converge, and return to the step of inputting the preprocessed sample key indicators into the evaluation model to obtain a sample evaluation result; A determination unit is used to determine that the evaluation model training is completed when the loss function converges.

10. The device according to claim 9, characterized in that The data preprocessing unit is specifically used for: Standardizing the numerical indicators in the sample key indicators to obtain standardized sample key indicators; Encoding the categorical indicators in the standardized sample key indicators to obtain encoded sample key indicators; Filling missing values ​​in the encoded sample key indicators to obtain preprocessed sample key indicators.

Images