A multi-dimensional research and development work hour input statistics and traceability management method

Abstract

The application provides a multi-dimensional research and development work hour investment statistics and traceability management method, comprising: comparing initial fluctuation characteristic data with a preset threshold range, analyzing a current reporting density interval, and marking a reporting scene type; comparing a difference narrowing quantitative result with a preset narrowing benchmark, evaluating a current narrowing state as excessive narrowing or insufficient narrowing, triggering an effective change node screening standard update, and obtaining an optimized node retention condition; selecting a specific condition suitable for the current reporting interval duration from the optimized node retention condition, filtering the condition for a traceability node list, evaluating whether each node has a substantial change in work hour data, and obtaining an effective node subset.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a method for multi-dimensional statistical and traceability management of R&D man-hour input. Background Technology

[0002] In enterprise R&D project management, multi-dimensional work hour input statistics and traceability are crucial tasks. They directly impact the accuracy and reliability of project schedule control, cost accounting, and resource optimization. This management capability is significant for improving R&D efficiency and decision-making quality. Currently, many work hour management systems rely on fixed-interval reporting to collect data and employ a unified storage strategy for traceability. However, in real-world R&D environments, work hour data often needs to be automatically and synchronously collected from multiple data sources, such as code repositories, task management platforms, and attendance systems. Due to differences in the update cycles and synchronization responses of each data source, the actual reporting intervals are not fixed and controllable but dynamically change with the synchronization status of the data sources. Specifically, when a project is in a stable maintenance phase or during off-peak hours, code repository commits are sparse, task statuses are fewer, and the synchronization trigger frequency of various data sources decreases, naturally lengthening the reporting interval. Conversely, when a project enters a sprint phase or is on the eve of a version release, code commits are intensive, task flow accelerates, and multiple data sources trigger synchronization frequently, shortening the reporting interval accordingly. Furthermore, as a project transitions from the requirements analysis phase to the concentrated development phase, or from the development peak to the testing and acceptance phase, the reporting interval will correspondingly change from long to short or from short to long. In practical applications, this approach easily overlooks the dynamic relationship between reporting frequency and actual changes in working hours, leading to unreasonable allocation of storage resources. When the reporting interval is long, developers often summarize working hour changes over a long period at once, resulting in significant differences between adjacent records. This necessitates generating numerous trace nodes to completely preserve the historical change trajectory. Conversely, when the reporting interval is short, although the number of records increases, the working hour changes between adjacent periods are usually small, and many records have negligible differences, yet they are still stored completely according to the same rules, further increasing the storage burden. This phenomenon makes it difficult for the system to maintain consistent storage efficiency under different reporting frequencies. The core challenge lies in the failure to effectively utilize the combined relationship between the magnitude of changes in adjacent reporting hours and the reporting time interval. This relationship directly impacts the frequency of traceability node generation. Records with large changes require more nodes to retain critical changes, while records with small changes only need a few nodes to meet traceability needs. Ignoring this correlation makes it impossible to accurately determine which changes are truly worth storing as valid nodes. For example, in a development cycle, if the team adopts high-frequency daily reporting, most adjacent records only reflect minor progress adjustments with minimal differences, yet the system still generates complete nodes for each report, quickly accumulating a large number of nearly identical records. Conversely, if weekly low-frequency reporting is adopted, a single report often covers significant changes accumulated over multiple days, resulting in substantial differences. This again leads to the generation of more nodes each time to capture these cross-time period jumps, similarly consuming significant storage space.Therefore, how to dynamically identify and store only those traceability nodes that reflect valid changes based on the comprehensive relationship between the magnitude of changes in adjacent reported working hours and the time interval, so as to control the storage scale while achieving refined management in the time dimension, has become a key issue in the current multi-dimensional R&D working hour statistics and traceability management. Summary of the Invention

[0003] This invention provides a multi-dimensional method for statistical and traceable management of R&D man-hour input, mainly including:

[0004] Extract the data on the reporting intervals, the variation range of adjacent reporting hours, and the R&D hour input from the R&D management system; obtain the current traceability node list and node generation frequency; identify the degree of fluctuation of hour values ​​within a unit interval; and obtain initial fluctuation characteristic data.

[0005] By comparing the initial fluctuation characteristic data with the preset threshold range, the current reporting density range is analyzed, and the reporting scenario type is marked.

[0006] Based on the type of the reported scenario, extract the data difference values ​​of adjacent time record nodes from the traceability node list, accumulate each difference value and associate it with the corresponding number of nodes, evaluate the decreasing trend and convergence speed of the average difference in the node sequence, and identify the quantitative result of difference narrowing.

[0007] The difference narrowing quantification results are compared with the preset narrowing benchmark to assess whether the current narrowing status is excessive or insufficient, triggering an update of the effective change node screening criteria to obtain optimized node retention conditions.

[0008] From the optimized node retention conditions, specific applicable conditions are selected in combination with the current reporting interval. These conditions are then applied to the traceability node list for filtering. The results are used to assess whether there are substantial changes in the working hour data for each node, thus obtaining a subset of effective nodes.

[0009] Based on the order of the timestamps of each node in the effective node subset and the R&D man-hour input data, a simplified traceability chain structure is generated. This structure is then matched with the historical records of the R&D man-hour data to confirm the balance of refined management and obtain a complete traceability management record.

[0010] Furthermore, the process involves extracting data from the R&D management system, including the reporting intervals for each time period, the variation in adjacent reporting hours, and R&D hour input data; obtaining the current traceability node list and node generation frequency; identifying the degree of fluctuation in hour values ​​within a unit interval; and obtaining initial fluctuation characteristic data, including:

[0011] The system retrieves the work hour reporting records of R&D personnel from the R&D management system. The reporting interval is calculated based on the timestamps of two consecutive reports. The difference between the work hour values ​​of each dimension in each reporting record and the previous record is used as the variation range of adjacent reporting work hours, resulting in a work hour variation sequence with interval markers. For this time interval variation sequence, the generation timestamps and node content of each traceability node are extracted. The number of times nodes are generated within the same time period is counted as the node generation frequency. The time hour variation sequence is traversed according to a preset window size, and the mean and standard deviation of the variation range of adjacent reporting work hours within each window are calculated to obtain a feature vector reflecting the fluctuation pattern of the time period. Based on the feature vector reflecting the fluctuation pattern of the time period, segmentation processing is performed. The average degree of difference per unit node is determined by the ratio of the number of node generation times to the cumulative difference value, constructing initial fluctuation feature data.

[0012] Furthermore, the step of comparing the initial fluctuation characteristic data with a preset threshold range, analyzing the interval to which the current reporting density belongs, and marking the reporting scenario type includes:

