A software development life cycle whole-process automatic management method

Abstract

The present application relates to the field of software engineering and artificial intelligence, and particularly relates to a software development life cycle full-process automatic management system, which comprises a requirement analysis and architecture design module, a development and test integration module, a deployment and running monitoring module and a visual management module; in the requirement stage, the present application carries out semantic analysis on natural language requirements to generate structured documents, intelligently matches historical architecture modes and establishes a bidirectional traceability relationship; in the development and test stage, the present application automatically generates code framework and test cases, executes incremental code review based on a defect prediction model, and automatically completes log cleaning, fault positioning, root cause analysis and defect work order closed loop when the test fails; in the deployment and operation stage, the present application intelligently generates a gray release strategy, constructs a digital twin operation model, and realizes multi-dimensional traceability and rapid disposal for operation exceptions; the present application breaks through the full-process data barriers by a unified digital main line data layer, and significantly improves the software development and delivery efficiency and system operation stability.

Description

Technical Field

[0001] This invention relates to the fields of software engineering and artificial intelligence, and in particular to a method for automating the entire software development lifecycle. Background Technology

[0002] As digital transformation deepens, software systems continue to expand in scale and business complexity increases. Traditional software development lifecycle management generally suffers from problems such as fragmented processes, low automation, missing traceability links, and delayed fault handling, making it difficult to meet the R&D delivery and stable operation requirements in high-concurrency, high-availability, and high-compliance scenarios.

[0003] During the requirements and architecture phase, user requirements are often submitted in a fragmented manner in natural language, relying on manual parsing and sorting. This can easily lead to problems such as ambiguity in requirements, logical conflicts, and lack of compliance. Architecture design relies too much on the experience of designers, making it difficult to efficiently reuse historical mature architecture assets. This results in repetitive design, inconsistent architecture, and a lack of two-way traceability between requirements and architecture, which can easily cause a chain of deviations when changes are made later.

[0004] During the development and testing phases, code framework setup, test case writing, and code review are highly dependent on manual processes, which are inefficient and prone to human error. Traditional static testing cannot accurately identify industry-specific defects, and hidden defects can easily flow into the testing phase. After a test fails, log analysis, fault location, root cause determination, and defect ticket creation all require manual intervention, resulting in long investigation cycles, high reproduction and repair costs, and difficulty in forming an automated closed loop.

[0005] During the deployment and operation phase, release strategies rely on manual configuration, and the standardization of canary and rolling deployments is insufficient. Operation monitoring mainly displays isolated indicators and lacks linkage with R&D process data. When performance fluctuations or business anomalies occur, it is impossible to quickly link code changes, version deployments, and the source of requirement design. Fault handling relies on experience-based judgment, resulting in slow root cause location and long recovery time. Furthermore, abnormal events are not bound to the entire process assets, making it difficult to form accumulative and reusable governance experience.

[0006] Furthermore, the data throughout the entire R&D process is scattered across independent systems such as requirements management, code repositories, testing platforms, and operations and maintenance monitoring. This results in severe data silos and a lack of a unified view, making project progress invisible, quality uncontrollable, and risks unpredictable. The requirements of highly compliant industries for full-chain traceability and auditing of requirements, design, development, testing, deployment, and operations and maintenance are also difficult to meet effectively through traditional models.

[0007] In summary, traditional software development lifecycle management methods suffer from shortcomings such as non-standard requirement transformation, low architecture reuse rate, insufficient automation in R&D and testing, difficulty in fault tracing, and lack of data flow throughout the entire process. There is an urgent need for a management method that covers the entire process, is traceable, automated, and intelligent, in order to improve delivery efficiency, reduce defect rate, ensure stable system operation, and meet high compliance requirements. Summary of the Invention

[0008] The purpose of this invention is to overcome the above-mentioned technical defects and to provide a high-quality, full-process, automated, and traceable software development lifecycle automated management method and system.

