Software item quality self-adaptive management method

Abstract

This invention provides an adaptive quality management method for software projects, relating to the field of software quality management technology. The method includes the following steps: S100, Quality Knowledge Graph Push: Automatically triggering the push of a quality knowledge graph at preset project nodes in the software project workflow; S200, Quality Test Execution: Calculating and analyzing collected project process metrics to obtain and visualize project status and quality conditions; S300, Quality Assurance Pipeline Operation: Performing quality assessments based on a project quality-related knowledge base on the execution results of quality assurance activities and the test results of quality test execution, and executing project closure or rectification steps according to the quality assessment results. Based on this, this invention solves the problems of high reliance on manual processes, lack of automated linkage mechanisms, and difficulty in global management in existing software quality management methods.

Description

Technical Field

[0001] This invention relates to the field of software quality management technology, specifically to an adaptive management method for software project quality. Background Technology

[0002] In the software industry, quality management is a crucial means to achieve continuous improvement in software quality. Systematic management and standardized definition of the software implementation process, combined with quantitative and qualitative audits and inspections of process outputs, and continuous quality optimization following the PDCA cycle (Plan, Do, Check, Act) constitute the core scope of software quality management and are widely applied in mainstream industries such as finance, e-commerce, telecommunications, automotive, and healthcare. Currently, quality management practices are mostly carried out by the company's professional QA (Quality Assurance) team. This requires manual auditing of projects and the collection and analysis of post-audit metrics, with analyses conducted at fixed frequencies (weekly, monthly, and project-specific). The analysis content is also limited to issues and static problems within the QA team's own auditing knowledge. Therefore, this manual approach by the QA team suffers from drawbacks such as weak real-time performance, long processing times, low efficiency, poor objectivity, and limited comprehensiveness. Although various auxiliary models for software quality management exist in the industry, such as CMMI (Capability Maturity Model Integration), ISO (Quality Management System), and Agile practices, in actual implementation, existing technical solutions still generally suffer from the following technical shortcomings closely related to software quality management: First, quality evaluation lacks objectivity, real-time performance, and automated linkage mechanisms: In software companies' objective evaluation and quality measurement of different roles, fairness, objectivity, and real-time performance are crucial indicators. However, current technologies lack complete and automated collection and visualization of dynamic quality data throughout the entire software engineering lifecycle. Most current assessments still rely on offline manual judgment, leading to subjective biases and making it difficult to achieve fair, objective, and real-time multi-role measurement. Furthermore, the evaluation results lack data-driven automated analysis with quality management mechanisms such as personalized recommendations and personnel incentives, failing to form a closed-loop quality improvement cycle.

[0003] Second, the quality execution process lacks dynamic adaptability: the implementation of quality activities cannot be fixed or unchanging. Currently, the only way to dynamically and adaptively change and optimize the execution process is for the QA team to conduct targeted communication and decision-making, which results in long communication and implementation times and a lack of personalized implementation.

[0004] Third, the project execution lacks real-time quality guidance and proactive tracking mechanisms: existing static and dynamic project execution is always lagging behind, failing to provide dynamic and clear quality task guidance to various roles in the software; at the same time, it lacks the ability to proactively track process deviations, requiring reliance on the QA team to guide and assist in tracking, which makes it difficult to promote project delivery and asset accumulation.

[0005] Fourth, lack of a professional quality assurance system: Many domestic enterprises, especially small and medium-sized enterprises, have not established independent QA+QC (quality assurance + control) teams, or only developers perform testing work, making it difficult to implement project execution standards. As a result, quality defects are often delayed until the user stage, leading to adverse consequences such as a decline in reputation and customer loss.

[0006] Fifth, fragmented quality data hinders comprehensive management: Current quality management systems lack aggregated asset records, and quantitative quality data is not integrated throughout the entire project lifecycle. Requirements design, code quality, test defects, performance results, retrospective data, and asset records are scattered across individual terminals and different servers, making it impossible for companies and organizations to view the overall picture. Enterprises generally rely on third-party teams for weekly and monthly data collection, summarization, and analysis using offline Excel spreadsheets. Without external support from third-party teams, activities such as quality evaluation, incentive distribution, personnel development, and delivery control rely solely on subjective judgment, severely compromising the continuity and objectivity of quality management and leaving teams lacking data-driven dynamism and motivation for improvement.

[0007] In summary, there is an urgent need for a new software project quality management method that can automatically aggregate quality data, dynamically adapt to execution processes, guide project roles in real time, and link incentive evaluations. Summary of the Invention

[0008] The purpose of this invention is to provide a software project quality adaptive management method to solve the following problems mentioned in the background: existing software quality management methods have a high degree of reliance on manual labor, poor objectivity and real-time performance, lack automated linkage mechanisms, dynamic adaptive capabilities, real-time quality guidance mechanisms, proactive tracking mechanisms, and quality assurance systems, and the quality data is scattered and difficult to manage globally.

[0009] This invention is achieved using the following technical solution: An adaptive quality management method for software projects includes the following steps: S100, Quality Knowledge Graph Push: In the preset engineering nodes of the software project workflow, the quality knowledge graph is automatically triggered to push; the target of the quality knowledge graph push is the relevant role of the current engineering node, so as to support the relevant role to perform corresponding quality assurance activities. S200, Quality Test Execution: The collected project process metrics are calculated and analyzed to obtain and visualize the project status and quality conditions; among them, quality testing is executed based on test case scripts. S300, Quality Assurance Production Line Operation: The results of quality assurance activities and quality testing are assessed based on the project's quality-related knowledge base. The project closure or rectification phase is then implemented based on the assessment results. The outputs of the closure phase and / or the content of the rectification phase are automatically pushed to the relevant roles in the project.

[0010] Furthermore, the generation and optimization of the test case scripts are automatically executed via AI, wherein: After AI automatically generates and / or optimizes test cases, they are reviewed online by test experts and the project team. If the review by any one or both of the test experts and the project team fails, the test cases will be optimized in accordance with the requirements of the test experts and / or the project team. Test case scripts are only generated and put into the quality testing execution phase after both the test experts and the project team have reviewed and approved them.

[0011] Furthermore, the quality test execution includes: Perform functional tests to obtain functional metrics, including test case pass rate, functional coverage, defect density, and status code accuracy. Perform benchmark tests to obtain benchmark metrics, including maximum response time and data volume; Perform performance tests to obtain resource utilization and performance metrics; resource utilization includes CPU utilization and memory utilization, and performance metrics include maximum concurrent users, system capacity, response time percentile P90, average response time, and error rate.

[0012] Furthermore, the project quality-related knowledge base includes: The AI ​​knowledge base is a database of intelligent experience and case features, storing refined defect patterns, case features, and risk indicator weights to guide AI in attribution analysis and trend prediction. Knowledge graphs structure project processes, quality requirements, and management rules in a graph format, enabling association and rule verification.

[0013] Furthermore, the project quality-related knowledge base is dynamically iterated, including periodically inputting, providing feedback to, maintaining, or updating the following content: Instructions and models that are continuously trained provide the impetus for upgrading the AI ​​knowledge base; The experiences and cases extracted after the quality assessment is passed will be used to enrich the AI ​​knowledge base and knowledge graph.

[0014] Furthermore, the knowledge graph includes: Key activities of a project define the work packages, tasks and deliverables that need to be completed in the project lifecycle. They are used to compare workflow execution data and confirm whether key activities are completed on time and as required. Quality access control rules stipulate the quality standards that must be met at key activities in each project, and are used to determine whether the process can continue. Project management rules, including institutional documents, include organizational-level project management processes, resource allocation strategies, change control procedures, and document specifications, used to ensure the standardization and compliance of project execution.