[0013] The initial fluctuation feature data is obtained, and the node generation frequency value and average difference value are extracted from it. The node generation frequency value is compared with the preset high-frequency threshold and low-frequency threshold to obtain the reporting density status identifier. The corresponding reporting scenario type is determined according to the reporting density status identifier to obtain the marked reporting scenario type.

[0014] Furthermore, after obtaining the initial fluctuation feature data, the filling interval duration sequence and the working hour change amplitude sequence are extracted from the initial fluctuation feature data. The timestamp of each filling operation by the R&D personnel and the filling ratio of each field in the corresponding working hour record are obtained as the content completeness. The Pearson correlation coefficient between the filling interval duration and the content completeness is calculated to obtain the completeness decay feature value. The filling density status is classified and determined by the decision tree algorithm to identify high-frequency filling scenarios, regular filling scenarios, or low-frequency filling scenarios.

[0015] Furthermore, based on the reporting scenario type, data difference values ​​of adjacent time record nodes are extracted from the traceability node list. These difference values ​​are accumulated and associated with the corresponding number of nodes. The decreasing trend and convergence speed of the average difference in the node sequence are evaluated, and the quantification results of difference narrowing are identified, including:

[0016] Based on the reported scenario type, a subset of nodes corresponding to the scenario is selected from the traceability node list. The node subsets are arranged in timestamp order. The absolute difference between the working hours recorded by each node and the working hours of the previous node is calculated as a single data difference value. All adjacent node pairs are traversed to obtain a difference value sequence. The difference value sequence is accumulated to obtain the total difference value. The number of node pairs participating in the accumulation is counted. The total difference value is divided by the number of node pairs to obtain the average difference. The node subset is segmented according to a fixed number of nodes. The local average difference within each segment is calculated to form an average difference change sequence distributed along the time axis. The difference is calculated based on the local average difference of adjacent segments in the average difference change sequence. The absolute value of all negative differences is accumulated and divided by the total number of segments to obtain the deceleration rate. The convergence benchmark value is calculated based on the deceleration rate. The difference narrowing quantization result is obtained by multiplying the deceleration rate and the convergence benchmark value.

[0017] Furthermore, the difference narrowing quantification results are compared with the preset narrowing benchmark to assess whether the current narrowing status is excessive or insufficient, triggering an update of the effective change node screening criteria to obtain optimized node retention conditions, including:

[0018] The difference narrowing quantification result is obtained and compared with the preset narrowing benchmark. A narrowing status identifier is generated based on the judgment result. The parameter adjustment direction is determined based on the narrowing status identifier and the current reporting scenario type. The corresponding parameters in the original node retention conditions are replaced with relaxed or tightened filtering parameters to obtain optimized node retention conditions.

[0019] Furthermore, the step of selecting applicable specific conditions from the optimized node retention conditions in conjunction with the current reporting interval duration, applying these conditions to filter the traceability node list, evaluating whether there are substantial changes in the working hour data for each node, and obtaining a subset of effective nodes, including:

[0020] Extract the difference threshold and time tolerance parameters from the optimized node retention conditions, obtain the current reporting interval duration, and use the selected threshold as a specific filtering condition; traverse each node in the traceability node list according to the specific filtering condition, calculate the difference between the current node's working hours and the previous node's working hours, and obtain a subset of effective nodes after traversing all nodes.

[0021] Furthermore, specific conditions are selected from the optimized node retention conditions in conjunction with the current reporting interval. These conditions are then applied to the traceability node list for filtering. The evaluation of whether there are substantial changes in the working hour data for each node is also conducted to obtain a subset of effective nodes. This includes: obtaining the lower limit value of working hour changes and the minimum time span from the node retention conditions; collecting the working hour record content and generation time of each node; analyzing the degree of difference between the working hour records of nodes before and after; evaluating whether the generation time interval meets the minimum span requirement; and identifying nodes whose differences exceed the lower limit value and whose time span meets the requirement as nodes with substantial changes.

[0022] Furthermore, based on the order of the timestamps of each node in the effective node subset and the R&D man-hour input data, a simplified traceability chain structure is generated. This structure is then matched with the historical records of R&D man-hour data to confirm the balance of refined management and obtain complete traceability management records, including:

[0023] Extract the record timestamps of each node from the subset of valid nodes, sort them from earliest to latest according to the timestamps, obtain the R&D man-hour input data corresponding to each node, and associate the timestamp sequence with the man-hour data in sequence to construct the link relationship between nodes and obtain the initial traceability chain structure; count the total number of valid nodes according to the initial traceability chain structure, obtain the total number of original nodes in the same period, calculate the ratio of the number of valid nodes to the number of original nodes, and obtain the scene compression feature mark; use the scene compression feature mark to verify the effectiveness of the traceability chain, extract the original data of the corresponding time period from the historical man-hour records, compare the man-hour values ​​of each node in the initial traceability chain with the original data, and obtain the verified simplified traceability chain; evaluate the storage saving ratio and information retention rate according to the verified simplified traceability chain, integrate the node identifier, timestamp, and man-hour data to form a structured record, and obtain a complete traceability management record.

[0024] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0025] This invention discloses a multi-dimensional method for statistical and traceability management of R&D work hours. Addressing the business problems of inconsistent reporting density and inaccurate traceability node selection in R&D work hour reporting scenarios, it identifies high-frequency, routine, and low-frequency reporting scenarios by analyzing reporting intervals, work hour variation amplitudes, and content completeness. It then dynamically adjusts node retention conditions based on the quantification results of difference narrowing. By evaluating the substance and time span of work hour changes, this invention generates a subset of effective nodes, constructs a streamlined traceability chain, and ensures a reduced number of nodes in high-frequency scenarios and comprehensive node coverage in low-frequency scenarios, ultimately achieving a balanced and refined management of work hour data. The technical effects of this invention are improved adaptability and accuracy of traceability management, optimized resource allocation, reduced interference from invalid nodes, and increased R&D management efficiency. Attached Figure Description

[0026] Figure 1 This is a flowchart of a multi-dimensional R&D man-hour input statistics and traceability management method according to the present invention.

[0027] Figure 2 This is a schematic diagram of a multi-dimensional R&D man-hour input statistics and traceability management method according to the present invention.

[0028] Figure 3 This is another schematic diagram of a multi-dimensional R&D man-hour input statistics and traceability management method of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and thoroughly described below with reference to the accompanying drawings. The described embodiments are merely some embodiments of the present invention.

[0030] like Figures 1-3 This embodiment of a multi-dimensional R&D man-hour input statistics and traceability management method may specifically include:

[0031] S101. Extract the data on the reporting intervals for each time period, the variation range of adjacent reporting hours, and the R&D hour input from the R&D management system. Obtain the current traceability node list and node generation frequency. Identify the degree of fluctuation of hour values ​​within a unit interval and obtain initial fluctuation characteristic data.

[0032] The system retrieves R&D personnel's work hour reporting records from the task management module and code repository interface of the R&D management system. The reporting interval is calculated based on the timestamps of two consecutive reports. The difference between the work hour values ​​of each dimension in each reporting record and the previous record is used as the variation range of adjacent reporting work hours. If the reporting interval is less than a preset short interval threshold, it is marked as a short interval reporting; if it is greater than a preset long interval threshold, it is marked as a long interval reporting, resulting in a work hour variation sequence with interval markings. For the work hour variation sequence with interval markings, the generation timestamps and node content of each traceability node are extracted. The number of times nodes are generated within the same time period is counted as the node generation frequency. The degree of fluctuation is determined based on the difference between the maximum and minimum work hour values ​​within a unit interval. The work hour variation sequence is traversed according to a preset window size, and the mean and standard deviation of the variation range of adjacent reporting work hours within each window are calculated to obtain a feature vector reflecting the fluctuation pattern of the time period. The feature vector reflecting the fluctuation pattern of the time period is segmented, and the number of node generation times and the cumulative value of working time difference between adjacent nodes are extracted from the traceability node list. The average degree of difference of a unit node is determined by the ratio of the number of node generation times to the cumulative value of difference. Initial fluctuation feature data is constructed based on the fluctuation degree and the average degree of difference.

[0033] In one implementation, when retrieving the work hour reporting records of R&D personnel from the task management module and code repository interface of the R&D management system, the update information of each data source is read in real time through the API interface. When a developer commits code in GitLab, the commit timestamp and the associated task number are automatically recorded, and the corresponding task's work hour update record is retrieved from the JIRA task management platform. The difference between these two timestamps is the reporting interval.

[0034] For example, in the early stages of a version iteration, a development team may have a low code submission frequency, with the interval between two consecutive submissions potentially reaching 72 hours. However, during the sprint phase before version release, the submission interval is shortened to 2-3 hours. Calculating the magnitude of change in adjacent submission hours involves comparing work hour data across multiple dimensions.

[0035] In one possible implementation, the time difference is calculated for each of the four dimensions: requirements analysis, code development, testing and verification, and documentation. If a developer reports 8 hours of code development time in the current report, while the previous report showed 6 hours, then the change in that dimension is 2 hours. When the cumulative change in all dimensions exceeds a preset significant change threshold, the system considers there to be a substantial change in working hours.

[0036] Preferably, the generation frequency of traceability nodes reflects the update density of time data.

[0037] For example, if 15 trace nodes are generated in the first three days of a two-week sprint, but only 8 nodes are generated in the following eleven days, it indicates that the workload fluctuates frequently in the early stages of the project and tends to stabilize in the later stages. By statistically analyzing the number of nodes per unit time, we can identify the concentrated and stable periods of workload input. This frequency distribution characteristic directly affects subsequent storage strategy optimization.

[0038] In one embodiment, the window traversal process uses a fixed-size sliding window to scan the sequence of time changes.

[0039] Understandably, the multiple time record points contained within a window constitute a local sample set. The average change amplitude of all adjacent records within this sample set is calculated as a representative feature of the window. By continuously sliding the window, a feature vector reflecting the fluctuation pattern of the entire time series is formed, with each vector element corresponding to the statistical characteristics of a time window.

[0040] Specifically, the initial fluctuation characteristic data construction process comprehensively considers two key factors: node density and degree of difference. When the number of node generation times is 20 and the cumulative difference in working hours between adjacent nodes is 40 hours, each node reflects an average of 2 hours of working hour change. This ratio becomes an important indicator for judging the intensity of fluctuations.

[0041] S102. Compare the initial fluctuation characteristic data with the preset threshold range, analyze the interval to which the current reporting density belongs, and mark the reporting scenario type.

[0042] The initial fluctuation feature data is acquired, and node generation frequency values ​​and average difference values ​​are extracted from it. The node generation frequency values ​​are compared with preset high-frequency and low-frequency thresholds. If the frequency value exceeds the high-frequency threshold and the average difference value is lower than the preset lower difference limit, it is determined to be a high-frequency reporting state. If the frequency value is lower than the low-frequency threshold and the average difference value is higher than the preset upper difference limit, it is determined to be a low-frequency reporting state. All other states are determined to be regular reporting states, resulting in a reporting density state identifier. Based on the reporting density state identifier, the corresponding reporting scenario type is determined, where high-frequency reporting corresponds to high-frequency reporting scenarios, regular reporting corresponds to regular reporting scenarios, and low-frequency reporting corresponds to low-frequency reporting scenarios, thus obtaining the labeled reporting scenario type.

[0043] In one implementation, the initial fluctuation characteristic data includes two key indicators: node generation frequency and average degree of difference.

[0044] Specifically, the node generation frequency value reflects the generation density of traceable nodes per unit time, while the average difference value reflects the average magnitude of the change in working hours between adjacent nodes.

[0045] For example, if a research and development team generates more than 5 traceability nodes per day within a sprint cycle, the frequency value is recorded as high; if it generates only 1 node every three days, the frequency value is recorded as low. The threshold is set based on statistical analysis of historical data.

[0046] Preferably, the high-frequency threshold is set to more than 3 nodes per day, and the low-frequency threshold is set to less than 1 node every two days. When the node generation frequency value exceeds the high-frequency threshold and the average difference value is less than 2 hours, it indicates that although the reporting is frequent, the changes each time are very small, and it is judged as a high-frequency reporting status.

[0047] For example, the labeling of the data entry scenario type directly affects subsequent storage optimization strategies. High-frequency data entry scenarios typically occur during the project sprint phase, when developers frequently update task progress; low-frequency data entry scenarios are more common during the project maintenance phase, with fewer changes in working hours; and regular data entry scenarios correspond to the daily development phase, maintaining a stable data entry rhythm.

[0048] The data includes initial fluctuation characteristic data to obtain the reporting interval duration and working time variation range, the data collection of R&D personnel's reporting operation time points and content completeness, analysis of the decline in content completeness when the reporting interval is shortened, assessment of the concentration of operation time points after the working time variation range increases, determination of whether the reporting density is dense, normal or sparse, and identification of high-frequency reporting scenarios, routine reporting scenarios or low-frequency reporting scenarios.

