Project process and product demand information fusion method and device and medium

Abstract

The invention discloses a project process and product demand information fusion method and device and a medium, and relates to the field of data processing. The method comprises the following steps: obtaining product demand information, decomposing the product demand information, and constructing a demand hierarchy BOM tree formed by a plurality of demand nodes; configuring a demand type and a predicted working hour for each demand node in the demand hierarchy BOM tree; based on the standard development process template, performing WBS decomposition on the target project to generate a plurality of project tasks; associating a demand node in the demand hierarchy BOM tree with the project task, and matching a corresponding standard development process template for the project task based on a demand type corresponding to the demand node; and calculating the predicted working hours of the demand nodes associated with each project task based on the predicted working hours of the sub demand nodes and the total predicted working hours of the parent demand nodes, and setting a project period for each project task. By implementing the technical scheme provided by the invention, the planning accuracy of the project plan is improved.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method, apparatus, and medium for integrating project process and product demand information. Background Technology

[0002] In the research and development of modern complex products, especially software and smart hardware, project management plays a crucial role. The core of project management lies in developing accurate and feasible project plans, breaking down project work into a series of specific project tasks, and rationally scheduling the timelines, resources, and dependencies of these tasks.

[0003] In existing project management practices, project planning and product requirement management are often two relatively independent stages. Project managers typically construct the Work Breakdown Structure (WBS) and estimate task durations based on high-level product feature lists and personal experience. This approach results in a lack of direct and clear correspondence between project tasks and specific product requirement details, making the basis for project planning estimations weak. This makes the plan prone to frequent adjustments during project execution due to misunderstandings or changes in requirements, leading to schedule delays and cost overruns. Therefore, existing methods suffer from low accuracy in project planning. Summary of the Invention

[0004] This application provides a method, apparatus, and medium for integrating project process and product demand information, thereby improving the accuracy of project planning.

[0005] A first aspect of this application provides a method for integrating project process and product requirement information. The method includes: acquiring product requirement information and decomposing the product requirement information to construct a requirement-level BOM tree composed of multiple requirement nodes; configuring a requirement type and estimated working hours for each requirement node in the requirement-level BOM tree; based on the hierarchical structure of the requirement-level BOM tree, summarizing the estimated working hours of sub-requirement nodes from bottom to top to calculate and obtain the total estimated working hours of the parent requirement node; establishing a standard development process template library corresponding to each requirement type, the standard development process template library containing multiple standard development process templates, wherein each standard development process template corresponds to a requirement type; performing a Work Breakdown Structure (WBS) decomposition on the target project based on the standard development process templates to generate multiple project tasks; associating the requirement nodes in the requirement-level BOM tree with the project tasks, and matching corresponding standard development process templates for the project tasks based on the requirement types corresponding to the requirement nodes; calculating the estimated working hours of the requirement nodes associated with each project task based on the estimated working hours of the sub-requirement nodes and the total estimated working hours of the parent requirement node, and setting a project cycle for each project task.

[0006] By adopting the above technical solution, product requirement information is acquired and decomposed to construct a hierarchical BOM tree consisting of multiple requirement nodes. This clearly shows the hierarchical and dependency relationships between product requirements, providing a structured foundation for subsequent requirement management and project planning. Simultaneously, by configuring requirement type and estimated time for each requirement node in the hierarchical BOM tree, and by summarizing the estimated time of sub-requirement nodes from bottom to top based on the hierarchical structure of the BOM tree to calculate the total estimated time of the parent requirement node, the workload of each requirement node can be accurately estimated, providing a quantitative basis for the allocation of project task time. Furthermore, by establishing a standard development process template library corresponding to each requirement type, and by performing WBS decomposition on the target project based on the standard development process templates to generate multiple project tasks, requirement-driven project task planning can be achieved, ensuring that project tasks match requirement types and improving the targeting and effectiveness of project execution. Finally, by associating requirement nodes in the requirement hierarchy BOM tree with project tasks, and setting project cycles for project tasks based on the estimated working hours of requirement nodes, bidirectional traceability of requirements and tasks can be achieved, ensuring that project plans and requirement changes remain synchronized, and improving the precision, accuracy, and controllability of project management.

[0007] Optionally, the step of obtaining product requirement information and decomposing the product requirement information to construct a requirement-level BOM tree composed of multiple requirement nodes specifically includes: obtaining product requirement information and classifying the product requirement information to obtain a structured requirement document; performing natural language processing on the requirement document, extracting keywords and performing semantic analysis to identify requirement points in the requirement document; constructing a requirement dependency graph based on the dependency relationships between the requirement points, where nodes in the requirement dependency graph represent requirement points and edges represent dependency relationships between requirement points, and the dependency relationships include contextual relationships and semantic dependencies; performing cluster analysis on the requirement dependency graph based on the dependency relationships to obtain multiple requirement clusters; constructing a requirement decomposition tree with the product requirement information as the root node, each requirement cluster as an intermediate layer node, and requirement points within each requirement cluster as leaf nodes; establishing an initial requirement-level BOM tree based on the structure of the requirement decomposition tree, where the requirement clusters correspond to BOM sub-items of the requirement-level BOM tree, and the requirement points correspond to components of the BOM sub-items; and optimizing the initial requirement-level BOM tree to obtain the requirement-level BOM tree.

[0008] By employing the aforementioned technical solutions, product requirement information is acquired and categorized to obtain structured requirement documents, improving the readability and comprehensibility of the requirement information and laying the foundation for subsequent requirement analysis. Natural language processing is applied to the requirement documents to extract keywords and perform semantic analysis, identifying requirement points within the documents. This allows for the rapid and accurate extraction of key requirement points, reducing the workload of manual analysis. A requirement dependency graph is constructed based on the dependencies between requirement points, and cluster analysis is performed on this graph to obtain multiple requirement clusters. This reveals the inherent connections between requirements, providing a basis for prioritizing requirements and analyzing the impact of requirement changes. A requirement decomposition tree is constructed using product requirement information as the root node, requirement clusters as intermediate nodes, and requirement points within each cluster as leaf nodes. This forms a clear hierarchical requirement structure, facilitating requirement decomposition and management. Finally, an initial requirement hierarchy BOM tree is established based on the structure of the requirement decomposition tree, and this initial requirement hierarchy BOM tree is optimized to obtain a higher-level requirement BOM tree. This further refines the hierarchical relationships of requirements, optimizes the requirement structure, and improves the efficiency and quality of requirement management.

[0009] Optionally, optimizing the initial requirement-level BOM tree to obtain the requirement-level BOM tree specifically includes: calculating the requirement complexity index for each requirement node based on the requirement type and the estimated working hours; performing structured analysis on the requirement-level BOM tree to calculate the structured complexity index for each requirement node, wherein the structured complexity index includes a depth index, a breadth index, and a coupling index; calculating the comprehensive complexity index for each requirement node based on the requirement complexity index and the structured complexity index; and merging requirement nodes with a comprehensive complexity index lower than a first threshold and splitting requirement nodes with a comprehensive complexity index higher than a second threshold in the initial requirement-level BOM tree to obtain the requirement-level BOM tree.

[0010] By adopting the above technical solutions, and calculating the requirement complexity index for each requirement node based on the requirement type and estimated working hours, the complexity of the requirement can be quantitatively assessed, providing a reference for requirement prioritization and resource allocation. Through structured analysis of the requirement hierarchy BOM tree, the structured complexity index of each requirement node is calculated, including depth, breadth, and coupling indices. This allows for the assessment of the complexity and importance of the requirement node within the overall requirement structure from different dimensions. By comprehensively considering the requirement complexity index and the structured complexity index, the comprehensive complexity index of each requirement node is calculated, providing a comprehensive assessment of the requirement node's complexity and a quantitative basis for requirement optimization. Finally, by merging requirement nodes with a comprehensive complexity index below the first threshold and splitting requirement nodes with a comprehensive complexity index above the second threshold in the initial requirement hierarchy BOM tree, an optimized requirement hierarchy BOM tree is obtained. This simplifies the requirement structure, improves requirement manageability, and ensures that complex requirements are fully decomposed and addressed, thereby improving the quality and efficiency of requirement implementation.

