Software development support device and software development support method

Abstract

The purpose of the present invention is to provide technology with which it is possible to notify a manager of an appropriate progress of software development. This software development support device comprises: a learning model generation unit that performs machine learning on a learning model on the basis of past deliverables information and generates an inference value of performance of each developer by using the learning model; an intermediate deliverables monitoring unit that generates alert information on the basis of a comparison result between an actual value calculated on the basis of the intermediate deliverables information of the current software development and the inference value; and a development state notification unit that notifies a manager of the alert information.

Description

Software development support device and software development support method

[0001] The present disclosure relates to a software development support device and a software development support method.

[0002] In recent software development, the use of cloud computing, shared servers, Outlook, Teams, and other communication tools has become widespread, making it possible for software developers and their managers to work remotely. However, in this type of development, opportunities for face-to-face communication between managers and other developers tend to decrease, requiring managers to keep a close eye on the progress and quality of each developer.

[0003] To manage the progress of software development, it is common to use tools with progress management functions and progress management tables. Developers themselves input progress data into the tools and management tables at regular meetings and other times. When development delays occur, there is a possibility that developers will be unable to input progress data. Therefore, if the manager and developer are located in the same location, the manager may communicate directly with the developer to input progress data into the progress management tool and progress management table.

[0004] The main methods proposed for verifying software quality are review and testing.

[0005] A review involves visually inspecting documents, such as requirements specifications that describe customer requirements and software design documents that describe the software's configuration and functions, as well as the source code that is implemented to run the software, to detect software defects. The stakeholders in this context include software developers, managers, customers, and hardware developers. The documents and source code are also called deliverables.

[0006] Testing involves running the implemented software to verify whether it operates as expected and to detect software defects. In order to develop high-quality software, it is effective to identify deliverables that are likely to contain many software defects and prioritize review and testing of those deliverables.

[0007] In addition, a technology has been proposed for displaying performance problems, i.e., the work ability of workers, at production sites that produce physical objects, rather than intangible objects such as software (for example, Patent Document 1).

[0008] Japanese Patent Application Laid-Open No. 2019-021014

[0009] In software development, it takes longer to complete a deliverable than to produce the actual product. For this reason, it is preferable for managers to understand a developer's performance by taking into account the intermediate deliverables obtained until the deliverable is completed. However, conventional technologies related to the production of actual products do not take into account the status of the intermediate deliverables, which makes it difficult to properly understand the progress of software development.

[0010] Therefore, the present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a technology that can notify an administrator of appropriate progress in software development.

[0011] The software development support device according to the present disclosure includes a data acquisition unit that acquires past product information of each developer in past software development; a learning model generation unit that performs machine learning on a learning model for inferring the performance of each developer based on the past product information and generates an inferred value of the performance of each developer using the learning model; an intermediate product monitoring unit that calculates actual performance values ​​of each developer based on intermediate product information of the current software development and generates alert information based on the comparison result between the actual values ​​and the inferred values; and a development status notification unit that notifies an administrator of the alert information.

[0012] According to the present disclosure, a manager is notified based on the results of a comparison between the inferred performance values ​​of each developer generated using a learning model and the actual performance values ​​of each developer calculated based on intermediate product information. With this configuration, the manager can be notified of appropriate progress in software development.

[0013] The objects, features, aspects and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings.

[0014] 1 is a block diagram showing a configuration of a software development support device according to a first embodiment. FIG. 1 is a flowchart showing the operation of a data acquisition unit according to the first embodiment. FIG. 2 is a diagram showing an example of a past performance result value according to the first embodiment. FIG. 3 is a flowchart showing the operation of a learning model generation unit according to the first embodiment. FIG. 4 is a diagram showing an example of an inferred value of performance according to the first embodiment. FIG. 5 is a flowchart showing the operation of an intermediate deliverable monitoring unit according to the first embodiment. FIG. 6 is a diagram showing an example of alert information according to the first embodiment. FIG. 7 is a flowchart showing the operation of a development status notification unit according to the first embodiment. FIG. 8 is a diagram showing an example of alert information notified by the development status notification unit according to the first embodiment. FIG. 9 is a block diagram showing a configuration of a software development support device according to a second embodiment. FIG. 10 is a flowchart showing the operation of a countermeasure result prediction unit according to the second embodiment. FIG. 11 is a diagram for explaining the operation of the countermeasure result prediction unit according to the second embodiment. FIG. 12 is a block diagram showing a configuration of a software development support device according to a third embodiment. FIG. 13 is a diagram showing an example of alert information according to the third embodiment. FIG. 14 is a flowchart showing the operation of a review target extraction unit according to the third embodiment. FIG. 15 is a flowchart showing the operation of a review target display unit according to the third embodiment. FIG. 16 is a diagram showing an example of review target evaluation object information according to the third embodiment. FIG. 17 is a flowchart showing the operation of a learning model generation unit according to the fourth embodiment. FIG. 18 is a diagram showing an example of an inferred value of support performance according to the fourth embodiment. FIG. 19 is a block diagram showing a configuration of a software development support device according to a fifth embodiment. FIG. 19 is a flowchart showing the operation of a support adequacy setting unit according to the fifth embodiment. Fig. 10 is a flowchart showing the operation of a learning model generation unit according to embodiment 5. Fig. 11 is a diagram showing an example of support suitability according to embodiment 5. Fig. 12 is a diagram showing an example of an inferred value of support performance according to embodiment 5. Fig. 13 is a block diagram showing the hardware configuration of a software development support device according to another modified example. Fig. 14 is a block diagram showing the hardware configuration of a software development support device according to another modified example.