[0009] The objective of this invention can be achieved through the following technical solution: an automated management system for the entire software development lifecycle, comprising a requirements analysis and architecture design module, a development and testing integration module, a deployment and operation monitoring module, and a visual management module; Requirements Analysis and Architecture Design Module: Collects users' natural language requirements text, generates structured requirements specification documents through semantic parsing, outputs initial architecture solutions based on vector retrieval and matching of historical architecture patterns, performs automated technology verification for completeness, consistency, and compliance, establishes a two-way traceability link between requirements and architecture, and writes it into a unified digital master data layer. The unified digital mainline data layer is a hierarchical structured data storage model, which uses database foreign key association indexes to achieve full-link data binding. The data structure includes: {mainline ID, requirement item, architecture component, code asset, test asset, deployment and operation}; Development and testing integration module: Based on the unified digital mainline data layer, it generates code frameworks and test cases, performs incremental code review and CI building through defect prediction model, and automatically completes log cleaning, fault service layer-level-code three-level localization, root cause reasoning analysis and defect ticket creation through log parsing when tests fail, forming an automated repair-regression testing technology closed loop; Deployment and Operation Monitoring Module: Based on the deployment topology and service dependencies, it intelligently generates canary release technology strategies, constructs a digital twin operation model that is mapped to the physical system in real time, performs multi-dimensional technical tracing of operation anomalies from code execution to deployment to requirements, and binds abnormal events to a unified digital mainline data layer to form observable data across the entire technology chain.

[0010] Preferably, the bidirectional traceability and correlation analysis of requirements and architecture includes: Collect user's natural language input requirement text, call the preset requirement analysis model to perform semantic parsing on the requirement text, automatically identify non-functional constraints, and output standardized and structured requirement specification documents; For the output requirement specification document, search the historical project knowledge base to match similar architecture patterns, and based on the semantic similarity of the current requirement, set the architecture pattern corresponding to the maximum semantic similarity of the current requirement among the matching similar architecture patterns as the main architecture pattern, and automatically output the initial architecture design scheme of the main architecture pattern. Perform validation on the requirements specification document, automatically identify ambiguities, missing content, and logical conflicts in the requirements, generate a requirements clarification list, and trigger a human-computer interaction confirmation process; After all the requirements specification documents have been verified and confirmed to be correct, the architecture solution is transformed into a standardized design deliverable, written into the unified digital master data layer, and a one-to-one correspondence between requirement items and architecture design components is established for bidirectional traceability.

[0011] Preferably, the unified digital mainline data layer adopts a hierarchical structured data model: {mainline ID, requirement item (including requirement ID, requirement text), architecture component (including architecture ID, pattern type), code asset (including commit ID, file path), test asset (including test case ID, associated code ID), deployment and operation (including defect ID, exception type)}; Each requirement ID is assigned a unique identifier. After the architecture pattern is matched, a foreign key association index of requirement ID-architecture ID-component ID is automatically established. When the code framework is generated, the associated requirement ID and architecture ID identifier are automatically written in the code comments. When the code is submitted, the CI pipeline automatically extracts and writes it into the digital master line, forming a full-link binding of requirement-architecture-code.

[0012] Preferably, the defect work order generation and analysis process is as follows: The system reads the initial architecture design scheme from the unified digital mainline data layer, obtains test cases, adopts a preset defect prediction model, monitors code repository commit change events in real time, automatically triggers incremental static code review, detects hidden defects, and writes the review results back to the visual management module in real time. After the code review and verification are passed, the CI automated build pipeline is automatically triggered, and the software deliverable package is automatically uploaded to the artifact repository. Once the software deliverable package is successfully built, multiple tests are automatically completed. If a test fails, the logs are automatically parsed to locate the root cause of the failure and a defect ticket with the associated code submission record is generated.