[0049] Extract the reporting interval duration sequence and the working hour variation amplitude sequence from the initial fluctuation characteristic data. Obtain the timestamp of each reporting operation by R&D personnel and the filling ratio of each field in the corresponding working hour record as the content completeness. Calculate the Pearson correlation coefficient between the reporting interval duration and the content completeness. If the correlation coefficient is negative and the absolute value exceeds a preset correlation threshold, it is determined that there is a negative correlation between shortened intervals and decreased completeness, resulting in a completeness decay characteristic value. Based on the completeness decay characteristic value, determine the reporting quality change trend. Statistically analyze reporting records where the working hour variation amplitude exceeds a preset amplitude threshold. Extract the operation time point corresponding to the reporting record and calculate the difference between adjacent operation time points. If the difference between three or more consecutive adjacent operation time points is less than the preset lower limit of 1 hour, it is determined that the operation time points show a concentrated distribution. Calculate the standard deviation of the difference between adjacent operation time points as a time clustering index. Using the time-gathering index and the completeness decay feature value as input features, the reporting density state is classified and determined according to the following rules: if the time-gathering index is higher than the upper threshold of 5 and the completeness decay feature value is higher than the decay threshold of 0.5, it corresponds to a dense state and is identified as a high-frequency reporting scenario; if the time-gathering index is lower than the lower threshold of 2 and the completeness decay feature value is lower than the decay threshold of 0.5, it corresponds to a sparse state and is identified as a low-frequency reporting scenario; the rest correspond to a normal state and are identified as a regular reporting scenario.

[0050] In one implementation, content completeness is calculated based on the completion status of each mandatory field in the work hour record. The R&D management system requires each work hour record to include four mandatory fields: task number, work content description, actual working hours, and completion progress. If all four fields are filled, the completeness is 100%; missing even one field reduces it by 25%. Statistical analysis revealed that when the reporting interval was shortened from once daily to once every four hours, the completion rate of the work content description field decreased from 95% to 60%, indicating that frequent reporting led R&D personnel to simplify the content description. The calculation of the Pearson correlation coefficient involves the covariance and standard deviation of the reporting interval duration series and the content completeness series.

[0051] Preferably, a sliding window method is used to calculate the local correlation coefficient, with the window size set to 10 consecutive reporting records. When the correlation coefficient reaches below -0.7, a strong negative correlation is considered to exist.

[0052] For example, a development team shortened the reporting interval from 8 hours to 2 hours a week before the release of a version. At the same time, the content completeness dropped from 90% to 40%, with a correlation coefficient of -0.85 and a completeness decay characteristic value of 0.85.

[0053] For example, the time clustering index reflects the density of data entry operations across the time axis.

[0054] In one possible implementation, important reporting records with work hour variations exceeding 4 hours are first selected. The timestamps of these records are extracted, and the interval between adjacent timestamps is calculated. If the standard deviation of five consecutive intervals is less than 0.5 hours, it indicates a high concentration of reporting time. In one project team, during the code merging window, 80% of the reporting was completed between 4 PM and 6 PM daily, resulting in a time clustering index of 0.9.

[0055] Specifically, the classification rules of the decision tree algorithm are based on threshold determination of two key features.

[0056] In one embodiment, the root node first determines whether the temporal clustering index exceeds 0.7. If it does, it proceeds to the left subtree to determine whether the completeness decay feature value exceeds 0.6. If both conditions are met, the node is classified as a dense state, corresponding to a high-frequency reporting scenario. If the temporal clustering index is below 0.3 and the completeness decay feature value is below 0.2, the node is classified as a sparse state, corresponding to a low-frequency reporting scenario. Cases falling between these two values ​​are classified as a normal state, corresponding to a regular reporting scenario.

[0057] Understandably, the identification results of the three reporting scenarios directly affect the subsequent traceability node selection strategy. In high-frequency reporting scenarios, the system will automatically increase the node merging threshold to reduce redundant storage.

[0058] S103. Extract the data difference values ​​of adjacent working hour record nodes from the traceability node list according to the reporting scenario type, accumulate each difference value and associate it with the corresponding number of nodes, evaluate the decreasing trend and convergence speed of the average difference in the node sequence, and identify the difference narrowing quantification result.

[0059] Based on the reported scenario type, a subset of nodes corresponding to the scenario is selected from the traceability node list. This subset is arranged in timestamp order. The working hours recorded by each node are extracted and compared to the working hours of the previous node. The absolute difference between the two is calculated as a single data difference value. This process is repeated for all adjacent node pairs to obtain a sequence of difference values. The difference value sequence is then summed to obtain the total difference value. The number of node pairs involved in the summation is counted, and the total difference value is divided by the number of node pairs to obtain the average difference. The subset is then segmented with a fixed number of nodes (20). This number is set based on experience with the total number of nodes and time distribution to ensure segment uniformity and statistical significance. The local average difference within each segment is calculated, forming a sequence of average difference changes distributed along the time axis. The difference is calculated based on the local average differences of adjacent segments in the average difference change sequence. If three or more consecutive differences are negative, a decreasing trend is identified. The absolute value of all negative differences is summed and divided by the total number of segments to obtain the deceleration rate. If the deceleration rate exceeds a preset rate threshold, it is marked as fast convergence; otherwise, it is marked as slow convergence, resulting in a trend convergence marker. Using the trend convergence marker and the deceleration rate, the weighted average of the last three segments of the average difference change sequence is calculated as the convergence benchmark value. If the convergence benchmark value is less than the preset proportion of the initial segment average difference, it is determined that the convergence state has been reached. The difference narrowing quantification result is obtained by multiplying the deceleration rate and the convergence benchmark value.

[0060] In one implementation, when filtering nodes from the traceability node list based on the reporting scenario type, different filtering strategies are adopted for different scenarios.

[0061] Specifically, the node density in high-frequency reporting scenarios is usually 3-5 times that of low-frequency scenarios. Each node record contains four core fields: timestamp, working hours, task identifier, and personnel number.

[0062] For example, a research and development team generates 200 traceability nodes during a sprint. These nodes are first sorted in ascending order of timestamps. Then, adjacent node pairs are traversed, and the absolute difference in work hours is calculated. If the Nth node records 8 hours of work and the (N+1)th node records 10 hours, the difference is 2 hours. By traversing all 199 adjacent node pairs, a sequence of difference values ​​containing 199 elements is formed. The calculation of the average difference involves two levels of statistical processing.

[0063] Preferably, the entire difference value sequence is first accumulated. Assuming the sum of 199 difference values ​​is 398 hours, the initial average difference is 2 hours. Then, the node subset is divided into segments of 20 nodes each. For 200 nodes, this can be divided into 10 segments. Within each segment, the system recalculates the local average difference of the 19 adjacent node pairs within that segment.

