Development assistance 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] Generally, in software development, a project 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 criterion for determining how close each version is to the final goal. KPIs are also called "key performance indicators" and are generally quantitative measurement criteria established to manage the process of achieving the final goal of a project. 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, technology has been proposed to predict this KPI using software architecture design data metrics. Software architecture design data metrics define standards 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 by core, the number of dependencies / amount of data, dependency direction, and cyclomatic complexity. In addition, various standards are adopted from the perspectives of measuring the system scale, grasping the sensitivity of the impact of the system on changes, grasping the degree of inter-element coupling, grasping the degree of inter-element coupling, and grasping the degree of element circularity. In the following, software architecture design will be simply referred to as soft architecture design, and software architecture design data metrics will be simply referred to as soft architecture design data metrics.

[0004] When software versions are changed, in addition to software architecture design data, hardware and project information may also change. Moreover, with the increasing scale and complexity of software development projects in recent years, the number of variables required for KPI prediction is also increasing. Therefore, it is necessary to establish a method to calculate the absolute amount of influence of each input variable on the KPI prediction results, and a method to calculate 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 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 change is made to the project, 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] JP 2020-119085 A [Patent Document 2] JP 2020-091843 A 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 KPI impact of architectural design changes. The same is true in Patent Document 2.

[0009] The present invention has been made in consideration of the above-mentioned points, and aims to provide a development support system that, when the software architecture design is changed during the execution of a project, can predict the impact of other input variables on the KPIs using a prediction model, 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 includes a memory unit that stores at least update history data of a first component and current data of a second component of a development product, 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 piece of data from the update history data, and a data modification unit that generates post-change data by modifying the current data of the second component based on the output of the difference extraction unit, and 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-change data of the second component. Effect 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, the problems, configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief description of the drawings]

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

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

[0014] FIG. 1 is a diagram showing 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 indicating the configuration requirements of the software to be developed, and includes the number of modules by core, the number of dependencies / amount of data, the dependency direction, cyclomatic complexity, etc., as described above. KPI-related data is not data related to the software to be developed itself, but other data related to the development project, and includes project management data related to the project itself, such as similarity with past projects and customer requests, and hardware design data such as microcomputer specifications. Specifically, it is the type of data indicated by the variable names X2 to X8 in FIG. 1, for example.