[0013] Preferably, when the test fails: S1: When a test fails, automatically capture the log information returned by the test engine and build an exception information database; S2: Call the built-in preset fault feature knowledge base, perform feature matching on the cleaned abnormal information database, and output the matched abnormal type; S3: Based on the determined exception type and combined with the call chain log, accurately locate the erroneous code; S4: Call the traceability relationship in the unified digital mainline data layer to associate the located error code with the code submission record corresponding to this test to pinpoint the cause of the failure; S5: Retrieve the historical defect database and root cause analysis records stored in the unified digital mainline data layer. According to the set combination conditions, retrieve historical similar cases, prioritize the screening of cases with a matching degree ≥ the preset matching degree threshold, extract their root cause conclusions and repair solutions, compare the root causes of historical cases with the analysis results of the current code change and error code, and output the root cause conclusions that can be directly reused or the root causes that are corrected. S6: Based on the analysis results, perform root cause reasoning according to the hierarchical reasoning engine to identify the direct triggering factors and root causes of test failure. Combine the direct causes, root causes, and remediation solutions for similar historical cases to generate specific and actionable remediation suggestions. S7: Based on the root cause analysis results, automatically create standardized defect work orders and bind the defect work orders to relevant data assets in the unified digital master data layer; S8: After completing the code modification and submitting it to the code repository based on the repair suggestions in the defect work order, the closed-loop process is automatically triggered.

[0014] Preferably, the specific steps for generating the error code are as follows: Service layer location: Based on the call chain logs, determine the microservice module corresponding to the test failure; Hierarchical location: Tracing back from the top of the call chain to the bottom layer to pinpoint the level at which the exception occurred; Code location: By combining the error line number, class name, and method name in the exception stack log, the specific class file, function method, and line of code that caused the error can be accurately located, and then the line of code is marked as the error code.

[0015] Preferably, the process for generating the end-to-end observable data is as follows: Retrieve the accepted software deliverables from the product warehouse, and intelligently generate a hierarchical gray-scale release strategy based on the deployment topology and service dependencies recorded in the unified digital master data layer. Complete the rolling deployment of online services in batches in an orderly manner. During the entire deployment process and the long-term operation cycle of the service, construct a full-element digital twin operation model that is mapped in real time to the physical operation system. When abnormal operating conditions occur, the multi-dimensional associated fault tracing process is automatically initiated, and standardized abnormal alarms and feasible handling and repair solutions are output. All online anomalies, handling processes, and rectification results are bound and associated with the corresponding requirement nodes, program code components, and software versions within the unified digital master data layer, forming end-to-end observable data for the entire software chain from requirement initiation, R&D construction to online operation and fault management.

[0016] The beneficial effects of this invention are as follows: (1) This invention realizes the fully automatic structured transformation of natural language requirements, reduces the ambiguity and deviation of requirements, greatly reduces the repeated clarification and rework of requirements, shortens the project initiation cycle, and reuses mature architecture assets based on vector retrieval, avoids repeated design, improves the rationality and standardization of the architecture, reduces the risk of later system iterations, and at the same time, the whole process of incremental automated code quality inspection, construction, deployment and testing closed loop reduces human operation errors and significantly reduces the probability of defect escape and online failure.

[0017] (2) The present invention also unifies the digital mainline data layer to break down data barriers in the entire R&D stage, effectively reducing requirement ambiguity, improving architecture reusability, and the reverse tracing link of abnormal events is clear, which greatly shortens the troubleshooting and recovery time, while reducing manual operation and defect escape, significantly improving software development and delivery efficiency and system operation stability, and adapting to high compliance level R&D scenarios. Attached Figure Description

