Open source component defect management method and device, electronic equipment and storage medium

Abstract

The invention discloses an open source component defect management method and device, electronic equipment and a storage medium, and relates to the technical field of software, the method comprises the following steps: determining an open source component with a defect; acquiring a defect priority of the open source component; obtaining the defect repair cost of the open source component; acquiring a defect risk level of the open source component; determining the defect density of the open source component based on the total row number of codes of the function module embedded in the open source component and the number of defects existing in the open source component; and based on the defect priority, the defect repair cost, the defect risk level and the defect density, determining a defect solving decision of the open source component. Therefore, the purpose of automatically managing the defects of the open source component is achieved.

Description

Technical Field

[0001] This application relates to the field of software management technology, and in particular to an open-source component defect management method, apparatus, electronic device, and storage medium. Background Technology

[0002] As software applications become increasingly larger and more complex, the challenges facing software development management processes are becoming more and more severe. Open-source components may be used during software application development, and defect management of these components is a crucial aspect of the software development management process.

[0003] In related technologies, defect management of open-source components mainly relies on manual reporting. This method is not only time-consuming, but also prone to errors and oversights due to human intervention, affecting the accuracy and efficiency of defect management for open-source components. Summary of the Invention

[0004] In view of the above problems, this application provides a method, apparatus, electronic device, and storage medium for managing defects in open-source components, so as to achieve the purpose of automatically managing defects in open-source components. The specific solution is as follows: The first aspect of this application provides a method for managing defects in open-source components, including: Identify defective open-source components; Obtain the defect priority of the open source component; Obtain the cost of fixing defects in the open-source component; Obtain the defect risk level of the open-source component; The defect density of the open source component is determined based on the total number of lines of code in the functional modules embedded in the open source component and the number of defects existing in the open source component. Based on the defect priority, the defect repair cost, the defect risk level, and the defect density, a decision is made to resolve the defects of the open-source component.

[0005] In one possible implementation, the step of obtaining the defect priority of the open-source component includes: Obtain the scope of influence of the open-source component, wherein the scope of influence represents the number of functional modules embedded in the open-source component; The user impact of the open-source component is obtained, and the user impact represents the number of users who were unable to complete their business due to defects in the open-source component. Obtain the defect reproducibility of the open source component. The defect reproducibility refers to the ratio of the number of target test cases to the total number of test cases. The target test cases refer to the test cases that detect the defect in the open source component during the testing of the functional modules embedded in the open source component. The severity of the defect in the open-source component is determined by the scope of impact, the impact on users, and the reproducibility of the defect. Obtain the repair complexity level of the open-source component; From the preset correspondence between development stages and repair priorities, find the target repair priority corresponding to the development stage of the functional module embedded in the open source component; The defect priority is obtained based on the defect severity, the repair complexity level, and the target repair priority.

[0006] In one possible implementation, the step of obtaining the defect repair cost of the open source component includes: obtaining the defect repair cost Cost based on the expected repair time H, the hourly co-working cost RR, the number of additional resources required Rs, and the cost of each additional resource RC; Cost = (H × RR) + (Rs × RC). The process of determining the amount of additional resources includes: Obtain fix information by publishing the official website of the open source component. The fix information includes the content of the official website fix patch or version upgrade, or the content of other related components that need to be modified in sync to fix the defect. Assess the scope of impact of the remediation information, including: the number of system servers carrying the defects that need to be remediated; and whether the system servers carrying the defects that need to be remediated are internet system servers or non-internet system servers. Determine the cost of defect repair based on the scope of impact.

[0007] In one possible implementation, the step of obtaining the defect risk level of the open-source component includes: Obtain the target number of days since the defect in the open-source component was discovered; Obtain the total number of development days for the functional module embedded in the open-source component; Obtain the importance score of the functional module embedded in the open-source component; The defect risk level is obtained based on the defect priority, the target number of days, the total number of development days, and the importance score.

[0008] In one possible implementation, the decision-making steps for determining the defects of the open-source component based on the defect priority, the defect repair cost, the defect risk level, and the defect density include: The number of personnel to resolve the defect is allocated based on the defect repair cost; Based on the defect risk level and the defect priority, determine the timeframe for resolving the defect; The decision to replace the open-source component is based on the defect density.

[0009] One possible implementation also includes: Determine the target defect type of the defect; The pre-defined personnel identifier, historical defect repair types, expertise, and current workload correspondence, along with the target defect type, are input into a pre-built personnel recommendation model. The target personnel identifier for resolving the defect is then obtained through the personnel recommendation model. Create a resolution task to address the aforementioned defects in the open-source component; Send the task to the communication address corresponding to the target personnel identifier.

[0010] A second aspect of this application provides an open-source component defect management device, comprising: The first identification module is used to identify open-source components with defects; The first acquisition module is used to acquire the defect priority of the open source component; The second acquisition module is used to acquire the defect repair cost of the open source component; The third acquisition module is used to acquire the defect risk level of the open source component; The second determining module is used to determine the defect density of the open source component based on the total number of lines of code of the functional modules embedded in the open source component and the number of defects existing in the open source component. The third determining module is used to determine the resolution decision of the defects of the open source component based on the defect priority, the defect repair cost, the defect risk level, and the defect density.

[0011] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the open-source component defect management method described in the first aspect or any implementation thereof.

[0012] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the open-source component defect management method of the first aspect or any implementation thereof.

[0013] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the open-source component defect management method described in the first aspect or any implementation thereof.

