A software development resource dynamic allocation optimization method and visualization analysis tool

Abstract

The present invention provides a software development resource dynamic allocation optimization method and a visualization analysis tool, which belongs to the field of data processing technology, and specifically includes: determining the monitoring targets among the R&D personnel according to the distribution data of the R&D personnel with different analysis requirement types in different related R&D projects, determining the monitoring processing strategies for different monitoring targets in the R&D projects based on the distribution data of the monitoring targets in different R&D projects and the composition data of the R&D personnel, and determining whether it is necessary to perform dynamic allocation optimization processing of software development resources based on the monitoring data of the monitoring targets in different R&D projects, thereby improving the reliability of the monitoring processing of the defect discovery rate in the development process of the software project.

Description

Technical Field

[0001] The present invention belongs to the field of data processing technology, and in particular relates to a software development resource dynamic allocation optimization method and a visual analysis tool. Background Art

[0002] The software development process often involves sub-tasks in multiple dimensions. Since the development progress of different sub-tasks is not interconnected, managers are often unable to accurately control the software development progress, and thus cannot optimize the scheduling of software R&D resources in a targeted manner to improve the efficiency of software development processing.

[0003] Therefore, in order to solve the above technical problems, the invention patent application CN202411505922.8 "A digital supervision system and method for software development based on a cloud platform" realizes quantitative supervision of the development process through the construction of a cloud platform, improves R&D efficiency, reduces R&D costs, maximizes the input-output ratio, improves the return on software R&D, and improves the efficiency and quality of software development. However, there are the following technical problems:

[0004] During the visual analysis and processing of data, the defect discovery rate needs to be verified by manual review of the defect discovery rates of different R&D personnel. Since there are a large number of different R&D personnel and there are deviations in the related R&D projects of different R&D personnel, the differences in data dimensions such as defect discovery rate have different impacts on the overall R&D progress. Therefore, how to determine the monitoring targets of the defect discovery rates of different R&D projects based on the relationship between different R&D personnel and R&D projects, while reducing the difficulty of monitoring and analysis, and at the same time meeting the needs of optimized scheduling of software R&D resources has become a technical problem that needs to be solved urgently.

[0005] To solve the above technical problems, this application provides a software development resource dynamic allocation optimization method and a visualization analysis tool. Summary of the Invention

[0006] To achieve the purpose of the present invention, the present invention adopts the following technical solutions:

[0007] Specifically, this application provides a method for optimizing the dynamic allocation of software development resources, which specifically includes:

[0008] S1 determines the related R&D projects of the R&D personnel, and determines the correlation coefficients of the test cases between the different related R&D projects and other R&D projects based on the test case requirement data of the different related R&D projects and other R&D projects;

[0009] S2 determines the analysis requirement types of the R&D personnel in different related R&D projects based on the correlation coefficients of the test cases between different related R&D projects and other R&D projects, combined with the software defect identification data in different R&D projects;

[0010] S3: determining monitoring targets among the R&D personnel based on distribution data of R&D personnel with different analysis requirement types in different related R&D projects;

[0011] S4 uses the distribution data of monitoring targets in different R&D projects and the composition data of R&D personnel to determine the monitoring and processing strategies for different monitoring targets in R&D projects, and determines whether dynamic allocation and optimization of software R&D resources is required based on the monitoring data of monitoring targets in different R&D projects.

[0012] The beneficial effects of the present invention are:

[0013] Based on the correlation coefficient of test cases between different related R&D projects and other R&D projects, and the software defect identification data in different R&D projects, the analysis requirement types of R&D personnel in different related R&D projects are determined. Full consideration is given to the differences in the feasibility of R&D personnel optimizing and scheduling processing to other R&D projects due to the differences in the similarity of test cases between related R&D projects and other R&D projects. This realizes the evaluation of the universality of testing experience in different related R&D projects, and lays the foundation for determining monitoring targets based on the feasibility of R&D personnel scheduling processing to other R&D projects.

[0014] Based on the distribution data of monitoring targets in different R&D projects and the composition data of R&D personnel, the monitoring and processing strategies for different monitoring targets in R&D projects are determined. This not only avoids the technical problem of excessive difficulty in monitoring and processing the defect discovery rate caused by monitoring and processing the monitoring targets in all R&D projects, but also further combines the distribution data of monitoring targets and the composition data of R&D personnel to ensure the reliability of the identification and processing of the defect discovery rate of R&D projects with a smaller number of monitoring targets.

