An enterprise informatization project whole life cycle management and control and evaluation method

By combining a four-dimensional quality assessment index matrix and a software artifact knowledge graph with a graph convolutional network, the problem of insufficient quality problem identification in existing tools is solved, realizing automated project quality assessment and root cause localization, and reducing the response cycle of manual investigation.

CN122367409APending Publication Date: 2026-07-10FUZHOU HAOXIN ELECTRONIC TECHNOLOGY CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
FUZHOU HAOXIN ELECTRONIC TECHNOLOGY CO LTD
Filing Date
2026-06-10
Publication Date
2026-07-10

AI Technical Summary

Technical Problem

Existing project management tools are unable to identify quality problems within software engineering in a timely manner, the root cause of defects relies on manual investigation, the assessment perspective is limited to surface indicators, and risk identification relies on regular manual review.

Method used

By employing a four-dimensional quality assessment index matrix and a software artifact knowledge graph, a project health index is extracted through a graph convolutional network, generating a risk warning report and triggering automated control measures.

Benefits of technology

It enables automated identification and root cause localization of project quality issues, expands the evaluation perspective to internal software engineering quality, and reduces the response time for manual investigation.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122367409A_ABST
    Figure CN122367409A_ABST
Patent Text Reader

Abstract

This invention specifically relates to a method for full lifecycle management and evaluation of enterprise information technology projects, belonging to the field of information technology project management technology. It includes: generating a software artifact knowledge graph based on software artifact information and its relationships contained in the four-dimensional quality evaluation index matrix, using requirement items, software architecture modules, code files, and test cases as entity nodes, and traceability and dependency relationships between entities as association edges. In this invention, a four-dimensional quality evaluation index matrix covering requirements, software architecture, code, and testing is established, expanding the project evaluation perspective from schedule and workload indicators to quality indicators within software engineering, enabling the quantitative identification of quality problems hidden beneath normal progress appearances.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of information technology project management, and in particular to a method for the full lifecycle management and evaluation of enterprise information technology projects. Background Technology

[0002] As enterprises continue to expand their IT infrastructure, the need for management and control of IT projects is becoming increasingly urgent. Existing project management tools typically assess project status based on metrics such as milestone completion rate, work hours, and lines of code.

[0003] The aforementioned metrics only reflect project progress and workload, failing to reveal the internal quality of software engineering. Specifically, modules ahead of schedule may exhibit high cyclomatic complexity and a large amount of duplicate code; a single requirement change may trigger a chain reaction of modifications to multiple related modules; and code that passes code style checks may contain high-risk technical debt. Such quality issues cannot be identified and warned about in a timely manner using traditional project management tools.

[0004] Furthermore, in existing tools, the requirements management platform, code repository, and test management platform operate independently. When defects are discovered, they cannot be automatically traced back to the corresponding code modification records and the source of the requirements, resulting in root cause localization relying on manual investigation and a long response cycle. Therefore, existing technologies suffer from technical problems such as a quality assessment perspective limited to surface indicators, the inability to automatically trace defect root causes, and the reliance on periodic manual review for risk identification. Summary of the Invention

[0005] The purpose of this invention is to provide a method for the full lifecycle management and evaluation of enterprise information projects in order to solve the above-mentioned problems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A method for full lifecycle management and evaluation of enterprise information technology projects, including: Raw data of quality indicators for requirements, software architecture, code, and testing dimensions were collected from the process management system of the information technology project. The raw data of each dimension were standardized to generate a four-dimensional quality assessment indicator matrix. Based on the software artifact information and its relationships contained in the four-dimensional quality assessment index matrix, a software artifact knowledge graph is generated, with requirement items, software architecture modules, code files and test cases as entity nodes and traceability and dependency relationships between entities as association edges. The attribute features and associated edge information of each entity node in the software artifact knowledge graph are input into a graph convolutional network. The graph convolutional network extracts the aggregated feature representation of each node and performs global pooling to output a comprehensive health index. The scores of each sub-item in the comprehensive health index are compared with preset warning thresholds. When any sub-item score is lower than the corresponding warning threshold, a risk warning report is generated, and corresponding control measures are triggered according to the warning level.

