A method of detecting focus on research and development iteration work

Abstract

This invention discloses a method for detecting focus during R&D iteration work, belonging to the field of software engineering technology. The method involves acquiring technical design documents and the current and historical code of R&D personnel; parsing the design documents to generate requirement data flow links, and generating code data flow links based on code differences; calculating the final implementation coverage of the technical design documents and the over-implementation rate of the current code through matching analysis; simultaneously collecting and analyzing behavioral video data of R&D personnel, and calculating an inattentiveness index using facial feature information; finally, combining the above implementation coverage, over-implementation rate, and inattentiveness index to calculate the focus score during this R&D iteration. This invention analyzes the focus during R&D iteration work from the dimensions of design implementation and process status of R&D iteration tasks, reflecting both whether iteration tasks are implemented according to design requirements and whether the user remains in an effective working state throughout the iteration process.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, and in particular relates to a method for detecting focus during R&D iteration work. Background Technology

[0002] With the expansion of software development scale and the popularization of iterative development models, a complete development iteration typically generates both design-implementation related data such as requirement documents, design diagrams, and code commit records, and process-state related data such as images and operation logs on the development terminal. For assessing focus during development iterations, it's necessary to consider both whether the iteration task is implemented according to design requirements and whether the target on the terminal remains effectively operational throughout the iteration process. Therefore, focus during development iterations cannot be accurately reflected by a single code inspection or behavior detection; a comprehensive analysis combining design implementation and process-state performance is required.

[0003] Currently, existing technical solutions that are similar in technical substance and application to this solution mainly fall into two categories. In terms of code and design consistency detection, traditional software development processes primarily rely on manual code reviews or static code analysis tools (such as SonarQube). Static tools mainly focus on syntax errors and code style, while manual reviews depend on the experience of the reviewers. Regarding work focus detection, existing monitoring methods typically use methods such as recording keyboard and mouse operation frequency, screen recording, or simple time clocks to calculate work hours. Some advanced solutions are beginning to utilize facial recognition via cameras to determine whether personnel are on duty.

[0004] The aforementioned prior art has the following main drawbacks:

[0005] 1. There is a serious disconnect between design documents and code implementation, and a lack of automated verification mechanisms for construction based on drawings. Design documents (such as PlantUML and Mermaid) are static text, while code is dynamic logic. There is a lack of methods to transform the logical flow of the design drawings into data structures that can be compared with the code's Control Flow Graph (CFG). This results in a disconnect between design and code, making it impossible to automatically determine whether the code accurately reflects or over-implements the design.

[0006] 2. Focus detection relies on a single dimension and cannot effectively identify abnormal states during iterative execution. Traditional solutions based on peripherals or simple face detection struggle to distinguish between passive states such as daydreaming (prolonged stillness) or drowsiness (closed eyes, nodding) and active working states, resulting in a high false positive rate.

[0007] 3. Lack of a comprehensive analysis model combining hardware and software, resulting in a fragmented detection system. Existing technologies typically handle code quality checks and process status monitoring separately, lacking a technical solution that combines the implementation status of design with the focus during iterative execution for unified quantitative analysis.

[0008] Therefore, how to achieve an automated, multi-dimensional, and integrated hardware and software testing solution to continuously and objectively evaluate the focus of R&D iteration work is an urgent problem to be solved in this field. Summary of the Invention

[0009] To address the aforementioned issues, this invention proposes a method for detecting focus during R&D iterations. It combines automated design-code consistency verification with multi-dimensional behavioral focus monitoring, and uses a unified quantitative evaluation model to achieve continuous and objective assessment of R&D personnel's focus.

[0010] The technical solution adopted in this invention is as follows:

[0011] Firstly, this invention proposes a method for detecting focus during R&D iteration work, comprising the following steps:

[0012] S1. Obtain the technical design documents, as well as the current and historical code of the target R&D personnel during the R&D iteration;

[0013] S2. Analyze the technical design document and generate multiple requirement data flow links;

[0014] S3. Generate multiple code data flow links based on the differences between the current code and historical code;

[0015] S4. Filter candidate code data flow links for each requirement data flow link to obtain a set of valid links;

[0016] The effective link set is processed in a positive direction. A one-to-one matching method is used to calculate the one-to-one matching degree between each requirement data flow link and each candidate code data flow link. The final implementation coverage of the technical design document is obtained by aggregating the data flow links through the target achievement algorithm.

[0017] The effective link set is processed in reverse. A one-to-one matching method is used to calculate the one-to-one matching degree between each code data flow link and the corresponding multiple requirement data flow links. If the maximum value of the one-to-one matching degree is lower than the over-implementation judgment threshold, the code data flow link is judged to be over-implemented. The over-implementation rate of the current code is obtained by statistically analyzing the proportion of the number of code data flow links judged to be over-implemented to the total number.

[0018] S5. Collect video data of the target R&D personnel's behavior during the R&D iteration, analyze the facial feature information in the video data, and calculate the "drifting off" index.

[0019] S6. Based on the final implementation coverage, over-implementation rate, and distraction index, calculate the focus score of the target R&D personnel during this R&D iteration.

[0020] Furthermore, S2 includes:

[0021] The technical design document is analyzed to obtain a use case diagram and an entity relationship diagram. The use case diagram includes vertices composed of actors and use cases and directed edges between vertices. The entity relationship diagram includes a set of entities, a set of attributes, and the relationships between entities. Entities and their attributes constitute a data table.

[0022] Based on the use case diagram, enumerate all simple paths from each actor vertex to each use case vertex to obtain the set of functional paths;

[0023] Based on the large language model, the functional path set and entity relationship diagram are associated to generate the requirement data flow link; each requirement data flow link includes multiple operation nodes arranged in the design order, and the operation node contains the data table involved in the operation and the corresponding operation type.

[0024] Furthermore, S3 includes:

[0025] Obtain the differences between the current code and the historical code;

[0026] The difference code is parsed into an abstract syntax tree, and the abstract syntax tree is then converted into a control flow graph;

[0027] Traverse all execution paths in the control flow graph, extract the database operations in each path node, and obtain the initial code operation sequence;

[0028] Based on the large language model, the initial code operation sequence corresponding to the current code and the historical code is compared and analyzed to generate code data flow links; each code data flow link includes multiple operation nodes arranged in execution order, and the operation node contains the data table involved in the operation and the corresponding operation type.

[0029] Furthermore, in S4, the process of filtering the set of valid links includes:

[0030] Calculate the table coverage matching degree and operation coverage matching degree for each requirement data flow link and each code data flow link to obtain a fast similarity score; based on the fast similarity score, apply the Top-K algorithm of heap permutation to dynamically select K candidate code data flow links for each requirement data flow link;

[0031] The formula for calculating the rapid similarity score is as follows:

[0032] ;

[0033] in, It is the demand data flow link and code data flow links Quick similarity scoring, It is the table coverage matching degree. It is the operation coverage matching degree. It is the difference penalty coefficient. It is the absolute value;

[0034] The calculation process for the table coverage matching degree is as follows: obtain the set of requirement data tables and the set of code data tables from the set of operation nodes of each requirement data flow link and each code data flow link respectively; divide twice the size of the intersection of the two data table sets by the sum of the sizes of the two data table sets to obtain the table coverage matching degree;

[0035] The calculation process for the operation coverage matching degree is as follows: obtain the set of demand operation types and the set of code operation types from the set of operation nodes of each demand data flow link and each code data flow link respectively; for each demand operation type, determine an optimal matching similarity in the set of code operation types according to a preset pairing rule; take the average of the optimal matching similarities corresponding to the set of demand operation types as the operation coverage matching degree.