[0015] Furthermore, the quality assessment includes the following steps: S310. The aggregated project-related data flows through the project quality-related knowledge base, and then parallel online automatic judgment and offline expert judgment are performed. Among them, online automatic judgment is to use AI knowledge base and knowledge graph to conduct automated and real-time evaluation; offline expert judgment is to conduct manual review by experts, and the judgment results are uploaded through the microservice system. S320. The judgment results of online automatic judgment and offline expert judgment, as well as the relevant data of the judged project, are summarized into analysis results to determine whether the current status of the project meets the standards. S330. Perform compliance assessment. If the assessment result is compliant, proceed to the project completion stage. If the assessment result is non-compliant, proceed to the rectification stage. The outputs of the project completion phase include a document quality dashboard, incentive review data, and reusable experiences and cases; the outputs of the rectification phase include dynamic graph analysis results, which include the project achievement status and areas for rectification. S340. If a rectification step was performed in S330, the quality assessment will be triggered again after the rectification is completed, that is, S310 to S330 will be repeated.

[0016] Furthermore, the following two notification mechanisms are executed in parallel: Automated notifications automatically trigger workflow start or end at preset project nodes. If a workflow start is triggered, the corresponding phased quality knowledge graph is pushed to relevant roles based on the current project stage. If a workflow end is triggered, the outputs of the project completion phase and / or the content of the rectification phase are automatically pushed to relevant roles. Manually triggered notifications can be initiated at any project node throughout the project lifecycle. When a manual click occurs, the microservice system receives and analyzes the click time and, based on the current project stage and / or project status, triggers the corresponding automated notification workflow.

[0017] Furthermore, it also includes the following steps: S400, development management, including: Project execution data collection involves collecting relevant quantitative data during the execution process of each project and summarizing it as input for multi-dimensional capability measurement analysis. Multi-dimensional capability measurement analysis, based on project-specific measurement libraries and capability measurement libraries, performs measurement analysis on the aggregated project quantitative data to generate development plans, and generates organizational strategic countermeasures based on the development plans; Organizational strategy alignment assessment involves reviewing and evaluating organizational strategic responses to obtain results on the adequacy of alignment. The development system is maintained by updating or cultivating organizations based on the results of fit adequacy, and a multi-dimensional development system is established based on organizational updates and / or cultivation.

[0018] Furthermore, the tissue renewal or tissue culture based on the fit adequacy results includes: If the fit is sufficient, then organizational updates will be carried out, including updating human resource allocation and skill-based job application mappings; If the fit is insufficient, organizational training will be conducted, including establishing organizational baselines and building individual historical records.

[0019] Compared with the prior art, the beneficial effects achieved by the present invention are: This paper provides an adaptive quality management method for software projects. By implementing quality knowledge graph push for project nodes, quality testing with visualized results, and a quality assurance pipeline based on a project quality-related knowledge base, it achieves fully automated, dynamically adaptive quality evaluation and management. Specifically: By automating quality testing through standardized test case scripts, reliance on offline manual evaluation is eliminated, ensuring the fairness, objectivity, and real-time nature of the results. The content in the project quality-related knowledge base can continuously evolve based on the results of quality assessments, thereby facilitating the automatic updating of quality management processes and requirements without requiring the QA team to spend a significant amount of time and energy on communication and decision-making. For project-related roles, the automatic execution of quality knowledge graphs, project completion outputs, and rectification content pushes enable timely and proactive task guidance and tracking, improving lag. Based on the automated quality management process, relevant quality data can be comprehensively collected and managed uniformly, thereby producing various quantitative content required by the team without relying on external support.

[0020] In summary, this invention establishes a professional quality assurance system that enables high-level quality control and optimization, preventing quality issues from arising during user operation. Attached Figure Description

[0021] Figure 1This is a schematic flowchart of the overall process of the management method described in the embodiments of the present invention; Figure 2 This is a schematic block diagram of the quality testing process in the development and testing phase of the management method described in this embodiment of the invention; Figure 3 This is a flowchart illustrating the quality assurance production line in the management method described in this embodiment of the invention. Figure 4 This is a flowchart illustrating two notification mechanisms in the management method described in this embodiment of the invention. Figure 5 This is a schematic flowchart of the nurturing management process in the management method described in the embodiments of the present invention; Figure 6 This is a schematic block diagram of the composition structure of the management system described in the embodiment of the present invention; Figure 7 This is an example diagram of the software interface for the AI-automated generation and / or optimization of test cases as described in the embodiments of the present invention; Figure 8 This is an example diagram of the software interface for automatically generating and / or optimizing test case results using AI, as described in this embodiment of the invention. Figure 9 This is an example diagram of the software interface for automatically generating and / or optimizing test script execution using AI, as described in an embodiment of the present invention. Figure 10 This is an example diagram of the software interface for the quality test report described in an embodiment of the present invention; Figure 11 This is a software interface example diagram of the milestone plan in the requirements design phase described in an embodiment of the present invention; Figure 12 This is a software interface example diagram of the static quality knowledge graph in the requirements design phase described in the embodiments of the present invention; Figure 13 This is an example diagram illustrating the indicator requirements for project schedule and cost management as described in this embodiment of the invention; Figure 14 This is an example diagram of an excerpt from the project schedule and cost management section of this invention (project not yet started); Figure 15 This is an example diagram of the contents of the project schedule cost management table (work progress of ongoing projects) as described in this embodiment of the invention; Figure 16 This is an example diagram illustrating the index requirements of the cutting table described in this embodiment of the invention; Figure 17 This is an example diagram of the content of the cropping table described in an embodiment of the present invention; Figure 18 This is an example diagram of the software interface of the microservice system for uploading cropping results as described in an embodiment of the present invention; Figure 19This is an example diagram illustrating the indicator requirements of the actual output documents during the requirements design phase as described in this embodiment of the invention. Figure 20 This is an example diagram illustrating the indicator requirements of the AI-automated test cases described in this embodiment of the invention; Figure 21 This is an example diagram illustrating the requirements for the completeness of the API documentation as described in this embodiment of the invention. Figure 22 This is an example diagram illustrating the indicator requirements for the implementation of the dual-track system as described in this embodiment of the invention; Figure 23 This is an example diagram of the software interface for creating a new RoadMap in the dual-track management system described in this embodiment of the invention; Figure 24 This is an example diagram of the software interface for the RoadMap project list and RoadMap preview described in an embodiment of the present invention; Figure 25 This is an example diagram of the software interface of the new project version of the dual-track management system described in this embodiment of the invention; Figure 26 This is an example diagram of the software interface of the project version mapping table described in an embodiment of the present invention; Figure 27 This is an example diagram illustrating the indicator requirements for showcasing the engineering capabilities of project members as described in this embodiment of the invention; Figure 28 This is an example diagram of the software interface for the quality assessment results during the requirements design phase as described in this embodiment of the invention; Figure 28 (a) is an example of the software interface for displaying dynamic graphs. Figure 28 (b) is an example image of the software interface displayed in the details list; Figure 29 This is an example diagram of the detailed list of dynamic spectrum analysis results described in an embodiment of the present invention; Figure 30 This is an example diagram of the software interface for modifying the milestone plan when the quality assessment during the requirements design phase fails to meet the standards, as described in this embodiment of the invention. Figure 31 This is an example diagram of the software interface that automatically proceeds to the next stage after the quality assessment in the requirements design phase meets the standards, as described in this embodiment of the invention. Figure 32 This is a software interface example diagram of the interface documentation completeness dimension of the project dashboard described in this embodiment of the invention; Figure 33 This is an example diagram of the software interface for the interface quality and health dimension of the project dashboard described in this embodiment of the invention; Figure 34 This is a software interface example diagram of the interface stability dimension of the project dashboard described in this embodiment of the invention; Figure 35This is a software interface example diagram illustrating the role weakness distribution of the individual dashboard as described in an embodiment of the present invention; Figure 35 Figure (a) shows an example of the skill distribution required for the current job position. Figure 35 Figure (b) shows an example of the distribution of an individual's current abilities in Subject 1, which is required for the target position. Figure 35 (c) is an example diagram showing the distribution of an individual's current abilities in Subject 2, which is required for the target position. Figure 35 (d) is an example diagram showing the distribution of an individual's current abilities as required by the Ministry of Human Resources and Social Security. Figure 35 (e) is an example diagram showing the distribution of an individual's current capabilities in accordance with other common requirements of the company. Detailed Implementation

