A project whole-process management stage automatic flow transfer and data association method and system

Abstract

The embodiment of the present application provides a project whole-process management stage automatic flow transfer and data association method and system, relates to the technical field of project management technology. The method comprises the following steps: acquiring a flow transfer rule of a project stage; real-time monitoring of a business event in a project execution process; when a combination of one or more groups of the business events meets the flow transfer rule of the current project stage, switching the project stage to a next project stage. Through the present application, the problem of high project management time delay is solved, and the effect of reducing project management time delay and improving project management efficiency is achieved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of project management technology, and more specifically, to a method and system for automatic phase flow and data association in the whole process management of projects. Background Technology

[0002] In modern enterprises and organizations, complex project management, such as software development, engineering construction, and management consulting, is typically divided into multiple consecutive phases, including requirements analysis, design, development, testing, and deployment. Project management systems are crucial tools for ensuring a smooth transition from one phase to the next. However, existing project management tools attempt to control an inherently dynamic project execution process using static, discrete management actions. This leads to technical problems such as low automation levels, poor data consistency, and disconnected process execution in project phase transition mechanisms.

[0003] For example, the reliance on manual decision-making during the transition between stages leads to process delays and subjectivity; cross-stage data transfer results in information silos, causing duplication of work and data errors; and the disconnect between stage changes and subsequent execution actions creates management gaps and waste of resources. Summary of the Invention

[0004] This invention provides a method and system for automatic phase transition and data association in project full-process management, which at least solves the problem of low timeliness in project process management in related technologies.

[0005] According to an embodiment of the present invention, a method for automatic phase transition and data association in project lifecycle management is provided, comprising: Obtain the workflow rules for each stage of the project, wherein the triggering conditions for the workflow rules consist of a combination of multiple business events; Real-time monitoring of the aforementioned business events during project execution; When a combination of one or more of the business events detected satisfies the flow rules of the current project stage, the project stage is switched to the next project stage.

[0006] In one exemplary embodiment, the method further includes: When switching project phases, one or more source data items generated in the original project phase are extracted according to preset data mapping rules. The source data is format-converted to obtain the first data; The first data is injected into the documents or tasks of the target project phase, and a source data link is established for each injected data item, which is used for data traceability.

[0007] In one exemplary embodiment, the data mapping rule uses a JSONPath expression to define the extraction path of the source data and an XPath expression to define the injection location path in the document or task of the target project stage; and the format conversion includes one or more of text concatenation functions, format conversion functions, arithmetic operation functions, and value mapping functions.

[0008] In one exemplary embodiment, the method further includes: When multiple flow rules are satisfied simultaneously, conflict resolution is performed according to the priority of the flow rules; if the priorities are the same, a selection is made according to a preset deterministic decision rule; wherein, the deterministic decision rule includes: Compare the specificity of the rules and select the rules whose triggering conditions contain more atomic events; If the specificity is the same, compare the timestamps of the last event in the activation rules and select the rule activated by the event with the latest timestamp; If the timestamps are the same, the rule is compared lexicographically based on its unique identifier, and the rule with the higher sort order is selected.

[0009] In an exemplary embodiment, before switching the project stage to the next project stage when a combination of one or more monitored business events satisfies the flow rules of the current project stage, the method further includes: Retrieve the preset task template associated with the next project phase; The preset task template is parsed to extract the initial task set and its corresponding estimated total workload. Obtain the available man-hour capacity of the target resource pool within a preset prediction time window, wherein the target resource pool is used to execute the initial task set; Based on the estimated total workload and the available man-hour capacity, the risk of resource congestion is determined; When the risk of resource congestion exceeds a preset throttling threshold, the stage transfer instruction is intercepted and placed in a memory suspend queue.

[0010] In one exemplary embodiment, after placing the stage transition instruction in the memory suspension queue, the method further includes: The first available working hours capacity is reacquired according to the preset polling cycle, and the first resource congestion risk is determined based on the first available working hours capacity. When the risk of congestion of the first resource is lower than the preset throttling threshold, the stage transition instruction is released from the memory suspend queue, and the project stage is switched to the next project stage.

[0011] According to another embodiment of the present invention, an automated phase transition and data association system for project lifecycle management is provided, comprising: The event listening module is used to monitor the business events during project execution in real time. The phase transition execution module is used to switch the project phase to the next project phase when a combination of one or more sets of business events monitored satisfies the transition rules of the current project phase.

[0012] In one exemplary embodiment, the system further performs the following steps: When switching project phases, one or more source data items generated in the original project phase are extracted according to preset data mapping rules. The source data is format-converted to obtain the first data; The first data is injected into the documents or tasks of the target project phase, and a source data link is established for each injected data item, which is used for data traceability.

[0013] According to yet another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0014] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0015] This invention achieves proactive, event-driven automatic workflow by directly linking the progress of project phases with the status of real business events. This mechanism effectively reduces the response time of phase transitions, thereby reducing process delays caused by manual judgment and communication coordination. It enables project processes to reflect their actual progress status in real time, thus solving the problem of low efficiency in project process management and improving the timeliness of project management. Attached Figure Description