[0036] Further, in S4, the one-to-one matching method is used to calculate the one-to-one matching degree between a source link and a target link; when processing the effective link set in the forward direction, the demand data flow link is used as the source link, and the multiple candidate code data flow links corresponding to each demand data flow link are used as the target link; when processing the effective link set in the reverse direction, the candidate code data flow link is used as the source link, and the multiple demand data flow links corresponding to each candidate code data flow link are used as the target link.

[0037] The one-to-one matching method is specifically as follows:

[0038] First, iterate through all target links and their associated operation node sets. For each data table in the operation node set, count the frequency of occurrence, the operation score based on the operation type, and the number of associations with other tables. After standardizing the statistical results, perform cluster analysis. Based on the clustering results, determine the data tables contained in the categories that show high values ​​on multiple feature dimensions as the core table set.

[0039] Data tables belonging to the core table set are extracted from both the source and target links, and the core table matching degree is calculated. If the core table matching degree is lower than the core table matching threshold, the core table matching degree is directly used as the one-to-one matching degree between the source and target links. Otherwise, the table structure level evaluation value is obtained based on the average of the table coverage matching degree and the core table matching degree between the source and target links, and the logical behavior level evaluation value is obtained based on the average of the operation coverage matching degree and the table sequence matching degree. The table sequence matching degree refers to the ratio of the number of pairwise table name combinations that appear in both links and have the same relative order to the total length of the table name sequence in the source link.

[0040] The smaller value between the table structure level evaluation value and the logical behavior level evaluation value is used as the one-to-one matching degree between the source link and the target link.

[0041] Furthermore, the calculation process of the core table matching degree includes: calculating the intersection size between the source data table included in the operation node of a source link that belongs to the core table set and the target data table included in the operation node of a target link that belongs to the core table set, and dividing the intersection size by the size of the source data table set to obtain the core table matching degree between the source link and the target link.

[0042] Furthermore, the target achievement algorithm is specifically as follows:

[0043] Obtain all one-to-one matching degrees between the requirement data flow link and each candidate code data flow link, and calculate the average value; compare the average value with the preset coverage threshold, and take the smaller value of the two as the implementation coverage of the requirement data flow link;

[0044] The final implementation coverage of the technical design document is obtained by summing the smaller values ​​of the implementation coverage of each requirement data flow link and the corresponding coverage threshold, and then dividing by the sum of all coverage thresholds.

[0045] Furthermore, in S5, the "idleness" index includes the total number and total duration of temporary absence behavior, drowsy behavior, and blank staring behavior; the temporary absence behavior refers to the absence of a face for a continuous period of time within the preset head dynamic reasonable area, or the detection of a face but the center point of its head continuously deviates from the head dynamic reasonable area.

[0046] Furthermore, S5 includes:

[0047] Video frames are extracted from behavioral video data at time intervals, and facial feature point detection is performed on each video frame to locate the coordinates of key points of the eyes, mouth and nose tip.

[0048] The dynamic reasonable area of ​​the head is calculated based on the coordinates of the key points;

[0049] If no face is detected within the first consecutive time period, or if a face is detected but the center point of its head continues to deviate from the dynamic reasonable area, then a temporary departure behavior is determined to have occurred.

[0050] Drowsiness is determined by the eye aspect ratio approaching zero or the head movement acceleration showing fluctuations that conform to periodic nodding characteristics in multiple consecutive frames.

[0051] A blanking behavior is determined to occur if the average value of head motion acceleration in multiple consecutive frames is lower than the blanking threshold and the proportion of low acceleration frames is higher than the proportion threshold.

[0052] The number and duration of time spent away from home, dozing off, and daydreaming are accumulated to obtain the number of times and duration of time spent daydreaming.

[0053] Furthermore, the calculation of the dynamic reasonable region of the head based on the key point coordinates includes:

[0054] Based on the correspondence between the image coordinates of the midpoint of the line connecting the outer canthi of both eyes and the coordinates of the screen center, an affine transformation matrix from the image coordinate system to the screen coordinate system is established.

[0055] Based on the affine transformation matrix and the preset safety factor, calculate the mapped width and height of the facial region in the screen coordinate system;

[0056] Based on the mapping width, height, and screen size, the dynamic boundary coordinates of the reasonable area in front of the screen are calculated.

[0057] Furthermore, S6 includes:

[0058] The first scoring item is calculated based on the ratio of the number of times someone goes astray to the threshold number of times someone goes astray.

[0059] The second scoring item is calculated based on the ratio of the time spent in the small divergence phase to the total iteration time.

[0060] The final coverage will be used as the third scoring item.

[0061] The difference between 1 and the overachievement rate is used as the fourth scoring item;

[0062] The focus score is obtained by weighting and summing the first, second, third, and fourth rating items and then normalizing the sum.

[0063] The corresponding focus level is determined based on the numerical range of the focus score.

[0064] Secondly, the present invention proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above for detecting focus during R&D iteration work.

[0065] Thirdly, a computer electronic device, including a memory and a processor;

[0066] The memory is used to store computer programs;

[0067] The processor is configured to, when executing the computer program, implement the method described above for detecting focus during R&D iteration work.

[0068] The beneficial effects of this invention are:

[0069] This invention uses methods such as parsing design documents, extracting code changes, analyzing control flow, and identifying database operations to uniformly model the functional and data relationships in the design documents with the control flow and database operation behaviors in the code changes, forming comparable requirement links and code links. Based on the matching of the two, it achieves automated detection of design consistency, thereby more effectively identifying design omissions, implementation deficiencies, and implementation content that exceeds the design scope.

[0070] This invention transforms design implementation into quantifiable and comparable metrics by calculating the final implementation coverage of design documents and the over-implementation rate of code. This reduces reliance on manual code review experience and improves the automation, efficiency, and coverage of the detection process. Simultaneously, by collecting and analyzing video data of R&D personnel's behavior, facial feature information is extracted to calculate an inattentiveness index. Finally, by combining the above design implementation metrics and process behavior metrics, a focus score for this R&D iteration is generated, outputting a unified comprehensive detection result. This overcomes the problem of the disconnect between code detection and process status detection in existing technologies.

[0071] This invention conducts joint detection and comprehensive analysis of the focus of R&D iteration work from the dimensions of design implementation and process status of R&D iteration tasks. It can reflect whether the iteration tasks are achieved according to the design requirements, and whether the work is continuously effective during the iteration process. It comprehensively, continuously and objectively characterizes the focus of R&D iteration work, and has good practical value and promotion significance. Attached Figure Description

[0072] Figure 1 This is a flowchart illustrating a method for detecting focus during R&D iteration work;

[0073] Figure 2 This is a schematic diagram illustrating the calculation process of the final implementation coverage of the technical design document and the over-implementation rate of the current code;

[0074] Figure 3 This is a schematic diagram of the one-to-one matching degree calculation process;

[0075] Figure 4 This is a schematic diagram of the core table evaluation process;

[0076] Figure 5 This is a schematic diagram illustrating the calculation process for the final implementation coverage of the technical design document;

[0077] Figure 6 This is a schematic diagram illustrating the calculation process of the overimplementation rate of the current code;

[0078] Figure 7 This invention provides a schematic diagram of the composition of a computer electronic device. Detailed Implementation