[0015] <First Embodiment> Fig. 1 is a block diagram showing the configuration of a software development support device according to the first embodiment. The software development support device in Fig. 1 includes a data acquisition unit 1, a learning model generation unit 2, an intermediate product monitoring unit 3, a development status notification unit 4, a past product database 11, a storage unit 12, and a current intermediate product database 31.

[0016] First, an overview of the components of the software development support device will be described.

[0017] The data acquisition unit 1 acquires past product information of each developer in past software development from the past product database 11. The past product information is information about the products of past software development, and the products include at least one of documents and source code developed to run the software. In this specification, for example, "at least one of A, B, C, ..., and Z" means any one of all combinations of one or more items selected from the group A, B, C, ..., and Z.

[0018] The past deliverable information includes past performance results 111 for each function type of each developer and for each software development process in past development projects. The function types include, for example, Model (data processing, etc.) corresponding to M, View (screen display, etc.) corresponding to V, and Controller (overall control, etc.) corresponding to C in the MVC model, which is a typical software design model. The software development process (hereinafter sometimes referred to as "development process") includes, for example, requirement analysis, design, implementation, and testing.

[0019] The past deliverable information may include not only the past performance result value 111 but also, for example, the instructions given to each developer when a past deliverable was created in a past development project. Furthermore, the past deliverable information may also include, for example, specifications that document requirements for the software to be developed and the software functions and software configuration for realizing those requirements. Furthermore, the past deliverable information may also include, for example, the deliverable itself, such as source code.

[0020] The learning model generation unit 2 performs machine learning on a learning model for inferring the performance of each developer based on the past work product information acquired by the data acquisition unit 1. For the machine learning, machine learning (training) such as deep learning is used.

[0021] Furthermore, the learning model generation unit 2 uses the learning model generated by machine learning to generate an inferred value 121 of the performance of each developer for each function type and each software development process in the current development project. The inferred value 121 generated by the learning model generation unit 2 is stored in the storage unit 12. Note that the learning model generated by learning in the learning model generation unit 2 may also be stored in the storage unit 12.

[0022] The current intermediate product database 31 stores intermediate product information for the current software development created by the developer 5. The intermediate product information is information related to intermediate products, which are products generated until the final product of the current software development is completed. The intermediate product information may be any information that allows calculation of the current performance results for each function type and each software development process of each developer 5 in the current software development. In the first embodiment, the intermediate product information includes, but is not limited to, the time required to create and the scale of creation of intermediate products including at least one of the document 312 and the source code 313. In the first embodiment, the intermediate product information also includes, but is not limited to, the development plan 311 for the current software development, the document 312, and the source code 313.

[0023] The intermediate product monitoring unit 3 acquires intermediate product information for the current software development from the current intermediate product database 31. Then, based on the intermediate product information, the intermediate product monitoring unit 3 calculates the current performance results for each function type and each software development process of each developer 5 in the current development project.

[0024] Furthermore, the intermediate product monitoring unit 3 compares the calculated actual value with the inferred value 121 stored in the storage unit 12, and generates alert information based on the comparison result. In the first embodiment, the intermediate product monitoring unit 3 generates alert information indicating that a development delay has occurred when the actual value for one developer 5, that is, for any developer 5, is less than the inferred value 121. Note that a development delay is also called a progress delay.

[0025] The development status notification unit 4 notifies the manager 6 who manages the developers 5 of the alert information generated by the intermediate product monitoring unit 3. This allows the manager 6 to know that a development delay has occurred in the current software development. Next, the components of the software development support device will be described in detail.

[0026] 2 is a flowchart showing the operation of the data acquisition unit 1 according to the present embodiment 1. In step S11, the data acquisition unit 1 acquires past product information including past performance results 111 from the past product database 11. In step S12, the data acquisition unit 1 outputs the past product information acquired in step S11 to the learning model generation unit 2.

[0027] Fig. 3 is a diagram showing an example of the past performance result value 111. The past performance result value 111 is set for each development project, and in the example of Fig. 3, it is set for each of the first project and the second project.

[0028] The past performance result value 111 in FIG. 3 includes a past performance result value 1113 for each function type 1112 of each developer 1111 and for each development process for the first project.

[0029] In the example of Fig. 3, in the first project, developer A of developer 1111 is in charge of the screen (V) in function type 1112, and when he created the requirements analysis document in the requirements analysis process, the past performance result value 1113 was 3 pages / hour. Note that hereinafter, time may also be abbreviated as "Hr." In the example of Fig. 3, in the first project, developer C of developer 1111 is in charge of the screen (V) in function type 1112, and when he created the source code in the implementation process, the past performance result value 1113 was 70 lines / hour.

[0030] The past performance result value 111 in FIG. 3 also includes a past performance result value 1123 for each function type 1122 of each developer 1121 and for each development process for the second project.

[0031] 3, in the second project, developer A of developer 1121 is in charge of screen (V) in function type 1122, and when he created the requirements analysis document in the requirements analysis process, the past performance result value 1123 is 1 page / Hr. In the example of Fig. 3, in the second project, developer C of developer 1121 is in charge of screen (V) in function type 1122, and when he created the design document in the design process, the past performance result value 1123 is 7 pages / Hr.

[0032] It should be noted that a process with "-" set in the past performance result values ​​1113 and 1123 indicates that the developer in question was not in charge of the project in question in the past, and therefore no result value exists for the developer in question.

[0033] The format in which the data acquisition unit 1 acquires the past performance actual values ​​111 from the past deliverables database 11 may be changed depending on the development project and organization. For example, some organizations may require that daily work hours be broken down into development projects, function types, and development processes and entered into an employment management system. In such cases, the data acquisition unit 1 may acquire the values ​​acquired from the employment management system as the past performance actual values ​​111 almost as they are.

