Software version risk index calculation and risk management method, electronic device and storage medium

Abstract

The embodiment of the present application relates to the technical field of version risk management, in particular to a software version risk index calculation and risk management method, an electronic device and a storage medium, the embodiment of the present application obtains use case data, defect data, historical code data and requirement change data corresponding to the requirements of the version, calculates the integrated risk index of the requirements according to the use case data, the defect data, the historical code data and the requirement change data, calculates the aggregated risk index of the version according to the integrated risk indexes of all the requirements, determines the risk level of the version according to the aggregated risk index, and finally presents the risk warning mark corresponding to the risk level of the version, in this way, the risk index of the software version can be automatically and efficiently calculated, the risk of the software version can be visually monitored, the project manager or the management personnel can timely control the risk of the software version, the development progress is ensured to be as little as possible to be affected, and the software development quality is improved.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the technical field of version risk management, in particular to a software version risk index calculation and risk management method, an electronic device and a storage medium. BACKGROUND

[0002] In software project management, a software project is usually divided into a requirement analysis stage, a function development stage, a function test stage and a software delivery stage, each stage corresponds to a clear start time, an end time and a stage goal, and on-time completion of each stage goal corresponding to each stage is of great significance to the entire software project. Therefore, project managers often need to monitor the overall progress of the software project in each stage to help the entire software project team adjust the requirements and work strategies in a timely manner and ensure the smooth completion of the software project.

[0003] In the related art, for software project development, there is a lack of a clear risk identification mechanism. When the delivery delay risk of the software project needs to be monitored, the conventional method is to review the requirement information, the research and development scheme, the test document and the historical submitted weekly report and monthly report of the software project and perform summarization to obtain the overall progress completion condition of the software project, and then infer the delivery delay risk of the software project. However, the above-mentioned method needs to consume a large amount of time and effort, and the monitoring efficiency of the delivery delay risk is low and the readability is poor. Due to the lack of the risk identification mechanism, potential problems such as technical implementation difficulty, requirement change and defect solution cannot be identified as early as possible, and the development process may encounter insurmountable technical obstacles, resulting in delayed development progress or quality that cannot meet the expectation, or even leading to the failure of the entire software project. SUMMARY

[0004] Therefore, an object of the embodiment of the present application is to provide a software version risk index calculation and risk management method, an electronic device and a storage medium to solve the technical problems of low monitoring efficiency and poor readability of the software version risk in the related art.

[0005] To solve the above technical problems, the embodiment of the present application provides the following technical solutions.

[0006] In a first aspect, the embodiment of the present application provides a software version risk index calculation and risk management method, comprising:

[0007] obtaining at least one requirement of a version;

[0008] Obtaining use case data, defect data, historical code data and requirement change data corresponding to a candidate requirement, the candidate requirement being any one of at least one requirement, the use case data including test cases and states and levels of the test cases, the defect data including defects and states and levels of the defects, the historical code data including code commit times of all requirements in at least one historical version and code amounts of each commit, and the requirement change data including first requirement texts before the candidate requirement is changed and / or second requirement texts after the candidate requirement is changed;

[0009] Based on the use case data, the defect data, the historical code data and the requirement change data, an integration risk index of the candidate requirement is calculated;

[0010] Based on the integration risk indexes of all the requirements, an aggregation risk index of a version is calculated;

[0011] Based on the aggregation risk index, a risk level of the version is determined;

[0012] Based on the risk level, a risk warning mark corresponding to the risk level is generated and presented, the risk warning mark being a mark for visually representing the risk level.

[0013] In a second aspect, an embodiment of the present application provides an electronic device, comprising:

[0014] a processor and a memory connected to the processor in communication;

[0015] The memory stores computer program instructions executable by the processor, and the computer program instructions, when executed by the processor, cause the electronic device to execute the software version risk index calculation and risk control method of the first aspect.

[0016] In a third aspect, an embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores computer program instructions executable by a processor, and the computer program instructions, when executed by the processor, cause the computer to execute the software version risk index calculation and risk control method of the first aspect.

[0017] The embodiment of the present application has the following beneficial effects: Different from the prior art, the software version risk index calculation and risk management method provided by the embodiment of the present application comprises the following steps: obtaining at least one requirement of a version, obtaining use case data, defect data, historical code data and requirement change data corresponding to a candidate requirement, the candidate requirement being any one of the at least one requirement, the use case data comprising test cases and states and levels of the test cases, the defect data comprising defects and states and levels of the defects, the historical code data comprising code submission times of all requirements in at least one historical version and code amounts of each submission, the requirement change data comprising a first requirement text before the candidate requirement is changed and / or a second requirement text after the candidate requirement is changed, calculating an integrated risk index of the candidate requirement based on the use case data, the defect data, the historical code data and the requirement change data, calculating an aggregated risk index of the version based on the integrated risk indexes of all the requirements, determining a risk level of the version based on the aggregated risk index, generating a risk warning mark corresponding to the risk level based on the risk level, and presenting the risk warning mark, the risk warning mark being a mark for visually representing the risk level.

[0018] The embodiment of the present application can automatically and efficiently calculate the risk index of the software version, and visually monitor the risk of the software version, so that the project manager or the management personnel can timely manage and control the risk of the software version, as far as possible, ensure that the development progress is not affected, and improve the software development quality. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the prior art or the embodiments. Obviously, the drawings described below only show some of the embodiments of the present application, and should not be regarded as a limitation to the protection scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0020] Figure 1 is an application scenario diagram of the software version risk index calculation and risk management method provided by some embodiments of the present application;

[0021] Figure 2 is a flowchart of main steps in the software version risk index calculation and risk management method provided by some embodiments of the present application;

[0022] Figure 3 is a structural schematic diagram of an electronic device provided by some embodiments of the present application;

[0023] Figure 4 is a flowchart of a software version risk index calculation and risk management method provided by some embodiments of the present application;

[0024] Figure 5 is a schematic diagram of a test case execution process in some embodiments of the present application;

[0025] Figure 6 is a schematic diagram of a defect repair execution process in some embodiments of the present application;

[0026] Figure 7 is a schematic diagram of a risk early warning identification in some embodiments of the present application. DETAILED DESCRIPTION

[0027] In order to make the objects and advantages of the embodiments of the present application more easily understood, the technical solutions of the embodiments of the present application will be described clearly and completely below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments of the present application. The following detailed description of the embodiments of the present application in the drawings is not intended to limit the scope of the present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the present application.

[0028] It should be noted that, if there is no conflict, each technical feature involved in the embodiments of the present application described below can be combined with each other, and all fall within the scope of the present application. In addition, although the functional modules are divided in the device or structural schematic diagram, and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. In addition, the expressions "first", "second", "third" and other similar expressions used herein do not limit the data and execution order, but are only for the purpose of explanation and to distinguish the same or similar items with basically the same function and effect, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features.

[0029] Unless otherwise defined, the technical terms and scientific terms used in the specification have the same meanings as those commonly understood by those of ordinary skill in the art to which the present application belongs. The terms used in the specification are only for the purpose of describing the specific embodiments and are not intended to limit the present application. It should be understood that the term "and / or" used in the specification includes any and all combinations of one or more listed items.

[0030] Referring to Figure 1 and Figure 2 , Figure 1 application scenarios of the software version risk index calculation and risk management method provided by some embodiments of the present application are shown, Figure 2 a flowchart of main steps in the software version risk index calculation and risk management method provided by some embodiments of the present application is shown.

[0031] As Figure 1 shown, the application scenario includes an electronic device 100, a first engine 10, a second engine 20, a third engine 30, a fourth engine 40 and a fifth engine 50, wherein the electronic device 100 is communicatively connected with the first engine 10, the second engine 20, the third engine 30, the fourth engine 40 and the fifth engine 50 through a communication network, which includes but is not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0032] Specifically, in the actual application of software development management, the first engine 10 is used to collect and provide requirements, and a user (such as a project manager, etc.) can publish requirements in the first engine 10. The first engine 10 collects multiple requirements for the same version of the same project, forms a requirement set, and stores the requirement set in a local storage, a cloud server or any other suitable medium. In the embodiments of the present application, the first engine 10 can be a project management tool "Redmine" or any other suitable system, tool or software, etc., and the embodiments of the present application do not make any limitation thereto.

[0033] In some embodiments, the electronic device 100 obtains a requirement set B of version A from the first engine 10, and the requirement set B includes at least one requirement (such as Figure 2 requirements B1, B2, B3 and B4 shown in FIG. 1). It can be understood that the requirement refers to the description of the function that the software system needs to implement, for example, the function that needs to be implemented is to count the number of patents and patent applications. The requirement can be to count the number of patents and patent applications in any time period, and can be counted in multiple aspects according to the application type, application time, authorization or not and legal status, etc.

[0034] It should be understood that one version of one project includes one or more requirements, one requirement can be divided into multiple refined sub-requirements, and multiple sub-requirements correspond to one requirement, for example, the requirement is to realize the patent and patent application quantity statistics function, and the divided multiple sub-requirements can include patent input requirements, patent information (including, for example, application time, application type, and whether authorized) acquisition requirements, and patent statistics requirements, and the like. The requirements are assigned to specific developers, and when each requirement is newly created, the man-hours of each requirement are preset, so that each requirement has a corresponding consumed man-hour (i.e., the man-hour required by the developer to solve each requirement). The consumed man-hours of the requirements are used for the project manager or the management personnel to control and manage the resource situation of the developers, and the scheduling plan of the project testing and delivery, and the like, to promote the development progress of the software project.