[0015] A further technical solution is that the related R&D projects are R&D projects in which the R&D personnel participate.

[0016] A further technical solution is that the requirement data of the test case includes requirement items in three dimensions: the number of function points tested, the type of input and output data, the number of performance test requirements, and the requirement value.

[0017] A further technical solution is that the method for determining the correlation coefficient of the test cases between the related R&D project and other R&D projects is:

[0018] Determine deviation data of requirement items in different dimensions based on the requirement data of test cases between the related R&D project and other R&D projects;

[0019] Determining the number of deviations of the test cases in different requirement items based on the deviation data, and determining similar test cases in the test cases based on the number of deviations;

[0020] Based on the proportion of the similar test cases in the test cases in other R&D projects, a correlation coefficient of the test cases between the associated R&D project and other R&D projects is determined.

[0021] A further technical solution is that the similar test cases are test cases in which the number of deviations in different requirement items is within a preset deviation number range.

[0022] A further technical solution is that the method for determining the monitoring and processing strategy of the monitoring target in the R&D project is:

[0023] Taking the R&D projects with the monitoring targets as analysis target projects, and determining the proportions of monitoring targets in different analysis target projects based on the proportions of the number of monitoring targets in the analysis target projects among the R&D personnel;

[0024] The analysis target items whose monitoring target ratio is less than the preset ratio threshold or whose monitoring target ratio of a type of demand is less than the preset ratio threshold are regarded as monitoring deviation items;

[0025] According to the number of monitoring deviation items and the proportion of monitoring targets in different analysis target items, the monitoring processing strategy of the monitoring targets in different analysis target items is determined.

[0026] A further technical solution is to determine the monitoring processing strategy for the monitoring targets in different analysis target projects based on the number of monitoring deviation projects and the proportion of monitoring targets in different analysis target projects, specifically including:

[0027] When the number of monitoring deviation items is greater than the preset monitoring item number threshold, it is only necessary to perform defect recognition processing on the monitoring deviation items;

[0028] When the number of monitoring deviation items is not greater than the preset monitoring item number threshold, the analysis target items that need to be identified for defect recognition rate are determined based on the preset number and the proportion of monitoring targets in different analysis target items.

[0029] A further technical solution is to determine whether dynamic allocation optimization of software development resources is needed, specifically including:

[0030] Determine the defect discovery rate of different monitoring targets in different R&D projects using the monitoring data of the monitoring targets in different R&D projects. The minimum value of the defect discovery rate in different R&D projects is used as the monitoring discovery rate of different monitoring targets.

[0031] Based on the monitoring discovery rate of monitoring targets in different R&D projects, determine whether dynamic allocation optimization of software R&D resources is needed.

[0032] A further technical solution is to determine whether dynamic allocation optimization of software development resources is needed based on the detection rate of monitoring targets in different R&D projects, including:

[0033] The monitoring targets whose detection rate is lower than the preset detection rate threshold are regarded as abnormal monitoring targets;

[0034] When there is an R&D project in which the proportion of abnormal monitoring targets among R&D personnel is greater than the preset monitoring target proportion threshold, it is determined that dynamic allocation optimization of software R&D resources is required.

[0035] In a second aspect, the present invention provides a visual analysis tool that uses the above-mentioned software development resource dynamic allocation optimization method, specifically comprising:

[0036] R&D project division module, monitoring target determination module, monitoring processing module;

[0037] The R&D project division module is responsible for dividing the R&D personnel in different R&D projects;

[0038] The monitoring target determination module is responsible for determining the monitoring targets in different R&D projects;

[0039] The monitoring processing module is responsible for determining the monitoring processing of defect discovery rates for different monitoring targets.

[0040] Other features and advantages will be described in the following description. The objectives and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description and drawings.

[0041] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and other features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the accompanying drawings.

[0043] Figure 1 It is a flow chart of a method for optimizing the dynamic allocation of software development resources;

[0044] Figure 2 A flowchart of a method for determining a correlation coefficient of test cases between an associated R&D project and other R&D projects;

[0045] Figure 3 A flowchart of a method for R&D personnel to determine the type of analysis requirements in the related R&D project;

[0046] Figure 4 It is a flow chart of a method for determining monitoring objectives among R&D personnel;