[0022] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0023] First, to facilitate a better understanding of the technical solution provided by this invention, the relevant technical terms involved or that can be referenced are explained here, as follows: In the software industry, quality management involves systematically managing and standardizing the software development process, conducting quantitative and qualitative audits and inspections of process outputs, and continuously driving quality optimization by following the PDCA cycle to ultimately achieve continuous improvement in software quality capabilities. This series of activities constitutes the core scope of software quality management and is widely applied in application software development across major industries such as finance, e-commerce, telecommunications, automotive, and healthcare.

[0024] Process improvement: Process improvement is a process of systematically optimizing and upgrading processes, tools, methods, and systems across multiple dimensions, based on specific problems encountered in software engineering practice, combined with quantitative and qualitative data, and referencing an established quality model framework. Its core lies in systematically identifying and eliminating waste and redundancy in the development process, thereby improving product quality and production efficiency while increasing first-pass yield. The ultimate goal is to drive a high-efficiency leap in productivity through the continuous accumulation of process assets, achieving multi-dimensional and sustainable organizational improvement.

[0025] Full-industry testing: Integrating commonalities across multiple industries (such as finance, e-commerce, telecommunications, automotive, and healthcare), this template provides a comprehensive testing strategy that is multi-layered, multi-faceted, and all-encompassing, ensuring that the software meets requirements in all aspects, including functionality, performance, security, and reliability.

[0026] Zen&Tao: An open-source, customized agile project management software based on an open-source system, further developed for internal use by software companies. It covers core modules such as requirements, tasks, bugs, versions, and documentation, enabling visualized management and process tracking throughout the entire project lifecycle.

[0027] RoadMap: Clearly displays the planning time and core functions of each version of the project using a timeline.

[0028] Dual-track system: A dual-track management model that runs parallel to version planning (Track 1) and iteration tasks (Track 2, Project Number). Track 1: Version Planning (RoadMap) focuses on the overall planning of project versions, ensuring each version has clear goals and value; by clearly defining the version number, release cycle, and core value of the product at different stages, it provides a clear roadmap for project development. Track 2: Iteration Tasks (Project Number) The core focus is on retaining the project number while strongly binding it to the version, avoiding fragmented execution.

[0029] Example 1 This embodiment provides an adaptive quality management method for software projects, applied to process improvement in software engineering practice. This management method dynamically acquires data on engineering process metrics, intelligently pushes individualized improvement items based on project milestones, automatically matching required processes to different project types. Simultaneously, it recommends essential quality activities based on the project itself and individual weaknesses, significantly compensating for personnel shortcomings. Furthermore, visualized data allows managers to make rapid decisions, effectively mitigating risks. Additionally, AI-powered intelligent analysis and visual dashboards provide targeted improvement suggestions, offering a one-stop solution for issues related to incentives, personnel development, efficiency and quality improvement, and enhanced delivery reputation. Based on this, this management method can provide software companies with expert-level quality improvement consultants, and offers a systematic talent development system for project managers, test managers, and testers with no or weak background experience, accelerating their transition to senior project management and testing experts.

[0030] Please refer to Figure 1 The above-mentioned adaptive quality management method for software projects includes the following steps: S100, Quality Knowledge Graph Push: In the preset engineering nodes of the software project workflow, the quality knowledge graph is automatically triggered for push. The target of the quality knowledge graph push is the relevant role of the current engineering node, so as to support the relevant role in performing corresponding quality assurance activities.

[0031] In this embodiment, based on the engineering processes and milestone plans of each project, a standardized CI / CD (Computer Integrated Development and Delivery) pipeline is configured through the Dolphin Scheduler platform, and an orchestratable workflow is designed. At key (pre-set) engineering nodes of the project, the management system can statically retrieve and match the quality knowledge graph corresponding to the current stage from the knowledge base of the internal server, and then automatically push it to the relevant roles to support them in carrying out the corresponding stage of quality assurance activities.

[0032] Please refer to Figure 6 The management system (project quality adaptive management system) in this embodiment includes an enterprise knowledge base system module, an external system integration and data collection module, a multi-dimensional measurement and analysis module, and a capability improvement and knowledge base feedback module. Specifically: The enterprise knowledge base system module includes an AI knowledge base (as part of the project quality-related knowledge base), a TesTa knowledge base, and an enterprise knowledge base. It is used to store data (knowledge assets, intelligent instructions, etc.) related to the entire process of quality management and to provide access to the management system.

[0033] The external system integration and data collection module includes a microservice system, which is used to receive, collect, process, analyze, and upload relevant data to realize the execution of each step in the quality management method of this project; it also includes a dual-track management system, which is used to perform dual-track management of software projects and code branches on the project management software (ZenTao), interface testing and quality assurance platform (TesTa in this embodiment), code hosting platform (GitLab / GitHub), and enterprise-level knowledge management and collaboration software (Confluence) integrated / associated with the management system, according to the dual-track management rules.

[0034] The multi-dimensional measurement and analysis module includes an enterprise personnel strategic database (including a project measurement library and a capability measurement library), which stores the strategic configuration requirements for different positions and talent teams within the enterprise (company). This database is used to construct organizational talent capability profiles after project completion, combining personnel's past project undertakings, business practice experience, and individual capability assessment results (corresponding to step S400 below), thereby providing data support for talent planning, resource allocation, capability enhancement, and strategic decision-making.

[0035] The capability enhancement and knowledge base feedback module generates capability-oriented quality dashboards, project improvement action items, individual development plans, retrospective data, and organizational strategic countermeasures. It then feeds back relevant improvement data, including organizational strategic countermeasures, reusable experiences and cases, instructions and models, to the enterprise's personnel strategic database and enterprise knowledge base system module. Additionally, the generated retrospective data can be transmitted to the enterprise's incentive retrospective department for evaluating the achievement of set incentive goals.

[0036] S200, Quality Test Execution: The collected project process metrics are calculated and analyzed to obtain and visualize the project status and quality conditions; among them, quality testing is executed based on test case scripts.

[0037] In this embodiment, during project execution, AI automatically generates optimized versions of test cases and scripts, and automatically pushes the generated results to TesTa (interface testing and quality assurance platform). TesTa automatically schedules test tasks and executes test processes according to milestone plans, and uploads test outputs (such as defect reports) to integrated tools (including management of projects / versions, tasks, bugs, etc.; such as ZenTao software), while maintaining the asset management of engineering products such as test data.

[0038] S300, Quality Assurance Production Line Operation: The results of quality assurance activities and quality testing are assessed based on the project's quality-related knowledge base. The project closure or rectification phase is then implemented based on the assessment results. The outputs of the closure phase and / or the content of the rectification phase are automatically pushed to the relevant roles in the project.

[0039] In this embodiment, TesTa is deeply integrated into the entire CI / CD process. Through continuous collection of process data and calculation and analysis of process metrics (quality assessment) of the project quality-related knowledge base, it enables visualization of the status and quality conditions of each project at key stages and provides real-time quality monitoring and dynamic push notifications.

[0040] Furthermore, after project completion, the management system automatically generates visualized engineering review data and quality dashboards, and automatically pushes the review results and improvement actions from the incentive evaluation department to the project team and relevant stakeholders. At the same time, the code development instructions, model assets, and phased knowledge generated by the project will continuously flow back to the project quality-related knowledge base in an incremental manner. For engineering data collected during project implementation, it is transformed into reusable experience, patterns, and cases through processes such as analysis, feature extraction, and knowledge summarization, continuously accumulating and evolving the organizational-level knowledge system, and realizing the dynamic iteration and long-term value growth of the project quality-related knowledge base.

[0041] S400, Development Management: By collecting project execution data, conducting multi-dimensional capability measurement and analysis, assessing organizational strategic alignment, and maintaining the training system, a closed loop of talent capability management is formed through continuous iteration, consisting of "practice data - measurement analysis - strategic assessment - organizational improvement - individual training - capability reapplication". This aims to achieve dynamic mastery of engineering talent capabilities, continuous iteration, and systematic improvement of organizational-level capability baselines, so as to provide software companies with long-term, stable engineering talent support that is highly aligned with their strategies.

[0042] In this embodiment, firstly, quantitative data such as engineering quality, individual quality, project feedback, and test quality are collected through the execution process of each project and summarized as input for measurement analysis. Then, project-specific and individual-specific capability measurement rules and standards are extracted from the software enterprise's personnel strategic database to construct personnel capability profiles and identify the differences between the capabilities required for the project and existing capabilities. Next, based on the results of the difference analysis, personalized capability development plans are generated for project-specific, job-specific, and individual-specific scenarios and dynamically updated to the corresponding databases. Finally, based on the summarized development plans, the enterprise-level talent strategy is reviewed and evaluated.

[0043] This incubation management process utilizes a dynamic enterprise knowledge base within the management system. This knowledge base requires periodic maintenance to ensure its completeness, accuracy, and timeliness. Furthermore, organizational-level engineering improvement knowledge (such as technology optimization and project management), accumulated technical expertise, lessons learned, and the TesTa knowledge base are all incorporated into the enterprise knowledge base system (represented by the enterprise knowledge base module of the management system). Specifically, the enterprise knowledge base stores data on the enterprise's mainstream development foundations and frameworks, code quality management standards, technical information and interactions, accumulated business knowledge, classic cases, and best practices; the TesTa knowledge base stores data on TesTa knowledge graphs, tutorial manuals, and standardized procedures.

[0044] Furthermore, the specific details of the above steps are as follows: In step S200: The AI ​​automatically generates and optimizes test case scripts. After the AI ​​automatically generates and / or optimizes the test cases, they are reviewed online by test experts and the project team. If the review by any one or both of the test experts and the project team fails, the test cases are optimized according to the requirements of the test experts and / or the project team. Only when the reviews by both the test experts and the project team are approved will the test case script be generated and put into the quality testing execution stage.

[0045] Quality testing includes: performing functional tests to obtain functional metrics, including test case pass rate, functional coverage, defect density, and status code accuracy; performing benchmark tests to obtain benchmark metrics, including maximum response time and data volume; and performing performance tests to obtain resource utilization and performance metrics. Resource utilization includes CPU utilization and memory utilization, while performance metrics include maximum concurrent users, system capacity, response time percentile P90, average response time, and error rate.

[0046] In this embodiment, please refer to Figure 2 Taking the development and testing phase of a software project as an example, this paper explains the quality testing execution process based on test case scripts, including the following: A210: The quality testing process is initiated automatically via workflow triggering or manually clicked by project members. Based on a process-driven mechanism, code branches are first created according to code branch management rules. Specifically: The code branch management rules are built on the Git distributed version control system. Through unified branch type definition and hierarchical synchronization mechanism, it can realize efficient management of multi-repository collaborative development. It has the advantages of controllable multi-repository collaboration, isolation between development and release, rapid response to emergency fixes without interfering with the development of new features, and version traceability.

[0047] In this embodiment, the code branch management rules include the following: Step 1: Define a unified branch type and permission specification; Step 2: Establish a layered synchronization mechanism under a multi-warehouse architecture; Step 3: Generate a unique version identifier for each code commit and establish a traceability chain linking version, task, and requirement.

[0048] The code branch management rules provide a concise definition of branch types as follows: Main branch: This is the stable release baseline; changes must be approved via pull requests (PRs), and direct pushes are prohibited. Develop branch: This is the main development line, bringing together code from various feature branches and serving an integration role. Feature branch: This is a branch cut from the Develop branch, used for developing specific features or sub-projects. Once completed, it is merged back into the Develop branch (and the feature branch is deleted). Release branch: This is a branch cut from the Develop branch, used for pre-release bug fixes. Once completed, it is merged into both the Main branch and the Develop branch. QC branch: This is a branch cut from the Develop or Release branch, used for verification testing. Once passed, it is merged back into the original branch. Hotfix branch: This is a branch cut from the Main branch, used for fixing urgent online issues. Once completed, it is merged back into both the Main branch and the Develop branch.

[0049] A220: When TesTa recognizes that a code branch already exists and meets the preset triggering conditions (the version branch of the current version has been created according to the RoadMap), it automatically starts the AI ​​use case optimization job, specifically: Based on different testing needs, test cases cover a wide range of categories, including functional testing, regression testing, interface testing, performance testing, full-economy testing, security penetration testing, and mobile application compatibility testing. During the software project's requirements design phase, AI automatically generates test cases and automatically supplements them according to different test case types and the roles of the testing and project teams. During the development and testing phase, AI automatically optimizes the test cases, and the optimization process can be adjusted automatically based on business conditions (e.g., AI tuning through interactive Q&A) and offline (e.g., QC (quality control) manual verification based on testing experience). For the optimized test cases, testing experts and the project team conduct online reviews. Testing experts assess business coverage, and the project team conducts risk assessments. The assessment results are processed as follows: First, if the test expert review fails, the test expert will provide missing scenarios (including insufficient identification of multi-condition combination scenarios, abnormal scenarios, boundary scenarios, negative scenarios, etc. under complex business logic) to supplement the test cases, and then the AI ​​will automatically optimize the test cases again. Secondly, if the project team's review fails, the project team will provide a risk assessment and suggestions, and the AI ​​will automatically optimize the use cases again. In other words, if any party's review fails, the test cases will be optimized based on the requirements of the testing experts / project team. Only when both the testing experts and the project team's reviews are passed can test case scripts be generated and the test enter the quality testing execution phase. Specifically, for the optimized and finally approved test cases, AI test case coverage is measured, including metrics such as AI test case generation speed, functional coverage, defect detection rate, and anomaly coverage. During the automatic optimization of AI test cases, it is possible to choose to use AI test cases to generate interface execution scripts, which are then automatically pushed to TesTa as input parameters for subsequent interface testing; otherwise, the test directly enters the testing execution phase.

[0050] A230: Quality testing execution, wherein the following are performed in sequence: Testers perform functional tests and obtain functional metrics, including test case pass rate, functional coverage, defect density, and status code accuracy. Testers perform benchmark tests and obtain benchmark metrics, including maximum response time and data volume; Testers perform performance tests and obtain performance metrics and resource utilization from the results returned by the performance testing tools. Performance metrics include maximum concurrent users, system capacity, response time percentile P90, average response time (under stress), and error rate (under stress). Resource utilization includes CPU utilization and memory utilization.

[0051] After the test is completed, if defects are found, they can be automatically uploaded to an integrated tool (such as ZenTao software) via TesTa's bug upload module. After the bug is fixed, the project team members update the code branch. Furthermore, after the bug is fixed, QC (Quality Control) regression testing is performed, repeating the above process until no bugs are found and the release criteria are met. Then, the TesTa test assets (including test cases, test defects, and test reports) are archived and uploaded to Confluence (enterprise-level knowledge management and collaboration software).

[0052] A240: After all functionalities in the software development and testing phase are completed, and the defects identified in the above quality tests are fixed (the final test result is defect-free), the code branch is merged and committed. The specific steps are as follows: Firstly, code security reviews are automatically triggered, and the review results are processed as follows: If the code security review results are not up to standard, there are rectification points. These rectification points will be automatically pushed to the project PJL (Project Manager) / PGL (Development Manager) to arrange for the project team to rectify them and then conduct another review. If the code security review results are satisfactory, the results will be automatically uploaded through the microservice system and notified to all members of the project team via email.

[0053] Secondly, CI / CD (Continuous Integration / Continuous Delivery & Deployment) is automatically triggered, initiating integration code quality analysis and scanning, and building automated tests to obtain unit test pass rates. The processing methods for scan results and pass rate results are as follows: If the code scan results show areas for rectification and / or the unit test pass rate is below standard, the code will be automatically pushed to the project PJL / PGL. After the project team makes rectifications, the code will be resubmitted to trigger CICD for automated testing and code scanning again. If the code scan results show no areas for remediation, the microservice system will automatically upload the review results and notify all project team members via email; if the unit test pass rate meets the target, functional tests will be triggered.