[0014] By employing the above technical solution, this application provides an open-source component defect management method, which identifies open-source components with defects; obtains the defect priority of the open-source component; obtains the defect repair cost of the open-source component; obtains the defect risk level of the open-source component; determines the defect density of the open-source component based on the total number of lines of code in the functional modules embedded in the open-source component and the number of defects existing in the open-source component; and determines the defect resolution decision of the open-source component based on the defect priority, the defect repair cost, the defect risk level, and the defect density. This achieves the goal of automatically managing the defects of open-source components. Attached Figure Description

[0015] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0016] Figure 1 A schematic diagram of a system architecture is provided for this application; Figure 2 A schematic diagram of an optional hardware structure for a terminal 100 provided in this application; Figure 3 This application provides a schematic diagram of the structure of an operation and maintenance server; Figure 4 A flowchart illustrating an open-source component defect management method provided in this application embodiment; Figure 5 A schematic diagram of the structure of an open-source component defect management device provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0018] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0019] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0020] See Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100, an operation and maintenance server 200 running functional modules embedded in open-source components, and a database 300 of open-source components.

[0021] For example, database 300 stores defects in open-source components. For example, there can be one or more databases 300.

[0022] For example, the operations and maintenance server 200 is a server that runs functional modules embedded with open-source components. For example, there can be one or more operations and maintenance servers 200. For example, users can access the operations and maintenance server 200 to conduct business through an application client.

[0023] In one optional implementation, an application can be installed on terminal 100. This application provides an interface, allowing terminal 100 to receive relevant parameters input by the user on the interface, such as instructions for collecting attribute information of open-source components, and send these parameters to database 300. Database 300 can then obtain a processing result based on the received parameters and return the result to terminal 100. Alternatively, terminal 100 can receive relevant parameters input by the user on the interface, such as instructions for collecting attributes of functional modules embedded in open-source components, and send these parameters to operations and maintenance server 300. Operations and maintenance server 300 can then obtain a processing result based on the received parameters and return the result to terminal 100. This enables terminal 100 to execute the open-source component defect management method provided in this application embodiment.

[0024] The following description Figure 1 The product form of the mid-terminal 100; The terminal 100 in this application embodiment can be a mobile phone, tablet computer, wearable device, vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0025] Figure 2 A schematic diagram of an optional hardware structure for terminal 100 is shown.

[0026] refer to Figure 2 As shown, the terminal 100 may include a radio frequency unit 110, a memory 120, an input unit 130, a display unit 140, a camera 150 (optional), an audio circuit 160 (optional), a speaker 161 (optional), a microphone 162 (optional), a headphone jack 163 (optional), a processor 170, an external interface 180, a power supply 190, and other components. Those skilled in the art will understand that... Figure 2 This is merely an example of a terminal and does not constitute a limitation on the terminal. It may include more or fewer components than shown in the illustration, or combine certain components, or use different components.

[0027] The input unit 130 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the terminal. Specifically, the input unit 130 may include a touch screen 131 (optional) and / or other input devices 132. The touch screen 131 can collect touch operations performed by the user on or near it (such as operations performed by the user using fingers, knuckles, styluses, or any suitable object on or near the touch screen), and drive the corresponding connection devices according to a pre-set program. The touch screen can detect the user's touch actions, convert the touch actions into touch signals and send them to the processor 170, and can receive and execute commands sent by the processor 170; the touch signal includes at least touch point coordinate information. The touch screen 131 can provide an input interface and an output interface between the terminal 100 and the user. In addition, various types of touch screens, such as resistive, capacitive, infrared, and surface acoustic wave, can be used to implement the touch screen. Besides the touch screen 131, the input unit 130 may also include other input devices. Specifically, other input devices 132 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0028] Among them, the input device 132 can receive input data, etc.

[0029] The display unit 140 can be used to display information input by the user or information provided to the user, various menus of the terminal 100, interactive interfaces, file display, and / or playback of any multimedia file. In this embodiment, the display unit 140 can be used to display interfaces, processing results, etc.

[0030] The memory 120 can be used to store instructions and data. The memory 120 may primarily include an instruction storage area and a data storage area. The data storage area can store various types of data, such as multimedia files and text. The instruction storage area can store software units such as operating systems, applications, and instructions required for at least one function, or subsets or extended sets thereof. It may also include non-volatile random access memory. It provides the processor 170 with hardware, software, and data resources for managing the computing device, supporting control software and applications. It is also used for storing multimedia files, as well as storing running programs and applications.

[0031] The processor 170 is the control center of the terminal 100. It connects various parts of the terminal 100 via various interfaces and lines. By running or executing instructions stored in the memory 120 and calling data stored in the memory 120, it performs various functions and processes data of the terminal 100, thereby controlling the terminal device as a whole. Optionally, the processor 170 may include one or more processing units; preferably, the processor 170 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 170. In some embodiments, the processor and memory can be implemented on a single chip; in some embodiments, they can also be implemented separately on independent chips. The processor 170 can also be used to generate corresponding operation control signals, send them to the corresponding components of the computing processing device, read and process data in the software, especially read and process data and programs in the memory 120, so that the various functional modules therein perform corresponding functions, thereby controlling the corresponding components to act according to the instructions.

[0032] The memory 120 can be used to store software code related to the open source component defect management method, and the processor 170 can execute the steps of the open source component defect management method, and can also schedule other units (such as the above-mentioned input unit 130 and display unit 140) to achieve the corresponding functions.

[0033] The radio frequency unit 110 (optional) can be used for receiving and transmitting signals during information transmission or calls. For example, it can receive downlink information from the base station and process it for the processor 170; additionally, it can transmit uplink data to the base station. Typically, the RF circuit includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, the radio frequency unit 110 can also communicate wirelessly with network devices and other devices. This wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.

