JP6141563B2 - Software management apparatus and software management method - Google Patents

Description

  The present invention relates to a software management apparatus and software management method for managing software during software development.

  In large-scale software development, one program is developed by a plurality of developers having different technical levels.

  In software development, after the coding process of describing the source code, a build process that converts the source code into an executable program, and a static analysis process that checks whether the source code violates coding rules, etc. , And a test process for checking whether the program operates correctly.

  If a bug (such as an error in the source code) is found in each process after coding, it is necessary to identify the cause of the bug and perform coding again. In particular, the cause of the bug found in build and test is identified. Takes a lot of time. In addition, when editing a program, a new source code is added or a source code is changed. However, a bug may occur at this time. Therefore, shortening the time required to identify the cause of the bug leads to a reduction in the number of steps for software development.

  As a countermeasure to the above problem, a tool that shows the revision history of the source code that can confirm which revision of each line of the source code in one source file has been used to help identify the cause of the bug. It was. In addition, techniques for evaluating the level of software developers are disclosed (for example, see Patent Documents 1 and 2).

JP 2006-59276 A JP 2010-186394 A

  Even when a method for identifying the cause of a bug based on the revision history of the source code is used, it takes time to identify the cause of the bug in large-scale software development with a large amount of source code.

  Moreover, if the techniques of Patent Documents 1 and 2 are used, the reliability for each source file can be grasped. In other words, if the developer level is low, it can be determined that the reliability of the source file is low, and if a bug occurs, the source file with low reliability may be given priority to identify the cause of the bug. it can. However, even in such a case, as the amount of source code increases, it takes time to identify the cause of the bug, and it cannot be said that the cause of the bug is efficiently identified.

  The present invention has been made to solve such a problem, and an object thereof is to provide a software management apparatus and a software management method capable of efficiently identifying the cause of a bug.

  In order to solve the above-described problem, a software management apparatus according to the present invention includes a revision information acquisition unit that acquires revision information including revisions corresponding to each line of source code in a source file and a revision person who revised the source code. And a developer level management unit that manages the developer level indicating the developer level of the source code and extracts the developer level of the developer corresponding to the revision included in the revision information acquired by the revision information acquisition unit. Based on the revision information acquired by the revision information acquisition unit and the developer level extracted by the developer level management unit, control is performed so that each line of the source code is displayed separately according to the developer level. And a control unit.

  In addition, the software management method according to the present invention obtains revision information including revisions corresponding to each line of the source code in the source file and the revision person who revised the source code, and indicates the level of the developer of the source code. The developer level of the developer corresponding to the revision person included in the obtained revision information is extracted, and each line of source code is extracted based on the obtained revision information and the extracted developer level. Control the display to be distinguished according to the developer level.

  According to the present invention, the software management apparatus includes a revision information acquisition unit that acquires revision information including a revision corresponding to each line of the source code in the source file and a revision person who revised the source code, and a developer of the source code. The developer level management unit that manages the developer level indicating the level of the developer and extracts the developer level of the developer corresponding to the revision included in the revision information acquired by the revision information acquisition unit, and the revision information acquisition unit Based on the obtained revision information and the developer level extracted by the developer level management unit, a control unit that controls to display each line of the source code separately according to the developer level of the developer Therefore, it is possible to efficiently identify the cause of the bug.

  In addition, the software management method obtains revision information including the revision corresponding to each line of the source code in the source file and the revision person who revised the source code, and sets the developer level indicating the level of the developer of the source code. The developer level of the developer corresponding to the revision person included in the obtained revision information is extracted, and each line of the source code is revised based on the obtained revision information and the extracted developer level. Since the display is controlled so as to be distinguished according to the developer level, the cause of the bug can be efficiently identified.

  Objects, features, aspects, and advantages of the present invention will become more apparent from the following detailed description and the accompanying drawings.

It is a block diagram which shows an example of a structure of the software management apparatus by Embodiment 1 of this invention. It is a figure which shows an example of the hardware constitutions corresponding to the software function in the software management apparatus by Embodiment 1 of this invention. It is a block diagram which shows another example of a structure of the software management apparatus by Embodiment 1 of this invention. It is a figure which shows an example of the revision information stored in the revision information database by Embodiment 1 of this invention. It is a figure which shows an example of the developer level stored in the developer level database by Embodiment 1 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 1 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 1 of this invention. It is a figure which shows an example of the display by Embodiment 1 of this invention. It is a figure which shows an example of the developer level stored in the developer level database by Embodiment 1 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 1 of this invention. It is a figure which shows an example of the developer level stored in the developer level database by Embodiment 1 of this invention. It is a block diagram which shows an example of a structure of the software management apparatus by Embodiment 2 of this invention. It is a figure which shows an example of the execution result stored in the execution result database by Embodiment 2 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 2 of this invention. It is a figure which shows an example of the revision information which the revision information acquisition part by Embodiment 2 of this invention acquires. It is a figure which shows an example of the revision information stored in the execution result database by Embodiment 2 of this invention. It is a figure which shows an example of the display by Embodiment 2 of this invention. It is a block diagram which shows an example of a structure of the software management apparatus by Embodiment 3 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 3 of this invention. It is a figure which shows an example of the revision information which the revision information acquisition part by Embodiment 3 of this invention acquires. It is a figure which shows an example of the execution result stored in the execution result database by Embodiment 3 of this invention. It is a figure which shows an example of the revision information stored in the execution result database by Embodiment 3 of this invention. It is a figure which shows an example of the developer level after evaluation by Embodiment 3 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 4 of this invention. It is a figure for demonstrating operation | movement of the software management apparatus by Embodiment 4 of this invention. It is a figure for demonstrating operation | movement of the software management apparatus by Embodiment 4 of this invention. It is a figure for demonstrating operation | movement of the software management apparatus by Embodiment 4 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 5 of this invention. It is a figure which shows an example of the revision information which the revision information acquisition part by Embodiment 5 of this invention acquires. It is a figure which shows an example of the execution result stored in the execution result database by Embodiment 5 of this invention. It is a figure which shows an example of the developer level after evaluation by Embodiment 5 of this invention. It is a block diagram which shows an example of a structure of the software management apparatus by Embodiment 6 of this invention. It is a flowchart which shows an example of operation | movement of the software management apparatus by Embodiment 6 of this invention. It is a figure for demonstrating the reliability of the file by Embodiment 6 of this invention. It is a block diagram which shows an example of a structure of the software management system by embodiment of this invention. It is a block diagram which shows another example of a structure of the software management system by embodiment of this invention.

  Embodiments of the present invention will be described below with reference to the drawings.

