Industrial software collaborative development method, device, equipment, storage medium and product

Abstract

The application discloses an industrial software collaborative development method and device, equipment, a storage medium and a product, relates to the technical field of computer-aided software engineering, and the industrial software collaborative development method comprises the following steps: acquiring requirement description information of industrial software to be developed; analyzing the requirement description information, extracting a plurality of function units, and establishing corresponding acceptance standards for each function unit; reading a pre-configured multi-source fact baseline, and confirming the output boundary of each function unit according to the multi-source fact baseline; and generating program code meeting the acceptance standards for each function unit by a pre-set large model based on the confirmed output boundary. The application solves the technical problem of poor output stability of auxiliary programming in the conventional technology.

Description

Technical Field

[0001] This application relates to the field of computer-aided software engineering technology, and in particular to methods, apparatus, equipment, storage media and products for collaborative development of industrial software. Background Technology

[0002] Industrial software is a fundamental tool in fields such as equipment manufacturing, energy, and aerospace. This type of software is characterized by domain knowledge intensity, high interaction complexity, strong module coupling, large-scale scenarios, and long lifecycles. Taking the migration of a desktop-based 3D multibody dynamics modeling tool to a web-based platform as an example, its global product requirements specification can typically be broken down into dozens or even hundreds of prototype scenarios. This involves browser-side compilation of the geometric kernel, 3D picking and snapping, the full-link linkage of the object tree and attribute panel, and the implementation of professional concepts such as grouping, frames, joints, drives, contact, and fluid dynamics. It is difficult for a single developer or team to complete this entire process in one go.

[0003] In recent years, large language models and intelligent agent technologies based on large language models have developed rapidly, introducing new auxiliary tools for software development. Among conventional technologies, large language model-based assisted programming methods mainly include code completion tools, one-time question-and-answer interactions, and small-scale automated script generation based on prompt word engineering. These methods have achieved certain results in tasks such as simple code generation, fragment reconstruction, and format conversion.

[0004] However, directly applying these conventional techniques to the development of complex industrial software presents a technical problem of poor output stability. Specifically, conventional techniques treat each dialogue as an independent interaction process, lacking a unified engineering context constraint. The understanding of technology selection, architectural boundaries, and domain terminology by the large model may drift across different sessions within the same project, leading to inconsistent output results across multiple iterations and making it difficult to distill them into reusable engineering assets. Furthermore, conventional techniques cannot automatically decompose global requirements encompassing dozens of functional scenarios into the smallest independently deliverable and verifiable units. Developers are forced to input the entire requirement at once, resulting in vague generated results or uncontrollable coupling between multiple modules. In addition, conventional techniques typically only call the large model during code generation; the preceding requirements clarification, technical reconnaissance, prototype generation, and subsequent testing, regression, and verification are still done manually. The large model cannot be integrated throughout the entire engineering chain from requirements to delivery. In summary, there is a structural contradiction between the fragmented and weakly constrained output provided by conventional techniques and the engineering, scalable, and verifiable delivery required by complex industrial software. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, equipment, storage medium and product for collaborative development of industrial software, which aims to solve the technical problem of poor stability of auxiliary programming output in conventional technologies.

[0006] To achieve the above objectives, this application proposes a collaborative development method for industrial software, the method comprising: Obtain the requirements description information for the industrial software to be developed; The requirement description information is parsed to extract several functional units, and corresponding acceptance criteria are established for each functional unit. Read the pre-configured multi-source fact baseline, and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; Based on the confirmed output boundaries, a pre-defined large model generates program code for each functional unit that meets the acceptance criteria.

[0007] In one embodiment, the step of reading a pre-configured multi-source fact baseline includes: Read the pre-configured task description file, extract the requirement boundary information and external dependency information from the task description file, and use the requirement boundary information and external dependency information as the first source of fact. Read the pre-configured technical architecture configuration file, extract the layered technology selection data from the technical architecture configuration file, and use the layered technology selection data as the second source of fact; Read the pre-configured prototype file, extract the interface layout information and interaction design information from the prototype file, and use the interface layout information and interaction design information as a third source of fact; Read the pre-configured scenario requirement document, extract functional boundary information and acceptance condition information from the scenario requirement document, and use the functional boundary information and acceptance condition information as the fourth source of fact; The first fact source, the second fact source, the third fact source, and the fourth fact source are merged into the multi-source fact baseline.

[0008] In one embodiment, the requirement description information includes product help documents and prototype files. The step of parsing the requirement description information and extracting several functional units includes: Read the pre-configured product help document, identify all independent operation units from the product help document, and assign a corresponding page identifier to each independent operation unit; Read the pre-configured prototype file and extract the prototype canvas corresponding to the page identifier from the prototype file; Using the page identifier as the association key, a one-to-one mapping relationship is established between the independent operation unit and the prototype drawing board; Based on the one-to-one mapping relationship, each of the independent operation units is determined as a functional unit.

[0009] In one embodiment, after the step of generating program code that meets the acceptance criteria for each functional unit from a preset large model, the method further includes: Obtain the set of preset test cases corresponding to the functional unit, wherein the set of preset test cases contains all test cases specified by the acceptance criteria of the functional unit; Execute the pre-set set of test cases, obtain the execution result of each test case, and compare the execution result with the corresponding expected result; When the execution result is inconsistent with the expected result, the code defect location is located based on the comparison result, and the functional boundary description in the scenario requirement document corresponding to the functional unit is revised. Adjust the task plan of the functional unit according to the revised scenario requirements document, and regenerate the program code and supplementary test cases until all test cases in the preset test case set pass the execution.

[0010] In one embodiment, the step of generating program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary using a preset large model includes: Read the pre-configured task execution chain description file, obtain multiple operation steps and their fixed execution order from the task execution chain description file, and use the operation steps and their fixed execution order as the execution framework of the functional unit; Read the pre-configured set of reusable execution units, and obtain the trigger condition field, input contract field, and output contract field of each reusable execution unit from the set of reusable execution units; Using the scene identifier of the functional unit as the query condition, match the target execution unit in the set of reusable execution units whose trigger condition field is consistent with the scene identifier; When no domain execution unit corresponding to the scene identifier is matched in the set of reusable execution units, a domain execution unit loading request is initiated to the set of reusable execution units, domain knowledge data corresponding to the domain type identifier is read from the preset domain knowledge base, and the domain knowledge data is injected into the current session context of the large model; Based on the output boundary, the target execution units are loaded and executed sequentially according to the fixed execution order specified by the execution framework to generate the program code; The step of generating program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary, using a preset large model, includes: Once the program code is generated and passes acceptance, the domain knowledge data generated by the functional unit during execution is extracted, the domain knowledge data is encapsulated into a new reusable execution unit, and the new reusable execution unit is written into the reusable execution unit set.

[0011] In one embodiment, after the step of generating program code that meets the acceptance criteria for each functional unit from a preset large model, the method further includes: Obtain four types of assets corresponding to the functional unit: requirement documents, task plans, program code, and test cases; and perform consistency verification on the four types of assets. When the verification result is inconsistent, the remaining assets in the four asset categories are compared item by item, based on the asset that was last changed among the four asset categories. Based on the item-by-item comparison results, the assets in the four asset categories that are inconsistent with the benchmark are updated synchronously until the contents of the four asset categories are consistent with each other. The four types of assets with consistent content are marked as delivered, and the functional units are updated to the delivered status in the global task dashboard.

[0012] Furthermore, to achieve the above objectives, this application also proposes an industrial software collaborative development device, which includes: The acquisition module is used to acquire the requirements description information of the industrial software to be developed. The parsing module is used to parse the requirement description information, extract several functional units, and establish corresponding acceptance criteria for each functional unit. The confirmation module is used to read the pre-configured multi-source fact baseline and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline. The output module is used to generate program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary and a preset large model.