[0034] In this embodiment of the application, the radio frequency unit 110 can send data to the server 200 and receive the processing results sent by the server 200.

[0035] It should be understood that the radio frequency unit 110 is optional and can be replaced with other communication interfaces, such as a network port.

[0036] The terminal 100 also includes a power supply 190 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 170 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0037] Terminal 100 also includes an external interface 180, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.

[0038] Although not shown, terminal 100 may also include a flash, a Wireless Fidelity (WiFi) module, a Bluetooth module, sensors with various functions, etc., which will not be described in detail here. Some or all of the methods described below can be applied to, for example... Figure 2 In the terminal 100 shown.

[0039] The following description Figure 1 Product form of mid-level maintenance servers; Figure 3 A schematic diagram of the structure of an operation and maintenance server is provided, such as... Figure 3 As shown, the maintenance server includes a bus 201, a processor 202, a communication interface 203, and a memory 204. The processor 202, the memory 204, and the communication interface 203 communicate with each other via the bus 201.

[0040] Bus 201 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0041] The processor 202 can be any one or more of the following processors: a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0042] Memory 204 may include volatile memory, such as random access memory (RAM). Memory 204 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0043] It should be understood that the aforementioned terminal 100 and maintenance server can be centralized or distributed devices. The processors (e.g., processor 170 and processor 202) in the aforementioned terminal 100 and maintenance server can be hardware circuits (such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), general-purpose processors, digital signal processors (DSPs), microprocessors or microcontrollers, etc.) or combinations of these hardware circuits. For example, the processor can be a hardware system with instruction execution capabilities, such as a CPU or DSP, or a hardware system without instruction execution capabilities, such as an ASIC or FPGA, or a combination of the aforementioned hardware systems without instruction execution capabilities and hardware systems with instruction execution capabilities.

[0044] Reference Figure 4 , Figure 4 This is a flowchart illustrating an open-source component defect management method provided in an embodiment of this application, as shown below. Figure 4 As shown in the embodiment of this application, an open-source component defect management method may include steps S401 to S406, which are described in detail below.

[0045] Step S401: Identify the defective open-source components.

[0046] Understandably, to achieve comprehensive automated defect management of open-source components, it is necessary to collect attribute information of open-source components from multiple data sources and store it in database 300. The collection process is described below, which includes steps A1 to A3.

[0047] Step A1: Automatically retrieve relevant data of open source components from the data source at predetermined time intervals.

[0048] For example, data sources include community websites, discussion platforms, and official websites that publish open-source components. Community websites and discussion platforms are the primary venues for developers to communicate and report issues.

[0049] For example, discussion hotspots, issue information, and other data can be automatically obtained from data sources through API (Application Programming Interface) or web crawling technology.

[0050] API interfaces provide a standardized way to access platform-specific data, while web crawlers are used to extract information from web pages. In addition to automated data collection, this application also supports internal feedback on frequently asked questions about open-source components to ensure the comprehensiveness of data collection.

[0051] For example, irrelevant information, such as advertisements and irrelevant comments, can be removed from the relevant data to improve its quality. For example, the collected data can be converted into a standardized format to facilitate subsequent analysis and processing. For example, date formats can be standardized, and text encoding can be standardized.

[0052] Step A2: Obtain attribute information of multiple defects from relevant data of open source components.

[0053] For example, the database described above is a secure and scalable database. Storing attribute information of multiple defects in the database can ensure data integrity and security.

[0054] For example, regular expressions can be used to define sensitive word patterns, and text matching can be performed from relevant data in open-source components to obtain attribute information about defects. The frequency of all words in the relevant data is statistically analyzed, and words with higher frequencies are selected as keywords. Machine learning models (such as TF-IDF) are used to evaluate the importance of words to a document set or a single document in a corpus. NLP (Natural Language Processing) tools are used to extract named entities from the relevant data as potential keywords. Simultaneously, a dynamically updated list of keywords and sensitive words is maintained, continuously updated, and compared and filtered each time data is acquired for analysis to improve the accuracy of defect identification.

[0055] Step A3: Classify the attribute information of multiple defects according to defect type and defect severity level.

[0056] For example, sensitive data in the attribute information of multiple defects can be specially processed, such as by binding with open source technology tags, to ensure data privacy protection.

[0057] For example, the attribute information of multiple defects can be stored in a structured defect pre-table, which is a place to temporarily store defects and to temporarily store data before defect assessment and identification.

[0058] For example, the attribute information of multiple defects is filtered and invalid data is removed to reduce the burden of subsequent processing.

[0059] For example, after the defects in the defect pre-defect table are evaluated and identified, they are stored in the defect post-defect table in the database. This is a place to store defect information for a long time and to record and manage the entire life cycle of defects.

[0060] For example, if a defect in an open-source component is fixed, the defect needs to be moved from the defect pre-defect table to the defect post-defect table to record the defect processing results and history.

[0061] The entire data collection process is designed to ensure comprehensive, accurate, and secure data from multiple data sources, providing a solid foundation for subsequent data analysis, defect assessment, and automated process management. By combining automation and manual methods, this process improves the efficiency and coverage of data collection while ensuring data quality and privacy.

[0062] Step S402: Obtain the defect priority of the open source component.

[0063] Defect priority refers to the priority level for fixing the defect.

[0064] Step S403: Obtain the defect repair cost of the open source component.

[0065] For example, the defect repair cost (Cost) can be obtained based on the expected repair time (H), the hourly co-working cost (RR), the number of additional resources required (Rs), and the cost of each additional resource (RC).

[0066] For example, the defect repair cost can be calculated based on the following formula: Cost = (H × RR) + (Rs × RC).

[0067] For example, the process of determining the amount of additional resources includes the following steps A1 to A3.

[0068] Step A1: Obtain fix information through the official website of the published open-source component. The fix information includes the content of the official website fix patch or version upgrade, or the content of other related components that need to be modified in sync to fix the defect.

[0069] Step A2: Assess the scope of impact of the remediation information. The scope of impact includes: the number of system servers hosting the defect requiring remediation; and whether the system servers hosting the defect are internet system servers or non-internet system servers.

[0070] For example, a list of system servers hosting defective open-source components can be pulled, categorized by system server importance level and type.

[0071] Understandably, repairing internet system servers requires the development of additional business continuity repair plans and canary release verification plans. It's also understandable that the hourly cost of repairing internet system servers is higher; for example, if the cost of repairing a non-internet system server is 100, then the cost of repairing an internet system server is 120. Furthermore, the number of additional resources required to repair internet system servers is greater; for example, if the number of additional resources required to repair a non-internet system server is 50, then the number of additional resources required to repair an internet system server is 100. The cost per additional resource required to repair internet system servers is also higher; for example, if the cost per additional resource required to repair a non-internet system server is 1, then the cost per additional resource required to repair an internet system server is 1.2.

[0072] Step A3: Determine the cost of defect repair based on the scope of impact.

[0073] For example, the additional resources required to repair defects hosted by Class A and Class B system servers can be determined based on the system operation and maintenance level of an enterprise. The additional resources required for Class A and Class B system servers include: the number of hardware resources such as servers, memory, and network resources for the defect repair verification solution; the number of unitized microservices for the business continuity uninterrupted solution; and the number of multi-center node deployments for the canary release verification solution. The additional resources required to repair defects hosted by Class C and Class D system servers are also determined; these additional resources include: the number of hardware resources such as servers, memory, and network resources for the defect repair verification solution.

[0074] Step S404: Obtain the defect risk level of the open source component.

[0075] Step S405: Determine the defect density of the open source component based on the total number of lines of code in the functional modules embedded in the open source component and the number of defects in the open source component.

[0076] Defect density can be calculated based on the size of the functional module and the number of defects present in the functional module.

[0077] For example, the size of a functional module can be represented by the total number of lines of code in the functional module. For example, the defect density (DefectDensity) is calculated as follows: DefectDensity = Number of Defects / Size of Module.

[0078] Step S406: Based on the defect priority, the defect repair cost, the defect risk level, and the defect density, determine the defect resolution decision for the open-source component.

[0079] For example, step S406 can be implemented by: allocating the number of personnel to resolve the defect based on the defect repair cost; determining the time limit for resolving the defect based on the defect risk level and the defect priority; and determining whether to replace the open-source component based on the defect density.

[0080] Understandably, higher defect repair costs indicate that the defect is more difficult to fix and requires more personnel. Higher defect risk levels and higher defect priorities indicate that fixing the defect is more urgent, has a shorter timeframe, and starts earlier.

[0081] Understandably, a higher defect density indicates a greater impact of the defect on the functional module. Replacing it with a defect-free open-source component could be considered. Alternatively, the defect could be fixed urgently.

[0082] For example, a comprehensive defect resolution decision engine based on multi-objective optimization and dynamic programming can be used to comprehensively consider defect priority (P), repair cost (C), risk level (R), defect density (D) and real-time system constraints, generate comprehensive resolution decisions including personnel scheduling plans, time scheduling strategies, and component replacement suggestions, and can perform multi-scheme simulation and deduction to provide optimal decision support for managers.

[0083] The defect resolution decision is modeled as a multi-objective, multi-constraint optimization problem. Decision variables include: N : Number of personnel allocated (vector, which may include different roles such as development, testing, and operations); Ts The point in time when repairs began; Td Repair period (duration); A Actions taken (repair, replace, downgrade, temporary circumvention, etc.).

[0084] Optimization objective (minimization): Total risk exposure: Risk_Exposure = R × (Ts + Td). This is the product of the risk level and the time to fix, representing the cumulative risk of the defect in the system. Total cost: includes labor costs (N×Td×unit cost), resource costs (predicted from step A3), and procurement and integration costs that may be incurred due to replacement components; System quality loss: related to defect density (D) and the probability of new defects that may be introduced after defect repair.

[0085] Constraints: Human resource constraints: the total number of available personnel and their skill matching degree (from the personnel recommendation model); Time window constraints: System maintenance windows allowed by business needs, project release dates, etc.; Budget constraint: The total cost of repairs cannot exceed a preset limit; Risk threshold constraint: High priority (P) or high risk (R) defects must be initiated within a specified time.

[0086] To solve the aforementioned complex optimization problem, a hybrid decision algorithm is adopted, which combines the deterministic planning of dynamic programming (DP) with the simulation and exploration capabilities of Monte Carlo Tree Search (MCTS).

[0087] The algorithm flow is as follows: State space definition: The decision-making process is discretized into a series of states S, each state containing information such as the current defect evaluation index, available resources, and time.

[0088] Action space definition: In each state, the possible actions A include: Assign a specific personnel combination Ni; Set the start time Ts,i and the duration Td,i; Choose from repair, replacement, or hybrid strategies.

[0089] Reward function design: Design a reward function Reward(S,A) based on the optimization objective, for example:

[0090] Where λ is the weighting coefficient, which can be learned from historical data or set by the strategy; Risk_Exposure represents the total risk exposure, Total_Cost represents the total cost, and Quality_Loss represents the system quality loss.

[0091] Hybrid Decision Search: Dynamic programming layer: For subproblems with high determinism (such as personnel scheduling), dynamic programming is used to quickly find local optima.

[0092] MCTS Simulation Layer: For decisions with high uncertainty (such as system stability after component replacement, repair success rate), MCTS is used to conduct a large number of stochastic simulations to evaluate the long-term expected reward of different decision sequences.

[0093] Decision generation: The algorithm outputs a decision sequence (Policy), including immediate actions (e.g., assigning personnel X and Y, starting at 12 o'clock tonight, with an estimated duration of 2 days) and possible future adjustment strategies.

[0094] The following section elaborates on the algorithm flow of this invention using a scenario involving the handling of defects in open-source payment components on an e-commerce platform. Assume an e-commerce platform uses the open-source payment component PayX (embedded in the core functional modules of order payment and refund verification). Testing revealed that this component has an occasional payment failure defect. The specific background is as follows: 1. Business impact: Approximately 500 users are unable to complete payments daily due to the defect, directly affecting transaction conversion rates; 2. Component Information: The payment module has a total of 10,000 lines of code and has identified 3 related defects (including a major defect causing payment failure). 3. Development phase: The component has been online for 6 months (target fix priority M=40 points); 4. Available Resources: 3 developers (A: proficient in payment components, 30% workload; B: general component expert, 50% workload; C: novice, 20% workload), 3 verification servers (available within 2 days). 5. Constraints: Business interruption must be minimized and the issue resolved within 3 days at the latest (high risk + high priority requirement).

[0095] First, the state space S is defined (containing all the information needed for discretized decision-making): State S is a vector containing defect assessment metrics, available resources, and time constraints:

[0096] State S transforms the abstract defect management problem into computable, quantifiable data, providing a basis for subsequent decision-making.

[0097] Action space A definition (optional decisions for each state): Action A is a combination of personnel allocation, time setting, and processing strategy. Three candidate actions are designed based on the scenario:

[0098] Action A is a specific, executable plan, and each action corresponds to different risks, costs, and quality losses.

[0099] Reward function design (quantifying the quality of decision-making): The core of the reward function is to minimize the total loss; therefore, a negative sign is used to transform the loss term into a reward value (the higher the reward, the better the solution). Weights λ are set based on the scenario (based on e-commerce business priorities: risk > cost > quality loss):

[0100] in: λ1=0.5 (the risk weight is the highest, and payment defects are related to the safety of funds). λ2=0.3 (cost weight is secondary); λ3 = 0.2 (quality loss weight, which is related to user experience).

[0101] The reward values ​​for the three actions are calculated one by one below (key parameters are reasonably estimated based on the scenario): Action 1: A solo nighttime repair Risk_Exposure (Total Risk Exposure): Risk Level × Project Duration Percentage = 9900 × (8 / 72) ≈ 1100 (Short project duration, less risk exposure time); Total Cost: Repair cost (2500 yuan) + No business interruption cost (off-peak nighttime) = 2500 yuan; Quality_Loss: No user churn during the night + no deduction for system stability = 0; Reward value:

[0102] Action 2: A+B off-peak mixing strategy Risk_Exposure: 9900 × (12 / 72) ≈ 1650 (The project duration is longer than action 1, and the risk exposure increases); Total Cost: Repair cost (2500 yuan) + Off-peak service interruption cost (100 users × 10 yuan / user) = 2500 + 1000 = 3500 yuan; Quality_Loss: 100 churned users × 50 yuan / user (user lifetime value) = 5000 yuan; Reward value:

[0103] Action 3: Complete replacement of peaks A+B+C Risk_Exposure: 9900 × (4 / 72) ≈ 550 (shortest project duration, but there is an unknown compatibility risk in the replacement; after MCTS simulation, it was corrected to 800). Total Cost: Replacement cost (component purchase 1000 yuan + adaptation development 3000 yuan) + peak business interruption cost (500 users × 10 yuan / user) = 4000 + 5000 = 9000 yuan; Quality_Loss: 500 user churn × 50 yuan / user + system adaptation and stability deduction (1000 yuan) = 25000 + 1000 = 26000 yuan; Reward value:

[0104] The reward function transforms qualitative decision preferences into quantitative numerical comparisons. Action 1 has the highest reward value (-1300), initially identified as optimal, but MCTS is needed to explore unknown risks. The execution process of the hybrid algorithm (DP+MCTS) is as follows: Step 1: Dynamic Programming (Deterministic Part) Dynamic programming (DP) excels at handling deterministic problems with predictable outcomes; here, it's used to calculate the base loss for each action: The repair cost of Action 1 and the absence of business interruption during off-peak hours at night are certain, and DP directly calculates the basic reward value as -1300. The number of users experiencing outages during off-peak hours in Action 2 and the repair cost of the hybrid strategy are also predictable, with a base reward value of -2875 for DP calculation. The replacement cost of Action 3 and the number of users experiencing peak interruptions are determined by DP, with a base reward value of -8300.

[0105] Step 2: MCTS Exploration (Uncertainty Part) Monte Carlo Tree Search (MCTS) excels at handling random problems with unknown outcomes; here it's used to simulate the potential risk of each action: Uncertainty of Action 1: Whether there are hidden defects after repair; MCTS simulates 1000 repair scenarios, of which 950 have no hidden defects, and 50 require secondary repair (additional cost of 1000 yuan). The corrected reward value is: -1300 + 50 / 1000 × (-0.3 × 1000) = -1315. Uncertainty of Action 2: Whether the submodule replacement is compatible; After MCTS simulation, it was found that there is a 30% probability of compatibility failure, which requires an additional 2 hours to fix. The corrected reward value is: -2875 + 0.3 × (-0.5 × (9900 × 2 / 72) + 0.3 × (2 × 200)) = -2950; Uncertainty of Action 3: Whether the new component PayY is compatible with the existing order system; after MCTS simulation, it was found that there is a 10% probability of compatibility failure, and an emergency rollback is required (an additional loss of 5,000 yuan). The corrected reward value is: -8300 + 0.1 × (-0.3 × 5000 + 0.2 × 25000) = -8850.

[0106] Step 3: Select the optimal action Final reward value comparison: Action 1 (-1315) > Action 2 (-2950) > Action 3 (-8850), therefore, Action 1 is the final choice.

[0107] This application provides a method for managing defects in open-source components. The method involves: identifying defective open-source components; obtaining the defect priority of the open-source components; obtaining the defect repair cost of the open-source components; obtaining the defect risk level of the open-source components; determining the defect density of the open-source components based on the total number of lines of code in the functional modules embedded in the open-source components and the number of defects in the open-source components; and determining a decision on how to resolve the defects of the open-source components based on the defect priority, the defect repair cost, the defect risk level, and the defect density. This achieves the goal of automatically managing defects in open-source components.

[0108] It is understood that there are multiple ways to implement step S402. The embodiments of this application provide, but are not limited to, the following method, which includes the following steps B1 to B7.

[0109] Step B1: Obtain the scope of influence of the open source component, wherein the scope of influence represents the number of functional modules embedded in the open source component.

[0110] It is understandable that the more functional modules that embed open-source components, the greater the scope of influence of the open-source components.

[0111] Understandably, a functional module embedding an open-source component may be a preceding or subsequent functional module to other functional modules. For example, the business process of business AA is: Functional Module AA1 → Functional Module AA2 → Functional Module AA3. Functional Module AA1 is the preceding functional module of Functional Module AA2, and Functional Module AA3 is the subsequent functional module of Functional Module AA2. Assuming the functional module embedding the open-source component is Functional Module AA2, if Functional Module AA2 has defects, it may cause Business AA to fail. For example, in summary, the impact of a functional module embedding an open-source component may also include the number of preceding and subsequent functional modules.

[0112] For example, the number of preceding and subsequent functional modules of a functional module embedding an open-source component can be determined based on the business processes of each business.

[0113] Step B2: Obtain the user impact of the open source component, whereby the user impact represents the number of users who were unable to complete their business due to defects in the open source component.

[0114] It is understandable that user transactions are processed through the system server. For example, based on the attribute information of the aforementioned defect stored in the database, it can be determined which application functional modules the defect may affect. Technical experts can then use the technical usage log to identify the system server using that functional module; this system will be referred to as the affected system server. For example, user data can be retrieved from the affected system server. Each system server has a user management module, which can be used to retrieve user data. The number of users using the affected system server can then be obtained from the user data.

[0115] It is understood that the number of users accessing the affected system server is the same as the number of users mentioned in step A2 above.

[0116] Step B3: Obtain the defect reproducibility of the open source component. The defect reproducibility refers to the ratio of the number of target test cases to the total number of test cases. The target test cases refer to the test cases that reveal the defect in the open source component during the testing of the functional modules embedded in the open source component.

[0117] Defect reproducibility refers to the property of an open-source component to be repeatedly triggered under specific test conditions. In essence, a defect is highly reproducible if it can be consistently reproduced; conversely, it is low reproducible if the triggering conditions are unstable or difficult to reproduce. Highly reproducible defects are easier to locate and analyze because testers can repeat the same steps to observe the defective behavior. Developers can leverage highly reproducible defects to reproduce problems, making it easier to find and fix errors in the code.

[0118] The following example illustrates the reproducibility of defects.

[0119] Assuming the total number of test cases for testing the open-source component is 100; and the number of test cases that detect the defect in the open-source component during the testing process is 10; then the reproducibility of the defect = 10 / 100 = 0.1.

[0120] For example, defects may be sporadic, and their reproducibility can be obtained through stress testing experiments.

[0121] Step B4: Determine the severity of the defect in the open-source component based on the scope of impact, the user impact, and the reproducibility of the defect.

[0122] For example, the severity S of a defect can be calculated using the following formula: S = W1 × I + W2 × UI + W3 × R. Where I is the scope of impact, UI is the user impact, R is the reproducibility of the defect, and W1, W2, and W3 are weighting coefficients reflecting the importance of different factors in the defect severity assessment.

[0123] Step B5: Obtain the repair complexity level of the open-source component.

[0124] For example, the official website of an open-source component that discloses a defect may publish patches or version upgrades to fix the defect, or other related components that fix the defect. Based on this information, the complexity level of fixing the defect in the open-source component can be determined. For example, the complexity level can be divided into four levels: complex usability, moderate, easy, and very easy. Different ratings correspond to different fix levels.

[0125] Step B6: From the preset correspondence between development stages and repair priorities, find the target repair priority corresponding to the development stage of the functional module embedded in the open source component.

[0126] For example, the development phase includes, but is not limited to: project initiation, project development, project testing, project deployment, and project verification. Fix priority is assigned based on the development phase, with lower cost and higher priority for fixes in earlier phases. For example, project initiation corresponds to a fix priority of 10 points, project development to 20 points, project testing to 30 points, project deployment to 40 points, and project verification to 50 points.

[0127] Step B7: Obtain the defect priority based on the defect severity, the repair complexity level, and the target repair priority.

[0128] For example, the defect priority can be calculated using the following formula; Where S represents the severity of the defect, M represents the complexity level of the repair, and W4, W5, and W6 are weighting coefficients that reflect the influence of different factors in the defect priority assessment.

[0129] It is understood that there are multiple ways to implement step S404. The embodiments of this application provide, but are not limited to, the following methods, which include the following steps C1 to C4 in the real-time process.

[0130] Step C1: Obtain the target number of days since the defect in the open-source component was discovered.

[0131] Step C2: Obtain the total number of development days for the functional module embedded in the open-source component.

[0132] Step C3: Obtain the importance score of the functional module embedded in the open source component.

[0133] Step C4: Obtain the defect risk level based on the defect priority, the target number of days, the total number of development days, and the importance score.

[0134] Understandably, the earlier a defect is discovered, the lower the risk; the later a defect is discovered, the higher the risk.

[0135] Understandably, the higher the importance score of the functional module embedded in the open-source component, the higher the defect risk level; conversely, the lower the defect risk level, the lower the importance score.

[0136] For example, the defect risk level Risk = S × (1 - DSD / TDD) × MI; where DSD is the target number of days, the total development days is TDD, and MI is the importance score.

[0137] In an alternative implementation, the method may also include the following steps D1 to D4 during implementation.

[0138] Step D1: Determine the target defect type of the defect.

[0139] Step D2: Input the preset personnel identifier, historical defect repair types, expertise, and current workload correspondence, as well as the target defect type, into the pre-built personnel recommendation model, and obtain the target personnel identifier for resolving the defect through the personnel recommendation model.

[0140] For example, the personnel recommendation model is trained by taking the pre-defined personnel identifiers, historical defect repair types, expertise, and current workload correspondences, as well as sample defect types, as inputs and labeled personnel identifiers as training targets.

[0141] The process of training the personnel recommendation model involves at least one of the following machine learning techniques: artificial neural networks, belief networks, reinforcement learning, transfer learning, inductive learning, and instructional learning.

[0142] For example, the people recommendation model can be any of the following models: neural network model, logistic regression model, linear regression model, support vector machine (SVM), Adaboost, XGboost, or Transformer-Encoder model.

[0143] For example, the neural network model can be any of the following: a model based on a recurrent neural network, a model based on a convolutional neural network, or a classification model based on a Transformer-encoder.

[0144] For example, the people recommendation model can be a deep hybrid model of a recurrent neural network-based model, a convolutional neural network-based model, and a classification model based on a Transformer-encoder.

[0145] For example, the people recommendation model can be any of the following: attention-based deep model, memory network-based deep model, or deep learning-based short text classification model.

[0146] Short text classification models based on deep learning are recurrent neural networks (RNNs) or convolutional neural networks (CNNs), or variations of recurrent neural networks or convolutional neural networks.

[0147] For example, some simple domain-adaptive modifications can be made to a pre-trained model to obtain a person recommendation model.

[0148] For example, simple domain-adaptive modifications include, but are not limited to, retraining a pre-trained model using a large-scale unsupervised domain corpus, and / or compressing a pre-trained model through model distillation.

[0149] For example, supervised or semi-supervised learning can also be performed on the first machine model. Semi-supervised learning is a learning method that combines supervised and unsupervised learning. Semi-supervised learning uses a large amount of unlabeled data, as well as labeled data, to perform pattern recognition tasks.

[0150] Step D3: Create a resolution task to address the aforementioned defects in the open-source component.

[0151] Step D4: Send the task to be resolved to the communication address corresponding to the target personnel identifier.

[0152] For example, a skills database can be maintained, recording each developer's technical expertise, historical defect types fixed, and current workload. This allows for automatic matching of the most suitable personnel to handle the defect based on the target defect type. Relevant information is automatically retrieved at each stage of the defect process for automated evaluation and processing, recording the defect's current status. When manual intervention is required, information and reference information are pushed to assist in handling the issue. During the defect repair phase, information such as the defect's status and problems is recorded. Ultimately, this information forms a defect database, providing data support for subsequent defect similarity matching and recommendations.

[0153] The above describes an open-source component defect management method provided by the embodiments of this application. The following describes the apparatus for implementing the above-described open-source component defect management method.

[0154] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an open-source component defect management device provided in an embodiment of this application. Figure 5 As shown, the open-source component defect management device includes: The first determination module 501 is used to determine the open-source components that have defects; The first acquisition module 502 is used to acquire the defect priority of the open source component; The second acquisition module 503 is used to acquire the defect repair cost of the open source component; The third acquisition module 504 is used to acquire the defect risk level of the open source component; The second determining module 505 is used to determine the defect density of the open source component based on the total number of lines of code of the functional modules embedded in the open source component and the number of defects existing in the open source component. The third determining module 506 is used to determine the resolution decision of the defects of the open source component based on the defect priority, the defect repair cost, the defect risk level and the defect density.

[0155] In an optional implementation, the first acquisition module 502 includes: The first acquisition unit is used to acquire the influence range of the open source component, wherein the influence range represents the number of functional modules embedded in the open source component; The second acquisition unit is used to acquire the user impact of the open source component, wherein the user impact represents the number of users who failed to complete their business due to defects in the open source component. The third acquisition unit is used to acquire the defect reproducibility of the open source component. The defect reproducibility refers to the ratio of the number of target test cases to the total number of test cases. The target test cases refer to the test cases that test the open source component to find the defect during the testing of the functional modules embedded in the open source component. The first determining unit is used to determine the severity of the defect in the open-source component based on the scope of impact, the user impact, and the reproducibility of the defect. The fourth acquisition unit is used to acquire the repair complexity level of the open-source component; The search unit is used to search for the target repair priority corresponding to the development stage of the functional module embedded in the open source component from a preset correspondence between development stages and repair priorities. The fifth acquisition unit is used to acquire the defect priority based on the defect severity, the repair complexity level, and the target repair priority.

[0156] In one alternative implementation, the third acquisition module 504 includes: The sixth acquisition unit is used to acquire the target number of days since the defect of the open-source component was discovered; The seventh acquisition unit is used to acquire the total number of development days of the functional module embedded in the open-source component; The eighth acquisition unit is used to acquire the importance score of the functional module embedded in the open source component; The ninth acquisition unit is used to acquire the defect risk level based on the defect priority, the target number of days, the total number of development days, and the importance score.

[0157] In one alternative implementation, the third determining module 506 includes: An allocation unit is used to allocate the number of personnel to resolve the defect based on the defect repair cost; The second determining unit is used to determine the time limit for resolving the defect based on the defect risk level and the defect priority; A replacement unit is used to determine whether to replace the open-source component based on the defect density.

[0158] In one alternative implementation, it also includes: The fourth determining module is used to determine the target defect type of the defect; The fourth acquisition module is used to input the preset personnel identifier, historical defect repair types, expertise and current workload correspondence, and the target defect type into a pre-built personnel recommendation model, and obtain the target personnel identifier for solving the defect through the personnel recommendation model; Create a module for creating solutions to the aforementioned defects in the open-source component; The sending module is used to send the task to be solved to the communication address corresponding to the target personnel identifier.

[0159] This application also provides an electronic device in its embodiments. (See reference...) Figure 6 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0160] like Figure 6As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0161] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, memory cards, hard drives, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0162] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the open-source component defect management methods provided in this application.