<Embodiment 1>
First, the configuration of the software management apparatus according to the embodiment of the present invention will be described. In the present embodiment, a case where the software management apparatus is realized alone will be described.

  FIG. 1 is a block diagram showing an example of the configuration of the software management apparatus 1 according to the first embodiment of the present invention. FIG. 1 shows the minimum necessary components constituting the software management apparatus 1.

  As shown in FIG. 1, the software management apparatus 1 includes at least a revision information acquisition unit 2, a developer level management unit 3, and a control unit 4.

  The revision information acquisition unit 2 acquires revision information including a revision corresponding to each line of the source code in the source file and a revision person who revised the source code.

  The developer level management unit 3 manages the developer level indicating the level of the developer of the source code including the revision, and the developer corresponding to the revision included in the revision information acquired by the revision information acquisition unit 2. Extract developer level.

  Based on the revision information acquired by the revision information acquisition unit 2 and the developer level extracted by the developer level management unit 3, the control unit 4 distinguishes and displays each line of the source code according to the developer level. Control to do.

  FIG. 2 is a diagram illustrating an example of a hardware configuration corresponding to a software function in the software management apparatus 1.

  The revision information acquisition unit 2, developer level management unit 3, and control unit 4 are realized as functions of the processor 5 when the processor 5 of FIG. 2 executes a program stored in the memory 6 or the like, for example. However, these may be realized in cooperation with a plurality of processors 5, for example.

  Next, another configuration of the software management apparatus 1 including the revision information acquisition unit 2, the developer level management unit 3, and the control unit 4 in FIG. 1 will be described.

  FIG. 3 is a block diagram illustrating an example of the configuration of the software management apparatus 7.

  As shown in FIG. 3, the software management apparatus 7 includes a revision information acquisition unit 2, a developer level management unit 3, and a control unit 4. The revision information acquisition unit 2 is connected to the revision information database 8, the developer level management unit 3 is connected to the developer level database 9, and the control unit 4 is connected to the display device 10.

  The revision information database 8 is composed of, for example, a storage device such as a hard disk (HDD) or a semiconductor memory, and is referred to as a version management tool (in the present invention, referred to as a revision management tool for easy understanding). Stores revision information managed by FIG. 4 is a diagram showing an example of revision information stored in the revision information database 8. As shown in FIG. 4, the revision information includes source code revision information and revision correspondence information.

  In the source code revision information, the source code and the revision number of the revised source code are associated with each line of the source code. With the source code revision information, it is possible to determine at which revision each line of the source code has been revised. The revision correspondence information associates a revision number with commit information that is information related to a commit including a committer (revision person) name and commit date (date information). The revision management tool corrects revision information each time it is revised by the committer.

  In the first embodiment, the revision number is assigned an integer value in the order of revision, but is not limited to this. For example, the revision number may be assigned a hash value for each revision. The revision management tool is assumed to be provided outside the software management apparatus 7.

  The revision information acquisition unit 2 acquires the revision information of the target file from the revision information database 8. Here, the target file means, for example, a file that becomes a target when the cause of the bug is identified when a bug occurs in each process in the above-mentioned software development, or the revision source has existing source code. Refers to the file that is subject to revision. The revision information acquisition unit 2 outputs the acquired revision information to each of the developer level management unit 3 and the control unit 4.

  The developer level database 9 is composed of, for example, a storage device such as a hard disk drive (HDD) or a semiconductor memory, and stores a developer level which is a level of a developer who develops software. FIG. 5 is a diagram showing an example of the developer level stored in the developer level database 9. As shown in FIG. 5, in the developer level database 9, the developer name and the developer level of the developer are stored in association with each other. The developer level is set in various ways. For example, there is a method in which a developer is appropriately evaluated and the developer level is manually set (manually). Also, for example, there is a method of automatically setting the developer level based on the working years of the developer.

  The developer level database 9 stores the development level of the developer that is the same as the committer included in the revision information stored in the revision information database 8 and the developer level of a developer other than the committer. That is, in the developer level database 9, a person who can be involved in software development is defined as a developer, and the developer level of the developer is stored.

  The developer level management unit 3 extracts the developer level from the developer level database 9 based on the revision information input from the revision information acquisition unit 2. The developer level management unit 3 outputs the extracted developer level to the control unit 4.

  Based on the revision information input from the revision information acquisition unit 2 and the developer level input from the developer level management unit 3, the control unit 4 sets each line of the source code in the target file according to the developer level. Control the display so that it is distinguished. The display device 10 displays the source code distinguished according to the developer level according to the control of the control unit 4.

  Next, the operation of the software management apparatus 7 according to the first embodiment will be described. In the description using the example in the text, the operation will be described by focusing on one source file for easy understanding of the description, but the present invention can also be applied to a plurality of source files.

  FIG. 6 is a flowchart showing an example of the operation of the software management apparatus 7. Note that, prior to step S101, the revision information acquisition unit 2 knows which file is the target file.

  In step S <b> 101, the revision information acquisition unit 2 acquires revision information from the revision information database 8. Specifically, the revision information acquisition unit 2 acquires, for example, revision information including source code revision information and revision correspondence information as shown in FIG. Then, the revision information acquisition unit 2 outputs the revision correspondence information to the developer level management unit 3 and outputs the source code revision information and the revision correspondence information to the control unit 4.

  In step S102, the developer level management unit 3 acquires the developer level from the developer level database 9 based on the revision correspondence information included in the revision information input from the revision information acquisition unit 2.

  Details of step S102 will be described with reference to FIG.

  In step S201, the committer name included in the revision correspondence information is input to the developer level management unit 3.

  In step S202, the developer level management unit 3 searches the developer level database 9 for a developer name corresponding to the committer name input from the revision information acquisition unit 2, and the committer name matches the developer name. The developer level of the developer is extracted from the developer level database 9. Then, the developer level management unit 3 outputs the extracted developer level to the control unit 4.

  For example, the revision correspondence information shown in FIG. 4 is input from the revision information acquisition unit 2 to the developer level management unit 3, and the developer level shown in FIG. 5 is stored in the developer level database 9. In such a case, the developer level management unit 3 searches the developer level database 9 for the developer name “Tanaka” corresponding to the committer name “Tanaka” when the revision number is “5”, for example. The developer level “35” of “Tanaka” is extracted.

  Returning to FIG. 6, in step S103, the control unit 4 determines the source code of the target file based on the revision information input from the revision information acquisition unit 2 and the developer level input from the developer level management unit 3. Control each line of to be displayed separately according to the developer level. Specifically, for example, as shown in FIG. 8, the control unit 4 performs control so that each line of the source code is displayed in different colors according to the level of the developer. The display device 10 displays each line of source code that is color-coded according to the developer level.

  For example, it is assumed that the revision information shown in FIG. 4 is input from the revision information acquisition unit 2 to the control unit 4, and the administrator level shown in FIG. 5 is input from the developer level management unit 3 to the control unit 4. Since the committer is “Sasaki” when the revision number is “1”, the control unit 4 sets the source code line of the revision number “1” in a color corresponding to the developer level “90” of “Sasaki”. Control to display. Similarly, the line of the source code with the revision number “5” is controlled to be displayed in a color corresponding to the developer level “35” of “Tanaka”. Control is performed so that the line of the source code of the revision number “3” is displayed in a color corresponding to the developer level “60” of “Suzuki”.

  In addition, as a method of displaying each line of the source code by color, for example, when the developer level is based on the working years, red when the working years of the developer are less than one year, and the working years of the developer is 1 It may be displayed in yellow when the year is less than 10 years and in blue when the developer has been working for more than 10 years.

  In the text, it is described that the developer who edits (codes) the source code is the same as the committer, but the developer who edits the source code may be different from the committer. In such a case, each line of source code is not based on the developer level of the developer who edited the source code, but on the developer level of the committer who received the edited source code and revised the source code revision. Are displayed in different colors. Therefore, the committer's developer level reflected in the color coding of each line of the source code includes not only the ability to edit (coding) the source code but also the ability to check the source code edited by other developers. To capture.

  Next, other examples (Modifications 1 and 2) of the first embodiment will be described.