[0035] Specifically, the second engine 20 is used to collect and provide use cases, and the use case refers to a test case used to test the implementation of each function of the software in the software development and defects, and the use case is associated with the requirement, that is, the use case is a test case for a specific requirement. The user can publish the use case in the second engine 20, the second engine 20 collects the use cases for the same requirement, forms use case data, and stores the use case data in the local storage, the cloud server, or other any suitable medium. The use case data includes the test case and the state and level of the test case. In some embodiments of the present application, the second engine 20 can be a software testing platform "MeterSphere" or other any suitable system, platform, or software, and the embodiments of the present application do not make any limitation thereto.

[0036] Specifically, the third engine 30 is used to collect and provide defects, and the defect refers to a problem that the actual result does not match the requirement expectation, and the defect is associated with the requirement, that is, the defect is a problem for a specific requirement. The user can publish the defect in the third engine 30, wherein the third engine 30 collects the defects for the same requirement, forms defect data, and stores the defect data in the local storage, the cloud server, or other any suitable medium. The defect data includes the defect and the state and level of the defect. In the embodiments of the present application, the third engine 30 can be a project management software "Zen" or other any suitable system, tool, or software, and the embodiments of the present application do not make any limitation thereto.

[0037] Exemplarily, the fourth engine 40 is configured to collect and provide historical code data, the historical code data including code submission data of all requirements in at least one historical version, the code submission data including code submission times of the requirements and code amount, submission time and submitter of each submission. The code submission data is associated with the requirements, i.e. the code submission data is the data related to code submission events of a specific requirement. The user can submit code data in the fourth engine 40, and the fourth engine 40 collects the code data of the same requirement, records the code submission times and code amount, submission time and submitter of each submission, thereby forming the code submission data. The fourth engine 40 collects all the code submission data of the requirements of each specific historical version, obtains the historical code data of each historical version, and stores the historical code data in the local storage, cloud server or other suitable storage medium. In the embodiment of the present application, the fourth engine 40 can be a project code management system "GitHub" or other suitable platform, tool or software, which is not limited in the embodiment of the present application.

[0038] Exemplarily, the fifth engine 50 is configured to collect and provide requirement change data, the requirement change data including first requirement text before the requirement change and / or second requirement text after the requirement change, i.e. the requirement change data is used to record the requirement text before and after the requirement change. The requirement change data is associated with the requirements, i.e. the requirement change data is the data before and after the change of a specific requirement. The user can publish the requirement text in the fifth engine 50, and the fifth engine 50 collects the first requirement text before the change and / or the second requirement text after the change of the same requirement, records the change time and changer of the requirement text, thereby forming the requirement change data, and stores the requirement change data in the local storage, cloud server or other suitable storage medium. In the embodiment of the present application, the fifth engine 50 can be a project management software "Redmine" or other suitable system, tool or software, which is not limited in the embodiment of the present application.

[0039] It can be understood that for the newly added requirements, the requirement change data does not have the first requirement text before the change and has the second requirement text after the change. For the deleted requirements, the requirement change data has the first requirement text before the change and does not have the second requirement text after the change.

[0040] In some embodiments, the electronic device 100 obtains, from the second engine 20, the use case data corresponding to the candidate requirement according to the obtained requirement set B, obtains, from the third engine 30, the defect data corresponding to the candidate requirement, obtains, from the fourth engine 40, the historical code data corresponding to the candidate requirement, and obtains, from the fifth engine 50, the requirement change data corresponding to the candidate requirement. The candidate requirement can be any one of the requirements in the requirement set B (for example, the candidate requirement is requirement B4). The historical code data corresponding to the candidate requirement obtained from the fourth engine 40 refers to determining the historical version in the software project corresponding to the reference version according to the reference version to which the candidate requirement belongs, searching and obtaining the historical code data of the historical version in the fourth engine 40, and thus obtaining the historical code data corresponding to the candidate requirement. It is easily understood that the historical version includes one or more, and for the purpose of easy understanding and description, the historical code data of the historical version with the closest release time to the reference version is selected as the historical code data corresponding to the candidate requirement.

[0041] Specifically, please refer to Figure 2 The electronic device 100 obtains the requirement set B of the version A of the software project from the first engine 10, and the requirement set B includes four requirements, i.e., requirement B1, requirement B2, requirement B3 and requirement B4. After selecting requirement B4 as the candidate requirement, the electronic device 100 obtains the data corresponding to requirement B4 from each engine to obtain the data set C4. That is, the use case data C41 corresponding to requirement B4 is obtained from the second engine 20, the defect data C42 corresponding to requirement B4 is obtained from the third engine 30, the historical code data C43 corresponding to requirement B4 is obtained from the fourth engine 40, and the requirement change data C44 corresponding to requirement B4 is obtained from the fifth engine 50. According to the use case data C41, the defect data C42, the historical code data C43 and the requirement change data C44, the integration risk index of requirement B4 is calculated. For other requirements in the requirement set B, the same method as described above is used to calculate the integration risk index of each requirement. After calculating the integration risk index of each requirement in the requirement set B, the electronic device 100 calculates the aggregation risk index of version A according to the integration risk indexes of all requirements (i.e., requirement B1, requirement B2, requirement B3 and requirement B4) in the requirement set B, determines the risk level of version A according to the aggregation risk index of version A, generates the risk warning identifier of version A according to the risk level of version A, and finally presents the risk warning identifier of version A.

[0042] In the above manner, the embodiments of the present application can automatically and efficiently calculate the risk index of the software version, and visually monitor the risk of the software version, so that the project manager or the management personnel can timely control the risk of the software version, as far as possible to ensure that the development progress is not affected, and the software development quality is improved.

[0043] It should be understood that, Figure 1 In the application scenario shown, the electronic device 100 is a laptop computer. This does not limit the structure, type, quantity, acquisition requirements, or the method of obtaining data corresponding to those requirements of the electronic device 100 in other application scenarios or embodiments. For example, in some other application scenarios or embodiments, the electronic device may also be a desktop computer, tablet computer, microcontroller, microcontroller, or other suitable type of device or apparatus. The data corresponding to the requirements is stored in the same storage medium. In this case, the electronic device directly obtains the use case data, defect data, historical code data, and requirement change data corresponding to the requirements from one storage medium, without having to obtain the corresponding data from multiple engines separately.

[0044] To facilitate understanding of the software version risk index calculation and risk management method provided in the embodiments of the present invention, the electronic device provided in the embodiments of the present invention will first be described in detail.

[0045] Please see Figure 3 , Figure 3 The schematic diagram illustrates the structure of an electronic device provided by some embodiments of the present invention.

[0046] like Figure 3 As shown, the electronic device 100 includes at least one processor 110 and a memory 120 connected in communication. Figure 3 Taking a bus system 130 and a processor as an example, the various components in the electronic device 100 are coupled together through the bus system 130, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 130 may include not only a data bus, but also a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, in... Figure 3 The general labels all buses as Bus System 130. Understandably, Figure 3 The structures shown in the embodiments are merely illustrative and do not limit the structure of the electronic device described above. For example, the electronic device may also include components that are larger than... Figure 3 The structure shown has more or fewer components, or has the same as Figure 3 The diagram shows different configurations of the structure.

[0047] In particular, the processor 110 is configured to provide operation and control capabilities to control the electronic device 100 to perform corresponding tasks, for example, to control the electronic device 100 to perform any one of the software version risk index calculation and risk management methods provided by the embodiments of the present application, or to perform steps in any one of the possible implementation manners of any one of the software version risk index calculation and risk management methods provided by the embodiments of the present application. Those skilled in the art can understand that the processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; and can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0048] The memory 120, as a non-transitory computer readable storage medium, can be configured to store non-transitory software programs, non-transitory computer executable programs, instructions and modules, for example, programs, instructions and modules corresponding to the software version risk index calculation and risk management methods in the embodiments of the present application. In some embodiments, the memory 120 can include a program storage area and a data storage area, the program storage area can store an operating system and at least one application required by a function, and the data storage area can store data created according to the use of the processor 110, etc. The processor 110 performs various functional applications and data processing of the electronic device 100 by running the non-transitory software programs, instructions and modules stored in the memory 120, so as to implement any one of the software version risk index calculation and risk management methods provided by the embodiments of the present application, or to perform steps in any one of the possible implementation manners of any one of the software version risk index calculation and risk management methods provided by the embodiments of the present application. In some embodiments, the memory 120 can include a high-speed random access memory, and can also include a non-transitory memory, for example, at least one magnetic disk storage device, a flash memory device or other non-transitory solid-state memory device. In some embodiments, the memory 120 can also include a memory remotely arranged with respect to the processor 110, and the remotely arranged memory can be connected to the processor 110 through a communication network. It can be understood that examples of the above communication network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0049] According to the above, it can be understood that the implementation subject of any one of the software version risk index calculation and risk control method provided by the embodiments of the present application can be any suitable type of electronic device with certain calculation and control capabilities, for example, can be implemented by the electronic device 100 described above. In some feasible implementations, the software version risk index calculation and risk control method provided by the embodiments of the present application can be implemented by a processor executing computer program instructions stored in a memory.

[0050] The software version risk index calculation and risk control method provided by the embodiments of the present application will be described in detail below in combination with the exemplary application and implementation of the electronic device provided by the embodiments of the present application.