[0163] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the open-source component defect management methods provided in this application.

[0164] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0165] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0166] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0167] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for managing defects in open-source components, characterized in that, include: Identify defective open-source components; Obtain the defect priority of the open source component; Obtain the cost of fixing defects in the open-source component; Obtain the defect risk level of the open-source component; The defect density of the open source component is determined based on the total number of lines of code in the functional modules embedded in the open source component and the number of defects existing in the open source component. Based on the defect priority, the defect repair cost, the defect risk level, and the defect density, a decision is made to resolve the defects of the open-source component.

2. The open-source component defect management method according to claim 1, characterized in that, The step of obtaining the defect priority of the open-source component includes: Obtain the scope of influence of the open-source component, wherein the scope of influence represents the number of functional modules embedded in the open-source component; The user impact of the open-source component is obtained, and the user impact represents the number of users who were unable to complete their business due to defects in the open-source component. Obtain the defect reproducibility of the open source component. The defect reproducibility refers to the ratio of the number of target test cases to the total number of test cases. The target test cases refer to the test cases that detect the defect in the open source component during the testing of the functional modules embedded in the open source component. The severity of the defect in the open-source component is determined by the scope of impact, the impact on users, and the reproducibility of the defect. Obtain the repair complexity level of the open-source component; From the preset correspondence between development stages and repair priorities, find the target repair priority corresponding to the development stage of the functional module embedded in the open source component; The defect priority is obtained based on the defect severity, the repair complexity level, and the target repair priority.

