A method and system for tracking the progress of VI design tasks in a school-enterprise collaborative manner

Abstract

This invention relates to the field of project management technology, and discloses a method and system for tracking the progress of VI design tasks in a school-enterprise collaborative context. The method includes: combining the project name and school-enterprise identifier as the project root node; generating and associating task nodes using a VI project template to construct a task structure tree; creating iteration status identifiers based on the node identifiers and timestamps of assigned events; sending requests to the review group based on the review status of the identifiers; updating the current iteration status based on feedback; linking and storing new version files with version files to obtain a version chain; traversing the version files using associated pointers to generate feedback traceability records; and determining layout coordinates and connecting nodes based on the timestamp order and state transition direction to obtain a progress tracking view. This invention can improve the efficiency of tracking the progress of VI design tasks in a school-enterprise collaborative context.

Description

Technical Field

[0001] This invention relates to the field of project management technology, and in particular to a method and system for tracking the progress of VI design tasks in a school-enterprise collaborative manner. Background Technology

[0002] In existing methods for tracking the progress of VI design tasks, university-enterprise collaboration scenarios typically employ general project management tools or simple file sharing for task allocation and version management. These methods lack the ability to construct a task structure tree tailored to the characteristics of VI design projects, failing to organically link project names, university / enterprise logos, and specific task nodes. This results in scattered task node storage and chaotic permission group configurations, making it difficult for the review team to accurately locate pending task nodes and easily leading to incorrect or missed review requests. Furthermore, existing version file storage methods often store files independently, lacking forward and reverse linking mechanisms between versions. When it's necessary to trace the iteration time, review comments, or status changes of a design version, manual comparison of timestamps and storage paths of multiple files is required, a cumbersome and error-prone process that fails to meet the real-time and accuracy requirements of progress tracking in a university-enterprise collaboration environment.

[0003] Furthermore, existing technologies have significant shortcomings in generating visual progress views. Most existing solutions can only display task lists or simple Gantt charts, failing to integrate the submission time sequence of version nodes, the hierarchical depth of task nodes under the project root node, and the direction of state transitions between adjacent versions into a single view. Information such as review comments and iteration time often requires switching between different interfaces or consulting separate documents, making it impossible for project managers to intuitively judge the review status and iteration efficiency of each version. Due to the lack of the ability to automatically calculate horizontal and vertical layout coordinates based on feedback traceability records, existing technologies struggle to generate progress tracking views that simultaneously reflect time evolution, task hierarchy, and version relationships, thus significantly reducing communication efficiency and decision-making accuracy in university-enterprise collaborative VI design tasks. Summary of the Invention

[0004] This invention provides a method and system for tracking the progress of VI design tasks in a school-enterprise collaboration context. Its main purpose is to solve the problem of low efficiency in tracking the progress of VI design tasks in a school-enterprise collaboration context.

[0005] To achieve the above objectives, this invention provides a method for tracking the progress of VI design tasks in a school-enterprise collaborative manner, comprising: The project name and school-enterprise identification of the target process are combined into the project root node, and the project template corresponding to the VI project type identification in the target process is used as the task node. The project root node is associated with the task node to construct the task structure tree of the target process. The status field of the target process is created based on the node identifier and timestamp of the assigned event in the task structure tree, and the iteration status identifier bit of the target process is obtained. Based on the review status of the iteration status flag, a review request is sent to the review group of the role permission group in the task node, and the iteration status flag is updated according to the feedback data of the review group to obtain the current iteration status of the target process. Link and store the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process; Based on the association pointers between adjacent version files in the version chain, the version files are traversed level by level to obtain the feedback traceability record of the target process; The layout coordinates are determined based on the timestamp order of the version nodes in the feedback traceability record, and the nodes are connected according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process.

[0006] In a preferred embodiment, the step of combining the project name and school-enterprise identifier of the target process into a project root node, using the project template corresponding to the VI project type identifier in the target process as a task node, and associating the project root node with the task node to construct the task structure tree of the target process includes: Obtain the project name string and the school-enterprise identification string of the target process, and concatenate the project name string and the school-enterprise identification string into a root node data block to obtain the project root node of the target process; Parse the task configuration items of the VI project type identifier in the target process to obtain the task name, task sequence index and required permission group type of the target process; A task node for the target process is created based on the task name and the task sequence index. The corresponding role permission group is obtained from the collaborative project information of the target process based on the required permission group type, and the role permission group is associated with the corresponding task node. Based on the task sequence index, the node identifiers of the task nodes are added to the child node identifier list of the project root node in sequence, and a parent node pointer pointing to the project root node is set for the task node to obtain the task structure tree of the target process.

[0007] In a preferred embodiment, the step of creating a status field for the target process based on the node identifier and timestamp of the assigned event in the task structure tree, and obtaining the iteration status identifier bit of the target process, includes: Read the nodes with assigned event tags from the task structure tree to obtain the node identifier and generation timestamp of the node in the target process; The node identifiers are filled with a fixed length to obtain the identifier segment of the target process, and the generated timestamp is converted into a timing value starting from the start time to obtain the time period of the target process; The identifier segment and the time period are concatenated in chronological order to obtain the status subfield of the target process; According to the preorder traversal order of the nodes in the task structure tree, the state subfields are concatenated end to end to obtain the iterative state identifier of the target process.

[0008] In a preferred embodiment, the step of sending an audit request to the audit group of the role permission group in the task node based on the audit status of the iteration status identifier bit, and updating the iteration status identifier bit according to the feedback data of the audit group to obtain the current iteration status of the target process, includes: Based on the iteration status flag, locate the task node corresponding to the flag that the review status is pending, and read the communication address list of the review group from the role permission group configuration information of the task node; The node identifier, file fingerprint, and current time of the task node are used as the audit request data packet for the target process and sent to the communication address list respectively. The feedback data of the audit group is received based on the audit request data packet. The feedback data includes an audit conclusion field and a feedback time field. The audit result of the target process is determined based on the audit conclusion distribution in the feedback data, and the corresponding bit in the iteration status identifier is updated to the value corresponding to the resolved status based on the audit result, so as to obtain the current iteration status of the target process.

[0009] In a preferred embodiment, linking and storing the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process includes: Based on the task node, determine the storage path and version number of the version file, and write the current iteration status into the custom attribute field of the new version file in plain text form; Write a backlink field at the end of the new version file, the content of which is the storage path of the version file; Write a forward link field in the header of the version file, the content of which is the storage path of the new version file; By associating the backlink field with the forward link field, a version chain of the target process is obtained.

[0010] In a preferred embodiment, the step of traversing the version files level by level based on the association pointers between adjacent version files in the version chain to obtain the feedback traceability record of the target process includes: Starting from the first pointer in the node pointer sequence of the version chain, read the version files pointed to by the pointers in sequence to obtain the submission timestamp, associated review comments, and iteration round number of the version files in the target process; Calculate the iteration time between adjacent version files in the version chain, and assemble the version identifier of the version file, the submission timestamp, the associated review comments, the iteration round number, and the iteration time into a feedback traceability record item for the target process according to the traversal order; The feedback traceability records are arranged in version order to obtain the feedback traceability records of the target process.

[0011] In a preferred embodiment, the formula for calculating the iteration time includes: in, For the first Version 1 and 2 Iteration time between versions This represents the iteration round number. For the first The commit timestamp of each version file For the first The commit timestamp of each version file This is the overall magnification factor. For the iterative round exponent, Sensitivity coefficient for the length of review comments. For the first The number of characters in the review comments text associated with each version file. It is a logarithmic modulation function. It is a natural constant. Steepness coefficient, The threshold for the inflection point round, The influence coefficient of the review team. For the first The sum of the frequencies of preset keywords in the review comments text associated with each version of the file. For the first The total number of members who participated in the review when each version file was submitted. This refers to the keyword frequency index. This is the membership index.

[0012] In a preferred embodiment, determining the layout coordinates based on the timestamp order of the version nodes in the feedback traceability record, and connecting the nodes according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process, includes: The commit timestamps of the version nodes in the feedback traceability record are sorted sequentially to obtain the timestamp sequence of the target process; The ratio of the horizontal pixel width of the target process view to the total number of timestamps in the timestamp sequence is used as the horizontal coordinate interval of the target process; Based on the sorting position of the submission timestamp in the timestamp sequence, the product of the sorting position and the horizontal coordinate interval is used as the horizontal layout coordinate of the target process; Based on the task node identifier of the feedback traceability record, the hierarchical depth starting from the project root node of the target process is used as the vertical layout coordinate of the target process; By connecting the version nodes based on the transition directions of adjacent versions in the feedback traceability record, a progress tracking view of the target process is obtained.