[0018] The invention will now be further described with reference to the accompanying drawings; Figure 1 This is a flowchart of the system of the present invention; Figure 2 This is a reference diagram for partial analysis of defect work orders in this invention; Figure 3 This is a reference analysis diagram of the method of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments; Example 1: Please refer to Figure 1-3As shown, the present invention is an automated management system for the entire software development lifecycle, including a requirements analysis and architecture design module, a development and testing integration module, a deployment and operation monitoring module, and a visual management module. The requirements analysis and architecture design module is connected to the development and testing integration module, the development and testing integration module is connected to the deployment and operation monitoring module, and the deployment and operation monitoring module is connected to the visual management module. Requirements Analysis and Architecture Design Module: Collects users' natural language requirements text, generates structured requirements specification documents through semantic parsing, outputs initial architecture solutions based on vector retrieval and matching of historical architecture patterns, performs automated technology verification for completeness, consistency, and compliance, establishes a two-way traceability link between requirements and architecture, and writes it into a unified digital master data layer. The unified digital mainline data layer is a hierarchical structured data storage model. It uses database foreign key association indexes to achieve full-link data binding. The data structure includes: {mainline ID, requirement item, architecture component, code asset, test asset, deployment and operation}. Development and testing integration module: Based on the unified digital mainline data layer, it generates code frameworks and test cases, performs incremental code review and CI building through defect prediction model, and automatically completes log cleaning, fault service layer-level-code three-level localization, root cause reasoning analysis and defect ticket creation through log parsing when tests fail, forming an automated repair-regression testing technology closed loop; Deployment and Operation Monitoring Module: Based on the deployment topology and service dependencies, it intelligently generates canary release technology strategies, constructs a digital twin operation model that is mapped to the physical system in real time, performs multi-dimensional technical tracing of abnormal operation execution code-deployment-requirements, and binds abnormal events to the unified digital mainline data word data layer to form observable data of the entire technology chain; The analysis process of establishing a two-way traceability link between requirements and architecture and writing it into the unified digital master data layer is as follows: Collect user's natural language input requirement text, call the preset requirement analysis model to perform semantic parsing on the requirement text, automatically identify non-functional constraints such as business function entities, business execution rules, performance and security compatibility, and output standardized and structured requirement specification documents; For the output requirement specification document, search the historical project knowledge base to match similar architecture patterns, and based on the semantic similarity of the current requirement, set the architecture pattern corresponding to the maximum semantic similarity of the current requirement among the matching similar architecture patterns as the main architecture pattern, and automatically output the initial architecture design scheme of the main architecture pattern. Perform integrity checks, logical consistency checks, and industry compliance checks on the requirements specification documents; automatically identify requirements ambiguities, missing content, and logical conflicts; generate a requirements clarification list; and trigger a human-computer interaction confirmation process. After all the verifications of the requirements specification document have been reviewed and confirmed to be correct, the initial architecture design scheme (after being transformed into standardized design deliverables) is written into the unified digital mainline data layer, establishing a one-to-one correspondence between requirement items and architecture design components, and the unified digital mainline data layer is output to the visual management module for display, so as to intuitively understand the architecture of the initial architecture design scheme. The unified digital mainline data layer adopts a hierarchical structured data model: {Mainline ID, Requirement Items (including Requirement ID, Requirement Text, etc.), Architecture Components (including Architecture ID, Pattern Type, etc.), Code Assets (including Commit ID, File Path, etc.), Test Assets (including Test Case ID, Associated Code ID, etc.), Deployment and Execution (including Defect ID, Exception Type, etc.)}; Each requirement ID is assigned a unique identifier. After the architecture pattern is matched, a foreign key association index of requirement ID-architecture ID-component ID is automatically established. When the code framework is generated, the associated requirement ID and architecture ID identifier are automatically written in the code comments. When the code is submitted, the CI pipeline automatically extracts and writes it into the unified digital master data layer, forming a full-link binding of requirement-architecture-code, which realizes two-way traceability.

