JP2018018267A - Software development support apparatus, software development support method, and program - Google Patents

Abstract

A software development support device for detecting occurrence of a defect in software development is provided. A software development support apparatus determines whether a commit is an update that corrects a bug mixed in another commit made before the commit, and information on the source code changed in the commit And a bug correction commit detection unit that detects a commit that is a bug correction, and the other that contains a bug corrected in the commit when the commit is detected as an update that corrects the bug. A bug-incorporating revision detecting unit for detecting the revision of the other commit, and a database for storing information for identifying the revision of the other commit in which the bug is incorporated. [Selection] Figure 2

Description

  The present invention relates to a software development support apparatus, a software development support method, and a program.

  There are various causes for the occurrence of defects in software development. For example, even if the same source code is edited, a difference occurs in the defect occurrence rate according to the developer's technology. Even if the same developer performs programming, the problem occurrence rate varies depending on the difficulty level of the development contents, the day of the week on which the programming is performed, and the time zone.

  In order to detect these problems, various methods using machine learning have been developed. If there is regularity in the occurrence of a defect, it is possible to improve the accuracy and speed of detection of the defect. As an example, as described in Non-Patent Document 1, a method using various parameters and machine learning algorithms has been developed to detect these defects.

JP2016-24784

T. Hall, “A systematic Literature Review on Fault Prediction Performance in Software Engineering,” IEEE Trans. On Software Engineering, Nov. 2012, Volume 38, Issue 6, page 1276.

  The problem to be solved by the present invention is to realize a software development support apparatus that detects occurrence of defects in software development.

A software development support apparatus according to an embodiment
It is a bug fix by determining whether a commit is an update that fixes a bug introduced in another commit made before that commit based on the information of the source code changed in the commit. A bug fix commit detector to detect commits;
A bug-incorporated revision detection unit that detects a revision of the other commit in which a bug fixed in the commit is mixed when the commit is detected as an update that fixes a bug;
A database that stores information identifying revisions of the other commits that contain bugs;
Is provided.

A software development support method according to an embodiment is:
The bug correction commit detection unit determines whether or not the commit is an update that fixes a bug mixed in another commit made before that commit based on the information of the source code changed in that commit. And detecting a commit that is a bug fix,
When the bug-mixed revision detection unit detects that the commit is an update that corrects a bug, a step of detecting a revision of the other commit mixed with the bug corrected in the commit;
Storing in the database information identifying the revision of the other commit that contains the bug;
Is provided.

A program according to an embodiment is:
On the computer,
It is a bug fix by determining whether a commit is an update that fixes a bug introduced in another commit made before that commit based on the information of the source code changed in the commit. Bug fix commit detection means to detect commits,
A bug-incorporating revision detection means for detecting a revision of the other commit in which the bug fixed in the commit is mixed when the commit is detected as an update that fixes the bug;
Storage means for storing information for identifying revisions of the other commits including bugs;
To function as.

  According to the present invention, it is possible to improve the accuracy and speed of defect detection by extracting the regularity of defect occurrence in software development by machine learning.

