JP7733622B2 - Development Support System - Google Patents

Description

The present invention relates to a development support system that predicts the extent to which an input variable will contribute to the outcome of a project such as software development.

In software development, a project typically goes through multiple version upgrades before the final version of the software is released. In recent years, a concept called KPI (Key Performance Index) has been introduced as a standard 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.

In recent years, technologies have been proposed that use software architecture design data metrics to predict these KPIs. Software architecture design data metrics define criteria for quantitatively evaluating the software architecture (software structure, functional/non-functional requirements, etc.) that is the development target of a 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's impact 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 referred to simply as software architecture design, and software architecture design data metrics will be referred to simply as software architecture design data metrics.

When software versions are updated, in addition to software architecture design data, hardware and project information may also change. Furthermore, as software development projects have grown in scale and complexity in recent years, the number of variables required for KPI prediction continues 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.

Patent document 1 discloses a technology that randomly changes input within a range of values and identifies the input (feature) required to achieve a target objective.

Patent Document 2 also discloses a technology that uses a prediction model to calculate a (second) project success probability from a project parameter set and planned end date, and similarly calculates a (first) project success probability from a new parameter set and planned end date when a project is changed, and estimates the risk of project changes from the difference between the first and second success probabilities.

Japanese Patent Application Laid-Open No. 2020-119085 Japanese Patent Application Laid-Open No. 2020-091843

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

The present invention was made in consideration of the above points, and aims to provide a development support system that uses a predictive model to predict the impact of other input variables on KPIs when the software architecture design is changed during project execution, thereby enabling early verification of the validity of the software architecture design.

An example of a development support system according to the present invention includes a storage unit that stores at least update history data for a first component of a development deliverable and current data for 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 for the first component and pre-update data, which is one piece of update history data; and a data modification unit that generates post-modification data by modifying the current data of the second component based on the output of the difference extraction unit. The evaluation prediction unit calculates a first variation of the evaluation value based on the current data and pre-update data for the first component, and calculates a second variation of the evaluation value based on the current data and post-modification data for the second component.

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 KPIs 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.

FIG. 1 is a diagram showing an overview of a method for predicting KPIs using a prediction model. FIG. 1 is a block diagram showing the functional configuration of a development support system according to an embodiment of the present invention. FIG. 2 is a diagram showing the relationship between the functional units in the processing executed by the development support system. 10 is a diagram for explaining a method for calculating a comparison of the fluctuation rates between variables with respect to a KPI when a development support system is applied. 4 is a flowchart showing a process executed by the development support system.

The following describes in detail an embodiment of the present invention with reference to the drawings.

Figure 1 shows an overview of a method for predicting KPIs by inputting software architecture design data and KPI-related data other than software architecture design 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 of dependencies/amount of data, 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, and includes project management data related to the project itself, such as similarities with past projects and customer requirements, as well as hardware design data such as microcontroller specifications. Specifically, this is the type of data indicated by variable names X2 to X8 in Figure 1, for example.

This data is then input into an AI-based KPI prediction model that has been trained on 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).

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

However, naturally, software architecture design data and KPI-related data also change as software versions are revised. As mentioned above, this, coupled with the increasing complexity of software development projects in recent years and the resulting increase in the number of variables that must be handled, means that while it is possible to predict to some extent the impact of overall variable changes on KPIs, it is extremely difficult to grasp the extent to which changes in each variable affect changes in KPIs.

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

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.

The storage unit 100 stores software architecture design data 101 and KPI-related data 102, which further includes hardware design data 1021 and project management data 1022. The software architecture design data 101 and KPI-related data 102 are stored and linked to each software version.

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.

The functional block diagram shown in Figure 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 Figure 1, or may be realized by functional units not shown in Figure 1.

Figure 3 shows the relationship between each functional unit in the processing executed by the development support system. As an example, referring to Figure 1, the processing when the software version is updated from v2.0 to v3.0 will be described here. 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 affine transformation can be used, where the maximum value of each data is 1 and the minimum value is 0.

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, so it takes on a value between -1 and 1.

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 pre-set 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.