[0034] On the other hand, some organizations require that only the daily start and end times of work be entered into the work management system, without tallying up details of the work content. In such cases, the data acquisition unit 1 may acquire the past performance actual values ​​111 from a server that stores software development deliverables and aggregates performance based on the edit time and amount of changes to the deliverables. The server may enable a periodic auto-save function when a deliverable file is opened and acquire and accumulate the amount of changes to the deliverable at the time of auto-save. Alternatively, if the amount of changes is zero, the server may determine that no work has been done and not accumulate the amount of changes. When the server is configured in this manner, the accuracy of the past performance actual values ​​111 acquired by the data acquisition unit 1 can be improved. Note that by finely configuring the periodic auto-save function within a range that does not reduce work efficiency, the accuracy of the amount of changes can be improved, thereby further improving the accuracy of the past performance actual values ​​111 acquired by the data acquisition unit 1.

[0035] 4 is a flowchart showing the operation of the learning model generation unit 2 according to the first embodiment. In step S21, the learning model generation unit 2 acquires past work product information from the data acquisition unit 1. In step S22, the learning model generation unit 2 performs machine learning on a learning model based on the past work product information acquired in step S21, and generates an inferred value 121 of the performance of each developer using the learning model thus generated. In step S23, the learning model generation unit 2 stores the inferred value 121 generated in step S22 in the storage unit 12.

[0036] 5 is a diagram showing an example of an inferred value 121 of performance generated by the learning model generation unit 2. To calculate the inferred value 121, a learning model is used in which, if an actual value exists for only one of the first and second projects in FIG. 3 , that actual value is used as the inferred value 121, and, if actual values ​​exist for both projects, the average of those actual values ​​is used to generate the inferred value 121.

[0037] Note that the learning model generated by the learning model generation unit 2 according to the first embodiment is not limited to this. For example, the learning model generation unit 2 may generate a learning model in which the closer the past deliverable information is to the intermediate deliverable information, the greater the weighting of the performance value of the past deliverable information used in the inferred value 121. In other words, the learning model generation unit 2 may generate a learning model in which the weighting of the performance value of one of the first and second projects in FIG. 3 that has a higher similarity to the current software development project is greater than the weighting of the performance value of the other project, thereby more effectively reflecting the weighting in the inferred value 121. The similarity between projects may be, for example, the similarity between the deliverables of the projects or the proximity of the development times of the projects.

[0038] The inference value 121 in FIG. 5 includes a performance inference value 1213 for each function type 1212 of each developer 1211 and for each development process.

[0039] 5, in the current software development, when developer A of developer 1211 is in charge of the screen (V) in function type 1212 and creates a requirements analysis document in the requirements analysis process, the performance inference value 1213 is 2 pages / Hr. In the example of Fig. 5, in the current software development, when developer C of developer 1211 is in charge of the screen (V) in function type 1212 and creates source code in the implementation process, the performance inference value 1213 is 70 lines / Hr.

[0040] When planning the current software development, the manager 6 can easily determine which developer 5 should be assigned to which development process for which function by utilizing the performance inference value 121 while taking into consideration the development period, development costs, etc.

[0041] 6 is a flowchart showing the operation of the intermediate product monitoring unit 3 according to the first embodiment. In step S31, the intermediate product monitoring unit 3 reads the inference value 121 stored in the storage unit 12. In step S32, the intermediate product monitoring unit 3 reads the intermediate product information of the current software development created by the developer 5 from the current intermediate product database 31. In step S33, the intermediate product monitoring unit 3 calculates the performance results value for each function type and each software development process of each developer, based on the creation time and development scale of the intermediate product included in the intermediate product information read in step S32.

[0042] In step S34, the intermediate product monitoring unit 3 determines whether the actual result value calculated in step S33 is less than the inferred value 121 read in step S31. If it is determined that the actual result value is less than the inferred value 121, the process proceeds to step S35, and if it is determined that the actual result value is equal to or greater than the inferred value 121, the process in FIG. 6 ends. In step S35, the intermediate product monitoring unit 3 generates alert information and outputs the alert information to the development status notification unit 4.

[0043] Fig. 7 is a diagram showing an example of alert information generated in step S35 of Fig. 6. The alert information of Fig. 7 includes a scale 341 of the deliverable to be created, a performance result value 342, a comparison result 343, and a predicted value 344 of development delay.

[0044] 7, the scale 341 of the deliverable to be created includes a 30-page requirements analysis specification and a 100-page design document. The scale 341 of the deliverable to be created is acquired from the development plan 311 included in the intermediate deliverable information, for example.

[0045] The performance result value 342 is the result value calculated in step S33 of Fig. 6. In the example of Fig. 7, the performance result values ​​of developer A for creating requirements analysis specifications and creating design documents on screen (V) are 3 pages / hour and 2 pages / hour, respectively.

[0046] Comparison result 343 shows the comparison result of step S34 in Fig. 6. With regard to developer A's performance in creating requirements analysis specifications on screen (V), the inferred value in Fig. 5 is 2 pages / hour, and the actual value in Fig. 7 is 3 pages / hour. Therefore, the comparison result shows that the actual value is equal to or greater than the inferred value, and it is determined that no development delay has occurred. On the other hand, with regard to developer A's performance in creating design documents on screen (V), the inferred value in Fig. 5 is 4 pages / hour, and the actual value in Fig. 7 is 2 pages / hour. Therefore, the comparison result shows that the actual value is less than the inferred value, and it is determined that a development delay has occurred.

