Development Support System

Abstract

To provide a development assistance system capable of predicting an influence degree with respect to KPI of other input variables by using a prediction model, and early verifying validity of soft architecture design, when changing the soft architecture design during execution of a project.SOLUTION: An example of a development assistance system comprises: a storage unit which stores at least update history data of a first component and current data of a second component of a developed product; an evaluation prediction unit which predicts an evaluation value with respect to a development result, for each component; a difference extraction unit which extracts a difference between the current data of the first component, and pre-update data which is one set of data in the update history data; and a data changing unit which generates post-change data obtained by changing the current data of the second component, on the basis of output of the difference extraction unit. The evaluation prediction unit calculates a first variation value of the evaluation value on the basis of the current data and the pre-update data of the first component, and calculates a second variation value of the evaluation value on the basis of the current data and the post-change data of the second component.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a development support system that predicts the degree to which an input variable will contribute to the outcome of a project such as software development. [Background technology]

[0002] In software development, a project typically goes through multiple version upgrades before the final version of the software is released. Recently, a concept called KPI (Key Performance Index) has been introduced as a criterion for determining how close each version is to achieving the final goal. KPIs, also known as "key performance indicators," are generally quantitative measurement standards established to manage the process of achieving a project's final goal. Specific examples of KPIs include CPU load, ROM consumption, RAM consumption, number of bugs, development man-hours, and software reuse rate.

[0003] In recent years, techniques for predicting these KPIs using software architecture design data metrics have been proposed. Software architecture design data metrics define criteria for quantitatively evaluating the software architecture (software structure, functional and non-functional requirements, etc.) being developed in a given project. Specific examples include the number of modules per core, the number / volume of dependencies, the direction of dependencies, and cyclomatic complexity. Various other criteria are also adopted from the perspectives of measuring system scale, understanding the sensitivity of the system to changes, understanding the degree of inter-element coupling, understanding the degree of inter-element coupling, and understanding the degree of element circularity. In the following, software architecture design will be simply referred to as "software architecture design," and software architecture design data metrics will be simply referred to as "software architecture design data metrics."

[0004] When software versions are updated, in addition to software architecture design data, hardware and project information may also be changed. Moreover, as software development projects have become larger in scale and complexity in recent years, the number of variables required for KPI prediction has also continued to increase. Therefore, it is necessary to establish a method for calculating the absolute amount of impact each input variable has on KPI prediction results, as well as a method for calculating the impact of software architecture design changes.

[0005] Patent Document 1 discloses a technique for randomly changing an input within a range of values ​​and identifying an input (feature amount) for achieving a purpose related to a target.

[0006] Furthermore, Patent Document 2 discloses a technology that uses a prediction model to calculate a (second) project success probability from a set of project parameters and a planned end date, and similarly calculates a (first) project success probability from a new set of parameters and a planned end date when a project is changed, and estimates the risk due to the project change from the difference between the first and second success probabilities. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Publication No. 2020-119085 [Patent Document 2] Japanese Patent Publication No. 2020-091843 Summary of the Invention [Problem to be solved by the invention]

[0008] However, the technology disclosed in Patent Document 1 does not take into consideration the handling of data that is version-managed and has continuity in time series, such as software design data, and is therefore unable to calculate the predicted value (absolute amount) of the impact of architecture design changes on KPIs. The same is true for Patent Document 2.

[0009] The present invention has been made in consideration of the above points, and aims to provide a development support system that, when the software architecture design is changed during the execution of a project, can use a prediction model to predict the impact of other input variables on KPIs, thereby enabling early verification of the validity of the software architecture design. [Means for solving the problem]

[0010] An example of a development support system according to the present invention comprises a memory unit that stores at least update history data of a first component of a development product and current data of a second component; an evaluation prediction unit that predicts an evaluation value for the development success level for each component; a difference extraction unit that extracts the difference between the current data of the first component and pre-update data, which is one of the update history data; and a data modification unit that generates modified data by modifying the current data of the second component based on the output of the difference extraction unit, wherein the evaluation prediction unit calculates a first variation value of the evaluation value based on the current data and pre-update data of the first component, and calculates a second variation value of the evaluation value based on the current data and post-update data of the second component. [Effects of the Invention]