[0079] The present invention will be further described and illustrated below with reference to specific embodiments. The embodiments described are merely examples of the content of this disclosure and do not limit the scope of the invention. The technical features of each embodiment in the present invention can be combined accordingly, provided that there is no mutual conflict.

[0080] The accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. Some of the block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0081] The flowchart shown in the attached diagram is merely an illustrative example and does not necessarily include all steps. For example, some steps may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0082] This invention proposes a method for detecting focus during R&D iterations. This method is used to assess the fluctuation of focus among specific R&D personnel within their individual baseline competence. Its basic assumption is that for a given individual, their technical skills and business understanding are relatively stable constants within short-term iterations. Under this premise, focus is assessed in conjunction with the quality of their work output.

[0083] like Figure 1 As shown, a method for detecting focus during R&D iteration work includes the following steps S1 to S6, wherein... Figure 2 This is a schematic diagram illustrating the implementation process of S1 to S4.

[0084] S1. Obtain technical design documents, current code, and historical code during the R&D iteration process.

[0085] Technical design documents refer to design specifications generated in the early stages or during the R&D iteration process, used to define system functions and data structures, and presented in a standardized graphical language (such as use case diagrams).

[0086] The current code refers to the executable source code written and submitted by developers in this iteration based on the technical design document. It specifically refers to the code that implements the functions and data operations in the design document, especially the code involving database interaction and core business logic.

[0087] S2. Analyze the technical design document and generate the requirement data flow chain.

[0088] The technical design document is parsed to obtain use case diagrams and entity relationship diagrams. Use case diagrams describe the system's functional requirements, showcasing the interactions between actors (such as ordinary users and administrators) and system functions (use cases), as well as the expansion and inclusion relationships between use cases. Entity relationship diagrams, parsed from the use case diagrams, describe the system's data model, showing the core entities in the business (such as tables), entity attributes, and the relationships between entities.

[0089] In one specific embodiment of the present invention, one implementation process of S2 is as follows:

[0090] S21, Analyze the use case diagram obtained from the technical design document. The use case diagram consists of vertices composed of actors and use cases, and directed edges between vertices.

[0091] In this embodiment, the use case graph is parsed using mermaid.js to obtain its inherent graph structure data, outputting JSON format data containing a set of vertices and a set of directed edges. The parsed result is formally defined as a directed graph G = (V, E), where the vertex set V is the union of the participant set A and the use case set U, i.e., V = A ∪ U. The edge set E contains directed edges between vertices, representing the association or inclusion relationship between participants and use cases. For example, the use case graph of a user authentication system design document would contain nodes such as "regular user," "login," and "register," along with their associated edges.

[0092] S22, enumerate all simple paths from each participant vertex to each use case vertex to obtain multiple functional paths.

[0093] Functional path is represented as A simple path is defined to satisfy both of the following conditions:

[0094] Continuity condition: There must be a directed edge directly connecting any two adjacent vertices in the path to ensure that the path is actually walkable in the graph.

[0095] Simplicity condition: No duplicate vertices are allowed in the path to avoid loops or redundant detours.

[0096] In this embodiment, a recursive algorithm is used to enumerate all paths from each participant vertex to each use case vertex that satisfy the above conditions. The algorithm aims to find all simple paths from the starting vertex v to the ending vertex w. If the starting vertex v equals the ending vertex w, the path is a sequence containing the vertex itself. If the starting vertex does not equal the ending vertex, all neighboring vertices u of the starting vertex v (i.e., vertices directly reachable from v by edges) are obtained. The set of vertices S that have already been visited and the current vertex v itself are excluded. For each neighboring vertex u that has not been excluded, all paths from u to the ending vertex w are recursively calculated. The current vertex v is used as a prefix and connected to each recursively obtained path to form a new path from v to w. Each participant node and each use case node in the graph is traversed, and all simple paths from that participant to that use case are calculated. The union of the path sets calculated for all participant-use case pairs is taken to obtain the set of functional paths F that covers all possible interaction scenarios in the use case graph.

[0097] S23, parse the technical design document to obtain an entity relationship diagram, which consists of an entity set, an attribute set, and the relationships between entities.

[0098] The entity-relationship diagram described using PlantUML class diagram syntax after parsing is simply called an ER diagram. For example, Table 1 below shows an ER diagram:

[0099] Table 1

[0100]

[0101] Table 1 shows the definition of two entities (data tables) and the relationship between them. Entity A is represented by class A, which defines two attributes: aId (of type Long) and name (of type String). Entity B is represented by class B, which defines three attributes: bId (of type Long), name (of type String), and aId (of type Long). The relationship between the two entities is that one entity A can be associated with multiple entities B.

[0102] The PlantUML class diagram syntax described above is parsed into a structured form through a structured information extraction process based on regular expression pattern matching. This process can be divided into four sub-steps:

[0103] (1) Input an ER diagram described in PlantUML format. Three sets of predefined regular expression patterns are used for precise parsing:

[0104] Class name pattern: used to extract entity names, optional descriptive text, and aliases.

[0105] Attribute pattern: Used to extract the visibility, data type, and field name of each attribute from the class definition block.

[0106] Relational schema: used to resolve the relationships between entities, extract source entities, target entities, relationship types (such as association, inheritance, etc. represented by arrow symbols), and cardinality constraints (such as "1" --> "many").

[0107] A single entity can be defined as {attribute name, attribute data type, relation}.

[0108] (2) Constructing the entity and attribute set

[0109] Entity collection E: Apply class name pattern matching to create an entity object for each data table in the diagram. , The object contains a unique identifier. ,name and description All entities constitute a set. .

[0110] Attribute set A: Apply attribute patterns to match the definition block of each entity and extract all attributes contained in that entity. Each attribute Includes attribute name and data types Ultimately, attribute set A is the set of all the relationships between each entity and all its attributes. .

[0111] (3) Construct a set of entity relations (A.2.1.3)

[0112] Relation sets (R): Apply relation schema matching to all relation statements in the graph, and each relation is extracted as a tuple. ,in It is the source entity. Let be the target entity, 'r' be the relation type, and 'c' be the cardinality constraint. All relations constitute the set R.

[0113] (4) Generate a data model and calculate the correlation.

[0114] Based on the above results, a complete triplet data model M = (E, A, R) representing the ER diagram structure is obtained, where E is the entity set, A is the attribute set, and R is the relation set. Entities and their attributes constitute the data table.

[0115] Taking the library management system as an example, E={book, author, member, borrowing record}, ​​each entity has a unique identifier and description, such as e1=(id1, book, book entity), e2=(id2, author, author entity)...., each entity has its corresponding attributes. Taking the book entity as an example, the data table is represented as {(book, identifier, string (20)), (book, title, string (100)), (book, publication year, integer), (book, author number, string (20)) / / foreign key attribute}, there are relationships between entities, such as relationship 1: author writes book (author→book), then r1=(author, book, write, one-to-many), and the complete set M=(E,A,R) can be obtained.

[0116] Based on the relation set R, calculate the in-degree (the number of times the table is joined) of each entity, i.e. It counts how many other entities point to this entity through relationships; this quantitative metric is used in subsequent steps to assess the importance or coreness of the table.

[0117] S24, associate the functional path with the entity relationship diagram to generate multiple requirement data flow links.

[0118] Information fusion and demand data flow link generation are performed based on a large language model. The nodes of the demand data flow link include data tables extracted from the entity relationship diagram and operation types derived from the functional path.