[0013] In a preferred embodiment, the step of connecting the version nodes based on the transition directions of adjacent versions in the feedback tracing record to obtain the progress tracking view of the target process includes: Connect adjacent version nodes in the version node sequence of the feedback traceability record in chronological order to obtain the directed edges of the target process; The state transition direction of the target process is determined based on the starting and ending layout coordinates of the directed edge. The iteration time between adjacent version nodes in the feedback traceability record is converted into time text labels and marked at the midpoint of the directed edge; The review comments text of the version node are marked as additional information on the side of the corresponding version node in the progress tracking view of the target process.

[0014] To address the aforementioned problems, this invention also provides a VI design task progress tracking system for university-enterprise collaboration, the system comprising: The task structure tree module combines the project name and school-enterprise identification of the target process into a project root node, takes the project template corresponding to the VI project type identification in the target process as a task node, and associates the project root node with the task node to construct the task structure tree of the target process. The iteration status module creates a status field for the target process based on the node identifier and timestamp of the allocated event in the task structure tree, and obtains the iteration status identifier bit of the target process; The current status module, based on the review status of the iteration status identifier, sends a review request to the review group of the role permission group in the task node, and updates the iteration status identifier according to the feedback data of the review group to obtain the current iteration status of the target process; The version chain module links and stores the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process; The feedback traceability record module traverses the version files level by level based on the association pointers between adjacent version files in the version chain to obtain the feedback traceability record of the target process; The progress tracking view module determines the layout coordinates based on the timestamp order of the version nodes in the feedback traceability record, and connects the nodes according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process.

[0015] Compared with the prior art, the present invention has the following beneficial effects:

[0016] 1. By constructing a task structure tree containing the project root node and task nodes, and combining the iteration status flag with the bidirectional link field of the version chain, this method achieves full-process automatic tracking of VI design task progress. The parent-child node pointers and child node identifier list in the task structure tree allow any task node to be quickly located to the project root node. The iteration status flag, connected end-to-end by the preorder traversal order and the status subfield, compresses the identifier and time information of each assigned task node into a single continuous field, facilitating storage and parsing. The forward and reverse link fields in the version chain are interconnected, allowing traversal of all historical versions from any version file along the bidirectional pointers without relying on external index tables. The automatically calculated horizontal and vertical layout coordinates based on feedback traceability records ensure that the position of each version node in the progress tracking view strictly corresponds to its submission time order and task hierarchy depth, achieving a fusion display of the time dimension and task structure.

[0017] 2. This method significantly improves the closed-loop efficiency of the review process and the readability of version information. The pending status positioning mechanism in the iteration status identifier ensures that review requests are only sent to a list of communication addresses with review authority. The review conclusion distribution in the feedback data directly updates the iteration status identifier to the resolved status after a majority vote, ensuring the real-time nature and accuracy of the current iteration status. The new version file header contains the current iteration status in plain text and the tail contains a backlink field, while the version file header contains a forward link field, enabling the version file itself to carry complete iteration status and related information between previous and subsequent versions. In the feedback traceability record, the iteration time between adjacent version nodes is converted into time text labels and marked at the midpoint of the directed edge. The review comments text is marked as additional information for the node and is located to the side of the version node. This allows the version evolution path, iteration time, review feedback, and status change direction to be presented simultaneously in the same progress tracking view, providing project managers with an intuitive, complete, and interactive progress monitoring interface. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a method for tracking the progress of VI design tasks in a school-enterprise collaborative manner, as provided in an embodiment of the present invention.

[0019] Figure 2 This is a functional block diagram of a VI design task progress tracking system for school-enterprise collaboration provided in an embodiment of the present invention;

[0020] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0022] This application provides a method for tracking the progress of VI design tasks in a school-enterprise collaborative environment. The execution entity of this method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the method for tracking the progress of VI design tasks in a school-enterprise collaborative environment can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0023] Reference Figure 1 The diagram shown is a flowchart illustrating a method for tracking the progress of a VI design task in a school-enterprise collaboration context according to an embodiment of the present invention. In this embodiment, the method for tracking the progress of a VI design task in a school-enterprise collaboration context includes: In this embodiment of the invention, the step of combining the project name and school-enterprise identifier of the target process into a project root node, using the project template corresponding to the VI project type identifier in the target process as a task node, and associating the project root node with the task node to construct the task structure tree of the target process is specifically used for: Obtain the project name string and the school-enterprise identification string of the target process, and concatenate the project name string and the school-enterprise identification string into a root node data block to obtain the project root node of the target process; Parse the task configuration items of the VI project type identifier in the target process to obtain the task name, task sequence index and required permission group type of the target process; A task node for the target process is created based on the task name and the task sequence index. The corresponding role permission group is obtained from the collaborative project information of the target process based on the required permission group type, and the role permission group is associated with the corresponding task node. Based on the task sequence index, the node identifiers of the task nodes are added to the child node identifier list of the project root node in sequence, and a parent node pointer pointing to the project root node is set for the task node to obtain the task structure tree of the target process.

[0024] Specifically, when obtaining the project name string and the school-enterprise identification string of the target process, the system reads the VI design project name text entered by the user from the project creation interface, and at the same time extracts the pre-stored school-enterprise cooperation identification code from the currently logged-in enterprise account information.

[0025] Specifically, when parsing the task configuration items of the VI project type identifier during the target process, the system reads the task configuration data from the corresponding project template file pre-stored in the template library based on the VI design project type selected by the user during the project initialization phase. The task configuration data contains multiple fields, from which the system extracts the name text of each task, the task execution order index value, and the permission group type identifier required to complete the task.

[0026] Specifically, when creating task nodes for the target process based on the task name and task sequence index, the system generates a unique node identifier for each task and stores the task name text as the node's display name attribute. The system creates task node objects sequentially in ascending order of task sequence index values, with each task node object occupying an independent data block in memory.

[0027] Specifically, based on the task sequence index, the system iterates through all created task nodes and adds the node identifier of each task node to the child node identifier list of the project root node in ascending order of task sequence index value. The child node identifier list is a dynamic array, which the project root node uses to record the identifiers of all its directly subordinate task nodes.

[0028] Furthermore, the system directly concatenates the project name string and the school-enterprise identification string together in the order of project name first, followed by school-enterprise identification, to form a complete root node data block. This root node data block, as the unique identifier of the project root node, is stored in the node data structure in memory, thus generating the project root node.

[0029] Furthermore, the task name text is used as a display label when creating nodes later, the task order index value determines the order of tasks in the structure tree, and the required permission group type identifier indicates which roles have permission to operate the task node.

[0030] Furthermore, based on the required permission group type, the system searches for a matching permission group object in the pre-configured role permission group mapping table within the collaborative project information. Each permission group object contains a set of role identifiers and corresponding operation permission bits. The system then assigns the reference address of the found role permission group object to the permission group field in the task node object, completing the association.

[0031] Furthermore, the system simultaneously sets a parent node pointer for each task node, which points to the project root node. The parent node pointer stores the memory address of the project root node. After completing the addition of child node lists and setting parent node pointers for all task nodes, the system organizes the project root node and all task nodes into a complete task structure tree.

[0032] In summary, by directly concatenating the project name with the university-enterprise logo to form a unique root node data block, each VI design project possesses a unique and identifiable identity from the outset, avoiding node confusion between different companies or projects. This root node, serving as the top-level anchor point of the task structure tree, provides a stable root address for the mounting and tracing of all subsequent task nodes, thereby ensuring data consistency and root node location within the entire task tracking system.

[0033] In summary, by parsing the task configuration items corresponding to the VI project type identifier, the system can automatically extract the task names, execution order, and permission group requirements for each task required to complete the VI design of that type, eliminating the need for manual configuration. This automated parsing method significantly reduces the manpower cost of project initialization while ensuring the standardization and reusability of task templates, providing a unified task decomposition basis for different university-enterprise cooperation projects.

[0034] In summary, by dynamically associating each task node with a predefined role and permission group, task execution permissions are decoupled from node creation. This mechanism ensures that only the review group or executor with the corresponding role permissions can operate the corresponding task node, thus embedding access control capabilities into the task structure tree. This effectively prevents unauthorized operations or cross-role interference, improving the security and standardization of VI design task flow.