[0021] Example 2: Development and Testing Integration Module: Based on the unified digital master data layer, it generates code frameworks and test cases. Incremental code review and CI building are performed through a defect prediction model. When tests fail, log cleaning, fault service layer-level-code three-level localization, root cause analysis, and automatic defect ticket creation are automatically completed through log parsing, forming an automated repair-regression testing technology closed loop, specifically including: Read the initial architecture design scheme from the unified digital mainline data layer, and automatically generate business module code engineering framework and standardized unit test cases; The test case generation rules are as follows: extract normal flow, abnormal flow, and boundary conditions from the functional requirements fields; extract input parameters, output parameters, and error codes from the architecture interface definition. Highly similar test cases are reused from the historical test case library through vector matching; the test case structure includes test case ID, associated code ID, test type, input parameters, expected output, preconditions, and postconditions, automatically meeting the coverage requirements of statement coverage (e.g., 100%), branch coverage ≥ preset threshold, and boundary coverage, and automatically generating standardized unit test cases. Employing a pre-defined defect prediction model, the system monitors code repository commit change events in real time, automatically triggering incremental static code reviews to detect hidden defects such as coding standard compliance, completeness of exception handling, null pointer exceptions, and resource memory leaks. The review results are written back to the visual management module in real time. Among them, the preset defect prediction model uses code abstract syntax tree features and historical defect change and repair patterns as training samples for supervised fine-tuning to accurately identify high-frequency specific defects in the industry and improve the accuracy of static detection. After the code review and verification are passed, the CI automated build pipeline is automatically triggered, which sequentially completes code retrieval, compilation, dependency security scanning, unit testing, packaging and container image building. The built software package is automatically uploaded to the artifact repository, and the build log and review results are synchronously written back to the unified digital mainline data layer, forming an automated closed loop of development-review-build. Once the software deliverable package is successfully built, it is automatically deployed to a dedicated testing environment to perform batch unit tests and interface contract consistency tests. When a test fails, the logs are automatically parsed to locate the root cause of the failure and a defect ticket with the associated code submission record is generated. The analysis process for defective work orders is as follows: S1: When a test fails (meaning any test case fails to execute), automatically capture log information such as the exception stack trace returned by the test engine, the interface return message, and the database execution log. Automatically filter out invalid and redundant information and duplicate error log information. Filter out invalid and redundant information such as timestamps, irrelevant links, and duplicate stack traces according to preset log cleaning rules. Retain exception information such as exception code, exception type, error stack frame, and error code line number. At the same time, convert unstructured text logs into structured key-value data to form an exception information database. S2: Call the built-in preset fault feature knowledge base (containing feature tags and matching rules for various common test failure exceptions), perform feature matching on the cleaned exception information base, and output the matched exception type. The exception types include: code logic exception, interface contract exception, environment dependency exception, etc. S3: Based on the determined exception type and combined with the call chain log, accurately locate the error code. The specific steps are as follows: Service layer location: Based on the call chain logs, determine the microservice module (such as user service, order service) corresponding to the test failure. Layer-by-layer location: trace back from the top layer of the call chain (frontend request) to the bottom layer (database / downstream service) to pinpoint the layer where the exception occurred (such as business logic layer, data access layer). Code location: By combining the error line number, class name, and method name in the exception stack log, the specific class file, function method, and line of code that caused the error can be accurately located. The line of code is then marked as the error code, and the error code and related code fragments are extracted as the core basis for subsequent root cause analysis. S4: Invoke the traceability relationship maintained in the unified digital mainline data layer, associate the located error code with the code commit record corresponding to this test, and pinpoint the cause of the failure. The specific tracing order is as follows: By associating the class file and line of code of the erroneous code with the corresponding code commit ID (i.e., the commit record of modifying / adding this code in this iteration); Extract the change patches from the error code commit records, compare the code differences before and after the change, and analyze whether the test failure was caused by this code modification (such as adding logic, modifying conditions, or adjusting interface parameters). Further link the corresponding requirement item ID and architecture design component ID of the error code submission to confirm whether the error code change meets the requirements and architecture design specifications, and investigate whether the failure was caused by a misunderstanding of the requirements or an error in the implementation of the architecture design. If there are multiple code commits with errors, compare them one by one in the order of the commit time to pinpoint the cause of the failure. S5: Retrieve the historical defect database and root cause analysis records stored in the unified digital mainline data layer. Search for similar historical cases based on the combination of exception type, error stack, error module, and code change mode. Prioritize cases with a matching degree ≥ the preset matching degree threshold and extract their root cause conclusions and repair solutions. Compare the root causes of historical cases with the analysis results of the current code change and error code. If they match, the root cause conclusions are directly reused. If there are differences, the root cause is corrected based on the analysis results to avoid duplicate analysis. S6: Based on the analysis results, perform root cause reasoning according to the hierarchical reasoning engine: Location layer (stack line number - class / method / code line) - Change layer (code line - most recent commit - change difference) - Association layer (commit - requirement / architecture - deviation check) - Case layer (exception + code pattern - historical defect matching) - Conclusion layer (full match is directly reused, partial match is merged for reasoning, no match is reasoned in the order of code - logic - configuration - dependency); Identify the direct triggers that cause test failures (such as null pointer exceptions in a line of code, incorrect interface parameter types, or database connection timeouts), and conduct in-depth analysis of the underlying causes (such as imprecise code logic, inconsistent interface contract definitions, outdated environment configurations, or incomplete consideration of business rules). Based on the direct causes, root causes, and remediation solutions for similar historical cases, specific and actionable remediation recommendations are generated, including: code modification points, modification methods, parameter adjustment rules, interface field correction solutions, dependency version adaptation recommendations, and strategies for supplementing boundary test cases. S7: Based on the root cause analysis results, automatically create standardized defect work orders. Defect work orders include: exception type, error code, root cause analysis results, and repair suggestions. Bind defect work orders to relevant data assets in the unified digital mainline data layer, including code commit ID, requirement item ID, architecture design component ID, etc. The complete process of this root cause analysis and defect work order information will be synchronously written back to the unified digital mainline data layer; S8: After completing the code modifications based on the repair suggestions in the defect ticket and submitting them to the code repository, the following closed-loop process is automatically triggered: Identify the code (error code), submit the corresponding defect work order, and mark the work order status as pending regression testing; Re-execute the failed test cases and related test cases to verify the effectiveness of the code fix; If the regression test passes, the defect work order status will be automatically updated to "fixed", and the defect status and code submission status in the unified digital mainline data layer will be updated synchronously. If the regression test still fails, return to S1 and re-execute the root cause analysis process until the defect is fixed and verified.