[0119] In this embodiment, the implementation process based on the large language model can be divided into three stages: the set of functional paths obtained from input S22 and the triplet model obtained from S23. The design prompts utilize the large language model as a design understanding and logical reasoning engine, whose task is to transform abstract, structured design elements into concrete, sequential database operation instructions. The large model needs to understand the business intent represented by each functional path and, combined with the data structure defined by the triplet data model M, deduce the logically ordered sequence of database operations necessary to implement that business function.

[0120] In this embodiment, one optional prompt word content is shown in Table 2:

[0121] Table 2

[0122]

[0123] For example, for the function of a user placing an order, the model needs to infer that it may first need to "query" product inventory and user information, then "add" an order record, and then "update" the inventory quantity, etc. Ultimately, the output of the large model inference is formatted as a set of demand data flow links (LD=LD1, LD2, ..., LD...). n ), each demand link LDn An operation pipeline is formed by connecting multiple first operation nodes arranged in the design order. Each first operation node is an operation unit, containing the operation table name and the specific operation type. The table name indicates which data entity the operation targets; the operation type indicates the type of database operation, i.e., query, add, update, or delete. These operation types are derived from the business logic of the functional path. For example, a requirement data flow chain is: Node 1 (TableA query operation, TableB query operation) -> Node 2 (TableC add operation) -> Node 3 (TableD update operation) -> Node 4 (TableE delete operation). Here, TableA, TableB, TableC, TableD, and TableE come from E in M, referring to the specific data table names.

[0124] The demand data flow chain obtained above can be formally described as follows: , represented as a set of m first operation nodes An ordered sequence constructed sequentially, where each first operation node is a tuple. It contains a table object. and an operation type The tables appearing in all the demand links constitute the demand table sequence. All the operation types that appear constitute the required operation sequence. .

[0125] S3. Generate code data flow links based on the differences between the current code and historical code.

[0126] This step reverse-engineers all the data table operation logic contained in the actual code commits and transforms it into a structured code-data flow link (LC) that can be compared with the design requirements.

[0127] In one specific embodiment of the present invention, one implementation process of S3 is as follows:

[0128] S31. Obtain the differences between the current code and the historical code;

[0129] Call the REST API of a version control system (such as GitLab or GitHub) to retrieve the code commits of the current iteration based on the project ID and commit SHA. Benchmark submissions from the previous iteration The source code file is represented as:

[0130]

[0131]

[0132] in, These are the historical source code and the current source code, respectively, as a combination of different code; path is the path to the target file, P is the project ID, and GetFileContent(.) is the operation to extract the source code file.

[0133] S32. Parse the difference code combination into an abstract syntax tree, and convert the abstract syntax tree into a control flow graph.

[0134] First, use a language-specific parser (such as Eclipse JDT) to parse the source code file into an AST, capturing the syntactic structure of the code.

[0135] Then, the abstract syntax tree (AST) is converted into a control flow graph using a predefined transformation function. The CFG consists of a basic block B and a conditional control flow edge W. Represents the set of basic blocks. For the i-th basic block, Let L represent the set of labeled edges, where L is the set of transition condition labels, and each edge... Corresponding from basic blocks arrive The transfer, and the transfer conditions are determined by the label. describe.

[0136] The process of converting an Abstract Syntax Tree (AST) into a Control Flow Graph (CFG) mainly involves two steps:

[0137] (1) Basic Block Identification. Taking the root node of the AST as input, the continuous code statements are divided into indivisible basic blocks by traversing the AST nodes in postorder. The partitioning rules are: sequentially executed statements (such as assignments, expressions, etc.) are aggregated into the same basic block; once a control flow statement (such as if, for, while, etc.) or jump statement (such as return, break, continue, etc.) is encountered, the current block is terminated immediately, and a new basic block is created starting from the control flow node. Finally, a set of basic blocks organized in execution order is output.

[0138] (2) Control Flow Edge Construction. The set of basic blocks obtained in the previous step is used as node V of the CFG. Then, according to the semantics of the source code, labeled directed edges are added between different types of nodes to describe the flow of program execution. The rules include: adding sequential edges labeled true between consecutive basic blocks; creating conditional edges for if statements pointing to true and false branches respectively; and constructing loop edges connecting initialization, condition judgment, loop body, update, and exit blocks for for loops. In addition, special processing is performed for special statements such as continue, break, and try-catch. Specifically, for the continue statement, after the basic block it is in ends, an edge is created that jumps directly from the statement to the condition judgment block of its loop structure; for the break statement, after the basic block it is in ends, an edge is created that jumps directly from the statement to the exit block of its loop or switch statement; for the try-catch statement, edges for normal execution flow and edges for abnormal execution flow are constructed respectively.

[0139] S33. Traverse all execution paths in the control flow graph, extract the structured query language operations in each execution path node, and obtain the initial code operation sequence.

[0140] This step transforms all potential execution paths in the Control Flow Graph (CFG) into a structured set of links representing all possible database access patterns of the program. It mainly includes four steps:

[0141] (1) Path enumeration: First, traverse the entire control flow graph to find all complete execution paths from the program entry node to the exit node. Each path is recorded as a sequence of nodes, along with conditional labels connecting these nodes, i.e. This refers to the path i that needs to pass through from arrive There are nodes, and they satisfy the following conditions: It is the program entry point node. It is the program exit node. It is a node To the node Conditional tags.

[0142] (2) SQL Operation Extraction: For each node on each path, the code statements are scanned, and SQL keywords are matched using regular expressions to identify statements containing database operations. In this embodiment, a regular expression is shown in Table 3:

[0143] Table 3

[0144]

[0145] Once a match is found, the rules are applied to precisely extract the table names and operation types involved in the operation. If a node contains multiple SQL statements, all of them are extracted and saved as the operation set for that node.

[0146] (3) Link Structure Construction: The above information is combined into structured link items. Each link item contains a unique ID and a sequence of nodes that make up the link. Each element in the node sequence records its position in the CFG and the set of operations extracted in the previous step.

[0147] Define link term i as:

[0148]

[0149] The link IDs are numbered in the order of discovery, such as... Node positions use node identifiers from the CFG, such as "node 12" and "node 15". The operation set is obtained from the SQL operation extraction steps.

[0150] (4) Merging and Deduplication: All link items generated in the preceding steps are sorted and optimized, retaining only paths containing at least one SQL operation, and excluding execution flows that are purely logical or have no database interaction. The node sequences of all links and their corresponding operation sets are compared, and links with completely identical node sequences and operations are considered duplicates, retaining only one of them. After filtering and deduplication, all unique link items constitute the CFG link set representing all possible database operation modes of the current code version.

[0151] The above process takes a Control Flow Graph (CFG) as input, scans all nodes to identify code points containing SQL operations, and extracts the table name and operation type—two core elements. Based on the connection order between nodes in the CFG, these discrete database operation nodes are organized into an ordered execution sequence. Finally, all possible operation sequences are merged and deduplicated, removing completely duplicated paths, and outputting a structured set of links. This set records, in standardized JSON format, the nodes traversed by each possible code execution path and all database operations performed at each node. This process will be applied to the control flow graph of older code versions. Control flow graph of the new version code This results in two corresponding outputs: a set of links. With Link Set This set of links is the initial code operation sequence.

[0152] S34. Compare and analyze the initial code operation sequences corresponding to the current code and the historical code to generate multiple code data flow links.

[0153] The nodes in the code data flow chain include data tables and corresponding operations extracted from the structured query language operations of the code. This step is implemented based on a large language model, inputting the database operation sequences of the old and new versions into the LLM, and providing detailed prompts, requiring it to:

[0154] Identify change points: Analyze the addition, deletion, modification, and order adjustment of operations.

[0155] Assess the rationality of the change: evaluate the change from multiple perspectives, including data consistency, business logic, and performance.

[0156] Generate final link: Output an optimized database operation link that represents the final logic of the current submission.

[0157] In this embodiment, one optional prompt word content is shown in Table 4:

[0158] Table 4

[0159]

[0160] Finally, the output of the large model inference is formatted as a set of code-data stream links (LC=LC1, LC2, ...,LC). n Each code data flow link LC n It consists of multiple second operation nodes connected in execution order. Each second operation node contains a set of all database operations at that execution point, including the table name and the specific operation type. The table name indicates which data entity the operation targets, and its extraction occurs during the SQL operation extraction process. The operation type indicates the type of database operation, i.e., query, insert, update, or delete. These operation types are obtained directly from the first keyword (such as SELECT, INSERT INTO, UPDATE, DELETE FROM) extracted directly from the SQL statement in the code through static analysis. For example, a code data flow chain might be: Node 1 (TableA query operation, TableB query operation) -> Node 2 (TableC insert operation) -> Node 3 (TableD update operation) -> Node 4 (TableE delete operation).

[0161] The code data flow chain obtained above can be formally described as follows: , represented as a set of m second operation nodes An ordered sequence constructed sequentially, where each second operation node is a tuple. It contains a table object. and an operation type The tables appearing in all the code data flow links constitute the code table sequence. All the operation types that appear constitute the code operation sequence. .

[0162] S4. Calculate the matching degree between each requirement data flow link and each code data flow link, and based on the matching degree, determine the final implementation coverage of the technical design document and the over-implementation rate of the current code.

[0163] This step first uses rapid similarity scoring to filter candidate code links for each requirement link, obtaining a set of valid links, and then identifies the core data table from all the code. Next, a detailed one-to-one matching degree calculation is performed on each candidate pair, such as... Figure 3 As shown. Finally, based on all one-to-one matching scores, the final implementation coverage of the technical design document and the over-implementation rate of the current code are calculated and aggregated.

[0164] S41. Calculate a fast similarity score based on table coverage matching degree and operation coverage matching degree, filter candidate code links, and obtain a set of effective links.

[0165] To address the computational explosion caused by performing full matching directly, a fast filtering and candidate link extraction method was designed. A fast similarity scoring function was defined to perform preliminary evaluation on any requirement link and a code link. The preliminary evaluation dimensions include:

[0166] Table coverage matching degree The Sørensen-Dice coefficient is used to calculate the intersection ratio of the table sets involved in the two links. The calculation formula is as follows: .

[0167] Operation coverage matching degree The process involves using a predefined pairing similarity function to find the best match in the code chain for each operation in the requirement chain, and then averaging the best matches across all requirement operations. The formula for calculating the pairing similarity function is as follows: ,in It is the i-th operation type in the demand chain. It is the j-th operation type in the code chain. It is an operation type pairing similarity function. If two operation types are exactly the same, the similarity is the highest value of 1; if one operation type is a query and the other is an update (or vice versa), they are considered to be somewhat related and the similarity is 0.5; for all other cases, the similarity is 0.

[0168] For example, for a sequence of demand operations =[SELECT,INSERT,UPDATE] and a sequence of operations. =[SELECT,DELETE,UPDATE,SELECT], Matching of the SELECT operation: σ(SELECT,SELECT)=1.0 (same as operation 1, hereinafter the same), σ(SELECT,DELETE)=0.0 (same as operation 2, hereinafter the same), σ(SELECT,UPDATE)=0.5 (same as operation 3, hereinafter the same), σ(SELECT,SELECT)=1.0 (same as operation 4, hereinafter the same), Best match: max(1.0,0.0,0.5,1.0)=1.0. Matching of the INSERT operation: σ(INSERT,SELECT)=0.0, σ(INSERT,DELETE)=0.0, σ(INSERT,UPDATE)=0.0, σ(INSERT,SELECT)=0.0, Best match: max(0.0,0.0,0.0,0.0)=0.0. The matching values ​​for the UPDATE operation are: σ(UPDATE,SELECT)=0.5, σ(UPDATE,DELETE)=0.0, σ(UPDATE,UPDATE)=1.0, σ(UPDATE,SELECT)=0.5. The best match is: max(0.5,0.0,1.0,0.5)=1.0. The final operation coverage match is... .

[0169] Ultimately, the table coverage matching degree is determined. Matching degree of operation coverage The smaller value in the formula is used to derive a quick similarity score, which is then combined with the difference penalty coefficient. The formula is expressed as:

[0170]

[0171] in, It is the difference penalty coefficient (usually) <0), this embodiment sets .

[0172] For example, when hour:

[0173] .

[0174] If the total number of requirement data flow links and code data flow links exceeds the quantity threshold The algorithm described above is used to calculate a fast similarity score between the requirement data flow link and each code data flow link. Based on the fast similarity score, a Top-K algorithm with heap permutation is used to select the K most similar code links for each requirement link, which are then used as the set of valid links. The K value is dynamically adjusted based on the matching status of each requirement. If a requirement has a clear best match (high score and large difference), fewer candidates are selected. If the requirement matching is ambiguous (multiple code scores are similar), more candidates are selected to avoid omissions. Subsequently, only the matching degree between the requirement data flow link and its corresponding candidate code data flow link is calculated. If the total number of requirement data flow links and code data flow links does not exceed a threshold, all code data flow links are used as the candidate code link set for each requirement data flow link. The threshold can be set according to actual conditions; in this embodiment, it is 150-250.

[0175] The computational logic of the heap replacement algorithm is as follows: First, a min-heap with a capacity of k_range_max is initialized to store the candidate with the highest current score. Next, all code links are traversed, and a fast similarity score is calculated between each code link and the current requirement link. If the heap is not full, the (score, link) pair is directly inserted into the heap; if the heap is full, the top element is replaced only if the current score is higher than the top element (i.e., the minimum score in the current heap). After the traversal, an adaptive decision is made, dynamically determining the actual number of candidates K returned through the auxiliary function DETERMINE_ACTUAL_K. This auxiliary function first checks the sorted candidate score sequence to find if there is a significant score drop between adjacent candidates (e.g., a decrease exceeding 30% of the previous score). If such a drop is found, the value of K is set before the drop; if no obvious drop is found, the function sets a threshold (e.g., 70% of the highest score) and counts the number of candidates with scores not lower than this threshold as a reference for K. The final value of K should not be lower than a preset range. Once the value of K is determined, the top K code links with the highest scores are extracted from the heap as the candidate code link set for that requirement link.

[0176] S42, Core Table Evaluation.

[0177] like Figure 4 As shown, based on the candidate code link set It iterates through all candidate code links corresponding to each requirement link, extracting all table names involved in the code operations and the specific operation types performed on these tables. Based on this raw data, three quantitative features are calculated for each appearing table:

[0178] (1) Frequency of occurrence: Count the total number of times the table appears in all the code links that are traversed. The more frequently a table appears, the stronger its generality and basicity may be.

[0179] (2) Operation score: Weights are assigned and accumulated based on the type of operation performed on the table. The rule is: query operation scores 1 point, and add, update and delete operations score 2 points.

[0180] (3) Number of associations: obtained from step S32.