[0035] In summary, by establishing parent-child references between the project root node and task nodes, a complete directed tree structure is formed, making the hierarchical relationship and execution order of the entire VI design task flow clear at a glance. The list of child node identifiers supports quick traversal of all tasks, while the parent node pointer allows traversal from any task node back to the project root node, providing an efficient data organization foundation for subsequent status tracking, version association, and progress view generation.

[0036] In this embodiment of the invention, when creating the state field of the target process based on the node identifier and timestamp of the allocated event in the task structure tree to obtain the iteration state identifier bit of the target process, it is specifically used for: Read the nodes with assigned event tags from the task structure tree to obtain the node identifier and generation timestamp of the node in the target process; The node identifiers are filled with a fixed length to obtain the identifier segment of the target process, and the generated timestamp is converted into a timing value starting from the start time to obtain the time period of the target process; The identifier segment and the time period are concatenated in chronological order to obtain the status subfield of the target process; According to the preorder traversal order of the nodes in the task structure tree, the state subfields are concatenated end to end to obtain the iterative state identifier of the target process.

[0037] Specifically, when reading nodes with assigned event flags from the task structure tree, the system iterates through all task nodes in the task structure tree and checks whether each node has an assigned event flag field. The assigned event flag field is a boolean value written by the system when a task node is created or a task is assigned. When the task corresponding to a node has been assigned to a specific executor, this flag field is set to true.

[0038] Specifically, when padding node identifiers to a fixed length, the system reads the original string of the node identifier for each node assigned an event tag. The system predefines a uniform fixed length value, sufficient to accommodate the maximum possible length of all possible node identifier strings. If the original string length is less than the fixed length, the system pads the string to the right with pre-defined padding characters until the string length equals the fixed length. For nodes whose original string length is exactly equal to the fixed length, the system performs no padding operation.

[0039] Specifically, when concatenating the identifier segment and time period in chronological order, the system creates a status subfield for each node assigned an event tag. The system retrieves the identifier segment string and time period value for that node, converting the time period value into a fixed-length decimal string, padding with zeros at the highest digits if necessary. The system concatenates the nodes according to the chronological order of the events assigned to them, determined by the generation timestamp of each node, with nodes having earlier timestamps appearing first.

[0040] Specifically, following the preorder traversal order of nodes in the task structure tree, the system starts from the root node of the task structure tree, first visiting the root node, and then recursively visiting the left subtree to the right subtree of each node. The specific execution method of the preorder traversal order in the task structure tree is as follows: the system starts from the project root node, first visiting the project root node itself, and then visiting each task node in ascending order of task order index. For each task node, the system checks whether the node has a status subfield; only nodes assigned event markers have a status subfield, and unmarked nodes do not.

[0041] Furthermore, the system selects only nodes whose assigned event flag field value is true and extracts two pieces of data from these nodes: a node identifier and a generation timestamp. The node identifier is a unique number for the task node in the task structure tree, and the generation timestamp is the time value recorded by the system clock at the moment the assigned event occurred, accurate to the second. The system collects the node identifiers and generation timestamps of all these tagged nodes into a temporary list as a data source for subsequent processing.

[0042] Furthermore, in cases where the original string of the node identifier exceeds a fixed length, the system truncates the excess portion, retaining only the first fixed number of characters. The padded string is called an identifier segment, which is a data block of identical length. Each node assigned an event marker corresponds to one identifier segment. Simultaneously, the system converts the generated timestamp into a timing value starting from the start time, which is a fixed baseline time point set by the system. The system calculates the time difference between the generated timestamp and the start time, converting this time difference into an integer value in seconds. This integer value is called a time period. The time period is a pure numerical value, containing no time format information, and only representing the number of seconds elapsed from the start time to the time the assigned event occurs.

[0043] Furthermore, the system uses the identifier string as the first half and the time period number string as the second half, directly concatenating the two parts to form a longer string. This string is the status subfield of the node. Each node assigned an event tag generates a unique status subfield, which contains both fixed-length identifier information for the node's identity and the time information of the event occurrence.

[0044] Furthermore, the system extracts the state subfields of nodes sequentially according to the order in which they are encountered during the preorder traversal. The system places the first encountered state subfield at the beginning, the second immediately following it, and so on, concatenating all state subfields into a single long string. This concatenated string is the iteration state identifier for the target process. The iteration state identifier is a compact binary or text sequence in which the state information of each node assigned an event marker is fully preserved according to its traversal order in the task structure tree.

[0045] In summary, by reading only nodes with assignment event markers, the system can accurately filter out task nodes that have been actually assigned to executors, avoiding the performance waste caused by traversing all task nodes. The extraction of node identifiers and generation timestamps provides the original data foundation for subsequent construction of iterative status identifiers, ensuring that the unique identity and assignment time of each assigned task are fully recorded, thereby guaranteeing the accuracy and traceability of status tracking.

[0046] In summary, by padding node identifiers with a fixed length, all identifier segments have a uniform byte width, facilitating rapid location and parsing in the status field. Converting the generated timestamp into a timing value starting from the initial time eliminates comparison ambiguities caused by different time formats, converting time information into pure numerical values, significantly improving the storage efficiency and sorting performance of the status field, and providing a feasible solution for the compact encoding of iterative status identifier bits.

[0047] In summary, by concatenating the identifier segment and time period according to the chronological order of the allocation events, each status subfield contains both node identity information and chronological order information. This allows a single status subfield to fully describe the allocation time and identity of a task node. This chronological concatenation method ensures the natural temporal order of the status subfields, and the order of task allocation can be directly reconstructed during subsequent parsing without additional sorting, thus simplifying the encoding and decoding logic of status fields.

[0048] In summary, by employing a pre-order traversal to sequentially connect the state subfields, the generated iterative state identifiers are kept consistent with the hierarchical structure of the task tree structure. The state information of any task node can be quickly located by traversing this identifier and combining it with the tree structure. The single continuous field formed by connecting the first and last nodes greatly compresses the storage space of the state information while retaining complete node state and time information. This facilitates efficient use in scenarios such as network transmission, database storage, and version file embedding, providing a unified data carrier for subsequent review request sending and status updates.

[0049] In this embodiment of the invention, when the step of sending an audit request to the audit group of the role permission group in the task node based on the audit status of the iteration status identifier bit, and updating the iteration status identifier bit according to the feedback data of the audit group to obtain the current iteration status of the target process, is specifically used for: Based on the iteration status flag, locate the task node corresponding to the flag that the review status is pending, and read the communication address list of the review group from the role permission group configuration information of the task node; The node identifier, file fingerprint, and current time of the task node are used as the audit request data packet for the target process and sent to the communication address list respectively. The feedback data of the audit group is received based on the audit request data packet. The feedback data includes an audit conclusion field and a feedback time field. The audit result of the target process is determined based on the audit conclusion distribution in the feedback data, and the corresponding bit in the iteration status identifier is updated to the value corresponding to the resolved status based on the audit result, so as to obtain the current iteration status of the target process.

[0050] Specifically, when locating the task node corresponding to the pending status flag based on the iterative status flag, the system divides the iterative status flag into multiple status subfields of a pre-defined fixed length. Each status subfield corresponds to a task node with an assigned event flag in the task structure tree. The system reads the flag segment portion of each status subfield sequentially according to the preorder traversal order. The system compares the read flag segment with the node flags of each task node in the task structure tree character by character. After finding a task node with a completely matching node flag, the system then checks the review status flag corresponding to the time period value in that status subfield.

[0051] Specifically, when sending the node identifier of the task node, the file fingerprint, and the review request data packet with the current time as the target process to the communication address list, the system first extracts a string copy of the node identifier from the attribute field of the task node. The file fingerprint is a fixed-length digest value obtained by hashing the current version of the file to be reviewed; the system reads this digest value from the metadata area of ​​the version file. The current time is read from the system clock in the format of a complete Coordinated Universal Time (UTC) time string.

[0052] Specifically, when determining the audit result of the target process based on the distribution of audit conclusions in the feedback data, the system collects the audit conclusion field values ​​returned by all audit team members. The system counts the number of items with an audit conclusion of "pass" and the number of items with an audit conclusion of "fail," and also records the number of members who did not return feedback data within the specified time. The system uses a majority voting method to determine the final audit result: when the number of passed items is greater than the number of failed items, the audit result is "pass"; when the number of passed items is less than the number of failed items, the audit result is "fail"; when the number of passed and failed items are equal, the system sets the audit result to "fail" according to a preset tie-breaking rule to ensure the rigor of the audit.