[0016] Figure 1 This is a flowchart of a method for automatic phase transition and data association in project full-process management according to an embodiment of the present invention; Figure 2 This is a system block diagram of a project full-process management stage automatic flow and data association system according to an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0018] In the following description, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0019] Furthermore, in this application, directional terms such as "upper," "lower," "left," and "right" may be defined relative to the orientation of the components shown in the accompanying drawings. It should be understood that these directional terms can be relative concepts, used for relative description and clarification, and may change accordingly depending on the orientation of the components in the accompanying drawings.

[0020] In this application, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral part; it can be a direct connection or an indirect connection through an intermediate medium. Furthermore, the term "coupled" can refer to an electrical connection that enables signal transmission.

[0021] As used herein, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from the given value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the given quantity (i.e., the limitations of the measurement system).

[0022] This embodiment provides a method and system for automatic phase transition in project management throughout the entire process. The method employs a multi-condition rule engine to match diverse business events generated during project execution in real time, thereby automatically triggering precise phase transitions with low latency. This solves the technical problem of slow response caused by reliance on manual intervention in project phase transitions in existing technologies, achieving the beneficial effects of automating, real-time processing, and intelligentizing project management processes.

[0023] The following example illustrates the product release project (Project ID: PROJ-SRS-V3) of "Smart Retail SaaS System V3.0 for a Large E-commerce Platform". This project involves multiple departments such as technology research and development, product design, marketing, legal affairs, and operation and maintenance. It has a high concurrency of events and complex logical relationships between process nodes, which can fully demonstrate the technical details of this invention.

[0024] Reference Figure 1 This illustrates an embodiment of the present invention that discloses an automated phase transition method for project lifecycle management. This method can be applied to a network system including a server and multiple client devices, wherein the core logic of the project management system is deployed on the server. Specifically, it includes the following steps: S100: Obtain and configure the workflow rules for the project phase. The triggering conditions for the workflow rules consist of multiple business events.

[0025] In one embodiment, the following sub-steps are specifically included: S110: Define the project lifecycle phases.

[0026] The project template administrator first defines a standardized lifecycle model for projects like [e-commerce platform release]. This model consists of a series of ordered stages, each representing the macro-level status of the project's progress. This stage information is stored in the project_stages table in the system's database.

[0027] For example, the project_stages table structure can be defined as: stage_id(INT,PK),template_id(INT,FK),stage_name(VARCHAR),stage_order(INT),description(TEXT).

[0028] For the "Smart Retail SaaS System V3.0" project, the administrator defined the following phases: Phase 10 (Technology Preliminary Research and Feasibility Analysis): stage_id=10, stage_name='Technology Preliminary Research', stage_order=10.

[0029] Phase 20 (Core Functionality Development): stage_id=20, stage_name='Core Development', stage_order=20.

[0030] Stage 30 (Internal Alpha Test): stage_id=30, stage_name='Alpha Test', stage_order=30.

[0031] Stage 40 (Inviting Customers to Beta Test): stage_id=40, stage_name='Beta Test', stage_order=40.

[0032] Stage 50 (Official Release and Launch): stage_id=50, stage_name='Official Release', stage_order=50.

[0033] S120: Define and register business event types.

[0034] The system predefines various atomic business event types, which are the basic elements constituting the flow rules. Each event type has a unique identifier and a structured data payload schema, typically defined in JSON Schema, to ensure the consistency of event data.

[0035] For example, some business event types involved in the PROJ-SRS-V3 project are defined as follows: `task_status_changed` (Task Status Change Event): Triggered when the status of a task in the project (such as a ticket in Jira) changes. Its data payload includes: `task_id`, `old_status`, `new_status`, and `assignee`.

[0036] `doc_section_approved` (Document Section Approval Event): Triggered when a specific section of a project document is approved. Its data payload includes: `doc_id`, `section_id`, `approver_role`, and `comment`.

[0037] `code_branch_merged` (code branch merge event): This event is triggered by the CI / CD system via a webhook when a feature development branch is merged into a main branch (such as master or main). Its data payload includes: `repository_url`, `source_branch`, `target_branch`, and `commit_hash`.

[0038] `budget_usage_exceeded` (Budget Usage Exceeded Event): Triggered when the financial system detects that the project's budget usage exceeds a preset threshold. Its data payload includes: `threshold_percentage` (e.g., 85.0, unit: %), and `current_usage_percentage`.

[0039] `legal_ip_review_completed` (Legal IP Review Completed Event): Triggered when the legal department completes its review of the intellectual property rights involved in the new feature. Its data payload includes: `review_result` (enumeration values: "passed", "passed_with_conditions", "rejected"), and `risk_level`.

[0040] `executive_override_triggered` (Special Executive Approval Event): Manually triggered by management personnel with special privileges to handle exceptional situations. Its data payload includes: `executive_id` and `reason_text`.

[0041] S130: Combine business events using logical operators to construct flow rules.

[0042] The project template administrator defines one or more flow rules for the output of each stage.

[0043] For example, regarding the transition from "Phase 10 (Technology Pre-research)" to "Phase 20 (Core Development)," the business requirements are: a technical feasibility analysis report must be completed and pass all internal reviews; performance stress testing of core technology components must meet standards; and the legal department must confirm there are no intellectual property risks. However, the CTO (Chief Technology Officer) can directly approve the project to enter the development phase.

[0044] In response, administrators can construct corresponding logical expressions by dragging and selecting rules in the rule configuration interface.

[0045] S200: Real-time monitoring of business events during project execution.

[0046] In this embodiment, the following sub-steps are specifically included: S210: The occurrence and release of the event.

[0047] During the execution of the PROJ-SRS-V3 project, when critical changes occur in the internal state of each business system, event messages conforming to the event type and data structure are generated and published to the central message queue. For example: Scenario 1: Document approval.

[0048] When a product manager approves a "cost assessment" in the document system, the document system's backend service will immediately construct a doc_section_approved event after updating the database status; this JSON object is serialized and sent as the message body to the message queue.

[0049] Scenario 2: Code merging.

[0050] When the development engineer merges the core functional branch of the payment module, feature / payment-gateway, into the develop branch, a webhook configured on the GitLab server is triggered. This webhook sends an HTTP POST request to a dedicated event-generating microservice, with the request body containing details of the merge operation. Upon receiving the request, the microservice converts it into a code_branch_merged event and publishes it.

[0051] Scenario 3: Special approval from senior management.

[0052] The CTO reviewed the blockages in the "Technology Pre-research" phase on the project management dashboard and clicked the "Approve to proceed with development" button. Afterward, the front-end application called the back-end API, and the back-end service performed permission verification, generating and publishing an executive_override_triggered event.

[0053] S220: Transmit relevant events via a distributed message queue.

[0054] In this embodiment, Apache Kafka is used as the underlying message queue infrastructure. Apache Kafka has high throughput, persistent storage, and horizontal scalability, making it suitable for handling a large number of concurrent project events. Specifically: Topic Design: The system creates a Kafka topic named srs_project_events, which is specifically used to transmit all business events related to the PROJ-SRS-V3 project. To further isolate and control priorities, multiple topics can also be designed, such as events_high_priority and events_low_priority.

[0055] Partitioning: Configure multiple partitions for the `srs_project_events` topic; up to 16 partitions can be configured here. When publishing events, the Kafka producer uses `project_id` as the message key. The default hash partitioning strategy ensures that all events for the same project are sent to the same partition in sequence.

[0056] Persistence and Reliability: The Kafka cluster persists all messages to disk and sets the message replication factor to 3 to ensure that event data is not lost even if a single Broker node fails. The producer is set to acks=all mode to ensure that a message is considered successfully published only after it has been acknowledged by all synchronous replicas.

[0057] S230: Consumption and preprocessing of events.

[0058] The event listening module, acting as a Kafka consumer group, subscribes to the `srs_project_events` topic. This consumer group can be deployed with multiple instances to consume event messages from different partitions in parallel, thereby achieving high processing capacity. Specifically: Consumption process: Each consumer instance pulls a batch of event messages from its assigned partition.

[0059] Deserialization and Validation: The consumer first deserializes the message body or byte stream into a JSON object. Then, based on the event type, it validates the event's data structure using the corresponding JSON Schema. If validation fails, the invalid event is moved to an "alarm queue," triggering an alarm and awaiting manual intervention.

[0060] Event distribution: For valid events that pass verification, the event listening module does not directly perform rule matching, but immediately pushes them to the entry point of the rule engine without modification. This allows the event listening module to focus on the stability and reliability of data access, while the rule engine focuses on complex logical matching calculations.

[0061] S300: When a combination of one or more business events detected meets the flow rules of the current project stage, the project stage will be automatically switched to the next project stage.

[0062] In this embodiment, the rule engine continuously receives the aforementioned event stream and efficiently matches it with all transition rules corresponding to the current stage of the project. Once the triggering conditions of a rule are fully met, the rule engine immediately generates a stage transition instruction to trigger subsequent system state changes. Specifically: S310: An incremental matching network is constructed using a variant of the Rete algorithm.

[0063] To avoid the inefficient "brute-force matching" approach of fully recalculating all rules for every event, the rule engine in this embodiment employs an optimized Rete algorithm. When the system starts up or the rule base changes, the JSON-formatted rules defined in S100 are compiled into an in-memory Rete network, which is a directed acyclic graph used to efficiently filter and connect events (referred to as "facts" in the Rete algorithm).

[0064] It should be noted that the variant used here differs from the standard Rete algorithm in the following three main aspects: 1. Project-level isolated Rete network instances: The standard Rete algorithm typically compiles all rules into a global, shared network. However, this variant dynamically creates and maintains a separate, lightweight Rete network instance in memory for each individual project (such as PROJ-SRS-V3). Before entering the rule engine, events are first routed to the corresponding network instance based on their project_id. This design significantly narrows the scope of event matching, avoids interference between unrelated project event streams, and substantially improves matching performance and scalability in high-concurrency, multi-project environments.