[0013] In addition, to achieve the above objectives, this application also proposes an industrial software collaborative development device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the industrial software collaborative development method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the industrial software collaborative development method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the industrial software collaborative development method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: Compared to the fragmented approach in related technologies that treats each large model interaction as an independent process and lacks unified engineering context constraints, this application obtains the requirements description information of the industrial software to be developed; parses the requirements description information to extract several functional units, and establishes corresponding acceptance criteria for each functional unit; reads a pre-configured multi-source fact baseline, and performs baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; based on the confirmed output boundary, the preset large model generates program code that meets the acceptance criteria for each functional unit. It is understood that when the large model is invoked, the baseline confirmation of the output boundary of each functional unit through the pre-configured multi-source fact baseline achieves unified engineering context constraints for each large model interaction. Therefore, based on this constraint, the range of functional unit output can be limited, thereby ensuring that the content of each large model output does not deviate from the preset technical selection and functional boundaries. Ultimately, the large model outputs consistent and verifiable program code across multiple functional units, solving the technical problem of poor stability in auxiliary programming output in conventional technologies. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the collaborative development method for industrial software in this application. Figure 2 This is a schematic diagram of the module structure of the industrial software collaborative development device according to an embodiment of this application; Figure 3 This is a schematic diagram of the equipment structure of the hardware operating environment involved in the industrial software collaborative development method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

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

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution in this application embodiment is: Obtain the requirements description information for the industrial software to be developed; The requirement description information is parsed to extract several functional units, and corresponding acceptance criteria are established for each functional unit. Read the pre-configured multi-source fact baseline, and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; Based on the confirmed output boundaries, a pre-defined large model generates program code for each functional unit that meets the acceptance criteria.

[0024] In this embodiment, the application uses an industrial software collaborative development device as the execution subject. For ease of description, it will be referred to as "device" in the following detailed description.

[0025] Because the relevant technologies treat each call to the large model as an independent interaction process, and lack unified constraints on the engineering context, the output results of the large model drift in multi-scenario and multi-round collaborative development, making it difficult to form reusable engineering assets and achieve verifiable delivery.

[0026] This application provides a solution that constructs a multi-source fact baseline as a hard constraint for the output of a large model and decomposes global requirements into functional units with independent acceptance criteria. This ensures that each large model call runs within a preset output boundary, thereby converging the generation behavior of the large model from an open response to a well-defined engineering output. This enables the large model to output consistent and verifiable program code across multiple functional units, solving the technical problem of poor stability of auxiliary programming output in conventional technologies.

[0027] In this embodiment, the research and development background is the collaborative development of complex industrial software across multiple scenarios. This type of software has large-scale requirements and high module coupling, making it difficult for a single developer or team to advance the entire process in one go. The application scenario addressed in this embodiment is the engineering development process of migrating desktop industrial software to a web-based format. This process involves the collaborative implementation of multiple professional fields, including browser-side compilation of geometric kernels, 3D interaction, and multibody dynamics modeling.

[0028] Based on this, embodiments of this application provide a collaborative development method for industrial software, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the industrial software collaborative development method of this application.

[0029] In this embodiment, the industrial software collaborative development method includes steps S10 to S40: Step S10: Obtain the requirements description information of the industrial software to be developed; It should be noted that the industrial software includes, but is not limited to, at least one of computer-aided design software, computer-aided engineering software, multibody dynamics modeling software, fluid simulation software, and industrial control software. The requirements description information refers to text or structured data describing the functional requirements, performance requirements, target system form, and external dependencies of the industrial software to be developed. Its sources include, but are not limited to, product task books, user requirement documents, or product specifications.

[0030] Understandably, this step serves as the entry point for the entire collaborative development process, acquiring the original requirements description information of the industrial software to be developed. This provides an initial input basis for subsequent functional unit decomposition and baseline constraint confirmation. In this embodiment, the requirements description information carries all user expectations and engineering requirements of the industrial software to be developed, ensuring that subsequent steps are all carried out on a unified input source.

[0031] Step S20: Parse the requirement description information, extract several functional units, and establish corresponding acceptance criteria for each functional unit; It should be noted that the parsing refers to the process of structuring the requirement description information to identify functional modules with independent operational semantics, including but not limited to splitting by functional page, operation unit, or business domain. The functional unit refers to the smallest functional closed loop extracted from the requirement description information that has independent delivery significance; each functional unit corresponds to an independent operation scenario or business process node. The acceptance criteria refer to a set of objective judgment conditions used to determine whether the functional unit has completed delivery, including but not limited to functional integrity conditions, input / output matching conditions, and boundary scenario coverage conditions.

[0032] Understandably, this step breaks down the original, vague global requirements into several independent functional units and pre-establishes acceptance criteria for each unit, thus transforming them into independently measurable and independently achievable engineering units. In this embodiment, the acceptance criteria are established simultaneously with the functional units, providing a comparable quality benchmark for subsequent code generation and automated verification.

[0033] Step S30: Read the pre-configured multi-source fact baseline and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; It should be noted that the multi-source fact baseline refers to a set of factual information pre-extracted and solidified from multiple heterogeneous sources to define the generation behavior of large models. These sources include, but are not limited to, task description files, technical architecture configuration files, prototype files, and scenario requirement documents. The types of information included in the multi-source fact baseline include, but are not limited to, requirement boundary information, external dependency information, layered technology selection data, interface layout information, interaction design information, functional boundary information, and acceptance condition information. The output boundary refers to the limitation on the scope of the program code corresponding to the functional unit, including but not limited to technology selection boundaries, functional scope boundaries, interface specification boundaries, and data format boundaries. The baseline confirmation refers to the process of mapping the factual information related to the current functional unit in the multi-source fact baseline to the output boundary of that functional unit.

[0034] Understandably, this step, by reading a pre-configured multi-source fact baseline and confirming the output boundary of each functional unit accordingly, transforms the subsequent generation behavior of the large model from an open-ended response constraint to a directed generation within a preset boundary. In this embodiment, the multi-source fact baseline is automatically loaded at the start of each large model session, allowing the generation processes of different functional units to share the same set of constraints, thus eliminating the drift phenomenon of the large model output in multiple interactions from the root.

[0035] Step S40: Based on the confirmed output boundary, program code that meets the acceptance criteria is generated for each functional unit by a preset large model.

[0036] It should be noted that the output boundary refers to the range limitation conditions of the functional unit program code determined after baseline confirmation. The large model refers to a pre-trained large language model with program code generation capabilities. Its input includes, but is not limited to, the requirement description, acceptance criteria, and output boundary constraints of the current functional unit, and its output is program code that meets the acceptance criteria. The program code includes, but is not limited to, at least one of the following: domain model code, geometric calculation code, rendering interaction code, and interface component code.

[0037] Understandably, this step uses the confirmed output boundary as a constraint on the large model, enabling the large model to generate program code that meets acceptance criteria within a confined space, thus achieving controllability and verifiability of the large model's output. In this implementation, the program code for each functional unit is generated within its corresponding output boundary, ensuring consistency in technology selection, directory structure, and interface specifications across different functional units, thereby guaranteeing the overall technical uniformity of the project.

[0038] This embodiment provides a collaborative development method for industrial software. When a large model is invoked, the output boundary of each functional unit is confirmed by a pre-configured multi-source fact baseline. This achieves a unified engineering context constraint for each interaction of the large model. Therefore, based on this constraint, the range of output of functional units can be limited, thereby ensuring that the content of each output of the large model does not deviate from the preset technology selection and functional boundaries. Finally, the large model outputs consistent and verifiable program code across multiple functional units, solving the technical problem of poor stability of auxiliary programming output in conventional technologies.