[0022] Example 3: Deployment and Operation Monitoring Module: Based on the deployment topology, an intelligent gray-scale release strategy is generated, a digital twin operation model is constructed, multi-dimensional fault tracing is performed for operational anomalies, and abnormal events are bound to the unified digital mainline data layer to form end-to-end observable data, specifically including: Retrieve the accepted software deliverables from the product warehouse, and based on the system deployment topology and service dependencies recorded in the unified digital master data layer, intelligently generate a graded gray release strategy according to service level, traffic ratio, and risk level (low / medium / high risk), and complete the rolling deployment of online services in batches in an orderly manner; Service levels: Core transactions / payments / user center are level 1, queries / statistics are level 2, and backend tasks are level 3; The tiered canary release strategy includes a complete release ticket with batches, proportions, rules, monitoring, rollback, and execution order. In other words, the tiered canary release strategy is a risk-controlled, gradual release mechanism: it automatically classifies the release risk level based on service level, scope of change, and historical risks, and follows a tiered process of low-proportion trial, gradual rollout, and full release to guide online traffic to the new version in batches. Each rollout level has an observation window and anomaly threshold. In case of anomalies, it automatically pauses or rolls back to avoid the new version failure affecting all users, ensuring a smooth, traceable, and quick loss mitigation process. Throughout the entire deployment process and the long-term operation cycle of the service, we continuously collect interface call performance indicators, business anomaly alarm logs, server computing power and resource usage data to build a full-element digital twin operation model that is mapped in real time to the physical operating system. When the system experiences abnormal operating conditions such as excessive response latency, abnormally high business error rate, or abnormal fluctuations in resource load, a multi-dimensional associated fault tracing process is automatically initiated: linking and comparing historical code change records, version deployment events, and full-link operation logs to quickly locate the program version and configuration parameter change causes corresponding to the anomaly, and outputting standardized anomaly alarms and implementable handling and repair solutions. All online anomalies, handling processes, and rectification results are bound and associated with the corresponding requirement nodes, program code components, and software versions within the unified digital mainline data layer, forming end-to-end observable data for the entire software chain from requirement initiation, R&D construction to online operation and fault management. A method for automating the entire software development lifecycle includes the following steps: Requirements analysis and architecture design phase: Collect users' natural language requirements text, generate structured requirements specification documents through semantic parsing, match historical architecture patterns to output initial architecture solutions, complete requirements verification and clarification, establish a two-way traceability link between requirements and architecture and write it into the unified digital master data layer. Development and test integration phase: Based on the unified digital mainline data layer, code framework and test cases are generated, incremental code review and CI building are performed, and when test failure occurs, log cleaning, fault hierarchical location, root cause analysis and defect ticket generation are automatically completed to form a repair-regression closed loop. Deployment and operation monitoring phase: Based on the deployment topology, intelligently generate a canary release strategy, build a digital twin operation model, perform multi-dimensional fault tracing for operational anomalies, and bind abnormal events to the unified digital mainline data layer to form full-link observability; In summary, this approach achieves fully automated structured conversion of natural language requirements, reducing ambiguity and deviations in requirements, significantly minimizing repeated clarification and rework, shortening project initiation cycles, and reusing mature architectural assets based on vector retrieval to avoid redundant design, improve architectural rationality and standardization, and reduce the risk of later system iterations. Furthermore, the fully automated incremental code quality inspection, building, deployment, and testing loop reduces human error, significantly lowering the probability of defect escape and online failures. A unified digital thread breaks down data barriers across all stages of development, effectively reducing requirement ambiguity and improving architectural reusability. The clear reverse tracing of abnormal events significantly shortens troubleshooting and recovery time, while also reducing manual operations and defect escape, significantly improving software development and delivery efficiency and system stability, making it suitable for high-compliance-level development scenarios.