[0181] To avoid the influence of differences in the dimensions of different features on the analysis results, the Z-score standardization method was used to process the raw data of the three dimensions, transforming them into a standard distribution with a mean of 0 and a standard deviation of 1. Then, the K-means clustering algorithm was applied to analyze all the standardized tables. The algorithm randomly initializes K cluster centers, iteratively calculates the Euclidean distance from each table to each center, and assigns it to the nearest cluster. The cluster centers are then recalculated until the center points converge stably. The characteristics of the tables in each cluster are analyzed, and those that consistently show high values ​​across multiple standardized feature dimensions such as frequency of occurrence, operation score, and number of associations are classified as the core table set. .

[0182] For example, suppose the clustering results are as follows: Cluster 1 (core tables): Tables A and D (high frequency, high score, many associations); Cluster 2: Tables B and E (high frequency, low score, many associations); Cluster 3: Table C (low frequency, high score, moderate number of associations). The tables in Cluster 1 are used as the core table set.

[0183] S43. One-to-one matching degree calculation.

[0184] for A demand data flow link With a code data flow link Extract the core table set from each of the two links. The table is then used to calculate the core table matching degree. Its value is the size of the intersection of the two link core table sets divided by the size of the requirement link core table set, expressed by the following formula:

[0185]

[0186] If the core table matching score is lower than the preset threshold, it is determined that the code severely lacks core design, and this low score will be directly used as the final one-to-one matching score. And terminate it to avoid subsequent invalid calculations.

[0187] For example, targeting The resulting core table set is [User table, Order table], and the demand chain table sequence is [User table, Order table, Product table, Address table]. The linked list has a length of 2; the code lists the linked list sequence as [product table, order table], i.e. The linked list has a length of 1. Therefore: It exists in both requirement path i and code path j, therefore The core table matching degree of the requirement chain and the code chain .like If less than the threshold, then .

[0188] If the core table matching degree meets the standard (higher than or equal to the preset threshold), then proceed to the calculation of the following two evaluation values:

[0189] Table structure level evaluation: The table structure level evaluation value is obtained by taking the arithmetic mean of the comprehensive table coverage matching degree and the core table matching degree. Among them, the comprehensive table coverage matching degree is taken from the calculation result of S41.

[0190] Logical Behavioral Level Evaluation: The logical behavioral level evaluation value is obtained by taking the arithmetic mean of the combined operation coverage matching degree and table sequence matching degree. The operation coverage matching degree is derived from the calculation result of S41. The table sequence matching degree evaluates the consistency of the order in which table names appear in the operation sequence. Its value is obtained by calculating the length of the longest common subsequence of the table name sequences of the two links and then dividing it by the length of the demand chain list. The formula is as follows:

[0191]

[0192] in, This calculates the number of common subsequences, which refers to the number of pairwise table name combinations that appear in both links and have the same relative order. For example, the table sequence of the demand chain list is [User table, Order table, Product table, Address table]. Length of linked list The code linked list's table sequence is [user table, product table, order table], that is... Length of linked list Therefore, we can conclude that: and There are two sets of table names, one in total, existing in both the demand list and the code list. Finally, the table sequence matching degree is obtained. .

[0193] Ultimately, one-to-one matching degree By adopting the shortest-board principle, the minimum value of the structural evaluation value and the logical behavior evaluation value of the above table is taken to ensure that the matching result takes into account both structural integrity and logical correctness.

[0194] S44. Many-to-many matching degree calculation.

[0195] like Figure 5 As shown, the effective link set is first processed in a positive direction, and then the required link is processed in a negative direction. The following code link collection Obtain the demand chain and code link Match score between The calculation result is obtained according to steps S42-S43. Then, regarding the demand chain... Its one-to-one matching degree set with all candidate code links is .

[0196] Final implementation coverage of computational technology design documents: Apply adaptive Top-K filtering to this set again, retain the K most relevant matching scores, and calculate their average. The above average value is compared with a preset coverage threshold. If the average value is lower than the threshold, the requirement is considered not fully met, and the requirement link is then blocked. Implementation coverage The above average value If the average value is higher than or equal to the threshold, the requirement is considered to have been fully met. It is not included in the overall calculation; the coverage threshold is regarded as its achieved coverage. ,Right now .

[0197] The implementation coverage of all requirement links is aggregated to obtain the final implementation coverage. .

[0198] like Figure 6 As shown, the next step is to reverse the processing of the valid link set, for code links... The following demand chain set Get the code link and demand chain Match score between This result also follows the principle of steps S42-S43, but with the code path and requirement path swapped. First, it iterates through all requirement paths corresponding to each code path, extracting all table names and the specific operation types performed on these tables, and then calculates the core table set. Then, the method in S43 is used to calculate the one-to-one matching degree, and the one-to-one matching degree set is... .

[0199] Calculate the overimplementation rate of the current code: for each code link Find the maximum score among all demand links that it matches. This maximum value is compared to the overimplementation threshold. If the maximum value is lower than the threshold, the code link is considered overimplemented, and the counter is incremented by 1. Ultimately, the overall overimplementation rate equals the number of code links identified as overimplemented, divided by the total number of code links.

[0200] S5. Collect behavioral video data of R&D personnel during R&D iterations, and calculate the R&D personnel's "daydreaming" index by analyzing the facial feature information in the behavioral video data.

[0201] This step involves periodically capturing video frames using a camera, extracting facial feature points, and then using coordinate mapping and dynamic analysis to determine behaviors such as momentary absence, drowsiness, and daydreaming. The number and duration of these behaviors are accumulated to obtain an index of absenteeism.

[0202] It should be noted that this invention involves the collection of video data on the behavior of R&D personnel, especially the extraction and analysis of facial feature information. In actual implementation, this invention strictly adheres to the principles of informed consent, minimum necessity, and data security, and complies with relevant laws and regulations. It is not used for any purpose of illegally monitoring employees or infringing on their personal dignity.

[0203] In one specific embodiment of the present invention, one implementation process of S5 is as follows:

[0204] S51. Extract video frames from the behavioral video data at time intervals, perform facial feature point detection on each video frame, and locate the coordinates of key points of the eyes, mouth, and nose tip.

[0205] This invention extracts static image frames from the behavioral video stream captured by the camera at preset fixed time intervals (e.g., every 5 minutes) during system monitoring. Then, for each extracted image frame, a 68-point facial feature point detection model from the Dlib library is applied for processing. This model automatically locates and outputs the two-dimensional coordinates (X, Y) of 68 key points on the face. From these 68 points, based on their predefined numbering ranges, specific subset coordinates representing the eyes (left eye: points 37-42; right eye: points 43-48), mouth (points 49-68), and nose (points 28-36, with the tip of the nose at point 34) are extracted. Each image frame is transformed into a set of structured coordinate data.

[0206] S52. Calculate the dynamic reasonable area of ​​the head based on the key point coordinates of the eyes, mouth and nose tip.

[0207] First, the baseline feature points are located and their coordinates are mapped.

[0208] Based on the facial key points extracted in the previous step, calculate the midpoint EC of the line connecting the outer canthi of the left and right eyes, the tip of the nose NC, and the center point of the corner of the mouth MC.

[0209] The image coordinate system is defined as a 2D coordinate system with the camera imaging plane as the reference, with the origin at the upper left corner, the X-axis horizontally to the right, and the Y-axis downwards; the screen coordinate system has its origin at the center, the X-axis horizontally to the right, and the Y-axis vertically upwards. To achieve the mapping from the camera image to the physical screen, three key facial feature points are selected as references. The primary reference point is the midpoint EC of the line connecting the outer canthi of the two eyes, which is mapped to the center (0, 0) of the screen coordinate system; the vertical reference point is the midpoint MC of the corner of the mouth, which is constrained and mapped to the vertical central axis of the screen (i.e., the vertical line x=0); the auxiliary calibration point is the tip of the nose NC, which is mapped to a virtual projection point in the depth direction of the screen.