[0039] In one feasible implementation, the step of reading a pre-configured multi-source fact baseline includes: Read the pre-configured task description file, extract the requirement boundary information and external dependency information from the task description file, and use the requirement boundary information and external dependency information as the first source of fact. Read the pre-configured technical architecture configuration file, extract the layered technology selection data from the technical architecture configuration file, and use the layered technology selection data as the second source of fact; Read the pre-configured prototype file, extract the interface layout information and interaction design information from the prototype file, and use the interface layout information and interaction design information as a third source of fact; Read the pre-configured scenario requirement document, extract functional boundary information and acceptance condition information from the scenario requirement document, and use the functional boundary information and acceptance condition information as the fourth source of fact; The first fact source, the second fact source, the third fact source, and the fourth fact source are merged into the multi-source fact baseline.

[0040] It should be noted that the task description file refers to a pre-configured structured document that records the engineering propositions and constraints of the industrial software to be developed. The requirement boundary information includes, but is not limited to, system boundary definitions and functional scope descriptions. The external dependency information includes, but is not limited to, dependency library names, dependency version numbers, and interface specifications. The first source of fact refers to a logical set of factual information extracted from the task description file. The technical architecture configuration file refers to a pre-configured structured document that records layered technology selection decisions. The layered technology selection data includes, but is not limited to, component names, version numbers, and dependencies of each technology layer. The second source of fact refers to a logical set of factual information extracted from the technical architecture configuration file. The prototype file refers to a pre-configured visual description file used to describe the interface layout and interactive behavior of the industrial software to be developed. The interface layout information refers to information extracted from the prototype file used to describe the spatial location and hierarchical relationship of interface components. The interaction design information refers to information extracted from the prototype file used to describe the response behavior and jump logic of interface components. The third source of fact refers to a logical set of factual information extracted from the prototype file. The scenario requirements document refers to a pre-configured structured document describing the functional boundaries and acceptance conditions of each functional unit. The functional boundary information refers to information used to distinguish between included and excluded scopes within a functional unit. The acceptance condition information refers to a set of objective conditions used to determine whether a functional unit has completed delivery. The fourth source of fact refers to a logical set of factual information extracted from the scenario requirements document. The merging refers to the process of uniformly collecting and deduplicating the factual information from the first, second, third, and fourth sources of fact to form a single multi-source fact baseline set.

[0041] It is understood that this implementation extracts factual information from four heterogeneous sources—task description files, technical architecture configuration files, prototype files, and scenario requirement documents—and merges them into a multi-source factual baseline. This ensures that the factual basis constraining the large model covers four dimensions: requirement boundaries, technology selection, interface design, and functional acceptance. In this implementation, the multi-source factual baseline is permanently stored after construction and is uniformly loaded each time the large model session starts. This ensures that different functional units share the same set of constraints when executing at different times, fundamentally eliminating output drift caused by inconsistent constraints.

[0042] In one feasible implementation, the requirement description information includes product help documents and prototype files. The step of parsing the requirement description information and extracting several functional units includes: Read the pre-configured product help document, identify all independent operation units from the product help document, and assign a corresponding page identifier to each independent operation unit; Read the pre-configured prototype file and extract the prototype canvas corresponding to the page identifier from the prototype file; Using the page identifier as the association key, a one-to-one mapping relationship is established between the independent operation unit and the prototype drawing board; Based on the one-to-one mapping relationship, each of the independent operation units is determined as a functional unit.

[0043] It should be noted that the product help document refers to a pre-configured structured document that records all operation instructions and functional descriptions of the industrial software to be developed, including but not limited to the operation steps, interface descriptions, and parameter definitions of each functional module. The independent operation unit refers to the smallest functional entity with complete operational semantics described by a functional page in the product help document, including but not limited to model import operations, frame creation operations, joint addition operations, and driver setting operations. The page identifier is a unique identifier assigned to each independent operation unit, used for indexing and associating the operation unit in subsequent processing. The prototype file refers to a pre-configured visual description file used to describe the interface layout and interactive behavior of the industrial software to be developed. The prototype canvas refers to the interface design canvas corresponding to an independent operation unit in the prototype file, used to describe the interface layout and component states of that operation unit. The one-to-one mapping relationship refers to the bidirectional correspondence between each independent operation unit and its corresponding prototype canvas, bound together by the page identifier as the association key.

[0044] Understandably, this implementation method establishes a one-to-one mapping between independent operation units and prototype canvases by reading product help documents and prototype files, using page identifiers as association keys. Based on this, each independent operation unit is identified as a functional unit, achieving a structured decomposition from document description to visual prototype to delivery unit. In this implementation, the extraction process of the functional units simultaneously anchors to two information sources: the functional description in the product help documents and the interface design in the prototype files. This ensures that each functional unit has both clear document basis and visual interactive reference, providing dual factual constraints for the subsequent code generation of the large model and avoiding potential functional omissions or boundary ambiguities that may occur when decomposing requirements based on only a single information source.

[0045] In one feasible implementation, after the step of generating program code that meets the acceptance criteria for each functional unit using a preset large model, the method further includes: Obtain the set of preset test cases corresponding to the functional unit, wherein the set of preset test cases contains all test cases specified by the acceptance criteria of the functional unit; Execute the pre-set set of test cases, obtain the execution result of each test case, and compare the execution result with the corresponding expected result; When the execution result is inconsistent with the expected result, the code defect location is located based on the comparison result, and the functional boundary description in the scenario requirement document corresponding to the functional unit is revised. Adjust the task plan of the functional unit according to the revised scenario requirements document, and regenerate the program code and supplementary test cases until all test cases in the preset test case set pass the execution.

[0046] It should be noted that the pre-configured test case set refers to a complete set of pre-configured test cases bound to the functional unit, including but not limited to unit test cases, integration test cases, and end-to-end test cases. Each test case contains three elements: input data, execution conditions, and expected results. The execution result refers to the output data or state obtained after actually running the input data of the test case on the program code of the functional unit. The expected result refers to the correct output or state that the program code should produce under given input conditions, as predefined in the test case. The comparison refers to the process of matching the execution result with the expected result item by item to determine whether they are consistent. The code defect location refers to the specific error in the program code located based on difference analysis when the execution result is inconsistent with the expected result. The functional boundary description refers to the information recorded in the scenario requirements document used to define the included and excluded scopes within the functional unit. The task plan refers to the implementation plan of the functional unit, including but not limited to implementation phase division, dependencies, risk identification, and completion definition.

[0047] Understandably, this implementation method achieves closed-loop verification of code quality by acquiring a pre-set set of test cases and performing automated comparisons after the program code is generated. When a test fails, this implementation method does not only correct the code itself, but first revises it at the functional boundary description level of the scenario requirement document, then simultaneously adjusts the task plan and regenerates the code and supplements test cases, ensuring that the four types of assets—requirement documents, task plans, program code, and test cases—maintain synchronous convergence in each iteration. In this implementation method, this closed-loop verification mechanism ensures that the delivery of functional units is always based on acceptance criteria, avoiding problems such as a disconnect between requirement documents and code, and inconsistencies between test coverage and implementation.

[0048] In one feasible implementation, the step of generating program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary using a preset large model includes: Read the pre-configured task execution chain description file, obtain multiple operation steps and their fixed execution order from the task execution chain description file, and use the operation steps and their fixed execution order as the execution framework of the functional unit; Read the pre-configured set of reusable execution units, and obtain the trigger condition field, input contract field, and output contract field of each reusable execution unit from the set of reusable execution units; Using the scene identifier of the functional unit as the query condition, match the target execution unit in the set of reusable execution units whose trigger condition field is consistent with the scene identifier; When no domain execution unit corresponding to the scene identifier is matched in the set of reusable execution units, a domain execution unit loading request is initiated to the set of reusable execution units, domain knowledge data corresponding to the domain type identifier is read from the preset domain knowledge base, and the domain knowledge data is injected into the current session context of the large model; Based on the output boundary, the target execution units are loaded and executed sequentially according to the fixed execution order specified by the execution framework to generate the program code; The step of generating program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary, using a preset large model, includes: Once the program code is generated and passes acceptance, the domain knowledge data generated by the functional unit during execution is extracted, the domain knowledge data is encapsulated into a new reusable execution unit, and the new reusable execution unit is written into the reusable execution unit set.

[0049] It should be noted that the task execution chain description file refers to a pre-configured structured document that records the entire process of operation steps from requirement input to code output and their fixed execution order. These operation steps include, but are not limited to, scenario mapping steps, requirement reading steps, plan update steps, code implementation steps, test supplementation steps, and verification execution steps. The fixed execution order refers to the unchangeable sequence of these operation steps, with the output of the previous step serving as the input of the next. The execution framework refers to a structured execution template extracted from the task execution chain description file and applied to the operation steps and their order within the current functional unit.

[0050] It should be noted that the reusable execution unit set refers to a pre-configured structured data set storing multiple reusable execution units. The reusable execution unit refers to a functional module that encapsulates specific execution logic and domain knowledge, including but not limited to scenario delivery execution units, domain knowledge execution units, and test verification execution units. The trigger condition field refers to the field in the reusable execution unit used to define the conditions required for the execution unit to be activated, including but not limited to scenario identifier matching conditions and domain type matching conditions. The input contract field refers to the field in the reusable execution unit used to define the set of input conditions that must be met before the execution unit can be executed, including but not limited to the required list of fact sources and data format requirements. The output contract field refers to the field in the reusable execution unit used to define the set of results that the execution unit should produce after execution, including but not limited to the output list and format specifications.

[0051] It should be noted that the scene identifier refers to a marker used to uniquely identify a functional unit. The target execution unit refers to a reusable execution unit matched from the set of reusable execution units whose trigger condition field matches the scene identifier of the current functional unit. The domain execution unit refers to an execution unit type among the reusable execution units that encapsulates specific professional domain knowledge, including but not limited to multibody dynamics domain execution units, fluid mechanics domain execution units, and 3D rendering mode execution units. The domain execution unit loading request refers to a request instruction initiated to the set of reusable execution units to trigger the loading of domain knowledge when no required domain execution unit is matched. The domain knowledge base refers to a pre-configured structured data warehouse that stores knowledge data from various professional domains. The domain type identifier refers to a marker used to distinguish different types of professional domain knowledge. The domain knowledge data refers to professional knowledge content read from the domain knowledge base that corresponds to the domain type identifier, including but not limited to domain terminology definitions, constraint equations, and computational models. The current session context refers to the set of session state information maintained by the large model when processing the current functional unit.

[0052] It should be noted that the sequential loading and execution refers to the process of loading the target execution units one by one and driving their execution according to the fixed execution order specified by the execution framework. The domain knowledge data extraction refers to the extraction of reusable knowledge data from the execution process of completed functional units, including but not limited to data format processing experience, interface call patterns, and exception handling strategies. The encapsulation refers to the process of organizing the extracted domain knowledge data according to the field structure of the reusable execution unit to form a new reusable execution unit that conforms to the specifications. The writing refers to adding the new reusable execution unit to the set of reusable execution units, making it part of the set.

[0053] Understandably, this implementation constructs an execution framework by reading the task execution chain description file and matches target execution units from the set of reusable execution units, thus standardizing and pipelined the large model code generation process. When a required domain execution unit is missing, this implementation automatically loads domain knowledge data from the domain knowledge base and injects it into the current session context, ensuring the continuity of the execution process and the integrity of domain knowledge. After the functional unit is delivered, this implementation encapsulates the domain knowledge data generated during execution into a new reusable execution unit and writes it back to the set of reusable execution units, enabling subsequent functional units to directly reuse the accumulated domain knowledge. This achieves self-accumulation and large-scale reuse of engineering capabilities, avoiding the repeated construction of the same domain context in each new functional unit.

[0054] In one feasible implementation, after the step of generating program code that meets the acceptance criteria for each functional unit using a preset large model, the method further includes: Obtain four types of assets corresponding to the functional unit: requirement documents, task plans, program code, and test cases; and perform consistency verification on the four types of assets. When the verification result is inconsistent, the remaining assets in the four asset categories are compared item by item, based on the asset that was last changed among the four asset categories. Based on the item-by-item comparison results, the assets in the four asset categories that are inconsistent with the benchmark are updated synchronously until the contents of the four asset categories are consistent with each other. The four types of assets with consistent content are marked as delivered, and the functional units are updated to the delivered status in the global task dashboard.

[0055] It should be noted that the requirements document refers to a structured description document that records the functional boundaries, acceptance criteria, and known gaps of the functional unit. The task plan refers to a structured description document that records the implementation phase division, dependencies, risk identification, and completion definition of the functional unit. The program code refers to the set of source code files generated by the large model that meet the acceptance criteria of the functional unit. The test cases refer to the test scripts and data set used to verify whether the program code meets the acceptance criteria. The four types of assets refer to the collective term for the requirements document, the task plan, the program code, and the test cases. The consistency verification refers to the process of cross-comparing the current content of the four types of assets to determine whether there are inconsistencies or logical conflicts among them. The asset that was last changed refers to the asset that was most recently modified among the four types of assets. The item-by-item comparison refers to the process of checking whether the content of the other three types of assets conforms to the benchmark content, using the content of the asset that was last changed as a reference. The synchronous update refers to the operation of modifying assets that are inconsistent with the benchmark content according to the item-by-item comparison results to make their content consistent with the benchmark content. The "delivered status" refers to the completion status of a functional unit, indicating that it has met the delivery standards, after the content of the four types of assets has become consistent. The "global task dashboard" is a structured view that records the current progress status of all functional units, including but not limited to the "not started," "in progress," and "delivered" statuses.

[0056] Understandably, this implementation method ensures consistency across the four asset classes—requirements, task plans, program code, and test cases—after code generation. This consistency is achieved through consistency verification and synchronized updates of these four asset classes upon delivery of a functional unit. In this implementation, any change to any asset drives the synchronized updates of the remaining assets, ensuring that the four asset classes evolve collaboratively as a whole. This avoids discrepancies between requirements and program code, and between test cases and implementation. Furthermore, the consistency status of the four asset classes serves as an objective criterion for determining whether a functional unit meets delivery standards. When the content of the four asset classes is consistent, the functional unit is marked as delivered and updated in the global task dashboard, providing a unified status view for overall project progress control.