[0011] Optionally, the step of decomposing the target project into a Work Breakdown Structure (WBS) based on the standard development process template to generate multiple project tasks specifically includes: parsing the standard development process template to extract the standard task decomposition structure, task attributes, and task deliverables, and constructing a standard WBS template; adding, deleting, or modifying corresponding task nodes on the standard WBS template according to the task requirements of the target project to obtain a target WBS template; determining the hierarchical task structure of the target project based on the target WBS template; traversing the hierarchical task structure and decomposing task nodes level by level until they are decomposed into work packages that can be directly assigned and executed to obtain the project tasks.

[0012] By employing the aforementioned technical solutions, the standard development process template is analyzed to extract the standard task breakdown structure, task attributes, and task deliverables. A standard Work Breakdown Structure (WBS) template is then constructed, forming a universal project task breakdown framework. This standardizes project management processes and improves the standardization of project execution. By adding, deleting, or modifying corresponding task nodes on the standard WBS template according to the target project's task requirements, a target WBS template is obtained. This allows for the rapid generation of a task breakdown structure that conforms to the characteristics of the target project, improving the efficiency of project planning. Based on the target WBS template, the hierarchical task structure of the target project is determined, forming a clear project task hierarchy that facilitates task decomposition and management. Finally, by traversing the hierarchical task structure and decomposing task nodes level by level until they are broken down into work packages that can be directly assigned and executed, project tasks are obtained. This decomposes project objectives into actionable task units, clarifies task boundaries and deliverables, and lays the foundation for project progress tracking and quality control.

[0013] Optionally, after setting the project cycle for each project task based on the total estimated working hours of the demand nodes associated with each project task, the method further includes: performing topological sorting of the project tasks based on the dependencies between the project tasks to generate a project task network diagram; using a critical path algorithm to identify critical task paths and non-critical task paths in the project task network diagram, and calculating the critical time of the critical task paths; adjusting the project cycle of non-critical tasks according to the non-critical task paths and the critical time of the projects to obtain an optimized project plan.

[0014] By adopting the above technical solutions, project tasks are topologically sorted based on their dependencies to generate a project task network diagram. This diagram visually displays the logical relationships and sequence of tasks, providing a basis for optimizing the project schedule. Using the critical path algorithm, critical and non-critical task paths are identified in the project task network diagram, and the critical time for each critical task path is calculated. This identifies key tasks affecting the overall project duration, providing a focus for project schedule control. Adjusting the project cycles of non-critical tasks based on their paths and critical times optimizes resource allocation, balances task load, and improves execution efficiency without impacting the overall project duration. Finally, generating an optimized project plan ensures the project is completed within a reasonable timeframe, maximizes resource utilization, and enhances the scientific and feasible nature of project management.

[0015] Optionally, the step of using the critical path algorithm to identify critical and non-critical task paths in the project task network graph and calculating the critical time of the critical task path specifically includes: initializing the earliest start time of each task node in the project task network graph to a preset value; traversing the project task network graph in a forward direction starting from the starting task node, calculating the earliest start time and earliest end time of each task node; initializing the latest end time of each task node in the project task network graph to the earliest end time of the project; and traversing the project task network graph in a reverse direction starting from the ending task node, calculating the earliest start time and earliest end time of each task node. The latest start time and latest end time of each node; for each task node, calculate the difference between the earliest start time and the latest start time as the total float of the task node; identify task nodes whose total float is within a preset float range as critical tasks, and identify task nodes whose total float is outside the preset float range as non-critical tasks; determine the path formed by the critical tasks as the critical task path, and determine the path formed by the non-critical tasks as the non-critical task path; take the earliest end time of the target task node on the critical task path as the critical time of the project, and the target task node is the last task node on the critical task path.

[0016] By adopting the above technical solutions, the earliest start time of each task node in the project task network diagram is initialized to a preset value. Starting from the initial task node, the project task network diagram is traversed forward to calculate the earliest start and earliest end times for each task node. This determines the earliest possible start and end times of project tasks, providing a benchmark for project schedule control. By initializing the latest end time of each task node in the project task network diagram to the earliest end time of the project, and starting from the end task node, the project task network diagram is traversed backward to calculate the latest start and latest end times for each task node. This determines the latest allowed start and end times of project tasks, providing constraints for project schedule optimization. By calculating the difference between the earliest and latest start times for each task node as the total float, the time flexibility of each task can be quantitatively evaluated, providing a basis for optimizing resource allocation. By identifying task nodes with total floats within a preset float range as critical tasks and task nodes with total floats outside the preset float range as non-critical tasks, the criticality of tasks can be quickly determined, providing a focus area for project management. Finally, by identifying the path consisting of critical tasks as the critical task path and the path consisting of non-critical tasks as the non-critical task path, and by taking the earliest end time of the target task node on the critical task path as the critical time of the project, the critical path affecting the total project duration can be clearly identified, providing decision support for project schedule optimization and risk management.

[0017] Optionally, adjusting the project cycle of non-critical tasks based on the non-critical task path and the project's critical time to obtain an optimized project plan specifically includes: calculating an adjustable time window for each non-critical task, the size of which is equal to the total float of the non-critical task; acquiring project resource pool information and the resource requirements of each project task, and generating a project resource load map based on the project task schedule before adjustment, identifying resource overload periods and resource idle periods; adjusting non-critical tasks within the resource overload periods based on the adjustable time window with resource load balancing as the goal, the adjustment including a delayed start strategy and an extended cycle strategy; and updating the planned start time, planned completion time, and project cycle of the non-critical tasks based on the adjustment results to generate the optimized project plan.

[0018] By employing the above technical solution, and calculating an adjustable time window for each non-critical task, the size of which is equal to the total float of the non-critical tasks, the adjustment space of each non-critical task can be quantitatively assessed, providing flexibility for optimizing project plans. By acquiring project resource pool information and the resource requirements of each project task, and generating a project resource load diagram based on the unadjusted project task schedule, resource overload periods and idle periods can be identified, providing a clear view of project resource usage and revealing resource bottlenecks and optimization opportunities. Based on the adjustable time window and aiming for resource load balancing, adjustments are made to non-critical tasks within resource overload periods. Using delayed start strategies and extended cycle strategies, resource allocation can be optimized, resource load smoothed, and resource utilization efficiency improved without affecting critical project times. Finally, by updating the planned start time, planned completion time, and project cycle of non-critical tasks based on the adjustment results, an optimized project plan is generated. This ensures on-time project completion while achieving reasonable resource allocation and efficient utilization, improving the precision and overall effectiveness of project management.

[0019] Secondly, embodiments of this application provide a device for fusing project process and product requirement information. The device includes one or more processors and a memory. The memory is coupled to the one or more processors and is used to store computer program code, which includes computer instructions. The one or more processors invoke the computer instructions to cause the device for fusing project process and product requirement information to perform the method described in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a device for integrating project process and product requirement information, cause the device to perform the method described in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a device for integrating project process and product requirement information, causes the device for integrating project process and product requirement information to execute the method described in the first aspect and any possible implementation thereof.

[0022] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. The above technical solution deeply integrates product requirements management with project planning, solving the problem of a lack of direct correspondence between project plans and requirements in existing technologies. Specifically, this solution constructs a hierarchical Bill of Materials (BOM) tree to decompose requirements into independent manageable units, configuring requirement type and estimated time for each requirement node; it combines a standard development process template library and WBS decomposition to associate requirement nodes with project tasks, ensuring a clear mapping between tasks and requirements; and it improves the accuracy and traceability of planning by summarizing time from the bottom up and automatically setting project cycles. This reduces plan adjustments caused by misunderstandings of requirements, significantly improving the accuracy of project planning, the efficiency of responding to requirement changes, and the rationality of resource allocation, thereby reducing the risk of schedule delays and cost overruns. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a method for integrating project process and product requirement information disclosed in an embodiment of this application; Figure 2 This is another flowchart illustrating a method for integrating project process and product requirement information disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a device for integrating project process and product requirement information provided in an embodiment of this application.