[0023] The threshold is set for result comparison and analysis to determine whether it is good or bad. The value of the threshold is determined by a combination of large-scale model analysis of the sample data and human experience, and can also be adjusted appropriately based on seasonal or common-sense influencing factors. The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A software development life cycle full-process automatic management system, characterized in that, It includes modules for requirements analysis and architecture design, development and testing integration, deployment and operation monitoring, and visual management. Requirements Analysis and Architecture Design Module: Collects users' natural language requirements text, generates structured requirements specification documents through semantic parsing, outputs initial architecture solutions based on vector retrieval and matching of historical architecture patterns, performs automated technology verification for completeness, consistency, and compliance, establishes a two-way traceability link between requirements and architecture, and writes it into a unified digital master data layer. The unified digital mainline data layer is a hierarchical structured data storage model, which uses database foreign key association indexes to achieve full-link data binding. The unified digital mainline data layer adopts a hierarchical structured data storage model: mainline ID, requirement items include requirement ID and requirement text, architecture components include architecture ID and pattern type, code assets include commit ID and file path, test assets include test case ID and associated code ID, and deployment and operation include defect ID and exception type. Each requirement ID is assigned a unique identifier. After the architecture pattern is matched, a foreign key association index of requirement ID-architecture ID-component ID is automatically established. When the code framework is generated, the associated requirement ID and architecture ID identifier are automatically written in the code comments. When the code is submitted, the CI pipeline automatically extracts and writes it into the digital master line, forming a full-link binding of requirement-architecture-code. Development and testing integration module: Based on the unified digital mainline data layer, it generates code frameworks and test cases, performs incremental code review and CI building through defect prediction model, and automatically completes log cleaning, fault service layer-level-code three-level localization, root cause reasoning analysis and defect ticket creation through log parsing when tests fail, forming an automated repair-regression testing technology closed loop; Deployment and Operation Monitoring Module: Based on the deployment topology and service dependencies, it intelligently generates canary release technology strategies, constructs a digital twin operation model that is mapped to the physical system in real time, performs multi-dimensional technical tracing of abnormal operation execution code, deployment, and requirements, and binds abnormal events to a unified digital mainline data layer to form observable data across the entire technology chain; The defect work order generation and analysis process is as follows: The system reads the initial architecture design scheme from the unified digital mainline data layer, obtains test cases, adopts a preset defect prediction model, monitors code repository commit change events in real time, automatically triggers incremental static code review, detects hidden defects, and writes the review results back to the visual management module in real time. After the code review and verification are passed, the CI automated build pipeline is automatically triggered, and the software deliverable package is automatically uploaded to the artifact repository. Once the software deliverable package is successfully built, multiple tests are automatically completed. If a test fails, the logs are automatically parsed to locate the root cause of the failure and a defect ticket with the associated code submission record is generated.