[0057] It should be noted that in this application, the industrial software development process involving AI is divided into seven stages. The first three stages (Idea, Research, Prototype) converge uncertainty in a sequential execution manner, while the latter four stages (PRD, Kanban, Execute, QA) promote deliverability in a parallel iterative manner. Specifically, in the Idea phase, AI acts as a "problem clarifier" to perform structured analysis of ambiguous requirements and output clear engineering proposition documents; in the Research phase, AI acts as a "technical scout" to search for and analyze candidate technical solutions and output a solidified technical architecture baseline; in the Prototype phase, AI acts as a "prototype generator" to generate high-fidelity UI prototypes and corresponding front-end code frameworks based on product help documents; in the PRD phase, AI acts as a "system decomposer" to map product help document function pages and prototype canvases one by one to deliverable scenarios SC01-SCn, and generate detailed scenario PRDs for each scenario; in the Kanban phase, AI acts as a "plan generator" to organize work packages, identify dependencies, and output a global task Kanban board and scenario-level task plans; in the Execute phase, AI acts as a "process executor" to automatically execute chains according to predefined Skills to advance delivery, achieving parallel evolution of documents, plans, code, and tests; in the QA phase, AI acts as a "quality gatekeeper" to execute unit tests and root-level integration tests within packages, output test reports, and trigger PRD / Plan revisions in reverse. In the above seven-stage process, the output of each stage serves as the input of the next stage and is subject to the hard constraints of a pre-configured multi-source fact baseline, thereby ensuring that the AI's behavior throughout the entire process from fuzzy requirements to verifiable delivery remains within the preset engineering boundaries.

[0058] It should also be noted that the system corresponding to the industrial software collaborative development method of this application includes: a task definition module, used to receive the original task book and output structured engineering propositions; a technology research module, used to perform technical solution retrieval and feasibility verification, generate a technical architecture baseline and write it into the context configuration; a prototype generation module, used to generate a visual UI prototype based on the help document and directly generate the initial front-end code framework from the prototype; a PRD management module, used to maintain the global PRD and scenario PRD, providing fields such as scenario index, target state-MVP boundary, and acceptance criteria; and a task planning module, used to maintain the global Kanban board and scenario plan, and perform dependency analysis, priority ranking and risk assessment. The system comprises several modules: a multi-source fact baseline engine, responsible for extracting facts from six fact sources (task description files, technical architecture configuration files, prototype files, and scenario requirement documents), loading the project context, and dynamically updating the baseline; a Skills automatic execution engine (core module), used to parse Skills definitions, schedule scenario execution chains, handle Skills dependencies, and trigger domain Skills loading; a four-in-one synchronization module, used to monitor change events of four types of assets (PRD, Plan, Code, and QA) and trigger synchronous updates; and a testing and verification module, used to execute in-package unit tests and root-level integration tests, output regression reports, and trigger PRD / Plan revisions. These modules work together, under the scheduling of the Skills automatic execution engine, to jointly achieve collaborative AI development of industrial software based on scenario-based decomposition and multi-source fact-driven approaches.

[0059] For example, this embodiment provides a collaborative development method for industrial software. This method divides the industrial software development process involving artificial intelligence models into seven stages: problem definition, technical feasibility verification, prototype generation, scenario-based requirement specification construction, task planning, AI-driven execution, and testing and verification. The first three stages converge uncertainty through sequential execution, while the latter four stages advance deliverability through parallel iteration.

[0060] In the problem definition phase, the task specification serves as input, including original requirements, target system form, external dependencies, optional technical solutions, and constraints. An artificial intelligence model acts as a problem clarifier, performing structured analysis on ambiguous requirements, identifying core contradictions and key uncertainties, listing issues requiring clarification, and comparing the merits of candidate technical solutions. This phase outputs a clear engineering proposition document, including the problem statement, target boundaries, key uncertainties, and a preliminary set of candidate technical routes.

[0061] In the technical feasibility verification phase, the engineering propositions output from the problem definition phase, along with relevant open-source projects, technical documents, and domain reference implementations, serve as input. The AI ​​model acts as a technical scout, retrieving and analyzing candidate technical solutions, verifying the feasibility of key technical paths, and providing the version number, dependencies, and known risks for each layer of technology selection. This phase outputs a technical architecture baseline, including a layered technology selection table and architecture diagrams, and solidifies key decisions into the project context configuration file as the technical baseline for subsequent phases. The layered technology selection table can cover the geometric kernel layer, 3D rendering layer, topology layer, engineering form layer, build tool layer, and application layer.

[0062] During the prototype generation phase, the product help documentation, reference interface, and technical architecture baseline serve as input. The AI ​​model acts as a prototype generator, generating a high-fidelity user interface prototype covering all functions based on the product help documentation. This prototype is then used as input to directly generate the corresponding front-end code framework. This phase outputs a visual prototype collection and an initial project directory. The visual prototype collection includes the main interface and several functional scene canvases. The initial project directory contains a core package, a geometry package, a rendering package, and a user interface package. The core package stores the domain model, the geometry package encapsulates the geometric kernel, the rendering package handles 3D rendering and interactive processing, and the user interface package stores interface components such as the menu bar, model tree, and attribute panel.

[0063] In the scenario-based requirement specification construction phase, product help documents, prototype whiteboards, and initial code frameworks serve as inputs. An AI model acts as a system decomposer, mapping the functional pages of the product help documents to deliverable scenarios in a one-to-one correspondence, and generating detailed scenario requirement specification documents for each deliverable scenario. This phase outputs a global requirement specification document and scenario requirement specification documents. The global requirement specification document categorizes all scenarios by module, while the scenario requirement specification documents include information source traceability, target state and minimum feasible product boundaries, acceptance criteria, and known gaps.

[0064] In this embodiment, the multi-source fact baseline extracts facts from six heterogeneous sources. The first category is the task specification fact source, anchoring to the engineering proposition and providing strong constraint information such as requirement boundaries, target systems, and external dependencies. The second category is the technical architecture configuration fact source, solidifying the layered technology selection determined in the technical feasibility verification phase into the engineering configuration file, anchoring the architecture decisions. The third category is the visual prototype fact source, with prototype files generated in the prototype generation phase anchoring the interaction design and interface layout. The fourth category is the requirement specification fact source, with the global requirement specification document and the scenario requirement specification document jointly anchoring the functional boundaries and acceptance criteria. The fifth category is the execution unit and plan fact source, with the scenario delivery execution unit and scenario plan anchoring the delivery standards and work sequence. The sixth category is the testing and quality assurance fact source, with testing specifications, quality assurance plans, and historical regression reports anchoring the quality baseline.

[0065] The mechanism for transforming facts into constraints for the AI ​​model involves six types of fact sources being automatically loaded by the AI ​​model at the start of each session via a unified engineering context loading protocol, forming hard constraints on the AI ​​model's generation behavior. Specific methods include writing the technology selection version number, directory structure, and naming conventions into the engineering context configuration file, which the AI ​​model automatically follows when generating code; using the included and excluded scope fields in the scenario requirement specification document as the boundaries of the AI ​​model's generation scope; using the execution unit execution chain as the fixed steps for the AI ​​model to advance its tasks; and using quality assurance verification commands as the objective basis for determining the AI ​​model's completion.

[0066] The multi-source fact baseline continuously evolves throughout the delivery process. When the AI-driven execution phase discovers discrepancies between the requirement specification and the actual implementation, the scenario requirement specification document is revised in reverse. When quality assurance during the testing and verification phase identifies new regression risks, the testing specifications and quality assurance plan are updated. When architectural decisions change, the technical architecture configuration file is updated synchronously, triggering a re-verification of the affected scenarios. Once a scenario is delivered, its accumulated domain knowledge is extracted into reusable domain execution units, expanding the fact source library.

[0067] During the task planning phase, the global requirements specification document and the scenario requirements specification document serve as inputs. The AI ​​model acts as a plan generator, organizing work packages by module, identifying dependencies, prioritizing tasks, and identifying risk points. This phase outputs a global task dashboard and scenario-level task plans. The scenario-level task plans include the current implementation status, technical solutions, implementation phases, risk identification, completion definitions, and verification commands.

[0068] In the AI-driven execution phase, the input includes scenario requirement specifications, scenario plans, current code, and tests. The AI ​​model acts as a process executor, automatically executing the chain according to predefined execution units to advance delivery, with four types of assets—documents, plans, code, and tests—evolving in parallel.