[0047] The development delay prediction value 344 is calculated by the intermediate deliverable monitoring unit 3. For example, the intermediate deliverable monitoring unit 3 acquires the remaining work scale and remaining work time from the intermediate deliverable information. In the example of FIG. 7 , the remaining work scale is an 80-page design document, and the remaining work time is 32 hours. Since the remaining work scale is an 80-page design document and Developer A's performance record for creating the design document is 2 pages / hour, the intermediate deliverable monitoring unit 3 calculates 40 hours (= 80 / 2) as the time required to complete the design document. Then, the intermediate deliverable monitoring unit 3 calculates the difference between the calculated time and the remaining work time, 8 hours (= 40 - 32), as the development delay prediction value 344.

[0048] <Development Status Notification Unit 4> Figure 8 is a flowchart showing the operation of development status notification unit 4 according to the first embodiment. In step S41, development status notification unit 4 determines whether or not it has received alert information such as that shown in Figure 7 from intermediate product monitoring unit 3. If it is determined that it has received alert information, the process proceeds to step S42, and if it is determined that it has not received alert information, the process of Figure 8 ends. In step S42, development status notification unit 4 notifies manager 6 of the alert information it received from intermediate product monitoring unit 3. Development status notification unit 4 may notify manager 6 of the alert information it received from intermediate product monitoring unit 3 as is, or may process the alert information as appropriate and then notify manager 6.

[0049] FIG. 9 is a diagram showing an example of alert information notified by the development status notifying unit 4. The notification in FIG. 9 includes the developer experiencing delays, the developer's responsibilities, a predicted development delay, and a message urging the developer to make up for the delay. Notification of the alert information includes, for example, displaying the alert information on a display terminal such as a display. By notifying the manager 6 of alert information such as that in FIG. 9, the manager 6 has an opportunity to take corrective measures to support the developer 5.

[0050] Summary of First Embodiment According to the software development support device of the first embodiment described above, the manager 6 is notified based on the results of a comparison between the inferred performance values ​​of each developer generated using a learning model and the actual performance values ​​of each developer calculated based on intermediate product information. With this configuration, the intermediate product information is taken into consideration, so that the manager 6 can be notified early of appropriate progress in the current software development. This allows the manager 6 to take early measures to make up for development delays.

[0051] 10 is a block diagram showing the configuration of a software development support device according to a second embodiment. In the following, of the components according to the second embodiment, components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components will be mainly described.

[0052] The configuration in Fig. 10 is the same as the configuration in Fig. 1 , but with the addition of a countermeasure result prediction unit 7. When the actual performance value for one developer becomes smaller than the inferred performance value 121 and, as a result, alert information such as that in Fig. 7 is generated, the countermeasure result prediction unit 7 acquires the alert information from the intermediate deliverable monitoring unit 3 and acquires the inferred performance values ​​121 of each developer from the storage unit 12. The countermeasure result prediction unit 7 presents the acquired inferred performance values ​​121 to the manager 6. As a result, the inferred performance value 121 of the one developer and the inferred performance values ​​121 of developers other than the one developer are presented to the manager 6.

[0053] The administrator 6 selects another developer to make up for the development delay of one developer, taking into consideration the functional category and development process in which the development delay is occurring, based on the alert information notified by the development status notification unit 4 and the inferred value 121 presented by the countermeasure result prediction unit 7. The administrator 6 then inputs the selected other developer into the countermeasure result prediction unit 7 and specifies them.

[0054] Based on the alert information from the intermediate deliverable monitoring unit 3, the countermeasure result prediction unit 7 calculates recovery prediction information for the development delay as a predicted result of progress when another developer designated by the manager 6 supports the one developer, and presents the recovery prediction information to the manager 6. From the recovery prediction information presented by the countermeasure result prediction unit 7, the manager 6 can determine appropriate recovery measures for the development delay and whether or not recovery measures for the development delay are necessary.

[0055] 11 is a flowchart showing the operation of the countermeasure result prediction unit 7 according to the present embodiment 2. The following operation is performed when alert information is generated by the intermediate product monitoring unit 3.

[0056] In step S71, the countermeasure result prediction unit 7 acquires alert information from the intermediate deliverable monitoring unit 3. In step S72, the countermeasure result prediction unit 7 acquires the inferred performance values ​​121 of each developer from the storage unit 12. In step S73, the countermeasure result prediction unit 7 presents the inferred performance values ​​121 of each developer acquired from the storage unit 12 to the administrator 6.

[0057] In step S74, the manager 6 specifies another developer to make up for the development delay, and the countermeasure result prediction unit 7 acquires the other developer specified by the manager 6. In step S75, the countermeasure result prediction unit 7 predicts progress if the other developer acquired in step S74 supports the developer experiencing development delay, based on the alert information, and generates development delay recovery prediction information. In step S76, the countermeasure result prediction unit 7 presents the development delay recovery prediction information to the manager 6.

[0058] Fig. 12 is a diagram for explaining the operation of the countermeasure result prediction unit 7. In the example of Fig. 12, the administrator 6 designates developer C as another developer who will support the screen design process of developer A, who is experiencing a development delay, based on the inferred value 121 of Fig. 5 presented by the countermeasure result prediction unit 7.

[0059] In this case, in step S75 of Fig. 11, the countermeasure result prediction unit 7 predicts progress when another developer C designated by the manager 6 supports one developer A, and generates development delay recovery prediction information 761 as shown in Fig. 12. Then, in step S76 of Fig. 11, the countermeasure result prediction unit 7 presents the recovery prediction information 761 as shown in Fig. 12 to the manager 6.