[0065] 2. Introduce state aggregation nodes (Gamma nodes): Traditional Rete network Beta nodes primarily handle AND connections. This variant introduces a "Gamma node" specifically for handling "macro events" such as "all sections of a document have been approved." The Gamma node is stateful; it subscribes to specific atomic events (such as `doc_section_approved`) and internally maintains a state counter or completion bitmap for each associated entity (such as `doc_id`). When a received atomic event causes the state of an entity to meet preset aggregation conditions (e.g., all sections are marked as approved), the Gamma node generates an aggregated "macro event" token and passes it to subsequent network nodes. This simplifies rule definition and cohedes complex aggregation logic within the network structure.

[0066] 3. Hash-optimized in-memory data structures: In the Beta nodes of the Rete network, the memory structure storing partial matching results (Tokens) is crucial for performance. A variant of this invention optimizes this by using an efficient hash map structure instead of simple lists for the left and right memory areas of the Beta node. When a new Token arrives at the left input of a Beta node, it uses the associated field in the join condition (such as project_id) as the hash key to directly look up the matching Token in the hash table in the right memory, achieving a time complexity close to O(1), rather than the potential O(n) linear scan in the standard implementation. This significantly accelerates join operations between nodes.

[0067] The specific implementation mechanism of incremental matching is as follows: When a new event (called a "fact" in Rete) enters the Rete network corresponding to its project: Alpha Network Filtering: Events first flow through the Alpha network, where each Alpha node checks if the event meets an atomic condition (e.g., Event.type=='legal_ip_review_completed'). Events that meet the condition are packaged into tokens and passed to subsequent nodes.

[0068] Beta Network Connection and State Update: When a token enters the Beta network, the system utilizes the hash optimization structure described above to attempt to connect the newly arrived token with only partially existing matching results in the memory on the other side. If a match is successful, a new, more complete token is generated and passed down; if a match fails, the new token is simply stored in the corresponding memory area. The entire process only calculates the changes brought about by the new event, without re-evaluating old events, reflecting the "incremental" characteristic. The system state (i.e., the set of tokens in the memory of each node) is only partially updated as events flow through it.

[0069] Specifically, taking the R10_TO_R20_SRS rule as an example: Building the Alpha network: For each atomic condition in the R10_TO_R20_SRS rule, the system creates a series of Alpha nodes, which are simple filters that only check the properties of a single event.

[0070] Similarly, AN3 will be created for the legal_ip_review_completed event, AN4 will be created for the executive_override_triggered event, and so on.

[0071] Building a Beta network: Beta nodes are used to process logical "AND" relationships in the rules. These nodes receive matching results (i.e., "Tokens", where a Token contains one or more matching events) from two parent nodes (which can be Alpha nodes or other Beta nodes) and perform concatenation operations.

[0072] For example, for the first AND combination in the rule, the system creates a Beta node BN1. BN1's left input is connected to the output of AN1, and its right input is connected to the output of AN2. BN1 internally has two memory areas, storing tokens from the left and right inputs respectively. When a new token arrives, it is matched against all tokens in the other memory area (e.g., checking if the project_id is the same). If a match is found, a new token containing both events is generated and passed down, and so on.

[0073] Next, a Beta node BN2 is created, with its left input connected to the output of BN1 and its right input connected to the output of AN3. BN2 is responsible for concatenating the results of the first two conditions with the third condition.

[0074] Endpoint Nodes and Logical OR: The logical OR relationship in a rule is achieved by sharing a single endpoint node.

[0075] At this point, a terminal node TN1 is created, representing the final activation of the entire Rete rule R10_TO_R20_SRS. The output of BN2 is then connected to TN1, and the output of AN4 (representing CTO special approval) is also directly connected to TN1. Thus, TN1 will be activated whether BN2 successfully generates a combined token containing three AND events, or AN4 matches a CTO special approval event.

[0076] S320: Event propagation and matching calculus in Rete networks.

[0077] Next, we simulate a series of events that occur during the "technology pre-research" phase of the PROJ-SRS-V3 project and observe their flow in the Rete network: Event E1 (Legal review passed): {event_type:'legal_ip_review_completed',payload:{review_result:'passed'}} The event entered the network, passed the AN3 test, and AN3 recorded E1 in its Alpha memory and generated a token T1={E1}, which was passed to the right input of BN2. BN2 stored T1 in its right memory. At this point, the network state was stable and awaited more events.

[0078] Event E2 (Performance test passed): {event_type:'performance_test_completed',payload:{tps:5280}} The event passes the test of AN2, generates a token T2={E2}, and passes it to the right input of BN1. BN1 stores T2 in its right memory.

[0079] Event E3 (Document Approval Aggregation): After the system aggregates the approval events of all chapters, it generates a doc_aggregate_approval event. This event passes the test of AN1 and generates a Token T3={E3}, which is passed to the left input of BN1.

[0080] Beta node BN1 activated: When T3 arrives at BN1's left input, BN1 immediately checks its right memory. It finds T2, and both T2 and T3 have the project_id PROJ-SRS-V3. After a successful connection, BN1 generates a new combination TokenT4={E3,E2} and passes it to BN2's left input.