[0011] According to the present invention, when the software architecture design is changed during the execution of a project, the impact of other input variables on the KPI can be predicted using a prediction model, making it possible to verify the validity of the software architecture design at an early stage. Further features related to the present invention will become apparent from the description of the present specification and the accompanying drawings. Furthermore, problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0012] [Figure 1] A diagram showing an overview of a method for predicting KPIs using a prediction model. [Figure 2] FIG. 1 is a block diagram showing the functional configuration of a development support system according to an embodiment of the present invention. [Figure 3] FIG. 2 is a diagram showing the relationship between the functional units in the processing executed by the development support system. [Figure 4] FIG. 10 is a diagram for explaining a method for calculating a comparison of the fluctuation rates between variables for a KPI when a development support system is applied. [Figure 5] 4 is a flowchart showing a process executed by the development support system. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0014] Figure 1 shows an overview of a method for predicting KPIs by inputting software architecture design data and other KPI-related data into a KPI prediction model. Software architecture design data is data that indicates the configuration requirements of the software being developed, and as mentioned above, includes the number of modules per core, the number / volume of dependencies, the direction of dependencies, and cyclomatic complexity. KPI-related data is not data related to the software being developed itself, but other data related to the development project, including project management data related to the project itself, such as similarities with past projects and customer requirements, and hardware design data such as microcontroller specifications. Specifically, this data type is, for example, the types indicated by variable names X2 to X8 in Figure 1.

[0015] These data are then input into an AI-based KPI prediction model that has learned data showing the relationship between past input variables and actually calculated KPIs, and the KPIs are predicted. Figure 1 shows examples of KPIs, such as Software productivity [LoC / hour] (number of lines of source code generated per unit time: indicating productivity), CPU workload [%] (CPU load rate), and Software bugs [Number / LoC] (number of bugs per line of source code).

[0016] As shown in Figure 1, each KPI fluctuates every time the version of the software being developed is revised. These results are fed back to the AI ​​of the KPI prediction model, improving its prediction accuracy.

[0017] However, as software version revisions occur, the software architecture design data and KPI-related data naturally change as well. As mentioned above, this, coupled with the increasing complexity of software development projects in recent years and the increase in the number of variables that must be handled, makes it possible to predict to some extent the impact of changes in the overall variables on KPIs, but it is extremely difficult to grasp the extent to which changes in each variable affect changes in KPIs.

[0018] The present invention has been made based on the above background, and a functional configuration block diagram of a development support system 1 according to one embodiment of the present invention is shown in Figure 2. Note that the hardware configuration of development support system 1 may be, for example, a computer equipped with a memory and a processor, or may be a cloud implemented on a server.

[0019] The development support system 1 includes a normalization processing unit 11, a difference extraction unit 12, a scale adjustment unit 13, a data modification unit 14, an evaluation prediction unit 15, a fluctuation rate calculation unit 16, a fluctuation rate comparison unit 17, and an evaluation result output unit 18. Details of these functions will be described later. The development support system 1 also includes a memory unit 100.

[0020] The storage unit 100 stores software architecture design data 101 and KPI-related data 102, and the KPI-related data 102 further includes hardware design data 1021 and project management data 1022. The software architecture design data 101 and the KPI-related data 102 are stored in association with each other for each software version.

[0021] The development support system 1 is also connected to an external server 3 via a communication path 2 connected to a communication interface (not shown) of the development support system 1. The communication path 2 may physically include multiple communication buses, and the standards of each communication bus may all be the same or different. The external server 3 sends and receives messages to and from the development support system 1 via the communication path 2.

[0022] The functional block diagram shown in Fig. 2 is an example, and the units and names of the functions are not limited to this. For example, the functions realized by the scale adjustment unit 13 in this embodiment may be realized by other functional units shown in Fig. 1 or by functional units not shown in Fig. 1.

[0023] FIG. 3 shows the relationship between each functional unit in the processing executed by the development support system. As an example, the processing when the software version is updated from v2.0 to v3.0 will be described with reference to FIG. 1. First, the normalization processing unit 11 extracts the current data (data for software version v3.0) and the data before the update (data for software version v2.0) of the software architecture design data 101 from the storage unit 100, and performs normalization processing. Any form of normalization can be used here. For example, a linear transformation or an affine transformation can be used, where the maximum value of each data is 1 and the minimum value is 0.