[0069] In this embodiment, the execution unit is a reusable artificial intelligence model execution unit. Each execution unit includes triggering conditions, input contracts, execution steps, output contracts, and dependencies. Triggering conditions define the conditions that must be met for the execution unit to be activated, including but not limited to scene identifiers, keywords, or file types. Input contracts define the list of fact sources required before the execution unit executes. Execution steps are a sequence of operations arranged in a fixed order. Output contracts define the list of results and format specifications that the execution unit should produce. Dependencies define preceding and subsequent execution units.

[0070] Taking the scenario delivery execution unit as an example, when a scenario identifier is input, the AI ​​model automatically proceeds according to the following fixed chain: querying the scenario mapping, reading the global requirements specification document and help page, updating the scenario requirements specification document, updating the scenario plan, updating the scenario quality assurance, implementing the code, supplementing regression testing, and running verification. Each step of the execution chain takes the output of the previous step as input and is constrained by multi-source factual baselines.

[0071] Dependencies between execution units are categorized into three types. The first type is sequential dependency, guaranteed by a fixed execution chain order; for example, reading the requirements specification document must precede the implementation code. The second type is data dependency, guaranteed by matching fields in the input and output contracts, ensuring that the output fields of the preceding execution unit must satisfy the input requirements of the following execution unit. The third type is domain dependency, where domain execution units are called as needed by the scenario execution unit as common dependencies. When a scenario execution unit detects that a required domain execution unit is not loaded during execution, it automatically triggers the loading of the domain execution unit and context injection, ensuring the execution chain remains uninterrupted.

[0072] During the testing and verification phase, the code and tests produced in the AI-driven execution phase, along with the scenario acceptance criteria, serve as input. The AI ​​model acts as a quality gatekeeper, constructing a two-tiered testing system of in-package unit tests and root-level integration tests. After each code modification, it automatically executes tests and regression verifications within the affected scope. This phase outputs test reports, regression verification results, and a quality risk list, and in turn triggers revisions to scenario requirement specifications and plans.

[0073] The four engineering assets—requirement specifications, plans, code, and tests—evolve synchronously in a unified manner. The core rule is that in any AI-driven execution phase of any scenario, a change in any of these four assets must simultaneously trigger corresponding updates in the other three, forming a closed loop. For example, when the requirement specification is inaccurate, the requirement specification document is revised, the plan is adjusted, the code is updated, tests are added, and verification is performed again. This method discovers and utilizes the following pattern: when the requirement specification document accurately describes the product functionality, code development is usually nearing completion. This pattern makes the synchronization between the document and the code itself an objective signal of delivery quality, which can be used to drive the AI ​​model to determine whether the current scenario meets delivery standards.

[0074] Scenario categorization follows a one-to-one correspondence between product help documentation function pages, prototype whiteboards, and delivery scenarios. Each scenario corresponds to an independent operational unit within the product help documentation, such as importing model files, creating a frame, or adding a rotational joint. Each scenario has independent acceptance criteria and a minimum demonstrable path. Scenarios are categorized and numbered by module, forming a complete scenario set. The granularity of scenarios adheres to the minimum closed-loop principle, meaning that a single scenario can be delivered and validated by the AI ​​model in one or a few execution chains.

[0075] The automatic decomposition process for complex requirements is as follows: parse the requirement specification input document to identify all functional pages; map each functional page to the corresponding prototype canvas to generate a document, prototype, and scenario mapping table; number the scenarios by module and write them into the scenario index of the global requirement specification document; generate a scenario requirement specification document skeleton for each scenario, which is then filled in with details by the execution chain of subsequent execution units; and prioritize the implementation of scenarios according to their dependencies.

[0076] In a specific migration case, a desktop-based 3D assisted design tool software, built on a desktop framework and geometric kernel, was migrated to a web-based assisted design tool in plug-in form. This tool possesses complete multibody dynamics modeling capabilities, including model file reading, group design, frame design, joint design, and drive design. The original system's global requirements specification document was broken down into sixty prototype scenes. The migration process involved browser-side compilation of the geometric kernel, 3D picking and snapping, end-to-end linkage between the object tree and attribute panel, and the implementation of professional concepts such as grouping, frames, various joint types, drives, contact, and fluid dynamics.

[0077] During the problem definition phase, after the task description was input, the AI ​​model, acting as a problem clarifier, listed two candidate technical solutions. Solution one involved compiling all desktop-side code into a browser-executable format. This solution relied on a specific software development kit (SDK), resulting in uncontrollable file size. Solution two involved compiling only the geometry engine into a browser-executable format, while rewriting the application layer in another programming language. This solution offered controllable file size and debuggability. The engineering proposition output by the AI ​​model clearly identified that the biggest obstacle to browser-side implementation was not writing the webpage, but rather the core contradiction of whether the geometry engine could run in a browser.

[0078] During the technical feasibility verification phase, the AI ​​model conducted technical reconnaissance by referencing open-source projects. It was verified that the geometry engine could be compiled into a browser-executable format, allowing the browser to directly call the geometry engine to read model files, mesh, and calculate attributes. 3D display was handled by a rendering library. The final technical architecture baseline was as follows: the geometry kernel layer used a browser-executable version of the geometry engine; the 3D rendering layer used a specific version of the rendering library; the topology layer used a graph computation core library; the engineering form layer used a code editor extension and web view; the construction layer used a build tool and package manager workspace; and the application layer used a typed scripting language.

[0079] During the prototype generation phase, the AI ​​model generates high-fidelity prototype files covering all functions based on the product help documentation. These files include two modes for the main interface: multi-body and fluid, as well as sixty scene canvases. The prototype files are used as input to directly generate the initial code for user interface components such as the menu bar, model tree, and attribute panel, while simultaneously building the project directory structure.

[0080] During the scenario-based requirement specification construction phase, the artificial intelligence model maps each of the sixty help document operation pages to a scenario, and after statistically analyzing the functional scope by module, forms a global requirement specification document scenario index. The scenario requirement specification document generated for each scenario includes information source traceability, target state and minimum feasible product boundaries, included and excluded scope, acceptance criteria and known gaps.

[0081] During the task planning phase, work packages are organized hierarchically according to the help documentation directory, including infrastructure work packages, import and browse work packages, multibody design work packages, fluid design work packages, design tool work packages, and save and export work packages.

[0082] This example demonstrates the entire collaborative development process from requirements input to code output, using the import of a single scenario model file as an example. Developers input instructions to advance the scenario into the AI ​​model. The AI ​​model identifies the scenario identifier, triggers the scenario delivery execution unit, and the execution chain progresses in a fixed order. The AI ​​model queries the global requirements specification document's scenario index for the model file import function page under the corresponding model import module, the corresponding prototype canvas, and the corresponding code module. The AI ​​model loads the global requirements specification document and help page, identifies the functional requirement as supporting the selection of local specific file formats, parses the hierarchical structure and part colors, renders it in the 3D view, and displays the hierarchy in the model tree. The AI ​​model generates the scenario's requirements specification document, including information sources, target state, minimum viable product boundaries, scope, and verification standards. The AI ​​model generates the scenario's planning document, identifies dependencies, divides implementation phases, marks risk points, and defines completion commands. The AI ​​model generates the scenario's quality assurance document, including the test scope, critical path, boundary scenarios, and automation commands.

[0083] The AI ​​model generates code under multi-source fact baseline constraints, including implementing a file reading class in the geometry package to call the browser-side binding of the geometry engine; implementing scene building methods in the rendering package to create rendering objects by grouping parts; and implementing a hierarchical tree component in the user interface package and binding it to the scene builder output. The entire code generation process strictly adheres to the technology selection version numbers, directory structure, and naming conventions fixed in the project context configuration file.