[0051] Please refer to Figure 4 , Figure 4 The flowchart of the software version risk index calculation and risk control method provided by some embodiments of the present application is schematically shown.

[0052] Those skilled in the art can understand that the software version risk index calculation and risk control method provided by the embodiments of the present application can be applied to the electronic device (for example, the electronic device 100) described above. Specifically, the execution subject of the software version risk index calculation and risk control method is one or at least two processors of the electronic device.

[0053] As shown in Figure 4 , the software version risk index calculation and risk control method includes but is not limited to the following steps S100-S600:

[0054] S100: Obtain at least one requirement of the version.

[0055] For example, the embodiments of the present application obtain a requirement set of a version of a software project from a project management tool "Redmine" or any other suitable system, tool or software, etc., and the requirement set includes at least one requirement, thereby obtaining at least one requirement of the version.

[0056] S200: Obtain use case data, defect data, historical code data and requirement change data corresponding to the candidate requirement.

[0057] Specifically, any one of the requirements in the requirement set is selected as a candidate requirement, that is, any one of the at least one requirement is selected as the candidate requirement. The embodiment of the present application obtains the use case data corresponding to the candidate requirement from the software test platform "MeterSphere" or any other suitable system, platform or software, obtains the defect data corresponding to the candidate requirement from the project management software "Zen" or any other suitable system, tool or software, obtains the historical code data corresponding to the candidate requirement from the project code management system "GitHub" or any other suitable platform, tool or software, and obtains the requirement change data corresponding to the candidate requirement from the project management software "Redmine" or any other suitable system, tool or software.

[0058] In the embodiment of the present application, the use case data includes test cases and the status and level of the test cases. The status of the test cases includes a pass state P, a failure state F, a block state B and a non-execution state N. The pass state P indicates that the test case has been executed and passed successfully. The failure state F indicates that the test case has been executed but failed, and the test case needs to be executed again after the problem is fixed. The block state B indicates that the execution of the test case is blocked (for example, there is a problem with the environment configuration), and the test case needs to be executed again after the block is resolved. The non-execution state N indicates that the test case has not been executed, and the test case needs to be executed. The level of the test case includes multiple levels, such as a first level, a second level and a third level. Each level is used to indicate the degree of influence of the test case on the risk index. For example, in some embodiments, the weights corresponding to the first level, the second level and the third level are 0.5, 0.3 and 0.2 respectively. Obviously, the degree of influence of the test case of the first level on the risk index is greater than that of the test case of the second level, and the degree of influence of the test case of the second level on the risk index is greater than that of the test case of the third level.

[0059] In the embodiments of the present application, the defect data includes defects and states and levels of the defects, the states of the defects include a new state N, a repair state R, a verification state V, a close state C and an invalid state I. The new state N indicates that the defect has been created but not repaired, the repair state R indicates that the defect has been confirmed to exist and needs to be repaired, the defect in the repair state R needs to be repaired by the corresponding developer. The verification state V indicates that the defect has been repaired and needs to be verified by the corresponding tester to determine whether the defect is successfully repaired. The close state C indicates that the defect has been repaired and verified, and the defect in the close state C is closed. The invalid state I indicates that the defect is misjudged when created, the defect actually does not exist or does not need to be repaired, and the defect in the invalid state I is closed. The levels of the defects include multiple levels, for example, a first level, a second level and a third level, and each level is used to indicate the influence degree of the defect on the risk index. In some embodiments, the weights of the first level, the second level and the third level are 0.5, 0.3 and 0.2 respectively. Obviously, the influence degree of the defect in the first level on the risk index is greater than the influence degree of the defect in the second level on the risk index, and the influence degree of the defect in the second level on the risk index is greater than the influence degree of the defect in the third level on the risk index.

[0060] In the embodiments, the historical code data includes code submission data of all requirements in at least one historical version, and the code submission data includes code submission times of the requirements, code amounts of each submission, submission times and submitters, etc. In some embodiments, the historical code data corresponding to the candidate requirement (i.e. the historical code data of at least one historical version) is shown in Table 1 as follows:

[0061] Table 1:

[0062]

[0063] According to Table 1, the requirement Z1 submits three times of codes totally with 110 lines of code. The first time of code submission is 80 lines of code (i.e., the first time of code submission), the second time of code submission is 10 lines of code (i.e., the second time of code submission), and the third time of code submission is 20 lines of code (i.e., the third time of code submission). After the third time of code submission, the code submission is switched to other requirements, i.e., the code of other requirements is submitted. The requirement Z2 submits three times of codes totally with 100 lines of code. The first time of code submission is 50 lines of code (i.e., the first time of code submission), the second time of code submission is 40 lines of code (i.e., the second time of code submission), and after the second time of code submission, the code submission is switched to other requirements, i.e., the code of other requirements is submitted. The third time of code submission of the requirement Z2 is 10 lines of code (i.e., the third time of code submission). The requirement Z3 submits three times of codes totally with 120 lines of code. The first time of code submission is 70 lines of code (i.e., the first time of code submission), the second time of code submission is 40 lines of code (i.e., the second time of code submission), and after the second time of code submission, the code submission is switched to other requirements, i.e., the code of other requirements is submitted. The third time of code submission of the requirement Z3 is 10 lines of code (i.e., the third time of code submission).

[0064] It can be understood that the above Table 1 is only exemplary, and the historical code data can further include more or less requirements, and the number of times of code submission and the amount of code submitted by each requirement can be the same or different. One or more historical versions of the historical code data can be obtained by a person skilled in the art, or the initial amount of code, the reference amount of code and the total amount of code can be set according to empirical data, experimental data, etc., and the embodiments of the present application do not make any limitation thereto.

[0065] In the embodiments of the present application, the requirement change data includes the first requirement text before the candidate requirement change and / or the second requirement text after the change, and the candidate requirement is determined to be a new, modified or deleted requirement according to the requirement change data, so that different methods are used to calculate the corresponding risk index according to different types of requirements.

[0066] S300: The integration risk index of the candidate requirement is calculated based on the use case data, the defect data, the historical code data and the requirement change data.

[0067] It can be understood that the integration risk index is a value for measuring the integration risk of a single requirement in the implementation, testing, change, etc. of the current version.

[0068] For example, the test risk index of the candidate requirement is calculated according to the use case data and the defect data, the development risk index of the candidate requirement is calculated according to the historical code data, the product risk index of the candidate requirement is calculated according to the requirement change data, and the integration risk index of the candidate requirement is calculated according to the test risk index, the development risk index and the product risk index.

[0069] Exemplarily, in some embodiments, based on the use case data, the defect data, the historical code data, and the requirement change data, the integration risk index of the candidate requirement is calculated, specifically including but not limited to the following steps S310-S340:

[0070] S310: Based on the use case data and the defect data, the test risk index of the candidate requirement is calculated.

[0071] In this embodiment, the test risk index mainly focuses on the completeness and quality of the function implementation, and considers the test case and the defect of each requirement in the version as two risk factors. The test case represents the expected function delivery range and is the basis for software acceptance, while the defect reflects the deviation between the actual result and the expected function. By repairing, it is ensured that the software delivery result meets the quality target. The test case defines the "standard to be reached", the defect exposes the "actual gap", and the repair realizes the "standard alignment". Based on the two risk factors of the test case and the defect repair, the quality of the function implementation of each requirement can be well evaluated.

[0072] Specifically, the state and level of the test case affect the calculation of the risk index. According to the state, weight, and number of test cases of each state of the first level test case, the state, weight, and number of test cases of each state of the second level test case, and the state, weight, and number of test cases of each state of the third level test case, the use case risk index of the candidate requirement is calculated. The state and level of the defect affect the calculation of the risk index. According to the state, weight, and number of defects of each state of the first level defect, the state, weight, and number of defects of each state of the second level defect, and the state, weight, and number of defects of each state of the third level defect, the defect risk index of the candidate requirement is calculated. Finally, the use case risk index and the defect risk index of the candidate requirement are weighted and summed to obtain the test risk index of the candidate requirement.

[0073] Exemplarily, in some embodiments, based on the use case data and the defect data, the test risk index of the candidate requirement is calculated, specifically including but not limited to the following steps S311-S313:

[0074] S311: Based on the state and level of the test case in the use case data, the use case risk index of the candidate requirement is calculated.

[0075] Specifically, according to the level of the test case in the use case data, the test cases of the same level are divided into the same set, and a plurality of test case sets are obtained, one test case set including one or more test cases of a reference level, and the execution of the test cases of each level has different influence on the risk index. The reference level is any one of the preset levels of the test cases (such as the first level, the second level, and the third level, etc.). It is easily understood that the level of the test case can also be expressed in other ways, such as high level, medium level, and low level, and the embodiments of the present application do not make any limitation on this.

[0076] In some embodiments, the first workload sum is calculated according to the state of the test case in the candidate test case set. The candidate test case set is any one of the plurality of test case sets. When the test case in the candidate test case set is in a certain state, the workload of each work item that has been executed is determined when the test case is in the certain state, the workload of each work item that has been executed is calculated as the workload of the test case, and the workloads of all test cases in the candidate test case set are added to obtain the first workload sum.

[0077] Please refer to Figure 5 , Figure 5 A schematic diagram of the test case execution process is shown. When the test case is in the pass state P, it means that the test case is executed and successfully executed, the first work items that have been executed include identifying the test case exeI and executing the test case exeC, and the workloads of identifying the test case exeI and executing the test case exeC are calculated as the workload of the test case in the pass state P.