[0054] A250: After all necessary reviews and automated testing are completed, the code is merged into the release branch, and version planning and mapping relationships, dynamic management metrics such as synchronization and pass rate are synchronized to the dynamic performance graph. If the release branch still has legacy issues that do not meet the overall quality standards, mandatory rectification must be carried out, and the process can only proceed to the next stage after confirming that all quality gate requirements are met again.

[0055] In step S300: Please refer to Figure 3The quality assurance pipeline aims to achieve closed-loop management and continuous optimization of project quality by integrating knowledge bases, automated judgment, and expert intervention. In the quality assurance pipeline, data is collected, analyzed, and summarized before reaching the project quality-related knowledge base. Objective data analysis, triggered by engineering milestones, is pushed from project teams and individuals, with regular dynamic feedback forming a closed loop. This makes project evaluation and organizational-level improvement systematic and achieves targeted, highly interconnected actions.

[0056] The project quality-related knowledge base is the core component supporting the project from data collection, rule verification, intelligent analysis to final feedback and rectification. It is not a single entity, but rather consists of two parts, each with a different functional role. Specifically: The project quality-related knowledge base includes: The AI ​​knowledge base is a database of intelligent experience and case features, storing refined defect patterns, case features, risk indicator weights, etc., to guide AI in attribution analysis and trend prediction. Knowledge graphs structure complex project processes, quality requirements, and management rules into a graph format, enabling rapid association and rule validation. Specifically, this includes: Key activities of the project define in detail the work packages, tasks and deliverables that need to be completed in the project lifecycle; they serve as the baseline of the process and are used to compare workflow execution data to confirm whether key activities are completed on time and as required. The quality access control rules clearly define the quality standards that must be met at key activities / nodes of each project, providing hard verification rules for online automatic judgment to determine whether the process can continue; Project management rules, including institutional documents, include organizational-level project management processes, resource allocation strategies, change control procedures, and document specifications, used to ensure the standardization and compliance of project execution.

[0057] In this embodiment, the content of the project quality-related knowledge base is not static but dynamically iterative, undergoing periodic maintenance to ensure its timeliness and accuracy. Specifically, the dynamic iteration of the project quality-related knowledge base includes periodically inputting, providing feedback to, maintaining, or updating the following content: The first is instructions and models: external input and continuous training algorithm configuration provide the impetus for upgrading the AI ​​knowledge base; Secondly, there are experiences and case studies: successful experiences and case studies that are accumulated / refined after quality assessments are achieved are used to enrich the AI ​​knowledge base and knowledge graph, so as to realize the assetization of the organization's experience.

[0058] After project data flows through the project quality-related knowledge base, it undergoes quality assessment through two parallel mechanisms, including the following steps: S310. The aggregated project-related data flows through the project quality-related knowledge base, and then parallel online automatic judgment and offline expert judgment are performed: Online automatic assessment utilizes AI knowledge bases and knowledge graphs for automated, real-time evaluation; Offline expert assessments are subject to manual review by experts, and the assessment results are uploaded via the microservice system.

[0059] S320. The results of online automatic judgment and offline expert judgment, as well as the original project-related data being judged, are summarized into an analysis result to determine whether the current status of the project meets the standards.

[0060] S330, Perform compliance determination and trigger the next step based on the determination result: If the judgment result is that the standard is not met, the rectification step will be implemented: the management system will generate dynamic graph analysis results (including each indicator of the project, the achievement status and the points to be rectified), and trigger automatic push to make the project team rectify. If the assessment result is satisfactory, the project closure phase will proceed: The project closure phase is when the process enters the closure and experience accumulation stage, and the output includes document quality dashboards, incentive review data, reusable experience and cases; among them, project-specific / person-specific document quality dashboards and incentive review data are automatically pushed to the project team and stakeholders, and the reusable experience and cases extracted from the project are used to enrich the project quality-related knowledge base.

[0061] S340. If a rectification step is performed in S330, a quality assessment will be triggered again after the rectification is completed, that is, S310 to S330 will be repeated to form a rectification cycle.

[0062] Through the implementation of the above quality assessment, organizational-level improvement and objective evaluation were achieved, specifically: Based on process measurement data and project completion comprehensive data, quantitative dashboards and dynamic graphs are formed, enabling project-level, PM (project group manager)-level, and enterprise-level to conduct in-depth and precise analysis through quantitative data; The evaluation should be conducted in a way that avoids formality, breaks away from considerations of relationships and arbitrariness, and achieves quantitative assessment and dynamic improvement to enhance company efficiency and stimulate innovation among high achievers.

[0063] During the execution of steps S100 to S400, the project quality notification system includes two parallel notification mechanisms: automated notification and manually triggered notification. Please refer to [link / reference needed]. Figure 4 , specifically: Regarding automated notifications: At preset project nodes, the workflow is automatically triggered to start or end. If the workflow is triggered to start, the corresponding phased quality knowledge graph is pushed to the relevant roles based on the project stage of the current project node. If the workflow is triggered to end, the outputs of the project completion stage and / or the content of the rectification stage are automatically pushed to the relevant roles.

[0064] In this embodiment, as an example, existing automated notification software such as TesTa Open API (Open Application Programming Interface), DingTalk, and WeChat Work Webhook are used (selection and expansion can be made according to the enterprise). The pushed content includes knowledge graphs as static data, dynamic graph analysis results as dynamic data, and knowledge asset accumulation and incentive feedback, wherein: Firstly, the knowledge graph, presented as static data, is pushed to the project's Project Job List (PJL) / Project Product List (PGL). This involves automatically triggering a workflow based on planned milestones and the project's current phase's initiation events. The workflow then pushes the corresponding phased static knowledge graph (containing a standardized list of tasks, key performance indicators, and quality standards) to the project's Product Job List (PJL) / Project Product List (PGL). Guided by this knowledge graph, the PJL / PGL coordinates the execution of various activities by different roles within the project team (e.g., developers, testers, architects).

[0065] Secondly, the dynamic graph analysis results, presented as dynamic data, include: automatically triggering the closing workflow based on planned milestones and the start events of the current project phase. This workflow aggregates all execution data and outputs generated during the project, combining automated judgment from the online knowledge base with subjective review by offline experts to summarize and analyze the dynamic achievements of the current phase. These analysis results will be automatically pushed to the project team and stakeholders. Specifically: For the critical non-compliance items identified in the analysis, they will be treated as rectification items and pushed to the project PJL / PGL along with the phase quality access control notification. After the project PJL / PGL assigns the relevant personnel to complete the rectification, the workflow will be triggered again to collect the latest data for judgment and analysis, thereby forming a closed loop of feedback and rectification.

[0066] The automated assessment of online knowledge bases includes: specific requirements and common measurement rules for each stage, such as document health in the requirements design stage, test health in the development and testing stage, and test stability in the release and delivery stage. Common parts include quality compliance checks (such as security specifications), measurement analysis, and other general quality rules.

[0067] Offline expert subjective reviews include in-depth, subjective, and professional reviews that lack objective quantitative basis and require integration with the expert's knowledge system, such as technical architecture reviews and security reviews. The review results will be uploaded by the QA team to the microservice system and aggregated with data from the online knowledge base after automated evaluation.

[0068] Third, the knowledge asset accumulation and incentive feedback includes: after the project is completed, the multi-dimensional measurement and analysis module will integrate the injected knowledge base resources to conduct in-depth analysis of all data collected during the project execution process (including process measurement indicators, phased output results, quality access records, etc.); based on the analysis results, the capability improvement and knowledge base feedback module will generate personalized quality dashboards, personalized development plans, personalized project incentive data, personalized asset accumulation, etc.

[0069] Regarding manually triggering notifications: At any point in the project's lifecycle, when a project team member clicks, the microservice system receives and analyzes the click time to obtain the project's stage and status; based on the different statuses of different stages, it dynamically triggers corresponding automatic workflow pushes in real time.