3. The open-source component defect management method according to claim 1, characterized in that, The step of obtaining the defect repair cost of the open source component includes: obtaining the defect repair cost Cost based on the expected repair time H, the hourly co-working cost RR, the number of additional resources required Rs, and the cost of each additional resource RC; Cost = (H × RR) + (Rs × RC). The process of determining the amount of additional resources includes: Obtain fix information by publishing the official website of the open source component. The fix information includes the content of the official website fix patch or version upgrade, or the content of other related components that need to be modified in sync to fix the defect. Assess the scope of impact of the remediation information, including: the number of system servers carrying the defects that need to be remediated; and whether the system servers carrying the defects that need to be remediated are internet system servers or non-internet system servers. Determine the cost of defect repair based on the scope of impact.

4. The open-source component defect management method according to claim 1, characterized in that, The step of obtaining the defect risk level of the open-source component includes: Obtain the target number of days since the defect in the open-source component was discovered; Obtain the total number of development days for the functional module embedded in the open-source component; Obtain the importance score of the functional module embedded in the open-source component; The defect risk level is obtained based on the defect priority, the target number of days, the total number of development days, and the importance score.

5. The open-source component defect management method according to any one of claims 1 to 4, characterized in that, The decision-making steps for determining the defects of the open-source component based on the defect priority, defect repair cost, defect risk level, and defect density include: The number of personnel to resolve the defect is allocated based on the defect repair cost; Based on the defect risk level and the defect priority, determine the timeframe for resolving the defect; The decision to replace the open-source component is based on the defect density.

6. The open-source component defect management method according to claim 1, characterized in that, Also includes: Determine the target defect type of the defect; The pre-defined personnel identifier, historical defect repair types, expertise, and current workload correspondence, along with the target defect type, are input into a pre-built personnel recommendation model. The target personnel identifier for resolving the defect is then obtained through the personnel recommendation model. Create a resolution task to address the aforementioned defects in the open-source component; Send the task to the communication address corresponding to the target personnel identifier.

7. An open-source component defect management device, characterized in that, include: The first identification module is used to identify open-source components with defects; The first acquisition module is used to acquire the defect priority of the open source component; The second acquisition module is used to acquire the defect repair cost of the open source component; The third acquisition module is used to acquire the defect risk level of the open source component; The second determining module is used to determine the defect density of the open source component based on the total number of lines of code of the functional modules embedded in the open source component and the number of defects existing in the open source component. The third determining module is used to determine the resolution decision of the defects of the open source component based on the defect priority, the defect repair cost, the defect risk level, and the defect density.

8. A computer program product, characterized in that, Includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the open-source component defect management method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the open-source component defect management method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the open-source component defect management method as described in any one of claims 1 to 7.

Images