[0210] Calculate scaling ratio: Horizontal scaling ratio The vertical scaling ratio is obtained by dividing the physical distance of the screen by the pixel distance ED between the outer canthi of both eyes in the image; It is obtained by dividing the physical height of the screen by the vertical pixel distance MH between the eyes and mouth in the image.

[0211] Calculate translation distance: horizontal translation The difference between the x-coordinate of the screen center point and the x-coordinate of point EC is calculated; a positive value indicates a move to the right, and a negative value indicates a move to the left; vertical translation... It is obtained by calculating the y-coordinates of the screen center point and the EC point.

[0212] Combine the calculated scaling and translation parameters into a 2×3 affine transformation matrix. This matrix can be directly applied to any point (x, y) in the image, mapping it to screen coordinates (X, Y).

[0213] Secondly, the dynamic and reasonable region of the head is generated based on the parameters of the affine transformation matrix.

[0214] The baseline facial dimensions (ED, MH) measured in the image are mapped to screen space using a scaling factor and a safety factor (e.g., horizontal 1.2, vertical 1.5). The face width FW and face height FH of the head mapping area are then calculated. For example: face width FW = pixel distance between the outer canthi of the eyes ED × horizontal scaling factor × safety factor; face height FH = vertical pixel distance between the eyes and mouth MH × vertical scaling factor × safety factor.

[0215] Using the center of the screen as a reference, calculate the maximum vertical, horizontal, and vertical positions of the head center (HC) based on the total screen size. The left limit = face width / 2, the right limit = screen width - face width / 2, the top limit = face height / 2, and the bottom limit = screen height - face height / 2. Based on these limits, the dynamic, reasonable area for the head can be determined, and the area of ​​this region... This is the product of the differences between the two corresponding coordinates. For example, for a screen size of 1080×1920, the affine transformation matrix... With ED=100px and MH=150px, the face width is 240px and the face height is 405px. The left and right limits represent the range of horizontal movement, i.e., 120~960px; the top and bottom limits represent the range of vertical movement, i.e., 202.5~1717.5px. This gives the dynamic reasonable area of ​​the head. Only when the real-time center point HC of the head falls within the above dynamic reasonable area is the posture considered correct.

[0216] S53. Calculate head motion acceleration based on head position coordinates, and extract the mean head acceleration, standard deviation of head acceleration, and proportion of low head acceleration frames.

[0217] The center point HC of the head in the current frame is calculated in real time, with coordinates (HC.x, HC.y), where HC.x = left limit + face width / 2, and HC.y = upper limit + face height / 2.

[0218] Within a set time interval (e.g., every 10 seconds), acquire the head's center point HC corresponding to a series of time points, calculate the displacement difference between adjacent time points, and divide by the time interval to obtain the instantaneous velocity of the head in the x and y directions. Subtract the velocity of the previous moment from the current velocity and divide by the time interval to obtain the instantaneous acceleration of the head in the x and y directions. The resultant acceleration is a scalar value. .

[0219] Based on the synthetic acceleration sequence within a time window, the mean head acceleration, the standard deviation of head acceleration, and the proportion of low-acceleration frames in the head are extracted. The proportion of low-acceleration frames in the head is obtained by statistically analyzing the proportion of time when the acceleration is below a certain threshold, reflecting the proportion of time in a static or slightly moving state. If the standard deviation of head acceleration is higher than the threshold, it indicates that the acceleration fluctuates violently.

[0220] S54. Calculate the aspect ratio of the eyes based on the coordinates of key eye points.

[0221] At more precise time intervals (e.g., every 10 seconds), drowsiness is monitored by calculating the eye aspect ratio. The EAR value is calculated based on the geometric relationship of six feature points of the eye (37-42 points for the left eye and 43-48 points for the right eye). When the eyes are open, the EAR value remains relatively stable; when the eyes are closed, the distance between the upper and lower eyelids approaches zero, causing the EAR value to drop sharply and approach 0. By monitoring changes in the EAR value over a period of time, persistent eye-closing behavior can be identified.

[0222] S55. By comprehensively evaluating the frequency and duration of absenteeism, drowsy behavior, and daydreaming behavior, an inattentiveness index is obtained.

[0223] In this embodiment, monitoring is performed within a continuous time window. If t... aNo face was detected within seconds, or a face was detected but the coordinates of the center point HC of its head remained unchanged for t seconds. b If the second does not fall within the dynamic reasonable range, a temporary departure event is recorded and the duration is accumulated.

[0224] If the eye aspect ratio approaches zero (e.g., below the eye-closing threshold) across multiple consecutive frames, or if head motion acceleration exhibits fluctuations consistent with nodding characteristics, then a drowsy behavior event is recorded and its duration is accumulated. Fluctuations in head motion acceleration consistent with nodding characteristics include two scenarios: head acceleration standard deviation... Above the threshold Or, within a set time window, the number of peak periodic head movements detected. Reaching or exceeding the set threshold (For example, 3 times within 5 seconds) is considered a drowsy characteristic of periodic head nodding.

[0225] If the average head acceleration is below the staring threshold Furthermore, the proportion of low-acceleration frames in the head exceeds the proportional threshold. If a blanking behavior event is recorded, the duration will be accumulated.

[0226] Statistically analyze the occurrence of minor deviations throughout the entire iteration cycle, including the number of minor deviations. It is the sum of the number of times the three types of behavior—temporary absence, dozing off, and daydreaming—occur; the duration of inattentiveness. It is the sum of the duration of these three types of behavior.

[0227] This invention utilizes existing technologies such as camera image acquisition, facial key point extraction, head image position detection, and temporal behavioral feature analysis, combined with multi-dimensional features such as head image center positioning, visible area mapping, closed eye features, and head movement acceleration, to jointly detect whether the target in front of the terminal is in a reasonable working area and whether there are abnormal focused states such as staring or dozing off. Compared with methods that rely solely on keyboard and mouse events or simple face presence detection, this invention has higher detection accuracy and a lower false positive rate.

[0228] S6. Based on the final implementation coverage of the technical design document, the over-implementation rate of the current code, and the distraction index, calculate the focus score of the R&D personnel in this iteration.

[0229] Calculate the number of times you daydream and score the points. , It is the threshold for the number of times someone might dart away from their destination.

[0230] Calculate the score for the time spent daydreaming , These are the iteration start time and iteration end time, respectively.

[0231] Calculate the final coverage score Here, the final implementation coverage of the design document is used directly to represent its score;

[0232] Current overrealization rate score Here, the score is represented by the difference between 1 and the overimplementation rate of the current code.

[0233] Multiply the four scores by their respective weights and sum them to obtain a weighted total score. Normalize the weighted total score to a 0-100 percentile range and use it as the focus score.

[0234] In this embodiment, a preset level standard is used for mapping, where 90-100 points represent high focus, 70-89 points represent medium focus, 50-69 points represent need for improvement, and below 50 points represent low focus.

[0235] It is understood that the method for detecting focus on R&D iteration work in the above embodiments can essentially be implemented by a computer program. Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer program product corresponding to the method for detecting focus on R&D iteration work provided in the above embodiments, which includes a computer program / instructions. When the computer program / instructions are executed by a processor, they can implement the method for detecting focus on R&D iteration work as described in the above embodiments.