[0070] In step S400: Please refer to Figure 5 The project execution data collection, multi-dimensional capability measurement and analysis, organizational strategic alignment assessment, and training system maintenance specifically include: Project execution data collection: Collect relevant quantitative data (including engineering quality, individual quality, project feedback and test quality, etc.) through the execution process of each project, and summarize them as input for multi-dimensional capability measurement analysis; Multi-dimensional capability measurement analysis: Based on the project measurement library and capability measurement library extracted from the enterprise personnel strategy database, the rules and standards for project-specific measurement and person-specific capability measurement are obtained. Then, the aggregated quantitative project data is measured and analyzed to build personnel capability profiles and identify the differences between the capabilities required for the project and the existing capabilities. Based on the difference analysis results, personalized capability development plans are generated for project-specific / position-specific / person-specific, and dynamically updated to the enterprise personnel strategy database. Organizational (enterprise / company-level) strategic countermeasures are generated with reference to the development plans. Organizational strategic alignment assessment: Based on the compiled development plan, the organizational strategic measures are reviewed and evaluated to obtain the adequacy of alignment results; the review and evaluation include QCD (Quality, Cost, Delivery). cost The delivery status (on schedule), the overall project quality personnel's multi-dimensional delivery capabilities, and the achievement of incentive targets (which can be based on indicators set by the company itself); Incubation system maintenance: Based on the fit adequacy results, conduct tissue renewal or tissue culture, and establish a multi-dimensional incubation system based on tissue renewal and / or tissue culture, specifically including: If the fit is sufficient, organizational updates will be carried out, including updating the human resource allocation and competency job application mapping, that is, the relevant data of project / person will be entered into the subsequent human resource allocation and competency job application mapping process. If the fit is insufficient, organizational development will be implemented, initiating an organizational-level capability improvement process. This includes: First, establishing an organizational baseline, developing targeted professional training courses, optimizing technical practices, establishing mentorship programs, and implementing improvement strategies. These strategies include completing planned specialized learning and practical training tailored to individual skill gaps, receiving company-organized training and targeted guidance, and undergoing capability assessment and certification. Second, constructing an individual's historical capability development portfolio to achieve targeted capability enhancement from multiple dimensions, including personal career development, company job requirements, online company courses, and offline mentorship programs.

[0071] In summary, the adaptive management method provided in this embodiment breaks away from traditional management models, offering effective tools for software managers, developers, and testers in the industry. It enables immediate improvement, immediate incentives, immediate analysis, and immediate knowledge graph enhancement. Furthermore, it allows for flexible allocation of local vector databases, enabling project management to accumulate data across multiple dimensions, including quantification, incentives, personnel development, and asset accumulation. This solution focuses on serving people, allowing project managers and technical managers to accelerate their growth and quickly adjust management strategies and organizational-level improvement plans.

[0072] Example 2 Regarding the generation of test case scripts in step S200 of the management method described in Embodiment 1, this embodiment provides a specific example as follows: First, please refer to Figure 7 Users can upload upstream requirement files or enter content in the requirement description box to provide detailed project requirements, functional specifications, and other test-related information.

[0073] Secondly, after obtaining the requirements, the advanced options configuration stage begins. In this stage, users can further adjust the settings according to the characteristics of their own projects. Depending on the different requirements of the project, users can choose to generate suitable interface test scripts or adjust the number and priority of test cases to ensure the relevance and comprehensiveness of the test cases.

[0074] Subsequently, during the AI-automated execution and review phase of test case scripts, the TesTa system supports seven major test types, including security penetration testing, functional testing, regression testing, interface testing, full-economy testing, performance testing, and mobile application compatibility testing. Each test type uses a proprietary prompt template (pre-configured by TesTa), comprising three parts: an execution template, a test team review template, and a project team review template. The prompt template provides the requirements for generating test cases, including but not limited to role settings, rules, test strategies, and output formats.

[0075] The TesTa system simulates the role of a senior testing expert to generate high-quality test cases according to template-defined conditions. These generated test cases then undergo review by senior testing and project team members. The testing team provides a review summary and risk assessment, reviews business requirement coverage, test case design quality, and offers suggestions for modification and optimization. The project team also provides a review summary, risk assessment, and reviews the rationality of testing priorities, ensuring no test cases are missing and offering supplementary suggestions. The review process aggregates all feedback and provides a detailed summary, using test cases to identify design flaws and help the development team quickly identify and fix potential problems. This review mechanism ensures that test cases cover project requirements to the maximum extent possible while avoiding omissions or redundancy.

[0076] At this point, the generated test cases have been meticulously designed by senior testing experts and reviewed by both the testing and project teams, enhancing the comprehensiveness, effectiveness, and efficiency of the testing. If the advanced options configuration is set to generate interface execution scripts, the corresponding execution scripts will be generated simultaneously when test cases are generated for use during quality testing.

[0077] Finally, please refer to Figure 8 The generated test cases and API execution scripts will be displayed in a clear Markdown format and available for download in Excel format. The test cases include specific preconditions, test steps, expected results, and API execution scripts. Please refer to... Figure 9 Testers can convert the generated interface execution script into a TesTa-supported format and import it into TesTa; then, please refer to... Figure 10 A quality test report can only be generated by executing the test set.

[0078] Example 3 Regarding the management method described in Example 1, this example takes the requirements design phase of software development as an example to provide a detailed explanation of the entire project quality management process as follows: P1: Please refer to Figure 11 After the project was approved and met the target requirements, it smoothly entered the requirements design phase according to the milestone plan.

[0079] P2: According to the milestone plan, the start date of the requirements design triggers the startup workflow, automatically sending static maps to the project team's PJL / PGL.

[0080] Please refer to Figure 12 The blue text on the graph represents the key metrics and dynamic data from the requirements design phase, specifically including the following seven items: P2.1: Project Schedule and Cost Management Please refer to the project schedule and cost management indicator requirements. Figure 13Once the project type is determined, and milestone plans and budgets for ABD-type projects are further clarified, they are uploaded to the microservice system. ABD projects are categorized by the enterprise based on their importance: A-type projects are key projects requiring continuous monitoring from initiation to completion; B-type projects are of moderate importance; and D-type projects are product-related. From this stage onward, the microservice system includes an input interface for updating actual progress.

[0081] For project schedule and cost management before the project starts, please refer to [link / reference needed]. Figure 14 Once the project milestone plan and work budget are finalized, they will be completed by PJL / PGL. Figure 14 The relevant information for each engineering phase of the project, including start and end times, budgeted man-hours, and the consumption percentage, is calculated using a formula (no need to fill in this out). Furthermore, this... Figure 14 The project schedule and cost management content shown is uploaded to the microservice system. From this stage onwards, the microservice system retains an input interface for back-filling the actual progress.

[0082] At the end of the requirements design phase, the QA team uses tools to extract the actual man-hours consumed in that phase and backfills the feature completion progress. Based on the comparison between the budgeted man-hours and the actual man-hours consumed, as well as the feature completion rate, the team automatically deducts points according to the rules to calculate the final score for this indicator and determines whether the target has been met based on this score.

[0083] For the progress of work completion status of ongoing projects, please refer to [link / reference]. Figure 15 If there are any changes to the milestone plan, the QA team can collect them offline and upload them to a designated location. The microservice system can then read the changes and modify the corresponding changed nodes, or modify them directly online (suitable for minor changes).

[0084] P2.2: Cutting Table: Please refer to the specifications for the cutting table. Figure 16 Before the requirements design phase ends, the offline QA team collects the tailored results from the project team and uploads them to the designated location; please refer to [the relevant documentation / reference]. Figure 17 Tailoring refers to cutting out some documents, activities, etc., according to the actual situation of the project. For example, based on the type, complexity, risk level and customer requirements of the project, the standard quality management activities required by the enterprise are appropriately adjusted, selected and configured to make them suitable for the current project.

[0085] Please refer to Figure 18 The clipped portion, read by the microservice system, will still be displayed in the graph, but will no longer be a document / activity that must be output as a quality requirement.