[0064] For example, the local average difference in the first segment is 3.5 hours, in the second segment it is 3.2 hours, in the third segment it is 2.8 hours, and so on, ultimately forming a sequence of average difference changes containing 10 values. This segmented processing method can capture the dynamic changes in difference values ​​over time.

[0065] For example, the determination of a decreasing trend is based on the difference analysis between adjacent segments.

[0066] In one possible implementation, the difference between the second and first segments is calculated as -0.3 hours, the difference between the third and second as -0.4 hours, and the difference between the fourth and third as -0.2 hours. When three or more consecutive negative differences occur, a decreasing trend is considered. The deceleration rate is calculated by summing the absolute values ​​of all negative differences; in this example, it's 0.3 + 0.4 + 0.2 + ... Assuming 8 out of 10 segments produce negative differences, the cumulative absolute value is 2.4 hours. Dividing this by the total number of segments (10) yields a deceleration rate of 0.24 hours per segment.

[0067] Specifically, the determination of trend convergence relies on a comparison between the deceleration rate and a preset threshold. If the preset rate threshold is 0.15 hours / segment, and the actual deceleration rate of 0.24 exceeds this threshold, the system marks it as fast convergence. Fast convergence typically means that the work hour reporting behavior of the R&D team is rapidly stabilizing, and the differences between adjacent records are rapidly decreasing. Furthermore, the convergence benchmark value is calculated using a weighted average method for the data in the last segment.

[0068] For example, if the last three segment values ​​of the average difference change sequence are 1.2 hours, 1.0 hours, and 0.9 hours, respectively, and the system assigns weights of 0.2, 0.3, and 0.5, the calculated convergence benchmark value is 1.2 × 0.2 + 1.0 × 0.3 + 0.9 × 0.5 hours. If the initial segment average difference is 3.5 hours and the preset proportion is 30%, then the threshold is 1.05 hours. Since the convergence benchmark value of 0.99 is less than 1.05, the system determines that convergence has been achieved.

[0069] In one embodiment, the difference narrowing quantification result is obtained by multiplying the deceleration rate by the convergence benchmark value. Specifically, it is calculated as 0.24 × 0.99, which reflects the overall degree of difference narrowing. The smaller the value, the lower the volatility of the work hour reporting and the more stable the data quality.

[0070] Understandably, the characteristics of difference narrowing differ significantly across different reporting scenarios. High-frequency reporting scenarios, due to their high node density, typically have smaller initial average differences but a faster rate of deceleration; low-frequency reporting scenarios, with sparse nodes, have larger initial average differences and a relatively slower rate of deceleration. Regular reporting scenarios fall somewhere in between.

[0071] For example, a project team used low-frequency data entry during the requirements analysis phase, updating work hours weekly. The initial average difference reached 15 hours. After 8 weeks of data accumulation, the deceleration rate was only 0.08 hours per segment, and the convergence baseline stabilized at around 12 hours. However, after entering the coding phase, the same project team switched to high-frequency data entry, updating twice daily. The initial average difference decreased to 2 hours, but the deceleration rate increased to 0.35 hours per segment, and the convergence baseline quickly dropped to 0.5 hours. The quantification results of the difference narrowing provided important basis for subsequent node selection and optimization. When the quantification result was below 0.1, it indicated that the work hour data was highly stable, allowing for a significant increase in the node merging threshold and a reduction in storage redundancy.

[0072] S104. Compare the difference narrowing quantification results with the preset narrowing benchmark to assess whether the current narrowing status is excessive or insufficient, trigger the update of the effective change node screening criteria, and obtain optimized node retention conditions.

[0073] The difference narrowing quantification result is obtained and compared with a preset narrowing benchmark. The lower threshold of the narrowing benchmark is set to 0.05, and the upper threshold is set to 0.5. These thresholds are set based on historical data statistical analysis and industry optimization standards. If the quantification result is less than the lower threshold of the narrowing benchmark, it is judged as an over-narrowing state. If the quantification result is greater than the upper threshold of the narrowing benchmark, it is judged as an under-narrowing state. A narrowing state identifier is generated based on the judgment result. The parameter adjustment direction is determined based on the narrowing state identifier and the current reporting scenario type. If an over-narrowing state is detected in a high-frequency reporting scenario, the difference value judgment threshold in the current node retention condition is extracted and multiplied by a preset relaxation factor greater than 1. At the same time, the time interval tolerance is increased by a preset tolerance increment. The preset relaxation factor is set to 1.5 based on empirical testing to balance efficiency, and the tolerance increment is set to 60 minutes based on the needs of low-risk scenarios, resulting in the relaxed screening parameters. If insufficient narrowing is detected in a low-frequency reporting scenario, the difference value judgment threshold in the current node retention condition is extracted and multiplied by a preset tightening multiple less than 1. At the same time, the time interval tolerance is reduced by a preset tolerance reduction. The corresponding parameters in the original node retention condition are replaced with relaxed or tightened filtering parameters to obtain optimized node retention conditions.

[0074] In one implementation, the comparison process between the difference narrowing quantization result and the preset narrowing benchmark involves multi-level threshold determination.

[0075] Specifically, the narrowing benchmark is set as a range, with a lower threshold typically of 0.05 and an upper threshold of 0.5. This range represents the normal degree of difference narrowing. When the quantization result is 0.02, which is less than the lower threshold, it is considered an over-narrowing state, meaning that the difference between adjacent nodes is too small, potentially leading to the loss of important change information. When the quantization result reaches 0.8, which exceeds the upper threshold, it is considered an under-narrowing state, indicating that there are still significant differences between nodes and the accuracy of the tracing chain is insufficient. Determining the direction of parameter adjustment requires comprehensive consideration of both the narrowing state and the type of reporting scenario.

[0076] For example, in high-frequency reporting scenarios, excessive narrowing indicates that the current node retention criteria are too strict, causing many valuable change nodes to be incorrectly filtered out. In this case, the current difference value judgment threshold is extracted, assuming it is 2 hours, and multiplied by a relaxation factor of 1.5, adjusted to 3 hours. At the same time, the time interval tolerance is increased by 60 minutes from the original 30 minutes, adjusted to 90 minutes. This relaxation adjustment allows more nodes reflecting substantial changes to be retained.

[0077] Preferably, the narrowing insufficiency state in low-frequency reporting scenarios adopts the opposite adjustment strategy.

[0078] In one possible implementation, when insufficient narrowing of low-frequency scenes is detected, it is identified that the node retention conditions are too lenient, resulting in a large number of redundant nodes being saved.