<Modification 1>
In general, a developer's development level increases over time as the developer's working years progress or the developer's capabilities improve. In order to reflect the improvement of the developer level, the developer level stored in the developer level database 9 is also periodically updated. However, for example, when the display as shown in FIG. 8 is performed, the current development in which the developer level is higher than the past developer level with respect to the revised source code line when the past developer level is low. There is a problem that the colors are classified according to the developer level (that is, the colors cannot be classified according to the developer level at the time of revision). The first modification solves such a problem.

  FIG. 9 is a diagram showing an example of the developer level stored in the developer level database 9.

  As shown in FIG. 9, the developer level database 9 stores a developer level history for each update. FIG. 9 shows that three updates (updates A, B, and C) have been performed. The update date and time are shown together with each revision. For example, paying attention to the developer “Tanaka”, it can be seen that the development level of “Tanaka” is “35” for update A, “50” for update B, and “80” for update C. . The developer level setting method is the same as described above.

  FIG. 10 is a flowchart showing details of step S102 in FIG. Since other operations are the same as those in FIG. 6, the description thereof is omitted here.

  In step S301, the committer name and the commit date / time included in the revision correspondence information are input to the developer level management unit 3.

  In step S302, the developer level management unit 3 extracts the developer level from the developer level database based on the committer name and the commit date and time input from the revision information acquisition unit 2. Then, the developer level management unit 3 outputs the extracted developer level to the control unit 4.

  For example, the revision correspondence information shown in FIG. 4 is input from the revision information acquisition unit 2 to the developer level management unit 3, and the developer level shown in FIG. 9 is stored in the developer level database 9. In such a case, the developer level management unit 3 searches the developer level database 9 for the developer name “Tanaka” corresponding to the committer name “Tanaka” at the revision number “5”, for example. Then, among the developers “Tanaka” in the respective updates A to C, the developer level “50” in the latest update B that is earlier than the commit date is extracted.

  From the above, each line of the source code can be displayed in different colors according to the development level at the time of revision.

<Modification 2>
In the above description, for example, as illustrated in FIG. 5, a case has been described in which there is one developer level item for each developer, but this is not a limitation. For example, a developer's ability may change for each type of programming language. Assuming such a case, the developer level may be a plurality of items.

  FIG. 11 is a diagram showing an example of the developer level stored in the developer level database 9. In the example of FIG. 11, three items of “C / C ++ development level”, “Java (registered trademark) development level”, and “Cobol development level” are set for each developer.

  From the above, the developer level management unit 3 may extract “C / C ++ development level” as the developer level when the programming language of the source code of the target file is C / C ++, for example. That is, the developer level management unit 3 can extract a developer level that matches the actual situation.

  From the above, according to the first embodiment, each line of the source code is displayed separately according to the developer level. Therefore, when a bug is found, the source code with a low developer level is given priority. It is possible to efficiently identify the cause of a bug by examining the above. In addition, when the existing source code is revised, the development level of each line of the source code can be grasped.

  In the above description, the case where revision information as shown in FIG. 4 is stored in the revision information database 8 by the management of the revision management tool has been described. However, there is a revision management tool that manages revision information in which a source code and a revised revision number of the source code are not associated with each line of the source code. The revision information managed by the revision management tool does not include source code revision information as shown in FIG. In such a case, the revision information acquisition unit 2 acquires all the revision information of the target file from the revision information database 8, and generates source code revision information as shown in FIG. 4 based on the acquired revision information. May be.

  In the revision information database 8, when there are a plurality of committers having the same surname, the committers are stored separately. The same applies to the developer name stored in the developer level database 9. In this case, it is necessary to associate the committed committer with the developer name.

  In the above description, the lines of the source code are displayed in different colors according to the developer level. However, the present invention is not limited to this. When the developer level is lower than a predetermined threshold, the corresponding source code line may be highlighted in bold or the like, or a symbol that identifies the corresponding source code line may be added. Further, a line of source code whose developer level is lower than a predetermined threshold value may be listed.