[0086] P2.3: Actual output documents during the requirements design phase: Please refer to the performance indicators for the actual output documents during the requirements design phase. Figure 19 On the deadline for requirements design, the end workflow is automatically triggered, and the actual number of project documents in Confluence is automatically checked to determine if it matches the trimmed number. If they do not match, points are deducted according to the rules, and the final score determines whether the target has been met. In case of special circumstances caused by objective factors, the project team can input the reasons to the system for explanation, etc.

[0087] P2.4: AI-automated test cases: Please refer to the metrics requirements for AI-automated test cases. Figure 20 Before the requirements design phase ends, the QA team communicates offline with the project team to collect the planned number of test cases and planned coverage of AI-generated test cases, which are then logged into the system by the project team (or QA).

[0088] The planned number of test cases is a mandatory value during the development and testing phase for AI-optimized test cases; the planned coverage is used to measure whether the coverage after AI-optimized test cases matches the set coverage. Therefore, this metric is not a criterion for determining whether the requirements design phase has been met; thus, this item is listed in this embodiment mainly to illustrate the relevant content and is not limited to the actual metric requirements of the requirements design phase.

[0089] P2.5: API Documentation Completeness: Please refer to the metrics for API documentation completeness requirements. Figure 21 On the end date of the requirements design phase, the workflow will be automatically terminated, and the API documentation will be automatically checked to ensure compliance. Figure 21 The requirements are specified, and points are deducted according to the rules. The final score determines whether the standard is met.

[0090] P2.6: Project Management Rules (Dual-Track System): Please refer to the indicator requirements for the implementation of the dual-track system. Figure 22 In this embodiment, for the dual-track system implementation: Firstly, starting from the requirements design phase, the workflow is triggered, automatically invoking the quality adaptive process subsystem, i.e., the dual-track management system, which includes the following: Automatically create a dual-track version roadmap or update the roadmap (for new projects on existing topics) and update it in the corresponding Confluence management space; Automatically create a dual-track mapping table to update the mapping relationship between each version of the project and the included iterative project number to the corresponding management space Confluence.

[0091] Secondly, upon completion of the requirements design phase, the workflow is terminated. The system automatically checks the RoadMap and mapping table on the Confluence management space corresponding to the project, determines whether the requirements are met, deducts points according to the rules, and determines whether the project qualifies based on the final score. Other tools used in subsequent project processes (besides Confluence, tools and platforms used for project management, development, testing, collaboration, and delivery activities, such as the project management tool ZenTao and the code management tool GitLab) should also be planned and managed according to the automatically generated roadmap and mapping table.

[0092] Please refer to Figure 23 and Figure 24 This shows the creation of a new RoadMap in the dual-track management system within the management system, as well as the RoadMap project list and RoadMap preview; please refer to... Figure 25 and Figure 26 This shows the new project version and project version mapping table in the dual-track management system.

[0093] P2.7: Demonstration of project members' engineering capabilities: Please refer to the indicator requirements for demonstrating the engineering capabilities of project members. Figure 27 This dashboard displays information about engineering skills tests, shortcomings and action items identified in projects participated in, and accumulated feedback received after participating in projects. It can serve as a reference for project managers and the individual in subsequent work on the current project, helping to avoid and correct shortcomings and better leverage the strengths of team members.

[0094] for Figure 27 The metrics in the plan will be automatically determined at the end of the requirements design phase, according to the milestone plan; please refer to... Figure 28 and Figure 29 The results are displayed as dynamic spectral analysis results, and clicking on a result will display a detailed list.

[0095] If the assessment result is deemed unsatisfactory, rectification and quality access control notifications will be pushed to the project PJL / PGL via software such as DingTalk; the project cannot proceed to the next stage until the standards are met. Please refer to [link / reference]. Figure 30 If modifying the time necessitates changing the milestone, this can be done on the microservice system.

[0096] If the assessment result is satisfactory, please refer to... Figure 31 If so, the microservice system updates the design phase of the requirements and moves to the next phase according to the milestone plan.

[0097] P3: According to the project milestone plan, once all phase indicators are completed, the project will enter the closing phase. This includes the following: P3.1: The microservice system aggregates metric data from all stages and generates project-specific dashboards from the following dimensions: P3.1.1: Basic Project Information.

[0098] P3.1.2: Overview of Key Indicators: Task completion rate, remaining work, number of valid bugs (defects), outstanding issues, faults, and incentive achievement.

[0099] P3.1.3: Task: Comparison of task completion plan with actual results, distribution of task status by project stage, and distribution of task status by individual.

[0100] P3.1.4: Interface: This includes three dimensions: completeness of API documentation, API quality and health, and API stability. Please refer to the relevant documentation for each dimension. Figure 32 , Figure 33 and Figure 34 .

[0101] P3.1.5: Project Management Project management rule compliance, completion rate of activities within the cut-off table, achievement status of completed content, dual-track system implementation, and statistical violations.

[0102] P3.1.6: Quality, Cost, and Delivery Time: Project safety review, project code review results, project code quality scan results, test defect rate, budgeted and actual manpower consumption, and distribution of manpower consumption per person.

[0103] P3.1.7: Project Review Summary: Project execution requirements & goal setting (motivation), individual task completion speed / efficiency, number of problems solved, number of outstanding issues and project manager comments, lessons learned - problem points & improvement points, project capability evaluation of participating members, and development plan.

[0104] P3.2: The microservice system aggregates data on individual project participation and corporate promotion requirements to generate individual dashboards from the following dimensions: P3.2.1: Member's basic information, current position and level, and target position.

[0105] P3.2.2: Project History & Current Level: Project experience and roles played in the past 3 years (UI, front-end development, etc.); you can click to view the project dashboard and development plan at that time.

[0106] P3.2.3: Competency Dimension: Compare your current skill level with the requirements of the target position.

[0107] P3.2.4: Skill Shortcomings: By referring to the technical experts in the company and the department, we can identify the content of the skill requirements and compare them with the current level and shortcomings.

[0108] P3.2.5: Core Weakness Items: The core business capabilities and technical requirements of the department, as well as the current level and shortcomings.

[0109] P3.2.6: Distribution of Weaknesses by Role: Cycle type: Position, target position, comparison of the content required by the company with the individual's level, display of the points of satisfaction and the points of deficiency, and automatic generation of personalized development plans based on the points of dissatisfaction in the role type.

[0110] For example, in this case, Wang is currently a technical manager assistant, and his goal is to become a senior technical manager. The generated personal dashboard would look like this: Figure 35 As shown. Among them, Figure 35 The diagram shows the current skill distribution of individuals for Subject 1 and Subject 2 required for the target position. Subject 1 and Subject 2 are shown here as examples; the actual number of subjects varies depending on the specific position.

[0111] P3.2.7: Personnel Development: Individual development plans for each cycle, priorities and completion rates, improvements before and after development, and achieved results.

[0112] P3.2.8: Role Promotion Readiness: A comparison of all items required for promotion to the target position with the current level.

[0113] P3.2.9: Organizational-level two-way analysis: Individual Weakness Analysis: Analysis of engineering capability weaknesses and superiors' comments at each stage; Individual-specific cycle improvement: Based on the company's continuous activities, the company conducts regular competency assessments and certifications to analyze the differences in personnel's capabilities in project undertaking and job positions. Based on the analysis results, personalized competency improvement plans are developed. Through specialized knowledge empowerment, experience sharing and reverse explanation, multi-dimensional evaluation by mentors and teams, and on-the-job practical training, the company promotes the continuous growth of personnel's capabilities and tracks, evaluates and dynamically optimizes the plans according to the cycle to achieve a continuous match between individual capabilities and organizational development needs. The analysis results are imported into the microservice system as data input and displayed in the microservice system; at the same time, data from the project knowledge base, metric knowledge base (project / engineering metric base, capability metric base), etc., will also flow into the organizational-level improvement knowledge base (i.e., the enterprise knowledge base).