The figure which shows the usage condition of the software development assistance apparatus which concerns on one Embodiment. The block diagram which shows the outline of the software development assistance apparatus which concerns on one Embodiment. The flowchart which shows the operation | movement at the time of the source code commit which concerns on one Embodiment. 10 is a flowchart showing an operation of bug correction commit determination according to an embodiment. The figure which shows an example of the judgment criteria which judges whether a commit is a bug correction. The flowchart which shows the learning operation | movement of the bug mixing parameter which concerns on one Embodiment. The figure which shows another example of the usage type of the software development assistance apparatus which concerns on one Embodiment.

  Embodiments of the present invention will be described below with reference to the drawings. This embodiment does not limit the present invention.

  FIG. 1 is a diagram showing a state of software development using the server according to the present embodiment. As shown in FIG. 1, the software development support apparatus 1 and the client 2 are connected via a wired or wireless network, and the software developer includes a file containing source code created or modified using the client 2. Is transmitted to the software development support apparatus 1 via the network. Hereinafter, the file transmission operation from the client 2 to the software development support apparatus 1 is referred to as commit.

  The source code described in the committed file is stored in the software development support apparatus 1, and a change history or the like can be referred from the client 2 via the network. By using this software development support apparatus 1, even when a plurality of developers modify the source code in the same file, the file and the source code can be shared among the developers.

  FIG. 2 is a block diagram showing the configuration of the software development support apparatus 1. As shown in FIG. 2, the software development support apparatus 1 includes a version management unit 10 and a bug information learning unit 20. The software development support apparatus 1 is configured by a bug management system such as Trac, Redmine, Bugzilla, or a project management system.

  The version management unit 10 is configured by a distributed or centralized version management system such as git, Mercurial, Subversion, CVS (Concurrent Versions System), BitKeeper, and AlienBrain. The version management unit 10 includes a source code input unit 100, a source code database 102, a change history database 104, a repository information output unit 106, a changed part detection unit 108, and a changed line count unit 110. Configured. In addition, a basic configuration of a so-called version management system such as a merge unit for merging source codes may be provided.

  When the file is committed from the client 2 in FIG. 1, the source code input unit 100 receives the file and records the source code described in the file in the source code database 102.

  The source code database 102 is a database for recording and holding the source code described in the committed file. In the present embodiment, the source code database 102 records the source code for each file, but may record the source code for each module or function.

  The change history database 104 is a database for recording a difference between source codes as a change history when the committed file is a file related to the source code already recorded in the source code database 102. Each database such as the source code database 102 and the change history database 104 is configured by a recording medium such as a solid state drive (SSD) or a hard disk drive (HDD).

  In addition to these, there may be a database for binary files (not shown), or the binary file may be recorded in the source code database 102. The file recorded in the source code database 102 is not limited to the file describing the source code, but is a file related to license information, a document describing how to use the source code, or a note. It may be a written text file, or it is not limited to these, and a necessary file may be recorded. Furthermore, instead of inputting the file itself, these attributes may be recorded when a file whose file attributes have been changed is committed. Hereinafter, these databases are collectively referred to as a repository, and an identifier for identifying each commit, for example, an identification number assigned sequentially is referred to as a revision.

  In the above description, the committed file is recorded in the source code database 102. However, the present invention is not limited to this. For example, in each file, the first committed information is recorded, When outputting a file, the current file may be reconstructed and output by scanning the change history of the file recorded in the change history database 104 in order from the past to the present. On the other hand, the change history database 104 records an identifier such as the revision number of each file, and compares the revision files in the source code database 102 when outputting the change history. May be output.

  The repository information output unit 106 is an output unit that outputs information in the repository to the client 2 in response to a command from the client 2. This output may be output by transferring a file to the client 2 or may be displayed on a monitor connected to the client 2 via a browser. The information to be output is a file recorded in a database such as the source code database 102 or a change history recorded in the change history database 104. Alternatively, the source code change history recorded in the change history database 104 may be converted into a format suitable for display and output.

  When the committed file is a file that has already been recorded in the source code database 102, the change location detection unit 108 includes a file that has been updated by the commit, a file that has been recorded in the existing source code database 102, It is a detection part which detects a change location by extracting the difference of these.

  The changed line number counting unit 110 is a counting unit that counts the number of deleted lines and the number of added lines in the committed file by scanning the changed parts detected by the changed part detecting unit 108.

  In the present embodiment, the source code input unit 100, the repository information output unit 106, the changed part detecting unit 108, and the changed line number counting unit 110 are a CPU (Central Processing Unit) provided in the software development support apparatus 1. ) Is realized by executing a predetermined program while using various I / O interfaces as necessary.

  The bug information learning unit 20 is a learning unit that performs machine learning of a revision in which a bug is corrected and a revision in which a bug corrected in a revision that is considered to be a bug correction is mixed. The bug information learning unit 20 includes a learning database 200, a bug mixing probability output unit 202, a bug correction commit detection unit 204, a bug mixing revision detection unit 206, and a bug mixing probability calculation unit 208. The

  The learning database 200 is a database that stores parameters for machine learning for detecting a revision in which a bug is mixed, and learning data and a learning model established for calculating a bug mixing probability. Based on the parameters and learning data stored in the learning database 200, the bug information learning unit 20 performs machine learning on the revision in which the bug is mixed, the development environment in the revision, and the bug mixing when the file is committed. Probability is calculated. Further, a revision in which a bug is corrected may be detected by machine learning. In this case, the learning database 200 may store learning data related to bug correction.

  When the file is committed, the bug mixing probability output unit 202 outputs the bug mixing probability in the commit to the client 2. As another example, when a file is going to be committed, a bug mixing probability may be displayed to the developer via the client 2 before the file is committed.

  When the file is committed, the bug correction commit detection unit 204 determines whether the commit is a commit related to the bug correction. By detecting a commit in which this bug has been corrected, it is used as a reference for detecting at which revision the bug corrected in the commit is mixed.

  The bug mixed revision detection unit 206 detects a revision in which a bug is mixed. The revision in which the bug is mixed detects the revision in which the bug corrected in the bug correction detected by the bug correction commit detection unit 204 is mixed.

  The bug mixing probability calculation unit 208 performs machine learning based on the situation at the time of committing the file in the bug mixing revision detected by the bug mixing revision detection unit 206. Calculate the probability of bugs being mixed. The bug mixing probability obtained by the bug mixing probability calculation unit 208 is output to the client 2 via the bug mixing probability output unit 202. The above configuration may be connected by, for example, PCIe (Peripheral Component Interconnect Express), SATA (Serial Advanced Technology Attachment), or the like.

  Note that the learning database 200 is configured by a recording medium such as an SSD or HDD in the same manner as the source code database 102 and the change history database 104 described above. The bug mixing probability output unit 202, the bug correction commit detection unit 204, the bug mixing revision detection unit 206, and the bug mixing probability calculation unit 208 are the source code input unit 100, the repository information output unit 106, and the change location detection unit described above. 108 and the changed row number counting unit 110, a CPU (Central Processing Unit) provided in the software development support apparatus 1 uses a variety of I / O interfaces as necessary, and executes predetermined programs. It is realized by executing.

  Next, the operation of the software development support apparatus 1 in this embodiment will be described. FIG. 3 is a flowchart showing the flow of processing of the software development support apparatus 1.

  First, the developer commits the file including the source code via the client 2. The source code described in the committed file is input to the software development support apparatus 1 via the source code input unit 100 (step S100). The source code input from the source code input unit 100 is registered in the source code database 102 (step S102).

  Next, the change location detection unit 108 compares the file in which the input source code is described with the source code of the same file already stored in the source code database 102 by the previous commit. Detection is performed (step S104). This change is made by automatically executing a diff command when a file is committed, for example.

  Next, the changed line number counting unit 110 counts the number of added lines and deleted lines of the file in the commit from the change information detected by the changed part detecting unit 108 (step S106). It should be noted that these changed portion detection unit 108 and changed row number counting unit 110 may have a single configuration, and may detect the changed portion and calculate the number of changed rows. Information on the detected change location and the number of changed lines is registered in the change history database 104 (step S108). The order of step S102 described above is not limited to this order, and the source code may be registered after the operation of step S104 or step S106.

  Next, it is determined whether or not it is a bug correction (step S110). The determination of whether or not the bug is corrected will be described with reference to FIGS. FIG. 4 is a flowchart showing details of the operation in step S110 for determining whether or not the bug is corrected. FIG. 5 is a graph showing the relationship between the number of added lines and the number of deleted lines of a file in a certain commit. In FIG. 5, a half line L1 is a line indicating a case where the number of deleted lines is equal to the number of added lines.

  First, the bug correction commit detection unit 204 compares the number of added lines and the number of deleted lines of a file in a certain commit counted by the changed line number counting unit 110 (step S200). If the number of changed lines of the file in the commit is smaller than the predetermined number of lines, there is a high possibility that the bug is not corrected. Therefore, it is determined whether or not the number of rows deleted or added in the commit is equal to or greater than a predetermined number (step S202). That is, in FIG. 5, it is determined whether the commit satisfies a relationship included in the region R4 or a relationship included in a region other than the region R4.

  Here, the predetermined number of rows is, for example, 8 rows, and more preferably 10 rows. Although the number of lines may be determined in advance, for example, by accumulating information that can be understood as bug correction by a commit message and registering it in the learning database 200, the situation at the time of commit by machine learning and the file that has been committed The predetermined number of lines may be changed based on the content of the commit by monitoring the state and the like and performing supervised learning.

  When the number of deleted / added lines is equal to or greater than the predetermined number (step S202: Yes), it is determined whether the ratio of the number of deleted / added lines is within a predetermined range (step S204). That is, in FIG. 5, it is determined whether the commit satisfies a relationship included in the region R1 or a relationship included in a region other than the region R1. This is because if the number of deleted lines and the number of added lines are not so different, the probability that the commit is a bug correction is high.

  For example, empirically and experimentally, if 0.8 (corresponds to half line L3) ≤ (number of added lines / deleted lines) ≤ 1.25 (corresponds to half line L2), bug fixes Is likely. This ratio is, for example, a ratio when 50 lines of source code are deleted and 40 lines are added, or when 40 lines of source code are deleted and 50 lines are added. This ratio may be a predetermined value as described above, or may be changed based on the content of the commit by supervised learning.

  In this embodiment, the bug correction is detected by simply comparing the number of deleted / added lines. However, the present invention is not limited to this, and the number of deleted / added characters, deleted / added, etc. The amount of information such as the number of bytes may be compared. In other words, the information amount of the deleted part and the information amount of the added part may be defined based on at least one of the number of lines, the number of characters, and the number of bytes. Also, out of the number of deleted and added lines, omitting lines that do not substantially have information as a program, such as comment lines and blank lines, the information amount of the deleted part and the information amount of the added part May be compared. Furthermore, information related to program execution, such as the number of instructions included in the deleted or added information, the number of steps, or a value obtained by roughly estimating the information may be compared. As described above, any information may be compared as long as the comparison is based on significant information that can be determined as bug correction, between the information amount of the deleted portion and the information amount of the added portion.

  As shown in FIG. 5, when the number of deleted rows is sufficiently larger than a predetermined value, that is, when the relationship included in the region R2 sandwiched between the curve L4 and the y-axis is satisfied. It may be determined that the commit is a function deletion and this situation is learned. Conversely, if the number of additional rows is sufficiently small compared to a predetermined value, that is, if the relationship included in the region R3 sandwiched between the curve L5 and the x-axis is satisfied, the commit adds a function. This situation may be learned by determining that it has been performed. By learning in this way, it is possible to improve the accuracy of the determination of the commit after the bug correction.

  When the ratio of the number of deleted and added lines is within the predetermined range (step S204: Yes), the bug correction commit detection unit 204 determines that the commit is a commit in which the bug has been corrected (step S206).

  On the other hand, when the number of deleted and added lines is not greater than or equal to the predetermined number (step S202: No), and when the ratio of the number of deleted and added lines is not within the predetermined range (step S204: No). Then, it is determined that the commit is not a bug correction (step S208).

  Next, when data to be learned is generated in the processing from step S200 to step S208, the learning data is registered as learning information in the learning database 200 (step S210). For example, if the commit message indicates that the bug is corrected, information about the content and status of the bug correction such as deletion, number of added lines, file name, corrected module name, and the like are stored in the learning database 200. It is possible to improve the accuracy of determining that the commit is a bug-fixed commit when a commit is made.

  Returning to FIG. 3, after determining whether or not the commit is a commit related to bug correction, the process proceeds to learning of bug inclusion parameters (step S <b> 112). FIG. 6 is a flowchart showing an outline of the process of learning the bug inclusion parameter.

  First, if it is determined in step S110 that the commit is a bug correction (step S300: Yes), the bug-incorporated revision detection unit 206 detects a revision in which a bug is incorporated (step S302). The revision in which the bug is mixed is detected as a bug-mixed revision by, for example, extracting the revision in which the bug was corrected in the commit from the source code database 102 and the change history database 104. . This is not limited to this, and the scope may be narrower than the file, and the bug-corrected revision may be detected by comparing the bug-corrected module or function unit. You may make it detect the revision which added and corrected the part where the line which was made is included.

  Next, a parameter indicating the status of committing the bug-mixed revision is acquired (step S304). Here, the parameters are, for example, information on the developer who made the commit, information on the date of commit, date of the week, time, etc., information on the number of rows deleted and added in the commit, file name, It is a parameter that serves as an index to represent the information when committing, such as information about the contents of the source code and what has been committed. By combining these parameters, information that a bug exists in a file committed by a developer at 3:00 pm, or information that a bug was mixed in a commit related to a specific function in a file. Can be obtained.

  The information used as these parameters may be acquired based on information stored in the source code database 102, or may be acquired based on information stored in the change history database 104. Good. Furthermore, the information used as parameters is not limited to information obtained from the version management system. For example, the developer's blood pressure, pulse rate, heart rate, body temperature, vitality information such as the amount of activity such as calories burned on the day and the number of steps walked, etc. Information obtained from a special input device such as external environment information indicating information around the developer at the time of committing, such as humidity, atmospheric pressure, and location may be acquired as a parameter.

  For example, wrist signs of blood pressure, pulse rate, body temperature, vital signs such as activity meters and heart rate meters may be used to acquire vital signs, or infrared that measures body temperature via images A vital sign may be obtained by something that the developer does not directly equip, such as a camera. It is also possible to acquire developer's breathing and other information through a headset, etc., or estimate the health status from the developer's face image obtained through the camera equipped with the development machine. . Furthermore, it is good also as what acquires a health condition automatically with devices, such as a smart phone, and a developer may input the physical condition of the day into those devices beforehand.

  The same applies to external information, and it may be measured by a thermometer, a hygrometer, a barometer, or may be acquired by accessing a weather information database on the Internet. The location is acquired based on information such as the location of the committed development machine and the location where the wireless LAN is used, but is not limited to these methods. In addition, the time is not limited to the time at the commit timing, and the commit file may be acquired based on the time when the file was finally updated before committing or the time stamp stored in the file. Furthermore, the time between the previous commit and the current commit may be acquired. All of these pieces of information may be acquired by wire or wirelessly.

  In either case, the information obtained from these input devices may be recorded as a parameter at the time of committing, or the information obtained from these input devices may be recorded in one of the databases. The information may be acquired based on various information such as time, environment, committing developer, and the like.

  FIG. 7 is a schematic diagram illustrating an example in which the above-described apparatus for acquiring vital information and external environment information and an external database are provided outside the software development support apparatus 1. As shown in FIG. 7, a vital information acquisition sensor 3, an external environment information acquisition sensor 4, and an environment database 5 are further provided outside the software development support apparatus 1.

  The vital information acquisition sensor 3 is, for example, a device such as the wristband type device described above, various cameras, a headset, or a smart phone.

  The external environment acquisition sensor 4 is, for example, the above-described thermometer, hygrometer, barometer, or weather information database on the Internet.

  The environment database 5 is a database that stores and stores these vital information and external environment information. In FIG. 7, the environment database 5 is assumed to be outside the software development support apparatus 1, but the form is not limited to this. For example, the software development support apparatus 1 such as the change history database 104, the learning database 200, etc. Such information may be recorded in an internal database, or a separate database may be provided in the software development support apparatus 1.

  After the parameters of the bug mixture revision are acquired, the bug mixture parameters are registered in the learning database (step S306). By registering each parameter in the learning database, the amount of samples in machine learning is increased, and the accuracy of machine learning is further improved.

  Next, based on the various parameters registered in the learning database and previous learning data, the bug inclusion probability calculation unit 208 performs machine learning such as the tendency of the parameters in the bug inclusion revision. Subsequently, the learning data that associates the various parameters calculated by machine learning with the bug inclusion probability is updated as a new machine learning parameter (step S308). Further, a learning model estimated by machine learning may be registered in the learning database 200.

  Whether or not each revision is a bug-mixed revision is added as teacher data to the above-described bug-mix parameters and machine-supervised data is created. In some cases, this supervised data may be handled in multiple values instead of binary values, such as no bugs, low bugs, and high bugs. Generally, a random forest or a support vector machine is adopted as the machine learning algorithm, but another algorithm including deep learning may be used.

  A machine learning model is created using the supervised data created as described above as an input. Hyperparameters for creating a model are determined by a search such as grid search, random sampling, and Bayesian optimization, and the variable parameter may include a ratio for determining a bug mixing probability. Here, the hyper parameter refers to a parameter that determines a prior model and a parameter that affects the entire probability model.

  The hyperparameters used for grid search etc. differ depending on the algorithm used, the number of decision trees, the depth, the number of samples, etc. for a random forest, the gamma value, the cost, etc. for a support vector machine, deep learning If so, the selection of the activation function, the number of units, the number of intermediate layers, the initial weight, and the like correspond thereto. The bug mixing parameter at the time of commit is given as an input to the learning model created here, and the bug mixing probability is output as a result.

  When a random forest is adopted, first, a predetermined number of sets are randomly subsampled as data of various parameters and whether or not a bug has occurred. For example, a certain developer randomly acquires data indicating that a commit made within a certain time on a certain day of the week was a bug or not, and a predetermined number, generally 2 of the total number of samples. / 3 Sub-sampling data is created. Thereafter, a decision tree for each sub-sampling data is generated using each sub-sampling data as teacher data. For these generated trees, as an example, learning data is created using the developer and time as parameters. By adjusting the number of nodes in the final tree, it is possible to refine the binary or multilevel classification. By determining the structure of the learning data using various parameters, the correlation between the trees is lowered. By using the learning model obtained based on the learning data in this way, the bug inclusion probability is output by performing weighting and function selection for each parameter.

  When a support vector machine is used, various parameters and whether or not a bug has occurred are used as teacher data, and classification within a space with the number of parameters is possible. The hyperplane that maximizes the margin from the point is calculated. As described above, as the hyper parameter, the cost C indicating the weighting for the error, the gamma γ for determining the ratio between the maximization of the margin and the minimization of the error, and the like are used. Similar to the random forest described above, binary classification or multi-level classification is also possible, and a learning model that outputs a bug mixing probability is estimated based on the parameters thus obtained.

  Even when deep learning is employed, learning data is generated by using various parameters and data indicating whether or not a bug has occurred as teacher data. Deep learning is generally configured by a neural network having a plurality of layers as intermediate layers. There are various configuration methods, for example, there are algorithms such as a convolutional neural network, a recurrent neural network, self-coding, and a deep Boltzmann machine, and learning may be performed by combining a plurality of these algorithms. Depending on the algorithm used, the configuration of the hyperparameters varies, but as described above, the selection of the activation function for firing the synapse that connects the neurons constituting each layer, the number of units in the intermediate layer, the number of intermediate layers, An initial weighting function or the like becomes a hyperparameter. Based on these hyperparameters, a learning model that outputs a bug mixing probability is estimated by performing binary classification or multi-level classification.

  Further, the present invention is not limited to the algorithm described above, and any algorithm may be used as long as it is a machine learning model that can perform supervised learning appropriately.

  Next, the commit parameter is registered in the learning database 200 (step S310). The data to be registered here is a parameter equivalent to the parameter acquired in step S304. That is, data such as developer and time information in the commit is registered in the learning database 200. In this way, when a bug is mixed in the commit, it is possible to detect the commit as a commit mixed with a bug in a bug correction commit made in the future. In the case where it is not detected that the commit includes bugs, the parameters are not stored in the learning database 200 as parameters not including bugs.

  On the other hand, if the commit is not determined to be bug correction in step S300 (step S300: No), the commit parameters are similarly registered in the learning database 200 (step S310). This is also for the same reason as described above, in order to register the state and environment of the commit as learning data regardless of whether or not it is a bug correction commit.

  When the bug mixing parameter learning is completed, the process returns to FIG. 3 again to calculate and output the bug mixing probability of the input source code (step 114). The bug mixing probability calculation unit 208 calculates the probability that a bug has been mixed in the commit based on the learned bug mixing parameter. For example, if a developer commits at around 3 o'clock, information that the bug mixing probability is 30%, or if a commit is made to change a specific part of a file, the bug mixing probability is 50%. , And the like are calculated. The calculated information is output to the client 2 via the bug inclusion probability output unit 202.

  The above processes are all processed after the commit is performed. For example, before transmitting the file to be committed to the software development support apparatus 1 that is a server, information on the commit schedule is displayed. It is also possible to display the probability that a bug is included in the planned commit before committing by calculating the bug inclusion probability by using it.

  In the above description, learning is performed for each commit. However, the learning is not limited to this, and may be performed at a constant cycle by batch processing or the like. For example, learning may be performed when a predetermined number of commits have been made, or learning may be performed at a fixed time such as midnight, and the learning is not limited to these, and may be performed at an appropriate timing. It may be.

  As described above, according to the present embodiment, it is possible to display the probability of occurrence of a failure to a developer at the time of committing or before committing. For example, if it is displayed that the probability of occurrence of a bug is high before committing, it is possible to avoid mixing bugs by testing in advance, and to improve the reliability of bug fixes even after committing It becomes.

  By using the developer as a parameter, it is possible to prevent the bug from being mixed in advance by making the developer aware of the situation where the developer tends to mix the bug. Furthermore, if the probability of occurrence of a bug in a specific file is high, the content of the file is advanced, and a warning is displayed indicating that there is a high probability that a bug will be mixed. It is also possible to avoid bugs by fixing bugs. In this way, by performing machine learning using the environment and situation at the time of commit as a parameter, it is possible to improve the accuracy and speed of bug correction and to reduce the number of bugs in the first place.

  In the above-described embodiment, each function may be configured by hardware such as a circuit having the above-described function, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), It may be configured by software using a program.

  The present invention is not limited to the above-described embodiment, and various modifications including an equivalent range are possible. The present invention is also applied to an embodiment in which these modifications are made and a combination of the above-described embodiments. It is included in the range.

