A software development system and a software development method

Abstract

The application belongs to the technical field of software development, and particularly relates to a software development system and a software development method. The BERT-base-based semantic understanding model can accurately extract function parameters, performance indexes and constraint conditions in natural language requirements, a three-layer verification mechanism of a technical entity design rule set is combined to ensure requirement compliance and integrity, priority calculation of the analytic hierarchy process makes development resources focus on core requirements, greatly reduces requirement deviation rate, through requirement hierarchical decomposition and intelligent matching of a component template library, combined with deep optimization of a technical entity design model, including design pattern adaptation, interface standardization and performance strategy customization, the generated core function components, auxiliary function components and interface components not only meet individualized requirements, but also meet performance requirements, and component reuse rate and development efficiency are significantly improved.

Description

Technical Field

[0001] This invention belongs to the field of software development technology, specifically relating to a software development system and a software development method. Background Technology

[0002] In the current software development process, there are problems such as low efficiency in requirement transformation, chaotic collaborative development process, poor component reusability, and insufficient testing focus.

[0003] In the traditional development model, user natural language requirements need to be manually broken down into technical parameters, which is prone to misunderstandings and lacks a standardized verification mechanism, resulting in frequent requirement loopholes. To address this, an improved software development system and software development method have been designed. Summary of the Invention

[0004] In view of the above-mentioned shortcomings in the prior art, the present invention provides a software development system and a software development method to solve the problems in the background art.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A software development methodology includes the following steps: S1: Receive natural language requirements input by the user, extract functional parameters, performance indicators and constraints from the natural language requirements through a semantic understanding model, verify them using technical entity design rules, and generate a list of requirements and requirement priority weights after the verification is qualified. S2: Based on the requirement list and requirement priority weights generated in step S1, call the templates in the component template library, combine them with the technical entity design model, and generate the development components; S3: Build a multi-role collaborative workspace, synchronize the requirement list generated in step S1 and the development components generated in step S2 to the collaborative space, and record the development progress in the collaborative space in real time. S4: Based on the requirements list in step S1, generate unit test, integration test and performance test cases, test the development components in step S3, provide real-time feedback on test results, and optimize test cases in conjunction with the technical entity design model until the test is qualified.

[0006] Preferably, in step S1, the training method of the semantic understanding model includes the following steps: S2.1: Construct a training dataset, which includes natural language demand samples and corresponding annotation information. The annotation information includes functional parameter annotations, performance index annotations, and constraint annotations. Clean, deduplicate, and normalize the training dataset, and divide it into a training set, a validation set, and a test set. S2.2: Select a pre-trained language model as the base model. Specifically, the pre-trained language model is the BERT-base model. The bottom parameters of the base model are frozen, while the top parameters are retained for training. A domain adaptation layer and a classification extraction head are added to the top of the base model to obtain the trained model. The domain adaptation layer adopts a fully connected layer structure. The extraction head contains three independent classification branches, which correspond to the classification extraction of functional parameters, performance indicators, and constraints, respectively. S2.3: The training set is used to train the constructed training model, with the cross-entropy loss function as the optimization objective. The model parameters are adjusted in combination with the Adam optimizer. During the training process, the model extraction accuracy is monitored in real time through the validation set. When the validation set accuracy does not improve for a preset number of consecutive rounds, the training is stopped. S2.4: Use the test set to test the performance of the trained model. If the model's extraction accuracy and recall both reach the preset threshold, the model training is considered complete. If the preset threshold is not reached, return to step S2.1 to expand the training dataset or adjust the model structure and retrain until the preset requirements are met.

[0007] Preferably, the verification of the technical entity model design rules specifically includes: S3.1: The functional parameters, performance indicators and constraints obtained in step S1 are used as the objects to be verified; S3.2: Call the technical entity design rule set, which includes parameter legality rules, indicator rationality rules and constraint compatibility rules. The parameter legality rules are used to verify whether the format and value of the functional parameters conform to the technical specifications. The indicator rationality rules are used to verify whether the performance indicators are within the reasonable range of industry norms and can be achieved. The constraint compatibility rules are used to verify that there are no conflicts between the various constraints and between the constraints and the functional parameters and performance indicators. S3.3: First, verify all functional parameters one by one through parameter validity rules, then verify performance indicators through indicator rationality rules, and finally verify overall correlation through constraint compatibility rules. During the verification process, mark the verification result of each object to be verified as qualified or unqualified, and mark the violation type for unqualified objects. S3.4: If all objects to be verified pass the verification, proceed to the requirement organization and priority calculation stage. If there are unqualified objects, generate a prompt message containing violation details and send it back to the user. After receiving the user's modification instruction, re-extract the modified objects to be verified and return to step S3.3 for verification again until all are qualified.

[0008] Preferably, in step S3.4, the requirement sorting and priority calculation step specifically includes: The verified functional parameters, performance indicators, and constraints are categorized and organized to form a requirement list. The specific description and associated technical requirements of each requirement item are clarified. The priority weight of each requirement item is calculated using the analytic hierarchy process. A judgment matrix is ​​constructed by combining the three dimensions of user requirement urgency, development difficulty, and business value. After passing the consistency check, a weight value in the range of 0-1 is assigned to ensure that the sum of the weight values ​​of all requirement items is 1. Finally, the requirement list and the corresponding requirement priority weights are output.

[0009] Preferably, in step S2, the step of generating the development component is as follows: S5.1: Extract the functional parameters, performance indicators and constraints from the requirement list generated in step S1. Combine the requirement priority weights to decompose the requirements into layers, distinguish the mandatory functional components corresponding to the core requirements and the optional functional components corresponding to the secondary requirements. Based on the decomposed functional requirements, call the retrieval module of the component template library and filter out the candidate templates corresponding to each functional requirement through keyword matching and functional similarity comparison. S5.2: Perform preliminary configuration on the selected candidate templates. Based on the specific parameters in the requirements list, adjust the basic configuration items of the templates, delete redundant modules that are irrelevant to the requirements, and add core modules that are clearly required by the requirements. S5.3: Input the pre-adapted template and the requirement list and requirement priority weights generated in step S1 into the technical entity design model. The technical entity design model performs in-depth optimization of the template based on component design specifications, interface adaptation standards and performance optimization rules. S5.4: Output the optimized template configuration parameters based on the technical entity design model, compile and generate the corresponding development components, and then verify the development components. The verification content includes component integrity, interface standardization and matching degree with the requirements list. If the preliminary verification fails, return to step S5.3 to re-optimize the template configuration. S5.5: If the verification is successful, the development component is confirmed to be generated. The generated development component is then synchronized to the system cache for subsequent collaborative development.