[0024] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0026] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple system devices refer to two or more system devices, and multiple screen terminals refer to two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] This application provides a method for integrating project process and product requirement information, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a method for integrating project process and product requirement information according to an embodiment of this application. The method is applied to a device, which is a server. The server can execute a program to integrate project process and product requirement information. The method includes steps S101 to S107, as follows: Step S101: Obtain product requirement information and decompose the product requirement information to construct a requirement hierarchy BOM tree consisting of multiple requirement nodes.

[0029] In step S101, product requirement information refers to the original data describing the functions, performance, constraints, etc. of the product to be developed, such as requirement documents, user stories, or specifications. A requirement node represents the smallest manageable independent requirement unit decomposed from the product requirement information. A requirement hierarchy BOM tree is a tree-like data structure used to represent the decomposition and hierarchy relationships between the overall product requirements and its sub-requirements at each level, where the root node represents the overall product, and the intermediate and leaf nodes represent the requirement nodes at each level.

[0030] Specifically, the server receives product requirement information files uploaded by users via a network interface. These files can be text documents, spreadsheets, or requirement specifications in a specific format. The server then activates its internal natural language processing engine to perform word segmentation, part-of-speech tagging, and syntactic analysis on the content of the product requirement information file to identify noun phrases and verb phrases representing specific requirement points. Next, the server constructs a dependency network between requirement points by analyzing co-occurrence relationships, contextual logic, and semantic associations. Based on this dependency network, the server uses clustering algorithms, such as K-means or hierarchical clustering, to aggregate closely related requirement points into requirement clusters. Finally, the server constructs a hierarchical structure from top to bottom, with the overall product as the root node, the identified requirement clusters as parent requirement nodes, and the specific requirement points within each cluster as child requirement nodes. This hierarchical structure is stored in the form of a Bill of Materials (BOM), thus forming a requirement-level BOM tree.

[0031] In one possible implementation, product requirement information is obtained and decomposed to construct a requirement-level BOM tree consisting of multiple requirement nodes. Specifically, this includes steps S1011-S10110, as follows: Step S1011: Obtain product requirement information and classify it to obtain a structured requirement document.

[0032] In step S1011, a structured requirements document refers to a standardized document generated by organizing and arranging raw, unformatted product requirements information according to preset categories and levels, such as dividing it into chapters such as functional requirements, performance requirements, and interface requirements.

[0033] Specifically, the server first obtains the product requirement information submitted by the user through a file upload interface. This information is typically an unprocessed raw document, such as a Word or PDF file. The server's internal document parsing program reads the content of the file and classifies the text content using predefined rules or machine learning models. For example, the server identifies headings, lists, and paragraphs in the document and categorizes corresponding content paragraphs based on sentences containing specific keywords such as functionality, performance, and interface. After processing, the server generates an internally represented, structured requirements document with clear chapter and paragraph divisions. This document is stored in formats such as XML or JSON for subsequent automated processing.

[0034] Step S1012: Perform natural language processing on the requirements document, extract keywords and perform semantic analysis to identify the requirements points in the requirements document.

[0035] In step S1012, natural language processing refers to the application of a series of algorithms and technologies that enable computers to understand, interpret, and generate human language. Keywords refer to nouns or verb phrases in the requirements document that represent core concepts or functions. Semantic analysis refers to the process of deeply understanding the logical relationships and true intentions between keywords. A requirement point refers to the smallest, indivisible, independent functional or characteristic unit identified from the requirements document after natural language processing and semantic analysis.

[0036] Specifically, the server invokes a natural language processing engine to process the structured requirements document generated in step S1011. First, the server performs word segmentation, breaking down continuous text into individual words. Next, it performs part-of-speech tagging, identifying the part of speech of each word, such as noun, verb, or adjective. The server extracts keywords representing the core requirements using either the TF-IDF algorithm or the TextRank algorithm. Subsequently, the server performs semantic analysis, utilizing techniques such as dependency parsing to identify the subject-verb-object relationships between keywords, thereby understanding the complete action and object, and forming a clear requirement. For example, for the sentence "users should be able to search for products," the server will identify "user," "search," and "product," combining them into a clear requirement: providing a product search function.

[0037] Step S1013: Construct a requirement dependency graph based on the dependencies between requirement points. Nodes in the requirement dependency graph represent requirement points, and edges represent the dependencies between requirement points. Dependencies include contextual relationships and semantic dependencies.

[0038] In step S1013, the requirement dependency graph is a graphical data structure used to visually represent the interrelationships between various requirement points. Nodes in the graph represent requirement points, and edges connecting nodes represent dependencies between requirement points. Dependencies include contextual dependencies and semantic dependencies. Contextual dependencies refer to the proximity of requirement points within the original document, while semantic dependencies refer to the fact that the implementation of one requirement point is a prerequisite for the implementation of another requirement point.

[0039] Specifically, based on all the requirement points extracted in step S1012, the server begins to construct a requirement dependency graph. The server creates a node for each requirement point. Then, the server traverses all requirement point pairs to determine if an edge exists between the nodes. For contextual relationships, the server checks whether the two requirement points originate from the same or similar paragraphs in the structured requirements document. If so, an edge representing the contextual relationship is established between the two nodes. For semantic dependencies, the server uses a pre-defined rule base or knowledge graph to make judgments. For example, if the server identifies requirement point A as user login and requirement point B as changing the user password, and the server's rule base defines that password changing must be performed while logged in, then an edge representing the semantic dependency is established between the nodes of requirement point A and requirement point B, pointing from A to B.

[0040] Step S1014: Perform cluster analysis on the requirement dependency graph based on the dependency relationship to obtain multiple requirement clusters.

[0041] In step S1014, cluster analysis refers to an unsupervised learning process that groups data objects into multiple clusters or sets, such that objects within the same cluster are similar to each other, while objects in different clusters are different from each other. A demand cluster refers to a set of demand points obtained by cluster analysis of the demand dependency graph, where the demand points in the set are highly related in function or logic.

[0042] Specifically, the server takes the demand dependency graph constructed in step S1013 as input and applies a graph clustering algorithm, such as the Louvain algorithm in community detection. This algorithm effectively identifies tightly connected groups of nodes in the graph by optimizing the modularity index. The server executes the algorithm to divide the nodes in the demand dependency graph, i.e., demand points, into different communities. Each identified community constitutes a demand cluster. For example, demand points related to user accounts, such as user registration, user login, and password retrieval, will be grouped into the same demand cluster by the algorithm because there are many dependency edges tightly connecting these nodes in the demand dependency graph.

[0043] Step S1015: Construct a requirement decomposition tree with product requirement information as the root node, each requirement cluster as the intermediate layer node, and the requirement points within the requirement cluster as the leaf nodes.

[0044] In step S1015, the requirement decomposition tree refers to a tree-like structure used to illustrate how the overall product requirements are decomposed layer by layer into requirement clusters, and finally refined into specific requirement points. The root node represents the entire product, the intermediate level nodes represent requirement clusters, and the leaf nodes represent specific requirement points within a requirement cluster.

[0045] Specifically, the server begins constructing a new tree-like data structure. First, the server creates a root node, named after the product name defined in the product requirement information. Next, the server traverses all requirement clusters obtained in step S1014. For each requirement cluster, the server creates a new child node under the root node as an intermediate-level node, using the general name or number of the requirement cluster as its name. Then, the server traverses all requirement points contained within the requirement cluster, creating a leaf node under the corresponding intermediate-level node for each requirement point. Through this process, the server generates a complete requirement decomposition tree that reflects the macro-to-micro decomposition relationship of requirements.

