Computer software development information management system and method

Abstract

The invention relates to the technical field of software engineering management, and discloses a computer software development information management system and method. According to the method, real-time multi-dimensional association among four entities, namely a demand entity, a code entity, a test entity and a deployment entity is realized by constructing a dynamic knowledge graph center, and an end-to-end closed-loop control system is formed; a full-link traceable network is dynamically established through explicit binding, implicit capturing and cross-layer traceability mechanisms, demand omission marks are automatically repaired, and accurate attribution of environmental problems is achieved; manual operation blind areas are eliminated through automatic means such as developing and submitting forced association, automatically freezing branches when test fails and deploying environment consistency verification; based on a risk thermodynamic diagram of full-link topology penetration and fusion defect density and change frequency, active early warning of a high-risk module is realized, and controllability and quality assurance capability of a software development process are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software engineering management, in particular to a computer software development information management system and method. BACKGROUND

[0002] The current mainstream software development management system adopts a separated tool chain combination to realize requirement management, version control, test execution and deployment operation, for example, splitting requirement entries and generating requirement IDs through JIRA, managing submission records through a code repository such as GitLab and manually marking and associating requirement identifiers, triggering automated testing through Jenkins and generating test reports, and completing containerized deployment through Kubernetes; there are also some integrated solutions in the prior art, such as a requirement-test case mapping table based on a traditional relational database, or an automated process from code submission to deployment through a CI / CD pipeline, some solutions try to introduce a basic graph technology to build a static association network of requirements and code modules, or use a configuration management tool (such as Ansible) to ensure the consistency of environment templates in the deployment stage.

[0003] However, the prior art still has problems:

[0004] The broken traceability chain specifically shows that the dependency relationship among requirements, code, test and deployment entities needs to be manually spliced across multiple independent systems, developers are prone to miss requirement ID markers when submitting code, leading to disconnection between requirements and code implementation, test results and requirement status changes are not synchronized, and the consistency of the environment cannot be automatically verified in the deployment stage; at the same time, the lack of real-time feedback shows that the traditional static association graph cannot dynamically respond to changes in development behavior, manual defect tickets need to be created and code branches need to be manually frozen when testing fails, and environment configuration deviations are only passively discovered after deployment fails; in addition, the risk control lag shows that there is a lack of a global risk quantification model that integrates code defect density and requirement change frequency, the existing dashboard only displays isolated test pass rate or deployment success rate indicators, and cannot generate a dynamic risk heat map that penetrates the entire requirement-code-test-deployment chain to realize proactive early warning of high module risk, therefore, a computer software development information management system and method are proposed. SUMMARY

[0005] In view of the deficiencies of the prior art, the present application provides a computer software development information management system and method to solve the problems in the background art.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical solutions:

[0007] In a first aspect, a computer software development information management system comprises:

[0008] Dynamic knowledge graph hub: Real-time construction and maintenance of multi-dimensional association network among requirement entities, code entities, test entities, and deployment entities;

[0009] Requirement structuring unit: connected to the dynamic knowledge graph hub, used to decompose raw requirements into atomic items (i.e., indivisible minimum requirement units) and generate unique identifiers with version traceability chains for each item;

[0010] Development behavior perception unit: connected to the dynamic knowledge graph hub, automatically extracts requirement identifiers and defect numbers in commit notes by analyzing commit records of code repositories, and establishes binding relationships between code commit nodes and requirement items;

[0011] Test closed-loop feedback unit: bidirectionally connected to the dynamic knowledge graph hub, performs:

[0012] Receives test result data and dynamically updates the status (pass / fail / block) of associated requirement items;

[0013] When the status becomes failed, automatically triggers defect node creation and freezes the merge permissions of the associated code branch;

[0014] Deployment consistency anchoring unit: connected to the dynamic knowledge graph hub, performs:

[0015] Generates a cryptographic hash fingerprint of the runtime environment configuration;

[0016] Compares the production environment fingerprint with the test baseline fingerprint, and if the deviation exceeds the threshold, interrupts the deployment and issues an alarm;

[0017] Full-link visualization engine: connected to the dynamic knowledge graph hub, obtains associated network data from the dynamic knowledge graph hub in real time, and generates:

[0018] Requirement-code-test-deployment topology graph with penetrable traceability;

[0019] Risk heat map that integrates development unit defect data and requirement unit change frequency.

[0020] Preferably, the dynamic knowledge graph hub maintains the association network by:

[0021] Explicit association channel: parses the mapping relationship between requirement identifiers and code commit IDs submitted by the development behavior perception unit;

[0022] Implicit association channel: binds unassociated code to requirement items by monitoring test coverage paths through code instrumentation;