[0024] Next, the difference extraction unit 12 extracts the difference between the current data processed by the normalization processing unit 11 and the pre-update data. This difference is the difference between data normalized to 0 to 1, and therefore takes a value between -1 and 1.

[0025] The extracted difference is passed to the scale adjustment unit 13. At the same time, or prior to this, the pre-data-change metrics value calculation unit 141 of the data change unit 14 references the KPI-related data 102 in the storage unit 100, extracts the current data (data for software version v3.0), measures it from a preset perspective, and calculates a metrics value. At this time, multiple data may be extracted from the KPI-related data and calculated together as a metrics value. The calculated metrics value is passed to the scale adjustment unit 13.

[0026] The scale adjuster 13 associates the difference received from the difference extractor 12 with the metrics value related to the current data of the KPI-related data 102 received from the pre-data metrics value calculator 141 and passes it to the post-data metrics value calculator 142.

[0027] Based on the received data, the post-data-change metrics value calculation unit 142 changes the metrics value of the current KPI-related data to a value having the same difference as the normalized difference between the software architecture design data metrics values ​​before and after the update extracted by the difference extraction unit 12. Specifically, for example, if the normalized difference between the software architecture design data metrics value is 0.5, that is, assuming that the software architecture design data metrics value before the update has increased by 50% of the maximum value from the software architecture design data metrics value before the update to the software architecture design data metrics value after the update, the post-data-change metrics value calculation unit 142 subtracts 0.5 from the normalized value of the current KPI-related data metrics value, and then quantifies this value using the pre-normalization standard to calculate the post-change KPI-related data metrics value. These values ​​are passed to the evaluation prediction unit 15.

[0028] The pre-data-change evaluation prediction value calculation unit 151 of the evaluation prediction unit 15 predicts the evaluation of the current (pre-data-change) KPI-related data metrics value received from the pre-data-change metrics value calculation unit 141, relative to the KPI. Similarly, the post-data-change evaluation prediction value calculation unit 152 predicts the evaluation of the KPI-related data metrics value after the data change, received from the post-data-change metrics value calculation unit 142, relative to the KPI. These calculated values ​​are passed to the fluctuation rate calculation unit 16.

[0029] The fluctuation rate calculation unit 16 compares the two predicted values ​​received from the evaluation prediction unit 15 and calculates the fluctuation rate. In other words, it calculates what percentage of the current KPI-related data metrics value is accounted for by the fluctuation from the KPI-related data metrics value changed based on the difference between the normalized software architecture design data metrics values ​​before and after the update. The calculated rate is passed to the fluctuation rate comparison unit 17.

[0030] The fluctuation rate comparison unit 17 compares the fluctuation rates between all variables, including the fluctuation rate of the software architecture design data metrics value, after receiving the fluctuation rates for all KPI-related data metrics values ​​from the fluctuation rate calculation unit 16. The calculated results are output as input variable impact evaluation results 19 from the evaluation result output unit 18 to an external administrator or the like.

[0031] FIG. 4 is a diagram for explaining a method for calculating a comparison of the fluctuation rates between variables with respect to KPIs when a development support system is applied, visually illustrating the processing explained in FIG.

[0032] First, the values ​​of any software architecture design data metric represented by variable name X1 before and after the update are input into the AI ​​that configures the KPI prediction model, and a KPI evaluation prediction for each is calculated. As an example, in Figure 4, the KPI is the number of bugs, and the number of bugs predicted for the software architecture design data metric value in the current version (after the update) is 20, and the number of bugs predicted for the software architecture design data metric value in the old version (before the update) is 10.

[0033] From this, since the proportion of the KPI fluctuation value (10) before and after the update to the predicted number of bugs (20) for the software architecture design data metrics value in the current version is 50%, in Figure 4 the fluctuation proportion calculation unit 16 calculates 50% as the fluctuation proportion of the software architecture design data metrics value represented by variable name X1 to the KPI.