[0046] Step S1016: Based on the structure of the requirement decomposition tree, establish an initial requirement hierarchy BOM tree. Requirement clusters correspond to BOM sub-items in the requirement hierarchy BOM tree, and requirement points correspond to the components of BOM sub-items.

[0047] In step S1016, the initial requirement hierarchy BOM tree refers to the data structure that represents and stores the structure of the requirement decomposition tree in the format of a Bill of Materials (BOM). BOM sub-items correspond to intermediate-level nodes in the requirement decomposition tree, i.e., requirement clusters. Components correspond to leaf nodes in the requirement decomposition tree, i.e., requirement points.

[0048] Specifically, the server performs a format conversion on the requirement decomposition tree generated in step S1015. The server considers the root node of the requirement decomposition tree as the final product. The server traverses all intermediate-level nodes of the requirement decomposition tree and converts each intermediate-level node into a BOM sub-item in the initial requirement-level BOM tree. This BOM sub-item represents a major functional module or component of the product. Subsequently, the server retrieves all leaf nodes under each intermediate-level node and lists these leaf nodes as components of the corresponding BOM sub-item. Finally, the server persistently stores this structure, which includes the three-tiered relationship of product, BOM sub-item, and components, forming the initial requirement-level BOM tree, providing a structured foundation for subsequent requirement time configuration and project task association.

[0049] Step S1017: Calculate the requirement complexity index for each requirement node based on the requirement type and estimated working hours.

[0050] In step S1017, the requirement complexity index is a numerical indicator used to quantify the inherent development difficulty and workload of a single requirement node. This index is calculated based on the requirement type and estimated working hours. A requirement node represents all nodes in the requirement hierarchy BOM tree, including BOM sub-items representing requirement clusters and components representing requirement points. The requirement type refers to the category obtained after classifying the requirement information in step S1011, such as functional requirements, performance requirements, or interface requirements. Estimated working hours refer to the estimated human time required to complete a requirement node.

[0051] Specifically, the server first needs to obtain the attribute information of each requirement node. For each leaf node, i.e., requirement point, in the requirement hierarchy BOM tree, the server reads the requirement type to which the requirement point belongs from the associated data storage and obtains the estimated work hours input by the project manager. The server calculates the requirement complexity index according to preset quantification rules. For example, different weight coefficients are assigned to different requirement types: the coefficient for interface requirements is 1.0, the coefficient for functional requirements is 1.5, and the coefficient for algorithm requirements is 2.0. The formula for calculating the requirement complexity index can be set as: Requirement Complexity Index = Requirement Type Weight Coefficient × Estimated Work Hours. For each intermediate layer node, i.e., requirement cluster, the server calculates its requirement complexity index as the sum of the requirement complexity indices of all leaf nodes under that node to reflect the overall workload of that functional cluster.

[0052] Step S1018: Perform structured analysis on the requirement hierarchy BOM tree and calculate the structured complexity index of each requirement node. The structured complexity index includes the depth index, breadth index, and coupling index.

[0053] In step S1018, the structured complexity index is an indicator used to measure the complexity of the position and relationships of a requirement node within the entire requirement hierarchy BOM tree structure. This index is composed of a depth index, a breadth index, and a coupling index. The depth index represents the hierarchical depth of a requirement node in the tree structure. The breadth index represents the number of child nodes directly subordinate to a requirement node. The coupling index represents the number of dependencies between a requirement node and other non-parent-child nodes.

[0054] Specifically, the server traverses and analyzes the initial requirement hierarchy BOM tree to calculate the structured complexity index of each requirement node. For the depth index, the server calculates the path length from each requirement node to the root node, with the root node as level 0; this length is the node's depth index. For the breadth index, the server counts the number of child nodes directly owned by each requirement node; this number is the node's breadth index, with leaf nodes having a breadth index of 0. For the coupling index, the server needs to reference the requirement dependency graph constructed in step S1013. The server examines each requirement node and counts the number of other nodes that have a dependency relationship with that node in the requirement dependency graph but are not its parent or child nodes in the requirement hierarchy BOM tree; this number is the node's coupling index. Finally, the server combines these three indices into a structured complexity index using a weighted summation method. The formula can be set as: Structured Complexity Index = Weight A × Depth Index + Weight B × Breadth Index + Weight C × Coupling Index.

[0055] Step S1019: Calculate the comprehensive complexity index of each requirement node based on the requirement complexity index and the structure complexity index.

[0056] In step S1019, the comprehensive complexity index refers to a final score that comprehensively evaluates the complexity of the requirement node. This score is derived by combining the inherent difficulty of the requirement node itself with the complexity of its position in the system structure.

[0057] Specifically, the server traverses each requirement node in the initial requirement hierarchy BOM tree. For each node, the server reads the requirement complexity index calculated in step S1017 and the structure complexity index calculated in step S1018 from the attributes stored in that node. The server uses pre-configured weights to linearly weight these two indices to calculate the comprehensive complexity index. The calculation formula can be: Comprehensive Complexity Index = Weight X × Requirement Complexity Index + Weight Y × Structure Complexity Index. After calculation, the server stores the obtained comprehensive complexity index value as a new attribute of that requirement node for subsequent optimization adjustments.

[0058] Step S10110: In the initial requirement hierarchy BOM tree, merge requirement nodes with a comprehensive complexity index lower than the first threshold, and split requirement nodes with a comprehensive complexity index higher than the second threshold to obtain the requirement hierarchy BOM tree.

[0059] In step S10110, the first threshold refers to a preset lower limit, used to identify requirement nodes with excessively low overall complexity and excessively fine granularity. The second threshold refers to a preset upper limit, used to identify requirement nodes with excessively high overall complexity and excessively coarse granularity. The requirement hierarchy BOM tree refers to the final BOM tree with a more reasonable structure and more uniform granularity obtained after merging and splitting the initial requirement hierarchy BOM tree.

[0060] Specifically, based on the comprehensive complexity index calculated in step S1019, the server performs optimization operations on the initial requirement-level BOM tree. First, the server traverses all requirement nodes, searching for nodes with a comprehensive complexity index below a first threshold. When such a node is found, the server searches for another sibling node with similarly low complexity that is most functionally related to or structurally closest to that node, and merges these two nodes into a new requirement node. The description of the new node integrates the contents of the original two nodes, and the complexity indices of the new node are recalculated. Second, the server traverses all requirement nodes, searching for nodes with a comprehensive complexity index above a second threshold. When such a node is found, the server performs a splitting operation. If the node is a leaf node, the server may call a natural language processing model to semantically decompose the description text of the requirement point, generating two or more finer-grained requirement points. If the node is an intermediate-level node, the server re-performs clustering analysis on all child nodes contained in that node, but uses stricter clustering parameters, thereby splitting a large requirement cluster into multiple smaller, more cohesive requirement clusters. After repeated merging and splitting, until the overall complexity index of all nodes in the tree is between the first and second thresholds, the server finally outputs the optimized requirement hierarchy BOM tree.

[0061] Step S102: Configure the requirement type and estimated working hours for each requirement node in the requirement hierarchy BOM tree.

[0062] In step S102, the demand type refers to the classification of the nature of the demand node, such as hardware development, software development, structural design, or algorithm research. Estimated working hours refer to the estimated amount of work required to complete a single demand node, usually measured in person-hours or person-days.

[0063] Specifically, the server displays the requirement hierarchy BOM tree generated in step S101 on the interface. Project managers traverse each leaf node in this tree, i.e., the lowest-level requirement node. For each selected requirement node, the server provides a preset list of requirement types for managers to choose from, which contains all work categories that may be involved in the project. Managers select the most matching requirement type based on the specific content of the requirement node. Simultaneously, the server provides an input field for managers to enter a value as the estimated work hours for the requirement node based on experience or historical data. The server associates the selected requirement type and the entered estimated work hours with the corresponding requirement node and stores this configuration information in the database.

[0064] Step S103: Based on the hierarchical structure of the requirement hierarchy BOM tree, summarize the estimated working hours of the sub-requirement nodes from bottom to top to calculate and obtain the total estimated working hours of the parent requirement node.

[0065] In step S103, the total estimated working hours of the parent demand node refers to the total amount of work required to complete the macro demand represented by a non-leaf node. This amount of work is the sum of the working hours of all the next-level sub-demand nodes that constitute the macro demand.

[0066] Specifically, the server performs a bottom-up traversal calculation of the requirement hierarchy BOM tree with the estimated work hours configured in step S102. Starting from all leaf nodes, the server moves upwards along the tree structure. For any parent requirement node, the server first locates all direct child requirement nodes under that parent requirement node. Then, the server reads and accumulates the estimated work hours of all these direct child requirement nodes. If a child requirement node is also a parent node, the server accumulates the total estimated work hours of that child requirement node. The accumulated sum is recorded by the server as the total estimated work hours of the current parent requirement node. This process is executed recursively until the total estimated work hours of all levels of parent requirement nodes in the tree are calculated, and finally the total estimated work hours of the root node are obtained. The total estimated work hours of the root node represent the total estimated workload of the entire product.

[0067] Step S104: Establish a standard development process template library corresponding to each requirement type. The standard development process template library contains multiple standard development process templates, where each standard development process template corresponds to a requirement type.

[0068] In step S104, the standard development process template library refers to a database or collection that stores various standard process definitions. These processes define the common steps and stages followed by different types of requirements from initiation to delivery. A standard development process template refers to a specific process definition file or data structure stored in the library.

[0069] Specifically, the server pre-installs or allows users to define and store a series of standardized project process templates. Each standard development process template is associated with a specific requirement type. For example, a template labeled as a software development type will define in detail the standard work breakdown structure (WBS) for that type of task, including a series of fixed task phases such as requirements analysis, system design, coding implementation, unit testing, and integration testing, and will define standard inputs, outputs, and quality gates for each phase. The server maintains this standard development process template library to ensure that each requirement type has a unique corresponding standard development process template.

[0070] In one possible implementation, based on a standard development process template, the target project is decomposed into a Work Breakdown Structure (WBS) to generate multiple project tasks, specifically including steps S1041-S1044, as follows: Step S1041: Analyze the standard development process template, extract the standard task decomposition structure, task attributes and task deliverables, and construct a standard WBS template.

[0071] In step S1041, the standard development process template refers to a predefined framework document containing all typical stages, activities, and tasks of a general standard development project. The standard task breakdown structure (WBS) is used to represent the hierarchy and subordinate relationships between tasks in this template, typically presented as a tree structure. Task attributes refer to detailed descriptions of each task, such as the expected duration, required resources, prerequisites, and responsible department. Task deliverables refer to the specific results to be produced upon completion of each task, such as documents, reports, or review records. The standard WBS template refers to the structured data object generated in memory or a database after the server parses the standard development process template; this object completely contains the standard task breakdown structure, task attributes, and task deliverable information.

[0072] Specifically, the server first accesses a pre-configured file storage location and reads a standard development process template file in a specific format, such as XML or JSON. The server extracts information by parsing the file's syntax structure. For standard task decomposition structures, the server identifies hierarchical relationships in the file, such as parent and child tags in XML, thereby constructing a tree-like hierarchy of tasks. For task attributes, the server reads the attribute fields under each task node, such as... <task name="起草" duration="30d">It then extracts data such as name and duration. For task deliverables, the server looks up a list of deliverables associated with the task node, such as... <deliverable> Standard Draft V1.doc< / deliverable> The server integrates and organizes all the extracted information into an in-memory data structure, which is the standard WBS template, providing the foundation for subsequent personalized customization.

[0073] Step S1042: Based on the task requirements of the target project, add, delete, or modify the corresponding task nodes on the standard WBS template to obtain the target WBS template.

[0074] In step S1042, the target project refers to the specific standard development project that currently requires project management. Task requirements refer to the personalized adjustments needed to the standard WBS template due to the specific characteristics of the target project. This includes adding specific tasks not present in the standard template, deleting general tasks unnecessary for the target project, or modifying the attributes of a task. Task nodes are elements in the WBS template that represent various tasks. The target WBS template is a customized WBS template formed based on the standard WBS template, after adding, deleting, and modifying elements according to the task requirements of the target project, thus conforming to the actual situation of the target project.

[0075] Specifically, the server first provides project managers with an interactive interface that displays the entire content of the standard WBS template in a tree-like list. Project managers issue operational instructions through this interface based on the specific needs of the target project. If the target project requires a special testing step not included in the standard template, the project manager will choose to add a task node and enter the new node's name, attributes, and parent node position. Upon receiving the instruction, the server will create a new task node in the target WBS template's data structure and establish the correct parent-child links. If the target project does not require market research, the project manager will choose to delete the corresponding task node. Upon receiving the instruction, the server will remove that node and all its child nodes from the data structure. Modification operations are handled similarly; the server will update the attributes of the corresponding task node based on the received new attribute values. After all operations are completed, the resulting modified WBS template is the target WBS template.

[0076] Step S1043: Determine the hierarchical task structure of the target project based on the target WBS template.

[0077] In step S1043, the hierarchical task structure refers to the tree structure that is finally determined according to the target WBS template and can completely and clearly display all tasks in the target project and their parent-child relationships.

[0078] Specifically, after completing the customization operation in step S1042, the server performs a final structural solidification of the generated target WBS template. The server iterates through each task node in the target WBS template, confirming that each node has a unique parent node (except the root node), and verifies the integrity of the entire structure to ensure there are no isolated nodes or circular parent-child relationships. Then, the server formally establishes this verified and solidified tree structure as the hierarchical task structure of the target project and persistently stores this structure in the database, preparing for the next step of task decomposition and project execution plan generation.

[0079] Step S1044: Traverse the hierarchical task structure, decompose the task nodes level by level until they are decomposed into work packages that can be directly assigned and executed, and obtain the project tasks.

[0080] In step S1044, a work package refers to the lowest-level task unit in the hierarchical task structure. This unit is small enough to be directly assigned to a specific individual or team and has a clearly defined start and end time and measurable deliverables. A project task refers to the collection of all work packages obtained through decomposition; this collection constitutes all the specific activities of project execution.

[0081] Specifically, the server takes the hierarchical task structure determined in step S1043 as input and recursively traverses it starting from the root node. For each task node encountered, the server judges it according to a preset decomposition rule. This rule can be a combination of one or more conditions, such as judging whether the estimated working hours of the node are less than a threshold, such as 40 working hours, or judging whether the node is marked as indivisible. If a task node meets the decomposition rule, that is, the node is determined to be a work package, the server stops further decomposing that branch and adds the node to a final project task list. If a task node does not meet the decomposition rule, the server continues to traverse all child nodes of the next level of the node and repeats the above judgment process for each child node. This process continues until all branches in the hierarchical task structure are decomposed to work packages that meet the conditions. Finally, the project task list output by the server is a complete list of all executable work packages for the target project.

[0082] Step S105: Based on the standard development process template, decompose the target project into a WBS and generate multiple project tasks.

[0083] In step S105, a project task refers to a specific activity or work package that needs to be performed in project management to achieve a specific goal. It is the basic execution unit after the project is decomposed.

[0084] Specifically, the server retrieves and loads all relevant standard development process templates from the standard development process template library based on all the requirement types included in the target project to be developed. Based on the preset WBS structure of these templates, the server generates an initial project WBS draft. The project manager can adjust this WBS draft through the interactive interface provided by the server; for example, adding customized testing tasks or merging some simple design tasks according to the project's specific characteristics. After the project manager confirms, the server solidifies the WBS structure and identifies and creates a series of specific project tasks from the lowest-level, indivisible activities within the WBS. Each project task includes basic attributes such as task name, description, and prerequisite / consequence relationships.

[0085] Please refer to Figure 2 In one possible implementation, after setting the project cycle for each project task based on the total estimated man-hours of the demand nodes associated with each project task, the method further includes steps S201-S213, as follows: Step S201: Based on the dependencies between project tasks, perform topological sorting of project tasks to generate a project task network diagram.