[0023] Cross-layer traceability channel: when the deployment consistency anchoring unit detects fingerprint deviation, trace back associated test cases and requirement items based on stack characteristics.

[0024] Preferably, the development behavior perception unit comprises:

[0025] Semantic parser: adopts a BERT-based natural language processing model to extract requirement identifiers and bug numbers from code comments;

[0026] Association enforcement gateway: blocks code into the repository and pushes a completion instruction to the developer terminal for submissions that do not contain the identifier.

[0027] Preferably, the test closed-loop feedback unit, when the requirement status is updated to failure:

[0028] Automatically creates a bug node and associates it to the corresponding requirement item and code module;

[0029] Drives the test case library to generate a regression verification task queue until the bug is closed.

[0030] Preferably, the cryptography hash fingerprint generation in the deployment consistency anchoring unit comprises:

[0031] Recursive hash calculation is performed on the operating system kernel version, dependency library list, and container image level; the test environment benchmark fingerprint is stored in an encrypted database.

[0032] Preferably, the risk heat map generation logic of the full-link visualization engine is:

[0033] Calculate the defect density of the code module: where D represents the total number of historical defects of the module, and L represents the number of lines of code of the module;

[0034] Statistical change frequency of requirement items: where N represents the number of version iterations of the requirement within the time window, and T represents the statistical time window length (unit: weeks);

[0035] Generate a risk score: R = α·δ + β·γ, where α is the defect density weight coefficient (α > 0), β is the change frequency weight coefficient (β > 0), and α + β = 1;

[0036] According to the R value, map to the red-yellow-green three-color risk map.

[0037] Preferably, the implicit association channel performs:

[0038] When the test coverage analysis finds that the newly added code has no associated requirements, automatically create a to-be-confirmed requirement node;

[0039] Before the next development iteration cycle begins, it is mandatory to supplement the requirement document or mark the obsolete code.

[0040] Preferably, when the deployment environment fingerprint deviation is over the threshold:

[0041] Automatically positioning the environment change person in charge and the operation timestamp;

[0042] Reconstructing the sandbox environment according to the test benchmark fingerprint, and performing the smoke test of the module associated with the current deployment version.

[0043] Preferably, the test environment benchmark fingerprint output by the test closed-loop feedback unit comprises:

[0044] The operating system kernel version hash value, the dependent library recursive hash tree and the container image level check.

[0045] In the second aspect, a computer software development information management method is provided, which is realized based on the computer software development information management system in the first aspect, and comprises the following steps:

[0046] The dynamic graph construction step comprises the following steps:

[0047] The requirement structuring unit generates atomic items and unique identifiers, and injects the knowledge graph;

[0048] The development behavior perception unit scans the code submission, and creates a requirement-code association edge;

[0049] The closed-loop control step comprises the following steps:

[0050] The test closed-loop feedback unit updates the requirement state, and freezes the abnormal code branch;

[0051] The deployment consistency anchoring unit verifies the environment fingerprint consistency, and blocks the non-compatible deployment;

[0052] The visualization driving step comprises the following steps:

[0053] The full-link visualization engine renders a topology graph and a risk heat map in real time.

[0054] Compared with the prior art, the application has the following beneficial effects:

[0055] The application realizes real-time multi-dimensional association among the four entities of requirements, codes, tests and deployments through the construction of a dynamic knowledge graph hub, forms an end-to-end closed-loop control system, dynamically establishes a full-link traceable network through explicit binding, implicit capture and cross-layer tracing mechanisms, automatically repairs requirement omission marks and realizes accurate attribution of environment problems, eliminates the blind area of manual operation through development submission forced association, test failure automatic freezing branch, deployment environment consistency verification and other automatic means, realizes active early warning of high-risk modules based on the risk heat map of defect density and change frequency through full-link topology penetration and fusion, and significantly improves the controllability and quality assurance capability of the software development process.

[0056] Other features and advantages of the present application will be set forth in the following description, and in part will be apparent from the description, or can be learned by practice of the application. The objects and other advantages of the application will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings. BRIEF DESCRIPTION OF DRAWINGS

[0057] Figure 1 is a system architecture diagram of the present application;

[0058] Figure 2 is a multi-dimensional association channel architecture diagram of the present application;

[0059] Figure 3 is a development behavior perception flow diagram of the present application;

[0060] Figure 4 is a test closed-loop control flow diagram of the present application;

[0061] Figure 5 is a deployment verification flow diagram of the present application;

[0062] Figure 6 is a visualization engine output flow of the present application. DETAILED DESCRIPTION