[0007] Preferably, the quality indicators of the requirement dimension include requirement change frequency and cross-requirement conflict index, wherein the requirement change frequency is the ratio of the number of times a requirement item changes within a unit time window to the total number of requirements, and the cross-requirement conflict index is the proportion of requirement pairs with contradictory or overlapping definitions to the total number of requirement pairs; the quality indicators of the software architecture dimension include module coupling degree and interface version drift rate, wherein the module coupling degree is calculated based on the fan-in coefficient and fan-out coefficient of each module, and the interface version drift rate is the proportion of the number of interfaces whose actual version is inconsistent with the agreed baseline version to the total number of interfaces.

[0008] Preferably, the quality indicators of the demand dimension further include a demand ambiguity score, which is obtained by: inputting the description text of each demand item into a pre-trained natural language processing model, which identifies and quantifies the uncertain expressions in the demand description and outputs the demand ambiguity score for each demand item; wherein, the uncertain expressions include ambiguous qualifying words, descriptive statements lacking quantitative standards, and terms with ambiguity; the natural language processing model adopts a supervised training method, using manually labeled demand ambiguity tags as supervision signals for training.

[0009] Preferably, the generation of the software artifact knowledge graph includes: extracting each requirement item, software architecture module, code file, and test case as entity nodes, and writing the standardized quality index value corresponding to each entity node as a node attribute into the graph database; generating derived type association edges based on the mapping relationship between requirement items and software architecture modules, generating implementation type association edges based on the implementation relationship between software architecture modules and code files, and generating verification type association edges based on the verification relationship between code files and test cases; generating call type association edges and dependency type association edges based on the call relationship and dependency relationship between code files, and generating sequence association edges based on the precondition relationship between test cases.

[0010] Preferably, when a new defect is recorded in the test management platform, the test case node associated with the defect is used as the starting node, and the software artifact knowledge graph is traversed backward along the associated edge to sequentially locate the corresponding code file node, code modification record, software architecture module node, and requirement item node, generating a complete traceability chain from defect to requirement; the complete traceability chain is output in the form of an ordered node list, and each node in the list is accompanied by the corresponding quality indicator value and timestamp information.

[0011] Preferably, in each graph convolutional layer, the graph convolutional network performs element-wise mean aggregation on the feature representations of all neighboring nodes of each node in the current layer. After linear transformation of the aggregation result through a learnable weight matrix and adding a bias vector, the feature representation of the node in the next layer is generated through an activation function. The graph convolutional network performs global pooling on the aggregated feature representations of all nodes to generate graph embedding vectors, which are then mapped and output through a fully connected layer to produce the comprehensive health index. The comprehensive health index includes functional health score, progress health score, quality health score, and team effectiveness health score, with each score ranging from 0 to 1.

[0012] Preferably, the warning thresholds include a primary warning threshold and a secondary warning threshold, wherein the primary warning threshold is higher than the secondary warning threshold; when any sub-item score is lower than the corresponding primary warning threshold but higher than the corresponding secondary warning threshold, the dimension corresponding to that score is marked as a primary risk dimension and a primary risk warning is triggered; when any sub-item score is lower than the corresponding secondary warning threshold, the dimension corresponding to that score is marked as a secondary risk dimension and a secondary risk warning is triggered; the risk warning report includes a risk dimension identifier, the current score, associated abnormal indicator items, and a traceability chain.

[0013] Preferably, after generating the risk warning report, the entity node that triggered the warning is used as the starting node, and the software artifact knowledge graph is traversed forward along the associated edges to obtain a set of downstream nodes that have a direct or indirect dependency relationship with the entity node that triggered the warning; the current quality index value of each node in the set of downstream nodes is evaluated, and if there is a downstream node whose quality index value is less than the warning threshold by a preset deviation value, the downstream node is marked as a potential risk node, and the potential risk propagation path is added to the risk warning report.

[0014] Preferably, the process further includes: acquiring four-dimensional quality assessment index data and corresponding final project outcome data of historical completed projects; using the four-dimensional quality assessment index data of historical completed projects as input features and the risk occurrence labels in the final project outcome data as supervision signals to train a risk prediction classifier; inputting the comprehensive health index and four-dimensional quality assessment index data of the current project into the trained risk prediction classifier, and outputting the risk probability values ​​of each module and each process; when the risk probability value exceeds a preset probability threshold, marking the corresponding module or process as a high-risk item and including it in the risk warning report.