[0086] In step S201, the dependency relationship between project tasks refers to the fact that the start or completion of one project task depends on the start or completion of one or more other project tasks. The most common relationship is the completion-start relationship, meaning that the preceding task must be completed before the subsequent task can begin. Topological sorting refers to linearly sorting all nodes in a directed acyclic graph such that for any edge from node A to node B, node A always appears before node B in the sorted result. A project task network graph is a directed graph where nodes represent project tasks, and directed edges between nodes represent the dependencies between tasks.

[0087] Specifically, the server first reads all project tasks and their predefined prerequisite task information, which together constitute a task dependency set. Based on this set, the server constructs a directed graph data structure, where each project task is a graph node and each dependency is a directed edge. After construction, the server executes a cycle detection algorithm, such as a depth-first search algorithm, to verify whether there are circular dependencies in the graph, such as task A depending on task B, and task B depending on task A. If a cycle is detected, an error is reported to the user and the process terminates. If no cycle is found, the server executes a topological sorting algorithm, such as Kahn's algorithm. This algorithm first finds all nodes with an in-degree of zero (i.e., nodes without prerequisite tasks) and puts these nodes into a queue. Then, the server removes nodes from the queue, adds them to the sorted result list, and removes all outgoing edges from those nodes. This process causes some subsequent nodes to have an in-degree of zero, and the server adds these new nodes with an in-degree of zero to the queue. The server repeats this process until the queue is empty. The final sorted result list, together with the original graph structure, constitutes the project task network graph.

[0088] Step S202: Initialize the earliest start time of each task node in the project task network diagram to a preset value.

[0089] In step S202, the earliest start time of a task node refers to the earliest point in time when a task can start without violating task dependencies. The preset value is an initial value set for the calculation. For a starting task node without any preceding tasks, this value is usually zero, representing the start time of the project.

[0090] Specifically, after generating the project task network diagram, the server adds an attribute field to the data structure of each task node in the diagram to store the earliest start time. The server then iterates through all task nodes and sets the earliest start time attribute of each node to an initial preset value, which is usually the number 0. This operation ensures that the calculation basis of all task nodes is consistent before performing forward traversal calculations, avoiding calculation errors caused by data residue.

[0091] Step S203: Starting from the initial task node, traverse the project task network graph in a forward direction and calculate the earliest start time and earliest end time of each task node.

[0092] In step S203, the starting task node refers to a node in the project task network graph that has no preceding tasks. Forward traversal refers to the process of visiting subsequent task nodes one by one, following the task dependency relationship, starting from the starting task node in the project task network graph according to the topological sorting order. The earliest end time of each task node refers to the earliest time when the task can be completed, and its value is equal to the earliest start time of the task plus the task's own project cycle.

[0093] Specifically, the server uses the topology sorting list generated in step S201 to process each task node sequentially. For the first task node in the list, i.e., the starting task node, its earliest start time has been initialized to 0 in step S202. The server calculates the earliest end time of this task using the formula: Earliest End Time = Earliest Start Time + Project Duration. For each subsequent task node in the list, the server searches for all its direct predecessor task nodes in the project task network graph. The earliest start time of this task node is set to the maximum value among the earliest end times of all its direct predecessor task nodes. After determining the earliest start time, the server also uses the above formula to calculate the earliest end time of this task node. The server repeats this process until all task nodes in the topology sorting list have been calculated.

[0094] Step S204: Initialize the latest end time of each task node in the project task network diagram to the earliest end time of the project.

[0095] In step S204, the latest end time of a task node refers to the latest time a task must be completed without delaying the final completion time of the entire project. The earliest end time of the project refers to the earliest time the entire project can be completed if all tasks start as early as possible; this value is equal to the maximum of the earliest end times of all ending task nodes in the project task network diagram.

[0096] Specifically, the server first identifies all terminating task nodes (nodes without any subsequent tasks) in the project task network graph. The server iterates through these terminating task nodes and compares their earliest end times calculated in step S203, taking the maximum value as the earliest end time of the project. Then, the server adds an attribute field to the data structure of each task node in the graph to store the latest end time, and iterates through all task nodes, uniformly initializing the latest end time attribute of each node to the earliest end time of the project just calculated.

[0097] Step S205: Starting from the end task node, traverse the project task network graph in reverse order and calculate the latest start time and latest end time for each task node.

[0098] In step S205, the ending task node refers to a node in the project task network graph that has no subsequent tasks. Reverse traversal refers to the process of visiting each preceding task node in reverse order of the topological sort, starting from the ending task node and proceeding along the reverse direction of the task dependencies. The latest start time for each task node refers to the latest time a task must begin without delaying the overall project completion time; its value is equal to the latest end time of the task minus the task's own project cycle.

[0099] Specifically, the server reverses the topology sort list generated in step S201 and then processes each task node in this reversed order. For the first task node in the list, i.e., the ending task node, its latest end time has been initialized to the earliest end time of the project in step S204. The server calculates the latest start time of this task using the formula: Latest Start Time = Latest End Time - Project Duration. For each subsequent task node in the list, the server searches for all its directly succeeding task nodes in the project task network graph. The latest end time of this task node is set to the minimum of the latest start times of all its directly succeeding task nodes. After determining the latest end time, the server also uses the above formula to calculate the latest start time of this task node. The server repeats this process until all task nodes in the reversed topology sort list have been calculated.

[0100] Step S206: For each task node, calculate the difference between the earliest start time and the latest start time, and use it as the total time difference of the task node.

[0101] In step S206, the total float of a task node refers to the amount of time a task can be delayed without affecting the overall project duration.

[0102] Specifically, after completing the forward and reverse traversal calculations, each task node in the graph has two attribute values: earliest start time and latest start time. The server then traverses all task nodes in the project task network graph. For each node, the server reads its earliest and latest start time values, performs a subtraction operation, and calculates the difference. The server uses this calculated difference as the total float for that task node and stores it in a new attribute field for that task node. After this process is performed on all task nodes, the scheduling flexibility of each task in the project is quantified.

[0103] Step S207: Identify task nodes whose total float is within the preset float range as critical tasks, and identify task nodes whose total float is outside the preset float range as non-critical tasks.

[0104] In step S207, the preset float range refers to a numerical interval used to determine whether a task is a critical task. Typically, both the upper and lower limits of this interval are zero, indicating no margin for delay. Critical tasks are those with a total float of zero or within the preset float range; any delay in these tasks will directly lead to a delay in the entire project. Non-critical tasks are those with a total float greater than zero; these tasks offer some flexibility in execution time.

[0105] Specifically, the server first reads a parameter representing a preset float range from the system configuration, for example, a lower limit of 0 and an upper limit of 0. Then, the server iterates through all task nodes and checks the total float calculated in step S206 for each node. If the total float value of a task node is greater than or equal to the lower limit of the preset range and less than or equal to the upper limit, the server adds an identifier to the task node's data structure, identifying it as a critical task. If the total float value is outside this range, the server identifies the task node as a non-critical task.

[0106] Step S208: Determine the path consisting of critical tasks as the critical task path, and the path consisting of non-critical tasks as the non-critical task path.

[0107] In step S208, a critical task path refers to one or more of the longest paths in the project task network diagram, consisting of a series of consecutive critical tasks from the start to the end of the project. The total duration of this path determines the shortest total project duration. A non-critical task path refers to any path in the diagram that contains at least one non-critical task.

[0108] Specifically, the server first filters out all nodes identified as critical tasks in step S207. Starting from the initial task node in the project task network graph, the server performs a depth-first or breadth-first graph traversal along the dependencies. During the traversal, the server only proceeds along edges connecting two critical tasks. When the traversal reaches an ending task node, a complete path consisting of critical tasks is found. The server records this path. Since there may be multiple parallel critical task paths in the graph, the server continues traversing until all possible critical task paths are determined. Meanwhile, all other paths in the graph that are not entirely composed of critical tasks are identified as non-critical task paths.