[0053] Furthermore, the review status flag is stored in the extended area of ​​the iteration status identifier. The system reads the current value of this flag; if the value is the code corresponding to the pending status, the task node is determined as the target node for which a review request needs to be sent. The system reads the pre-stored list of review group communication addresses from the role and permission group configuration information of the task node. The list of communication addresses contains the network communication addresses of each member in the review group, and the address format is Uniform Resource Locator or email address.

[0054] Furthermore, the system combines the node identifier string, file fingerprint digest value, and current time string in a fixed order into an audit request data packet, which uses a structured encoding format. The system iterates through each address in the communication address list and sends a separate audit request data packet with identical content to each address. After sending, the system enters a waiting state, listening for response messages from the network addresses of audit team members. When the system receives feedback data, it parses the audit conclusion field and feedback time field from it. The audit conclusion field contains a judgment result such as pass or fail, and the feedback time field records the system time when the audit team member submitted the conclusion.

[0055] Furthermore, the system ignores members who have not returned feedback data and only makes judgments based on the valid feedback data received. When updating the corresponding bit in the iteration status flag to the value corresponding to the resolved state based on the review result, the system locates the offset position of the task node in the iteration status flag and modifies the status flag at that position from unresolved state code to resolved state code. There are two types of resolved state codes: approved code and rejected code. The system selects and writes the corresponding code based on the previously determined review result. After completing all bit update operations, all flags in the iteration status flag that are in an unresolved state either remain in an unresolved state or change to a resolved state. At this point, the value of the entire iteration status flag is the current iteration status of the target process.

[0056] In summary, by directly locating task nodes in the pending state through iterative status flags, the inefficient operation of traversing the entire task structure tree or scanning all version files is avoided, enabling precise filtering of the targets for review request sending. Reading the pre-stored communication address list from the role permission group configuration information ensures that review requests are only sent to members with review permissions, preventing unauthorized personnel from receiving requests or abuse of review permissions. Furthermore, the unified management of the communication address list facilitates subsequent batch sending and address change maintenance.

[0057] In summary, by combining node identifiers, file fingerprints, and the current time into a single review request data packet, each review team member receives a request containing the identity information of the task being reviewed, a unique digest of the file to be reviewed, and the precise time the request was sent, thus eliminating the risk of file tampering or request replay attacks. Sending the request to each address in the communication address list ensures that each review team member receives the complete request information independently, without interference. The feedback data includes both a review conclusion field and a feedback time field, recording both the review result and the time point at which the conclusion was reached, providing precise time information for subsequent review result statistics and iteration time calculations.

[0058] In summary, the final review result was determined by analyzing the distribution of review conclusions across all feedback data. This collective decision-making mechanism avoided the impact of subjective bias or erroneous judgments from individual reviewers on project progress, thus improving the fairness and reliability of the review results. Based on the review results, the corresponding bits in the iteration status flag were updated to the values ​​corresponding to the resolved status, ensuring that the iteration status flag reflects the latest review progress of each task node in real time, achieving synchronous updates between the status flag and the review process. The updated current iteration status can be used to trigger subsequent version file storage operations and also to visually display the task's approval or rejection status in the progress tracking view, providing project managers with immediate decision-making support.

[0059] In this embodiment of the invention, the step of linking and storing the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process is specifically used for: Based on the task node, determine the storage path and version number of the version file, and write the current iteration status into the custom attribute field of the new version file in plain text form; Write a backlink field at the end of the new version file, the content of which is the storage path of the version file; Write a forward link field in the header of the version file, the content of which is the storage path of the new version file; By associating the backlink field with the forward link field, a version chain of the target process is obtained.

[0060] Specifically, when determining the storage path and version number of a version file based on a task node, the system reads the pre-defined root directory address for file storage and the file naming rules corresponding to that task node from the task node's attributes. The storage path is composed of three parts: the root directory address, the task node's node identifier string, and the current date and time string. The system creates a folder corresponding to this path on the storage medium. The version number is determined by scanning the number of existing version files under the storage path and adding one to the largest existing version number as the version number of the new version file.

[0061] Specifically, when the backlink field is written to the end of a new file, the system reopens the binary stream of the new file and moves the read / write pointer to the end of the file. The backlink field is a fixed-format text block containing the complete storage path string of the previous version file. The system reads the storage path of the latest version file from the version record of the task node. If no historical version file exists, the content of the backlink field is set to an empty path identifier.

[0062] Specifically, when the forward link field is written to the header of the version file, the system opens the binary stream of the previous version file and locates the starting position of the forward link field reserved in the header area of ​​that file. The content of the forward link field is the complete storage path string of the new version file, which the system obtains from the path variable when the new version file was previously generated.

[0063] Specifically, when associating the backlink field with the forward link field, the system confirms that the backlink field in the new version file has correctly recorded the storage path of the previous version file, and simultaneously confirms that the forward link field in the previous version file has correctly recorded the storage path of the new version file. The two fields form a pair of mutually pointing pointers, with the backlink field pointing to the predecessor version and the forward link field pointing to the successor version.

[0064] Furthermore, the system retrieves the value of the current iteration state from memory, which is a string representing the iteration state identifier. The system opens the binary stream of the new file, locates the starting position of the reserved custom attribute field in the file header area, writes the plain text string of the current iteration state byte by byte into this field, and closes the file stream after writing is complete.

[0065] Furthermore, the system first writes the field identifier of the backlink field to the end of the file, then writes the field length value, and finally writes the storage path string of the previous version file. After writing is complete, the system records the write position at the end of the file as a file end marker, and then closes the file stream. The existence of the backlink field allows the storage location of its direct predecessor file to be found by starting from the new version file.

[0066] Furthermore, the system first writes the field identifier of the forward link field to the header of the version file, then writes the field length value, and finally writes the storage path string for the new version file. After writing is complete, the system closes the file stream of the version file. At this point, the forward link field that originally existed in the version file may be empty; the system updates this field from an empty value to a valid path pointing to the new version file. The forward link field allows the storage location of the successor version file to be found forward from the historical version file.

[0067] Furthermore, the system records this pair of associated pointers in the version chain management table, which maintains the successor relationship between all version files under the task node. When multiple consecutive versions exist, each version file establishes a bidirectional link with adjacent versions through its own reverse link field and the forward link field of the previous version file. All version files are chained together through these bidirectional link fields to form a complete chain, which is the version chain of the target process. The head of the version chain is the initial version file with the smallest version number, whose reverse link field is empty; the tail of the version chain is the latest version file with the largest version number, whose forward link field is empty.

[0068] In summary, determining the storage path and version number through task nodes ensures a clear attribution relationship between each version file and its respective task node, preventing version files from overwriting or becoming confused between different task nodes. Writing the current iteration status as plain text into a custom attribute field in the header of the new version file means that the version file itself contains complete status information from when that version was generated. This allows for independent parsing of the review status without relying on an external database, enhancing the portability of version files and the readability of long-term archives.

[0069] In summary, by writing a backlink field pointing to the storage path of the previous version file at the end of the new version file, it is possible to directly locate the storage location of the previous historical version file starting from any new version file. This backlink mechanism does not require maintaining a separate version mapping table; the tracing relationship between versions is completely embedded in the version file itself. Even if the external index is lost, users can still trace back all historical versions one by one along the backlink field, significantly improving the robustness and fault tolerance of the version chain.

[0070] In summary, by writing a forward link field pointing to the storage path of the new version file at the beginning of the previous version file, it is possible to directly find the storage location of the successor version file starting from any older version file. The forward and reverse links together form a bidirectional pointer system, supporting both reverse tracing from newest to oldest and forward evolution queries from oldest to newest. This design allows version chain traversal operations to proceed freely in both directions, providing complete path support for the generation of feedback tracing records, and also facilitating the rapid adjustment of adjacent pointers when inserting or deleting versions in the middle of the version chain.

[0071] In summary, by pairing and associating the backlink fields in the new version file with the forward link fields in the previous version file, a strong bidirectional coupling relationship is formed between version files. This interrelationship ensures the continuity and integrity of the version chain; the absence or corruption of any version file will not cause the entire chain to break, and adjacent versions can still be located through pointers in the other direction. The resulting version chain is a distributed linked list structure that can exist independently without a central index. Each version file stores both its own content data and its relationship data with previous and subsequent versions, thus providing a reliable and efficient data organization foundation for subsequent feedback traversal and progress tracking view generation.

[0072] In this embodiment of the invention, when the step of traversing the version files level by level based on the association pointers between adjacent version files in the version chain to obtain the feedback traceability record of the target process is specifically used for: Starting from the first pointer in the node pointer sequence of the version chain, read the version files pointed to by the pointers in sequence to obtain the submission timestamp, associated review comments, and iteration round number of the version files in the target process; Calculate the iteration time between adjacent version files in the version chain, and assemble the version identifier of the version file, the submission timestamp, the associated review comments, the iteration round number, and the iteration time into a feedback traceability record item for the target process according to the traversal order; The feedback traceability records are arranged in version order to obtain the feedback traceability records of the target process.

[0073] Specifically, when reading the version files pointed to by the pointers sequentially from the first pointer in the version chain's node pointer sequence, the system first retrieves the node pointer sequence stored in the version chain management table. The node pointer sequence is a list of pointers arranged in ascending order of version number, with each pointer pointing to the complete path of the corresponding version file in the storage medium. The system reads from the first pointer in the sequence and opens the corresponding version file based on the storage path recorded in the pointer. After opening the version file, the system reads three pieces of information from the file's metadata area: the submission timestamp is recorded in the file creation attribute, the associated review comments are recorded in the custom attribute field at the beginning of the file, and the iteration round number is recorded in the extended field at the end of the file.

[0074] Specifically, when calculating the iteration time between adjacent version files in the version chain and assembling the information of the version files into feedback traceability record items, the system traverses each record in the temporary record table and calculates the iteration time between each record and the previous record, starting from the second record.

[0075] Specifically, when arranging the feedback trace records by version order to obtain the feedback trace records for the target process, the system confirms that the feedback trace record items in the list are naturally arranged in ascending order of version number. This is because the system traverses the version chain from the first pointer to the last pointer in the node pointer sequence, and the node pointer sequence itself is stored in ascending order of version number. Therefore, the feedback trace record items in the list naturally conform to the version order. The system outputs this list as the feedback trace records for the target process.

[0076] Furthermore, the system temporarily stores these three pieces of information, along with the version identifier of the current version file, in a temporary record table in memory. After completing the reading of the information for the current version file, the system closes the file and moves to the next pointer in the node pointer sequence, repeating the above reading operation until all version files pointed to by all pointers in the sequence have been read. The system stores the information of each version file sequentially in the temporary record table according to the reading order, with each version file corresponding to one temporary record.

[0077] Furthermore, for the first version file in the version chain, its iteration time is set to zero because there is no earlier version to compare it with. The system creates a feedback traceability record for each version file, with each record containing five fields: version identifier (obtained directly from the temporary record), submission timestamp (obtained directly from the temporary record), associated review comments (obtained directly from the temporary record), iteration round number (obtained directly from the temporary record), and iteration time using the time difference calculated earlier. The system writes these feedback traceability records into a list sequentially according to the traversal order, with each record occupying an independent position in the list.

[0078] Furthermore, the feedback traceability record is a structured data collection, where each entry fully describes a version file's position in the version chain, its time information, review information, and the time interval between it and the previous version. Feedback traceability records can be directly used by the subsequent progress tracking view generation module, or they can be persistently stored in a database for later querying.

[0079] In summary, by reading each version file sequentially according to the node pointer sequence, the integrity and orderliness of the version traversal operation are ensured, preventing any historical versions from being missed. Directly reading the commit timestamp, associated review comments, and iteration round number from each version file binds this critical information to the version file itself, allowing for independent retrieval without relying on external databases or index tables. This improves the reliability and robustness of data acquisition. This reading method provides an accurate and complete source of raw data for subsequent calculations of iteration time and assembly feedback traceability records.

[0080] In summary, by calculating the iteration time between adjacent version files, the original timestamp difference is transformed into a time-consuming metric with practical management significance, allowing project managers to intuitively understand the length of time spent in each iteration. Version identifiers, commit timestamps, associated review comments, iteration round numbers, and iteration times are assembled into feedback traceability record items in traversal order. This makes each record item a self-contained, structured data unit, fully describing the entirety of a version file and its temporal relationship with the previous version. This assembly method facilitates subsequent record storage, querying, and visualization, providing standardized input data for generating progress tracking views.

[0081] In summary, by arranging the feedback traceability records in version order, a complete timeline is formed, clearly showing the entire evolution process from the first version to the latest version. As a holistic data structure, the feedback traceability records retain both the independent information of each version and the chronological relationships and time intervals between versions, providing systematic data support for project review, problem identification, and efficiency analysis. These records can be directly read and converted into graphical displays by the progress tracking view module, or exported for offline analysis or archiving, significantly improving the traceability and data reuse value of VI design task progress tracking.

[0082] In this embodiment of the invention, the formula for calculating the iteration time is specifically used for: in, For the first Version 1 and 2 Iteration time between versions This represents the iteration round number. For the first The commit timestamp of each version file For the first The commit timestamp of each version file This is the overall magnification factor. For the iterative round exponent, Sensitivity coefficient for the length of review comments. For the first The number of characters in the review comments text associated with each version file. It is a logarithmic modulation function. It is a natural constant. Steepness coefficient, The threshold for the inflection point round, The influence coefficient of the review team. For the first The sum of the frequencies of preset keywords in the review comments text associated with each version of the file. For the first The total number of members who participated in the review when each version file was submitted. This refers to the keyword frequency index. This is the membership index.

[0083] Specifically, the overall scaling factor is a global scaling value set by the project manager during system initialization based on the overall complexity of the project. The iteration round exponent is an empirical value derived from statistical regression analysis of previously completed university-enterprise collaborative VI design projects, used to describe the impact of iteration rounds on the increase in time consumption. The review comment length sensitivity factor is a fixed configuration value calculated based on the average reading speed of review team members, stored in the system parameter table. The character count of the review comments text associated with each version file is derived from the actual character count directly read by the system from the review feedback data of that version file. The natural constant is a fixed irrational number defined in mathematics, used as the base of logarithmic modulation functions and steepness functions. The steepness coefficient is a value fitted from historical project data, used to control the width of the transition band affected by iteration rounds. The inflection point round threshold is an empirical value automatically calculated by the system based on the average number of iterations for similar VI design projects, representing the turning point where the time consumption increases from slow to rapid. The review group influence coefficient is a weighted value set by the project manager based on the number and permission levels of review group members, stored in the role permission group configuration information of the task node. The sum of the frequencies of preset keywords in the review comment text associated with each version of the file comes from the system scanning the review comment text and summing the frequency of each word in the preset keyword list. The total number of members participating in the review when a version file is submitted is obtained by counting duplicates from the list of communication addresses sent in the review request data packet. The keyword frequency index is an index parameter trained using machine learning methods from historical review feedback data, used to amplify the impact of high-frequency keywords on iteration time. The member number index is an index parameter obtained from regression analysis of historical project data, used to describe the effect of increasing the number of review members on reducing iteration time.

[0084] Furthermore, the significance of this formula lies in the iteration time between versions. This time is not only equal to the difference between the submission timestamps of the two versions, but also multiplied by an impact factor composed of multiple factors. The base of the impact factor is one, indicating that when all additional influences are zero, the iteration time equals the original difference between the submission timestamps of the two versions. The first part of the impact factor consists of the iteration round number, the length of the review comments, and a logistic growth function, used to describe the additional time overhead caused by the increase in iteration rounds and the length of review comments. The second part of the impact factor consists of the sum of the frequencies of preset keywords in the review comments and the total number of members participating in the review, used to describe the moderating effect of the intensity of the review team's feedback and the scale of the review on the iteration time. This formula combines all influencing factors through an additive relationship, enabling the calculation of iteration time to simultaneously reflect the inherent laws of project progress and the influence of external review behaviors.