[0236] Similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the method for detecting focus on R&D iteration work provided in the above embodiments, such as... Figure 7 It is shown that it includes memory and processor;

[0237] The memory is used to store computer programs;

[0238] The processor is configured to implement the method for detecting focus on R&D iteration work as described in the above embodiments when executing the computer program.

[0239] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0240] Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the method for detecting focus on R&D iteration work provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, can implement the method for detecting focus on R&D iteration work in the above embodiments.

[0241] It is understood that the computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device of any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of any data processing device. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0242] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A method for detecting focus during R&D iteration work, characterized in that, Includes the following steps: S1. Obtain the technical design documents, as well as the current and historical code of the target R&D personnel during the R&D iteration; S2. Analyze the technical design document and generate multiple requirement data flow links; S3. Generate multiple code data flow links based on the differences between the current code and historical code; S4. Filter candidate code data flow links for each requirement data flow link to obtain a set of valid links; The effective link set is processed in a positive direction. A one-to-one matching method is used to calculate the one-to-one matching degree between each requirement data flow link and each candidate code data flow link. The final implementation coverage of the technical design document is obtained by aggregating the data flow links through the target achievement algorithm. The effective link set is processed in reverse. A one-to-one matching method is used to calculate the one-to-one matching degree between each code data flow link and the corresponding multiple requirement data flow links. If the maximum value of the one-to-one matching degree is lower than the over-implementation judgment threshold, the code data flow link is judged to be over-implemented. The over-implementation rate of the current code is obtained by statistically analyzing the proportion of the number of code data flow links judged to be over-implemented to the total number. S5. Collect video data of the target R&D personnel's behavior during the R&D iteration, analyze the facial feature information in the video data, and calculate the "drifting off" index. S6. Based on the final implementation coverage, over-implementation rate, and distraction index, calculate the focus score of the target R&D personnel during this R&D iteration.

2. The method for detecting focus during R&D iteration work according to claim 1, characterized in that, S2 include: The technical design document is analyzed to obtain a use case diagram and an entity relationship diagram. The use case diagram includes vertices composed of actors and use cases, as well as directed edges between vertices. The entity relationship diagram includes a set of entities, a set of attributes, and the relationships between entities. Entities and their attributes constitute a data table. Based on the use case diagram, enumerate all simple paths from each actor vertex to each use case vertex to obtain the set of functional paths; Based on the large language model, the functional path set and entity relationship diagram are associated to generate the requirement data flow link; each requirement data flow link includes multiple operation nodes arranged in the design order, and the operation node contains the data table involved in the operation and the corresponding operation type.

3. The method for detecting focus during R&D iteration work according to claim 1, characterized in that, S3 includes: Obtain the differences between the current code and the historical code; The difference code is parsed into an abstract syntax tree, and the abstract syntax tree is then converted into a control flow graph; Traverse all execution paths in the control flow graph, extract the database operations in each path node, and obtain the initial code operation sequence; Based on the large language model, the initial code operation sequence corresponding to the current code and the historical code is compared and analyzed to generate code data flow links; each code data flow link includes multiple operation nodes arranged in execution order, and the operation node contains the data table involved in the operation and the corresponding operation type.

4. The method for detecting focus during R&D iteration work according to claim 1, characterized in that, In S4, the process of filtering the set of valid links includes: Calculate the table coverage matching degree and operation coverage matching degree for each requirement data flow link and each code data flow link to obtain a fast similarity score; based on the fast similarity score, apply the Top-K algorithm of heap permutation to dynamically select K candidate code data flow links for each requirement data flow link; The formula for calculating the rapid similarity score is as follows: ； in, It is the demand data flow link and code data flow links Quick similarity scoring, It is the table coverage matching degree. It is the operation coverage matching degree. It is the difference penalty coefficient. It is the absolute value; The calculation process for the table coverage matching degree is as follows: obtain the set of requirement data tables and the set of code data tables from the set of operation nodes of each requirement data flow link and each code data flow link respectively; divide twice the size of the intersection of the two data table sets by the sum of the sizes of the two data table sets to obtain the table coverage matching degree; The calculation process for the operation coverage matching degree is as follows: obtain the set of demand operation types and the set of code operation types from the set of operation nodes of each demand data flow link and each code data flow link respectively; for each demand operation type, determine an optimal matching similarity in the set of code operation types according to a preset pairing rule; take the average of the optimal matching similarities corresponding to the set of demand operation types as the operation coverage matching degree.

5. The method for detecting focus during R&D iteration work according to claim 4, characterized in that, In S4, the one-to-one matching method is used to calculate the one-to-one matching degree between a source link and a target link; when processing the effective link set in the forward direction, the demand data flow link is used as the source link, and the multiple candidate code data flow links corresponding to each demand data flow link are used as the target link; when processing the effective link set in the reverse direction, the candidate code data flow link is used as the source link, and the multiple demand data flow links corresponding to each candidate code data flow link are used as the target link. The one-to-one matching method is specifically as follows: First, iterate through all target links and their associated operation node sets. For each data table in the operation node set, count the frequency of occurrence, the operation score based on the operation type, and the number of associations with other tables. After standardizing the statistical results, perform cluster analysis. Based on the clustering results, determine the data tables contained in the categories that show high values ​​on multiple feature dimensions as the core table set. Extract the data tables belonging to the core table set from the source link and the target link respectively, and calculate the core table matching degree; If the core table matching degree is lower than the core table matching threshold, the core table matching degree will be used as the one-to-one matching degree between the source link and the target link. Otherwise, the table structure level evaluation value is obtained based on the average of the table coverage matching degree and the core table matching degree between the source link and the target link, and the logical behavior level evaluation value is obtained based on the average of the operation coverage matching degree and the table sequence matching degree; the table sequence matching degree refers to the ratio of the number of pairwise table name combinations that appear in both links and have the same relative order to the total length of the table name sequence in the source link. The smaller value between the table structure level evaluation value and the logical behavior level evaluation value is used as the one-to-one matching degree between the source link and the target link.

6. The method for detecting focus during R&D iteration work according to claim 5, characterized in that, The calculation process of the core table matching degree includes: calculating the intersection size between the source data table that belongs to the core table set contained in the operation node of a source link and the target data table that belongs to the core table set contained in the operation node of a target link, and dividing it by the size of the source data table set to obtain the core table matching degree between the source link and the target link.

7. The method for detecting focus during R&D iteration work according to claim 1, characterized in that, The specific algorithm for achieving the target is as follows: Obtain all one-to-one matching degrees between the requirement data flow link and each candidate code data flow link, and calculate the average value; compare the average value with the preset coverage threshold, and take the smaller value of the two as the implementation coverage of the requirement data flow link; The final implementation coverage of the technical design document is obtained by summing the smaller values ​​of the implementation coverage of each requirement data flow link and the corresponding coverage threshold, and then dividing by the sum of all coverage thresholds.

8. The method for detecting focus during R&D iteration work according to claim 1, characterized in that, In S5, the "idleness" index includes the total number and total duration of temporary absence behavior, drowsy behavior, and blank staring behavior; the temporary absence behavior refers to the absence of a face for a continuous period of time within the preset head dynamic reasonable area, or the detection of a face but the center point of its head continuously deviates from the head dynamic reasonable area.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method for detecting focus during R&D iteration work as described in any one of claims 1 to 8.

10. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to, when executing the computer program, implement the method for detecting focus on R&D iteration work as described in any one of claims 1 to 8.

Images