[0010] Preferably, in step S5.3, the depth optimization includes: The technical entity design model matches the applicable design pattern to the development components based on the functional parameters in the requirements list, and reconstructs the division and dependency relationship of the internal modules of the components according to the cohesion coupling degree standard to ensure that the cohesion of a single module is higher than the first preset threshold and the coupling degree between different modules is lower than the second preset threshold. The technical entity design model selects communication protocols and data formats for the development components based on the interaction requirements of the components in the requirements list and other components, and generates or adjusts the corresponding interface application programming interface definitions. The technical entity design model parses the performance indicators in the requirements list, decomposes the abstract indicators into quantitative constraints that can be applied to component design, and calls the corresponding optimization strategy according to the constraint type; including: For response time metrics, employ algorithm optimization, caching, or asynchronous processing strategies. For resource consumption metrics, connection pool reuse, lazy loading, or resource release strategies are employed. For concurrency metrics, thread pool configuration, lock optimization, or stateless design strategies can be adopted.

[0011] Preferably, in step S5.4, the development components include core functional components, auxiliary functional components, and interface components.

[0012] Preferably, in step S3, the specific method for building a multi-role collaborative workspace is as follows: S8.1: The underlying framework of the collaborative workspace is built using a distributed architecture, including server node deployment, data storage module configuration, and network communication module setup; S8.2: Presets four core roles: developers, testers, product personnel, and operations personnel. Configures the operation permissions of each role based on the principle of least privilege. Developers have the permission to view, edit, and submit development components; testers have the permission to view the requirement list, development components, and enter test results; product personnel have the permission to view, review, and submit modification suggestions for the requirement list; and operations personnel have the permission to monitor the operation status of the collaborative space and handle anomalies. S8.3: Deploy the requirement and component synchronization module, development task allocation module, and real-time progress recording module within the collaborative space; S8.4: Through the development task allocation module, the requirement items in the requirement list of step S1 and the development components generated in step S2 are allocated to the developers of the corresponding roles, taking into account the requirement priority weights. S8.5: The development progress is recorded in real time through the real-time progress recording module. The development progress includes task completion rate, problem resolution timeliness and component iteration number.

[0013] Preferably, the method for testing the development components in step S4 includes: S9.1: Based on the requirements list generated in step S1, extract the functional parameters, performance indicators and constraints as the basis for testing; S9.2: Based on the hierarchy and dependencies of the core functional components, auxiliary functional components, and interface components generated in step S2, generate test cases, which include: S9.2.1: For a single core functional component or auxiliary functional component, generate unit test cases to verify its logical functions and data processing capabilities; S9.2.2: For multiple components that interact with each other, generate integration test cases to verify the interface calls, data transfer, and overall functional implementation between the components; S9.2.3: Generate load test, stress test, and concurrency test cases for the performance metrics in the requirements list to verify the performance metrics compliance. S9.3: Based on the test cases generated in step S9.2, perform tests on the development components in the predetermined order of unit testing, integration testing, and performance testing; S9.4: Capture and record the execution process and results of each test in real time, including test pass, test failure and test error. For test cases that fail, record the failure location and the difference between the expected result and the actual result. For test cases that have errors, record the error exception information. S9.5: Feed back the test results recorded in step S9.4 to the collaborative workspace in real time and synchronize them with the corresponding developers and testers; S9.6: Input the test results and component defects exposed during the test into the technical entity design model. The technical entity design model optimizes and generates more targeted test cases through component design specifications, interface adaptation standards and performance optimization rules. S9.7: Based on the optimized test cases, return to step S9.3 and re-perform the tests until all levels of test cases pass.

[0014] A software development system, comprising: The requirement processing module is used to receive natural language requirements input by users, extract functional parameters, performance indicators and constraints from the natural language requirements through a semantic understanding model, verify them using technical entity design rules, and generate a requirement list and requirement priority weights after the verification is qualified. Component generation module: Based on the requirement list and requirement priority weights generated in step S1, it calls the corresponding templates in the component template library, combines them with the technical entity design model, and generates development components. Collaborative Development Management Module: Used to build a multi-role collaborative workspace, synchronize the requirement list generated in step S1 and the development components generated in step S2 to the collaborative space, and record the development progress in the collaborative space in real time. Dynamic testing and optimization module: Based on the requirements list in step S1, it generates unit test, integration test and performance test cases, tests the development components in step S3, provides real-time feedback on test results, and optimizes test cases in conjunction with the technical entity design model until the test is qualified.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. The semantic understanding model based on BERT-base can accurately extract functional parameters, performance indicators and constraints from natural language requirements. Combined with the three-layer verification mechanism of the technical entity design rule set, it ensures the compliance and completeness of requirements. The priority calculation of the analytic hierarchy process allows development resources to focus on core requirements, greatly reducing the requirement deviation rate. 2. Through layered decomposition of requirements and intelligent matching of component template library, combined with in-depth optimization of technical entity design model, including design pattern adaptation, interface standardization and performance strategy customization, the generated core functional components, auxiliary functional components and interface components not only meet personalized needs, but also meet performance requirements, significantly improving component reusability and development efficiency. 3. A multi-role collaborative workspace built on a distributed architecture allocates operation permissions based on the principle of least privilege. Through modules for automatic task allocation, real-time progress recording, and data synchronization, it enables efficient collaboration among development, testing, product, and operations personnel. Data visualization, such as task completion rate and problem resolution timeliness, makes the development process traceable and controllable. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating an embodiment of a software development system and software development method according to the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solution of the present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0018] The accompanying drawings are for illustrative purposes only and are schematic diagrams, not actual images. They should not be construed as limiting the scope of this patent. To better illustrate the embodiments of the present invention, some parts in the drawings may be omitted, enlarged, or reduced, and do not represent the actual dimensions of the product. It is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0019] In the accompanying drawings of the embodiments of the present invention, the same or similar reference numerals correspond to the same or similar components. In the description of the present invention, it should be understood that if terms such as "upper," "lower," "left," "right," "inner," and "outer" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, the terms used to describe positional relationships in the drawings are only for illustrative purposes and should not be construed as limiting the present patent. For those skilled in the art, the specific meaning of the above terms can be understood according to the specific circumstances.