<Embodiment 2>
First, the configuration of the software management apparatus according to the second embodiment of the present invention will be described.

  FIG. 12 is a block diagram showing an example of the configuration of the software management apparatus 11 according to the second embodiment.

  As shown in FIG. 12, the software management apparatus 11 according to the second embodiment is characterized by including an execution result management unit 12 and a source code extraction unit 13. The execution result management unit 12 is connected to the execution result database 14. Since other configurations and operations are the same as those in the first embodiment, detailed description thereof is omitted here.

  The revision information acquisition unit 2 acquires the revision information of the target file from the revision information database 8 and acquires the execution result of the target file. Here, the execution result of the target file according to the second embodiment means success or failure of execution in each step of software development (for example, a build step and a test step). The execution result is input to the revision information acquisition unit 2 from, for example, a build tool used in the build process or a test tool used in the test process. At this time, the execution result and the revision information are input to the revision information acquisition unit 2 in association with each other by a plug-in. In this way, the revision information acquisition unit 2 acquires the execution result and revision information when the target file is executed. The revision information acquisition unit 2 outputs the acquired revision information to the developer level management unit 3 and the control unit 4, and outputs the acquired execution result and revision information to the execution result management unit 12.

  The execution result management unit 12 manages the execution result input from the revision information acquisition unit 2 and the revision information so as to be associated with each other and stored in the execution result database 14. Further, the execution result management unit 12 outputs the revision information stored in the execution result database 14 to the source code extraction unit 13.

  The execution result database 14 is composed of a storage device such as a hard disk drive (HDD) or a semiconductor memory, for example, and stores execution results and revision information in association with each other by management of the execution result management unit 12. Yes. FIG. 13 is a diagram illustrating an example of execution results stored in the execution result database 14. As shown in FIG. 13, the execution result database 14 stores an execution result and revision information in association with each executed revision number. For example, the execution result of the revision number “1” and the revision number “5” indicates “× (failure)”, and the execution result of the revision number “3” indicates “◯ (success)”. Show.

  The source code extraction unit 13 extracts a line of source code based on the revision information input from the execution result management unit 12. The source code extraction unit 13 outputs the extracted source code line to the developer level management unit 3.

  Note that the execution result management unit 12 and the source code extraction unit 13 are realized as functions of the processor 5 when the processor 5 of FIG. 2 executes a program stored in the memory 6 or the like, for example. However, these may be realized in cooperation with a plurality of processors 5, for example.

  Next, the operation of the software management apparatus 11 according to the second embodiment will be described.

  FIG. 14 is a flowchart illustrating an example of the operation of the software management apparatus 11. Note that step S406, step S408, and step S409 in FIG. 14 correspond to each of step S102 and step S103 in FIG.

  In step S401, the revision information acquisition unit 2 acquires the revision information of the target file from the revision information database 8, and acquires the execution result of the target file. For example, the revision information acquisition unit 2 acquires the execution result and revision information including the source code revision information shown in FIG. In FIG. 15, the revision number of the current revision of the source code is “5”, and revision numbers “2”, “3”, “4”, and “5” including revisions revised in the past are also included. Indicates that the revision is affected by the revision. That is, the revision information acquisition unit 2 acquires the revision information of the target file including the source code revision information shown in FIG. 15 and the execution result thereof.

  In step S <b> 402, the execution result management unit 12 manages the execution result and the revision information input from the revision information acquisition unit 2 so as to be associated with each other and stored in the execution result database 14. In the example of FIG. 13, the execution result database 14 stores revision information and execution results for the revision number “5” acquired by the revision information acquisition unit 2 this time.

  In step S403, the execution result management unit 12 determines whether or not the execution result of the current target file is a failure. If the execution result is failure, the process proceeds to step S404. On the other hand, if the execution result is not a failure (that is, the execution result is a success), the process is terminated. In the example of FIG. 13, the execution result of the current target file (revision number “5”) is “× (failure)”.

  In step S404, the execution result management unit 12 determines whether revision information of a parent revision whose execution result has been successful in the past has been stored in the execution result database 14. If the revision information of the parent revision whose execution result is successful is stored in the execution result database 14, the process proceeds to step S405. On the other hand, if the revision information of the parent revision whose execution result is successful is not stored in the execution result database 14, the process proceeds to step S408 and the same processing as in the first embodiment is performed. Here, the parent revision means a past revision (revision) in the target file. In the example of FIG. 13, the parent revision of the revision number “5” is the revision number “1” and the revision number “3”, and the execution result when the revision number is “3” is “◯ (success)”.

  In step S405, the execution result management unit 12 extracts the revision information of the current revision and the revision information of the latest parent revision of the parent revisions that have been successful in the past from the execution result database 14, and the source code extraction unit 13 Output to. In the example of FIG. 13, the execution result management unit 12 executes the revision information of revision number “5” (current revision) and the revision information of revision number “3” (latest parent revision that was successful in the past). Extract from the database 14 and output to the source code extraction unit 13. Note that the source code revision information included in the revision information with the revision number “3” shown in FIG. 13 is the source code revision information shown in FIG. 16, for example.

  The source code extraction unit 13 takes the difference between the revision information of the current revision input from the execution result management unit 12 and the revision information of the latest parent revision that has succeeded in the past, and obtains the source code line of the difference part. Identify the revised committer. For example, if the difference between the revision information of the revision number “5” (current revision) and the revision information of the revision number “3” (the latest parent revision that has succeeded in the past) is taken, the difference part is the revision number “4”. ”And the source code corresponding to the revision number“ 5 ”. Then, the revised committer is specified when the vision number is “4” and the revision number is “5”.

  In step S407, the control unit 4 converts each line of the source code of the target file into the source code based on the revision information input from the revision information acquisition unit 2 and the developer level input from the developer level management unit 3. Control is performed so as to distinguish and display according to the developer level of the committer specified by the extraction unit 13. Specifically, for example, as shown in FIG. 17, the control unit 4 displays each line of the source code corresponding to the revision number “4” and the revision number “5” in different colors according to the level of the developer. To control. The display device 10 displays each line of source code that is color-coded according to the developer level.

  From the above, according to the second embodiment, the source code lines of the difference portion between the revision information that has failed this time and the latest revision information that has succeeded in the past are displayed in different colors. The cause of the bug can be identified more efficiently than in the first embodiment in which all the lines are displayed in different colors.