[0047] Figure 5 It is a framework diagram of a visual analysis tool. DETAILED DESCRIPTION

[0048] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this specification without creative work should fall within the scope of protection of this specification.

[0049] In this application, the related R&D projects for defect discovery rate monitoring are determined based on the similarity between the test cases of R&D personnel in related R&D projects and other R&D projects, as well as the number of R&D personnel in different related R&D projects, thereby improving the efficiency of software defect rate monitoring and processing.

[0050] The defect discovery rate is the ratio of the number of software defects discovered by R&D personnel during testing to the number of software defects discovered during review.

[0051] The correlation coefficient of test cases between the associated R&D project and other R&D projects is determined based on the ratio of the number of test cases in the associated R&D project that are consistent with other R&D projects in different requirement items to the number of test cases in other R&D projects.

[0052] The analysis requirement types include Class I requirement types and Class II requirement types, among which Class I requirement types are R&D personnel whose average number of identified software defects in more than 5 other R&D projects with a correlation coefficient greater than 0.5 or other R&D projects with a correlation coefficient greater than 0.5 is less than a preset number of R&D personnel.

[0053] R&D personnel who have more than three related R&D projects of a certain demand type will be taken as monitoring targets.

[0054] In R&D projects where the ratio of monitoring targets to R&D personnel is less than 0.1, the defect discovery rate of the monitoring targets is monitored.

[0055] Example 1

[0056] like Figure 1 As shown, this application provides a method for dynamically allocating and optimizing software development resources, specifically including:

[0057] S1 determines the related R&D projects of the R&D personnel, and determines the correlation coefficients of the test cases between the different related R&D projects and other R&D projects based on the test case requirement data of the different related R&D projects and other R&D projects;

[0058] Furthermore, the related R&D projects are R&D projects in which the R&D personnel participate.

[0059] Specifically, the requirement data of the test case includes requirement items in three dimensions: the number of function points tested, the type of input and output data, the number of performance test requirements, and the requirement value.

[0060] It should be noted that if Figure 2 As shown, the method for determining the correlation coefficient of the test cases between the related R&D project and other R&D projects is:

[0061] Determine deviation data of requirement items in different dimensions based on the requirement data of test cases between the related R&D project and other R&D projects;

[0062] Determining the number of deviations of the test cases in different requirement items based on the deviation data, and determining similar test cases in the test cases based on the number of deviations;

[0063] Based on the proportion of the similar test cases in the test cases in other R&D projects, a correlation coefficient of the test cases between the associated R&D project and other R&D projects is determined.

[0064] Furthermore, the similar test cases are test cases in which the deviation numbers in different requirement items are all within a preset deviation number range.

[0065] In another possible embodiment, the method for determining the correlation coefficient of the test cases between the related R&D project and other R&D projects is:

[0066] Determine test cases with the same requirements in different dimensions based on the test case requirement data between the related R&D project and other R&D projects;

[0067] Treat test cases with the same requirements in different dimensions as the same test cases;

[0068] Based on the proportion of the same test case in the test cases in other R&D projects, a correlation coefficient of the test cases between the associated R&D project and other R&D projects is determined.

[0069] S2 determines the analysis requirement types of the R&D personnel in different related R&D projects based on the correlation coefficients of the test cases between different related R&D projects and other R&D projects, combined with the software defect identification data in different R&D projects;

[0070] Furthermore, the software defect identification data in the R&D project includes the number of identified software defects in the R&D project and the code size of the software code.

[0071] Specifically, such as Figure 3 As shown, the method for determining the analysis requirement type of the R&D personnel in the related R&D project is:

[0072] Based on the correlation coefficient of the test cases between the related R&D project and other R&D projects, determine other R&D projects whose correlation coefficient is greater than a preset correlation coefficient threshold, and regard them as similar R&D projects;

[0073] Determining the number of identified software defects and the amount of software code in different similar R&D projects based on the software defect identification data in the similar R&D projects;

[0074] Based on the number of identified software defects and the amount of software code in different similar R&D projects, the analysis requirement type of the R&D personnel in the related R&D project is determined.

[0075] Furthermore, based on the number of identified software defects and the amount of software code in different similar R&D projects, the type of analysis requirements of the R&D personnel in the related R&D projects is determined, specifically including:

[0076] Determine the defect recognition coefficients of different similar R&D projects based on the ratio of the number of identified software defects to the amount of software code in different similar R&D projects;

[0077] The sum of the defect recognition coefficients of different similar R&D projects is used as the identification requirement value. When the identification requirement value is less than the preset identification requirement threshold, it is determined that the analysis requirement type of the R&D personnel in the related R&D project is a first-class requirement type. When the identification requirement value is not less than the preset identification requirement threshold, it is determined that the analysis requirement type of the R&D personnel in the related R&D project is a second-class requirement type.

[0078] It should be noted that the first type of demand is greater than the second type of demand.

[0079] Table 1. Classification of the types of requirements of a certain R&D personnel in different R&D projects

[0080]

[0081] In another possible embodiment, the method for determining the analysis requirement type of the related R&D project by the R&D personnel is:

[0082] S21, based on the correlation coefficient of the test cases between the related R&D project and other R&D projects, determining other R&D projects whose correlation coefficient is greater than a preset correlation coefficient threshold, and treating them as similar R&D projects;

[0083] It should be noted that before proceeding to step S22, it is also necessary to determine whether there are similar R&D projects to the related R&D projects, whether the number of similar R&D projects meets the requirements, and whether the sum of the correlation coefficients between different similar R&D projects and the related R&D projects meets the requirements.

[0084] It can be understood that when there are no similar R&D projects, the analysis requirement type in the related R&D projects is directly determined to be the second category requirement type. When there are similar R&D projects, when the number of similar R&D projects and the sum of the correlation coefficients between different similar R&D projects and the related R&D projects do not meet the requirements, that is, they are all less than the corresponding threshold value, then the analysis requirement type in the related R&D projects is directly determined to be the second category requirement type.

[0085] Specifically, when any one of the number of similar R&D projects and the sum of the correlation coefficients between different similar R&D projects and the related R&D projects meets the requirements, it is also necessary to determine that the number of similar R&D projects is greater than the threshold value of the number of similar R&D projects or the sum of the correlation coefficients between different similar R&D projects and the related R&D projects is greater than the preset coefficient threshold, then directly determine that the analysis requirement type in the related R&D project is a type of requirement; if not, proceed to step S22.

[0086] S22: determining the number of software defects identified and the amount of software code in different similar R&D projects based on the software defect identification data in the similar R&D projects, and determining defect identification coefficients for different similar R&D projects using the number of software defects identified and the amount of software code in the different similar R&D projects;

[0087] It should be further explained that the above step S22 also includes the following contents:

[0088] When there are multiple similar R&D projects whose number of identified software defects is less than a preset identification number threshold, the analysis requirement type in the related R&D project is directly determined to be a type of requirement. If not, the defect identification coefficients of different similar R&D projects are further determined using the number of identified software defects and the amount of software code in different similar R&D projects.

[0089] When there are multiple similar R&D projects whose defect recognition coefficients are less than a preset defect recognition coefficient threshold, it is directly determined that the analysis requirement type in the related R&D project is a type of requirement. If not, it is also necessary to determine whether the sum of the defect recognition coefficients of different similar R&D projects meets the requirements;

[0090] When the sum of the defect recognition coefficients of different similar R&D projects is less than the preset recognition requirement threshold, the analysis requirement type in the related R&D project is directly determined to be a type of requirement. If and only if the sum of the defect recognition coefficients of different similar R&D projects is not less than the preset recognition requirement threshold, proceed to the next step.

[0091] S23 determines the scheduling requirement value of the R&D personnel based on the defect recognition coefficient in different similar R&D projects and the correlation coefficient of the test cases between different similar R&D projects, and determines the analysis requirement type of the R&D personnel in the related R&D projects based on the scheduling requirement value.

[0092] It can be understood that the scheduling requirement value of the R&D personnel can be determined based on the sum of the products of the defect identification coefficient and the correlation coefficient in different similar R&D projects. When the scheduling requirement value is less than the preset scheduling requirement threshold, the analysis requirement type in the related R&D project is determined to be a Class I requirement type. If not, it is a Class II requirement type.

[0093] S3: determining monitoring targets among the R&D personnel based on distribution data of R&D personnel with different analysis requirement types in different related R&D projects;

[0094] Specifically, such as Figure 4 As shown, the method for determining the monitoring target among the R&D personnel is:

[0095] Based on the distribution data of R&D personnel with different analysis requirement types in different related R&D projects, determining that the R&D personnel belong to related R&D projects of a certain requirement type, and treating them as a type of R&D project;

[0096] Determine the matching coefficients in different types of R&D projects based on the number of R&D personnel of a certain type of demand in different types of R&D projects;

[0097] Based on the matching coefficients in different types of R&D projects, it is determined whether the R&D personnel are monitoring targets.

[0098] Furthermore, the matching coefficient is determined according to the inverse of the number of R&D personnel of a certain demand type in the R&D project of a certain type.

[0099] It should be noted that when the sum of the matching coefficients in different types of R&D projects is greater than a preset matching coefficient threshold, the R&D personnel are determined to be monitoring targets.

[0100] S4 uses the distribution data of monitoring targets in different R&D projects and the composition data of R&D personnel to determine the monitoring and processing strategies for different monitoring targets in R&D projects, and determines whether dynamic allocation and optimization of software R&D resources is required based on the monitoring data of monitoring targets in different R&D projects.

[0101] Specifically, the method for determining the monitoring and processing strategy of the monitoring target in the R&D project is:

[0102] Taking the R&D projects with the monitoring targets as analysis target projects, and determining the proportions of monitoring targets in different analysis target projects based on the proportions of the number of monitoring targets in the analysis target projects among the R&D personnel;

[0103] The analysis target items whose monitoring target ratio is less than the preset ratio threshold or whose monitoring target ratio of a type of demand is less than the preset ratio threshold are regarded as monitoring deviation items;

[0104] According to the number of monitoring deviation items and the proportion of monitoring targets in different analysis target items, the monitoring processing strategy of the monitoring targets in different analysis target items is determined.

[0105] Furthermore, based on the number of monitoring deviation items and the proportion of monitoring targets in different analysis target items, the monitoring processing strategies for the monitoring targets in different analysis target items are determined, specifically including:

[0106] When the number of monitoring deviation items is greater than the preset monitoring item number threshold, it is only necessary to perform defect recognition processing on the monitoring deviation items;

[0107] When the number of monitoring deviation items is not greater than the preset monitoring item number threshold, the analysis target items that need to be identified for defect recognition rate are determined based on the preset number and the proportion of monitoring targets in different analysis target items.

[0108] It is understandable that the analysis target items requiring defect recognition rate identification processing are determined based on the preset number and the proportion of monitoring targets in different analysis target items, specifically including:

[0109] The difference between the preset number and the number of monitoring deviation items is used as the target number, and the analysis target item with the smallest monitoring target ratio is used as the analysis target item that needs to be identified and processed for defect recognition rate.

[0110] In another possible embodiment, the method for determining the monitoring processing strategy of the monitoring target in the R&D project is:

[0111] The R&D projects with the monitoring targets are taken as the analysis target projects;

[0112] It is understandable that before proceeding to the next step, it is necessary to further determine whether the number of analysis target items is too small. Specifically, when the number of analysis target items is too small, that is, less than a fixed threshold, in order to achieve reliable monitoring of the monitoring target, when the number of analysis target items is too small, it is necessary to monitor the defect discovery rate of the monitoring target in different analysis target items;

[0113] In addition, even if the number of analysis target projects is not too small, if the number of analysis target projects is greater than the preset analysis target project number threshold, then the development of the entire software system will be affected when there is an abnormality in its defect discovery rate. Therefore, it is possible to directly determine the second preset number according to which the second preset number of analysis target projects are screened from small to large according to the number of monitoring targets, and use them as analysis target projects that need to monitor the defect discovery rate of the monitoring targets. Only when the number of analysis target projects is not greater than the preset analysis target project number threshold, proceed to the next step to continue determining the monitoring deviation values of different analysis target projects.

[0114] Determine the monitoring deviation values of different analysis target projects based on the proportion of the monitoring targets in different analysis target projects among the R&D personnel, and in combination with the number of monitoring targets in different analysis target projects, the number of analysis target projects for different monitoring targets, and the type of analysis requirements;

[0115] It is understandable that, in the above steps, if it is determined that the proportion of the monitoring targets in different analysis target projects among the R&D personnel is relatively small, that is, less than a fixed threshold, it is necessary to monitor the defect discovery rate in different analysis target projects;