[0085] In summary, as the iteration round number gradually increases from zero, the value of the iteration round number multiplied by the exponent in the first part monotonically increases, leading to an increase in the overall amplification factor multiplied by this term. When the number of characters in the review comment text increases, the value of the logarithmic modulation function (within parentheses) plus the review comment length sensitivity coefficient multiplied by the number of characters increases. The logarithmic function itself is monotonically increasing, therefore the contribution value of the entire first part increases, manifested as the iteration time increasing as the review comment length increases. The logistic function part is one divided by one plus the negative steepness coefficient of the natural constant multiplied by the iteration round number minus the inflection point round threshold raised to the power of the parentheses. The value of this function approaches zero when the iteration round number is much smaller than the inflection point round threshold, approaches one when it is much larger than the threshold, and equals 0.5 when it is equal to the threshold. The trend of the logistic function indicates that when the number of iterations has not reached the inflection point threshold, the additional contribution of iterations to the time consumption is strongly suppressed; when the number of iterations exceeds the inflection point threshold, the influence of iterations rises rapidly and eventually approaches saturation, meaning it no longer grows indefinitely. In the second part, when the sum of the frequencies of preset keywords increases, the numerator increases, leading to an increase in the value of the entire second part, which means that the more frequently the key feedback words appear, the longer the iteration time. When the total number of members participating in the review increases, the denominator increases, leading to a decrease in the value of the entire second part, which means that the more reviewers there are, the shorter the iteration time. However, the number of members determines that this decrease is marginally diminishing, meaning that the effect is significant when adding a small number of members, but the effect weakens when there are many members. The general trend is as follows: In the early stages of a project, when there are fewer iterations, shorter review comments, and fewer keywords, the overall impact factor is close to one, and the iteration time is close to the original time difference. As the project progresses, the number of iterations increases, the review comments become longer, and the frequency of keywords rises, the overall impact factor becomes significantly greater than one, and the iteration time is amplified. If the total number of reviewers is large, the amplification effect is partially offset.

[0086] In this embodiment of the invention, the step of determining the layout coordinates based on the timestamp order of the version nodes in the feedback traceability record, and connecting the nodes according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process, is specifically used for: The commit timestamps of the version nodes in the feedback traceability record are sorted sequentially to obtain the timestamp sequence of the target process; The ratio of the horizontal pixel width of the target process view to the total number of timestamps in the timestamp sequence is used as the horizontal coordinate interval of the target process; Based on the sorting position of the submission timestamp in the timestamp sequence, the product of the sorting position and the horizontal coordinate interval is used as the horizontal layout coordinate of the target process; Based on the task node identifier of the feedback traceability record, the hierarchical depth starting from the project root node of the target process is used as the vertical layout coordinate of the target process; By connecting the version nodes based on the transition directions of adjacent versions in the feedback traceability record, a progress tracking view of the target process is obtained.

[0087] Specifically, when sorting the commit timestamps of version nodes in the feedback traceability record, the system extracts the value of the commit timestamp field corresponding to each version node from the feedback traceability record list. The commit timestamp is an absolute time value represented by an integer in seconds, recording the moment when the version file was committed to the system.

[0088] Specifically, when using the ratio of the horizontal pixel width of the target process view to the total number of timestamps in the timestamp sequence as the horizontal coordinate interval of the target process, the system first reads the preset horizontal pixel width value from the view configuration parameters. The horizontal pixel width of the view is the total pixel length of the progress tracking view in the horizontal direction, which is determined by the user interface settings.

[0089] Specifically, based on the sorting position of the commit timestamp in the timestamp sequence, the system uses the product of the sorting position and the horizontal coordinate interval as the horizontal layout coordinate of the target process, and iterates through each version node in the feedback traceability record. For the currently processed version node, the system looks up the index of the commit timestamp of that node in the timestamp sequence.

[0090] Specifically, based on the task node identifiers in the feedback traceability records, when using the hierarchical depth that progresses from the project root node of the target process as the vertical layout coordinates of the target process, the system reads the task node identifiers associated with each version node in the feedback traceability records.

[0091] Specifically, when connecting version nodes based on the transition direction of adjacent versions in the feedback tracing record, the system first arranges the version nodes in the feedback tracing record in ascending order of version number. For each pair of adjacent version nodes in the sequence, the system obtains a pointer to the next version node from the forward link field in the storage path of the first version node, confirming the existence of a version transition relationship between the two nodes.

[0092] Furthermore, the system places all extracted commit timestamp values ​​into an array and then sorts the values ​​in the array from smallest to largest. After sorting, the first element in the array is the earliest commit timestamp, and the last element is the latest commit timestamp. The system names this sorted array a timestamp sequence, and the position index of each element in the timestamp sequence starts from zero and increases sequentially, reflecting the order of the commit timestamp in the entire sequence.

[0093] Furthermore, the system counts the total number of submission timestamps in the timestamp sequence; this total equals the total number of version nodes in the feedback traceability record. The system divides the horizontal pixel width of the view by the total number of timestamps, and the resulting value is the horizontal coordinate interval. The horizontal coordinate interval represents the pixel distance that two adjacent version nodes should occupy in the horizontal direction of the view. The system stores this horizontal coordinate interval for subsequent calculation of the horizontal position of each version node in the view.

[0094] Furthermore, the position index starts from zero, representing the ascending sequence number of the commit timestamp in the timestamp sequence. The system multiplies this position index value by the previously calculated horizontal coordinate interval, and the product is the horizontal layout coordinate of that version node. The unit of the horizontal layout coordinate is pixels, and its value is the starting horizontal drawing position of the version node in the progress tracking view. The horizontal layout coordinate of the version node with the earliest commit timestamp is zero, and the horizontal layout coordinate of the version node with the latest commit timestamp is equal to the horizontal pixel width of the view minus the horizontal coordinate interval.

[0095] Furthermore, each task node identifier corresponds to a specific task node in the task structure tree. The system starts from the project root node and traverses downwards along the parent-child pointer relationships of the task structure tree. The system counts the number of edges traversed from the project root node to the task node; this number is the hierarchy depth. The project root node itself has a hierarchy depth of zero, its direct child nodes have a hierarchy depth of one, and so on. The system multiplies the hierarchy depth value of each version node by a preset vertical row height in pixels to obtain the vertical layout coordinates of that version node. The vertical layout coordinates determine the vertical drawing position of that version node in the progress tracking view.

[0096] Furthermore, the system locates the horizontal and vertical layout coordinates of the first version node on the view canvas, as well as the coordinates of the second version node. Starting from the position of the first version node, the system draws an arrowed line segment pointing towards the position of the second version node; the direction of the arrow indicates the version transition direction. The system repeats this connection operation for all adjacent version nodes. All the drawn version node graphics and connecting lines together form the progress tracking view of the target process. The progress tracking view fully displays the horizontal position of each version node on the timeline, its vertical hierarchy in the task structure tree, and the evolution path between versions.

[0097] In summary, by sequentially sorting the commit timestamps of all version nodes, the potential for disorder or randomness in the original records is eliminated, ensuring that each version node obtains a unique and definite position index on the timeline. The resulting timestamp sequence serves as the sole basis for subsequent horizontal coordinate calculations, guaranteeing that the horizontal arrangement of version nodes in the view strictly matches the actual commit time order, thus avoiding view distortion or intersecting lines caused by out-of-order timestamps.

[0098] In summary, by dividing the horizontal pixel width of the view by the total number of timestamps, all version nodes are evenly distributed horizontally, making full use of the view's available width. This horizontal coordinate interval ensures that the progress tracking view automatically adapts to the current display area regardless of the number of version nodes, preventing issues such as node crowding, overlap, or sparse distribution, thereby improving the view's readability and general adaptability.

[0099] In summary, by multiplying the sort position by the horizontal coordinate interval, a horizontal coordinate is calculated for each version node that is strictly proportional to its chronological order. This calculation method places earlier commit versions closer to the left side of the view and later commit versions closer to the right side, achieving an intuitive mapping from the time dimension to the spatial dimension. Users can immediately determine the order of versions based on the horizontal position of the nodes.

[0100] In summary, by calculating the hierarchical depth starting from the project root node based on task node identifiers, all version nodes under the same task node share the same vertical coordinates. Task nodes at different hierarchical depths are arranged separately vertically, forming a clear task hierarchy. Users can simultaneously observe version time evolution horizontally and distinguish the hierarchical affiliation of different tasks vertically, significantly improving the information density and expressive efficiency of the progress tracking view.

[0101] In summary, by connecting adjacent version nodes and clearly marking the direction of change, discrete version nodes are transformed into continuous evolution paths, intuitively demonstrating the succession relationship between versions. This progress tracking view integrates time sequence, task hierarchy, and version change information, enabling project managers to quickly locate the historical position of any version, understand the evolution trajectory from the previous version to the current version, and provide a graphical framework for subsequent time consumption annotations and review comments.

[0102] In this embodiment of the invention, when connecting the version nodes based on the transition directions of adjacent versions in the feedback tracing record to obtain the progress tracking view of the target process, it is specifically used for: Connect adjacent version nodes in the version node sequence of the feedback traceability record in chronological order to obtain the directed edges of the target process; The state transition direction of the target process is determined based on the starting and ending layout coordinates of the directed edge. The iteration time between adjacent version nodes in the feedback traceability record is converted into time text labels and marked at the midpoint of the directed edge; The review comments text of the version node are marked as additional information on the side of the corresponding version node in the progress tracking view of the target process.

[0103] Specifically, when connecting adjacent version nodes in the version node sequence of the feedback traceability record in chronological order, the system extracts the version node sequence from the feedback traceability record. The version nodes in this sequence are already arranged in ascending order of version number. Starting from the first version node in the sequence, the system takes the current version node and the next version node in the sequence to form a pair of adjacent nodes. The system checks whether there is a version transition relationship between these two nodes, confirming this by whether the forward link field of the current version file points to the storage path of the next version file.

[0104] Specifically, when determining the state transition direction of the target process based on the start and end layout coordinates of the directed edges, the system traverses each directed edge already drawn on the view canvas. The system reads the start and end position coordinates of the directed edge, where the start coordinates correspond to the position of the earlier version node and the end coordinates correspond to the position of the later version node. The system calculates the positional relationship between the end coordinates and the start coordinates: if the horizontal value of the end coordinate is greater than the horizontal value of the start coordinate, the state transition direction is from left to right; if the horizontal value of the end coordinate is less than the horizontal value of the start coordinate, the state transition direction is from right to left; if the horizontal value of the end coordinate is equal to the horizontal value of the start coordinate and the vertical value of the end coordinate is greater than the vertical value of the start coordinate, the state transition direction is from top to bottom.

[0105] Specifically, when the iteration time between adjacent version nodes in the feedback traceability record is converted into a time text label and marked at the midpoint of the directed edge, the system reads the iteration time value between two adjacent version nodes from the feedback traceability record. The iteration time is a time difference value in seconds, and the system converts this value into a readable time text format.

[0106] Specifically, when the review comments text of a version node is marked as additional information on the side of the corresponding version node, the system reads the content of the associated review comments field for each version node from the feedback traceability record. The review comments text is the written feedback content filled in by the review team during the review process, which may include modification suggestions or approval instructions.

[0107] Furthermore, the system locates the drawing position point on the view canvas, determined by the horizontal and vertical layout coordinates of the current version node, as well as the drawing position point on the next version node, determined by the horizontal and vertical layout coordinates. The system draws a straight line segment from the current version node's position point to the next version node's position point; this straight line segment is the directed edge. The system repeats this operation for all adjacent version node pairs in the sequence, generating a directed edge for each pair of adjacent nodes. The set of all directed edges constitutes the connection structure of the target process.

[0108] Furthermore, when drawing directed edges, the system adds an arrow graphic to the end of the line segment, and the direction of the arrow indicates the state transition direction. The arrow is drawn as follows: an equilateral triangle is drawn at the end position of the line segment, with the base of the triangle perpendicular to the direction of the line segment and the vertex of the triangle pointing in the direction of the line segment's extension.

[0109] Furthermore, the system calculates the midpoint position between the start and end points of the directed edge. The horizontal coordinate of the midpoint is equal to half the sum of the horizontal coordinates of the start and end points, and the vertical coordinate is equal to half the sum of the vertical coordinates of the start and end points. The system creates a text label control at the midpoint position on the view canvas, using the converted time text label as the content of this control. The system sets the font size, color, and background style of the text label to ensure that the label is clearly visible and does not overlap with the directed edge. The system repeats this operation for all directed edges, labeling the midpoint position of each directed edge with the corresponding time text label.

[0110] Furthermore, the system determines the drawing position coordinates of each version node on the view canvas, and then calculates the lateral position based on these coordinates: the system sets the lateral position at a fixed offset distance to the right of the version node's drawing position, the offset distance being determined by the preset node width plus a fixed spacing value. The system creates a text label control at the lateral position, using the review comment text as the control's content. If the length of the review comment text exceeds the maximum width for single-line display, the system splits the text into multiple lines. The system repeats this operation for all version nodes in the feedback traceability record, labeling the lateral position of each version node with its associated review comment text. After completing the connections, direction labels, time-consuming labels, and review comment labels for all version nodes, the system finally outputs a complete progress tracking view.

[0111] In summary, by connecting adjacent version nodes in chronological order to form directed edges, discrete version nodes are linked together into a continuous evolution path, making the inheritance relationship between versions clear at a glance in the view. This avoids the tedious operation of manually comparing the timestamps of multiple version files to understand the version order.

[0112] In summary, by determining the direction of state transition from the starting coordinate to the ending coordinate, the arrow clearly shows that version evolution is from the old version to the new version, eliminating directional ambiguity between versions. This allows users to intuitively judge the positive flow path of version iteration without having to look at the timestamps, thus improving the understandability of the progress tracking view.

[0113] In summary, by converting iteration time into readable time text labels and marking them at the midpoint of directed edges, users can directly obtain the time spent on each iteration while viewing the version evolution path, without having to jump to view other data tables. This achieves a fusion display of time information and topology path, making it easier for project managers to quickly identify iteration stages with abnormal time consumption.

[0114] In summary, by annotating the review comments text on the side of the version node, the review feedback information associated with each version file is visually closely linked to the version node itself. Users can read the review comments directly in the view without opening the file, which greatly improves the efficiency of problem location and feedback tracing, while ensuring the information integrity and self-explanatory nature of the progress tracking view.

[0115] Compared with the prior art, the present invention has the following beneficial effects:

[0116] 1. By constructing a task structure tree containing the project root node and task nodes, and combining the iteration status flag with the bidirectional link field of the version chain, this method achieves full-process automatic tracking of VI design task progress. The parent-child node pointers and child node identifier list in the task structure tree allow any task node to be quickly located to the project root node. The iteration status flag, connected end-to-end by the preorder traversal order and the status subfield, compresses the identifier and time information of each assigned task node into a single continuous field, facilitating storage and parsing. The forward and reverse link fields in the version chain are interconnected, allowing traversal of all historical versions from any version file along the bidirectional pointers without relying on external index tables. The automatically calculated horizontal and vertical layout coordinates based on feedback traceability records ensure that the position of each version node in the progress tracking view strictly corresponds to its submission time order and task hierarchy depth, achieving a fusion display of the time dimension and task structure.

[0117] 2. This method significantly improves the closed-loop efficiency of the review process and the readability of version information. The pending status positioning mechanism in the iteration status identifier ensures that review requests are only sent to a list of communication addresses with review authority. The review conclusion distribution in the feedback data directly updates the iteration status identifier to the resolved status after a majority vote, ensuring the real-time nature and accuracy of the current iteration status. The new version file header contains the current iteration status in plain text and the tail contains a backlink field, while the version file header contains a forward link field, enabling the version file itself to carry complete iteration status and related information between previous and subsequent versions. In the feedback traceability record, the iteration time between adjacent version nodes is converted into time text labels and marked at the midpoint of the directed edge. The review comments text is marked as additional information for the node and is located to the side of the version node. This allows the version evolution path, iteration time, review feedback, and status change direction to be presented simultaneously in the same progress tracking view, providing project managers with an intuitive, complete, and interactive progress monitoring interface.

[0118] like Figure 2 The diagram shown is a functional block diagram of a VI design task progress tracking system for school-enterprise collaboration provided by an embodiment of the present invention.

[0119] The VI design task progress tracking system 100 for university-enterprise collaboration described in this invention can be installed in an electronic device. Depending on the functions implemented, the VI design task progress tracking system 100 for university-enterprise collaboration may include a task structure tree module 101, an iteration status module 102, a current status module 103, a version chain module 104, a feedback traceability record module 105, and a progress tracking view module 106. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and are stored in the memory of the electronic device.

[0120] In this embodiment, the functions of each module / unit are as follows: The task structure tree module combines the project name and school-enterprise identification of the target process into a project root node, takes the project template corresponding to the VI project type identification in the target process as a task node, and associates the project root node with the task node to construct the task structure tree of the target process. The iteration status module creates a status field for the target process based on the node identifier and timestamp of the allocated event in the task structure tree, and obtains the iteration status identifier bit of the target process; The current status module, based on the review status of the iteration status identifier, sends a review request to the review group of the role permission group in the task node, and updates the iteration status identifier according to the feedback data of the review group to obtain the current iteration status of the target process; The version chain module links and stores the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process; The feedback traceability record module traverses the version files level by level based on the association pointers between adjacent version files in the version chain to obtain the feedback traceability record of the target process; The progress tracking view module determines the layout coordinates based on the timestamp order of the version nodes in the feedback traceability record, and connects the nodes according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process.

[0121] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0122] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0124] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0125] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0126] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for tracking the progress of VI design tasks in a school-enterprise collaborative manner, characterized in that, The method includes: The project name and school-enterprise identification of the target process are combined into the project root node, and the project template corresponding to the VI project type identification in the target process is used as the task node. The project root node is associated with the task node to construct the task structure tree of the target process. The status field of the target process is created based on the node identifier and timestamp of the assigned event in the task structure tree, and the iteration status identifier bit of the target process is obtained. Based on the review status of the iteration status flag, a review request is sent to the review group of the role permission group in the task node, and the iteration status flag is updated according to the feedback data of the review group to obtain the current iteration status of the target process. Link and store the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process; Based on the association pointers between adjacent version files in the version chain, the version files are traversed level by level to obtain the feedback traceability record of the target process; The layout coordinates are determined based on the timestamp order of the version nodes in the feedback traceability record, and the nodes are connected according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process.

2. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 1, characterized in that, The process involves combining the project name and school-enterprise identification of the target process into a project root node, using the project template corresponding to the VI project type identification in the target process as a task node, and associating the project root node with the task nodes to construct the task structure tree of the target process, including: Obtain the project name string and the school-enterprise identification string of the target process, and concatenate the project name string and the school-enterprise identification string into a root node data block to obtain the project root node of the target process; Parse the task configuration items of the VI project type identifier in the target process to obtain the task name, task sequence index and required permission group type of the target process; A task node for the target process is created based on the task name and the task sequence index. The corresponding role permission group is obtained from the collaborative project information of the target process based on the required permission group type, and the role permission group is associated with the corresponding task node. Based on the task sequence index, the node identifiers of the task nodes are added to the child node identifier list of the project root node in sequence, and a parent node pointer pointing to the project root node is set for the task node to obtain the task structure tree of the target process.

3. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 1, characterized in that, The step of creating a status field for the target process based on the node identifier and timestamp of the assigned event in the task structure tree, and obtaining the iteration status identifier bit of the target process, includes: Read the nodes with assigned event tags from the task structure tree to obtain the node identifier and generation timestamp of the node in the target process; The node identifiers are filled with a fixed length to obtain the identifier segment of the target process, and the generated timestamp is converted into a timing value starting from the start time to obtain the time period of the target process; The identifier segment and the time period are concatenated in chronological order to obtain the status subfield of the target process; According to the preorder traversal order of the nodes in the task structure tree, the state subfields are concatenated end to end to obtain the iterative state identifier of the target process.

4. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 1, characterized in that, The process of sending an audit request to the audit group of the role permission group in the task node based on the audit status of the iteration status flag, and updating the iteration status flag according to the feedback data of the audit group to obtain the current iteration status of the target process includes: Based on the iteration status flag, locate the task node corresponding to the flag that the review status is pending, and read the communication address list of the review group from the role permission group configuration information of the task node; The node identifier, file fingerprint, and current time of the task node are used as the audit request data packet for the target process and sent to the communication address list respectively. The feedback data of the audit group is received based on the audit request data packet. The feedback data includes an audit conclusion field and a feedback time field. The audit result of the target process is determined based on the audit conclusion distribution in the feedback data, and the corresponding bit in the iteration status identifier is updated to the value corresponding to the resolved status based on the audit result, so as to obtain the current iteration status of the target process.

5. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 1, characterized in that, The step of linking and storing the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process includes: Based on the task node, determine the storage path and version number of the version file, and write the current iteration status into the custom attribute field of the new version file in plain text form; Write a backlink field at the end of the new version file, the content of which is the storage path of the version file; Write a forward link field in the header of the version file, the content of which is the storage path of the new version file; By associating the backlink field with the forward link field, a version chain of the target process is obtained.

6. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 1, characterized in that, The step-by-step traversal of the version files based on the association pointers between adjacent version files in the version chain to obtain the feedback traceability record of the target process includes: Starting from the first pointer in the node pointer sequence of the version chain, read the version files pointed to by the pointers in sequence to obtain the submission timestamp, associated review comments, and iteration round number of the version files in the target process; Calculate the iteration time between adjacent version files in the version chain, and assemble the version identifier of the version file, the submission timestamp, the associated review comments, the iteration round number, and the iteration time into a feedback traceability record item for the target process according to the traversal order; The feedback traceability records are arranged in version order to obtain the feedback traceability records of the target process.

7. The method for tracking the progress of VI design tasks in a school-enterprise collaboration as described in claim 6, characterized in that, The formula for calculating the iteration time includes: in, For the first Version 1 and 2 Iteration time between versions This represents the iteration round number. For the first The commit timestamp of each version file For the first The commit timestamp of each version file This is the overall magnification factor. For the iterative round exponent, Sensitivity coefficient for the length of review comments. For the first The number of characters in the review comments text associated with each version file. It is a logarithmic modulation function. It is a natural constant. Steepness coefficient, The threshold for the inflection point round, The influence coefficient of the review team. For the first The sum of the frequencies of preset keywords in the review comments text associated with each version of the file. For the first The total number of members who participated in the review when each version file was submitted. This refers to the keyword frequency index. This is the membership index.

8. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 1, characterized in that, The step of determining the layout coordinates based on the timestamp order of the version nodes in the feedback traceability record, and connecting the nodes according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process includes: The commit timestamps of the version nodes in the feedback traceability record are sorted sequentially to obtain the timestamp sequence of the target process; The ratio of the horizontal pixel width of the target process view to the total number of timestamps in the timestamp sequence is used as the horizontal coordinate interval of the target process; Based on the sorting position of the submission timestamp in the timestamp sequence, the product of the sorting position and the horizontal coordinate interval is used as the horizontal layout coordinate of the target process; Based on the task node identifier of the feedback traceability record, the hierarchical depth starting from the project root node of the target process is used as the vertical layout coordinate of the target process; By connecting the version nodes based on the transition directions of adjacent versions in the feedback traceability record, a progress tracking view of the target process is obtained.

9. The method for tracking the progress of VI design tasks in a school-enterprise collaborative manner as described in claim 8, characterized in that, The process of connecting the version nodes based on the transition directions of adjacent versions in the feedback tracing record to obtain the progress tracking view of the target process includes: Connect adjacent version nodes in the version node sequence of the feedback traceability record in chronological order to obtain the directed edges of the target process; The state transition direction of the target process is determined based on the starting and ending layout coordinates of the directed edge. The iteration time between adjacent version nodes in the feedback traceability record is converted into time text labels and marked at the midpoint of the directed edge; The review comments text of the version node are marked as additional information on the side of the corresponding version node in the progress tracking view of the target process.

10. A VI design task progress tracking system for school-enterprise collaboration, used to implement the VI design task progress tracking method for school-enterprise collaboration as described in any one of claims 1-9, characterized in that, The system includes: The task structure tree module combines the project name and school-enterprise identification of the target process into a project root node, takes the project template corresponding to the VI project type identification in the target process as a task node, and associates the project root node with the task node to construct the task structure tree of the target process. The iteration status module creates a status field for the target process based on the node identifier and timestamp of the allocated event in the task structure tree, and obtains the iteration status identifier bit of the target process; The current status module, based on the review status of the iteration status identifier, sends a review request to the review group of the role permission group in the task node, and updates the iteration status identifier according to the feedback data of the review group to obtain the current iteration status of the target process; The version chain module links and stores the new version file of the current iteration state with the version file of the task node to obtain the version chain of the target process; The feedback traceability record module traverses the version files level by level based on the association pointers between adjacent version files in the version chain to obtain the feedback traceability record of the target process; The progress tracking view module determines the layout coordinates based on the timestamp order of the version nodes in the feedback traceability record, and connects the nodes according to the state transition direction in the feedback traceability record to obtain the progress tracking view of the target process.

Images