<Embodiment 3>
First, the configuration of the software management apparatus according to the third embodiment of the present invention will be described.

  FIG. 18 is a block diagram showing an example of the configuration of the software management apparatus 15 according to the third embodiment.

  As shown in FIG. 18, the software management apparatus 15 according to the third embodiment includes a developer evaluation unit 16 instead of the source code extraction unit 13 of the software management apparatus 11 (see FIG. 12) according to the second embodiment. It is characterized by that. Since other configurations and operations are the same as those in the second embodiment, detailed description thereof is omitted here.

  The developer evaluation unit 16 evaluates the developer based on the revision information input from the execution result management unit 12. Specifically, the developer evaluation unit 16 identifies a developer (commiter) that lowers the developer level, and determines to lower the developer level of the developer.

  Note that the developer evaluation unit 16 is realized as a function of the processor 5 when the processor 5 of FIG. 2 executes a program stored in the memory 6 or the like, for example. However, these may be realized in cooperation with a plurality of processors 5, for example.

  Next, the operation of the software management apparatus 15 according to the third embodiment will be described.

  FIG. 19 is a flowchart illustrating an example of the operation of the software management apparatus 15.

  In step S501, the revision information acquisition unit 2 acquires the revision information of the target file from the revision information database 8, and acquires the execution result of the target file. For example, the revision information acquisition unit 2 acquires the execution result and revision information including the source code revision information shown in FIG. In FIG. 20, the revision number of the current revision of the source code is “6”, and revision numbers “2”, “3”, “4”, “6” including revisions revised in the past are also included. Indicates that the revision is affected by the revision. That is, the revision information acquisition unit 2 acquires the revision information of the target file having the source code shown in FIG. 20 and the execution result thereof.

  In step S502, the execution result management unit 12 manages the execution result input from the revision information acquisition unit 2 and the revision information so as to be associated with each other and stored in the execution result database 14. For example, as shown in FIG. 21, the execution result database 14 stores the revision information and the execution result for the revision number “6” acquired by the revision information acquisition unit 2 this time.

  In step S503, the execution result management unit 12 determines whether or not the execution result of the current target file is successful. If the execution result is successful, the process proceeds to step S504. On the other hand, if the execution result is not successful (that is, the execution result is failure), the process is terminated. In the example of FIG. 21, the execution result of the current target file (revision number “6”) is “◯ (success)”.

  In step S504, the execution result management unit 12 determines whether or not the execution result of the latest parent revision stored in the execution result database 14 is a failure. When the execution result of the latest parent revision is unsuccessful, the process proceeds to step S505. On the other hand, if the execution result of the latest parent revision is not a failure (the execution result of the latest parent revision is successful, or the parent revision is not stored in the execution result database 14), the process ends. In the example of FIG. 21, the parent revision of the revision number “6” is the revision number “1”, the revision number “3”, and the revision number “5”, and the revision number “1” and the revision number “5”. The execution result is “× (failure)”.

  In step S505, the execution result management unit 12 extracts the revision information of the current revision and the revision information of the latest parent revision of the parent revisions that have failed in the past from the execution result database 14, and the developer evaluation unit 16 Output to. In the example of FIG. 21, the execution result management unit 12 executes the revision information of revision number “6” (current revision) and the revision information of revision number “5” (latest parent revision that failed in the past). Extracted from the database 14 and output to the developer evaluation unit 16. It is assumed that the source code revision information included in the revision information with the revision number “5” shown in FIG. 21 is the source code revision information shown in FIG.

  The developer evaluation unit 16 takes the difference between the revision information of the current revision input from the execution result management unit 12 and the revision information of the latest parent revision that failed in the past, and in the latest parent revision that failed in the past The committer of the revision corresponding to the difference part is specified, and it is determined that the developer level of the specified committer is lowered. For example, if the difference between the revision information of revision number “6” that is the current revision and the revision information of revision number “5” that is the latest parent revision that failed in the past is taken, Is the line of the source code corresponding to the revision number “6” (in the example, the revision revised from the latest parent revision that failed in the past to the current revision is the revision with the revision number “6”). Only the revision number “6” is targeted, but when there are a plurality of revisions revised from the latest parent revision that failed in the past, the source code line corresponding to each revision is targeted). In the latest parent revision that failed in the past, this line corresponds to the revision with revision number “5” (in the example, the revision number of the latest parent revision that failed in the past is the same as the revision number corresponding to the difference part). But may be different). As a result, it can be estimated that the bug was embedded by the revision with the revision number “5”, so the developer evaluation unit 16 identifies the committer revised at the revision number “5” from the revision information, and the developer level of the committer Is determined to lower.

  In step S <b> 506, the developer level management unit 3 lowers the developer level of the developer corresponding to the committer specified by the developer evaluation unit 16. That is, the developer level management unit 3 updates the developer level stored in the developer level database 9. For example, when the developer level shown in FIG. 5 is stored in the developer level database 9, the developer level management unit 3 develops the committer (here “Tanaka”) specified by the developer evaluation unit 16. The person level is lowered from “35” to “30” (see FIG. 23). How to lower the developer level may be determined by an arbitrary method.

  As described above, according to the third embodiment, since a committer that has failed to be revised in the past is identified and the developer level of the committer is lowered, a more appropriate developer level evaluation can be performed. . In addition, by distinguishing and displaying each line of the source code according to the updated developer level, it is possible to efficiently identify the cause of the bug. In addition, when the existing source code is revised, the development level of each line of the source code can be grasped.

  It should be noted that between step S505 and step S506 in FIG. 19, the committer name determined to lower the development level and the source code revised by the committer are displayed, and the user determines whether to lower the committer development level. You may make it confirm. In this case, developers can be evaluated more carefully.