[0034] In parallel with this, the KPI is predicted for the KPI-related data metric (past project similarity metric in Figure 4) represented by variable name X2, and the fluctuation rate is calculated. As described above, the KPI-related data metric value is changed so that it matches the difference in the normalized software architecture design data metric value before and after the update. In Figure 4, assuming that the normalized value of the current past project similarity metric is 0.7 and the difference in the normalized software architecture design data metric value before and after the update described above is -0.02, the normalized value of the changed past project similarity metric is set to 0.72.

[0035] These values ​​are then input into the KPI prediction model, and the KPI evaluation prediction for each is calculated. In the example in Figure 4, the number of bugs predicted for the current past project similarity metric value is 20, and the number of bugs predicted for the past project similarity metric value after the data change is 18.

[0036] From this, it can be seen that the change in the past project similarity metrics value before and after the change is 2, and the proportion of the current past project similarity metrics value to the predicted number of bugs of 20 is 10%, so in Figure 4 the change proportion calculation unit 16 calculates 10% as the change proportion of the past project similarity metrics value to the KPI.

[0037] The above process is similarly performed on the remaining KPI-related data metrics represented by variable names X3 to X5. As a result, the fluctuation rate calculation unit 16 calculates 15%, 8%, and 30% as the fluctuation rates relative to the KPI for the KPI-related data metrics represented by variable names X3 to X5, respectively.

[0038] The fluctuation rate comparison unit 17 then compares the fluctuation rates between the variables based on the calculation results of the fluctuation rate calculation unit 16. This can be obtained, for example, by leveling out each fluctuation rate so that the total becomes 100%. From this result, it can be seen that when the software version is updated, the impact of the software architecture design data metrics value on the fluctuation of the KPI is 44% of the total, and the impact of the requirement complexity metrics value represented by the variable name X3, for example, on the fluctuation of the KPI is 13% of the total.

[0039] Finally, the flow of processing executed by the development support system 1 will be explained using the flowchart of FIG.

[0040] First, in step S501, arbitrary data is extracted from the software architecture design data and KPI-related data for each version, and is quantified (metrics value calculation) by evaluating it according to a predetermined standard. This process may be executed by, for example, the data modification unit 14, or may be executed by a CPU (not shown) provided in the development support system.

[0041] Next, in step S502, the software architecture design data metrics change ratio between versions is calculated. Specifically, this is executed by the normalization processing by the normalization processing unit 11 (step S5021) and the difference extraction processing by the difference extraction unit 12 (step S5022), which have already been explained.

[0042] Next, in step S503, scale adjustment is performed by the scale adjustment unit 13 based on the current (before change) KPI-related data metrics value and the software architecture design data metrics value difference between versions, and in step S504, data change is performed by the data change metrics value calculation unit 142.

[0043] In step S505, the changed KPI-related data metrics value is input to the evaluation prediction unit 15, and the predicted KPI value is calculated.

[0044] In step S507, it is determined whether the above processing has been executed for all input variables, and the processing of steps S504 to S505 is repeated until the processing has been executed for all input variables.

[0045] In parallel with or prior to the above process, in step S506, KPI predicted values ​​of the current software architecture design data metrics values ​​and KPI-related data metrics values ​​are calculated.

[0046] In step S508, the fluctuation rate calculation unit 16 calculates the fluctuation rate from the KPI predicted values ​​of the KPI-related data metrics values ​​before and after the change.

[0047] Finally, in step S509, the fluctuation rate comparison unit 17 compares the fluctuation rates of the KPI predicted values ​​between the input variables, and calculates the results as the input variable influence evaluation result 19.

[0048] As explained above, according to this embodiment, the KPI-related data metrics values ​​are adjusted so that they have the same fluctuation range as before and after updating the known software architecture design data metrics values, and the KPI is predicted using a KPI prediction model. This makes it possible to evaluate the impact on the KPI of each variable, including the software architecture design data metrics values. Therefore, using this evaluation result, it becomes possible to quickly evaluate the validity of the software architecture design.

[0049] According to the embodiment of the present invention described above, the following advantageous effects are achieved. (1) An example of a development support system according to the present invention includes a memory unit that stores at least update history data of a first component of a development product and current data of a second component; an evaluation prediction unit that predicts an evaluation value for the development success level for each component of the development product; a difference extraction unit that extracts the difference between the current data of the first component and pre-update data, which is one of the update history data; and a data modification unit that generates modified data by modifying the current data of the second component based on the output of the difference extraction unit, wherein the evaluation prediction unit calculates a first variation value of the evaluation value based on the current data and pre-update data of the first component, and calculates a second variation value of the evaluation value based on the current data and post-update data of the second component.