[0063] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0064] Please refer to Figures 1-6 , a computer software development information management system and method in the present application, the present application forms a full-link trace cornerstone by constructing a real-time association network of requirements, code, test, and deployment entities in a dynamic knowledge graph hub (using a Neo4j graph database). The requirement structuring unit decomposes atomic requirements and generates version trace chains; the development behavior perception unit analyzes submission records to bind requirements and code; the test closed-loop feedback unit dynamically updates the state and freezes abnormal branches; the deployment consistency anchoring unit verifies environmental consistency through cryptography hashing; and the full-link visualization engine generates topology graphs and risk heat maps. Each unit works cooperatively through event-driven, and specifically includes the following contents:

[0065] I. Dynamic knowledge graph hub implementation

[0066] A real-time association network of four types of entities (requirements R / code C / test T / deployment D) is constructed, supporting three types of association channels: explicit / implicit / cross-layer.

[0067] 1. Entity definition and multi-dimensional association implementation

[0068] 1) Entity modeling: To build the association network, the system clearly defines four categories of core entities and their key attributes:

[0069] Requirement: Requirement(id, status, version_chain)

[0070] id: Unique identifier of atomic entry generated by requirement structuring unit (format: REQ-Project ID.Parent Requirement ID.Sequence Number@Version Number, such as REQ-5.1.3@v1.2).

[0071] status: Status dynamically updated by test closed-loop feedback unit (DEV / TESTING / PASS / FAIL / BLOCKED).

[0072] version_chain: Version traceability chain recording requirement change history, using Merkle tree structure to store hash value, ensuring tamper resistance.

[0073] Code: Code(commit_id, branch, path, author)

[0074] commit_id: Unique hash identifier of code repository submission.

[0075] branch: Branch where the code is located.

[0076] path: Code file path.

[0077] author: Committer.

[0078] Test: Test(test_id, coverage, result, link_module)

[0079] test_id: Unique identifier of test case.

[0080] coverage: Code path or module information covered by the test.

[0081] result: Test execution result (PASS / FAIL / SKIPPED, etc.).

[0082] link_module: Associated module under test.

[0083] Deploy: Deploy(env_hash, cluster, timestamp)

[0084] env_hash: Cryptographic hash fingerprint of the deployment environment configuration (generated by the deployment consistency anchoring unit).

[0085] cluster: Target cluster identity of the deployment.

[0086] timestamp: Deployment timestamp.

[0087] Module Summary: Defines four categories of core entities and their key attributes in a structured manner, laying the data foundation for building dynamic association networks.

[0088] 2. Multi-dimensional Association Network Construction

[0089] The hub discovers, establishes, and maintains the association relationships between entities in real time through the following three channels:

[0090] 1) Explicit Association Channel:

[0091] Steps:

[0092] Receive input: Receive explicit mapping pairs <Req_ID, Commit_ID> from the development behavior perception unit output (e.g., explicit inclusion of REQ-5.1.3 in the commit comment).

[0093] Create relationship: Directly create the IMPLEMENTED_BY relationship edge in the knowledge graph, connecting the requirement entity R i and the code commit entity C j .

[0094] Let the requirement set R (R i is a single requirement entity) and the code commit set C = C (C j is a single code commit entity), then the explicit association relationship set is defined as:

[0095]

[0096] Where (R i , C j ) represents that the requirement R i is implemented by the code commit C j .

[0097] Establishes a deterministic, developer explicitly specified binding relationship between requirements and implementation code.

[0098] 2) Implicit Association Channel

[0099] Steps:

[0100] Acquire coverage data: acquire the set of code paths covered by the test execution using a code instrumentation tool (e.g. Jacoco) (P x single code path).

[0101] Detect unassociated code: check if there exists a code path P x not explicitly associated to any requirement (i.e. where is the existential quantifier and ∪ is the union operation, is the set of requirement-associated code mappings).

[0102] Create pending requirement: if unassociated code blocks are found, automatically create a pending requirement node with status PENDING (where AUTO_ID is the automatically generated ID, is the empty version chain), and associate it with these code blocks.

[0103] Freeze permissions: invoke the gateway function of the development behavior perception unit to freeze the merge permissions of the branch containing the unassociated code.

[0104] Enforce handling: before the start of the next development iteration, the system enforces the developer to either supplement the requirement documentation for this code or mark it as deprecated. If not handled, the branch remains frozen.

[0105] Automatically capture requirements binding missed during development (i.e. "requirements leakage"), preventing code with unverified or undefined requirements from entering production.

[0106] 3) Cross-layer traceability channel

[0107] Trigger condition: the deployment consistency anchoring unit detects that the deviation value ΔH between the production environment fingerprint and the test baseline fingerprint exceeds the preset threshold τ, for example ΔH > 0.01.