<Embodiment 4>
In the third embodiment, it is assumed that there is a cause of a bug in the difference part between the revision information in the failed revision and the revision information in the succeeded revision, and the committer developer level revised when the difference part fails The case of lowering was explained. However, the above difference part may include a part other than the cause of the bug, and it cannot be said that the developer level is appropriately evaluated. The fourth embodiment of the present invention solves such a problem, and will be described in detail below. The configuration of the software management apparatus according to the fourth embodiment is the same as that of the software management apparatus 15 (see FIG. 18) according to the third embodiment. In the following description, it is assumed that the software management apparatus according to the fourth embodiment is the software management apparatus 15 shown in FIG.

  FIG. 24 is a flowchart showing an example of the operation of the software management apparatus 15 according to the fourth embodiment.

  In step S601, the revision information acquisition unit 2 acquires the revision information of the target file from the revision information database 8, and acquires the execution result of the target file.

  In step S602, the execution result management unit 12 manages the execution result input from the revision information acquisition unit 2 and the revision information so as to be associated with each other and stored in the execution result database 14.

  In step S603, the execution result management unit 12 determines whether or not the execution result of the current file (second timing) is a failure. If the execution result is unsuccessful, the process proceeds to step S604. On the other hand, if the execution result is not a failure (that is, the execution result is a success), the process proceeds to step S606.

  In step S604, the execution result management unit 12 determines whether revision information of a parent revision whose execution result has been successful in the past (first timing) has been stored in the execution result database 14. When the revision information of the parent revision whose execution result is successful is stored in the execution result database 14, the process proceeds to step S605. On the other hand, if the revision information of the parent revision whose execution result is successful is not stored in the execution result database 14, the process ends.

  In step S605, the execution result management unit 12 extracts the revision information of the current revision and the revision information of the latest parent revision among the parent revisions that have been successful in the past from the execution result database 14, and the developer evaluation unit 16 Output to.

  The developer evaluation unit 16 takes the difference between the revision information of the current revision input from the execution result management unit 12 and the revision information of the latest parent revision that has failed in the past, and bugs the revision corresponding to the difference part. Stored as a cause candidate revision (first revision). The bug cause candidate revision may be stored in the developer evaluation unit 16 or may be stored in another storage unit (not shown).

  For example, the source code revision information shown in FIG. 25 is included in the revision information of the revision of this time (the execution result is failed in this case), and the source code revision information shown in FIG. 26 is the revision of the latest parent revision that has succeeded in the past. When included in the information, the developer evaluation unit 16 sets the revision number “7” and the revision number “8” corresponding to the difference portion of each revision information as bug cause candidate revisions. FIG. 25 shows source code revision information executed when the revision number is “8”, and FIG. 26 shows source code revision information executed when the revision number is “6”.

  In step S606, the developer evaluation unit 16 determines whether a bug cause candidate revision is stored. If the bug cause candidate revision is stored, the process proceeds to step S607. On the other hand, if no bug cause candidate revision is stored, the process is terminated.

  In step S607, the developer evaluation unit 16 takes the difference between the revision information of the latest parent revision that has failed in the past and the revision information (second revision) of the current (third timing) and calculates the difference. It is determined whether the portion includes a line of source code corresponding to the bug cause candidate revision. If the source code line corresponding to the bug cause candidate revision is included, the process proceeds to step S608. On the other hand, if the source code line corresponding to the bug cause candidate revision is not included, the process ends.

  In step S608, the developer evaluation unit 16 determines that the revision level of the committer of the revision in which the source code of the difference portion has been revised among the revisions stored in the bug cause candidate revision will be lowered, and the bug cause candidate. The source code line corresponding to the revision is decided to raise the developer level of the committer who revised this time.

  For example, the source code revision information shown in FIG. 27 is included in the revision information of the current revision (here, the execution result is successful). The revision number “7” and the revision number “7” in the source code revision information shown in FIG. 8 ”is a bug cause candidate revision. In such a case, it is determined that the development level of the committer revised when the source code corresponding to the revision number “9” in the difference part of each revision information is the revision number “7” is lowered. It is determined that the development level of the revised committer is sometimes raised. FIG. 27 shows the source code revision information executed when the revision number is “10”.

  In step S609, the developer level management unit 3 changes the developer level of the developer corresponding to the committer specified by the developer evaluation unit 16. Specifically, the developer level management unit 3 develops a committer that revised the source code that caused the execution result to fail (the committer that was revised when the revision number was “7” in the example of FIG. 25). Lower the level Further, the developer level management unit 3 revises the committer that revised the source code that caused the execution result to be successful (resolved the past failure) (in the example of FIG. 27, the revision number is 9). Raise the developer level.

  In step S610, all revisions stored as bug cause candidate revisions are erased from the bug cause candidate revisions.

  From the above, according to the fourth embodiment, it is possible to identify a committer that has failed to be revised in the past with higher accuracy than in the third embodiment. Moreover, since the evaluation of the committer which solved the past failure is raised, a more appropriate developer evaluation can be performed.

  Note that, between step S608 and step S609 in FIG. 24, the committer name determined to change the development level and the source code revised by the committer are displayed, and whether or not to change the committer development level is determined. You may make it confirm with a user. In this case, developers can be evaluated more carefully.

<Embodiment 5>
In the fifth embodiment of the present invention, when an error or warning is issued when a problematic source code line (causing a bug) such as a static analysis process in software development can be identified, the error or warning is issued. It is characterized by lowering the evaluation of the committer that caused the. In the following description, only the static analysis process will be described. However, when a tool that can identify a problematic source code line is used, the present embodiment can be used as an object in addition to the static analysis process. The configuration of the software management apparatus according to the fifth embodiment is the same as that of the software management apparatus 15 (see FIG. 18) according to the third embodiment. However, it is not always necessary to store execution results of past revisions in the execution result database 14. In the following description, it is assumed that the software management apparatus according to the fifth embodiment is the software management apparatus 15 shown in FIG.

  FIG. 28 is a flowchart showing an example of the operation of the software management apparatus 15 according to the fifth embodiment.

  In step S701, the revision information acquisition unit 2 acquires the revision information of the target file from the revision information database 8, and acquires the execution result of the target file. Here, the execution result of the target file in the fifth embodiment is an execution result in a static analysis process in software development, and points out a portion (line) where an error or warning of the source code occurs. Is. In the static analysis process, it is determined whether or not the source code conforms to the coding rule or the like (does not violate the coding rule or the like). If the source code does not conform to the coding rule or the like, the execution result indicating an error or warning Is input to the revision information acquisition unit 2. Further, the execution result and the revision information are input to the revision information acquisition unit 2 in association with the plug-in.

  For example, the revision information acquisition unit 2 acquires the execution result and revision information including the source code revision information shown in FIG. FIG. 29 shows that the line of the source code with the revision number “6” has been revised this time. That is, the revision information acquisition unit 2 acquires the revision information of the target file including the source code revision information shown in FIG. 29 and the execution result thereof.

  In step S <b> 702, the execution result management unit 12 manages the execution result input from the revision information acquisition unit 2 and the revision information so as to be associated with each other and stored in the execution result database 14. For example, as shown in FIG. 30, the execution result database 14 stores the revision information of the revision number “6” acquired by the revision information acquisition unit 2 this time and the execution result (not shown in FIG. 30).

  In step S703, the execution result management unit 12 determines whether or not there is a location where an error or warning has occurred in the execution result of the current target file. If there is a location where an error or warning has occurred, the process proceeds to step S704. On the other hand, if there is no error or warning, the process is terminated.

  In step S <b> 704, the execution result management unit 12 extracts the revision information of the current revision and the revision information of the latest parent revision in the past from the execution result database 14 and outputs them to the developer evaluation unit 16. In the example of FIG. 30, the execution result management unit 12 extracts revision information of revision number “6” (current revision) and revision information of revision number “5” from the execution result database 14, and developer evaluation unit 16 is output.

  The developer evaluation unit 16 takes the difference between the revision information of the current revision input from the execution result management unit 12 and the revision information of the latest parent revision in the past, and the difference part is an error or warning due to static analysis. If it is a corresponding part of the above, it is determined that the developer level of the committer that revised the relevant part of the error or warning due to the static analysis of the difference part will be lowered. In the example of FIG. 29, the revision number “6” corresponds to the difference between the revision information of the current revision and the revision information of the latest parent revision in the past, and in the source code corresponding to the revision number “6”, “= Does not follow the coding rules that must include a space before and after, and is an appropriate error or warning in the results of static analysis. Therefore, the revision committer with the revision number “6” is identified from the revision information, and it is determined that the developer level of the committer is to be lowered.

  In step S705, the developer level management unit 3 lowers the developer level of the developer corresponding to the committer specified by the developer evaluation unit 16. That is, the developer level management unit 3 updates the developer level stored in the developer level database 9. For example, when the developer level shown in FIG. 5 is stored in the developer level database 9, the developer level management unit 3 develops the committer (here “Sasaki”) specified by the developer evaluation unit 16. The person level is lowered from “90” to “80” (see FIG. 31).

  From the above, according to the fifth embodiment, since the development level of the committer describing the source code that generates an error or warning in the static analysis is lowered, a more appropriate developer level evaluation can be performed. it can.

  In addition, between step S704 and step S705 in FIG. 28, the committer name determined to lower the development level and the source code revised by the committer are displayed, and the user determines whether to lower the committer development level. You may make it confirm. In this case, developers can be evaluated more carefully.