[0015] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention expands the project evaluation perspective from schedule and workload indicators to internal quality indicators of software engineering by establishing a four-dimensional quality assessment index matrix covering four dimensions: requirements, software architecture, code, and testing. This enables quality problems hidden beneath the surface of normal progress to be quantitatively identified.

[0016] 2. This invention establishes a software artifact knowledge graph, integrating requirements, software architecture modules, code files, and test cases scattered across various management platforms, along with their interrelationships, into a unified graph structure. When a defect is discovered, it can automatically trace back to the corresponding code modification record and the source of the requirement along the associated edges, thereby transforming manual investigation into automated root cause localization. Attached Figure Description

[0017] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0018] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement this application. This application may be embodied in many different forms and for various purposes and should not be limited to the embodiments set forth herein. These embodiments are provided to make this application thorough and complete, and to fully convey the scope of this application to those skilled in the art. The embodiments described do not limit this application.

[0019] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0020] Example 1

[0021] Its specific implementation method is combined with the appendix Figure 1 Please provide a detailed explanation.

[0022] In this embodiment, it includes: Step 1: Obtain the four-dimensional quality assessment index data for the information technology project.

[0023] Raw data of quality indicators for requirements, software architecture, code, and testing dimensions are collected from the process management system of the information technology project. The raw data for each dimension are then Z-score standardized to generate a four-dimensional quality assessment indicator matrix.

[0024] Step 1 may specifically include: Step S101: Obtain change records, requirement description texts, and relationships between requirements from the requirement management platform, and calculate the requirement change frequency and cross-requirement conflict index.

[0025] Step S102: Obtain module partitioning information, interface definitions, and inter-module call records from the version control system and software architecture management tools, and calculate module coupling degree and interface version drift rate. The module coupling degree is calculated based on the fan-in and fan-out coefficients of each module.

[0026] Step S103: Obtain the commit records and static analysis results of each code file from the code repository, and obtain the code style compliance, cyclomatic complexity, duplicate code rate, and technical debt quantification score.

[0027] Step S104: Obtain test case execution results, defect records, and defect repair time information from the test management platform, and calculate unit test coverage, integration test pass rate, defect escape rate, and average defect repair time.

[0028] It should be noted that the requirement change frequency is the ratio of the number of times a requirement item changes within a unit time window to the total number of requirements, where the time window length is configured according to the project iteration cycle. The cross-requirement conflict index is the proportion of requirement pairs with contradictory or overlapping definitions to the total number of requirement pairs. The interface version drift rate is the proportion of interfaces whose actual version differs from the agreed baseline version to the total number of interfaces. The technical debt quantification score is obtained by weighted summation of the number and severity levels of items to be fixed output by the code static analysis tool. The defect escape rate is the ratio of the number of defects discovered during integration testing and subsequent phases that should have been caught during unit testing to the total number of defects.

[0029] In this embodiment, to obtain more accurate ambiguity assessment results, in step S101, the descriptive text of each requirement item is input into a pre-trained natural language processing (NLP) model. The NLP model identifies and quantifies the uncertainty expressions in the requirement descriptions and outputs a requirement ambiguity score for each requirement item. Uncertainty expressions include ambiguous qualifying words, descriptive statements lacking quantification standards, and terms with multiple meanings. The NLP model employs supervised training, using manually labeled requirement ambiguity tags as supervision signals. The output layer is a fully connected layer, using the cross-entropy loss function, and the parameters are updated using the Adam optimization algorithm. The requirement ambiguity score is incorporated as a supplementary indicator of the requirement dimension into the four-dimensional quality assessment indicator matrix and is also standardized by Z-score before participating in subsequent calculations.

[0030] Step 2: Generate a knowledge graph of software artifacts throughout the entire lifecycle of the information technology project.