[0078] When the test case is in the failure state F, it means that the test case is executed but fails, and needs to be repaired and executed again. At this time, the second work items that have been executed include identifying the test case exeI, executing the test case exeC, and repairing the failed test case fixF, and the workloads of identifying the test case exeI, executing the test case exeC, and repairing the failed test case fixF are calculated as the workload of the test case in the failure state F.

[0079] When the test case is in the block state B, it means that the test case is executed but there is an obstacle in the execution, and needs to be solved and executed again. At this time, the third work items that have been executed include identifying the test case exeI, executing the test case exeC, and solving the execution obstacle fixB, and the workloads of identifying the test case exeI, executing the test case exeC, and solving the execution obstacle fixB are calculated as the workload of the test case in the block state B.

[0080] When the test case is in the unexecuted state N, it means that the test case has not been executed, and the fourth work item that has been executed includes identifying the test case exeI, calculating the work amount of the identified test case exeI as the work amount of the test case in the unexecuted state N.

[0081] It can be understood that the work amount of the identified test case exeI refers to the benchmark work amount of identifying one test case, the work amount of the executed test case exeC refers to the work amount of executing one test case, the work amount of the fixed failed test case fixF refers to the additional work amount of fixing one failed test case (including the work amount of fixing the code and the regression test), and the work amount of the fixed execution barrier fixB refers to the work amount of solving one test case barrier (i.e., the test case in the barrier state B) (including the work amount of fixing the environment problem and the regression test). The designer presets the work amount of each work item (including identifying the test case exeI, executing the test case exeC, fixing the failed test case fixF, and fixing the execution barrier fixB) according to historical data, experience values, and the like, and the work amount unit can be time, day, and the like.

[0082] In some embodiments, the first standard work total amount of the standard test case in the candidate test case set is determined according to the first work amount total sum, and the standard test case is the test case in the passed state P. For example, as described above, the work amount total sum of all test cases in the candidate test case set (i.e., the first work amount total sum) has been calculated, and the first standard work total amount of the standard test case in the candidate test case set is filtered from the first work amount total sum. Apparently, the standard test case in the candidate test case set can be zero, one, or more.

[0083] In some embodiments, the test progress value of the test case of the reference level is calculated according to the first work amount total sum and the first standard work total amount, and the risk coefficient corresponding to the test progress value is determined as the risk coefficient of the test case of the reference level in the candidate test case set according to the corresponding relationship table of the test progress value and the risk coefficient.

[0084] In some embodiments of the present application, the test case risk index of the candidate requirement is calculated according to the risk coefficients of the test cases of the reference level in the all test case set. That is, the risk coefficients of all test cases of the reference level are weighted and added according to the weight coefficients corresponding to the test cases of the reference level to obtain the test case risk index of the candidate requirement.

[0085] For example, the corresponding relationship table of the state and the work amount of the test case of the reference level in the test case set is shown in Table 2 as follows:

[0086] Table 2:

[0087]

[0088] In some embodiments, the corresponding relationship table between the test progress of the test case of the reference level in the test case set and the risk coefficient is shown in Table 3 as follows:

[0089] Table 3:

[0090]

[0091] According to Table 2, the first total workload is calculated according to the state of the test case in the candidate test case set. Apparently, the first total workload . The first standard total workload of the standard test case is , and the test progress value of the test case of the reference level is . According to Table 3 above, the test progress value of the test case of the reference level is , located in the test threshold range , and the risk coefficient corresponding to the test threshold range is . Therefore, the risk coefficient is determined as the risk coefficient of the test case of the reference level.

[0092] Suppose that three test case sets are divided, including the test case of the first level, the test case of the second level and the test case of the third level. The risk coefficient and the weight coefficient of the test case of the first level are and , respectively. The risk coefficient and the weight coefficient of the test case of the second level are and , respectively. The risk coefficient and the weight coefficient of the test case of the third level are and , respectively. Then, the test case risk index of the candidate requirement is calculated as .

[0093] It can be understood that the above-mentioned Table 2 and Table 3 are only exemplary, and the corresponding relationship table between the state of the test case of different levels and the workload, and the corresponding relationship table between the test progress and the risk coefficient are the same or different. The designer designs the corresponding relationship table between the state of the test case of each level and the workload, and the corresponding relationship table between the test progress and the risk coefficient according to the experience data, experimental data and the like, and the embodiments of the present application do not make any limitation thereto.

[0094] S312: Calculate the defect risk index of the candidate requirement based on the state and level of the defect in the defect data.

[0095] For example, according to the levels of the defects in the defect data, the defects of the same level are classified into the same set, and a plurality of defect sets are obtained, one defect set including one or more defects of a reference level, and the processing conditions of the defects of each level have different influence degrees on the risk index. The reference level is any one of preset levels (for example, the first level, the second level, and the third level, etc.), and it is easily understood that the level of the defect can also be expressed in other manners, for example, high level, medium level, low level, etc., and the embodiments of the present application do not make any limitation in this regard.

[0096] In some embodiments, the second total work amount is calculated according to the states of the defects in the candidate defect set. The candidate defect set is any one of the plurality of defect sets. When the defects in the candidate defect set are in a certain state, the work amounts of the work items that have been performed when the defects are in the certain state are determined, the work amounts of the work items that have been performed are calculated as the work amounts of the defects, and the work amounts of all the defects in the candidate defect set are added to obtain the second total work amount.

[0097] Please refer to Figure 6 , Figure 6 A schematic diagram of a defect repair execution process is shown. When the defect is in the new state N, it means that the defect is just created and whether the defect needs to be repaired is not confirmed. At this time, the fifth work item that has been performed includes identifying the defect bug I, and the work amount of identifying the defect bug I is calculated as the work amount of the defect in the new state N.

[0098] When the defect is in the repair state R, it means that the existence of the defect is identified and the defect needs to be repaired, but the repair has not been performed and needs to be performed by the developer; or the repair is being performed and has not been completed. At this time, the sixth work item that has been performed includes identifying the defect bug I and confirming the defect bug C, and the work amounts of identifying the defect bug I and confirming the defect bug C are calculated as the work amounts of the defect in the repair state R.

[0099] When the defect is in the verification state V, it means that the defect has been modified but has not been verified, and needs to be verified by the tester; or the defect has been modified and is being verified, and has not been completed. At this time, the seventh work item that has been performed includes identifying the defect bug I, confirming the defect bug C, and repairing the defect bug R, and the work amounts of identifying the defect bug I, confirming the defect bug C, and repairing the defect bug R are calculated as the work amounts of the defect in the verification state V.

[0100] When the bug is in the closed state C, it means that the bug has been fixed and verified, at this time, the eighth work item that has been performed includes identifying the bug bug I, confirming the bug bug C, fixing the bug bug R and verifying the bug bug V, and the work amount of identifying the bug bug I, confirming the bug bug C, fixing the bug bug R and verifying the bug bug V is calculated as the work amount of the bug in the unperformed state N.

[0101] When the bug is in the invalid state I, it means that the bug does not exist or does not need to be fixed, and does not need to be fixed by the developer, and can be directly closed, at this time, the ninth work item that has been performed includes identifying the bug bug I and confirming the bug bug C, and the work amount of identifying the bug bug I and confirming the bug bug C is calculated as the work amount of the bug in the invalid state I.

[0102] It can be understood that the work amount of identifying the bug bug I refers to the reference work amount of identifying one bug, the work amount of confirming the bug bug C refers to the reference work amount of confirming one bug (including the work amount of confirming the specific content of the bug, the bug level, the bug fixing personnel and the preset fixing time), the work amount of fixing the bug bug R refers to the additional work amount of fixing one bug (including the work amount of fixing the code), and the work amount of verifying the bug bug V refers to the work amount of verifying one modified bug (including the work amount of verification test). It is easy to understand that the designer presets the work amount of each work item (including identifying the bug bug I, confirming the bug bug C, fixing the bug bug R and verifying the bug bug V) according to historical data, experience value, etc., and the work amount unit can be time, day, etc.

[0103] In some embodiments, according to the second work amount sum, a second standard work total amount of standard bugs in the candidate bug set is determined, and the standard bug is a bug in the closed state C or the invalid state I. For example, as described above, the sum of the work amounts of all bugs in the candidate bug set (i.e. the second work amount sum) has been calculated, and then the second standard work total amount of the standard bugs in the candidate bug set is screened from the second work amount sum. Obviously, the standard bugs in the candidate bug set can be zero, one or more.

[0104] In some embodiments, according to the second work amount sum and the second standard work total amount, a fixing progress value of the reference level bug is calculated, and according to the corresponding relationship table of the fixing progress value and the risk coefficient, the risk coefficient corresponding to the fixing progress value is determined as the risk coefficient of the reference level bug in the candidate bug set.

[0105] In some embodiments, the defect risk index of the candidate requirement is calculated according to the risk coefficients of the defects of the reference level in the defect set. That is, the risk coefficients of the defects of all the reference levels are weighted and added according to the weight coefficients corresponding to the defects of the reference levels to obtain the defect risk index of the candidate requirement.

[0106] For example, the correspondence table between the state of the defects of the reference level in the defect set and the workload is shown in Table 4 as follows:

[0107] Table 4:

[0108]

[0109] In some embodiments, the correspondence table between the repair progress of the defects of the reference level in the defect set and the risk coefficient is shown in Table 5 as follows:

[0110] Table 5:

[0111]