[0109] Step S209: Take the earliest end time of the target task node on the critical task path as the critical time of the project, and the target task node is the last task node on the critical task path.

[0110] In step S209, the target task node on the critical task path refers to the ending task node located at the end of the critical task path. The project critical time refers to the shortest time required to complete the entire project, which is numerically equal to the sum of the project cycles of all tasks on the critical task path, and also equal to the earliest end time of the target task node.

[0111] Specifically, after determining the critical task path, the server locates the last task node on that path, i.e., the target task node. The server then reads the earliest finish time attribute value calculated during the forward traversal in step S203 from the data structure of this target task node. This value is determined as the project's critical time. If multiple critical task paths exist, their target task nodes' earliest finish times must be the same. The server ultimately outputs this single value as the critical time for the entire project, which is also the project's shortest total duration.

[0112] Step S210: Calculate an adjustable time window for each non-critical task. The size of the adjustable time window is equal to the total float of the non-critical tasks.

[0113] In step S210, the adjustable time window refers to the time range within which non-critical tasks can be scheduled and adjusted without affecting the overall project duration. The starting point of this range is the earliest start time of the task, and the ending point is the latest end time of the task.

[0114] Specifically, the server iterates through all task nodes identified as non-critical tasks in step S207. For each non-critical task, the server reads the task's earliest start time, latest end time, and the total float calculated in step S206. The server defines an adjustable time window for this task, with the window's start boundary set to the task's earliest start time and its end boundary set to the task's latest end time. The duration of this window is equal to the task's latest end time minus its earliest start time, and the amount of time the task can float within this window—that is, the size of the window—is equal to the task's total float.

[0115] Step S211: Obtain project resource pool information and resource requirements for each project task, and generate a project resource load diagram based on the project task schedule before adjustment, and identify resource overload time periods and resource idle time periods.

[0116] In step S211, project resource pool information refers to detailed data on the total amount and available time periods of various resources in the project, such as the number of engineers with specific skills and the number of available devices. Resource requirements for each project task refer to the amount of specific resources required to complete a single task per unit of time. The unadjusted project task schedule refers to the initial plan based on all tasks starting at the earliest possible start time. The project resource load chart is a graph or data structure that displays the total daily or per unit time resource requirements within the project cycle, with time as the horizontal axis and resource usage as the vertical axis. Resource overload periods refer to the time intervals during which the total resource demand exceeds the total available resources in the project resource pool. Resource idle periods refer to the time intervals during which the total resource demand is significantly lower than the total available resources, resulting in low resource utilization.

[0117] Specifically, the server first retrieves complete project resource pool information and detailed resource requirements associated with each project task from the database or configuration file. Based on the earliest start and end times of all tasks, the server constructs the unadjusted project task schedule. Then, the server creates a data structure indexed by time units, covering the entire cycle from project start to finish. The server iterates through each time unit on this timeline, accumulating the resource requirements of all currently executing tasks at each time unit to obtain the total requirement for each type of resource at each time unit. This collection of total resource requirements that changes over time constitutes the project resource load map. Finally, the server compares the total resource requirements for each time unit with the total available resources in the project resource pool information. If demand consistently exceeds supply during a certain period, the server records that period as a resource overload period. Conversely, if demand consistently falls far below supply, the server records that period as a resource idle period.

[0118] Step S212: Based on the adjustable time window, with the goal of resource load balancing, adjust non-critical tasks that are in the resource overload period. The adjustments include delayed start strategy and extended cycle strategy.

[0119] In step S212, resource load balancing refers to adjusting task scheduling to stabilize daily resource demands throughout the project cycle, avoiding drastic fluctuations in resource demand, thus eliminating resource overload and improving the utilization rate of idle resource periods. The delayed start strategy involves postponing the planned start time of non-critical tasks within their adjustable time windows. The extended cycle strategy, while maintaining the total workload, reduces the daily resource demand of non-critical tasks by increasing the number of execution days.

[0120] Specifically, with resource load balancing as the optimization goal, the server first focuses on the resource overload periods identified in step S211. The server filters out all non-critical tasks executed during these overload periods. For each eligible non-critical task, the server evaluates two adjustment strategies. For the delayed start strategy, the server calculates the feasibility of delaying the start of the task after the resource overload period, ensuring that the new planned completion time does not exceed the task's latest end time. The server will prioritize moving the task to an identified resource idle period. For the extended cycle strategy, the server calculates the new daily resource requirements after the extended cycle based on the task's total workload, i.e., the product of the original project cycle and the original resource requirements. For example, a task requiring 2 engineers to work for 5 days, with a total workload of 10 person-days, can be adjusted to require 1 engineer to work for 10 days. The server verifies whether the extended new project cycle will cause the task's planned completion time to exceed its latest end time. The server uses a preset optimization algorithm, such as a heuristic algorithm, to iteratively apply the above strategies to non-critical tasks, recalculating the resource load graph after each adjustment, until all resource overload issues are resolved, or all adjustable non-critical tasks can no longer be adjusted.

[0121] Step S213: Based on the adjustment results, update the planned start time, planned completion time, and project cycle of non-critical tasks, and generate an optimized project plan.

[0122] In step S213, the planned start time refers to the final scheduled start time of the task after resource load balancing optimization. The planned completion time refers to the task's planned start time plus its final determined project cycle. The optimized project plan refers to a final executable project scheduling scheme that comprehensively considers task dependencies and resource constraints and has been adjusted through resource load balancing.

[0123] Specifically, the server performs a final update to the project task data based on the adjustment results executed in step S212. The server iterates through all tasks. For non-critical tasks that have been adjusted, the server updates the start time attribute in their data structure to the new planned start time and the project duration attribute to the new project duration, and calculates and updates their planned completion time based on these two new values. For all critical tasks and non-critical tasks that have not been adjusted, the server sets their planned start time to the earliest start time and their planned completion time to the earliest end time. After updating all task attributes, the server will contain the final scheduling information for all tasks, including task name, planned start time, planned completion time, final project duration, and resource allocation, and integrate this information to generate a structured data report, which is the optimized project plan.

[0124] Step S106: Associate the requirement nodes in the requirement hierarchy BOM tree with the project tasks, and match the corresponding standard development process template for the project tasks based on the requirement type corresponding to the requirement node.

[0125] In step S106, associating the requirement nodes in the requirement hierarchy BOM tree with project tasks means establishing a traceability link between the source of requirements and project execution activities, clarifying which specific requirements(s) each project task is established to fulfill.

[0126] Specifically, the server provides a mapping interface for project managers. One side of the interface displays the requirements hierarchy BOM tree, and the other side displays the project task list generated in step S105. Managers can assign one or more requirement nodes in the requirements hierarchy BOM tree to a related project task by dragging or clicking. The server records this association. After establishing the association, the server automatically reads the requirement type of the associated requirement node, then searches the standard development process template library for a standard development process template that perfectly matches the requirement type, and applies the found template to the corresponding project task, thereby automatically configuring a standard execution process and deliverable list for the project task.

[0127] Step S107: Based on the estimated working hours of the sub-requirement nodes and the total estimated working hours of the parent requirement nodes, calculate the estimated working hours of the requirement nodes associated with each project task, and set the project cycle for each project task.

[0128] In step S107, setting a project cycle for each project task means planning a clear start and end time for the task based on the workload required and available resources, i.e., the duration of the task.

[0129] Specifically, the server first iterates through all project tasks. For each project task, the server finds the corresponding requirement node through the association established in step S106. The server reads the estimated working hours of that requirement node; if the requirement node is a parent requirement node, it reads the total estimated working hours of that parent requirement node. This working hour value represents the total workload required to complete the task. Subsequently, the server converts the total estimated working hours into a project cycle based on the system's preset work calendar, such as an 8-hour workday, and considering the standard resource allocation model. The calculation formula is: project cycle equals total estimated working hours divided by the daily standard working hours. For example, for a task associated with a total estimated working hours of 40 person-hours, under an 8-hour workday, the server will set a project cycle of 5 days for that task. The server updates the calculated project cycle value into the attributes of the corresponding project task, ultimately completing the setting of the cycle for all project tasks.

[0130] The following describes a device for fusing project process and product requirement information from the perspective of hardware processing in an embodiment of this invention. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the structure of a device for integrating project process and product demand information in an embodiment of this application.

[0131] It should be noted that, Figure 3 The structure of the device for integrating project process and product demand information shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0132] like Figure 3 As shown, a device for integrating project process and product requirement information includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for device operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0133] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0134] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0135] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0136] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0137] Specifically, the device for fusing project process and product requirement information in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the method for fusing project process and product requirement information provided in the above embodiment.

[0138] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the project process and product requirement information fusion device described in the above embodiments; or it may exist independently and not assembled into the project process and product requirement information fusion device. The storage medium carries one or more computer programs, which, when executed by a processor of the project process and product requirement information fusion device, enable the project process and product requirement information fusion device to implement the project process and product requirement information fusion method based on IoT data encryption transmission provided in the above embodiments.< / task>

Claims

1. A method of integrating project process and product requirement information, characterized by, The method comprises: obtaining product demand information and decomposing the product demand information to construct a demand hierarchical BOM tree composed of multiple demand nodes; configuring a demand type and an estimated man-hour for each demand node in the demand hierarchical BOM tree; based on the hierarchical structure of the demand hierarchical BOM tree, the estimated man-hours of sub-demand nodes are summarized step by step from bottom to top to calculate and obtain the total estimated man-hours of a parent demand node; establishing a standard development process template library corresponding to each demand type, wherein the standard development process template library comprises multiple standard development process templates, and each standard development process template corresponds to a demand type; based on the standard development process template, performing WBS decomposition on a target project to generate multiple project tasks; associating the demand nodes in the demand hierarchical BOM tree with the project tasks, and matching the project tasks with corresponding standard development process templates based on the demand type corresponding to the demand nodes; based on the estimated man-hours of the sub-demand nodes and the total estimated man-hours of the parent demand node, calculating the estimated man-hours of the demand nodes associated with each project task, and setting a project cycle for each project task.

2. The method of claim 1, wherein, The method comprises: obtaining product demand information and decomposing the product demand information to construct a demand hierarchical BOM tree composed of multiple demand nodes; obtaining product demand information and decomposing the product demand information to construct a demand hierarchical BOM tree composed of multiple demand nodes; based on the hierarchical structure of the demand hierarchical BOM tree, the estimated man-hours of sub-demand nodes are summarized step by step from bottom to top to calculate and obtain the total estimated man-hours of a parent demand node; establishing a standard development process template library corresponding to each demand type, wherein the standard development process template library comprises multiple standard development process templates, and each standard development process template corresponds to a demand type; based on the standard development process template, performing WBS decomposition on a target project to generate multiple project tasks; associating the demand nodes in the demand hierarchical BOM tree with the project tasks, and matching the project tasks with corresponding standard development process templates based on the demand type corresponding to the demand nodes; based on the estimated man-hours of the sub-demand nodes and the total estimated man-hours of the parent demand node, calculating the estimated man-hours of the demand nodes associated with each project task, and setting a project cycle for each project task.

3. The method of claim 2, wherein, The method comprises: obtaining product demand information and decomposing the product demand information to construct a demand hierarchical BOM tree composed of multiple demand nodes; obtaining product demand information and decomposing the product demand information to construct a demand hierarchical BOM tree composed of multiple demand nodes; based on the hierarchical structure of the demand hierarchical BOM tree, the estimated man-hours of sub-demand nodes are summarized step by step from bottom to top to calculate and obtain the total estimated man-hours of a parent demand node; establishing a standard development process template library corresponding to each demand type, wherein the standard development process template library comprises multiple standard development process templates, and each standard development process template corresponds to a demand type; based on the standard development process template, performing WBS decomposition on a target project to generate multiple project tasks; associating the demand nodes in the demand hierarchical BOM tree with the project tasks, and matching the project tasks with corresponding standard development process templates based on the demand type corresponding to the demand nodes; based on the estimated man-hours of the sub-demand nodes and the total estimated man-hours of the parent demand node, calculating the estimated man-hours of the demand nodes associated with each project task, and setting a project cycle for each project task. In the initial demand hierarchical BOM tree, merging demand nodes with a comprehensive complexity index lower than a first threshold value, and splitting demand nodes with a comprehensive complexity index higher than a second threshold value, to obtain the demand hierarchical BOM tree.

4. The method of claim 1, wherein, The method comprises the following steps of: analyzing the standard development process template to extract a standard task decomposition structure, task attributes, and task deliverables, and constructing a standard WBS template; adding, deleting, or modifying corresponding task nodes on the standard WBS template according to task requirements of the target project, to obtain a target WBS template; determining a hierarchical task structure of the target project according to the target WBS template; traversing the hierarchical task structure to decompose task nodes level by level until the task nodes are decomposed into work packages that can be directly allocated and executed, to obtain the project tasks.

5. The method of claim 1, wherein, After setting a project cycle for each project task based on total estimated man-hours of demand nodes associated with each project task, the method further comprises the following steps of: topologically sorting the project tasks based on a dependency relationship between the project tasks, to generate a project task network diagram; identifying critical task paths and non-critical task paths in the project task network diagram by using a critical path algorithm, and calculating a project critical time of the critical task paths; adjusting a project cycle of a non-critical task according to a non-critical task path and the project critical time, to obtain an optimized project plan.

6. The method of claim 5, wherein, The method of identifying critical task paths and non-critical task paths in the project task network diagram by using a critical path algorithm, and calculating a project critical time of the critical task paths, specifically comprises the following steps of: initializing an earliest start time of each task node in the project task network diagram as a preset value; forwardly traversing the project task network diagram from a starting task node, to calculate an earliest start time and an earliest end time of each task node; initializing a latest end time of each task node in the project task network diagram as an earliest end time of the project; backwardly traversing the project task network diagram from an ending task node, to calculate a latest start time and a latest end time of each task node; calculating, for each task node, a difference between the earliest start time and the latest start time as a total float of the task node; identifying a task node with a total float within a preset float range as a critical task, and identifying a task node with a total float not within the preset float range as a non-critical task; determining a path formed by the critical tasks as a critical task path, and determining a path formed by the non-critical tasks as a non-critical task path; taking an earliest end time of a target task node on the critical task path as the project critical time, the target task node being a last task node on the critical task path.

7. The method of claim 5, wherein, The method of adjusting a project cycle of a non-critical task according to a non-critical task path and the project critical time, to obtain an optimized project plan, specifically comprises the following steps of: calculating an adjustable time window for each of the non-critical tasks, the adjustable time window having a size equal to a total float of the non-critical task; obtaining project resource pool information and resource requirements of each of the project tasks, and generating a project resource load diagram based on the project task schedule before adjustment, and identifying resource overload time periods and resource idle time periods; adjusting the non-critical tasks in the resource overload time periods according to the adjustable time window, the adjustment including a delayed start strategy and an extended cycle strategy, the adjustment being aimed at balancing resource loads; updating the planned start time, the planned completion time and the project cycle of the non-critical tasks according to the adjustment result, and generating the optimized project plan.

8. An apparatus for integrating project process and product requirement information, characterized by comprising: The project process and product requirement information fusion device comprises one or more processors and a memory; the memory is coupled with the one or more processors; the memory is configured to store computer program codes; the computer program codes comprise computer instructions; the one or more processors invoke the computer instructions to enable the project process and product requirement information fusion device to perform the method according to any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, The instructions enable the project process and product requirement information fusion device to perform the method according to any one of claims 1-7 when the instructions run on the project process and product requirement information fusion device.

10. A computer program product, characterised in that, The computer program product enables the project process and product requirement information fusion device to perform the method according to any one of claims 1-7 when the computer program product runs on the project process and product requirement information fusion device.

Images