[0031] Based on the software artifact information and their relationships contained in the four-dimensional quality assessment index data, a software artifact knowledge graph is established. The software artifact knowledge graph uses requirement items, software architecture modules, code files, and test cases as entity nodes, and traceability and dependency relationships between entities as association edges. The entity nodes and association edges are stored in a graph database to generate a searchable software artifact knowledge graph.

[0032] Step 2 may specifically include: Step S201: Extract each requirement item, software architecture module, code file and test case into entity nodes, and write the standardized quality index value corresponding to each entity node into the graph database as node attribute.

[0033] Step S202: Based on the mapping relationship between requirement items and software architecture modules, the implementation relationship between software architecture modules and code files, and the verification relationship between code files and test cases, directed association edges are generated between the corresponding entity nodes, and the type label of the association edges is written into the graph database.

[0034] Step S203: Based on the calling and dependency relationships between code files, generate dependency association edges between code file nodes; based on the precondition relationships between test cases, generate sequence association edges between test case nodes.

[0035] It should be noted that the types of associated edges include "Derivative", "Implementation", "Verification", "Invocation", and "Dependency". Among them, "Derivative" represents the tracing relationship from a requirement item to a software architecture module; "Implementation" represents the mapping relationship from a software architecture module to a code file; "Verification" represents the test coverage relationship of test cases on code files; "Invocation" and "Dependency" represent the runtime invocation relationship and compile-time dependency relationship between code files, respectively.

[0036] In this embodiment, to achieve automatic root cause tracing of defects, based on the association edges generated in steps S202 and S203, when a new defect is recorded in the test management platform, the test case node associated with the defect is used as the starting node. The software artifact knowledge graph is traversed backward along the association edges to sequentially locate the corresponding code file node, code modification record, software architecture module node, and requirement item node, generating a complete traceability chain from defect to requirement. The complete traceability chain is output in the form of an ordered list of nodes, with each node in the list accompanied by corresponding quality indicator values ​​and timestamp information.

[0037] Step 3: Calculate the comprehensive health index of the information technology project based on the knowledge graph of software artifacts.

[0038] The attribute features and associated edge information of each entity node in the software artifact knowledge graph are input into a graph convolutional network. The graph convolutional network extracts the aggregated feature representation of each node and outputs a comprehensive health index at the project level.

[0039] The input layer of a graph convolutional network receives node feature vectors composed of standardized quality index values ​​for each entity node, and edge features composed of type and direction encodings for associated edges. Graph convolutional networks use the adjacency structure of a software artifact knowledge graph for message passing. In each graph convolutional layer, nodes... Aggregation feature representation Calculated by the following formula: ; in, For nodes In the Layer feature representation, This refers to the layer index of the graph convolutional layer. For nodes In the Layer feature representation, For nodes The neighboring nodes, For nodes The set of neighboring nodes, Neighboring nodes In the Layer feature representation, and The first The learnable weight matrix and bias vector of the layer, For activation function, This is a feature aggregation function for neighbors. For nodes All neighboring nodes The Layer feature representation Perform the element-wise mean operation, that is: ; in, For the set of neighboring nodes The graph convolutional network (GCNN) performs global pooling on the aggregated feature representations of all nodes to generate project-level graph embedding vectors. These vectors are then mapped through fully connected layers to output a comprehensive health index. The comprehensive health index includes functional health scores, schedule health scores, quality health scores, and team effectiveness health scores. Each score is a real number output after a linear transformation by the fully connected layer, and its value range is constrained to 0-1 by the activation function of the output layer. Higher values ​​indicate better health in the corresponding dimension. The GCNN uses historical project health-labeled data as supervision signals, employs a mean squared error loss function, and is trained using the Adam optimization algorithm.

[0040] It should be noted that the functional health score reflects the completeness of requirement implementation and the impact of requirement changes on existing functions. The schedule health score reflects the on-time completion of deliverables at each stage and the smoothness of transitions between stages. The quality health score reflects the combined performance of code and testing metrics. The team effectiveness health score reflects the speed of defect repair response and the execution of code reviews.

[0041] In this embodiment, since the nodes and edges in the software artifact knowledge graph are continuously updated as the project progresses, when a new entity node or associated edge is added to the software artifact knowledge graph, step 3 is re-executed to generate an updated comprehensive health index. By continuously recording the comprehensive health index at multiple time points, a time-series change sequence of the project's health is generated for subsequent trend analysis and risk prediction.