<Embodiment 6>
First, the configuration of the software management apparatus according to the sixth embodiment will be described.

  FIG. 32 is a block diagram showing an example of the configuration of the software management apparatus 17 according to the sixth embodiment.

  As shown in FIG. 32, the software management apparatus 17 according to the sixth embodiment is characterized by including a file level evaluation unit 18. Since other configurations and operations are the same as those in the first embodiment, detailed description thereof is omitted here.

  Based on the revision information of the target file input from the revision information acquisition unit 2 and the developer level contributing to the target file input from the developer level management unit 3, the file level evaluation unit 18 Assess at least one of the levels.

  Next, the operation of the software management apparatus 17 according to the sixth embodiment will be described.

  FIG. 33 is a flowchart illustrating an example of the operation of the software management apparatus 17. Note that step S801 and step S802 in FIG. 33 correspond to step S101 and step S102 in FIG.

  In step S803, the file level evaluation unit 18 evaluates the level of the target file. Specifically, the file level evaluation unit 18 is based on the revision information of the target file input from the revision information acquisition unit 2 and the developer level contributing to the target file input from the developer level management unit 3. For example, as shown in FIG. 34, the number of lines of the source code is totaled for each developer level. Then, the file level evaluation unit 18 calculates the ratio of the number of lines of the source code revised by the committer of the developer level or higher determined in advance for all lines of the source code of the target file, and calculates the calculated ratio. At the file level. Here, the predetermined developer level is arbitrarily set by the user.

  In step S804, the file level evaluation unit 18 determines whether one piece of software is configured from a plurality of files including the target file. If the software is composed of a plurality of files including the target file, the process proceeds to step S805. On the other hand, if the software is not composed of a plurality of files including the target file, the process is terminated.

  In step S805, the file level evaluation unit 18 calculates the level of the software based on the levels of a plurality of files constituting the software. The software level may be an average of the levels of each file, for example. Note that when performing the process of step S805, the level of each file constituting the software needs to be calculated in step S803.

  From the above, according to the sixth embodiment, the level of the target file or the level of software including the target file can be grasped.

  The software management apparatus described above can also be applied to a software management apparatus constructed as a system by appropriately combining a server and a mobile communication terminal (for example, a mobile phone, a smartphone, and a tablet terminal). In this case, each function or each component of the software management apparatus is distributed and arranged in each function for constructing the system.

  Specifically, as an example, the function of the software management apparatus can be arranged in a server. For example, as shown in FIG. 35, each component having the display device 10 having the same function as the display device 10 shown in FIG. 3 on the user side and having the same function as the software management device 7 shown in FIG. A software management system can be constructed by providing elements. In addition, you may make it each component with which the server 19 is provided disperse | distributing to the server 19 and the display apparatus 10 suitably. The same applies to each component shown in FIGS.

  As another example, the function of the software management apparatus can be arranged in a server and a mobile communication terminal. For example, as shown in FIG. 36, the user is provided with the display device 10 having the same function as the display device 10 shown in FIG. 3, and the server 20 has the revision information acquisition unit 2 and developer level management unit 3 shown in FIG. And a software management system can be constructed by providing the mobile communication terminal 21 with the control unit 4 shown in FIG. In addition, you may make it each component with which the server 20 and the portable communication terminal 21 are provided disperse | distributing to the display apparatus 10, the server 20, and the portable communication terminal 21 suitably. The same applies to each component shown in FIGS.

  Even if it is a case where it is said structure, the effect similar to said embodiment is acquired.

  In addition, software (software management method) that executes the operation in the above-described embodiment may be incorporated in a server or a mobile communication terminal, for example.

  Specifically, as an example, the above software management method obtains revision information including the revision corresponding to each line of the source code in the source file and the revision person who revised the source code, and the source including the revision person. The developer level indicating the level of the developer of the code is managed, the developer level of the developer corresponding to the revision included in the acquired revision information is extracted, the acquired revision information, the extracted developer level, and Based on the above, each line of the source code is controlled to be displayed separately according to the developer level.

  As described above, the same effects as those of the above-described embodiment can be obtained by operating the software that executes the operation of the above-described embodiment in a server or a mobile communication terminal.

  1, 3, 12, 18, 32, 35, and 36, the revision information acquisition unit 2, developer level management unit 3, control unit 4, execution result management unit 12, source code extraction unit 13, developer evaluation Each of the unit 16 and the file level evaluation unit 18 is realized by the processor 5 of FIG. 2 operating according to a software program stored in the memory 6 or the like. However, instead of this, each of the revision information acquisition unit 2, the developer level management unit 3, the control unit 4, the execution result management unit 12, the source code extraction unit 13, the developer evaluation unit 16, and the file level evaluation unit 18 is provided. May be configured as hardware (for example, an arithmetic / processing circuit configured to perform a specific calculation or process on an electric signal). Further, both of the above may be mixed.

  Each of the software revision information acquisition unit 2, the developer level management unit 3, the control unit 4, the execution result management unit 12, the source code extraction unit 13, the developer evaluation unit 16, and the file level evaluation unit 18, A concept that combines the hardware revision information acquisition unit 2, the developer level management unit 3, the control unit 4, the execution result management unit 12, the source code extraction unit 13, the developer evaluation unit 16, and the file level evaluation unit 18. As an alternative, the word “processing circuit” can be used instead of the word “part”.

  It should be noted that the present invention can be freely combined with each other within the scope of the invention, and each embodiment can be appropriately modified or omitted.

  Although the present invention has been described in detail, the above description is illustrative in all aspects, and the present invention is not limited thereto. It is understood that countless variations that are not illustrated can be envisaged without departing from the scope of the present invention.

  DESCRIPTION OF SYMBOLS 1 Software management apparatus, 2 Revision information acquisition part, 3 Developer level management part, 4 Control part, 5 Processor, 6 Memory, 7 Software management apparatus, 8 Revision information database, 9 Developer level database, 10 Display apparatus, 11 Software Management device, 12 execution result management unit, 13 source code extraction unit, 14 execution result database, 15 software management device, 16 developer evaluation unit, 17 software management device, 18 file level evaluation unit, 19, 20 server, 21 mobile communication Terminal.

Claims (15)

A revision information acquisition unit for acquiring revision information including a revision corresponding to each line of the source code in the source file and a revision person who revised the source code;
Development that manages the developer level indicating the level of the developer of the source code and extracts the developer level of the developer corresponding to the revision included in the revision information acquired by the revision information acquisition unit Person level management department,
Based on the revision information acquired by the revision information acquisition unit and the developer level extracted by the developer level management unit, each line of the source code is displayed separately according to the developer level. A control unit for controlling
A software management device.   The software management apparatus according to claim 1, wherein the developer level is updated at a predetermined timing. The revision information includes date and time information indicating the date and time when the revision person revised the source code,
The control unit distinguishes and displays each line of the source code in accordance with the developer level updated at the predetermined timing that is older than the date and time indicated in the date and time information and is the latest. The software management apparatus according to claim 2, wherein the software management apparatus controls the software. When the execution result of the source code and the revision information acquired by the revision information acquisition unit are managed in association with each other and the execution result of this time is determined to be unsuccessful, An execution result management unit that extracts the corresponding revision information and the latest revision information of the past revision information determined that the execution result is successful;
A source code extraction unit that extracts a line of the source code in a difference portion between the source code included in the current revision information extracted by the execution result management unit and the source code included in the latest revision information;
Further comprising
The software management apparatus according to claim 1, wherein the control unit performs control to distinguish and display the source code lines extracted by the source code extraction unit. When the execution result of the source code and the revision information acquired by the revision information acquisition unit are managed in association with each other and the execution result of this time is determined to be successful, An execution result management unit that extracts the corresponding revision information and the latest revision information of the past revision information determined that the execution result is unsuccessful;
The revision person who revised the line of the source code in the difference part between the revision information corresponding to the current execution result extracted by the execution result management unit and the latest revision information is identified. And a developer evaluation unit that performs an evaluation to lower the developer level of the developer corresponding to the identified reviser,
The software management apparatus according to claim 1, further comprising: An execution result management unit that manages the source code execution result and the revision information acquired by the revision information acquisition unit in association with each other;
The execution result management unit determines that the execution result is successful at a first timing, and the execution result management unit fails the execution result at a second timing after the first timing. The first revision, which is the revision revised with respect to the revision determined to be, is specified, and the execution result management unit determines that the execution result is successful at a third timing after the second timing. A developer evaluation unit that performs the developer-level evaluation based on whether the source code line revised in the first revision is further revised in the second revision that is the determined revision;
The software management apparatus according to claim 1, further comprising:   If the developer evaluation unit determines that the source code line revised in the first revision has been revised in the second revision, the developer evaluation part revised the source code line in the first revision. The software management apparatus according to claim 6, wherein an evaluation for lowering the developer level of the developer corresponding to the revised person is performed.   If the developer evaluation unit determines that the source code line revised in the first revision is further revised in the second revision, the developer evaluation part revised the source code line in the second revision. The software management apparatus according to claim 6, wherein an evaluation for raising the developer level of the developer corresponding to the revision person is performed. An execution result management unit that manages the source code execution result and the revision information acquired by the revision information acquisition unit in association with each other;
When the execution result management unit determines that the current execution result is failure, the revision information corresponding to the current execution result and the latest latest revision information managed by the execution result management unit If the source code in the difference part is a corresponding part of an error or warning by static analysis, it corresponds to the revision person who revised the line of the source code that is a corresponding part of error or warning by static analysis The software management apparatus according to claim 1, further comprising a developer evaluation unit that performs an evaluation for lowering the developer level of the developer.   A file level evaluation unit that evaluates the level of the source file based on a ratio of the number of lines of the source code revised by the revamper of the developer level that is predetermined or higher with respect to the entire source code; The software management apparatus according to claim 1, wherein: In the case where one software is composed of a plurality of the source files,
11. The software management apparatus according to claim 10, wherein the file level evaluation unit evaluates the level of the software based on the level of each source file.   The software management apparatus according to claim 1, wherein the developer level management unit manages the developer level for each type of programming language.   The software management apparatus according to claim 1, wherein the developer level is manually set.   The software management apparatus according to claim 1, wherein the developer level is automatically set. Obtain revision information including the revision corresponding to each line of the source code in the source file and the revision who revised the source code;
Managing a developer level indicating a level of a developer of the source code, and extracting the developer level of the developer corresponding to the revision included in the obtained revision information;
A software management method for controlling to display each line of the source code in accordance with the developer level based on the acquired revision information and the extracted developer level.

Images