[0116] The monitoring deviation value of the analysis target project is determined using a mathematical model based on the hierarchical analysis method based on the input of the proportion of monitoring targets in different analysis target projects among the R&D personnel, the number of monitoring targets in different analysis target projects, the number of analysis target projects of different monitoring targets, and the analysis requirement type.

[0117] In addition, it should be further explained that even if the number of R&D personnel is unevenly distributed and relatively small, it is necessary to further determine whether there are analysis target projects whose monitoring deviation values meet the requirements. When the monitoring deviation values of different analysis target projects do not meet the requirements, that is, the monitoring deviation values are greater than the preset threshold, it is necessary to monitor the defect discovery rate of the monitoring target in different analysis target projects.

[0118] In addition, even if the monitoring deviation values of not all analysis target items do not meet the requirements, the defect detection rate of the monitoring target will be monitored and processed first in the analysis target items whose monitoring deviation values do not meet the requirements, and then the next step will be continued to determine the monitoring and processing strategy of the monitoring target.

[0119] Based on the monitoring deviation values of different analysis target items, monitoring processing strategies for monitoring targets in different analysis target items are determined.

[0120] It can be understood that when the number of analysis target items whose monitoring deviation values do not meet the requirements is less than the preset analysis item number threshold, the defect detection rate monitoring process is performed on all analysis target items whose monitoring deviation values are greater than the preset deviation threshold; when the number of analysis target items whose monitoring deviation values do not meet the requirements is not less than the preset analysis item number threshold, it is only necessary to monitor the defect detection rate in all analysis target items whose monitoring deviation values do not meet the requirements.

[0121] Specifically, determine whether dynamic allocation optimization of software development resources is needed, including:

[0122] Determine the defect discovery rate of different monitoring targets in different R&D projects using the monitoring data of the monitoring targets in different R&D projects. The minimum value of the defect discovery rate in different R&D projects is used as the monitoring discovery rate of different monitoring targets.

[0123] Based on the monitoring discovery rate of monitoring targets in different R&D projects, determine whether dynamic allocation optimization of software R&D resources is needed.

[0124] Furthermore, based on the detection rate of monitoring targets in different R&D projects, it is determined whether dynamic allocation optimization of software R&D resources is needed, specifically including:

[0125] The monitoring targets whose detection rate is lower than the preset detection rate threshold are regarded as abnormal monitoring targets;

[0126] When there is an R&D project in which the proportion of abnormal monitoring targets among R&D personnel is greater than the preset monitoring target proportion threshold, it is determined that dynamic allocation optimization of software R&D resources is required.

[0127] The defect discovery rate is the ratio of the number of software defects discovered by R&D personnel during testing to the number of software defects discovered during the review process. The serious defect discovery rate is the ratio of the number of serious software defects discovered by R&D personnel during the testing process to the number of serious software defects discovered during the review process. Serious software defects are determined based on the internal definition of the enterprise.

[0128] Table 2. Data on defect discovery rates of R&D personnel in a certain R&D project

[0129]

[0130] Example 2

[0131] Second, as Figure 5 As shown, the present invention provides a visual analysis tool, which adopts the above-mentioned software development resource dynamic allocation optimization method, specifically including:

[0132] R&D project division module, monitoring target determination module, monitoring processing module;

[0133] The R&D project division module is responsible for dividing the R&D personnel in different R&D projects;

[0134] The monitoring target determination module is responsible for determining the monitoring targets in different R&D projects;

[0135] The monitoring processing module is responsible for determining the monitoring processing of defect discovery rates for different monitoring targets.