[0042] Step 4: Generate risk warnings and trigger control measures based on the comprehensive health index.

[0043] The scores of each sub-item in the comprehensive health index are compared with the preset warning thresholds. When any sub-item score is lower than the corresponding warning threshold, a risk warning report is generated, and corresponding control measures are triggered according to the warning level.

[0044] Step 4 may specifically include: Step S401: Obtain the pre-configured set of warning thresholds, and compare the functional health score, progress health score, quality health score, and team effectiveness health score with their respective warning thresholds.

[0045] Step S402: When any score is lower than the corresponding first-level warning threshold, the dimension corresponding to the score is marked as a first-level risk dimension, and a risk warning report containing the risk dimension identifier, the current score, the associated abnormal indicator items, and the traceability chain is generated; when any score is lower than the corresponding second-level warning threshold, the dimension corresponding to the score is marked as a second-level risk dimension, and the warning level is upgraded in the risk warning report.

[0046] It should be noted that the Level 1 warning threshold is higher than the Level 2 warning threshold. The Level 1 warning threshold corresponds to mild risk, while the Level 2 warning threshold corresponds to moderate risk. A Level 1 risk warning is triggered when the score is below the Level 1 warning threshold but above the Level 2 warning threshold; a Level 2 risk warning is triggered when the score falls further below the Level 2 warning threshold.

[0047] Step S403: Based on the warning level in the risk warning report, match the corresponding control measures from the preset control measure library and trigger their execution. For example, control measures triggered by a level 1 risk warning include pushing risk alerts to the project manager and increasing the frequency of quality indicator collection for that dimension; control measures triggered by a level 2 risk warning include forcibly increasing code review rounds and suspending the deployment process of high-risk modules.

[0048] In this embodiment of the application, in order to predict the spread of risk after a single node triggers an early warning, the following steps are also included: based on the association edge relationship in the software artifact knowledge graph, taking the entity node that triggers the early warning as the starting node, traversing the software artifact knowledge graph in the forward direction along the association edge to obtain a set of downstream nodes that have a direct or indirect dependency relationship with the entity node that triggers the early warning; evaluating the current quality index value of each node in the downstream node set, and if there is a downstream node whose quality index value is close to the early warning threshold, marking the downstream node as a potential risk node, and supplementing the potential risk propagation path in the risk early warning report.

[0049] In this embodiment, to improve the accuracy of risk prediction, based on step S401, four-dimensional quality assessment index data of historical completed projects and corresponding project final result data are also acquired. The four-dimensional quality assessment index data of historical completed projects is used as input features, and the risk occurrence label in the project final result data is used as a supervision signal to train a risk prediction classifier. The input layer of the risk prediction classifier receives a feature vector formed by concatenating the comprehensive health index and the four-dimensional quality assessment index data. The output layer is a fully connected layer, which outputs the risk probability value of each module and each process after passing through a sigmoid activation function. The value ranges from 0 to 1; a higher value indicates a greater probability of risk occurring in the corresponding module or process. A binary cross-entropy loss function is used, and gradient descent is employed for training. The comprehensive health index and four-dimensional quality assessment index data of the current project are input into the trained risk prediction classifier, which outputs the risk probability value of each module and each process. When the risk probability value exceeds a preset probability threshold, the corresponding module or process is marked as a high-risk item and included in the risk warning report.

[0050] In this embodiment, to ensure the authenticity and traceability of the quality assessment data, when acquiring the original data for each dimension in step 1, a hash digest value is calculated for the execution record of each task node, and the hash digest value is written into the smart contract on the blockchain for notarization. In step 4, when generating the risk warning report, a consistency check is performed between the indicator data referenced in the risk warning report and the hash digest value notarized on the blockchain. If the check fails, the indicator data is marked as questionable in the risk warning report.

[0051] In this embodiment, to protect sensitive data in multi-role collaborative review scenarios, zero-knowledge proofs are used to anonymize quality assessment data that needs to be shared across roles. Each participant verifies whether the quality indicator values ​​meet preset compliance conditions without obtaining the original data, thereby achieving cross-role collaborative review.