[0050] With the above configuration, if the software architecture design is changed during the execution of a project, the impact of other input variables on the KPI can be predicted using a prediction model, making it possible to verify the validity of the software architecture design at an early stage.

[0051] (2) The system further includes a normalization processing unit that normalizes the current data and pre-update data of the first component, where the difference extraction unit extracts the difference between the normalized current data and pre-update data of the first component, and the data modification unit modifies the current data of the second component to correspond to the normalized difference extracted by the difference extraction unit to generate modified data. This makes it possible to easily compare data between components by normalizing and non-dimensionalizing the data, even if the granularity or units of the data differ between the components.

[0052] (3) The system further includes a fluctuation rate calculation unit that calculates the fluctuation rate of each of the first and second fluctuation values ​​relative to the development performance level. This makes it possible to compare the magnitude of the influence of each fluctuation value on the development performance, and to easily determine which component has a greater influence on the development performance.

[0053] (4) The evaluation prediction unit predicts the evaluation values ​​of the plurality of second components and calculates the variations between the first component and the plurality of second components. splitThis makes it possible to rank and understand the magnitude of the influence of multiple components, in addition to the effect of (3).

[0054] (5) An output unit that outputs the first and second variable values ​​is further provided, which makes it possible to output the evaluation results to a display device or the like that can be viewed by an external administrator or the like, thereby improving the convenience of information management for the administrator or the like.

[0055] (6) The development deliverable is software, the first components are components included in the software itself, and the second components include at least either components related to a software development environment or components related to hardware for executing the software. The present invention is suitably applicable to such a software development environment.

[0056] The present invention is not limited to the above-described embodiments, and various modifications are possible. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to embodiments including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment. It is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to delete part of the configuration of each embodiment, or to add or replace other configurations. [Explanation of symbols]

[0057] 1 Development support system, 11 Normalization processing unit, 12 Difference extraction unit, 13 Scale adjustment unit, 14 Data modification unit, 15 Evaluation prediction unit, 16 Fluctuation rate calculation unit, 17 Fluctuation rate comparison unit, 18 Evaluation result output unit (output unit), 100 Memory unit, 101 Software architecture design data, 102 KPI-related data

Claims

1. A development support system for supporting evaluation of development deliverables, a storage unit that stores at least update history data of a first component of the development deliverable and current data of a second component; an evaluation prediction unit that predicts an evaluation value of a development performance level for each component element of the development deliverable; a difference extraction unit that extracts a difference between current data of the first component and pre-update data that is one data item of the update history data; a data modification unit that generates modified data by modifying the current data of the second component based on the output of the difference extraction unit, the rating prediction unit calculates a first variation of the rating value based on the current data of the first component and the pre-update data, and calculates a second variation of the rating value based on the current data of the second component and the post-change data; A development support system characterized by:

2. 2. The development support system according to claim 1, a normalization processing unit that normalizes the current data of the first component and the pre-update data, the difference extraction unit extracts a difference between the normalized current data of the first component and the pre-update data; the data modification unit modifies the current data of the second component so as to correspond to the normalized difference extracted by the difference extraction unit, thereby generating the modified data. A development support system characterized by:

3. 2. The development support system according to claim 1, a fluctuation rate calculation unit that calculates a fluctuation rate of each of the first fluctuation value and the second fluctuation value with respect to the development result level, A development support system characterized by:

4. 4. The development support system according to claim 3, the evaluation prediction unit predicts the evaluation values ​​of the second components; a fluctuation rate comparison unit that compares the fluctuation rate between the first component and each of the second components; A development support system characterized by:

5. 2. The development support system according to claim 1, further comprising an output unit that outputs the first variable value and the second variable value; A development support system characterized by:

6. 2. The development support system according to claim 1, The development deliverable is software, the first component is a component included in the software itself, The second components include at least one of a component related to a development environment for the software and a component related to hardware for executing the software. A development support system characterized by:

Images