[0081] Beta node BN2 activation: When T4 arrives at BN2's left input, BN2 checks its right memory. It finds T1, and the item ID matches. After a successful connection, BN2 generates the final combined token T5={E3,E2,E1} and passes it to the terminal node TN1.

[0082] Terminal node TN1 activation: TN1 is activated and immediately issues an atomic instruction to the stage flow execution module.

[0083] Stage Switching: After receiving the instruction, the stage transition execution module updates the current_stage_id field of the PROJ-SRS-V3 record in the projects table from 10 to 20 in the database transaction and records the transition log.

[0084] S330: The distributed rule engine uses a consistent hashing sharding algorithm to achieve load balancing.

[0085] To handle scenarios where tens of thousands of projects run simultaneously, this invention employs a distributed deployment scheme, distributing projects and their event flows across multiple rule engine nodes for processing. Specifically: Hash Ring and Virtual Nodes: The system maintains a virtual hash ring ranging from 0 to 2^32-1. Assume four physical rule engine nodes are deployed (N1, N2, N3, N4). 128 virtual nodes are created for each physical node. A suffix (e.g., N1#1, N1#2, ..., N1#128) is appended to the node ID, and its SHA-1 hash value is calculated. This virtual node's position on the ring is determined by its hash value, resulting in 4 * 128 = 512 virtual nodes evenly distributed across the ring.

[0086] Project Routing: For the PROJ-SRS-V3 project, the system calculates the SHA-1 hash value of its ID, obtaining a 32-bit integer, assuming H_proj = 1234567890. The system then finds the position 1234567890 on the hash ring and searches clockwise, encountering the first virtual node, let's say N3#57. Therefore, all events of the PROJ-SRS-V3 project will be directed to physical node N3 for processing by an upstream router or gateway. Afterwards, N3's memory will load and maintain all the Rete networks required for the current phase (technical pre-research) of the PROJ-SRS-V3 project.

[0087] Elastic Scaling: If the system detects that N3 is overloaded, the administrator can add a new physical node N5. N5's 128 virtual nodes are added to the hash ring. For example, projects that were originally part of N3 will now find their hash value to a virtual node on N5 as the first node in a clockwise direction. As a result, the event streams and Rete network state (tokens in memory) of these projects will smoothly migrate to N5. This process is imperceptible to most projects (such as PROJ-SRS-V3, if its position is unaffected), only affecting those projects whose hash values ​​fall before the new virtual node on N5, thus minimizing disruption to the entire system.

[0088] S340: A deterministic adjudication mechanism for handling rule conflicts.

[0089] In complex processes, multiple rules may be satisfied simultaneously, and conflicts can be resolved according to preset rules.

[0090] For example, suppose that in addition to R10_TO_R20_SRS (priority 100), there is also an emergency rule R10_TO_HALT_SRS (priority 100), whose trigger condition is the budget_usage_exceeded event. At 2024-05-21T10:00:06.000Z, TN1 is activated due to the above combination of events E1, E2, and E3. At the same time, at 2024-05-21T10:00:06.001Z, the financial system sends a budget_usage_exceeded event, activating the terminal node TN2 of R10_TO_HALT_SRS.

[0091] At this point, the following conflict resolution procedure will be executed: Priority comparison: The conflict resolution module found that the two activated rules R10_TO_R20_SRS and R10_TO_HALT_SRS both had a priority of 100, and could not be decided.

[0092] Specificity comparison: The regular path of R10_TO_R20_SRS requires a combination of 3 events, while R10_TO_HALT_SRS only requires 1 event. Therefore, R10_TO_R20_SRS has higher specificity.

[0093] The system ruled that the more specific R10_TO_R20_SRS should be processed first. At this point, a phase transition instruction was issued, and the project entered the "core development" phase, while the activation of R10_TO_HALT_SRS was ignored.

[0094] Alternate Decision: If the specificity is also the same, the system compares the timestamps of the last event activating the rule and selects the rule with the updated timestamp. If the timestamps are still exactly the same, the lexicographical order of the rule IDs is compared, and so on. This decision tree guarantees the consistency and predictability of the system's behavior under any concurrent conflicts.

[0095] S400: When switching project phases, it automatically extracts data from the source phase according to preset data mapping rules, performs format conversion, and injects the converted first data into the target phase.

[0096] In this embodiment, the following sub-steps are specifically included: S410: Configure data mapping rules.

[0097] When configuring the flow rule R10_TO_R20_SRS, the project template administrator also associated it with a set of data mapping rules. The business objective is to automatically populate the "core technical components" and their "performance index requirements" identified in the "Technical Feasibility Analysis Report" into the "Core Development Task Breakdown" to be created in the new stage, as key performance indicators (KPIs) that the development team must adhere to.

[0098] S420: Execute the data mapping process.

[0099] Once the stage transition instruction is confirmed for execution, the data mapping module is immediately activated and executes the following process: Data extraction: The module first loads the latest version of the structured content (JSON format) of the "Technical Feasibility Analysis Report" from the document library.

[0100] For example, The module successfully extracted an array containing two component objects using the JSONPath expression: $.sections[?(@.id=='sec-core-components')].content.components[*] Data transformation: The module iterates through the extracted array and applies the function chain defined in transformations to each object: Processing the first component object: CONCAT: "Core Components - " + "User Authentication Center" + "Performance Metrics" → "Core Components User Authentication Center Performance Metrics" *REGEX_EXTRACT(pattern1): In "peak recognition" The expression "(\d+\.?\d*)→"5000" is matched within this expression. *REGEX_EXTRACT(pattern2): In "peak recognition" The expression "[a-zA-Z / ]+$→"TPS" (dimensionless, but matches letters) matches the expression "[a-zA-Z / ]+$" (in this context, "TPS" is a string that matches letters). *MAP:"P0" → "Highest" Processing the second component object: CONCAT:...→"Core Components" Real-time recommendation engine Performance indicators *REGEX_EXTRACT(pattern1): Matches "20" in "single recommendation time ≤ 20ms". *REGEX_EXTRACT(pattern2): Matches "ms" in "single recommendation time ≤ 20ms". *MAP:"P1"→"High" After conversion, we get an array containing two new structure objects, ready for injection.

[0101] Data injection and traceability link establishment: The module loads the HTML template for the "Core Development Task Breakdown" from the template library based on the target_doc_template_id. This template contains an empty table body.

[0102] The module executes the XPath expression / / div[@id='kpi-section'] / table / tbody and locates the kpi-tbody element.

[0103] Then, the module iterates through the transformed data array, uses target_element_template to dynamically generate HTML fragments, and attaches traceable metadata.

[0104] The first element generated: The second element generated has a similar data-* attribute.

[0105] These generated elements are inserted into the kpi-tbody, completing the data injection. When a user views this new document on the front-end interface, these table rows can be specially rendered, for example, as small link icons. Clicking the icon will cause the system to parse the data-* attributes, automatically open the "Technical Feasibility Analysis Report," and highlight the original "User Authentication Center" entry, achieving one-click traceability from the target to the source.

[0106] S500: When switching project phases, it automatically triggers the task assignment, permission configuration, document template loading, and notification push of the next phase.

[0107] In this embodiment, this step is executed in parallel with S400 to automate all necessary management actions after the phase switch, eliminating the management vacuum period. Specifically: S510: Configure linkage operation rules.

[0108] When configuring the R10_TO_R20_SRS rule, the administrator also defined a series of linked_actions.

[0109] S520: Execute the linkage operation procedure.

[0110] Once the phase transition is confirmed, the linked execution module is activated. It parses the linked_actions array and sends instructions to each internal microservice.

[0111] Automatic task assignment: The module sends a command to the task management service, requesting the creation of a task for the PROJ-SRS-V3 project using the task template tpl-dev-kickoff.

[0112] Example of task template tpl-dev-kickoff content (YAML format): -task_name:"Set up the core development environment" Description: "Includes local and test environments for all microservices..." default_due_days: 3-task_name:"Creating a code repository and CI / CD pipeline" Description: "Create Git repositories for all backend services based on the architecture design..." default_due_days:2 The task management service then creates these two tasks based on the template and assigns them to all members of the "Development Supervisor" role group according to the assignee_group_role.

[0113] Automatic permission configuration: The module then sends a command to the Identity and Access Management (IAM) service. The IAM service parses the command and locates all user members under the DevelopmentTeam role group. Then, the IAM service grants these users Developer permissions (read and write access) for all GitLab code repositories with names matching PROJ-SRS-V3 / *. Simultaneously, it obtains the document ID of the newly created Core Development Task Breakdown Sheet and grants edit permissions to the user group.

[0114] Automatic push notifications: The module sends instructions to the notification service.

[0115] The notification service loads the message template msg-dev-stage-start, the content of which is: Project Update: {project_name} has automatically entered the {new_stage_name} stage at {timestamp}. Related tasks have been created; please check your development team. The new stage document, 《{target_doc_name}》, has been generated, containing the key KPIs mapped from previous reports. The notification service populates all placeholders with the current project context, then sends a formatted Markdown message to the #proj-srs-v3 channel via the Slack API, and sends an HTML-formatted email notification to members of all relevant roles via the mail gateway.

[0116] This achieves a highly automated and intelligent closed-loop process for project phase transitions.

[0117] Example 2 Unlike Embodiment 1, this embodiment anticipates the resource load bottleneck of the target execution team in the next stage before a hard switch occurs in the project phase, and proactively intercepts and smooths the flow instructions to solve the technical problem of the automatic flow of existing technologies causing a sudden accumulation of tasks downstream. This achieves the beneficial effect of cross-stage resource load distribution and ensuring the continuity of project execution.

[0118] Specifically, the instructions are generated during the rule engine's terminal node phase, but before being submitted to the database, the following steps are performed: S610: Extract target stage prediction data When the phase transition execution module receives a transition instruction pointing to the target phase (e.g., "Phase 20: Core Development"), the system first intercepts the direct execution of the instruction. Then, the system calls the resource planning service to obtain the initial task set associated with "Phase 20".

[0119] For example, for the PROJ-SRS-V3 project, the system reads the preset "Core Development Initial Task Template" and extracts five key tasks that must be started within three days before the start of the phase. The system extracts the estimated_hours field defined in these tasks, sums them up, and obtains the estimated total workload. This assumes an estimated total workload. h.

[0120] The system then queries the Identity and Access Management (IAM) service and identifies the backend development core team as the group responsible for these tasks. Therefore, the system sets a prediction time window. h (hours), and query the scheduling system and leave system to calculate the available working hours for the group members in the next 72 hours. This assumes the group has 4 available members. After deducting scheduled meetings and leave, the available working hours are calculated. h.

[0121] Simultaneously, the system queries the project concurrency matrix to calculate the estimated overlapping time of other high-priority projects (such as the "Double Eleven promotion stability maintenance project") that the backend development core team needs to process in parallel within the aforementioned predicted time window. Assuming the query yields overlapping execution times h.

[0122] S620: Calculation of Resource Congestion Risk Perform a resource constraint assessment using the following formula to determine the risk of resource congestion. :

[0123] In the formula, the first term This is the ratio of labor demand to available labor hours, representing the basic resource saturation level. In the second item, As a time penalty factor, this ensures that the system can make a highly sensitive circuit breaker response when faced with multiple high-priority projects competing for the same resource. It should be noted that the value of γ is not fixed, but is determined through one or more of the following methods based on the specific circumstances of the organization and the business scenario: 1. Empirical fitting based on historical data: This is determined by analyzing massive amounts of data from past projects within the organization, especially development efficiency data during multi-project parallel processing (such as code submission frequency, task completion cycle, defect fix time, etc.). At this point, a statistical model can be built to quantify the actual loss of engineer time caused by "context switching." For example, analysis might reveal that when a team handles two high-priority projects simultaneously, its effective output is not 100%, but rather drops to approximately 80%. The value of γ can be calibrated so that when ΔToverlap reflects this parallel situation, the exp(γΔToverlap) term accurately simulates this 20% efficiency loss. γ = 0.05h -1 This example value means that for every additional hour of parallel overlap time, the exponential penalty term increases by approximately 5.12%, simulating the non-linear growth of context switching costs.

[0124] 2. Simulation modeling and stress testing: Before the system goes live, a simulation model can be built to simulate resource request scenarios under different project concurrency levels and ΔToverlap. At this point, by adjusting the value of γ, the trigger frequency of the system's throttling mechanism and the queuing length of the resource pool can be observed. A γ value that achieves the optimal balance between ensuring project workflow efficiency and avoiding excessive resource overdraft can be selected.

[0125] 3. Configurable business parameters and dynamic adaptive adjustment: In a practical system, γ is designed as a configurable system parameter, allowing the Project Management Office (PMO) or system administrator to adjust it based on resource strategies for different business phases (e.g., regular development phase vs. year-end sales promotion preparation phase). Furthermore, the system can incorporate machine learning models that continuously learn about the project's actual execution efficiency and resource usage, dynamically fine-tuning the γ value based on predicted project delay risks to achieve adaptive management of resource congestion risks.

[0126] The above methods ensure that the setting of the γ value is supported by sufficient theory and data, so that the calculation results of the Rpot risk potential can truly reflect the organization's resource health status.

[0127] S630: Throttling Threshold Determination and Suspension Compensation Calculation The system will calculate the resource congestion risk potential. With preset throttling threshold Compare them.

[0128] For example, setting weight coefficients , Time penalty factor Then, the extracted values ​​are substituted into the formula for calculation: ≈

[0129] Assuming a throttling threshold Due to the actual calculations obtained Therefore, it is determined that the resource pool in the current target stage is in a state of severe congestion warning.

[0130] Based on the above judgment results, the system blocks the submission action of the transit_stage command in S300 to the database. Subsequently, the system serializes the flow command token containing the trigger source information and target stage information, stores it in the Redis suspended queue in memory, and marks the status as THROTTLED.

[0131] Simultaneously, the system calls the API to send a resource rebalancing event to the resource scheduling module. This event generates a high-priority scheduling task on the project director's dashboard named "PROJ-SRS-V3 flow blocking: Please release backend development core group resources".

[0132] Afterward, the system starts a background daemon process that polls every 15 minutes, continuously re-collecting data from S610 and re-executing the formula calculations from S620. This process occurs when team members complete other tasks. Increase, or It naturally decreases over time, making the recalculated value... When the value drops below 0.85, the daemon will retrieve the intercepted flow instructions from the Redis suspended queue and resume the execution of the original S400 data mapping and S500 action linkage logic, thereby ensuring the smooth flow of project management.

[0133] Example 3 This embodiment provides an automated workflow and data association system for project-wide management. This system can be deployed as a cluster of collaborative microservices, running on a cloud platform or a private enterprise data center. At the hardware level, the system may include multiple servers, each equipped with high-performance processors, large-capacity storage, high-speed network interfaces, and other standard computing components. At the software functional module level, the system includes: The rules configuration module typically consists of a front-end application based on a modern web framework (such as React or Vue.js) and a back-end service that provides a RESTful API. It provides project administrators with a graphical rules designer, allowing users to intuitively build complex logical rules, data mappings, and linked operations in S100 through drag-and-drop, connection, and form filling, and serialize the final configuration into JSON format and store it in the rules database.

[0134] The event listening module typically serves one or more highly available Kafka consumers. This module is responsible for subscribing to business event topics in S200, deserializing, formatting, and performing preliminary preprocessing on the consumed messages, and then forwarding valid events to the stage flow execution module.

[0135] The phase flow execution module contains a high-performance rule engine based on a variant of the Rete algorithm, which can be implemented using an open-source framework. This engine compiles rules from the database into an in-memory Rete network, receives and processes event streams to perform incremental matching of S310 and S320. Simultaneously, this module integrates the consistent hashing routing logic of S330 and the conflict resolution mechanism of S340 to ensure stable execution in a large-scale distributed environment. Upon successful matching, it updates the project's main state and activates downstream modules.

[0136] The data mapping module receives instructions from the stage flow execution module. These instructions typically include the triggering rule ID and project context. This module incorporates a JSONPath parser, an XPath processor, and a library of extensible data transformation functions. It is responsible for executing the complete S400 workflow, specifically including retrieving data from source document repositories (such as MongoDB), performing transformations, injecting data into target document repositories (such as collaborative editing systems), and logging detailed operation logs and data versions.

[0137] The linkage execution module is used to translate decisions into actions. It also receives instructions from the stage flow execution module and, as an API client, integrates with other business systems within the organization (such as Jira, GitLab, IAM systems, Slack, enterprise email, etc.). It parses the linkage operations defined in S500 and calls the corresponding system's API to programmatically complete a series of management actions such as task creation, permission changes, and message pushes.

[0138] These modules communicate asynchronously via well-defined APIs (such as gRPC or RESTful APIs) or message queues.

[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0140] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0141] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0142] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0143] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0144] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0145] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0146] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0147] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

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