[0114] Example 4 Regarding the AI ​​knowledge base in step S300 of the management method described in Embodiment 1, this embodiment provides a specific example as follows: The application of AI knowledge base for attribution analysis is reflected in the following: when an interface fails and a bug report needs to be generated, the raw data such as interface call logs, error stacks, request parameters, response data, and system environment information are structured and then fed into the AI ​​knowledge base for in-depth attribution analysis.

[0115] In the attribution analysis phase, the AI ​​knowledge base calls upon a defect pattern library to match current failure characteristics with historically stored defect patterns. This library contains typical characteristics of various interface failures, such as "database connection pool exhaustion," "improper timeout configuration," "third-party service degradation," "missing parameter validation," "memory overflow," and "concurrency conflicts." Through feature matching, the AI ​​knowledge base can quickly pinpoint the root cause of the failure. For example, it can identify "ConnectionTimeoutException" in the error stack and match it with the "database connection pool exhaustion" pattern, or identify "NullPointerException" and match it with the "missing parameter validation" pattern. Simultaneously, the AI ​​knowledge base calls the attribution analysis module, combining multi-dimensional information such as the call chain context, dependent service status, and resource usage to determine whether the failure is due to code defects, configuration errors, environmental issues, or external dependency anomalies. Furthermore, the attribution analysis module also calls a successful case feature library to retrieve repair solutions and resolution paths for similar failure cases in the past, providing developers with referable repair suggestions.

[0116] Finally, the AI ​​diagnostic assistant integrates the attribution analysis results to generate a structured bug analysis report, which is returned to the user. The report includes: root cause location and detailed steps of the failure event, expected behavior and actual behavior, environmental information, and intelligent error analysis. Therefore, through attribution analysis using the AI ​​knowledge base, interface failures are no longer simply presented as error stacks, but are transformed into actionable diagnostic conclusions with root causes, suggestions, and predictions, thereby helping developers and operations personnel shift from passive response to proactive prevention.

[0117] It should be noted that the parts not described in detail or in elaboration in the above solutions are all prior art and do not constitute improvements made by this invention to existing technology, nor are they within the protection scope of this invention's technical solutions. Therefore, they will not be elaborated upon further in this document. Of course, the above content is merely a preferred embodiment of this invention and should not be considered as limiting the scope of the embodiments of this invention. This invention is also not limited to the above examples; equivalent changes and improvements made by those skilled in the art within the substantial scope of this invention should all fall within the patent coverage of this invention.

Claims

1. A software project quality adaptive management method, characterized in that, Includes the following steps: S100, Quality Knowledge Graph Push: In the preset engineering nodes of the software project workflow, the quality knowledge graph is automatically triggered to push; the target of the quality knowledge graph push is the relevant role of the current engineering node, so as to support the relevant role to perform corresponding quality assurance activities. S200, Quality Test Execution: The collected project process metrics are calculated and analyzed to obtain and visualize the project status and quality conditions; among them, quality testing is executed based on test case scripts. S300, Quality Assurance Production Line Operation: The results of quality assurance activities and quality testing are assessed based on the project's quality-related knowledge base. The project closure or rectification phase is then implemented based on the assessment results. The outputs of the closure phase and / or the content of the rectification phase are automatically pushed to the relevant roles in the project.

2. The software project quality adaptive management method according to claim 1, characterized in that, The test case scripts are automatically generated and optimized using AI, wherein: After AI automatically generates and / or optimizes test cases, they are reviewed online by test experts and the project team. If the review by any one or both of the test experts and the project team fails, the test cases will be optimized in accordance with the requirements of the test experts and / or the project team. Test case scripts are only generated and put into the quality testing execution phase after both the test experts and the project team have reviewed and approved them.

3. The software project quality adaptive management method according to claim 1, characterized in that, The quality test execution includes: Perform functional tests to obtain functional metrics, including test case pass rate, functional coverage, defect density, and status code accuracy. Perform benchmark tests to obtain benchmark metrics, including maximum response time and data volume; Perform performance tests to obtain resource utilization and performance metrics; resource utilization includes CPU utilization and memory utilization, and performance metrics include maximum concurrent users, system capacity, response time percentile P90, average response time, and error rate.

4. The software project quality self-adapting management method of claim 1, wherein, The project quality-related knowledge base includes: The AI ​​knowledge base is a database of intelligent experience and case features, storing refined defect patterns, case features, and risk indicator weights to guide AI in attribution analysis and trend prediction. Knowledge graphs structure project processes, quality requirements, and management rules in a graph format, enabling association and rule verification.

5. The software project quality self-adapting management method of claim 4, wherein, The project quality-related knowledge base is dynamically iterated, including periodically inputting, providing feedback to, maintaining, or updating the following content: Instructions and models that are continuously trained provide the impetus for upgrading the AI ​​knowledge base; The experiences and cases extracted after the quality assessment is passed will be used to enrich the AI ​​knowledge base and knowledge graph.

6. The software project quality self-adapting management method of claim 4, wherein, The knowledge graph includes: Key activities of a project define the work packages, tasks and deliverables that need to be completed in the project lifecycle. They are used to compare workflow execution data and confirm whether key activities are completed on time and as required. Quality access control rules stipulate the quality standards that must be met at key activities in each project, and are used to determine whether the process can continue. Project management rules, including institutional documents, include organizational-level project management processes, resource allocation strategies, change control procedures, and document specifications, used to ensure the standardization and compliance of project execution.

7. The software project quality self-adapting management method of claim 4, wherein, The quality assessment includes the following steps: S310. The aggregated project-related data flows through the project quality-related knowledge base, and then parallel online automatic judgment and offline expert judgment are performed. Among them, online automatic judgment is to use AI knowledge base and knowledge graph to conduct automated and real-time evaluation; offline expert judgment is to conduct manual review by experts, and the judgment results are uploaded through the microservice system. S320. The judgment results of online automatic judgment and offline expert judgment, as well as the relevant data of the judged project, are summarized into analysis results to determine whether the current status of the project meets the standards. S330. Perform compliance assessment. If the assessment result is compliant, proceed to the project completion stage. If the assessment result is non-compliant, proceed to the rectification stage. The outputs of the project completion phase include a document quality dashboard, incentive review data, and reusable experiences and cases; the outputs of the rectification phase include dynamic graph analysis results, which include the project achievement status and areas for rectification. S340. If a rectification step was performed in S330, the quality assessment will be triggered again after the rectification is completed, that is, S310 to S330 will be repeated.

8. The software project quality self-adaptive management method of claim 1, wherein, The following two notification mechanisms will be executed in parallel: Automated notifications automatically trigger the start or end of a workflow at preset project nodes; If the workflow is triggered, the corresponding phased quality knowledge graph will be pushed to the relevant roles based on the current project stage. If the workflow is terminated, the output of the project completion stage and / or the content of the rectification stage will be automatically pushed to the relevant roles. Manually triggered notifications can be initiated at any project node throughout the project lifecycle. When a manual click occurs, the microservice system receives and analyzes the click time and, based on the current project stage and / or project status, triggers the corresponding automated notification workflow.

9. The adaptive quality management method for software projects according to claim 1, characterized in that, It also includes the following steps: S400, development management, including: Project execution data collection involves collecting relevant quantitative data during the execution process of each project and summarizing it as input for multi-dimensional capability measurement analysis. Multi-dimensional capability measurement analysis, based on project-specific measurement libraries and capability measurement libraries, performs measurement analysis on the aggregated project quantitative data to generate development plans, and generates organizational strategic countermeasures based on the development plans; Organizational strategy alignment assessment involves reviewing and evaluating organizational strategic responses to obtain results on the adequacy of alignment. The development system is maintained by updating or cultivating organizations based on the results of fit adequacy, and a multi-dimensional development system is established based on organizational updates and / or cultivation.

10. The software project quality adaptive management method according to claim 9, characterized in that, The tissue renewal or tissue culture based on the fit adequacy results includes: If the fit is sufficient, then organizational updates will be carried out, including updating human resource allocation and skill-based job application mappings; If the fit is insufficient, organizational training will be conducted, including establishing organizational baselines and building individual historical records.

Images