[0079] For example, if the current threshold for determining the difference is 10 hours, the system will adjust it to 6 hours by multiplying it by a tightening factor of 0.6. The time interval tolerance will be reduced by 1 hour from 4 hours to 3 hours.

[0080] Specifically, the parameter replacement process is implemented by updating the data structure of the node retention conditions. The original node retention conditions include three core parameters: difference threshold, time tolerance, and scene identifier. The system updates the values ​​of the first two parameters based on the adjustment results, while keeping the scene identifier unchanged.

[0081] For example, when a research and development project transitions from the requirements analysis phase to the development phase, the reporting frequency increases. The system automatically identifies the change in scenario and applies corresponding parameter adjustment strategies, achieving dynamic optimization of traceability node storage. The optimized node retention conditions can adapt to different reporting modes, reducing storage redundancy while ensuring traceability integrity.

[0082] S105. Select applicable specific conditions from the optimized node retention conditions and the current reporting interval duration, apply the conditions to the traceability node list for filtering, evaluate whether there are substantial changes in working hour data for each node, and obtain a subset of effective nodes.

[0083] Extract the difference threshold and time tolerance parameters from the optimized node retention conditions, obtain the current reporting interval duration, and if the interval duration is less than the time tolerance, select the strict difference threshold from the node retention conditions; otherwise, select the lenient difference threshold. Use the selected threshold as a specific filtering condition. Based on the specific filtering condition, traverse each node in the traceability node list, calculate the difference between the current node's working hours and the previous node's working hours, and if the difference exceeds the threshold used as the filtering condition, determine that the node has undergone substantial changes and retain it; otherwise, filter the node. After traversing all nodes, obtain a subset of valid nodes.

[0084] In one implementation, the node retention conditions include two sets of difference threshold parameters: a strict difference threshold set to 1 hour and a lenient difference threshold set to 3 hours. When the reporting interval is 2 hours, which is less than the 4-hour time tolerance, the system determines it as a short-interval reporting mode and selects the 1-hour strict difference threshold as the filtering condition. This strict condition is suitable for frequent reporting scenarios, filtering out minor changes and retaining only significant work hour change records.

[0085] It should be noted that the node filtering process uses a sequential traversal method to process the traceability node list.

[0086] For example, if a node records 8 hours of work time, and the previous node recorded 7.5 hours, the difference of 0.5 hours is less than the strict threshold of 1 hour, so this node is filtered out. On the other hand, if another node records 10 hours, and the previous node recorded 8 hours, the difference of 2 hours exceeds the threshold, so it is determined that there is a substantial change and is retained.

[0087] Preferably, the process of constructing the effective node subset is dynamically adjusted.

[0088] In one possible implementation, the original node list contains 100 nodes, which are then filtered to retain 35 valid nodes, achieving a 65% optimization of storage space while preserving all critical time change information.

[0089] Obtain the lower limit of time variation and the minimum time span from the node retention conditions, collect the time record content and generation time of each node, analyze the degree of difference between the time records of nodes before and after, assess whether the generation time interval meets the minimum span requirement, and determine the nodes whose difference exceeds the lower limit and whose time meets the span as the substantial change nodes.

[0090] Extract the lower limit of time variation and the minimum time span parameter from the node retention conditions. Obtain the time record content and generation timestamp of each node in the traceability node list. Combine the time record content and generation timestamp to form a node basic information set. For the node basic information set, traverse adjacent node pairs, calculate the difference in time values ​​between two consecutive nodes, and simultaneously calculate the time interval between the generation timestamps of two nodes. If the difference exceeds the lower limit of time variation and the time interval is greater than the minimum time span, mark the node as a candidate change node, obtaining a candidate node marking sequence. Filter nodes according to the candidate node marking sequence, extract nodes with candidate change node markings, determine the nodes as substantial change nodes, and obtain a substantial change node set after traversing all marked nodes.

[0091] In one implementation, the lower limit for work hour variation and the minimum time span are core parameters for node retention, directly affecting the accuracy of identifying nodes with substantial changes. The lower limit for work hour variation is typically set to 2 hours, meaning that only changes in work hours that reach or exceed 2 hours are considered valuable for recording. The minimum time span is set to 4 hours to prevent excessively frequent minor changes from being recorded. This dual-limit mechanism effectively filters out noisy data and retains truly meaningful work hour change records. The construction of the node basic information set involves the integration of multi-source data.

[0092] For example, the time records extracted from the JIRA system include fields such as task ID, actual working hours, and task status, with each record bearing a timestamp accurate to the second. If a developer records 8 hours of work at 9:00 AM and updates it to 10 hours at 2:00 PM, the system automatically captures complete information from these two time points, forming a structured dataset for subsequent analysis.

[0093] Preferably, the traversal of adjacent node pairs adopts a sliding window mechanism.

[0094] In one possible implementation, all nodes are arranged in chronological order, and adjacent nodes are compared one by one.

[0095] For example, node A records 6 hours of work time, generated at 10:00 AM on Monday; node B records 9 hours of work time, generated at 3:00 PM on Monday. The calculated work time difference is 3 hours, exceeding the lower limit of 2 hours; the time interval is 5 hours, exceeding the minimum span of 4 hours. Since both conditions are met, node B is marked as a candidate change node.

[0096] Specifically, the processing of the candidate node labeling sequence reflects the rigor of the screening process. Only nodes that simultaneously meet the conditions of both time variation and time span can enter the candidate sequence. If a node's time variation reaches 3 hours, but the time interval with the previous node is only 2 hours, failing to meet the minimum time span requirement, the node will not be labeled as a candidate node, thus avoiding the over-recording of frequent small adjustments within a short period. Furthermore, the formation process of the set of nodes with substantial changes ensures the simplicity of the traceability chain.

[0097] For example, if the original number of nodes in a certain sprint cycle is 150, after double-condition screening, only 42 nodes are finally identified as having undergone substantial changes. While retaining key change information, storage requirements are reduced by 72%.

[0098] Understandably, this node identification mechanism based on dual judgment has shown good adaptability at different stages of R&D, capable of capturing important changes during peak development periods while filtering out trivial adjustments during maintenance periods.

[0099] S106. Based on the order of the timestamps of each node in the effective node subset and the R&D man-hour input data, generate a simplified traceability chain structure, match it with the historical records of R&D man-hour data, confirm the balance result of refined management, and obtain a complete traceability management record.