[0108] Steps:

[0109] Extract production error features: extract the feature vector of the error stack from the production environment error logs or monitoring system (d is the feature dimension).

[0110] Calculate test similarity: calculate the cosine similarity between the feature vector f and the feature vector t k of all test cases T k in the knowledge graph:

[0111]

[0112] where Sim is the cosine similarity, · denotes the dot product, and | · | denotes the vector's modulus (length). This formula measures the degree of matching between the test case feature and the production bug feature.

[0113] Binding the most similar test: find the test case with the highest similarity

[0114] Backtracking the root requirement: backtracking along the relationship edges in the knowledge graph:

[0115]

[0116] where VERIFIES is the verification relationship, and the test case verifies the relationship of the code entity; IMPLEMENTS is the implementation relationship, and the code entity implements the relationship of the requirement entity.

[0117] Finally, locate the root requirement entity R that is most likely to cause the production environment problem i .

[0118] When the production environment has a problem (especially when the environment deviation causes the problem), quickly and automatically locate the root requirement entry, and shorten the troubleshooting time.

[0119] The dynamic knowledge graph hub is the core of the system, which builds and maintains the dynamic association network between the four-dimensional entities of requirements, code, tests, and deployment in real time through three channels of explicit, implicit, and cross-layer tracing, forming a complete and traceable closed loop. At the same time, the implicit channel realizes the creation and forced processing mechanism of the to-be-confirmed requirement, and the cross-layer channel realizes the environment problem requirement tracing mechanism.

[0120] II. Implementation of the requirement structured unit

[0121] The original, unstructured requirement document is automatically decomposed into atomic entries (the smallest requirement unit), and a unique identifier with version traceability chain is generated for each entry.

[0122] 1. Atomic decomposition process

[0123] Input: original requirement document D (supporting text, Markdown, etc. Common formats)

[0124] Semantic segmentation:

[0125] Use the pre-trained BERT base model (BERTbase) to encode and segment the document:

[0126] [h1,h2,...,h L ]=BERT base (D)

[0127] where L is the text length of the document D, and hi is the context vector representation of the i-th position.

[0128] On top of the BERT output, a classification layer is applied to predict the probability that each position is a segmentation point:

[0129] Segment i = Softmax(Wh i + b)

[0130] where W is the weight matrix and b is the bias vector.

[0131] The output value represents the probability that this position is the start or end of an atomic requirement fragment.

[0132] Rule Engine Supplement: To further improve the accuracy of decomposition, the system integrates a rule engine. If the syntactic dependency analysis detects that the sentence contains conjunctions (such as "and", "or", "and") that represent parallel relationships, it is forced to split at the conjunction.

[0133] Output: Generate a set of atomic requirements {R1, R2,..., R p}, where each R i is a semantically independent, indivisible minimum requirement unit.

[0134] 2. Version Traceability Chain Generation

[0135] Generate Unique ID: For each atomic requirement entry R i generate a standard-compliant and globally unique identifier ID (format: REQ-Project ID.Parent Requirement ID.Sequence Number@Version Number, such as REQ-5.1.3@v1.2).

[0136] Build Merkle Tree: Use the Merkle tree structure to store and manage the change history of requirement entries, ensuring the integrity and tamper resistance of historical records.

[0137] Leaf Node: Calculate the hash value of the specific version content of each requirement entry (such as ): is the k-th version content of the requirement entry R i .

[0138] Parent Node: Concatenate the hash values of adjacent child nodes and calculate the hash value again: H parent = SHA256(H left || H right ), where || represents concatenation, H left represents the left child node hash value, and H right represents the right child node hash value.

[0139] Root Hash: The final RootHash represents the current version state of the entire requirement set: RootHash = H top , H top is the root node hash value of the Merkle tree.

[0140] Handling Changes: When a requirement entry is changed (a new version is created), the system creates a new leaf node (containing the hash of the new version content) and recalculates the hash values on all paths from the leaf node to the root node, updating the RootHash.

[0141] The requirement structuring unit converts the original requirements into structured atomic entries and generates a unique identifier with a cryptographic hash chain (Merkle tree) and a version trace chain, providing a standardized requirement entity input for the knowledge graph hub.

[0142] III. Development Behavior Perception Unit Implementation

[0143] Automatically parse the comment information in the code commit record, extract the requirement identifier (REQ-X.Y.Z) or bug number (#BUG-NUM) contained therein, and forcibly establish the binding relationship between the code commit node and the requirement entry.

[0144] 1. Semantic Parser

[0145] Input: The comment text T filled in by the developer when submitting the code repository (for example: "Fix login validation REQ-3.2.1.1 #BUG-45").

[0146] Identifier Extraction:

[0147] Fine-tuned BERT-CRF model for Named Entity Recognition (NER):

[0148] e1,e2,...,e L =BERT ft (T)

[0149] TagSeq=CRF(W[e1;e2;...;e L ]+b)

[0150] Where e i is the embedding vector at position i, TagSeq is the label sequence, W is the weight matrix, and b is the bias vector.

[0151] The model is trained and fine-tuned on a code commit comment dataset containing about 10,000 manually annotated entries, achieving high recognition accuracy (F1 score ≈ 0.92).

[0152] Output: Set of identified requirement IDs and Set of identified bug IDs where REQ-3.2.1.1 is an example requirement ID, specifically Project ID = 3, Parent Requirement ID = 2.1, Sequence Number = 3, Version Number 1.1); BUG-45 is the 45th bug.

[0153] 2. Association Enforcing Gateway

[0154] Interception Logic: The gateway decides whether to allow the code commit to enter the repository based on the output of the semantic parser.

[0155] Case 1: No identifier

[0156] Block this code commit directly, prohibit it from entering the code repository.

[0157] Push a clear instruction message to the corresponding developer's terminal or Integrated Development Environment (IDE) in real time:

[0158] {“action”: “block”, “message”: “The commit must be associated with at least one requirement ID (format: REQ-X.Y.Z) or bug number (#BUG-NUM). Please modify the commit comment and retry.”}

[0159] Case 2: Contains valid identifier

[0160] Allow the code commit to enter the repository.

[0161] Call the API of the dynamic knowledge graph hub to create an IMPLEMENTED_BY relationship edge in the knowledge graph ( C j is the current submitted code entity). If it is associated with a bug , establish the association between the code and the bug node (the bug node is created by the test closed-loop feedback unit).

[0162] The development behavior perception unit uses NLP technology (BERT-CRF) to automatically parse the commit comment, and through the enforcing gateway ensures that all code commits entering the repository are explicitly associated with requirements or bugs, providing key “requirement-code” explicit association data for the knowledge graph hub.

[0163] Four, Test Closed-Loop Feedback Unit Implementation

[0164] Receive test execution results, dynamically update the status of associated requirement items; when the status becomes failed, automatically create a bug node and manage the subsequent processing flow; generate a test environment benchmark fingerprint.

[0165] 1. State machine management

[0166] The system maintains a state machine for each requirement entity. The transition of the state machine is driven by test events and triggers corresponding automated actions. The state transition rules are shown in the following table:

[0167]

[0168]

[0169] The state machine is updated in real time to ensure that the requirement status accurately reflects the latest test results and development progress.

[0170] 2. Defect handling mechanism

[0171] When the requirement status changes to FAIL due to test failure:

[0172] Create defect node: The system automatically creates a defect node (e.g. DEF-301) in the knowledge graph. This node contains the severity level (e.g. severity = 0.4, calculated based on the importance and impact of the failed test), the associated requirement entity R i , associated code entity C j (or code module), and the associated failing test case T k .

[0173] Freeze code branch: The system automatically freezes the code branch associated with the defect (such as feature-login), preventing it from being merged into the main branch (main / master), preventing the problematic code from affecting the stability of the trunk.

[0174] Generate a regression queue: The system analyzes the current failed defects and potentially affected areas, selects test cases that need to be re-executed from the test case library, and generates a regression verification task queue. Test cases in the queue are sorted by priority. The priority calculation formula is:

[0175]

[0176] Among them, Coverage(T k ) represents the test case T k Code coverage (the higher the value, the wider the coverage), ExecTime (T k ) represents the test case T k The execution time of the test cases is determined by the value of the queue (higher values ​​mean longer execution times). This formula prioritizes test cases with high coverage and short execution times to maximize regression testing efficiency. The queue continues running until the associated defects are fixed, verified, and closed.

[0177] 3. Test environment fingerprint output

[0178] To perform environment consistency verification in the deployment phase, this unit generates a cryptographic hash fingerprint H representing the test environment configuration baseline test . The fingerprint contains three key levels:

[0179] OS kernel hash: H os = SHA256(uname -r output) (hash of kernel version information).

[0180] Dependency library recursive hash tree (Merkle Root):

[0181] Calculate the hash of each dependency library (lib_i) specific version as a leaf node: LeafHash i = SHA256(lib i .version).

[0182] Use the function TreeHash(V) to recursively hash the concatenated hash of adjacent leaf nodes to generate the final dependency library Merkle root hash H libs .

[0183] Container image layer-level checksum:

[0184] H docker = SHA256(docker inspect -f='RootFS.Layers' image

[0185] Calculate the hash of the concatenated hash of all file system layer IDs of the container image.

[0186] Final fingerprint: H test = [H os , H libs , H docker ] T (a vector containing three hash values), the baseline fingerprint is securely stored.

[0187] The test closed-loop feedback unit implements dynamic closed-loop management of requirement status, automatically creates defect nodes and manages regression processes when testing fails, and generates a test environment baseline fingerprint containing operating system, dependency library, and container image information to provide a baseline for deployment consistency verification.

[0188] Five, deployment consistency anchoring unit implementation

[0189] Verify the configuration of the target production environment against the test environment baseline before software is deployed to production; if significant deviations are detected, interrupt the deployment and trigger an alert and remediation process; generate a deployment environment fingerprint.

[0190] 1. Cryptographic Hash Fingerprint Generation

[0191] This unit executes the exact same process as the test environment fingerprint generation on the target production environment during the deployment phase:

[0192] Recursively compute the dependency library hash tree (resulting in );

[0193] Compute the operating system kernel hash (resulting in );

[0194] Compute the container image layer hashes (resulting in );

[0195] Generate the final fingerprint vector for the target production environment:

[0196] This fingerprint, after being used for comparison, is AES-256 encrypted and stored in a secure database for auditing and traceability.

[0197] 2. Environment Deviation Detection and Disposition

[0198] Compute Deviation: Compute the Euclidean Distance between the production environment fingerprint H prod and the test baseline fingerprint H test as a measure of deviation: ΔH = ||H prod -Htest||2.

[0199] Deployment Decision:

[0200]

[0201] Sandbox Rebuild and Smoke Test: When the deployment is interrupted due to a deviation above the threshold:

[0202] Identify the Responsible Party: Analyze the audit logs of the infrastructure (e.g., Kubernetes) to identify the responsible party and the operation timestamp for the most recent change to the production environment.

[0203] Rebuild Sandbox According to Baseline: Rebuild an environment consistent with the test environment according to the description of the test environment baseline fingerprint H test (operation system version, dependency library list and version, container image).

[0204] Perform Smoke Test: In the rebuilt sandbox environment, only run the modified or added components in the current version to be deployed Htest Verify if the basic functions of the current deployment package are normal in the "correct" environment.

[0205] The deployment consistency anchoring unit strictly ensures the consistency of the production environment and the test environment by generating and comparing cryptographic hash fingerprints. When unacceptable environmental deviations are detected, the deployment is interrupted, an alarm is raised, the person responsible is located, and a sandbox reconstruction and smoke test process is started to ensure that only compatible environments can run the software.

[0206] Six, full-link visualization engine implementation

[0207] Requirements, code, test, deployment entities and their associated relationship data are obtained in real time from the dynamic knowledge graph hub to generate intuitive penetrable traceability topology graphs and risk indicator-based heat maps.

[0208] 1. Penetrable traceability topology graph

[0209] Data source: Directly query the dynamic knowledge graph hub to obtain current entity and relationship network data.

[0210] Layout algorithm: Use an improved force-directed graph layout algorithm to automatically calculate node positions.

[0211] Gravitational formula: Where F attr is the gravitational force, k is the gravitational constant, p i and p j are node coordinate vectors, w is the edge weight (e.g., the number of associated code lines, the number of test cases), and |p i -p j | is the Euclidean distance between two points. The greater the weight w, the stronger the gravitational force, and the nodes tend to be closer.

[0212] Repulsive force formula: Where F rep is the repulsive force, c is the repulsive force constant. The closer the distance between nodes, the greater the repulsive force, preventing node overlap.

[0213] Penetrable traceability: User clicks on any entity node in the topology graph (such as a requirement REQ-3.2.1.1), and the engine automatically expands to display 3 layers of associated entities directly connected to the node (e.g., code commit Commit-8f2e that implements it, test case Test_login_001 that verifies it, environment Deploy_Prod_A that deploys it, and other entities further associated with these entities), forming a focused subgraph that clearly shows the node's context in the entire link.

[0214] 2. Risk heat map

[0215] The engine calculates risk scores for code modules or requirement areas based on development history and test data and renders a heat map.

[0216] Input metrics:

[0217] Defect density (δ): where D represents the total number of historical defects produced by the module / area in the statistical time period, and L represents the number of code lines (unit: KLOC) of the module / area. This metric measures the stability of code quality.

[0218] Change frequency (γ): where N represents the number of version iterations of the requirement items associated with the module / area within the statistical time window, and T represents the length of the statistical time window (unit: weeks). This metric measures the volatility of requirements and the modification frequency of code.

[0219] Normalization: Normalize the δ and γ values of all modules / areas within the statistical range to eliminate the dimensional effect and make them fall within the [0, 1] interval:

[0220]

[0221] where δ min is the minimum defect density, δ max is the maximum defect density, γ min is the minimum change frequency, and γ max is the maximum change frequency.

[0222] Risk score (R): Calculate the final risk score using the weighted formula:

[0223] R = α · δ norm + β · γ norm

[0224] where α is the weight coefficient of defect density (α > 0), β is the weight coefficient of change frequency (β > 0), and α + β = 1. This embodiment defaults to α = 0.6, β = 0.4 (indicating more attention to historical defect density).

[0225] Color mapping: Map the module / area to the red-yellow-green three-color warning according to the value of risk score R:

[0226]

[0227] The full-link visualization engine visually displays the complex associations between entities through a topological graph that can be traced through, and provides managers with a global risk perspective and decision basis through the risk heat map that integrates defect density and change frequency.

[0228] Seven, complete workflow example

[0229] The following scenario demonstrates how the system works in concert, covering the method steps:

[0230] Scenario: User login module requirement change (atomic requirement: REQ-3.2.1.1 - Password encryption logic optimization).

[0231] Dynamic graph construction steps:

[0232] Requirement structuring: The original requirement document is input into the requirement structuring unit, which is decomposed into atomic items REQ-3.2.1.1, etc., generating a unique ID and version chain Merkle root hash Root_v1.3, and injecting the knowledge graph.

[0233] Development submission: The developer submits the code with the comment "Optimize password hash for REQ-3.2.1.1".

[0234] Development awareness: The BERT-CRF parser of the development behavior awareness unit extracts REQ-3.2.1.1. The mandatory gateway verification passes, allowing the submission to be stored, and the knowledge graph hub creates the IMPLEMENTED_BY edge of REQ-3.2.1.1 -> Commit-8f2e.

[0235] Closed-loop control steps:

[0236] Test execution: The code is merged into the test branch, and the test closed-loop unit sets the status of REQ-3.2.1.1 to TESTING, triggering automated testing.

[0237] Test failure: Performance testing fails. The test closed-loop unit updates the status of REQ-3.2.1.1 to FAIL.

[0238] Defect handling: Automatically create a defect node DEF-301 (severity = 0.4) associated with REQ-3.2.1.1 and Commit-8f2e. Freeze the merge permissions of the feature-auth branch. Generate a priority-ordered regression test queue.

[0239] Deployment verification: The repaired code is ready for deployment, and the deployment consistency anchoring unit generates the production environment fingerprint, discovering the missing OpenSSL3.0 dependency (ΔH = 0.18 > τ = 0.01).

[0240] Interruption and handling: The deployment is interrupted, and the K8s logs are parsed to locate the change responsible person. According to the test baseline fingerprint H test Rebuild the sandbox environment. Run the smoke test related to the login module.

[0241] Visualization driving steps:

[0242] Topology graph: The full-link visualization engine generates a topology graph, clearly showing the link: REQ-3.2.1.1 -> Commit-8f2e -> DEF-301 (highlighted in red), and you can view the associated test and deployment information by clicking through.

[0243] Heat map: The engine calculates the risk score of the login module: after normalization of defect density δ (assumed = 1.2 defects / KLOC) and change frequency γ (assumed = 2 times / week), R = 0.6·δ + 0.4·γ = 0.78, the login module is displayed in red (high risk) on the heat map. norm norm

[0244] Workflow summary: This example fully demonstrates how the system manages the entire process of a demand change from development, testing to deployment (blocked) through the "dynamic graph construction -> closed-loop control -> visualization-driven" three-step method, and triggers defect handling, environment repair and risk visualization.

[0245] Summary of the embodiment:

[0246] This embodiment proposes a computer software development information management system and method, the core of which is to build a closed-loop control network based on the architecture of a dynamic knowledge graph hub, to establish and maintain multi-dimensional associations between requirements, code, testing and deployment entities through three channels of explicit, implicit and cross-layer tracing in real time, to completely solve the fragmentation problem of traditional tool chains, to achieve end-to-end traceability from requirement definition to production deployment, and to form a complete development and operation closed-loop control system by combining key technologies such as structured requirement decomposition, development behavior mandatory binding, test closed-loop feedback, environment consistency anchoring and full-link visualization.​​

Claims

1. A computer software development information management system, characterized in that: include: Dynamic knowledge graph hub: builds and maintains a multi-dimensional association network between requirement entities, code entities, test entities, and deployment entities in real time; Demand structuring unit: connected to the dynamic knowledge graph hub, used to decompose the original demand into atomic items (i.e., the smallest indivisible demand unit) and generate a unique identifier with a version traceability chain for each item; Development behavior perception unit: connected to the dynamic knowledge graph hub, automatically extracts requirement identifiers and defect numbers from submission comments by parsing the submission records of the code repository, and establishes a binding relationship between the code submission node and the requirement item; Test closed-loop feedback unit: bidirectionally connected to the dynamic knowledge graph hub, performing: Receive test result data and dynamically update the status of associated requirement items (pass / fail / blocked); When the status changes to failure, it automatically triggers the creation of a defect node and freezes the merge permission of the associated code branch; Deployment consistency anchor unit: connected to the dynamic knowledge graph hub, performs the following during the deployment phase: Generate a cryptographic hash fingerprint of the runtime environment configuration; Compare the production environment fingerprint with the test benchmark fingerprint. If the deviation exceeds the threshold, the deployment is interrupted and an alarm is issued. Full-link visualization engine: Connected to the dynamic knowledge graph hub, it obtains relevant network data from the dynamic knowledge graph hub in real time and generates: A traceable requirements-code-test-deployment topology diagram; A risk heat map that integrates development unit defect data and requirement unit change frequency.

2. A computer software development information management system according to claim 1, characterized in that: The dynamic knowledge graph hub maintains the association network in the following ways: Explicit association channel: parses the mapping relationship between the requirement identifier submitted by the development behavior perception unit and the code submission ID; Implicitly associated channels: Monitor test coverage paths through code instrumentation and bind unassociated code to requirement items; Cross-layer traceability channel: When the deployment consistency anchor unit detects fingerprint deviation, it traces back and associates test cases and requirement items based on stack features.

3. A computer software development information management system according to claim 1, characterized in that: The development behavior perception unit includes: Semantic parser: uses a BERT-based natural language processing model to extract requirement identifiers and defect numbers from code comments; Associated mandatory gateway: For submissions that do not contain the identifier, the code is blocked from being stored and completion instructions are pushed to the developer's terminal.

4. A computer software development information management system according to claim 1, characterized in that: When the test closed-loop feedback unit updates the demand status to failure: Automatically create defect nodes and associate them with corresponding requirement items and code modules; Drive the test case library to generate a regression verification task queue until the defect is closed.

5. A computer software development information management system according to claim 1, characterized in that: The cryptographic hash fingerprint generation in the deployment consistency anchor unit includes: Recursive hash calculation of the operating system kernel version, dependency library list, and container image layer; The test environment benchmark fingerprint is stored in an encrypted database.

6. A computer software development information management system according to claim 1, characterized in that: The risk heat map generation logic of the full-link visualization engine is: Calculate the defect density of a code module: Where D represents the total number of historical defects in the module, and L represents the number of code lines in the module; Statistical requirement item change frequency: Where N represents the number of version iterations of the requirement within the time window, and T represents the length of the statistical time window (unit: week); Generate risk score: R = α·δ + β·γ, where α is the defect density weight coefficient (α>0), β is the change frequency weight coefficient (β>0), and α+β=1; According to the R value, it is mapped to the red-yellow-green risk map.

7. A computer software development information management system according to claim 2, characterized in that: The implicitly associated channel performs: When the test coverage analysis finds that the newly added code has no associated requirements, a requirement node to be confirmed is automatically created; Before the next development iteration cycle begins, it is mandatory to supplement the requirements document or mark the abandoned code.

8. A computer software development information management system according to claim 5, characterized in that: When the deployment environment fingerprint deviation exceeds the threshold: Automatically locate the person responsible for environmental changes and the timestamp of the operation; Start the sandbox environment and rebuild it according to the test benchmark fingerprint, and perform smoke testing on the modules associated with the currently deployed version.

9. A computer software development information management system according to claim 1, characterized in that: The test environment reference fingerprint output by the test closed-loop feedback unit includes: Operating system kernel version hash value, dependency library recursive hash tree, and container image layer verification.

10. A computer software development information management method, characterized in that: The method is implemented based on the computer software development information management system according to any one of claims 1 to 9, and includes: Steps to build a dynamic graph: Generate atomic entries and unique identifiers through demand structured units and inject them into the knowledge graph; Scan code submissions through the development behavior perception unit to create requirement-code association edges; Closed-loop control steps: Update the requirement status through the test closed-loop feedback unit and freeze the abnormal code branch; Verify the consistency of environment fingerprints by deploying consistency anchor units to block incompatible deployments; Visualization driving steps: The topology map and risk heat map are rendered in real time through the full-link visualization engine.

Images