2. The software development lifecycle automated management system according to claim 1, characterized in that, The bidirectional traceability analysis of requirements and architecture includes: Collect user's natural language input requirement text, call the preset requirement analysis model to perform semantic parsing on the requirement text, automatically identify non-functional constraints, and output standardized and structured requirement specification documents; For the output requirement specification document, search the historical project knowledge base to match similar architecture patterns, and based on the semantic similarity of the current requirement, set the architecture pattern corresponding to the maximum semantic similarity of the current requirement among the matching similar architecture patterns as the main architecture pattern, and automatically output the initial architecture design scheme of the main architecture pattern. Perform validation on the requirements specification document, automatically identify ambiguities, missing content, and logical conflicts in the requirements, generate a requirements clarification list, and trigger a human-computer interaction confirmation process; After all the requirements specification documents have been verified and confirmed to be correct, the architecture solution is transformed into a standardized design deliverable, written into the unified digital master data layer, and a one-to-one correspondence between requirement items and architecture design components is established for bidirectional traceability.

3. The software development lifecycle automated management system according to claim 1, characterized in that, When the test fails: S1: When a test fails, automatically capture the log information returned by the test engine and build an exception information database; S2: Call the built-in preset fault feature knowledge base, perform feature matching on the cleaned abnormal information database, and output the matched abnormal type; S3: Based on the determined exception type and combined with the call chain log, accurately locate the erroneous code; S4: Call the traceability relationship in the unified digital mainline data layer to associate the located error code with the code submission record corresponding to this test to pinpoint the cause of the failure; S5: Retrieve the historical defect database and root cause analysis records stored in the unified digital mainline data layer. According to the set combination conditions, retrieve historical similar cases, prioritize the screening of cases with a matching degree ≥ the preset matching degree threshold, extract their root cause conclusions and repair solutions, compare the root causes of historical cases with the analysis results of the current code change and error code, and output the root cause conclusions that can be directly reused or the root causes that are corrected. S6: Based on the analysis results, perform root cause reasoning according to the hierarchical reasoning engine to identify the direct triggering factors and root causes of test failure. Combine the direct causes, root causes, and remediation solutions for similar historical cases to generate specific and actionable remediation suggestions. S7: Based on the root cause analysis results, automatically create standardized defect work orders and bind the defect work orders to relevant data assets in the unified digital master data layer; S8: After completing the code modification and submitting it to the code repository based on the repair suggestions in the defect work order, the closed-loop process is automatically triggered.

4. The software development lifecycle automated management system according to claim 3, characterized in that, The specific steps for obtaining the error code are as follows: Service layer location: Based on the call chain logs, determine the microservice module corresponding to the test failure; Hierarchical location: Tracing back from the top of the call chain to the bottom layer to pinpoint the level at which the exception occurred; Code location: By combining the error line number, class name, and method name in the exception stack log, the specific class file, function method, and line of code that caused the error can be accurately located, and then the line of code is marked as the error code.

5. The software development lifecycle automated management system according to claim 1, characterized in that, The process of generating observable data using the end-to-end technology is as follows: Retrieve the accepted software deliverables from the product warehouse, and intelligently generate a hierarchical gray-scale release strategy based on the deployment topology and service dependencies recorded in the unified digital master data layer. Complete the rolling deployment of online services in batches in an orderly manner. During the entire deployment process and the long-term operation cycle of the service, construct a full-element digital twin operation model that is mapped in real time to the physical operation system. When abnormal operating conditions occur, the multi-dimensional associated fault tracing process is automatically initiated, and standardized abnormal alarms and feasible handling and repair solutions are output. All online abnormal events, handling processes, and rectification results are bound and associated with the corresponding requirement nodes, program code components, and software versions in the unified digital mainline data layer, forming end-to-end observable data for the entire software chain from requirement initiation, R&D construction to online operation and fault management.

Images