[0112] According to Table 4, the second workload sum is calculated according to the state of the defects in the candidate defect set, and the second workload sum . The second standard workload of the standard defect is , and the repair progress value of the defect of the reference level is . According to Table 5 above, when the repair progress value of the defect of the reference level is , the risk coefficient corresponding to the repair progress value is , and the risk coefficient is determined as the risk coefficient of the defect of the reference level.

[0113] For example, it is assumed that three defect sets are divided, including defects of the first level, defects of the second level and defects of the third level, wherein the risk coefficient and the weight coefficient of the defects of the first level are and , the risk coefficient and the weight coefficient of the defects of the second level are and , and the risk coefficient and the weight coefficient of the defects of the third level are and , and the defect risk index of the candidate requirement is calculated as .

[0114] It can be understood that the above Table 4 and Table 5 are only exemplary, and the state and workload correspondence table of different levels of defects, the repair progress and risk coefficient correspondence table are the same or different. The designer designs the state and workload correspondence table of each level of defects, the repair progress and risk coefficient correspondence table according to experience data, experimental data, etc. The present embodiment does not make any limitation.

[0115] S313: Based on the use case risk index and the defect risk index, the test risk index of the candidate requirement is calculated.

[0116] For example, according to the influence degree of the use case risk index on the test risk index, the weight of the use case risk index is set in advance, and according to the influence degree of the defect risk index on the test risk index, the weight of the defect risk index is set in advance. The weight of the use case risk index and the weight of the defect risk index are obtained, and the use case risk index and the defect risk index are weighted and summed according to the obtained weight of the use case risk index and the weight of the defect risk index, to obtain the test risk index of the candidate requirement. That is, the use case risk index is multiplied by the weight of the use case risk index to obtain the use case risk index result, the defect risk index is multiplied by the weight of the defect risk index to obtain the defect risk index result, and the use case risk index result and the defect risk index result are added to obtain the test risk index of the candidate requirement.

[0117] For example, the use case risk index and the defect risk index are respectively and The weight of the use case risk index and the weight of the defect risk index are respectively and The test risk index of the candidate requirement is .

[0118] S320: Based on historical code data, the development risk index of the candidate requirement is calculated.

[0119] In this embodiment, the development risk index mainly focuses on the management and cooperation of the code in the software version development process. The code is the core in the version development and is the final carrier of the version. The progress, frequency and quality of code submission will directly affect the stability of requirement function and performance and the team cooperation efficiency.

[0120] For example, the development risk index of the candidate requirement is calculated according to the code submission data of all the requirements corresponding to the candidate developer in at least one historical version (i.e., the number of code submissions of all the requirements corresponding to the candidate developer and the code amount of each submission, hereinafter referred to as reference code data). The candidate developer is the developer corresponding to the candidate requirement, i.e., the developer responsible for processing the candidate requirement. Based on the reference code data, the total code reference amount is calculated, which refers to the sum of the code amounts of all the requirements corresponding to the candidate developer submitted in the reference code data. If there is no available or valid reference code data, the candidate developer sets any reasonable total code reference amount corresponding to the reference version to which the candidate requirement belongs. According to the number of code submissions of all the requirements corresponding to the candidate developer in the reference code data, the code amount of each submission, and the total code reference amount, the code development progress value of the candidate requirement is calculated. That is, when the code of the candidate requirement is submitted for the first time, the sum of the code amounts of the first submission of all the requirements corresponding to the candidate developer is divided by the total code reference amount to obtain the code development progress value when the code of the candidate requirement is submitted for the first time. According to the code development progress value when the code of the candidate requirement is submitted for the first time and the preset corresponding relationship table of code development progress and risk index, the development risk index of the candidate requirement is determined.

[0121] For example, the corresponding relationship table of code development progress and risk index is shown in Table 6.

[0122] Table 6:

[0123]

[0124] The requirements corresponding to the candidate developer in the historical code data shown in Table 1 include requirement Z1 and requirement Z2 (i.e., the candidate developer is responsible for processing requirement Z1 and requirement Z2 / candidate developer submits the code data of requirement Z1 and requirement Z2), and the reference code data includes the code data of requirement Z1 and requirement Z2 submitted by the candidate developer. According to Table 1 and Table 6, the code amounts of the first submission of the two requirements (i.e., requirement Z1 and requirement Z2) corresponding to the candidate developer in the reference code data are and respectively. The sum of the code amounts of the first submission of all the requirements in the reference code data is , the total code reference amount is , and the code development progress value when the code of the candidate requirement is submitted for the first time is calculated as . According to Table 6, the risk index corresponding to the code development progress value is , and the risk index is determined as the development risk index of the candidate requirement.

[0125] When detecting the code submitted to other requirements, the sum of the code amount submitted by all requirements in the reference code data to other requirements different from them is calculated according to the code submission times of all requirements corresponding to the candidate developer in the reference code data, the code amount of each submission and the total code reference amount, and the total code amount submitted is obtained. The total code amount submitted is divided by the total code reference amount to obtain the code development progress value of the candidate requirement when submitting code to other requirements, and the development risk index of the candidate requirement is determined according to the code development progress value of the candidate requirement when submitting code to other requirements and the corresponding relationship table of code development progress and risk index.

[0126] It can be understood that the candidate developer tests the submitted code data by using the self-test case after the last submission of the code. When detecting that the self-test case of the candidate requirement is executed, it indicates that the candidate developer has submitted all the code data, and at this time, the code development progress value is According to Table 6, the risk index corresponding to the code development progress value is the development risk index of the candidate requirement.

[0127] Exemplarily, in some embodiments, the development risk index of the candidate requirement is calculated based on the historical code data, specifically including but not limited to the following steps S321-S324:

[0128] S321: Extracting reference code data from the historical code data.

[0129] In this embodiment, the reference code data includes the code submission times and the code amount of each submission of all requirements corresponding to the candidate developer in at least one historical version, and the candidate developer is the developer corresponding to the candidate requirement.

[0130] Specifically, the reference code data is extracted from the historical code data, that is, the code submission times and the code amount of each submission of all requirements corresponding to the candidate developer are extracted, for example, refer to Table 1, the requirements corresponding to the candidate developer include requirement Z1 and requirement Z2, and the code submission times and the code amount of each submission of requirement Z1 and requirement Z2 are extracted as the reference code data.

[0131] S322: Calculating the total code reference amount based on the reference code data.

[0132] S323: In response to detecting the first submission of the code corresponding to the candidate requirement, calculating the initial code amount based on the reference code data.

[0133] S324: Obtaining the development risk index of the candidate requirement based on the initial code amount and the total code reference amount.

[0134] In this embodiment, the reference code data is code data submitted by the candidate developer, including the code submission times of all requirements corresponding to the candidate developer and the code amount of each submission.

[0135] Specifically, the sum of the code amounts of all requirements submitted in the reference code data is calculated based on the reference code data to obtain a code reference total amount, which is the sum of the code amounts of all requirements submitted in the reference code data. For example, referring to Table 1, the total code submission amounts of the two requirements (i.e., requirement Z1 and requirement Z2) in the reference code data are and respectively, and the code reference total amount can be calculated as . If there is no available or valid reference code data, the candidate developer can set a reasonable code reference total amount corresponding to the reference version to which the candidate requirement belongs.

[0136] For example, when it is detected that the candidate developer submits the code corresponding to the candidate requirement for the first time, the sum of the code amounts of all requirements submitted for the first time in the reference code data is calculated based on the reference code data to obtain an initial code amount, wherein the initial code amount is the sum of the code amounts of all requirements submitted for the first time in the reference code data. For example, referring to Table 1, the code amounts of the two requirements (i.e., requirement Z1 and requirement Z2) submitted for the first time in the reference code data are and respectively, and the sum of the code amounts of all requirements submitted for the first time in the reference code data is calculated as , i.e., the initial code amount is .

[0137] For example, the initial code amount is divided by the code reference total amount to obtain a code development progress value, and the risk index corresponding to the code development progress value is determined as the development risk index of the candidate requirement according to the corresponding relationship table (e.g., Table 6) between the code development progress and the risk index, to obtain the development risk index of the candidate requirement.

[0138] For example, when it is detected that the candidate developer submits the code corresponding to the candidate requirement for the first time, the initial code amount is calculated as based on the reference code data, the code reference total amount is , and the code development progress value can be calculated as . According to Table 6, the risk index corresponding to the code development progress value is , and the risk index is determined as the development risk index of the candidate requirement.

[0139] Exemplarily, in some embodiments, based on the reference code data, the development risk index of the candidate requirement is calculated, specifically including but not limited to the following steps S325-S326:

[0140] S325: in response to detecting that the code corresponding to the reference requirement is first submitted, the reference code amount is calculated based on the reference code data.

[0141] S326: based on the reference code amount and the total code reference amount, the development risk index of the candidate requirement is obtained.

[0142] Generally, after the candidate developer approaches to develop all the code of the candidate requirement, the code of the next requirement is continuously developed and submitted, which indicates that the code development of the candidate requirement is approaching completion, and thus, based on the reference code data, the sum of the code amount of all the requirements in the reference code data that has been submitted at the time when the code of a different requirement is submitted can be calculated to obtain the reference code amount. The reference requirement is any one requirement different from the candidate requirement, that is, the reference requirement can be any one requirement in at least one requirement of the current version except the candidate requirement, or can also be any one requirement in other versions.