[0136] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0137] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0138] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A software development resource dynamic allocation optimization method, characterized in that: Specifically include: Determine the related R&D projects of the R&D personnel, and determine the correlation coefficient of the test cases between the related R&D projects and other R&D projects based on the test case requirement data of different related R&D projects and other R&D projects; Determining the analysis requirement types of the R&D personnel in the different related R&D projects based on the correlation coefficients of the test cases between the different related R&D projects and other R&D projects, combined with the software defect identification data in the different R&D projects; Determine monitoring targets among the R&D personnel based on distribution data of R&D personnel with different analysis requirement types in different related R&D projects; Based on the distribution data of monitoring targets in different R&D projects and the composition data of R&D personnel, the monitoring and processing strategies for different monitoring targets in R&D projects are determined. Based on the monitoring data of monitoring targets in different R&D projects, it is determined whether dynamic allocation and optimization of software R&D resources is needed. The method for determining the correlation coefficient of the test cases between the related R&D project and other R&D projects is as follows: Determine deviation data of requirement items in different dimensions based on the requirement data of test cases between the related R&D project and other R&D projects; Determining the number of deviations of the test cases in different requirement items based on the deviation data, and determining similar test cases in the test cases based on the number of deviations; Determining a correlation coefficient between the test cases of the associated R&D project and other R&D projects based on a proportion of the similar test cases in the test cases in other R&D projects; The similar test cases are test cases in which the deviation numbers of different requirement items are all within a preset deviation number range; The method for determining the analysis requirement type of the R&D personnel in the related R&D project is: Based on the correlation coefficient of the test cases between the related R&D project and other R&D projects, determine other R&D projects whose correlation coefficient is greater than a preset correlation coefficient threshold, and regard them as similar R&D projects; Determining the number of identified software defects and the amount of software code in different similar R&D projects based on the software defect identification data in the similar R&D projects; Determining the type of analysis requirements of the R&D personnel in the related R&D project based on the number of identified software defects and the amount of software code in different similar R&D projects; Determine the defect recognition coefficients of different similar R&D projects based on the ratio of the number of identified software defects to the amount of software code in different similar R&D projects; The sum of the defect recognition coefficients of different similar R&D projects is used as the identification requirement value. When the identification requirement value is less than the preset identification requirement threshold, it is determined that the analysis requirement type of the R&D personnel in the related R&D project is a first-class requirement type. When the identification requirement value is not less than the preset identification requirement threshold, it is determined that the analysis requirement type of the R&D personnel in the related R&D project is a second-class requirement type.

2. The software development resource dynamic allocation optimization method according to claim 1, characterized in that: The related R&D projects are R&D projects in which the R&D personnel participate.

3. The software development resource dynamic allocation optimization method according to claim 1, characterized in that: The test case requirement data includes requirement items in three dimensions: the number of function points tested, the type of input and output data, the number of performance test requirements, and the requirement value.

4. The software development resource dynamic allocation optimization method according to claim 1, characterized in that: The software defect identification data in the R&D project includes the number of identified software defects in the R&D project and the code size of software codes.

5. The software development resource dynamic allocation optimization method according to claim 1, characterized in that: The method for determining the monitoring and processing strategy of the monitoring target in the R&D project is as follows: Taking the R&D projects with the monitoring targets as analysis target projects, and determining the proportions of monitoring targets in different analysis target projects based on the proportions of the number of monitoring targets in the analysis target projects among the R&D personnel; The analysis target items whose monitoring target ratio is less than the preset ratio threshold or whose monitoring target ratio of a type of demand is less than the preset ratio threshold are regarded as monitoring deviation items; According to the number of monitoring deviation items and the proportion of monitoring targets in different analysis target items, the monitoring processing strategy of the monitoring targets in different analysis target items is determined.

6. The software development resource dynamic allocation optimization method according to claim 5, characterized in that: Based on the number of monitoring deviation items and the proportion of monitoring targets in different analysis target items, the monitoring and processing strategies for monitoring targets in different analysis target items are determined, including: When the number of monitoring deviation items is greater than the preset monitoring item number threshold, it is only necessary to perform defect recognition processing on the monitoring deviation items; When the number of monitoring deviation items is not greater than the preset monitoring item number threshold, the analysis target items that need to be identified for defect recognition rate are determined based on the preset number and the proportion of monitoring targets in different analysis target items.

7. The software development resource dynamic allocation optimization method according to claim 6, characterized in that: Based on the preset number and the proportion of monitoring targets in different analysis target projects, determine the analysis target projects that need to be identified and processed for defect recognition rate, including: The difference between the preset number and the number of monitoring deviation items is used as the target number, and the analysis target item with the smallest monitoring target ratio is used as the analysis target item that needs to be identified and processed for defect recognition rate.

8. A visual analysis tool, characterized in that: A software development resource dynamic allocation optimization method according to any one of claims 1 to 7 is used, specifically comprising: R&D project division module, monitoring target determination module, monitoring processing module; The R&D project division module is responsible for dividing the R&D personnel in different R&D projects; The monitoring target determination module is responsible for determining the monitoring targets in different R&D projects; The monitoring processing module is responsible for determining the monitoring processing of defect discovery rates for different monitoring targets.

Images