[0060] 12 includes a work scale 7611 of the remaining deliverable (here, the design document on page 80), an actual performance value 7612 of one developer A for whom development delays are occurring, and an inferred performance value 7613 of another developer C designated by the manager 6. The recovery prediction information 761 in Fig. 12 also includes an inferred performance value 7614 in the case where development is carried out in a collaborative system between one developer A and another developer C, man-hours 7615 required to complete the design document on page 80 7611, and a completion date and plan achievement probability 7616 in the case where development proceeds with the man-hours 7615.

[0061] <Summary of Second Embodiment> According to the software development support device of the second embodiment described above, when the actual value for one developer is smaller than the inferred value, the inferred values ​​of the other developers are presented to the manager 6, and progress in the case where other developers designated by the manager 6 support the one developer is predicted and presented to the manager 6. With this configuration, the manager 6 can easily determine whether or not delay recovery measures are necessary by checking the recovery prediction information when planning personnel reallocation, which is expected to improve productivity.

[0062] 13 is a block diagram showing the configuration of a software development support device according to a third embodiment. In the following, of the components according to the third embodiment, components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components will be mainly described.

[0063] The configuration of FIG. 13 is the same as that of FIG. 10, except that a review target extraction unit 8, a review target display unit 9, a current final product database 32, and an alert information storage unit 41 are added.

[0064] When it is determined that a development delay has occurred, the development status notification unit 4 notifies the manager 6 of alert information 411 and stores the alert information 411 in the alert information storage unit 41 .

[0065] The current final product database 32 stores final product information of the current software development created by the developer 5. The final product information is information about the final product of the current software development. For example, if the document is not complete but the source code is, the intermediate product information includes information about the document, and the final product information includes information about the source code. In the third embodiment, the final product information includes, but is not limited to, the document 321 and the source code 322.

[0066] The review target extraction unit 8 acquires intermediate product information from the current intermediate product database 31, final product information from the current final product database 32, and alert information 411 from the alert information storage unit 41. Then, based on the acquired information, the review target extraction unit 8 extracts review target deliverables that should be reviewed with priority by the manager 6. For example, the review target extraction unit 8 extracts, from among the intermediate deliverables and final deliverables, deliverables that were created when a development delay occurred as review target deliverables to be reviewed. The review target extraction unit 8 generates review target deliverable information, which is information related to the extracted review target deliverables, and outputs the information to the review target display unit 9. Note that the review target deliverable information may be the review target deliverable itself.

[0067] The review target display unit 9 presents the review target deliverable information generated by the review target extraction unit 8 to the manager 6. By giving priority to reviewing the review target deliverable information displayed on the review target display unit 9, the manager 6 can quickly discover defects in the current software development.

[0068] 14 is a diagram showing an example of alert information stored in the alert information storage unit 41. The alert information in FIG. 14 includes an identification number 4111 uniquely assigned to the alert information, a notification date and time 4112 indicating the date and time of notification, a developer 4113 determined to be experiencing a development delay, a function type 4114 and a development process 4115 for which the developer 4113 is responsible. The function type 4114 indicates, for example, one of M (data processing, etc.), V (screen display, etc.), and C (overall control, etc.), similar to the function type 1112 in FIG. 3. The development process 4115 indicates, for example, one of requirement analysis, design, implementation, and testing.

[0069] 14 also includes a performance result value 4116. The performance result value 4116 is a performance result value for each function type and software development process of each developer 4113 in the current development project, and is calculated by the intermediate product monitoring unit 3 in step S33 of FIG.

[0070] 14 also includes a performance inference value 4117. The performance inference value 4117 is the performance inference value 121 for each function type and each software development process of each developer 4113 in the current development project, as shown in FIG. 5, and is generated by the learning model generation unit 2 in step S22 of FIG.

[0071] 14 also includes a name 4118 of a notification target deliverable. The name 4118 of a notification target deliverable indicates the name of an intermediate deliverable in the current software development for which the performance result value 4116 has been calculated by the intermediate deliverable monitoring unit 3. An intermediate deliverable created when the performance result value 4116 is less than the performance inferred value 4117, i.e., a notification target deliverable, has a high risk of containing a defect. For this reason, in the current software development, a notification target deliverable is a deliverable that should be reviewed by the manager 6 as a priority.

[0072] As described above, in the example of Figure 14, the alert information with identification number 4111 of No. 1 indicates that "the inferred value of the performance of developer A's screen function requirements analysis process is 2 pages / hour, its actual value is 0.5 pages / hour, and the name of the intermediate deliverable generated by the work is document number XXX: Screen Requirements Specification" was notified at 10:58 on April 11, 2023.

[0073] 15 is a flowchart showing the operation of the review target extraction unit 8 according to the third embodiment. In step S81, the review target extraction unit 8 acquires alert information 411 notified in the current software development from the alert information storage unit 41. In step S82, the review target extraction unit 8 acquires intermediate product information including documents 312 and source code from the current intermediate product database 31. In step S83, the review target extraction unit 8 acquires final product information including documents 321 and source code 322 from the current final product database 32. The order of steps S31 to S33 may be changed as appropriate.

[0074] In step S84, the review target extraction unit 8 extracts review target deliverables that should be reviewed with priority by the manager 6, based on the intermediate deliverable information, final deliverable information, and alert information 411. The review target extraction unit 8 extracts, for example, from among the intermediate deliverables and final deliverables, deliverables that were created when a development delay occurred, as review target deliverables to be reviewed. In step S85, the review target extraction unit 8 outputs the review target deliverable information to the review target display unit 9.

[0075] 16 is a flowchart showing the operation of the review target display unit 9 according to the third embodiment. In step S91, the review target display unit 9 determines whether or not it has received the review target deliverable information output from the review target extraction unit 8. If it is determined that the review target deliverable information has been received, the process proceeds to step S92, and if it is determined that the review target deliverable information has not been received, the operation in FIG. 16 ends. In step S92, the review target display unit 9 generates review target deliverable information and displays it to the manager 6.

[0076] FIG. 17 is a diagram showing an example of review target deliverable information displayed by the review target display unit 9. The review target deliverable information in FIG. 17 includes an identification number 91 uniquely assigned to the review target deliverable information, a function type 92 related to the review target deliverable, a development process 93 and developer 96, a status 94 of the review target deliverable, and a name 95 of the review target deliverable. The function type 92 indicates, for example, one of M (data processing, etc.), V (screen display, etc.), and C (overall control, etc.). The development process 93 indicates, for example, one of requirements analysis, design, implementation, and testing. The status 94 of the review target deliverable indicates whether the review target deliverable is an intermediate deliverable or a final deliverable. The developer 96 indicates the developer who created the review target deliverable.

[0077] In the example of Figure 17, the information on the review target deliverable with identification number 91 No. 1 indicates that the intermediate deliverable of "Document No. XXX: Screen Requirement Specification" created by developer A regarding the screen function and requirement analysis process is the review target deliverable.

[0078] Summary of Third Embodiment According to the software development support device of the third embodiment described above, a deliverable to be reviewed that should be reviewed with priority by the manager 6 is extracted, and information about the deliverable to be reviewed is displayed to the manager 6. With this configuration, a quality check can be performed immediately after a defect is introduced, thereby preventing the defect from spreading to other deliverables. As a result, high-quality software can be developed efficiently.

[0079] Fourth Embodiment There are cases where a developer participates in development as a support member supporting other developers. However, the performance of a developer when he or she is in charge of the main task is not necessarily the same as the support performance, which is the performance of a developer when supporting the main task. Therefore, in the software development support device according to the fourth embodiment, the learning model generation unit 2 of the first to third embodiments is configured to generate an inferred value of the support performance.

[0080] Specifically, the learning model generation unit 2 performs machine learning (training) on ​​a support learning model for inferring the support performance of each developer based on the support track record of each developer.The learning model generation unit 2 then generates an inferred value of the support performance of each developer using the support learning model.

[0081] 18 is a flowchart showing the operation of the learning model generation unit 2 according to the fourth embodiment. In step S101, the learning model generation unit 2 acquires support performance actual values, including the support performance of each developer in past software development, from the data acquisition unit 1. In step S102, the learning model generation unit 2 performs machine learning on a support learning model based on the support performance actual values ​​acquired in step S101, and generates an inferred value of the support performance of each developer using the support learning model. In step S103, the learning model generation unit 2 stores the inferred value of the support performance generated in step S102 in the memory unit 12.

[0082] 19 is a diagram showing an example of an inferred value 211 of support performance generated by the learning model generation unit 2. The inferred value 211 of support performance is associated with each developer, responsible function type, and development process. In the example of FIG. 19, when developer A is in charge of supporting screen (V) in the current software development, the inferred value 211 of support performance for creating a requirements analysis document in the requirements analysis process is 1.5 pages / hour.

[0083] Summary of the Fourth Embodiment According to the software development support device of the fourth embodiment, machine learning is performed on a support learning model based on the support performance of each developer, and an inferred value of the support performance of each developer is generated using the support learning model. With this configuration, when a situation arises in which developer support is required for a certain process, the administrator or the software development support device can assign a developer as a support member based on the inferred value of the support performance. As a result, a plan can be created that can make up for development delays.

[0084] Fifth Embodiment Support members are required to quickly identify the issues the main person in charge is facing, investigate the causes, and develop solutions. Support members are also required to have communication skills, such as attentive listening, involving other parties, and timely status reports, which accompany collaboration with the main person in charge. Therefore, the software development support device according to the fifth embodiment is configured so that, for example, an administrator 6 can set these "qualities that a support member should possess" as "support aptitude," and generate (calculate) an inferred value for support performance based on this.

[0085] 20 is a block diagram showing the configuration of a software development support device according to the fifth embodiment. In the following, among the components according to the fifth embodiment, components that are the same as or similar to the components described above are given the same or similar reference numerals, and different components will be mainly described.

[0086] 20 includes a support suitability setting unit 10 in addition to the data acquiring unit 1, learning model generating unit 2, past deliverable database 11, and storage unit 12 described in the first embodiment. Note that the fifth embodiment may be applied to embodiments other than the first embodiment.

[0087] In the support aptitude setting unit 10, the administrator 6 sets the qualities that each developer's support member should have as support aptitude.

[0088] 21 is a flowchart showing the operation of the support adequacy setting unit 10 according to the fifth embodiment. In step S111, the support adequacy setting unit 10 acquires a support adequacy value that quantifies support adequacy from the manager 6. In step S112, the support adequacy setting unit 10 stores and sets the support adequacy value acquired in step S111 in the support adequacy setting unit 10.

[0089] The learning model generation unit 2 generates an inferred value of the support performance of each developer based on the support suitability set in the support suitability setting unit 10 and the inferred value of each developer's performance when they are in charge of the main task, which was generated using the learning model described in embodiment 1.

[0090] 22 is a flowchart showing the operation of the learning model generation unit 2 according to the fifth embodiment. In step S121, the learning model generation unit 2 acquires the past performance result value 111, i.e., past deliverable information including the performance result value when the developer was in charge of the main task in past software development, from the data acquisition unit 1. In step S122, the learning model generation unit 2 acquires the support adequacy value of each developer from the support adequacy setting unit 10.

[0091] In step S123, the learning model generation unit 2 generates an inferred value of the support performance of each developer based on the past work product information acquired in step S121 and the support aptitude value acquired in step S122. For example, the learning model generation unit 2 performs machine learning on the learning model described in embodiment 1 based on the past work product information acquired in step S121, and generates an inferred value of the performance of each developer using the learning model. The inferred value of the performance of each developer generated here is an inferred value of the performance of each developer when they were the main developer. The learning model generation unit 2 generates an inferred value of the support performance of each developer based on the support aptitude and the inferred value of the performance of each developer when they were the main developer. This will be described in detail later.

[0092] In step S124, the learning model generation unit 2 stores the inferred value of the support performance generated in step S123 in the storage unit 12.

[0093] 23 is a diagram showing an example of the support aptitude set by the manager 6 for each developer. The manager 6 quantifies in advance each developer's "qualities that should be possessed by a support member," which correspond to communication skills such as attentive listening, involving other parties, and timely status reports, as a support aptitude value 251 for each developer. In the example of FIG. 23, the support aptitude value 251 is shown on a 10-point scale from 1 to 10, but the present invention is not limited to this.

[0094] The administrator 6 updates each developer's support aptitude value 252 after the completion of development, taking into consideration each developer's behavior and performance as a support member. For example, suppose that when developer A, whose support aptitude value 251 is "8," completes a development in which he participated as a support member, the administrator 6 highly evaluates developer A's qualities as a support member for that development. Furthermore, suppose that the administrator 6 evaluates that developer A's performance during support is at least a certain percentage (e.g., 90%) of developer A's performance during primary responsibility. In this case, the administrator 6 may update developer A's support aptitude value 251 from "8" to "9."

[0095] FIG. 24 is a diagram showing an example of an inferred value 261 of support performance generated by the learning model generation unit 2. When the support aptitude value 251 of developer A is "8" as shown in FIG. 24 , the learning model generation unit 2 generates (calculates) the inferred value 262 of support performance by weighting the inferred value 261 of performance when in primary responsibility by the support aptitude value 251. For example, in FIG. 24 , the inferred value 261 of the performance of requirements analysis for screen (A) when developer A is in primary responsibility is 2 pages / hour. In this case, the learning model generation unit 2 multiplies 2 pages / hour by 0.1 times the support aptitude value 251 ("8") (i.e., 0.8), to obtain 1.6 pages / hour, and generates this as the inferred value 262 of the support performance of requirements analysis for screen (A) when developer A is providing support. Note that when the support aptitude value is updated, the learning model generation unit 2 may use the updated support aptitude value to generate an inferred value of the support performance of each developer.

[0096] Summary of Embodiment 5 According to the software development support device of Embodiment 5 described above, an inferred value of support performance for each developer is generated based on the support aptitude and the inferred value of performance for each developer when they were in charge of the project, which was generated using the learning model described in Embodiment 1. With this configuration, an inferred value of support performance can be generated even for developers who have no support experience and therefore no actual support performance value. Therefore, as with Embodiment 4, it is possible to create a plan that can make up for development delays.

[0097] <Other Modifications> The data acquisition unit 1, learning model generation unit 2, and intermediate product monitoring unit 3 shown in FIG. 1 are hereinafter referred to as the "data acquisition unit 1, etc." The data acquisition unit 1, etc. are realized by a processing circuit 81 shown in FIG. 25. That is, the processing circuit 81 includes: a data acquisition unit 1 that acquires past product information of each developer in past software development; a learning model generation unit 2 that performs machine learning on a learning model for inferring each developer's performance based on the past product information and generates an inferred value of each developer's performance using the learning model; and an intermediate product monitoring unit 3 that calculates actual performance values ​​of each developer based on intermediate product information of the current software development and generates alert information based on the comparison between the actual values ​​and the inferred values. The processing circuit 81 may be implemented using dedicated hardware or a processor that executes a program stored in memory. Examples of the processor include a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a DSP (Digital Signal Processor).

[0098] When the processing circuit 81 is dedicated hardware, the processing circuit 81 may be, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination thereof. The functions of each unit such as the data acquisition unit 1 may be realized by a circuit in which the processing circuits are distributed, or the functions of each unit may be realized by a single processing circuit.

[0099] When the processing circuit 81 is a processor, the functions of the data acquisition unit 1 and the like are realized in combination with software and the like. Software and the like may include, for example, software, firmware, or software and firmware. The software and the like are written as a program and stored in memory. As shown in FIG. 26 , the processor 82 applied to the processing circuit 81 realizes the functions of each unit by reading and executing a program stored in memory 83. That is, the software development support device includes a memory 83 for storing a program that, when executed by the processing circuit 81, ultimately executes the following steps: acquiring past work product information of each developer in previous software development; performing machine learning on a learning model for inferring each developer's performance based on the past work product information and generating an inferred performance value for each developer using the learning model; calculating actual performance values ​​for each developer based on intermediate work product information of the current software development, generating alert information based on the comparison between the actual values ​​and the inferred values; and notifying an administrator of the alert information. In other words, this program can be said to cause a computer to execute the procedures and methods of the data acquisition unit 1 and the like. Here, the memory 83 may be, for example, a non-volatile or volatile semiconductor memory such as a RAM (Random Access Memory), a ROM (Read Only Memory), a flash memory, an EPROM (Erasable Programmable Read Only Memory), or an EEPROM (Electrically Erasable Programmable Read Only Memory), a HDD (Hard Disk Drive), a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, a DVD (Digital Versatile Disc), a drive device for any of these, or any storage medium to be used in the future.

[0100] The above describes a configuration in which each function of the data acquisition unit 1, etc. is realized either by hardware or software, etc. However, this is not limited to this, and a configuration in which part of the data acquisition unit 1, etc. is realized by dedicated hardware and another part is realized by software, etc. For example, the function of the data acquisition unit 1 can be realized by a processing circuit 81 as dedicated hardware, and the other functions can be realized by the processing circuit 81 as a processor 82 reading and executing a program stored in a memory 83.

[0101] As described above, the processing circuitry 81 can realize the above-described functions by hardware, software, or a combination of these.

[0102] The software development support device described above can also be applied to a software development support system constructed as a system by appropriately combining an information processing device such as a PC, the functions of an application installed in at least one of a vehicle device and a communication terminal, and a server. In this case, the functions or components of the software development support device described above may be distributed among the devices that construct the system, or may be concentrated in one of the devices.

[0103] It should be noted that the embodiments and modifications may be freely combined, and the embodiments and modifications may be modified or omitted as appropriate. The above description is illustrative in all respects and is not limiting. It is understood that countless modifications not illustrated can be envisioned.

[0104] Various aspects of the present disclosure are summarized below as appendices.

[0105] (Supplementary Note 1) A software development support device comprising: a data acquisition unit that acquires past product information of each developer in past software development; a learning model generation unit that performs machine learning on a learning model for inferring the performance of each developer based on the past product information, and generates an inferred value of the performance of each developer using the learning model; an intermediate product monitoring unit that calculates an actual performance value of each developer based on intermediate product information of a current software development, and generates alert information based on a comparison between the actual value and the inferred value; and a development status notification unit that notifies an administrator of the alert information.

[0106] (Supplementary Note 2) The software development support device according to Supplementary Note 1, further comprising a countermeasure result prediction unit that, if the actual value for one of the developers is smaller than the inferred value, presents the inferred values ​​of other developers to the administrator, and predicts progress when the other developers designated by the administrator support the one developer, and presents the predicted progress to the administrator.

[0107] (Supplementary Note 3) The software development support device according to Supplementary Note 1 or Supplementary Note 2 further comprises: a review target extraction unit that extracts review target deliverables that the manager should review as a priority based on the intermediate deliverable information, the final deliverable information of the current software development, and the alert information notified by the development status notification unit, and generates review target deliverable information that is information about the review target deliverables; and a review target display unit that displays the review target deliverable information to the manager.

[0108] (Supplementary Note 4) The software development support device according to Supplementary Note 1, wherein the learning model generation unit performs machine learning on a support learning model for inferring the support performance of each developer based on the support track record of each developer, and generates an inferred value of the support performance of each developer using the support learning model.

[0109] (Appendix 5) The software development support device according to Appendix 1, further comprising a support suitability setting unit that enables the administrator to set the support suitability of each of the developers, and the learning model generation unit generates an inferred value of the support performance of each of the developers based on the support suitability and the inferred value of the performance of each of the developers.

[0110] (Supplementary Note 6) A software development support method comprising: acquiring past product information of each developer in past software development; performing machine learning on a learning model for inferring the performance of each developer based on the past product information; generating an inferred value of each developer's performance using the learning model; calculating an actual performance value of each developer based on intermediate product information of a current software development; generating alert information based on a comparison between the actual value and the inferred value; and notifying an administrator of the alert information.

[0111] 1 Data acquisition unit, 2 Learning model generation unit, 3 Intermediate product monitoring unit, 4 Development status notification unit, 5 Developer, 6 Administrator, 7 Countermeasure result prediction unit, 8 Review target extraction unit, 9 Review target display unit, 10 Support suitability setting unit, 121 Inference value, 411 Alert information.

Claims

1. A software development support device comprising: a data acquisition unit that acquires past product information of each developer in past software development; a learning model generation unit that performs machine learning on a learning model for inferring the performance of each developer based on the past product information, and generates an inferred value of each developer's performance using the learning model; an intermediate product monitoring unit that calculates actual performance values ​​of each developer based on intermediate product information of a current software development, and generates alert information based on a comparison result between the actual values ​​and the inferred values; and a development status notification unit that notifies an administrator of the alert information.

2. A software development support device as described in claim 1, further comprising a countermeasure result prediction unit that, if the actual value for one of the developers is smaller than the inferred value, presents the inferred values ​​of the other developers to the administrator, and predicts progress when the other developers designated by the administrator support the one developer, and presents the predicted progress to the administrator.

3. A software development support device as described in claim 1 or claim 2, further comprising: a review target extraction unit that extracts review target deliverables that should be reviewed as a priority by the manager based on the intermediate deliverable information, the final deliverable information of the current software development, and the alert information notified by the development status notification unit, and generates review target deliverable information that is information about the review target deliverables; and a review target display unit that displays the review target deliverable information to the manager.

4. A software development support device as described in claim 1, wherein the learning model generation unit performs machine learning on a support learning model for inferring the support performance of each developer based on the support track record of each developer, and generates an inferred value of the support performance of each developer using the support learning model.

5. A software development support device as described in claim 1, further comprising a support aptitude setting unit in which the administrator sets the support aptitude of each of the developers, and the learning model generation unit generates an inferred value of the support performance of each of the developers based on the support aptitude and the inferred value of the performance of each of the developers.

6. A software development support method comprising: acquiring past work product information of each developer in past software development; performing machine learning on a learning model for inferring the performance of each developer based on the past work product information; generating an inferred value of each developer's performance using the learning model; calculating an actual performance value of each developer based on intermediate work product information of a current software development; generating alert information based on a comparison result between the actual value and the inferred value; and notifying an administrator of the alert information.

Images