[0084] The AI ​​model automatically generates three layers of test cases—file reading tests, scenario building tests, and end-to-end tests—based on the test scope defined in the quality assurance document, covering critical paths and boundary scenarios. The AI ​​model automatically executes test commands and outputs test reports. If a test fails, the AI ​​model reverse-engineers the failure reason, revising the requirements specification description, adjusting the plan, fixing code, and adding tests until all tests pass.

[0085] After the execution chain is completed, the four types of assets—requirement specification documents, plans, code, and tests—reach a consensus. The artificial intelligence model determines that the scenario has been delivered, marks the scenario as delivered in the global dashboard, updates the multi-source fact baseline, and precipitates the practice of color parsing model files into domain execution units for reuse in subsequent scenarios.

[0086] When adding a rotational joint in another scene, triggering the execution chain during the AI-driven execution phase, the AI ​​model detects that the required multibody dynamics domain knowledge execution unit is not loaded. It automatically loads the execution unit before generating the joint definition code, ensuring that the joint degrees of freedom, constraint equations, and coordinate system definitions conform to multibody dynamics semantics. When adding fluid boundary conditions in yet another scene, the fluid domain execution unit is automatically loaded in the same manner, and the rendering mode execution unit is reused, avoiding the repeated construction of the domain context in each new scene.

[0087] Using the method provided in this embodiment, the migration project supports basic functions such as cloud platform deployment, model file import, rigid body grouping design, and standard frame design. All sixty scenarios are implemented according to a unified standard, and the four types of assets—documentation, planning, code, and testing—remain highly synchronized, without any disconnect between requirement specifications and code, or between testing and implementation. Developer experience is distilled into reusable execution units, requirement specification templates, prototype assets, testing standards, and domain knowledge bases, providing scalable and reusable engineering capabilities for subsequent new projects.

[0088] As an alternative implementation, the sources of multi-source fact baselines are not limited to the six categories mentioned above, and the types of fact sources can be added or reduced according to actual engineering needs. For example, for backend industrial computing software that does not involve a user interface, the prototype file fact source can be omitted, and only the task specification fact source, technical architecture configuration fact source, requirement specification fact source, execution unit and plan fact source, and testing and quality assurance fact source can be retained.

[0089] As an alternative implementation, the triggering method for the execution unit is not limited to scene identifier matching; it can also employ at least one of functional unit type tag matching, file type matching, or keyword matching. The fixed order of the execution chain can be adjusted according to different scene types. For example, for pure repair scenarios, the verification step can be moved forward, forming an execution order of verification followed by modification.

[0090] As another alternative implementation method, the triggering condition of the four-in-one collaborative evolution mechanism is not limited to triggering when any asset changes. It can also be triggered by timed batch verification, or by uniformly triggering consistency verification after a preset number of functional units are detected in the global dashboard.

[0091] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the collaborative development method of industrial software in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0092] This application also provides an industrial software collaborative development device; please refer to [reference needed]. Figure 2 The industrial software collaborative development device includes: Module 10 is used to acquire the requirements description information of the industrial software to be developed. The parsing module 20 is used to parse the requirement description information, extract several functional units, and establish corresponding acceptance criteria for each functional unit. The confirmation module 30 is used to read the pre-configured multi-source fact baseline and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; The output module 40 is used to generate program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary and a preset large model.

[0093] And / or, the industrial software collaborative development device includes: The first reading module is used to read the pre-configured task description file; The first extraction module is used to extract requirement boundary information and external dependency information from the task description file, and use the requirement boundary information and external dependency information as the first source of fact. The second reading module is used to read the pre-configured technical architecture configuration file; The second extraction module is used to extract layered technology selection data from the technology architecture configuration file and use the layered technology selection data as a second source of fact. The third reading module is used to read pre-configured prototype files; The third extraction module is used to extract interface layout information and interaction design information from the prototype file and use the interface layout information and interaction design information as a third source of fact. The fourth reading module is used to read pre-configured scenario requirement documents; The fourth extraction module is used to extract functional boundary information and acceptance condition information from the scenario requirement document, and to use the functional boundary information and acceptance condition information as the fourth source of fact. The first merging module is used to merge the first fact source, the second fact source, the third fact source, and the fourth fact source into the multi-source fact baseline; And / or, the industrial software collaborative development device includes: The fifth reading module is used to read pre-configured product help documents; The first identification module is used to identify all independent operating units from the product help document; The first allocation module is used to allocate a corresponding page identifier to each of the independent operation units; The sixth reading module is used to read pre-configured prototype files; The fifth extraction module is used to extract the prototype canvas corresponding to the page identifier from the prototype file; The first module is used to establish a one-to-one mapping relationship between the independent operation unit and the prototype drawing board, using the page identifier as the association key. The first determining module is used to determine each of the independent operation units as a functional unit based on the one-to-one mapping relationship; And / or, the industrial software collaborative development device includes: The first acquisition module is used to acquire a set of preset test cases corresponding to the functional unit, wherein the set of preset test cases includes all test cases specified by the acceptance criteria of the functional unit. The first execution module is used to execute the preset test case set and obtain the execution result of each test case; The first comparison module is used to compare the execution result with the corresponding expected result; The first positioning module is used to locate the code defect location based on the comparison result when the execution result is inconsistent with the expected result. The first revision module is used to revise the functional boundary description in the scenario requirement document corresponding to the functional unit; The first adjustment module is used to adjust the task plan of the functional unit according to the revised scenario requirements document; The first regeneration module is used to regenerate the program code and supplementary test cases until all test cases in the preset test case set pass the execution. And / or, the industrial software collaborative development device includes: The seventh reading module is used to read the pre-configured task execution chain description file; The sixth extraction module is used to obtain multiple operation steps and their fixed execution order from the task execution chain description file, and use the operation steps and their fixed execution order as the execution framework of the functional unit. The eighth reading module is used to read a pre-configured set of reusable execution units; The seventh extraction module is used to obtain the trigger condition field, input contract field and output contract field of each reusable execution unit from the set of reusable execution units; The first matching module is used to match target execution units in the set of reusable execution units whose trigger condition fields are consistent with the scene identifier, using the scene identifier of the functional unit as the query condition; The first initiation module is used to initiate a domain execution unit loading request to the set of reusable execution units when no domain execution unit corresponding to the scene identifier is matched in the set of reusable execution units. The ninth reading module is used to read domain knowledge data corresponding to the domain type identifier from a pre-set domain knowledge base; The first injection module is used to inject the domain knowledge data into the current session context of the large model; The first loading module is used to load and execute the target execution units sequentially according to the fixed execution order specified by the execution framework, based on the output boundary, to generate the program code; The eighth extraction module is used to extract the domain knowledge data generated by the functional unit during execution after the program code is generated and passes acceptance. The first encapsulation module is used to encapsulate the domain knowledge data into a new reusable execution unit; The first writing module is used to write the new reusable execution unit into the reusable execution unit set; And / or, the industrial software collaborative development device includes: The second acquisition module is used to acquire four types of assets corresponding to the functional unit: requirement documents, task plans, program code, and test cases. The first verification module is used to perform consistency verification on the four types of assets. The second comparison module is used to compare the remaining assets in the four asset categories one by one, based on the asset that was last changed among the four asset categories, when the verification result is inconsistent. The first update module is used to synchronously update the assets in the four asset categories that are inconsistent with the benchmark based on the item-by-item comparison results, until the contents of the four asset categories are consistent with each other. The first marking module is used to mark the four types of assets with consistent content as delivered. The second update module is used to update the functional unit to the delivered status in the global task dashboard.

[0094] The industrial software collaborative development device provided in this application, employing the industrial software collaborative development method in the above embodiments, can solve the technical problem of poor stability of auxiliary programming output in conventional technologies. Compared with related technologies, the beneficial effects of the industrial software collaborative development device provided in this application are the same as those of the industrial software collaborative development method provided in the above embodiments, and other technical features in the industrial software collaborative development device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0095] This application provides an industrial software collaborative development device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the industrial software collaborative development method in Embodiment 1 above.

[0096] The following is for reference. Figure 3 The diagram illustrates a structural schematic of an industrial software collaborative development device suitable for implementing embodiments of this application. The industrial software collaborative development device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital televisions and desktop computers. Figure 3 The industrial software collaborative development equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0097] like Figure 3As shown, the industrial software collaborative development equipment may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the industrial software collaborative development equipment. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the industrial software collaborative development equipment to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows industrial software collaborative development equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0098] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0099] The industrial software collaborative development equipment provided in this application, employing the industrial software collaborative development method described in the above embodiments, can solve the technical problem of poor stability of auxiliary programming output in conventional technologies. Compared with related technologies, the beneficial effects of the industrial software collaborative development equipment provided in this application are the same as those of the industrial software collaborative development method provided in the above embodiments, and other technical features of this industrial software collaborative development equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0100] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0101] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0102] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the industrial software collaborative development method in the above embodiments.

[0103] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More 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 or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0104] The aforementioned computer-readable storage medium may be included in the industrial software collaborative development equipment; or it may exist independently and not be assembled into the industrial software collaborative development equipment.

[0105] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the industrial software collaborative development equipment, enable the industrial software collaborative development equipment to: acquire the requirements description information of the industrial software to be developed; The requirement description information is parsed to extract several functional units, and corresponding acceptance criteria are established for each functional unit. Read the pre-configured multi-source fact baseline, and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; Based on the confirmed output boundaries, a pre-defined large model generates program code for each functional unit that meets the acceptance criteria.

[0106] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing 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 indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0108] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0109] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described industrial software collaborative development method, which can solve the technical problem of poor stability of auxiliary programming output in conventional technologies. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the industrial software collaborative development method provided in the above embodiments, and will not be repeated here.

[0110] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the industrial software collaborative development method described above.

[0111] The computer program product provided in this application can solve the technical problem of poor stability of auxiliary programming output in conventional technologies. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the industrial software collaborative development method provided in the above embodiments, and will not be repeated here.

[0112] All acquisition of signals, information, or actions in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the relevant device owner.

[0113] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A collaborative development method for industrial software, characterized in that, The method includes: Obtain the requirements description information for the industrial software to be developed; The requirement description information is parsed to extract several functional units, and corresponding acceptance criteria are established for each functional unit. Read the pre-configured multi-source fact baseline, and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline; Based on the confirmed output boundaries, a pre-defined large model generates program code for each functional unit that meets the acceptance criteria.

2. The method as described in claim 1, characterized in that, Prior to the step of reading the pre-configured multi-source fact baseline, the following includes: Read the pre-configured task description file, extract the requirement boundary information and external dependency information from the task description file, and use the requirement boundary information and external dependency information as the first source of fact. Read the pre-configured technical architecture configuration file, extract the layered technology selection data from the technical architecture configuration file, and use the layered technology selection data as the second source of fact; Read the pre-configured prototype file, extract the interface layout information and interaction design information from the prototype file, and use the interface layout information and interaction design information as a third source of fact; Read the pre-configured scenario requirement document, extract functional boundary information and acceptance condition information from the scenario requirement document, and use the functional boundary information and acceptance condition information as the fourth source of fact; The first fact source, the second fact source, the third fact source, and the fourth fact source are merged into the multi-source fact baseline.

3. The method as described in claim 1, characterized in that, The requirement description information includes product help documents and prototype files. The steps of parsing the requirement description information and extracting several functional units include: Read the pre-configured product help document, identify all independent operation units from the product help document, and assign a corresponding page identifier to each independent operation unit; Read the pre-configured prototype file and extract the prototype canvas corresponding to the page identifier from the prototype file; Using the page identifier as the association key, a one-to-one mapping relationship is established between the independent operation unit and the prototype drawing board; Based on the one-to-one mapping relationship, each of the independent operation units is determined as a functional unit.

4. The method as described in claim 1, characterized in that, After the step of generating program code that meets the acceptance criteria for each functional unit using a preset large model, the method further includes: Obtain the set of preset test cases corresponding to the functional unit, wherein the set of preset test cases contains all test cases specified by the acceptance criteria of the functional unit; Execute the pre-set set of test cases, obtain the execution result of each test case, and compare the execution result with the corresponding expected result; When the execution result is inconsistent with the expected result, the code defect location is located based on the comparison result, and the functional boundary description in the scenario requirement document corresponding to the functional unit is revised. Adjust the task plan of the functional unit according to the revised scenario requirements document, and regenerate the program code and supplementary test cases until all test cases in the preset test case set pass the execution.

5. The method as described in claim 1, characterized in that, The step of generating program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary, using a preset large model, includes: Read the pre-configured task execution chain description file, obtain multiple operation steps and their fixed execution order from the task execution chain description file, and use the operation steps and their fixed execution order as the execution framework of the functional unit; Read the pre-configured set of reusable execution units, and obtain the trigger condition field, input contract field, and output contract field of each reusable execution unit from the set of reusable execution units; Using the scene identifier of the functional unit as the query condition, match the target execution unit in the set of reusable execution units whose trigger condition field is consistent with the scene identifier; When no domain execution unit corresponding to the scene identifier is matched in the set of reusable execution units, a domain execution unit loading request is initiated to the set of reusable execution units, domain knowledge data corresponding to the domain type identifier is read from the preset domain knowledge base, and the domain knowledge data is injected into the current session context of the large model; Based on the output boundary, the target execution units are loaded and executed sequentially according to the fixed execution order specified by the execution framework to generate the program code; The step of generating program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary, using a preset large model, includes: Once the program code is generated and passes acceptance, the domain knowledge data generated by the functional unit during execution is extracted, the domain knowledge data is encapsulated into a new reusable execution unit, and the new reusable execution unit is written into the reusable execution unit set.

6. The method as described in claim 1, characterized in that, After the step of generating program code that meets the acceptance criteria for each functional unit using a preset large model, the method further includes: Obtain four types of assets corresponding to the functional unit: requirement documents, task plans, program code, and test cases; and perform consistency verification on the four types of assets. When the verification result is inconsistent, the remaining assets in the four asset categories are compared item by item, based on the asset that was last changed among the four asset categories. Based on the item-by-item comparison results, the assets in the four asset categories that are inconsistent with the benchmark are updated synchronously until the contents of the four asset categories are consistent with each other. The four types of assets with consistent content are marked as delivered, and the functional units are updated to the delivered status in the global task dashboard.

7. An industrial software collaborative development device, characterized in that, The device includes: The acquisition module is used to acquire the requirements description information of the industrial software to be developed. The parsing module is used to parse the requirement description information, extract several functional units, and establish corresponding acceptance criteria for each functional unit. The confirmation module is used to read the pre-configured multi-source fact baseline and perform baseline confirmation on the output boundary of each functional unit based on the multi-source fact baseline. The output module is used to generate program code that meets the acceptance criteria for each functional unit based on the confirmed output boundary and a preset large model.

8. An industrial software collaborative development device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the industrial software collaborative development method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the industrial software collaborative development method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the industrial software collaborative development method as described in any one of claims 1 to 6.

Images