[0052] In this embodiment, to achieve continuous accumulation and reuse of project management experience, the following steps are included after project acceptance: Obtaining actual project outcome data, including actual cost, actual cycle time, post-launch defect rate, and user satisfaction rating; performing correlation analysis between the actual outcome data and the four-dimensional quality assessment indicator data and management measure execution records recorded throughout the entire lifecycle, identifying management measures implemented before positive changes in indicators and marking them as effective practices, and identifying situations where indicators continue to deteriorate but are not addressed in a timely manner and marking them as items to be improved; writing effective practices and items to be improved into an experience knowledge base in the form of structured entries; and when a new project is launched, based on the initial requirements and technology stack information of the new project, retrieving effective practice entries from similar historical projects from the experience knowledge base, and recommending corresponding management strategies and risk avoidance measures to the project leader.

[0053] Example 2

[0054] A certain e-government platform launched an iterative development project for its e-government data sharing system (project code: GOV-DSS-02) in QB of 20XX. This project comprises four software architecture modules: data aggregation, access control, interface services, and data governance. It is currently in its third iteration cycle. The project team used this method to assess and provide early warnings regarding the project's health status.

[0055] The execution process of step 1: Raw indicator data across four dimensions were collected from the requirements management platform, version control system, code repository, and test management platform. In the requirements dimension, the frequency of requirement changes in the access control module was significantly high, and the natural language processing model output a high requirement ambiguity score for the two requirement descriptions of this module. This was attributed to the inclusion of expressions lacking quantitative standards, such as "appropriate permission granularity." In the code dimension, the cyclomatic complexity and technical debt quantification scores for the interface service module were both high. After Z-score standardization of each raw value, a four-dimensional quality assessment indicator matrix was generated.

[0056] Table 1. Original data and standardized results of the four-dimensional quality assessment indicators

[0057] The execution process of step 2: Based on the software artifact information collected in step 1, the project's requirements, software architecture modules, code files, and test cases are extracted as entity nodes. Standardized quality indicator values ​​are written as node attributes into the graph database. Then, directed edges are generated between the entity nodes. The requirement item "REQ-AUTH-07" points to the access control module node via a "derive" edge; the access control module node points to the code file "auth_core.py" node via an "implementation" edge; and the "auth_core.py" node points to the test case "TC-AUTH-023" node via a "verification" edge. Compilation dependencies between code files generate "dependency" edges, and runtime call relationships generate "call" edges.

[0058] During the third iteration, the test management platform recorded a new defect (defect number: BUG-0341), associated with the test case "TC-AUTH-023". Starting from the "TC-AUTH-023" node, the knowledge graph was traversed backwards along the associated edges, sequentially locating the "auth_core.py" code file node, the corresponding code commit record (commit number: COMMIT-b7f3a), the access control module node, and the requirement item "REQ-AUTH-07" node, generating a complete traceability chain.

[0059] Table 2 Root Cause Tracing Chain of Defect BUG-0341

[0060] The execution process of step 3: The standardized quality index values ​​of each node in the software artifact knowledge graph are used to form a node feature vector. This vector, along with the type and direction encoding of associated edges, is then input into a graph convolutional network. Taking the access control module node as an example, its neighbor node set... This includes the requirement item node "REQ-AUTH-07" and the code file node "auth_core.py". The graph convolutional network performs element-wise mean aggregation on the feature representations of neighboring nodes at each layer. After processing the aggregation result through weight matrix transformation and activation function, it updates the aggregated feature representation of the access control module node. After two layers of graph convolution, the aggregated features of the access control module nodes have incorporated the quality status information of upstream requirements and downstream code files. Global pooling is then performed on the aggregated features of all nodes to generate project-level graph embedding vectors, which are then mapped through a fully connected layer to output a comprehensive health index.

[0061] Table 3. Output Results of the Comprehensive Health Index