[0100] The record timestamps of each node are extracted from the subset of valid nodes and sorted from earliest to latest according to the timestamps. The corresponding R&D man-hour input data for each node is obtained. The timestamp sequence and man-hour data are sequentially associated to construct the link relationship between nodes, resulting in an initial traceability chain structure. Based on the initial traceability chain structure, the total number of valid nodes is counted, and the total number of original nodes for the same period is obtained. The ratio of the number of valid nodes to the number of original nodes is calculated. If the current scenario is a high-frequency reporting scenario and the ratio is less than a preset compression threshold, it is marked as a high-frequency compression feature; if the current scenario is a low-frequency reporting scenario and the ratio is greater than a preset retention threshold, it is marked as a low-frequency retention feature, resulting in a scenario compression feature label. The effectiveness of the traceability chain is verified using the scenario compression feature label. The original data for the corresponding time period is extracted from historical man-hour records. The man-hour values ​​of each node in the initial traceability chain are compared with the original data, and the degree of consistency between the two is calculated. If the degree of consistency exceeds a preset matching threshold, the traceability chain is confirmed to be accurate, resulting in a verified simplified traceability chain. Based on the verified streamlined traceability chain, the storage saving ratio and information retention rate are evaluated. A unique identifier is assigned to each node in the traceability chain. The node identifier, timestamp, and working time data are integrated to form a structured record. The result of refined management balance is confirmed, and a complete traceability management record is obtained.

[0101] In one implementation, the process of constructing the initial traceability chain structure involves the orderly organization of multi-dimensional data.

[0102] Specifically, the timestamps extracted from the subset of valid nodes are accurate to the millisecond level, ensuring the accuracy of node sorting. Each node carries R&D man-hour input data that includes not only numerical information but also associated task context, such as metadata like the Sprint it belongs to, the associated requirement number, and the responsible person's identifier. Through the ascending order of the timestamps, the system constructs a timeline trajectory of man-hour changes, and adjacent nodes are linked through pointers, forming a traceable data chain.

[0103] For example, a two-week sprint contains 42 valid nodes, which, when strung together in chronological order, clearly demonstrate the complete time commitment process from requirements analysis to code submission.

[0104] For example, in a high-frequency reporting scenario, R&D personnel update their work hours every 2-3 hours, resulting in an initial number of 200 nodes. However, after the aforementioned filtering steps, only 35 valid nodes are retained, representing a compression ratio of 17.5%. In a low-frequency reporting scenario, R&D personnel update their work hours only every 2-3 days, resulting in an initial number of only 30 nodes. However, due to the significant changes in work hours involved in each update, 25 valid nodes are retained, achieving a compression ratio as high as 83.3%. This phenomenon indicates a clear inverse relationship between reporting frequency and node retention rate: the more frequent the reporting, the lower the percentage of valid nodes; the sparser the reporting, the higher the percentage of valid nodes.

[0105] Preferably, the determination of scene compression feature labels adopts a dual threshold mechanism.

[0106] In one possible implementation, the compression threshold for high-frequency scenarios is set to 0.3, meaning the number of effective nodes should be less than 30% of the original nodes; the retention threshold for low-frequency scenarios is set to 0.7, indicating the number of effective nodes should remain above 70% of the original nodes. By calculating the relationship between the actual compression ratio and the corresponding threshold, it is determined whether the current traceability chain meets the expected compression mode. If the compression ratio in high-frequency scenarios is 0.25, which is less than the threshold of 0.3, it is marked as a high-frequency compression feature, indicating that the node selection strategy has achieved the expected compression effect in high-frequency scenarios.

[0107] Specifically, the traceability chain verification process ensures accuracy through multi-level data comparison. First, raw data from the same time period as the traceability chain is extracted from historical work hour records. This raw data comes from the backup database of the R&D management system, preserving complete records without any filtering. Then, the work hour value of each node in the traceability chain is compared with the corresponding value in the raw records, calculating the degree of deviation. The degree of consistency is measured by the correlation coefficient; when the correlation coefficient reaches 0.95 or higher, it indicates that the simplified traceability chain still accurately reflects the key characteristics of work hour changes.

[0108] For example, a project's traceability chain contains 50 nodes. After comparing it with the original 180 records, the work hours at key time points are completely consistent. The 130 nodes that were filtered out in the middle have only minor fluctuations and do not affect the accuracy of the overall trend. Furthermore, the evaluation of the results of refined management involves a trade-off analysis between storage efficiency and information integrity. The storage saving ratio is calculated by comparing the storage space occupied by the streamlined traceability chain with the original complete records. In one project, the original data was compressed from 15MB to 3.2MB, saving 78.7% of storage space. The information retention rate is determined by evaluating the coverage of key business nodes, such as ensuring that all milestone nodes and major work hour adjustment points are fully retained.

[0109] In one embodiment, node identifiers are assigned using a combination of an incrementing sequence number and a timestamp to ensure the uniqueness of each node throughout the system.

[0110] For example, the identifier "2024Q1_SPR03_NODE_042" represents the 42nd node of the 3rd Sprint in the first quarter of 2024.

[0111] Understandably, a complete traceability management record forms a structured dataset containing information across multiple dimensions, including node identifier sequences, timestamp arrays, time value vectors, scenario type markers, and compression feature markers. This record not only meets the basic requirements for time traceability but also achieves efficient utilization of storage resources through simplification and optimization. By identifying and utilizing the inverse correlation between reporting frequency and node compression rate, a differentiated node selection strategy is implemented, achieving a balance between storage optimization and information preservation in different reporting scenarios, thus providing an adaptive traceability mechanism for enterprise R&D time management.

[0112] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for multi-dimensional statistical and traceable management of R&D man-hour input, characterized in that, The method includes: Extract the data on the reporting intervals for each time period, the variation range of adjacent reporting hours, and the R&D hour input from the R&D management system; obtain the current traceability node list and node generation frequency; identify the degree of fluctuation of hour values ​​within a unit interval; and obtain initial fluctuation characteristic data. By comparing the initial fluctuation characteristic data with the preset threshold range, the current reporting density range is analyzed, and the reporting scenario type is marked. Based on the type of the reported scenario, extract the data difference values ​​of adjacent time record nodes from the traceability node list, accumulate each difference value and associate it with the corresponding number of nodes, evaluate the decreasing trend and convergence speed of the average difference in the node sequence, and identify the quantification result of difference narrowing. The difference narrowing quantification results are compared with the preset narrowing benchmark to assess whether the current narrowing status is excessive or insufficient, triggering an update of the effective change node screening criteria to obtain optimized node retention conditions. From the optimized node retention conditions, specific applicable conditions are selected in combination with the current reporting interval. These conditions are then applied to the traceability node list for filtering. The results are used to assess whether there are substantial changes in the working hour data for each node, thus obtaining a subset of effective nodes. Based on the order of the timestamps of each node in the effective node subset and the R&D man-hour input data, a simplified traceability chain structure is generated. This structure is then matched with the historical records of the R&D man-hour data to confirm the balance of refined management and obtain a complete traceability management record.

2. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, The process involves extracting data from the R&D management system, including the data on the reporting intervals for each time period, the variation in adjacent reporting hours, and the R&D hour input. This process yields the current traceability node list and node generation frequency, identifies the degree of fluctuation in hour values ​​within a unit interval, and obtains initial fluctuation characteristic data, including: The system retrieves the work hour reporting records of R&D personnel from the R&D management system. The reporting interval is calculated based on the timestamps of two consecutive reports. The difference between the work hour values ​​of each dimension in each reporting record and the previous record is used as the variation range of adjacent reporting work hours, resulting in a work hour variation sequence with interval markers. For this time interval variation sequence, the generation timestamps and node content of each traceability node are extracted. The number of times nodes are generated within the same time period is counted as the node generation frequency. The time hour variation sequence is traversed according to a preset window size, and the mean and standard deviation of the variation range of adjacent reporting work hours within each window are calculated to obtain a feature vector reflecting the fluctuation pattern of the time period. Based on the feature vector reflecting the fluctuation pattern of the time period, segmentation processing is performed. The average degree of difference per unit node is determined by the ratio of the number of node generation times to the cumulative difference value, constructing initial fluctuation feature data.

3. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, The step of comparing the initial fluctuation characteristic data with a preset threshold range to analyze the current reporting density range and mark the reporting scenario type includes: The initial fluctuation feature data is obtained, and the node generation frequency value and average difference value are extracted from it. The node generation frequency value is compared with the preset high-frequency threshold and low-frequency threshold to obtain the reporting density status identifier. The corresponding reporting scenario type is determined according to the reporting density status identifier to obtain the marked reporting scenario type.

4. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, After obtaining the initial fluctuation feature data, the filling interval duration sequence and the working hour change amplitude sequence are extracted from the initial fluctuation feature data. The timestamp of each filling operation by the R&D personnel and the filling ratio of each field in the corresponding working hour record are obtained as the content completeness. The Pearson correlation coefficient between the filling interval duration and the content completeness is calculated to obtain the completeness decay feature value. The filling density status is classified and determined by the decision tree algorithm to identify high-frequency filling scenarios, regular filling scenarios, or low-frequency filling scenarios.

5. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, The process involves extracting data difference values ​​from adjacent time record nodes in the traceability node list based on the reported scenario type, accumulating each difference value and associating it with the corresponding number of nodes, evaluating the decreasing trend and convergence speed of the average difference in the node sequence, and identifying the quantification result of difference narrowing, including: Based on the reported scenario type, a subset of nodes corresponding to the scenario is selected from the traceability node list. The node subsets are arranged in timestamp order. The absolute difference between the working hours recorded by each node and the working hours of the previous node is calculated as a single data difference value. All adjacent node pairs are traversed to obtain a difference value sequence. The difference value sequence is accumulated to obtain the total difference value. The number of node pairs participating in the accumulation is counted. The total difference value is divided by the number of node pairs to obtain the average difference. The node subset is segmented according to a fixed number of nodes. The local average difference within each segment is calculated to form an average difference change sequence distributed along the time axis. The difference is calculated based on the local average difference of adjacent segments in the average difference change sequence. The absolute value of all negative differences is accumulated and divided by the total number of segments to obtain the deceleration rate. The convergence benchmark value is calculated based on the deceleration rate. The difference narrowing quantization result is obtained by multiplying the deceleration rate and the convergence benchmark value.

6. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, The process involves comparing the quantified narrowing results with a preset narrowing benchmark to assess whether the current narrowing state is excessive or insufficient, triggering an update to the effective change node selection criteria, and obtaining optimized node retention conditions, including: The difference narrowing quantification result is obtained and compared with the preset narrowing benchmark. A narrowing status identifier is generated based on the judgment result. The parameter adjustment direction is determined based on the narrowing status identifier and the current reporting scenario type. The corresponding parameters in the original node retention conditions are replaced with relaxed or tightened filtering parameters to obtain optimized node retention conditions.

7. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, The process involves selecting applicable specific conditions from the optimized node retention criteria combined with the current reporting interval, applying these conditions to filter the traceability node list, evaluating whether there are substantial changes in the working hour data for each node, and obtaining a subset of valid nodes, including: Extract the difference threshold and time tolerance parameters from the optimized node retention conditions, obtain the current reporting interval duration, and use the selected threshold as a specific filtering condition; traverse each node in the traceability node list according to the specific filtering condition, calculate the difference between the current node's working hours and the previous node's working hours, and obtain a subset of effective nodes after traversing all nodes.

8. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, From the optimized node retention conditions, specific applicable conditions are selected in conjunction with the current reporting interval. These conditions are then applied to the traceability node list for filtering. The evaluation of whether there are substantial changes in the work hour data for each node is conducted to obtain a subset of effective nodes. This includes: obtaining the lower limit value of work hour changes and the minimum time span from the node retention conditions; collecting the work hour record content and generation time of each node; analyzing the degree of difference between the work hour records of nodes before and after; evaluating whether the generation time interval meets the minimum span requirement; and identifying nodes whose differences exceed the lower limit value and whose time span meets the requirement as nodes with substantial changes.

9. The method for multi-dimensional R&D man-hour input statistics and traceability management according to claim 1, characterized in that, The simplified traceability chain structure is generated based on the order of the timestamps of each node in the effective node subset and the R&D man-hour input data. This structure is then matched with the historical records of the R&D man-hour data to confirm the refined management balance result and obtain a complete traceability management record, including: Extract the record timestamps of each node from the subset of valid nodes, sort them from earliest to latest according to the timestamps, obtain the R&D man-hour input data corresponding to each node, and associate the timestamp sequence with the man-hour data in sequence to construct the link relationship between nodes and obtain the initial traceability chain structure; count the total number of valid nodes according to the initial traceability chain structure, obtain the total number of original nodes in the same period, calculate the ratio of the number of valid nodes to the number of original nodes, and obtain the scene compression feature mark; use the scene compression feature mark to verify the effectiveness of the traceability chain, extract the original data of the corresponding time period from the historical man-hour records, compare the man-hour values ​​of each node in the initial traceability chain with the original data, and obtain the verified simplified traceability chain; evaluate the storage saving ratio and information retention rate according to the verified simplified traceability chain, integrate the node identifier, timestamp, and man-hour data to form a structured record, and obtain a complete traceability management record.

Images