The scale adjustment unit 13 associates the difference received from the difference extraction unit 12 with the metrics value related to the current data of the KPI-related data 102 received from the pre-data-change metrics value calculation unit 141, and passes it to the post-data-change metrics value calculation unit 142.

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 further 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.

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 metric 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 post-data-change KPI-related data metric value 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.

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

After receiving the fluctuation rates for all KPI-related data metric values from the fluctuation rate calculation unit 16, the fluctuation rate comparison unit 17 compares the fluctuation rates between all variables, including the fluctuation rate of the software architecture design data metric values. The calculated results are output as input variable impact evaluation results 19 from the evaluation result output unit 18 to an external administrator, etc.

Figure 4 visually illustrates the process described in Figure 3, and explains how to calculate the fluctuation rate comparison between variables for KPIs when a development support system is applied.

First, the values before and after the update of any software architecture design data metric represented by variable name X1 are input into the AI that constitutes 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.

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

In parallel with this, a KPI is predicted for the KPI-related data metric represented by variable name X2 (past project similarity metric in Figure 4), and the rate of change 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, 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, so the normalized value of the changed past project similarity metric is set to 0.72.

These values are then input into the KPI prediction model, and a KPI evaluation prediction is calculated for each. In the example of 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.

From this, 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.

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 the fluctuation rates relative to the KPI for the KPI-related data metrics represented by variable names X3 to X5 as 15%, 8%, and 30%, respectively.

The fluctuation rate comparison unit 17 then compares the fluctuation rates between 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 is 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 KPI fluctuations is 44% of the total, and the impact of the requirement complexity metrics value represented by variable name X3, for example, on KPI fluctuations is 13% of the total.

Finally, the processing flow executed by the development support system 1 will be explained using the flowchart in Figure 5.

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

Next, in step S502, the inter-version software architecture design data metrics change ratio is calculated. Specifically, this is performed 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), as already explained.

Next, in step S503, the scale adjustment unit 13 performs scale adjustment based on the current (pre-change) KPI-related data metrics value and the difference in software architecture design data metrics value between versions, and in step S504, the data is changed by the post-data-change metrics value calculation unit 142.

In step S505, the changed KPI-related data metrics values are input to the evaluation prediction unit 15, and the KPI prediction values are calculated.

In step S507, it is determined whether the above processing has been performed for all input variables, and steps S504 and S505 are repeated until it has been performed for all input variables.

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

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.

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 input variable influence evaluation result 19.

As explained above, according to this embodiment, KPI-related data metric values are adjusted so that they have the same fluctuation range as before and after updates to known software architecture design data metric values, and KPIs are predicted using a KPI prediction model. This makes it possible to evaluate the impact on KPIs of each variable, including software architecture design data metric values. Therefore, the results of this evaluation can be used to quickly evaluate the validity of the software architecture design.

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 post-modification 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-modification data of the second component.

With the above configuration, if the software architecture design is changed during the project, the predictive model can be used to predict the impact of other input variables on KPIs, making it possible to verify the validity of the software architecture design at an early stage.

(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, thereby generating modified data. This makes it possible to easily compare data by normalizing and non-dimensionalizing it, even if the granularity or units of data differ between components.

(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 degree of influence on the development performance between the fluctuation values, making it easy to determine which components have a greater influence on the development performance.

(4) The evaluation prediction unit further includes a fluctuation rate comparison unit that predicts the evaluation values of multiple second components and compares the fluctuation rates between the first component and the multiple second components. This makes it possible to rank and understand the magnitude of the influence of multiple components, in addition to the effect of (3).

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

(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 the software development environment or components related to hardware for executing the software. The present invention is suitably applicable to such software development environments.

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

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 Storage unit, 101 Software architecture design data, 102 KPI-related data

Claims (6)

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. 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: 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. 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: 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: 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: