JP2018036792A - Data processing program and data processing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to avoid that a reason for update of a source code becomes unknown.SOLUTION: With reference to a set of first data which is issued every reason for update of a software source code and includes identification information of the reason for update, a period of occurrence of the reason for update, and a task completion period in accordance with the reason for update, a set of second data which is recorded every update of the source code and includes the period of update, and regarding a part of the second data, a set where identification information of a reason for update corresponding to the update related to the second data is inputted by a user, reasons that the identification information is not inputted to the second data are classified into one of a plurality of patterns on the basis of a relation between the period of occurrence and the completion period included in the first data that includes the identification information inputted with respect to a part of the second data on the one hand and a period of update included in the second data where identification information is not inputted.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a data processing program and a data processing method.

  With the spread of business on the Internet and the spread of mobile networks, various things are realized by software, and the importance of development quality of software used for commercial use is increasing. In addition, since the investment effect of software is required in a short period, the development period of system development is also shortened.

  In short-term software development represented by agile development and lean development, when a new task (functional implementation or bug repair) occurs, a ticket corresponding to each task of the developer is drafted (draft Is performed by the software development manager (eg Scrum Master) or the developer himself).

  When a ticket is issued, a developer responsible for a task corresponding to the ticket is assigned. The assigned developer updates (creates / changes / deletes) the source code based on the contents of the task.

  In such software development projects, in general, an issue management system (ITS (Issue Tracking System)) that manages ticket status and a version management system (VMS (Version Management System)) that manages source code version management. These two are used.

  The developer updates (newly creates / changes / deletes) the source code based on the contents of the ticket (corresponding task) issued by the ITS, and commits the source code being updated to the VMS. When the task corresponding to the ticket is completed (source code update is completed), confirmation work predetermined in the project (for example, implementation of regression test, confirmation of administrator behavior) is performed. Then, the developer commits the updated source code to the VMS. In addition, in ITS, the status of the ticket corresponding to the task is recorded as completed.

"Software production technology revolution in the age of great competition", [online], the Internet <http://itpro.nikkeibp.co.jp/article/COLUMN/20130601/481262/?rt=nocnt>

  However, in actual software development, only the developer's implementation work (update of source code and commit to VMS) proceeds ahead, and tickets corresponding to those tasks have not been drafted or drafted. Even if it is done, there are many cases where the ticket does not reflect the contents of the latest source code. As a result, after development (for example, iteration), the development may end without reflecting the contents of the latest source code in the contents of the ticket and the related development document (for example, requirement definition document).

  In this way, if a ticket (and development document related to it) is missed and remains, any problem will occur in the software, and the status of reflection of bug fixes during development in the source code When trying to confirm, etc., it becomes impossible to confirm whether or not each update to the source code was due to a bug fix. In addition, even when a new member participates in the next development (iteration), it is not possible to grasp the entire contents of the software implementation function or the ground information (Relational) why the function is implemented.

  The present invention has been made in view of the above points, and an object of the present invention is to avoid the reason why the source code has been updated.

  Therefore, in order to solve the above problems, a data processing program is issued for each reason for updating the source code of software, and the identification information of the reason for updating, the timing of occurrence of the reason for updating, A first data set including a completion time and a second data set recorded for each update of the source code and including the time of the update, and a part of the second data, And a set in which identification information of an update reason corresponding to an update related to the second data is input by a user, including the identification information input with respect to the partial second data Based on the relationship between the occurrence time and completion time included in the first data and the update time included in the second data for which the identification information is not input, the second data The identification information causes the computer to function as a classification unit for classifying the one of the plurality of patterns why not input Te.

  It is possible to avoid the reason why the source code has been updated.

It is a figure which shows the hardware structural example of the data processor in embodiment of this invention. It is a figure which shows the function structural example of the data processor in embodiment of this invention. It is a flowchart for demonstrating an example of the process sequence which a data processor performs. It is a figure which shows an example of ticket data. It is a figure which shows an example of a commit log. It is a figure which shows an example of TCNC. It is a figure which shows the example of output of the notification information according to a classification result. It is a figure which shows the example of output of the recommendation information of the correction candidate according to a classification result.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a hardware configuration example of a data processing device according to an embodiment of the present invention. The data processing device 10 in FIG. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, an input device 107, and the like that are mutually connected by a bus B.

  A program for realizing processing in the data processing apparatus 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not be installed from the recording medium 101 and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 realizes functions related to the data processing device 10 according to a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a GUI (Graphical User Interface) or the like by a program. The input device 107 includes a keyboard and a mouse, and is used for inputting various operation instructions.

  FIG. 2 is a diagram illustrating a functional configuration example of the data processing device according to the embodiment of the present invention. In FIG. 2, the data processing apparatus 10 includes a VMS 11, an ITS 12, a TCNC generation unit 13, a cause classification unit 14, a correction candidate output unit 15, and the like. These are realized by processing that one or more programs installed in the data processing apparatus 10 cause the CPU 104 to execute.

  The VMS 11 is a version management system (Version Management System) that performs version management of source codes of software (mainly programs). A general (commercially available) version control system may be used as the VMS 11.

  2, the VMS 11 includes a commit log generation unit 111, a commit log storage unit 112, and the like. When a commit instruction such as newly created source code or existing source code is input to the VMS 11, the commit log generation unit 111 generates a commit log related to the source code, and the commit log is stored in the commit log storage unit. 112. Commit means that the version (version) of the source code is incremented by one and registered in the VMS 11. That is, the commit is executed every time the source code is updated. Therefore, the commit log is recorded every time the source code is updated.

  The ITS 12 is an issue management system (Issue Tracking System) that manages ticket data to which tasks (work) of software developers are assigned. A general (commercially available) problem management system may be used as the ITS 12. Ticket data is drafted according to the occurrence of the reason for updating the software source code (that is, according to the occurrence of a task corresponding to the reason for the update (source code update work such as function implementation or bug repair)). Data.

  In FIG. 2, the ITS 12 includes a ticket status update unit 121, a ticket data storage unit 122, and the like. The ticket status update unit 121 updates the status of ticket data stored in the ticket data storage unit 122. Specifically, the ticket status update unit 121 generates ticket data in accordance with the ticket data drafting instruction input by the user, and records the ticket data in the ticket data storage unit 122. At this time, the draft time (that is, update reason and task occurrence time) is recorded in the ticket data. Therefore, the ticket data is recorded for each source code update reason (for each task corresponding to the update reason). Further, when the task completion notification corresponding to the update reason is input by the user, the ticket status update unit 121 records the completion time for the ticket data corresponding to the task.

  For example, when a source code update reason occurs, ticket data is issued to start a task corresponding to the update reason. The developer updates the source code based on the contents of the ticket data, and commits the updated source code to the VMS 11. As a result, a commit log corresponding to the update is recorded in the commit log storage unit 112.

  The commit log storage unit 112 and the ticket data storage unit 122 can be realized by using, for example, a storage device that can be connected to the auxiliary storage device 102 or the data processing device 10 via a network.

  The functions of the TCNC generation unit 13, the cause classification unit 14, and the correction candidate output unit 15 will be clarified in the description of the processing procedure.

  Note that the VMS 11 and the ITS 12 may each be realized using a computer different from the data processing apparatus 10.

  FIG. 3 is a flowchart for explaining an example of a processing procedure executed by the data processing apparatus. The processing procedure in FIG. 3 is started, for example, when a process execution instruction is input by the user.

  In step S <b> 101, the TCNC generation unit 13 acquires a set of ticket data from the ticket data storage unit 122.

  FIG. 4 is a diagram illustrating an example of ticket data. In FIG. 4, one row corresponds to one ticket data. Each ticket data includes a ticket ID, a draft time, a completion time, and the like. The ticket ID is identification information for each ticket data (that is, for each update reason or each task). The draft time is the draft time of the ticket data. The completion time is the completion time of the task corresponding to the ticket data. The ticket ID and the draft time are recorded in the ticket data at the time of drafting. The completion time is recorded in the ticket data when the task corresponding to the ticket data is completed.

  The general ticket data includes task contents (for example, contents of functions to be implemented or bug contents to be corrected) and other information, but in this embodiment, for convenience. Other information is omitted.

  Subsequently, the TCNC generation unit 13 acquires a set of commit logs from the commit log storage unit 112 (S102).

  FIG. 5 is a diagram illustrating an example of the commit log. In FIG. 5, one line corresponds to one commit log. Each commit log includes a source code name and a commit time. Some commit logs further include a ticket ID.

  The source code name is the name of the committed source code (for example, the source code file name). The commit time is the time when the commit is performed (that is, the time when the update is reflected in the VMS 11). The ticket ID is the ticket ID of the task ticket data corresponding to the update of the source code related to the commit log.

  For example, when the source code is committed to the VMS 11, the ticket ID is input by a user (developer or the like) via a dialog box or the like. That is, when a ticket ID is input at the time of committing, the commit log generating unit 111 generates a commit log including the ticket ID. However, the ticket ID may not be input. This is because ticket data drafting, ticket ID input, etc. are left to the user's operation. Therefore, a commit log that does not include a ticket ID can be generated.

  Various other information is recorded in the general commit log, but is omitted for convenience in the present embodiment.

  Subsequently, the TCNC generation unit 13 visualizes the relationship between the start time and completion time of the ticket data and the commit time of the commit log for each source code based on the acquired ticket data and commit log (ticket). A commit network chart (Ticket-Commit Network Chart)) is generated (S103). Hereinafter, the ticket-commit network diagram is referred to as “TCNC”.

  Subsequently, the TCNC generation unit 13 displays the generated TCNC on the display device 106 (S104).

  FIG. 6 is a diagram illustrating an example of a TCNC. As shown in FIG. 6, the TCNC indicates the timing of the ticket data start time, completion time, and commit log commit time in time series for each source code (Source 1 to 3). In the example of FIG. 6, the timing granularity is in units of one day, but the timing may be shown in units of one hour or half a day depending on the time width desired to be visualized.

  There are two types of commits, a commit with a ticket ID and a non-commit with a ticket ID (red circle in the figure), depending on whether a ticket ID is input at the time of commit. In FIG. 6, the commit with ticket ID is represented by a black circle, and the uncommitted ticket ID is represented by a white circle.

  According to FIG. 6, it can be seen that there are two commits with ticket ID (6/2 and 6/3) and two uncommitted ticket IDs (6/29, 6/30) for Source1. These are extracted and visualized based on the contents of the commit log.

  The TCNC also indicates the lifetime of the ticket data corresponding to the ticket ID (the period from the draft time to the completion time) based on the ticket ID included in the commit log. For example, for Source1, there is a commit log including “TID-1” as the ticket ID. Therefore, the TCNC generation unit 13 acquires the draft time (6/1) and completion time (6/4) of the ticket data including the ticket ID of “TID-1”, and from 6/1 to 6/4. Display as survival time. In FIG. 6, both ends of the lifetime are indicated by triangles.

  That is, in TCNC, a line (solid horizontal line) is drawn for each source code to indicate the lifetime of the ticket ID related to the ticket ID for each ticket ID included in the commit log related to the source code, In the line, the start time and completion time of the ticket data and the commit time of the commit log including the ticket ID are arranged.

  On the other hand, the commit time with no ticket ID commit is arranged on a line different from the commit time with ticket ID commit, the ticket issue time, and the completion time. This is because it is unknown which ticket data corresponds to the ticket ID no commit. For example, in Source 1, a line (solid line) where a commit time corresponding to TID-1 is arranged is separated from a line (dashed line) where a ticket ID uncommitted is arranged.

  Subsequently, the cause classifying unit 14 classifies the cause (or reason) for which the ticket ID is not input into any of a plurality of patterns for each ticket ID uncommitted (S105).

In the present embodiment, there are the following two patterns that cause no ticket ID to be input.
Pattern 1: The ticket data update (draft / correction) corresponding to the commit is missing.
Pattern 2: Ticket data corresponding to the commit exists, but the developer simply forgot to enter the ticket ID at the time of commit.

  For example, in Source 1 and Source 3, a ticket ID no commit occurs outside the lifetime of a ticket (TID-1 or TID-3) corresponding to a commit with a ticket ID. With regard to such uncommitted ticket ID, there is a high possibility that a new ticket is issued or the content of an existing ticket is not updated. Therefore, the cause classification unit 14 classifies the ticket ID uncommitted with the commit time not included in the lifetime as the pattern 1.

  On the other hand, in Source 2, no ticket ID commit occurs within the lifetime of the ticket (TID-2) corresponding to the commit with ticket ID. With regard to such a ticket ID uncommitted, there is a high possibility that the developer simply forgot to input TID-2 at the time of committing. Therefore, the cause classification unit 14 classifies the ticket ID uncommitted with the commit time included in the lifetime as the pattern 2.

  Subsequently, the cause classification unit 14 outputs notification information corresponding to the classification result for each ticket ID uncommitted to the TCNC displayed on the display device 106 (S106).

  FIG. 7 is a diagram illustrating an output example of the notification information according to the classification result. As shown in FIG. 7, a message indicating that there is a possibility of omission of ticket update is displayed for the source ID or source 3 ticket ID uncommitted classified as pattern 1 as in the notification information n1 and n3. Is done.

  On the other hand, for the source 2 ticket ID uncommitted classified as pattern 2, a message indicating that there is a possibility that a ticket ID may not be provided at the time of commit is displayed as in the notification information n2.

  The user can refer to the notification information and input a ticket ID to a commit log corresponding to no ticket ID uncommitted, or issue or modify ticket data corresponding to ticket ID uncommitted.

  Subsequently, the correction candidate output unit 15 outputs recommendation information of correction candidates corresponding to the classification result to each TCNC displayed on the display device 106 for each ticket ID uncommitted (S107).

  FIG. 8 is a diagram illustrating an output example of recommendation information for correction candidates according to the classification result. As shown in FIG. 8, for ticket ID uncommitted that is classified as pattern 1, the ticket data for the source code related to the ticket ID uncommitted is used as a correction candidate, as in recommendation information r1 or recommendation information r3. Presented.

  For example, in the case of Source1, the ticket data of TID-1 that has been drafted and completed before the ticket ID is not committed is presented as a correction candidate. Further, since there is a possibility that ticket data different from the ticket data may have to be issued, this is also indicated. Similarly, in the case of Source 3, the ticket data of TID-3 issued after ticket ID uncommitted is presented as a correction candidate. Note that the correction of the ticket data is, for example, correction of the draft time or completion time.

  On the other hand, for ticket ID no commits classified as pattern 2, ticket IDs corresponding to commits with ticket IDs committed in the same period are presented as correction candidates, as in recommendation information r2. For example, for Source2, “TID-2” is presented as an input candidate for the commit log corresponding to ticket ID no commit.

  Only one of steps S106 and S107 may be executed. Further, in the TCNC shown in FIG. 7, step S107 may be executed for the uncommitted ticket ID selected by the user.

  As described above, according to the present embodiment, it is possible to notify the user of the existence of a commit log related to uncommitted ticket ID, and to prompt the user to modify the commit log or issue / modify ticket data. it can. Accordingly, it is possible to promote the cancellation of the uncommitted ticket ID, and it is possible to avoid the reason why the source code has been updated.

  In other words, according to the present embodiment, after the development is completed, an attempt is made to confirm the reflection status of the bug correction at the time of development to the source code by enhancing the draft of the ticket data in the software development process. At this time, it is possible to avoid a situation in which it is impossible to confirm whether or not each update to the source code is due to a bug correction. Further, it is possible to avoid that the next developer (or the requester of update) cannot grasp the entire contents of the implemented function or cannot understand the basis of the implemented function. As a result, the quality of maintenance work in software development can be improved.

  In the present embodiment, ticket data is an example of first data. The commit log is an example of second data. The issue time and completion time of the ticket data are examples of the generation timing of the update reason and the completion timing of the work corresponding to the update reason, respectively. The commit time in the commit log is an example of the update time. The cause classification unit 14 is an example of a classification unit. The correction candidate output unit 15 is an example of an output unit.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

10 Data processor 11 VMS
12 ITS
13 TCNC generation unit 14 cause classification unit 15 correction candidate output unit 100 drive device 101 recording medium 102 auxiliary storage device 103 memory device 104 CPU
105 Interface Device 106 Display Device 107 Input Device 111 Commit Log Generation Unit 112 Commit Log Storage Unit 121 Ticket Status Update Unit 122 Ticket Data Storage Unit B Bus

Claims (5)

A set of first data that is drafted for each reason for updating the source code of the software, and includes identification information of the reason for updating, an occurrence time of the reason for updating, and a completion time of work according to the reason for updating A set of second data that is recorded every time the source code is updated and includes the timing of the update, and a part of the second data further corresponds to an update related to the second data. With reference to the set of update reason identification information entered by the user,
The generation time and completion time included in the first data including the identification information input for the partial second data, and the update included in the second data for which the identification information is not input. Data that causes a computer to function as a classification unit that classifies a cause that the identification information is not input to the second data into any one of a plurality of patterns based on the relationship with the time Processing program. The classification unit includes the second data whose update time is included between the generation time and the completion time included in the first data including the identification information input with respect to the partial second data. And the cause of the update is classified into different patterns with respect to the second data that is not included between the occurrence time and the completion time,
The data processing program according to claim 1. The classification unit includes the second data whose update time is included between the generation time and the completion time included in the first data including the identification information input with respect to the partial second data. Is classified into a pattern caused by the fact that the identification information is not input despite the presence of the first data relating to the update reason corresponding to the update,
The data processing program according to claim 1 or 2, characterized by the above-mentioned. An output unit that outputs the identification information input with respect to the partial second data as an input candidate for the second data for which the identification information is not input;
A data processing program according to any one of claims 1 to 3, wherein a computer is caused to function. A set of first data that is drafted for each reason for updating the source code of the software, and includes identification information of the reason for updating, an occurrence time of the reason for updating, and a completion time of work according to the reason for updating A set of second data that is recorded every time the source code is updated and includes the timing of the update, and a part of the second data further corresponds to an update related to the second data. With reference to the set of update reason identification information entered by the user,
The generation time and completion time included in the first data including the identification information input for the partial second data, and the update included in the second data for which the identification information is not input. Data in which the computer executes a classification procedure for classifying the cause of the fact that the identification information is not input to the second data into one of a plurality of patterns based on the relationship with the time Processing method.

Images