[0150] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for automatic phase transition and data association in project lifecycle management, characterized in that, include: Obtain the workflow rules for each stage of the project, wherein the triggering conditions for the workflow rules consist of a combination of multiple business events; Real-time monitoring of the aforementioned business events during project execution; When a combination of one or more of the business events detected satisfies the flow rules of the current project stage, the project stage is switched to the next project stage.

2. The method according to claim 1, characterized in that, The method further includes: When switching project phases, one or more source data items generated in the original project phase are extracted according to preset data mapping rules. The source data is format-converted to obtain the first data; The first data is injected into the documents or tasks of the target project phase, and a source data link is established for each injected data item, which is used for data traceability.

3. The method according to claim 2, characterized in that, The data mapping rules use JSONPath expressions to define the extraction path of the source data and XPath expressions to define the injection location path in the document or task of the target project stage; and the format conversion includes one or more of the following: text concatenation functions, format conversion functions, arithmetic operation functions, and value mapping functions.

4. The method according to claim 1, characterized in that, The method further includes: When multiple flow rules are satisfied simultaneously, conflict resolution is performed according to the priority of the flow rules; if the priorities are the same, a selection is made according to a preset deterministic decision rule; wherein, the deterministic decision rule includes: Compare the specificity of the rules and select the rules whose triggering conditions contain more atomic events; If the specificity is the same, compare the timestamps of the last event in the activation rules and select the rule activated by the event with the latest timestamp; If the timestamps are the same, the rule is compared lexicographically based on its unique identifier, and the rule with the higher sort order is selected.