[0062] The progress health score remained stable, but the quality health score decreased from 0.58 to 0.43, and both functional health and team effectiveness health scores also declined. This result reflects the role of graph convolutional networks in aggregating neighbor information: the high cyclomatic complexity of the interface service module and the high demand ambiguity of the access control module, through the association edges in the knowledge graph, affected the aggregation characteristics of adjacent nodes, ultimately leading to a simultaneous decrease in quality health and functional health scores, rather than reflecting only the isolated state of a single module.

[0063] The execution process of step 4: Compare the scores for each item in Table 3 with the preset warning thresholds. The first-level warning threshold for functional health is 0.65, and the second-level warning threshold is 0.50; the first-level warning threshold for quality health is 0.60, and the second-level warning threshold is 0.45; the first-level warning threshold for team effectiveness health is 0.60, and the second-level warning threshold is 0.45. The current functional health score of 0.61 is lower than the first-level warning threshold of 0.65, triggering a first-level risk warning; the current quality health score of 0.43 is lower than the second-level warning threshold of 0.45, triggering a second-level risk warning.

[0064] The risk prediction classifier receives a feature vector formed by concatenating data from the comprehensive health index and the four-dimensional quality assessment indicators, and outputs the risk probability value for each module. The risk probability value output for the access control module is 0.79, which exceeds the preset probability threshold of 0.70, so it is marked as a high-risk item and included in the risk warning report.

[0065] Starting with the “auth_core.py” node that triggered the warning, the knowledge graph was traversed forward along the “call” and “dependency” association edges. It was found that the “api_gateway.py” node in the interface service module has a direct call relationship with “auth_core.py”. Its technical debt quantitative score standardized value is 1.61, which is close to the first-level warning threshold, and it is marked as a potential risk node.

[0066] Table 4 Summary of Risk Warning Report

[0067] In the blockchain evidence storage phase, the hash digest values ​​of the execution records of each task node collected in step 1 have been written into the smart contract. When generating the risk warning report shown in Table 4, a consistency check is performed on the quality and health indicator data referenced in the report and the on-chain hash digest values. If the check passes, all indicator data in the report are marked as verified.

[0068] Throughout the execution process, data begins with the raw indicator collection in Step 1. After Z-score standardization, a four-dimensional quality assessment indicator matrix is ​​formed and written as node attributes into the software artifact knowledge graph in Step 2. The graph structure and node attributes of the knowledge graph serve as input to the graph convolutional network in Step 3, and after neighbor feature aggregation, a comprehensive health index is output. In Step 4, the comprehensive health index is compared with the warning threshold, combined with the risk probability value of the risk prediction classifier and the potential risk propagation path, to finally form a risk warning report containing traceability chains and control measures. The standardized values ​​in Table 1 directly correspond to the quality indicators in the traceability chain in Table 2. The quality problems of the access control module exposed in the traceability chain in Table 2 directly affect the functional health and quality health scores in Table 3. The changes in the scores in Table 3 ultimately drive the warning level determination and control measures triggering in Table 4. The data flow between each step forms a complete closed loop.

[0069] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0070] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

Claims

1. A method for full lifecycle management and evaluation of enterprise information technology projects, characterized in that, include: Raw data of quality indicators for requirements, software architecture, code, and testing dimensions were collected from the process management system of the information technology project. The raw data of each dimension were standardized to generate a four-dimensional quality assessment indicator matrix. Based on the software artifact information and its relationships contained in the four-dimensional quality assessment index matrix, a software artifact knowledge graph is generated, with requirement items, software architecture modules, code files and test cases as entity nodes and traceability and dependency relationships between entities as association edges. The attribute features and associated edge information of each entity node in the software artifact knowledge graph are input into a graph convolutional network. The graph convolutional network extracts the aggregated feature representation of each node and performs global pooling to output a comprehensive health index. The scores of each sub-item in the comprehensive health index are compared with preset warning thresholds. When any sub-item score is lower than the corresponding warning threshold, a risk warning report is generated, and corresponding control measures are triggered according to the warning level.

2. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 1, characterized in that, The quality metrics for the requirement dimension include requirement change frequency and cross-requirement conflict index. The requirement change frequency is the ratio of the number of requirement items that change within a unit time window to the total number of requirements. The cross-requirement conflict index is the proportion of requirement pairs with contradictory or overlapping definitions to the total number of requirement pairs. The quality metrics for the software architecture dimension include module coupling degree and interface version drift rate. The module coupling degree is calculated based on the fan-in and fan-out coefficients of each module. The interface version drift rate is the proportion of the number of interfaces whose actual version is inconsistent with the agreed baseline version to the total number of interfaces.

3. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 1, characterized in that, The quality indicators for the demand dimension also include demand ambiguity scores, which are obtained as follows: the descriptive text of each demand item is input into a pre-trained natural language processing model, which identifies and quantifies the uncertain expressions in the demand description and outputs the demand ambiguity score for each demand item; wherein, the uncertain expressions include ambiguous qualifying words, descriptive statements lacking quantitative standards, and terms with ambiguity; the natural language processing model adopts a supervised training method, using manually labeled demand ambiguity tags as supervision signals for training.

4. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 1, characterized in that, The process of generating a software artifact knowledge graph includes: extracting each requirement item, software architecture module, code file, and test case as entity nodes, and writing the standardized quality indicator values ​​corresponding to each entity node as node attributes into the graph database; generating derived type association edges based on the mapping relationship between requirement items and software architecture modules, generating implementation type association edges based on the implementation relationship between software architecture modules and code files, and generating verification type association edges based on the verification relationship between code files and test cases; generating call type association edges and dependency type association edges based on the call relationship and dependency relationship between code files, and generating sequence association edges based on the precondition relationship between test cases.

5. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 4, characterized in that, When a new defect is recorded in the test management platform, the test case node associated with the defect is used as the starting node. The software artifact knowledge graph is traversed backward along the associated edge to locate the corresponding code file node, code modification record, software architecture module node, and requirement item node in sequence, generating a complete traceability chain from defect to requirement. The complete traceability chain is output in the form of an ordered list of nodes, with each node in the list accompanied by the corresponding quality indicator value and timestamp information.

6. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 1, characterized in that, In each graph convolutional layer, the graph convolutional network performs element-wise mean aggregation on the feature representations of all neighboring nodes of each node in the current layer. The aggregation result is then linearly transformed by a learnable weight matrix and a bias vector is added. Finally, an activation function is used to generate the feature representation of the node in the next layer. The graph convolutional network performs global pooling on the aggregated feature representations of all nodes to generate graph embedding vectors, which are then mapped through a fully connected layer to output the comprehensive health index. The comprehensive health index includes functional health score, schedule health score, quality health score and team effectiveness health score, with each score ranging from 0 to 1.

7. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 1, characterized in that, The warning thresholds include a primary warning threshold and a secondary warning threshold, wherein the primary warning threshold is higher than the secondary warning threshold. When any sub-item score is lower than the corresponding primary warning threshold but higher than the corresponding secondary warning threshold, the dimension corresponding to that score is marked as a primary risk dimension and a primary risk warning is triggered. When any sub-item score is lower than the corresponding secondary warning threshold, the dimension corresponding to that score is marked as a secondary risk dimension and a secondary risk warning is triggered. The risk warning report includes a risk dimension identifier, the current score, associated abnormal indicator items, and a traceability chain.

8. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 7, characterized in that, After generating the risk warning report, the software artifact knowledge graph is traversed in the forward direction along the associated edges, starting from the entity node that triggered the warning, to obtain the set of downstream nodes that have a direct or indirect dependency relationship with the entity node that triggered the warning. The current quality index values ​​of each node in the downstream node set are evaluated. If there is a downstream node whose quality index value is less than the pre-set deviation value, the downstream node is marked as a potential risk node, and the potential risk propagation path is added to the risk warning report.

9. The method for full lifecycle management and evaluation of enterprise information technology projects according to claim 1, characterized in that, Also includes: Obtain the four-dimensional quality assessment index data and corresponding final project data of historical completed projects. Use the four-dimensional quality assessment index data of the historical completed projects as input features and the risk occurrence label in the final project data as supervision signal to train a risk prediction classifier. Input the comprehensive health index and four-dimensional quality assessment index data of the current project into the trained risk prediction classifier and output the risk probability value of each module and each process. When the risk probability value exceeds the preset probability threshold, the corresponding module or process is marked as a high-risk item and included in the risk warning report.