[0143] Exemplarily, when it is detected that the code corresponding to the reference requirement is first submitted, it indicates that the code development of the candidate requirement is approaching completion, and based on the reference code data, the sum of the code amount of all the target requirements in the reference code data that has been submitted at the reference time is calculated to obtain the reference code amount, that is, the reference code amount is the sum of the code amount of all the target requirements in the reference code data that has been submitted at the reference time. The target requirement is any one requirement in all the requirements of the reference code data, the reference time is the time when the code of the reference requirement is first submitted, and the reference requirement is any one requirement different from the target requirement, which can be any one requirement different from the target requirement in any one historical version. For example, as shown in Table 1, the code amount of the two requirements (i.e., requirement Z1 and requirement Z2) in the reference code data that has been submitted at the reference time (i.e., the time when the code of the reference requirement is first submitted) is and respectively, and thus, the sum of the code amount of all the target requirements in the reference code data that has been submitted at the reference time is calculated to be lines, that is, the reference code amount is lines.

[0144] Exemplarily, the reference code amount is divided by the total code reference amount to obtain the code development progress value, and based on the corresponding relationship table between the code development progress and the risk index (for example, Table 6 described above), the risk index corresponding to the code development progress value is determined as the development risk index of the candidate requirement, and thus, the development risk index of the candidate requirement is obtained.

[0145] For example, when detecting that the candidate developer first submits the code corresponding to the benchmark requirement, according to the reference code data, the sum of the code amount of all requirements in the reference code data that has been submitted at the benchmark time (i.e., the benchmark code amount) is calculated as The sum of the code amount of all requirements in the reference code data that has been submitted (i.e., the code reference total amount) is The code development progress value is According to the table 6 query, the risk index corresponding to the code development progress value is The risk index is determined as the development risk index of the candidate requirement.

[0146] For example, in some embodiments, the development risk index of the candidate requirement is calculated based on the historical code data, specifically including but not limited to the following steps S327:

[0147] S327: In response to detecting that the self-test case execution of the candidate requirement passes, the preset benchmark risk index is determined as the development risk index of the candidate requirement.

[0148] Specifically, after the candidate developer develops all the code of the candidate requirement, the developed code needs to be self-tested, i.e., the self-test case of the candidate requirement is executed to test the code. When detecting that the self-test case execution of the candidate requirement passes, it indicates that the candidate developer has developed and submitted all the code of the candidate requirement, i.e., the code development progress value is According to the table 6 query, the risk index corresponding to the code development progress value is The risk index is the preset benchmark risk index, and the risk index is determined as the development risk index of the candidate requirement.

[0149] S330: Calculate the product risk index of the candidate requirement based on the requirement change data.

[0150] In this embodiment, the product risk index mainly focuses on the dynamic adjustment of business requirements. Requirement changes are the main cause of version range spread and delay, and need to be independently evaluated for their impact on priority, resources, test scheduling, and software delivery. It can be understood that, unlike test cases and defects, requirement changes belong to "external input" and need to be specially managed for their chain reactions. For each requirement in the software version, there may be one or more changes during the entire software development process, and the impact of the change degree on the entire requirement development needs to be determined.

[0151] In the embodiment of the present application, the similarity of the first demand text before change and the second demand text after change is calculated by using a text similarity algorithm each time the candidate demand is changed. The text similarity algorithm can be a cosine similarity algorithm, a Jaro-Winkler algorithm, etc. According to the similarity between the first demand text and the second demand text and a preset corresponding relationship table of demand text similarity and risk index, the product risk index of the candidate demand is determined.

[0152] For example, the corresponding relationship table of demand text similarity and risk index is shown in Table 7 as follows:

[0153] Table 7:

[0154]

[0155] According to Table 7 above, it is assumed that the similarity of the first demand text and the second demand text (i.e., demand text similarity) is According to the query of Table 7, the demand text similarity corresponds to a risk index of Therefore, the risk index is the product risk index of the candidate demand.

[0156] Exemplarily, in some embodiments, the product risk index of the candidate demand is calculated based on the demand change data, specifically including but not limited to the following steps S331-S332:

[0157] S331: In response to the demand change data not having the first demand text and having the second demand text, determining that the first preset value is the similarity of the demand text.

[0158] S332: In response to the similarity of the demand text being the first preset value, determining that the first risk coefficient is the product risk index of the candidate demand.

[0159] It can be understood that when the candidate demand is a newly added demand, the demand change data does not have the first demand text before change and has the second demand text after change. Therefore, the first preset value can be directly determined as the similarity of the demand text When the similarity of the demand text is , according to the corresponding relationship table of demand text similarity and risk index (such as Table 7 described above), the first risk index corresponding to the similarity of the demand text is the product risk index of the candidate demand.

[0160] Exemplarily, in some embodiments, the product risk index of the candidate demand is calculated based on the demand change data, specifically including but not limited to the following steps S333-S337:

[0161] S333: In response to the existence of the first demand text and the second demand text, calculating the similarity of the first demand text and the second demand text to obtain a calculation result.

[0162] S334: In response to the calculation result being that the similarity of the first demand text and the second demand text is a first preset value, determining that the first risk coefficient is the product risk index of the candidate demand.

[0163] S335: In response to the calculation result being that the similarity of the first demand text and the second demand text is within a first threshold range, determining that the second risk coefficient is the product risk index of the candidate demand.

[0164] S336: In response to the calculation result being that the similarity of the first demand text and the second demand text is within a second threshold range, determining that the third risk coefficient is the product risk index of the candidate demand.

[0165] S337: In response to the calculation result being that the similarity of the first demand text and the second demand text is a second preset value, determining that the fourth risk coefficient is the product risk index of the candidate demand.

[0166] For example, each time the candidate demand is changed, the similarity of the first demand text before the change and the second demand text after the change is calculated using a text similarity algorithm to obtain a calculation result (i.e., the demand text similarity / the similarity of the first demand text and the second demand text), and the product risk index of the candidate demand is determined according to the calculation result and the corresponding relationship table of the demand text similarity and the risk index (such as Table 7 described above).

[0167] In some embodiments, when the calculation result is that the similarity of the first demand text and the second demand text is the first preset value , it indicates that the demand texts before and after the change of the candidate demand have no similarity, and therefore, according to the corresponding relationship table of the demand text similarity and the risk index (such as Table 7 described above), the first risk index corresponding to the demand text similarity is determined as the product risk index of the candidate demand.

[0168] In some embodiments, when the calculation result is that the similarity of the first demand text and the second demand text is within the first threshold range , i.e. , it indicates that the similarity of the demand texts before and after the change of the candidate demand is small, and therefore, according to the corresponding relationship table of the demand text similarity and the risk index (such as Table 7 described above), the second risk index corresponding to the demand text similarity within the first threshold range is determined.​ a product risk index of the candidate requirement.

[0169] In some embodiments, when the calculation result is that the similarity of the first requirement text and the second requirement text is within a second threshold range, the second threshold range is , that is , it indicates that the similarity of the requirement texts before and after the change of the candidate requirement is large, and according to the corresponding relationship table of the requirement text similarity and the risk index (such as Table 7 described above), the fourth risk index corresponding to the similarity of the requirement texts is determined. a product risk index of the candidate requirement.

[0170] In some embodiments, when the calculation result is that the similarity of the first requirement text and the second requirement text is a second preset value , it indicates that the requirement texts before and after the change of the candidate requirement are completely similar, and according to the corresponding relationship table of the requirement text similarity and the risk index (such as Table 7 described above), the fourth risk index corresponding to the similarity of the requirement texts is determined. a product risk index of the candidate requirement.

[0171] For example, in some embodiments, based on the requirement change data, the product risk index of the candidate requirement is calculated, specifically including but not limited to the following steps S338-S339:

[0172] S338: In response to the existence of the first requirement text and the non-existence of the second requirement text in the requirement change data, the second preset value is determined as the similarity of the requirement texts.

[0173] S339: In response to the similarity of the requirement texts being the second preset value, the fourth risk coefficient is determined as the product risk index of the candidate requirement.

[0174] It can be understood that when the candidate requirement is a deleted requirement, the first requirement text before the change exists and the second requirement text after the change does not exist in the requirement change data, the second preset value is directly determined as the similarity of the requirement texts. When the similarity of the requirement texts is , according to the corresponding relationship table of the requirement text similarity and the risk index (such as Table 7 described above), the fourth risk index corresponding to the similarity of the requirement texts is determined. a product risk index of the candidate requirement.

[0175] S340: Based on the test risk index, the development risk index and the product risk index, the integrated risk index of the candidate requirement is calculated. ​

[0176] Specifically, according to the influence degree of the test risk index, the development risk index and the product risk index on the integrated risk index of the candidate demand, the weight of the test risk index, the weight of the development risk index and the weight of the product risk index are pre-set. The test risk index, the development risk index and the product risk index are weighted and added according to the weights of the test risk index, the development risk index and the product risk index, to obtain the integrated risk index of the candidate demand.

[0177] For example, in some embodiments, the integrated risk index of the candidate demand is calculated based on the test risk index, the development risk index and the product risk index, specifically including but not limited to the following steps S341-S345:

[0178] S341: Obtain the test weight coefficient corresponding to the test risk index, the development weight coefficient corresponding to the development risk index and the product weight coefficient corresponding to the product risk index.

[0179] S342: Multiply the test risk index by the test weight coefficient to obtain a first risk index.

[0180] S343: Multiply the development risk index by the development weight coefficient to obtain a second risk index.