5. The method according to claim 1, characterized in that, Before switching the project stage to the next stage when a combination of one or more monitored business events satisfies the flow rules of the current project stage, the method further includes: Retrieve the preset task template associated with the next project phase; The preset task template is parsed to extract the initial task set and its corresponding estimated total workload. Obtain the available man-hour capacity of the target resource pool within a preset prediction time window, wherein the target resource pool is used to execute the initial task set; Based on the estimated total workload and the available man-hour capacity, the risk of resource congestion is determined; When the risk of resource congestion exceeds a preset throttling threshold, the stage transfer instruction is intercepted and placed in a memory suspend queue.

6. The method according to claim 5, characterized in that, After placing the stage transition instructions in the memory suspension queue, the method further includes: The first available working hours capacity is reacquired according to the preset polling cycle, and the first resource congestion risk is determined based on the first available working hours capacity. When the risk of congestion of the first resource is lower than the preset throttling threshold, the stage transition instruction is released from the memory suspend queue, and the project stage is switched to the next project stage.

7. A system for automatic phase transition and data association in project lifecycle management, characterized in that, include: The rule configuration module is used to obtain the flow rules of the project phase. The triggering conditions of the flow rules are composed of a combination of multiple business events. The event listening module is used to monitor the business events during project execution in real time. The phase transition execution module is used to switch the project phase to the next project phase when a combination of one or more sets of business events monitored satisfies the transition rules of the current project phase.

8. The system according to claim 7, characterized in that, The system also performs the following steps: When switching project phases, one or more source data items generated in the original project phase are extracted according to preset data mapping rules. The source data is format-converted to obtain the first data; The first data is injected into the documents or tasks of the target project phase, and a source data link is established for each injected data item, which is used for data traceability.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program is configured to perform the method described in any one of claims 1 to 6 when executed.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 6.

Images