[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 the actually calculated KPIs, and the KPIs are predicted. In Figure 1, examples of KPIs are 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 time the version of the software being developed is revised, the KPIs also change. These results are fed back to the AI ​​of the KPI prediction model, and the prediction accuracy improves.

[0017] However, naturally, software architecture design data and KPI-related data are also changed with software version revisions. As mentioned above, this, coupled with the increase in variables to be handled due to the recent increase in the complexity of software development projects, makes it extremely difficult to grasp the extent to which changes in each variable affect changes in the KPI, although it is possible to predict to some extent the impact of changes in the overall variables on the KPI.

[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 an embodiment of the present invention is shown in Fig. 2. 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 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 ratio calculation unit 16, a fluctuation ratio comparison unit 17, and an evaluation result output unit 18. The 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 that is 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 transmits 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 those shown therein. 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 may be realized by functional units not shown in Fig. 1.

[0023] Fig. 3 is a diagram showing the relationship between each functional unit in the process executed by the development support system. Here, as an example, the process 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 of software version v3.0) and the data before the update (data of 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 to transform the maximum value of each data to 1 and the minimum value to 0.

[0024] Next, the difference extraction unit 12 extracts the difference between the current data and the pre-update data processed by the normalization processing unit 11. This difference is a 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 current data (data for software version v3.0), measures it from a preset viewpoint, and calculates a metrics value. At this time, multiple data may be extracted from the KPI-related data and collectively calculated as a metrics value. The calculated metrics value is passed to the scale adjustment unit 13.

[0026] 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 metrics value calculation unit 141 , and passes it to the post-data metrics value calculation unit 142 .

[0027] Based on the received data, the post-change data 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 of 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-change data metrics value calculation unit 142 subtracts 0.5 from the normalized value of the current KPI-related data metrics value, and further quantifies the value based on the standard before normalization 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 predicted value calculation unit 151 of the evaluation prediction unit 15 predicts the evaluation of the current (before data change) KPI-related data metrics value received from the pre-data-change metrics value calculation unit 141 with respect to the KPI. Similarly, the post-data-change evaluation predicted 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 with respect to the KPI. These calculated values ​​are passed to the fluctuation ratio calculation unit 16.

[0029] The fluctuation ratio calculation unit 16 compares the two predicted values ​​received from the evaluation prediction unit 15 and calculates the fluctuation ratio. That is, it calculates what percentage of the current KPI-related data metrics value 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 accounts for. The calculated percentage is passed to the fluctuation ratio comparison unit 17.

[0030] The fluctuation ratio comparison unit 17 compares the fluctuation ratios between all variables, including the fluctuation ratios of the software architecture design data metrics values, after receiving the fluctuation ratios for all KPI-related data metrics values ​​from the fluctuation ratio calculation unit 16. The calculated results are output as input variable influence 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 of calculating a comparison of the fluctuation rates between variables with respect to a KPI when a development support system is applied, visually illustrating the process explained in FIG.

[0032] First, the values ​​of any software architecture design data metric represented by the variable name X1 before and after the update are input into the AI ​​that constitutes the KPI prediction model, and the evaluation prediction of the KPI 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 represented by the variable name X2 (past project similarity metric in Fig. 4), 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 Fig. 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 above-mentioned update is -0.02, so 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, 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 ratio calculation unit 16 calculates 10% as the change ratio 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 the variable names X3 to X5. As a result, the fluctuation ratio calculation unit 16 calculates the fluctuation ratios of the KPI-related data metrics represented by the variable names X3 to X5 to 15%, 8%, and 30%, respectively, relative to the KPI.

[0038] Then, the fluctuation rate comparison unit 17 compares the fluctuation rates between the variables based on the calculation results of the fluctuation rate calculation unit 16. This is 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 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 the process executed by the development support system 1 will be described with reference to the flowchart of FIG.

[0040] First, in step S501, any data is extracted from the software architecture design data and KPI-related data for each version, and quantified (metrics value calculation) by evaluating it based on 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) included in the development support system.

[0041] Next, in step S502, the software architecture design data metrics change ratio between versions is calculated. This is specifically 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 described.

[0042] Next, in step S503, scale adjustment is performed by the scale adjustment unit 13 based on the current (pre-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 post-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 KPI predicted value is calculated.

[0044] In step S507, it is determined whether the above processing has been executed for all the input variables, and the processing in steps S504 to S505 is repeated until the processing has been executed for all the 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 ratio calculation unit 16 calculates the fluctuation ratio from the KPI predicted values ​​of the KPI-related data metrics values ​​before and after the change.

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

[0048] As described above, according to this embodiment, the KPI-related data metric values ​​are adjusted so that they have the same fluctuation range as before and after updating the known software architecture design data metric values, and the KPI is predicted using a KPI prediction model. This makes it possible to evaluate the impact of each variable, including the software architecture design data metric values, on the KPI. Therefore, using the evaluation results, 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 obtained. (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 a 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-change 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-change 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) A normalization processing unit that normalizes the current data and pre-update data of the first component is further provided, 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 unit of the data differs between the components.

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

[0053] (4) The evaluation prediction unit further includes a fluctuation ratio comparison unit that predicts the evaluation values ​​of the multiple second components and compares the ratio of the fluctuation values ​​between the first component and the multiple second components. This makes it possible to rank and grasp 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. 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 the administrator, etc.

[0055] (6) The development deliverable is software, the first components are components contained in the software itself, and the second components include at least either components related to a development environment for the software 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 an embodiment having all of the configurations described. It is also possible to replace a 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 a part of the configuration of each embodiment, or to add or replace another configuration. [Explanation of symbols]

[0057] 1 Development support system, 11 Normalization processing unit, 12 Difference extraction unit, 13 Scale adjustment unit, 14 Data change 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 Soft architecture design data, 102 KPI related data

Claims

1. A development support system for supporting evaluation of development deliverables, comprising: 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 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 of the update history data; a data modification unit that generates modified data by modifying the current data of the second component based on an output of the difference extraction unit; the evaluation prediction unit calculates a first variation value of the evaluation value based on the current data and the pre-update data of the first component, and calculates a second variation value of the evaluation value based on the current data and the post-change data of the second component; A development support system comprising:

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

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

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

5. 2. The development support system according to claim 1, An output unit that outputs the first variable value and the second variable value is further provided. A development support system comprising:

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 of the software or a component related to hardware for executing the software. A development support system comprising:

Images