[0181] S344: Multiply the product risk index by the product weight coefficient to obtain a third risk index.

[0182] S345: Add the first risk index, the second risk index and the third risk index to obtain the integrated risk index of the candidate demand.

[0183] Specifically, the pre-set test weight coefficient corresponding to the test risk index, the development weight coefficient corresponding to the development risk index and the product weight coefficient corresponding to the product risk index are obtained. The test risk index is multiplied by the test weight coefficient to obtain a first risk index, the development risk index is multiplied by the development weight coefficient to obtain a second risk index, and the product risk index is multiplied by the product weight coefficient to obtain a third risk index. The first risk index, the second risk index and the third risk index are added to obtain the integrated risk index of the candidate demand.

[0184] For example, the test risk index, the development risk index and the product risk index are , and , the test weight coefficient of the test risk index is , the development weight coefficient of the development risk index is , and the development weight coefficient of the development risk index is , then the integrated risk index of the candidate demand is .

[0185] S400: An aggregated risk index calculated based on all requirements.

[0186] Specifically, based on factors such as the difficulty, urgency, and time required for each requirement in the version, a weighting coefficient is set corresponding to the integration risk index of each requirement. The integration risk index of each requirement is multiplied by the weighting coefficient corresponding to the integration risk index of each requirement to obtain the weighted result of the integration risk index of each requirement. The integration risk indices of all requirements in the version are weighted and summed to obtain the aggregate risk index of the version.

[0187] For example, such as Figure 2 As shown, version A's demand set B includes four demands: demand B1, demand B2, demand B3, and demand B4. Assume the integration risk indices for demands B1, B2, B3, and B4 are respectively... , , and The weighting coefficients for demands B1, B2, B3, and B4 are respectively... , , and The aggregation risk index of the version .

[0188] For example, in some embodiments, a version of the aggregated risk index is calculated based on the integrated risk index of all requirements, specifically including but not limited to the following steps S410-S450:

[0189] S410: Obtain the reference working hours for each requirement.

[0190] S420: Add up the reference working hours for all requirements to get the total reference working hours.

[0191] S430: Divide the reference working hours for each requirement by the total reference working hours to obtain the working hour percentage for each requirement.

[0192] S440: Multiply the percentage of working hours for each requirement by the integration risk index of that requirement to obtain the reference risk index for that requirement.

[0193] S450: Sum the reference risk indices of all requirements to obtain the aggregated risk index of the version.

[0194] In this embodiment, the integrated risk index of all requirements is weighted and fused based on the reference working hours of each requirement to obtain the aggregated risk index of the version. The reference working hours are the pre-set working hours when a new requirement is created, i.e., the working hours expected to be required for developers to solve the requirement. Designers can set the reference working hours for each requirement based on historical experience data and actual tasks, and attach the reference working hours to the requirement, so that the corresponding reference working hours can be directly read from the requirement when needed.

[0195] For example, when calculating the aggregate risk index of a version based on the integration risk index of requirements, the electronic device obtains the reference working hours for each requirement of the version, adds up the reference working hours of all requirements, and obtains the total reference working hours. For each requirement, the reference working hours of each requirement are divided by the total reference working hours to obtain the working hour percentage of each requirement. The working hour percentage of each requirement is multiplied by the integration risk index of that requirement to obtain the reference risk index of that requirement. The reference risk indices of all requirements are added up to obtain the aggregate risk index of the version.

[0196] For example, such as Figure 2 As shown, version A's demand set B includes four demands: demand B1, demand B2, demand B3, and demand B4. Assume the integration risk indices for demands B1, B2, B3, and B4 are respectively... , , and The reference working hours for demands B1, B2, B3, and B4 are as follows: sky, sky, Tianji If the total working hours are [number] days, then [number] days are considered. sky.

[0197] Calculations show that the reference risk index for demand B1 is: The reference risk index for demand B2 is: The reference risk index for demand B3 is: The reference risk index for demand B4 is: The aggregate risk index of the version is obtained by adding up the reference risk indices of all requirements. .

[0198] S500: Determines the risk level of a version based on the aggregated risk index.

[0199] It can be understood that the risk assessment is a process of evaluating and quantifying the identified risk index, and by evaluating the probability and impact of the risk, the manager can determine the risk level of the version and provide the basis for subsequent risk treatment. According to the influence of test, development and product dimensions on the demand risk index and the influence degree of each demand in the version delivery, the embodiment of the present application calculates the version delivery risk index (i.e. the aggregated risk index), which can help the manager to better perform risk assessment.

[0200] Specifically, according to the above risk index calculation, the integrated risk index range of the demand calculated by the test, development and product dimensions is , and the aggregated risk index range of the version calculated according to the weight and integrated risk index of all demands of the version is . The designer divides a plurality of aggregated risk index ranges according to experimental data and empirical data, and each aggregated risk index range corresponds to a risk warning level, to obtain a corresponding relationship table of aggregated risk index and risk warning level. According to the aggregated risk index of the version, the risk warning level corresponding to the aggregated risk index is determined as the risk level of the version.

[0201] For example, the corresponding relationship table of the aggregated risk index and the risk warning level is shown in Table 8 as follows:

[0202] Table 8:

[0203]

[0204] According to Table 8, for the lower rated risk (i.e. the aggregated risk index is located in , the risk warning level is blue), it can be selected to be accepted, and no measures are needed to change the possibility or impact of the risk, but to be prepared to cope with the consequences of the risk. For the medium rated risk (i.e. the aggregated risk index is located in , the risk warning level is yellow), it can be selected to be mitigated, and some necessary measures are taken to reduce the possibility or impact of the risk. For the higher rated risk (i.e. the aggregated risk index is located in , the risk warning level is orange), it can be selected to be avoided, and the plan of the project needs to be changed and adjusted to reduce or eliminate the possibility of the risk. For the extremely high rated risk (i.e. the aggregated risk index is located in , the risk warning level is red), it can be selected to be transferred, and the risk with huge impact is transferred to the outside.

[0205] For example, when the aggregated risk index of the version is , according to the corresponding relationship table of the aggregated risk index and the risk warning level (such as Table 8 above), the aggregated risk index located in the interval range a yellow level in the risk warning level is determined as the risk level of the version.

[0206] In some embodiments, based on the aggregated risk index, the risk level of the version is determined, specifically including but not limited to the following steps S510-S540:

[0207] S510: in response to the aggregated risk index being located in the first risk index range, a blue level is determined as the risk level of the version.

[0208] S520: in response to the aggregated risk index being located in the second risk index range, a yellow level is determined as the risk level of the version.

[0209] S530: in response to the aggregated risk index being located in the third risk index range, an orange level is determined as the risk level of the version.

[0210] S540: in response to the aggregated risk index being located in the fourth risk index range, a red level is determined as the risk level of the version.

[0211] For example, according to the aggregated risk index of the version, the risk warning level corresponding to the aggregated risk index in the correspondence table between the aggregated risk index and the risk warning level is determined as the risk level of the version.

[0212] In some embodiments, when the aggregated risk index of the version is located in the first risk index range, a blue level is determined as the risk level of the version. For example, as shown in the above table 8, assuming that the aggregated risk index is located in the interval range , a blue level is determined as the risk level of the version.

[0213] In some embodiments, when the aggregated risk index of the version is located in the second risk index range, a yellow level is determined as the risk level of the version. For example, as shown in the above table 8, assuming that the aggregated risk index is located in the interval range , a yellow level is determined as the risk level of the version.

[0214] In some embodiments, when the aggregated risk index of the version is located in the third risk index range, an orange level is determined as the risk level of the version. For example, as shown in the above table 8, assuming that the aggregated risk index is located in the interval range , an orange level is determined as the risk level of the version.

[0215] In some embodiments, when the aggregated risk index of the version is located in the fourth risk index range, a red level is determined as the risk level of the version. For example, as shown in the above table 8, assuming that the aggregated risk index is is located in the interval range , the red level is determined as the risk level of the version.

[0216] S600: generating a risk warning mark corresponding to the risk level based on the risk level, and presenting the risk warning mark.

[0217] In this embodiment, the risk warning mark is a mark for visually representing the risk level, so as to attract the attention of the project manager or the management personnel by the visual risk warning mark.

[0218] Specifically, after determining the risk level of the version, the corresponding risk warning mark is generated according to the risk level, and the risk warning mark is presented on the display device. It can be easily understood that the risk warning mark can be generated by using image generation technology, image processing technology, etc., and can be presented at any suitable position in the display device to remind the project manager or the management personnel, etc.

[0219] In some embodiments, when the risk level of the version is the blue level, a blue risk warning mark corresponding to the blue level is generated, for example, the blue risk warning mark shown in a1 in FIG. 6 is generated, and the blue risk warning mark is presented. Figure 7

[0220] In some embodiments, when the risk level of the version is the yellow level, a yellow risk warning mark corresponding to the yellow level is generated, for example, the yellow risk warning mark shown in a2 in FIG. 6 is generated, and the yellow risk warning mark is presented. Figure 7

[0221] In some embodiments, when the risk level of the version is the orange level, an orange risk warning mark corresponding to the orange level is generated, for example, the orange risk warning mark shown in a3 in FIG. 6 is generated, and the orange risk warning mark is presented. Figure 7

[0222] In some embodiments, when the risk level of the version is the red level, a red risk warning mark corresponding to the red level is generated, for example, the red risk warning mark shown in a4 in FIG. 6 is generated, and the red risk warning mark is presented. Figure 7