[0020] In the description of this invention, unless otherwise explicitly specified and limited, the term "connection" or similar designation indicating a connection between components should be interpreted broadly. For example, it can refer to a fixed connection, a detachable connection, or an integral part; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can refer to the internal communication between two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] Example 1: like Figure 1 The invention discloses a software development system and method. When a user inputs natural language requirements for an enterprise customer management system (CRM system) through the system's interactive interface, the system uses a pre-trained semantic understanding model to process these natural language requirements, extracting functional parameters, performance indicators, and constraints. The training method for the semantic understanding model is as follows: Requirements processing module: Collect 1000 natural language requirement samples from various CRM systems and office systems, label each sample with functional parameters, performance indicators and constraints, clean the samples: delete invalid characters, remove duplicates, normalize the parameter format, and then divide the training set, validation set and test set in a 7:2:1 ratio. Model Construction: The BERT-based pre-trained language model was selected as the text feature encoder. This model has a 12-layer Transformer structure with an output dimension of 768. To fully utilize the powerful semantic knowledge learned by BERT in general languages ​​and to prevent overfitting on small datasets, a partial freezing strategy was adopted, freezing the parameters of the bottom 8 layers of BERT so that they do not participate in training. A fully connected layer Linear (768, 512) was added to the top layer of BERT as a domain adaptation layer. Above the domain adaptation layer, three independent fully connected layers were connected in parallel as classification heads, corresponding to the three types of information extraction tasks respectively. Functional parameter classification header: Linear(512, ), This represents the total number of functional parameter categories.

[0022] Performance metric classification header: Linear(512, ), This represents the total number of performance metric categories.

[0023] Constraint Classification Header: Linear(512, ), This represents the total number of constraint categories.

[0024] The model is defined by the forward propagation process, and its computational flow is as follows: Taking functional parameters as an example: Input text The result of training the model is that it obtains text sequences. Input the frozen 8-layer BERT-base model and obtain the context encoding. , From the fine-tuned BERT Extracting sentence-level global representation vectors from marked locations Then, a nonlinearity is introduced in the fully connected domain adaptation layer using the ReLU activation function: ,in , This compresses the 768-dimensional features into 512-dimensional neighborhood enhancement features. Converting domain features into normalized scores specifically involves performing a linear transformation on them. ,in The scores are transformed into a probability distribution using the Softmax function. , No. The predicted probability of the class is: Then, cross-entropy corruption is used for calculation, i.e., for example... There are 5 categories: irrelevant items (0), report generation items (1), user management items (2), data export items (3), and approval process items (4). Their actual label vectors are as follows: Irrelevant items: Report generation items: User management items: Data export items: Approval process items: The probability distribution is compared with the true label. Since it is a multi-task classification, the loss is calculated separately for each task. For a single task, the cross-entropy between the current model's predicted probability distribution and the true label is calculated using the cross-entropy loss function. The formula for calculating the loss value for each task is as follows: During training, it is done in batches. Assume a batch has... If there are [number] samples, then the total loss for this batch on the functional parameter task is [number]. The average loss of each sample: Calculate the loss of each of the three classification heads for the task samples in this batch in turn, and obtain the sum of the final losses: The optimization settings are as follows: Use the AdamW optimizer, with an initial learning rate set to... The batch size is 32, and a maximum of 50 training rounds are performed. In each training round, the overall classification accuracy (precision) is calculated on the validation set. If the validation set accuracy does not improve for five consecutive rounds, training is terminated. After training, the model is tested as follows: For each task, namely the functional parameters, performance metrics, and constraints, let's take the functional parameters as an example to calculate the calculation for each category. accuracy Recall rate And F1 value: This represents the proportion of the model's correct predictions out of all predictions, where the denominator is the class the model considers to be... Of all predictions, the numerator represents the correct predictions. All true categories in the denominator test set The sample, or molecule, is identified by the model from the real sample. Then, the F1 score is used to comprehensively measure the recognition ability of this category; For each task, calculate the macro-average precision, recall, and F1 score, which represents all values ​​for that task. The arithmetic mean of the corresponding indicators for each category; Task macro average precision: ; Average recall rate for task macros: ; Task macro average F1: ; Then, the three tasks are combined to calculate the final model's precision, recall, and F1 score. Accuracy: ; Recall rate: ; F1: ; If both final precision and final recall are greater than or equal to 95%, the validation is passed.

[0025] Using the trained language understanding model, the CRM system requirements input by the user are extracted to obtain functional parameters: customer information entry, customer classification management, sales follow-up records, and data statistics; performance indicators: system response time; and constraints: security constraints and compatibility constraints. These are verified by calling the entity design rule set. The process for constructing an entity design rule set is as follows: First, the user's natural language is read through the requirement list item by item by business analysts and product managers to identify the core business objects and operations or behaviors in each requirement. Then, a table tool is used to record the requirement ID (e.g., R1), the original requirement description, the extracted business entities (e.g., "customer", "sales record"), the extracted operations (e.g., "entry", "query"), business constraints (e.g., "required", "unique"), and priority weights for each requirement, resulting in a requirement-entity mapping table (e.g., an Excel spreadsheet). The process involves aggregating all extracted business entities from the requirements, merging synonyms (e.g., whether "customer" and "user" refer to the same concept), creating an entity list, and having the business analyst assign a unique identifier to each entity. For each entity, attributes are merged from all related requirements to form a preliminary entity attribute list. For example, if the "customer" entity is extracted from R1, R2, and R3, the merged entity list would be: Customer, SalesRecord, and Report. Customer's attributes are merged as follows: R1: Name, Phone Number, Email, Address; R2: Customer Level, Category Tag; R3: Customer Status (Potential / Converted / Chapped). After merging, Customer contains all attributes, resulting in the final business entity list. Architects and developers then analyze the business relationships between entities (one-to-one, one-to-many, many-to-many) using this business entity list, identify associated attributes (e.g., "Sales Record" associated with "Customer ID"), and draw a business entity relationship diagram (an ER diagram at the business level). Technical architecture selection and layered design: Assess the requirements characteristics (such as concurrency, data volume, and security requirements), consider the team's familiarity with the technology stack, recruitment difficulty, and community support, compare candidate technical solutions, and generate a decision document through meetings with architects, technical leads, and development team representatives. Then, adopt a four-layer DDD architecture: Presentation Layer: UI components, API interfaces; Application Layer: business use cases, service orchestration; Domain Layer: core business entities, domain services; and Infrastructure Layer: database access, external service calls. Draw a layered architecture diagram and transform non-functional requirements (performance, security, compatibility) into specific technical principles. Formulate design constraints (such as all APIs must be idempotent, all sensitive data must be encrypted) to form a technical design principle document. Then, transform the business entities and architecture into executable technical specifications, specifically: determine the data type of each field (varchar, int, datetime), determine the field length and precision, define constraints (primary key, foreign key, unique index, NOT NULL), and consider indexing strategies (which fields need indexes). Use database design tools to draw a physical ER diagram and generate DDL scripts (table creation statements). Domain model design: Map business entities to domain object classes (DomainClass), define class properties (corresponding database fields), define class methods (such as business behaviors, such as Customer), define value objects (such as immutable objects like Money, Address, etc.), and use UML class diagram tools to draw the domain model diagram; API / Service Interface Design: Design RESTful APIs or gRPC services for each core business operation, define the following for each API: HTTP method (GET / POST / PUT / DELETE), URL path, request parameters (path parameters, query parameters, request body), response body format (JSON structure), HTTP status codes (200 / 400 / 500, etc.), write API documentation using OpenAPI / Swagger specifications, and define DTO (Data Transfer Object) structures.

[0026] UI component design guidelines: Define front-end component specifications based on the requirement type (form, list, chart). Define the component's: Props (input attributes, such as field configuration and validation rules), Events (events, such as @submit and @cancel), Slots (slots for custom content), style specifications (CSS class names and theme variables), and create component documentation using Storybook or similar tools. Define a front-end state management solution (such as Vuex / Pinia). Non-functional design: Performance design: Identify performance bottlenecks (such as large data volume queries), design caching strategies (which data Redis caches and its expiration time), design database sharding schemes (such as sharding tables by customer ID), and design asynchronous processing (such as using message queues to handle time-consuming operations). Security design: authentication schemes (JWT, OAuth2.0), authorization schemes (RBAC permission model), data encryption (TLS at the transport layer, encryption of sensitive fields at the storage layer), and attack prevention measures (prevention of SQL injection, XSS, CSRF). Monitoring and logging: Design log format (structured log), design monitoring metrics (interface response time, error rate), and design alarm rules (e.g., alarm when error rate > 5%). Then, a technical review meeting is organized to review the design documents item by item, obtain the final design documents, and manage all the final design documents (data models, API documents, component specifications, etc.) in a versioned manner. A design document repository is established using tools such as Git, a change management process is established, and the final design model is archived as a technical entity design model package.

[0027] The key information that has passed verification will be categorized and organized to form a standardized requirements list, clearly defining the specific description and associated technical requirements of each requirement item: R1, Functional Requirements, Requirement Description: Customer Information Input: Customer Name, Contact Information, Industry, Cooperation Status, etc.; Related Technical Requirements: Design the input form and its connection to the database; R2, Functional Requirements, Requirement Description: Customer classification management, categorized by cooperation status (potential customers, interested customers, converted customers, lost customers) and industry; Related technical requirements: Design classification filtering logic; R3, Functional Requirements, Requirement Description: Sales follow-up records, supporting the input of follow-up person, follow-up time, follow-up content, and follow-up result. Related Technical Requirements: Design a follow-up record form, implement interface for adding, deleting, modifying, and querying records, and link customer information. R4, Functional Requirements, Requirement Description: Data statistical analysis, statistics on customer numbers and sales follow-up conversion rates, Related technical requirements: Design statistical algorithms, implement a visual report interface, and support report export; R5, performance requirements, requirement description: system response time ≤ 3s, support for ≥ 50 concurrent online users, related technical requirements: optimize interface performance, adopt caching mechanism, and configure reasonable server resources; R6, Constraint Requirements, Requirement Description: Data storage complies with enterprise data security specifications; Related Technical Requirements: Enterprise Data Security Specifications. R7, Constraints and Requirements, Requirement Description: Compatible with Windows 10 and above operating systems and Chrome / Edge browsers. Related Technical Requirements: Browser adaptation development to ensure compatibility with different system display formats. Then, a judgment matrix is ​​constructed by combining three dimensions, in which the urgency of user needs accounts for 40%, the business value accounts for 30%, and the development difficulty accounts for 30%. After passing the consistency check, the priority weight of each requirement item is assigned, and a complete list of CRM system requirements and priority weights are generated and synchronized to subsequent modules of the system. A scoring system is used, with a maximum score of 5 and a minimum of 1. The score is determined through joint evaluation by the product manager, business stakeholders, and the technical team. The scores assess the urgency, business value, and development difficulty of all requirements from R1 to R7. For urgency: 5 = Very Urgent, 1 = Not Urgent; for business value: 5 = Extremely High Value, 1 = Low Value; for development difficulty: 5 = Very Difficult, 1 = Very Easy. A judgment matrix is ​​constructed based on the scores, specifically comparing the relative importance of the seven requirements in terms of urgency, forming a 7x7 judgment matrix A. The matrix element calculation rules are as follows: in For the requirement item The rating based on the urgency level. For the requirement item Scoring in the urgency dimension; Then, the eigenvectors of the judgment matrix A are calculated using the sum-product method. Specifically, each column element is divided by its column sum, and then the sum of each row is divided by 7 to obtain the weight vector. Matrix matrices are constructed for the business value dimension and the development difficulty dimension, and weight vectors are calculated respectively. Consistency checks are performed based on urgency, and the largest eigenvalue is calculated. , Calculate the consistency index , Obtain the average random consistency index by looking up the table. For n=7, Calculate the consistency ratio , ,judge If the value is less than 0.1, the weight allocation is considered reasonable. After verification, the weights of the requirement items are calculated based on the three dimensions. The development difficulty is first processed in reverse to obtain... , Then, calculate the comprehensive weight based on the weight of urgency (40%), business value (30%), and development difficulty (30%) to obtain the weight values ​​of R1-R7. If the comprehensive weight is 1, it means that the calculation is correct. Then, sort them from high to low according to the weight values ​​of R1-R7 to obtain the priority order. Component production module: Based on the weight values ​​of R1-R7, requirements with a weight value greater than or equal to 0.15 are classified as core requirements, those with a weight value between 0.08 and 0.14 are classified as secondary requirements, and those with a weight value less than 0.08 are classified as auxiliary requirements. The module then calls the retrieval module of the component template library, which pre-stores component templates for various office systems and management systems. Candidate templates corresponding to each requirement are selected through keyword matching and functional similarity comparison. The similarity filtering process is as follows: Each requirement item and the template matched by keywords are converted into a feature vector through one-hot vector encoding. Then, the one-hot vector encodings of the feature vectors of each requirement item and the template are compared. If they are the same, it is recorded as 1; if they are different, it is recorded as 0. A similarity threshold of 0.7 is set. If the similarity between the template and the requirement item is greater than the threshold, the match is successful. R1 corresponding candidate template: General form entry template; R2 corresponding candidate template: General category query template; R3 corresponding candidate template: General record entry and query template; R4 candidate template: General data visualization template; R5 corresponding candidate template: Interface performance optimization template; R6 corresponding candidate templates: Data encryption and IP whitelist templates; R7 candidate templates: Browser-compatible templates; For each candidate template selected, preliminary configuration is performed based on the specific parameters in the requirements list, including removing redundant modules and adding core modules. General form entry template R1: Remove redundant modules such as "batch import" and "data export" from the template, add "customer information modification and deletion" modules, adjust the form fields to "customer name, contact information, industry, cooperation status" as specified in the requirements, and set the field validation rules to 11-digit mobile phone numbers for contact information; General Category Query Template R2: The core "multi-condition filtering" module is retained, the redundant "batch operation" module is removed, the category conditions are adjusted to "cooperation status, industry", and the "pagination display of category results" function is added; General Record Entry and Query Template R3: Added the "Follow-up Records and Customer Information Association" module, adjusted the entry fields to "Follow-up Person, Follow-up Time, Follow-up Content, Follow-up Result", and set the follow-up time auto-fill function; Other modules: Adjust the template configurations in sequence according to the requirements list. For example, add the "Redis caching" module to the interface performance optimization template, configure the encryption algorithm specified by the enterprise in the data encryption template, and add the Edge browser adaptation module to the browser adaptation template. All the initially configured templates, requirement lists, and priority weights are input into the technical entity design model. The model is then deeply optimized based on component design specifications, interface adaptation standards, and performance optimization rules. The technical entity design model design method is as follows: Business Requirements Analysis: Extract core nouns / noun phrases from natural language requirements to identify business entities. Requirement R1: "The system needs to support customer information entry." Entity identified: Customer. Extract key attributes and constraints from the requirement description. Customer information includes: name, phone number, email, and address. Extracted attributes: name, phone, email, address. Analyze the business relationships between entities. Combined with Requirement R3: Record each sales follow-up, deduce relationships. A customer may have multiple sales follow-up records, determined based on the system type (CRM), team skills, and performance requirements. Frontend uses Vue.js3, TypeScript, and ElementPlus; backend uses SpringBoot (Java) or .NET Core (C#); database: MySQL 8.0; layered architecture design; tool used: PowerDesigner. The `ner` module transforms business entities into specific database table structures (ER diagrams) or domain objects, outputting detailed definitions of entity classes, including data types, lengths, indexes, and foreign keys. It designs CRUD (Create, Read, Update, Delete) interfaces for each core entity, defines the API URL, HTTP methods, and request / response body formats, and outputs API interface documentation. Based on the requirement type (form, list, chart), it defines the technical specifications for front-end components, outputting UI component Props / Events definitions, state management schemes, and style specifications. It transforms performance metrics, security constraints, and compatibility requirements in the requirements into specific technical solutions, caching strategies, encryption algorithms, and browser compatibility lists. All of the above design outputs are compiled into standardized technical design documents, reviewed by the team, and ultimately form a technical entity design model that can guide development.

[0028] The specific optimization process is as follows: Based on the functional parameters, appropriate design patterns are matched for each component. For example, the customer information entry component and the sales follow-up record component adopt the "singleton pattern" to avoid creating duplicate instances. The internal module division of the components is restructured to ensure that the cohesion of a single module is ≥0.8 and the coupling between different modules is ≤0.3. Based on the interaction requirements between components, the communication protocol is selected as HTTP / HTTPS and the data format is JSON; generate the API definitions for each component, such as the API interface for the customer information entry component and the sales follow-up record query interface, to ensure that the interface parameters of each component are consistent and the calls are smooth. For example, the customer classification management component can call the API interface of the customer information entry component to obtain basic customer data. Performance metrics adaptation and optimization: Analyzing performance requirements (response time ≤ 3s, concurrent users ≥ 50) Response time optimization: Simplified SQL query statements are used to reduce the number of database queries; Redis is introduced to cache basic customer information and commonly used category data, with the cache validity period set to 30 minutes; asynchronous processing is used, and the sales follow-up record logs are saved asynchronously without affecting the main process response. Resource consumption optimization: Database connection pool reuse is adopted, with a connection pool size of 20 and a maximum number of connections of 50. Lazy-loaded data statistics and analysis components are loaded only when triggered by the user and not when the system starts. Database connections are released in a timely manner after the resource release interface call is completed, and resources are cached. Concurrency processing optimization: Thread pool is adopted with a core thread count of 10 and a maximum thread count of 30. Lock optimization: Optimistic locking is used for customer information modification to avoid concurrent modification conflicts. Stateless design: Core functional components adopt a stateless design to improve concurrency processing capabilities. Based on the optimized template configuration parameters output by the technical entity design model, the templates are compiled using Java (backend) and Vue.js (frontend) to generate the corresponding development components. The specific components are as follows: Customer information entry component: front-end form + back-end interface + data validation module; Sales follow-up record component: front-end entry form + back-end interface + related query module; Customer classification management component: front-end filtering interface + back-end query interface; Data statistical analysis component: front-end visual report + back-end statistical algorithm; Interface components: Interaction interfaces between components, front-end and back-end interaction interfaces, and database access interfaces; Adaptation components: Performance optimization components: caching module + thread pool configuration; Security constraint components: data encryption module and IP whitelist configuration; Browser / system adaptation components: browser compatibility module + system display adaptation module; All compiled development components are validated, including the following: Component integrity: Check whether the core modules of each component are complete. For example, does the customer information entry component include all "create, delete, modify, and query" modules without any missing modules? Interface compliance: Check whether the parameter format and return format of the API interface conform to the standard, and whether the interface call is smooth and without errors; Requirements matching: Check whether the component functions are consistent with the requirements list. For example, can the performance optimization component meet the requirement of "response time ≤ 3s"? Can the security constraint component achieve "access by specified IP"? When all developed components meet the verification requirements, the development of the components is considered complete. Collaborative Development Management Module: Building the Underlying Framework: The collaborative workspace's underlying framework is built using a distributed architecture, deploying 3 server nodes (1 master node and 2 slave nodes) to achieve load balancing; a MySQL database is configured to store the requirement list, development tasks, and progress data; a Redis cache is configured to cache development components and temporary data; and a WebSocket network communication module is built to achieve real-time message push and data synchronization. Role and permission configuration: Four core roles are preset, and operation permissions are configured based on the principle of least privilege, as follows: Developers: Have permissions to view, edit, and submit development components; can view the requirements list; can receive and complete assigned development tasks; and can submit component iteration versions. Testers: Have access to the requirements list and development components, can enter test results, and can report test defects; Product personnel: have permission to view and review the requirements list, submit suggestions for requirement modification, and confirm whether the development results meet the requirements; Operations and maintenance personnel: have access to monitor the operational status of the collaborative space, can handle server and network anomalies, and can maintain the component template library; Three core modules are deployed within the collaborative space: Requirements and Components Synchronization Module: Synchronizes the generated requirement list and the generated development components to the collaboration space in real time, ensuring that all roles see the same content. Update notifications are pushed in real time after requirements or components are updated. Development task allocation module: used to allocate development tasks and associate the requirements list with development components; Real-time progress recording module: Used to record development progress, generate progress reports, and support viewing by all roles.

[0029] By developing a task allocation module and combining requirement priority weights, requirements and development components are assigned to corresponding developers. The specific allocation scheme is as follows: Developer 1: Assign development and debugging of R1 and R3, with the highest priority; Developer 2: Assign development and debugging tasks to R2 and R7, with lower priority; Developer 3: Assign development and debugging tasks to R5, R6, and R4, prioritizing R5 and R6, and then R4.

[0030] After the task is assigned, the collaborative space automatically pushes task notifications to each developer, specifying the task requirements and completion deadline. The real-time progress recording module records the development progress in real time, and the specific recorded content is as follows: Task completion rate: The task completion status of each developer is updated daily. For example, if developer 1 completes the front-end development of the customer information entry component on the 3rd working day, the task completion rate is 50%. Problem resolution timeliness: Record problems that occur during development, such as component interface call errors, functions not matching requirements, and record the time of submission, resolution time, and personnel responsible for resolution. For example, if developer 3 submits an "IP whitelist configuration error" problem on the 6th working day and the operations and maintenance personnel resolve it within 1 hour, the problem resolution timeliness is 1 hour. Component iteration count: Records the iteration versions of each developed component. For example, the customer information entry component undergoes 1 iteration due to "incomplete field validation rules", and the iteration count is 1.

[0031] Progress data is synchronized to the collaborative space in real time, which can be viewed by product personnel and testers at any time. If the progress is behind schedule, the collaborative space will push reminder notifications to developers and product personnel.

[0032] Dynamic Testing and Optimization Module: This module uses the functional parameters, performance metrics, and constraints in the standardized requirements list as the core basis for testing. Test Case Generation: Based on the hierarchy and dependencies of development components, it generates three types of test cases: unit tests, integration tests, and performance tests, as detailed below: Unit test cases, for a single component: Generate no less than 10 unit test cases for each component to verify the logical function and data processing capability of the single component. For example: unit test cases for the customer information entry component: Enter a valid mobile phone number and verify whether the data can be saved normally; enter an invalid mobile phone number and verify whether a verification prompt can be triggered; delete customer information and verify whether the data in the database can be deleted synchronously.

[0033] Performance optimization component unit test cases: Simulate 10 users simultaneously calling the customer information query interface to verify whether the response time is ≤3s; simulate 50 users online simultaneously to verify whether the system is lag-free.

[0034] Integration test cases are generated for multiple interactive components: 15 integration test cases are generated to verify the interface calls, data transmission, and overall function implementation between components. For example: integration test of the customer classification management component and the customer information entry component: after entering customer information, verify whether the customer classification management component can query the customer information and whether the classification result is accurate; integration test of the sales follow-up record component and the customer information entry component: select a specified customer, enter a follow-up record, verify whether the customer information can be associated and whether the follow-up record can be queried normally.

[0035] Performance test cases are generated for performance metrics: 8 performance test cases are generated, including load testing, stress testing, and concurrency testing. For example: Load test cases: simulate 30, 50, and 60 users online simultaneously, testing system response time, CPU utilization, and memory usage respectively; Stress test cases: simulate 100 users simultaneously calling the customer information query interface for 10 minutes, testing whether the system will crash and whether it can return to normal after the stress is relieved; Concurrency test cases: 50 users simultaneously entering customer information, verifying whether data duplication or loss occurs.

[0036] The development components are tested sequentially in the order of unit testing → integration testing → performance testing. Automated testing tools such as JUnit and JMeter are combined with manual testing methods. The test environment is consistent with the actual deployment environment. Results are recorded: the execution process and results of each test are captured and recorded in real time. Test cases that malfunction are fed back to the collaborative workspace in real time, synchronizing with the relevant developers and testers. This clarifies the location of the failure, the difference between expected and actual results, and allows developers to modify and optimize the components based on the feedback. Developer 1: Modified the validation rules of the customer information entry component, adding a mandatory field validation for "industry"; modified the date validation rules of the sales follow-up record component to prohibit the entry of illegal dates; Developer 3: Optimize the caching strategy of the performance optimization component, increase the cache capacity, adjust the thread pool configuration: change the maximum number of threads to 40, optimize the interface query logic, reduce the number of database queries, and solve the component association query latency problem; Developer 2: Assist in troubleshooting API call issues in the customer classification management component to ensure smooth API calls.

[0037] Test case optimization: Input the test results and component defects into the technical entity design model. The model combines component design specifications, interface adaptation standards and performance optimization rules to generate more targeted test cases. Based on the optimized test cases, re-execute unit tests, integration tests and performance tests until all tests pass.

[0038] The above are merely embodiments of the present invention. The circuits, electronic components, and modules involved are all prior art, fully achievable by those skilled in the art, and require no further explanation. The scope of protection in this application does not involve improvements to the software and methods. Commonly known structures and characteristics in the solutions are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all prior art in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.

Claims

1. A software development method, characterized in that, Includes the following steps: S1: Receive natural language requirements input by the user, extract functional parameters, performance indicators and constraints from the natural language requirements through a semantic understanding model, verify them using technical entity design rules, and generate a list of requirements and requirement priority weights after the verification is qualified. S2: Based on the requirement list and requirement priority weights generated in step S1, call the templates in the component template library, combine them with the technical entity design model, and generate the development components; S3: Build a multi-role collaborative workspace, synchronize the requirement list generated in step S1 and the development components generated in step S2 to the collaborative space, and record the development progress in the collaborative space in real time. S4: Based on the requirements list in step S1, generate unit test, integration test and performance test cases, test the development components in step S3, provide real-time feedback on test results, and optimize test cases in conjunction with the technical entity design model until the test is qualified.

2. The software development method as described in claim 1, characterized in that, In step S1, the training method of the semantic understanding model includes the following steps: S2.1: Construct a training dataset, which includes natural language demand samples and corresponding annotation information. The annotation information includes functional parameter annotations, performance index annotations, and constraint annotations. Clean, deduplicate, and normalize the training dataset, and divide it into a training set, a validation set, and a test set. S2.2: Select a pre-trained language model as the base model. Specifically, the pre-trained language model is the BERT-base model. The bottom parameters of the base model are frozen, while the top parameters are retained for training. A domain adaptation layer and a classification extraction head are added to the top of the base model to obtain the trained model. The domain adaptation layer adopts a fully connected layer structure. The extraction head contains three independent classification branches, which correspond to the classification extraction of functional parameters, performance indicators, and constraints, respectively. S2.3: The training set is used to train the constructed training model, with the cross-entropy loss function as the optimization objective. The model parameters are adjusted in combination with the Adam optimizer. During the training process, the model extraction accuracy is monitored in real time through the validation set. When the validation set accuracy does not improve for a preset number of consecutive rounds, the training is stopped. S2.4: Use the test set to test the performance of the trained model. If the model's extraction accuracy and recall both reach the preset threshold, the model training is considered complete. If the preset threshold is not reached, return to step S2.1 to expand the training dataset or adjust the model structure and retrain until the preset requirements are met.

3. The software development method as described in claim 2, characterized in that, The verification of the technical entity model design rules specifically involves: S3.1: The functional parameters, performance indicators and constraints obtained in step S1 are used as the objects to be verified; S3.2: Call the technical entity design rule set, which includes parameter legality rules, indicator rationality rules and constraint compatibility rules. The parameter legality rules are used to verify whether the format and value of the functional parameters conform to the technical specifications. The indicator rationality rules are used to verify whether the performance indicators are within the reasonable range of industry norms and can be achieved. The constraint compatibility rules are used to verify that there are no conflicts between the various constraints and between the constraints and the functional parameters and performance indicators. S3.3: First, verify all functional parameters one by one through parameter validity rules, then verify performance indicators through indicator rationality rules, and finally verify overall correlation through constraint compatibility rules. During the verification process, mark the verification result of each object to be verified as qualified or unqualified, and mark the violation type for unqualified objects. S3.4: If all objects to be verified pass the verification, proceed to the requirement organization and priority calculation stage. If there are unqualified objects, generate a prompt message containing violation details and send it back to the user. After receiving the user's modification instruction, re-extract the modified objects to be verified and return to step S3.3 for verification again until all are qualified.

4. The software development method as described in claim 3, characterized in that, In step S3.4, the requirement organization and priority calculation process specifically includes: The verified functional parameters, performance indicators, and constraints are categorized and organized to form a requirement list. The specific description and associated technical requirements of each requirement item are clarified. The priority weight of each requirement item is calculated using the analytic hierarchy process. A judgment matrix is ​​constructed by combining the three dimensions of user requirement urgency, development difficulty, and business value. After passing the consistency check, a weight value in the range of 0-1 is assigned to ensure that the sum of the weight values ​​of all requirement items is 1. Finally, the requirement list and the corresponding requirement priority weights are output.

5. The software development method as described in claim 4, characterized in that, In step S2, the generation step of the development component is as follows: S5.1: Extract the functional parameters, performance indicators and constraints from the requirement list generated in step S1. Combine the requirement priority weights to decompose the requirements into layers, distinguish the mandatory functional components corresponding to the core requirements and the optional functional components corresponding to the secondary requirements. Based on the decomposed functional requirements, call the retrieval module of the component template library and filter out the candidate templates corresponding to each functional requirement through keyword matching and functional similarity comparison. S5.2: Perform preliminary configuration on the selected candidate templates. Based on the specific parameters in the requirements list, adjust the basic configuration items of the templates, delete redundant modules that are irrelevant to the requirements, and add core modules that are clearly required by the requirements. S5.3: Input the pre-adapted template and the requirement list and requirement priority weights generated in step S1 into the technical entity design model. The technical entity design model performs in-depth optimization of the template based on component design specifications, interface adaptation standards and performance optimization rules. S5.4: Output the optimized template configuration parameters based on the technical entity design model, compile and generate the corresponding development components, and then verify the development components. The verification content includes component integrity, interface standardization and matching degree with the requirements list. If the preliminary verification fails, return to step S5.3 to re-optimize the template configuration. S5.5: If the verification is successful, the development component is confirmed to be generated. The generated development component is then synchronized to the system cache for subsequent collaborative development.

6. The software development method as described in claim 5, characterized in that, In step S5.3, the depth optimization includes: The technical entity design model matches the applicable design pattern to the development components based on the functional parameters in the requirements list, and reconstructs the division and dependency relationship of the internal modules of the components according to the cohesion coupling degree standard to ensure that the cohesion of a single module is higher than the first preset threshold and the coupling degree between different modules is lower than the second preset threshold. The technical entity design model selects communication protocols and data formats for the development components based on the interaction requirements of the components in the requirements list and other components, and generates or adjusts the corresponding interface application programming interface definitions. The technical entity design model parses the performance indicators in the requirements list, decomposes the abstract indicators into quantitative constraints that can be applied to component design, and calls the corresponding optimization strategy according to the constraint type; including: For response time metrics, employ algorithm optimization, caching, or asynchronous processing strategies. For resource consumption metrics, connection pool reuse, lazy loading, or resource release strategies are employed. For concurrency metrics, thread pool configuration, lock optimization, or stateless design strategies can be adopted.

7. The software development method as described in claim 6, characterized in that, In step S5.4, the development components include core functional components, auxiliary functional components, and interface components.

8. The software development method as described in claim 7, characterized in that, In step S3, the specific method for building a multi-role collaborative workspace is as follows: S8.1: The underlying framework of the collaborative workspace is built using a distributed architecture, including server node deployment, data storage module configuration, and network communication module setup; S8.2: Presets four core roles: developers, testers, product personnel, and operations personnel. Configures the operation permissions of each role based on the principle of least privilege. Developers have the permission to view, edit, and submit development components; testers have the permission to view the requirement list, development components, and enter test results; product personnel have the permission to view, review, and submit modification suggestions for the requirement list; and operations personnel have the permission to monitor the operation status of the collaborative space and handle anomalies. S8.3: Deploy the requirement and component synchronization module, development task allocation module, and real-time progress recording module within the collaborative space; S8.4: Through the development task allocation module, the requirement items in the requirement list of step S1 and the development components generated in step S2 are allocated to the developers of the corresponding roles, taking into account the requirement priority weights. S8.5: The development progress is recorded in real time through the real-time progress recording module. The development progress includes task completion rate, problem resolution timeliness and component iteration number.

9. A software development method as described in claim 8, characterized in that, The methods for testing the development components in step S4 include: S9.1: Based on the requirements list generated in step S1, extract the functional parameters, performance indicators and constraints as the basis for testing; S9.2: Based on the hierarchy and dependencies of the core functional components, auxiliary functional components, and interface components generated in step S2, generate test cases, which include: S9.2.1: For a single core functional component or auxiliary functional component, generate unit test cases to verify its logical functions and data processing capabilities; S9.2.2: For multiple components that interact with each other, generate integration test cases to verify the interface calls, data transfer, and overall functional implementation between the components; S9.2.3: Generate load test, stress test, and concurrency test cases for the performance metrics in the requirements list to verify the performance metrics compliance. S9.3: Based on the test cases generated in step S9.2, perform tests on the development components in the predetermined order of unit testing, integration testing, and performance testing; S9.4: Capture and record the execution process and results of each test in real time, including test pass, test failure and test error. For test cases that fail, record the failure location and the difference between the expected result and the actual result. For test cases that have errors, record the error exception information. S9.5: Feed back the test results recorded in step S9.4 to the collaborative workspace in real time and synchronize them with the corresponding developers and testers; S9.6: Input the test results and component defects exposed during the test into the technical entity design model. The technical entity design model optimizes and generates more targeted test cases through component design specifications, interface adaptation standards and performance optimization rules. S9.7: Based on the optimized test cases, return to step S9.3 and re-perform the tests until all levels of test cases pass.

10. A software development system, characterized in that, include: The requirement processing module is used to receive natural language requirements input by users, extract functional parameters, performance indicators and constraints from the natural language requirements through a semantic understanding model, verify them using technical entity design rules, and generate a requirement list and requirement priority weights after the verification is qualified. Component generation module: Based on the requirement list and requirement priority weights generated in step S1, it calls the corresponding templates in the component template library, combines them with the technical entity design model, and generates development components. Collaborative Development Management Module: Used to build a multi-role collaborative workspace, synchronize the requirement list generated in step S1 and the development components generated in step S2 to the collaborative space, and record the development progress in the collaborative space in real time. Dynamic testing and optimization module: Based on the requirements list in step S1, it generates unit test, integration test and performance test cases, tests the development components in step S3, provides real-time feedback on test results, and optimizes test cases in conjunction with the technical entity design model until the test is qualified.

Images