1: software development support device, 2: client, 3: vital information acquisition sensor, 4: external environment acquisition sensor, 5: environment database, 10: version management unit, 100: source code input unit, 102: source code database, 104 : Change history database, 106: repository information output unit, 108: change location detection unit, 110: change line count unit, 20: bug information learning unit, 200: learning database, 202: bug inclusion probability output unit, 204: bug Correction commit detection unit 206: Bug-mixed revision detection unit 208: Bug-mixing probability calculation unit

Claims (11)

It is a bug fix by determining whether a commit is an update that fixes a bug introduced in another commit made before that commit based on the information of the source code changed in the commit. A bug fix commit detector to detect commits;
A bug-incorporated revision detection unit that detects a revision of the other commit in which a bug fixed in the commit is mixed when the commit is detected as an update that fixes a bug;
A database that stores information identifying revisions of the other commits that contain bugs;
Software development support device comprising:   Whether the commit is a commit related to the bug correction by comparing the deleted part with the added part in the source code described in the file updated in the commit, The software development support apparatus according to claim 1, which determines whether or not.   When the difference between the information amount of the deleted part and the information amount of the added part is within a predetermined range, the bug correction commit detection unit is determined to be a commit related to bug correction. The software development support apparatus according to claim 2, which makes a determination.   The information amount of the deleted part and the information amount of the added part are defined based on at least one of the number of lines, the number of characters, the number of bytes, the number of instructions, and the number of steps. The software development support apparatus described. A bug mixing probability calculation unit that calculates a bug mixing probability that is a probability that a new bug is mixed in a file updated in the commit based on a situation in which the commit is performed;
A bug mixing probability output unit for outputting the calculated bug mixing probability;
The software development support apparatus according to claim 1, further comprising: The database stores the state of each commit as a parameter,
The bug mixture probability calculation unit calculates a learning model by performing machine learning using a parameter indicating a commit state stored in the database, and based on the learning model, the bug mixture probability in the commit The software development support apparatus according to claim 3, which calculates   The software development support apparatus according to claim 6, wherein the parameter includes at least information on a developer who has made the commit and information on a time at which the commit has been made.   In addition to the parameter indicating the commit status stored in the database, the bug mixture probability calculation unit has made a commit stored in an environment database provided inside or outside the software development support apparatus. The software development support apparatus according to claim 6 or 7, wherein the learning model is calculated also using a parameter indicating a situation.   The parameter indicating the committed state stored in the environment database includes at least vital information that is information indicating a developer's health state or external environment information that is information indicating a surrounding environment of the developer. Item 9. The software development support device according to Item 8. The bug correction commit detection unit determines whether or not the commit is an update that fixes a bug mixed in another commit made before that commit based on the information of the source code changed in that commit. And detecting a commit that is a bug fix,
When the bug-mixed revision detection unit detects that the commit is an update that corrects a bug, a step of detecting a revision of the other commit mixed with the bug corrected in the commit;
Storing in the database information identifying the revision of the other commit that contains the bug;
Software development support method comprising: On the computer,
It is a bug fix by determining whether a commit is an update that fixes a bug introduced in another commit made before that commit based on the information of the source code changed in the commit. Bug fix commit detection means to detect commits,
A bug-incorporating revision detection means for detecting a revision of the other commit in which the bug fixed in the commit is mixed when the commit is detected as an update that fixes the bug;
Storage means for storing information for identifying revisions of the other commits including bugs;
Program to function as.

Images