[0223] It can be understood that after identifying and evaluating the risk of the software version, the project manager or the management personnel can take corresponding risk response strategies according to different risk types. For example, when encountering technical risk, a technical risk response strategy is adopted, a previously established technical alternative solution is started, and technical obstacles are solved. For example, when encountering development progress risk, a progress risk response strategy is adopted, spare human resources are increased, parallel development is carried out, and delivery is negotiated to be delayed, and every effort is made to solve the progress risk. ​​​​

[0224] It is worth mentioning that in the above embodiment, the risk warning mark corresponding to the integrated risk index of each requirement is generated and presented, and the risk warning mark corresponding to the test risk index, the development risk index and the product risk index of each requirement is generated and presented, and the risk warning mark corresponding to the use case risk index and the defect risk index of each requirement is generated and presented, so that various risks of the software version can be monitored comprehensively, and the risks of the software version can be controlled in time.

[0225] In summary, the software version risk index calculation and risk control method provided by the embodiment of the present application can automatically and efficiently calculate the risk index of the software version, and visually monitor the risk of the software version, so that the project manager or the management personnel can control the risk of the software version in time, and the development progress can be ensured as much as possible, and the software development quality is improved.

[0226] The computer readable storage medium provided by the embodiment of the present application stores the computer program instructions executable by the processor, and the computer program instructions are executed by the processor to make the computer execute the software version risk index calculation and risk control method provided by the embodiment of the present application, or execute the steps in any possible implementation manner of the software version risk index calculation and risk control method provided by the embodiment of the present application.

[0227] Those skilled in the art can understand that the embodiments provided by the present application are only illustrative, and the writing order of each step in the method of the embodiments does not mean a strict execution order and does not constitute any limitation on the implementation process, and the order can be adjusted, combined and deleted according to actual needs. The modules or sub-modules, units or sub-units, etc. in the device or system of the embodiments can be combined, divided and deleted according to actual needs. For example, the division of the unit is only a logical function division, and another division mode can be used in actual implementation. For example, a plurality of units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0228] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be realized by means of software plus a general hardware platform, and of course can also be realized by hardware. Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiment methods. It should be understood that the storage medium can be a flash memory, a hard disk, an optical disk, a register, a magnetic surface memory, a removable magnetic disk, a random access memory (RAM), a CD-ROM, a read-only memory (ROM), an electrically programmable ROM, and an electrically erasable programmable ROM, etc.

[0229] It should be noted that the above embodiments are for the purpose of illustrating the technical concept and characteristics of the present application, and the purpose is to enable those skilled in the art to understand the content of the present application and to implement it accordingly, and cannot be used to limit the scope of protection of the present application. Those skilled in the art can understand that all or part of the processes of the above-mentioned embodiments can be modified according to the technical solutions described in the embodiments of the present application, or some technical features can be replaced by equivalent ones. It can be understood that these modifications or replacements do not change the essence of the corresponding technical solutions out of the scope of the technical solutions of the embodiments of the present application, and should be regarded as equivalent changes and modifications based on the embodiments of the present application, and should be regarded as falling within the scope of the claims of the present application.

Claims

1. A software version risk index calculation and risk management method, characterized in that, The method comprises the following steps: acquiring at least one requirement of the version; acquiring use case data, defect data, historical code data and requirement change data corresponding to a candidate requirement, the candidate requirement being any one of the at least one requirement, the use case data comprising test cases and states and levels of the test cases, the defect data comprising defects and states and levels of the defects, the historical code data comprising code submission times and code amounts of each submission of all requirements in at least one historical version, and the requirement change data comprising first requirement texts before the candidate requirement is changed and / or second requirement texts after the candidate requirement is changed; calculating an integration risk index of the candidate requirement based on the use case data, the defect data, the historical code data and the requirement change data, comprising: calculating a test risk index of the candidate requirement based on the use case data and the defect data; calculating a development risk index of the candidate requirement based on the historical code data; calculating a product risk index of the candidate requirement based on the requirement change data; and calculating the integration risk index of the candidate requirement based on the test risk index, the development risk index and the product risk index; calculating the development risk index of the candidate requirement based on the historical code data, comprising: extracting reference code data from the historical code data, the reference code data comprising code submission times and code amounts of each submission of all requirements corresponding to a candidate developer in at least one historical version, the candidate developer being a developer corresponding to the candidate requirement; calculating a total code reference amount based on the reference code data, the total code reference amount being a sum of code amounts of all submitted requirements in the reference code data; in response to detecting that code corresponding to the candidate requirement is submitted for the first time, calculating an initial code amount based on the reference code data, the initial code amount being a sum of code amounts of all first submissions of requirements in the reference code data; and obtaining the development risk index of the candidate requirement based on the initial code amount and the total code reference amount; or in response to detecting that code corresponding to a reference requirement is submitted for the first time, calculating a reference code amount based on the reference code data, the reference requirement being any one of requirements different from the candidate requirement, the reference code amount being a sum of code amounts of the target requirement submitted at a reference time in the reference code data, the target requirement being any one of all requirements in the reference code data, and the reference time being a time when code is submitted to the reference requirement for the first time; and obtaining the development risk index of the candidate requirement based on the reference code amount and the total code reference amount; or in response to detecting that a self-test use case of the candidate requirement is executed successfully, determining a preset reference risk index as the development risk index of the candidate requirement; calculating an aggregation risk index of the version based on integration risk indexes of all the requirements; determining a risk level of the version based on the aggregation risk index. generate a risk warning mark corresponding to the risk level based on the risk level, and present the risk warning mark, the risk warning mark being an identifier for visually representing the risk level.

2. The method of claim 1, wherein, The test risk index of the candidate requirement is calculated based on the use case data and the defect data, including: The use case risk index of the candidate requirement is calculated based on the status and level of the test case in the use case data; The defect risk index of the candidate requirement is calculated based on the status and level of the defect in the defect data; The test risk index of the candidate requirement is calculated based on the use case risk index and the defect risk index.

3. The method of claim 2, wherein, The integrated risk index of the candidate requirement is calculated based on the test risk index, the development risk index and the product risk index, including: The test weight coefficient corresponding to the test risk index, the development weight coefficient corresponding to the development risk index and the product weight coefficient corresponding to the product risk index are obtained; The first risk index is obtained by multiplying the test risk index and the test weight coefficient; The second risk index is obtained by multiplying the development risk index and the development weight coefficient; The third risk index is obtained by multiplying the product risk index and the product weight coefficient; The integrated risk index of the candidate requirement is obtained by adding the first risk index, the second risk index and the third risk index.

4. The method of claim 1, wherein, The product risk index of the candidate requirement is calculated based on the requirement change data, including: In response to the absence of the first requirement text and the presence of the second requirement text in the requirement change data, a first preset value is determined as the similarity of the requirement text; In response to the similarity of the requirement text being the first preset value, a first risk coefficient is determined as the product risk index of the candidate requirement; Or, In response to the presence of the first requirement text and the second requirement text in the requirement change data, the similarity of the first requirement text and the second requirement text is calculated to obtain a calculation result; In response to the calculation result being that the similarity of the first requirement text and the second requirement text is the first preset value, the first risk coefficient is determined as the product risk index of the candidate requirement; In response to the calculation result being that the similarity of the first requirement text and the second requirement text is within a first threshold range, a second risk coefficient is determined as the product risk index of the candidate requirement; In response to the calculation result being that the similarity of the first requirement text and the second requirement text is within a second threshold range, a third risk coefficient is determined as the product risk index of the candidate requirement; In response to the calculation result being that the similarity of the first requirement text and the second requirement text is a second preset value, a fourth risk coefficient is determined as the product risk index of the candidate requirement; Or, In response to the absence of the second requirement text and the presence of the first requirement text in the requirement change data, the second preset value is determined as the similarity of the requirement text; In response to the similarity of the requirement text being the second preset value, the fourth risk coefficient is determined as the product risk index of the candidate requirement.

5. The method according to any one of claims 1 to 4, characterized in that, The integrated risk index based on all the requirements is used to calculate the aggregated risk index of the version, including: Obtaining reference man-hours of each requirement, the reference man-hours being man-hours preset when the requirement is newly created; Adding the reference man-hours of all the requirements to obtain a total reference man-hours; Dividing the reference man-hours of each requirement by the total reference man-hours to obtain a man-hour proportion of each requirement; Multiplying the man-hour proportion of each requirement by the integrated risk index of the requirement to obtain a reference risk index of the requirement; Adding the reference risk indexes of all the requirements to obtain the aggregated risk index of the version.

6. The method according to any one of claims 1 to 4, characterized in that, The aggregated risk index is used to determine a risk level of the version, including: In response to the aggregated risk index being located in a first risk index range, determining a blue level as the risk level of the version; In response to the aggregated risk index being located in a second risk index range, determining a yellow level as the risk level of the version; In response to the aggregated risk index being located in a third risk index range, determining an orange level as the risk level of the version; In response to the aggregated risk index being located in a fourth risk index range, determining a red level as the risk level of the version.

7. An electronic device, comprising: including: a processor and a memory connected to the processor in communication; the memory stores computer program instructions executable by the processor, and the computer program instructions, when executed by the processor, cause the electronic device to perform the software version risk index calculation and risk control method according to any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions executable by the processor, and the computer program instructions, when executed by the processor, cause the computer to perform the software version risk index calculation and risk control method according to any one of claims 1-6.

Images