JP4883700B2 - Repository server management system - Google Patents

Description

  The present invention relates to management of a repository server in application development, and more particularly to a system that determines whether or not a repository can be updated according to voting and past performance of a developer.

In recent years, with the expansion of the scale of applications, the development of applications involving many developers has increased. In such development projects, it has become common to manage source code in a storage location called a repository server in order to share the development status among developers.
In a development system using a repository server, the updated contents often affect the entire application and cause serious problems. Therefore, before storing the source code in the repository, it is often performed that the updated contents are thoroughly read by the team, and the problems are identified and corrected. This kind of careful reading is called source code review.

  FIG. 21 is a diagram showing the configuration of a development system that uses a repository server. This system is composed of a development PC 2101, an issue database 2102, a schedule database 2103, and a repository server 2104, and the development PC 2101, The database 2102, the schedule database 2103, and the repository server 2104 are connected via a network.

The development PC 2101 is equipped with an application for writing source code and a client application for the repository server 2104, and a mouse 2105 and a keyboard 2106 for operating them are provided.
The problem database 2102 stores defects found during application development and the contents of requests.
The schedule database 2103 stores a scheduled start time and end time for each developer.
The repository server 2104 stores source code registered by the developer, and includes means for storing an update history for each file.

In such a development system, the developer describes the source code on the development PC 2101 according to the contents (issues and requests) of the issue database 2102 and adjusts the developer's schedule in the development project registered in the schedule database 2103. Conduct a source code review at
If it is confirmed that the source code review is valid, the updated contents are reflected in the repository server 2104 by the client application.
Reflecting the update contents of the source code in the repository server 2104 in this way is generally called commit.
If a problem is found in the source code after committing, the contents are registered in the assignment database 2102, the target source code is acquired from the repository server 2104, corrected, and committed again.
The following patent document 1 is given as a known technical document related to the present invention.

JP 2006-18735 A

Source code review is effective in improving the quality of applications, but in many cases it is conducted in a conference format, so it is necessary to adjust the schedule of each developer.
This is to build a system that reserves vacant schedules for each developer, performs voting on the validity of the contents updated at that time, and decides whether to reflect in the repository server according to the voting results Can be solved.
However, as the scale of development increases, the amount of source code becomes enormous, so it is not realistic to check the update contents of all developers. In many development sites, in order to perform source code review efficiently, it is decided whether to perform source code review from the past performance of the developer such as the occurrence rate of defects. It is desirable to conduct voting.
Also, since the time required for source code review varies from developer to developer, it is inefficient to assign the same time uniformly. It is desirable to determine the voting time based on the past delay time.

  The object of the present invention is to determine whether or not to commit based on the past performance of the committed developer, and if not, calculate the voting time from the past voting delay time, and in accordance with the voting result, It is an object of the present invention to provide a repository server management system capable of efficiently performing a source code review by determining whether to reflect.

In order to achieve the above object, the repository server management system of the present invention manages the storage of programs developed by a plurality of developers belonging to a development project, using the respective developer computers, in the repository server. A system,
The evaluation value including the past performance is acquired from the first database for the developer who has received the program storage application from the developer computer and sent the program storage application, and the program that has received the storage application is stored in the repository server. It is determined whether or not to store based on the evaluation value. If the evaluation value does not satisfy a preset setting value, the storage application program is saved and stored in the second database. A first means for storing in the repository server if satisfied;
Obtain the schedule of each developer from the third database in order to determine whether to save the program stored in the second database in the repository server by an approval vote of another developer belonging to the same development project. A second means for determining a schedule for each developer to vote for approval and notifying each developer;
Accepts and approves approval approval notifications that describe whether or not to save the programs saved in the second database from the developer computer of each developer in the repository server, and sets a preset value for which the approval rate is preset. And a third means for storing the saved and stored program in the repository server when the condition is satisfied, and discarding the saved and stored program when the set value is not satisfied.

The repository server management system of the present invention has the following effects.
A source code review can be performed based on the past performance of the developer, and the quality of the application can be improved. In addition, the source code review can be carried out efficiently, such as making effective use of the developer's time.

Hereinafter, an embodiment of a repository server management system to which the present invention is applied will be described.
FIG. 1 is a system configuration diagram of a repository server management system showing an example of an embodiment of the present invention.
The system according to this embodiment includes a common system 101 and n development systems 102, and the common system 101 and the development system 102 are connected by a network.
In addition, although n development systems are illustrated, even if it is one, it is applicable.
The common system 101 manages information shared among development projects, and stores a project database 103 that holds development project definition information, and the history, evaluation, and results of participating development projects for each developer. A developer database 104 and a schedule database 105 for storing developer schedules are provided.
The project database 103 and developer database 104 are provided with a project input unit 106 for updating the project history.
The schedule database 105 is provided with a schedule input unit 107 for updating the schedule. The contents of the project input unit 106 and the schedule input unit 107 are displayed on the browser by the Web server 108. The developer updates the information managed by the common system 101 by accessing the Web server 108 with a browser.

The development system 102 is provided for each development project, and includes a development PC 109 that is an environment for describing source code, a voting system 110 that evaluates developers and performs voting, and a repository that stores the created source code. The server 111 is configured.
The development PC 109 is connected to the repository server 111 via the voting system 110 via a network.
The development PC 109 is provided for each developer, and includes a source code editing application and a repository server 111 client application. A mouse 112 and a keyboard 113 are provided for operating them. The client application of the repository server has basic functions for operating the repository server 111 such as source code acquisition and commit.
Normally, the connection destination of the client application is set in the repository server 111, but in this system, it is set in the voting system 110. Hereinafter, the commit to the voting system 110 is particularly referred to as a commit application, and the update of the repository 111 by the voting system 110 is referred to as a commit. Since the operation of the client application is known, the description thereof is omitted.

  The voting system 110 includes a system setting database 114 that holds setting information of the voting system 110, a commit availability determination unit 115 that determines whether to acquire the evaluation of the developer who applied for the commit and reflect it in the repository server 111, and a commit application A hold database 116 that holds the content that has been held, a voting database 117 that stores the voting results for the held content, a schedule adjustment unit 118 that determines the scheduled voting date and time for each developer and reserves the schedule, and a decision A mail server 119 for transmitting the scheduled voting date and pending content to the voter by e-mail and a vote input unit 120 for receiving a vote from the voter are provided. In addition, a task input unit 121 that receives requests and defects from the developer and a task database 122 that stores input contents are provided.

Here, the request indicates an individual function that needs to be implemented by the application to be developed. When all the requests are satisfied, the application is completed. A defect indicates a problem such as a program implementation error. In the following, the request and the defect are collectively referred to as an issue.
The voting system 110 is provided with a Web server 123 that displays the contents of the voting input unit 119 and the assignment input unit 120 on a browser. In addition, an evaluation storage unit 124 is provided that calculates the evaluation of the developer based on the determination result of the commit permission determination unit 115, the contents of the assignment database 122, and the contents of the voting database 117, and stores it in the developer database 104. .

The commit permission determination unit 115 acquires developer evaluation from the project database 103 and the developer database 104, and determines whether or not to reflect the contents of the commit application on the repository server 111.
In this system, the evaluation is expressed numerically according to the importance for each item such as occurrence of a defect, and the total evaluation is called integrated evaluation. The integrated evaluation is calculated taking into account the number of days elapsed and experience of development projects. When the integrated evaluation does not satisfy the threshold value stored in the system setting database 114, the commit permission determination unit 115 saves the content of the commit application to the pending database. The suspended content is reflected in the repository server 111 when approved by voting. However, if the vote is rejected, the pending content will be discarded. If the integrated evaluation is higher than the threshold, voting is not performed, but it is immediately reflected in the repository server.
The commit permission / non-commitment determination unit 115 includes means for transmitting a request other than a commit application such as acquisition of a source code of a client application or acquisition of an update history to the repository server 111 and returning the result.

The schedule adjustment unit 118 calculates the voting time for each developer based on the delay time in the past voting recorded in the voting database 117, and the voting scheduled date and time is calculated in the developer's free time recorded in the schedule database 105. Make a reservation.
Here, the delay time is a delay time until the developer actually votes for the reserved voting scheduled date and time.
The repository server 111 manages the change history for each registered source code, updates the source code in accordance with an instruction from the client application, and transmits the contents of the source code at a certain point to the developer PC 109. Note that the internal operation of the repository server 111 is well-known and will not be described.

FIG. 2 is a diagram showing the data structure of the project database 103. The project database 103 includes a project ID 201 for uniquely identifying a project, a project name 202 for designating a project name, and an attribute 203 for designating a feature of the project. Composed.
The project input unit 106 sets a value for the project ID 201 that does not overlap between development projects. Further, the project name 202 stores a name input by the developer to easily distinguish the project. The attribute 203 designates a keyword of a development project, and a plurality of arbitrary items can be designated for one project. The content of the attribute 203 is used for calculation of the integrated evaluation.

FIG. 3 is a diagram showing a data structure of the developer database 104. The developer database 104 includes a developer ID 301 that uniquely identifies a developer and a project history 302. The developer ID is set to a value that does not overlap for each developer. The project history is a record of the projects that the developer specified by the developer ID 301 has participated so far and the evaluation of the projects. The project ID 303, the participation date 304, the end date 305, the type 306, the evaluation 307.
The project ID 303 is input as defined by the project ID 201 in FIG. The participation date 304 and the end date 305 store the date of participation in the project and the date of completion, respectively, and no end date is input to the currently participating project.
The type 306 and the evaluation 307 are stored by the evaluation storage unit 124, and are stored whenever the evaluation is calculated in the participating project.
An evaluation type 306 represents an evaluation type, a request solution indicating that the request has been satisfied, a defect solution indicating that the defect has been corrected, an application approval indicating that the commit application has been approved as a result of voting, and an application There are five types of voting: rejection of application indicating that voting has been rejected, and voting indicating that voting has been performed. The evaluation 307 is an evaluation value calculated by the evaluation storage unit 121 according to the evaluation type, and the value fluctuates according to the setting value of the system setting database 114.

FIG. 4 is a diagram illustrating a data structure of the schedule database 105, and the schedule database 105 includes a developer ID 401 and a schedule 402.
The developer ID 401 is stored as defined by the developer ID 301 in FIG.
A plurality of schedules are registered for each developer, and include a start date 403, an end date 404, and contents 405. These contents are stored by the developer through the schedule input unit 107 or the schedule adjustment unit 118.

FIG. 5 is a diagram illustrating a data structure of the system setting database 114. The system setting database 114 indicates a setting name 501 that is a setting name, a setting value 502 that indicates a set value, and a corresponding setting value. The range 502 is configured.
There are 12 types of setting names, and the integrated evaluation threshold value is an integrated evaluation threshold value for determining whether or not voting is necessary for the developer who has applied for committing by the commit permission determination unit 115.
The average browsing time is the average time required for browsing in line units.
The approval rate threshold value is a threshold value of the approval rate for determining whether or not to reflect in the repository server 111 in the vote result.
The project progress correction value is a correction value for changing the evaluation in the past development project according to the elapsed days in the calculation of the integrated evaluation, and changes according to the elapsed days.
The delayed evaluation value is an evaluation value for voting and changes according to the number of days of delay.
The approval evaluation value is an evaluation value given to an approved developer.
The rejection evaluation value is an evaluation value given to a rejected developer.
The importance level evaluation value is an evaluation value given when the problem is solved, and changes according to the importance level.
The delay correction value is a correction value of the evaluation value given when the problem is solved, and changes according to the delay time of problem resolution.
The defect resolution correction value is an evaluation correction value given when the problem to be solved is a defect.
The demand solution correction value is an evaluation correction value given when the solved problem is a request.
The defect occurrence correction value is an evaluation correction value given when a defect occurs.

FIG. 6 is a diagram illustrating a data structure of the hold database 116. The hold database 116 includes a hold ID 601 for uniquely specifying the held content in the project, an application date / time 602 for storing the date / time of commit application, An applicant 603 indicating a developer who has applied for a commit, a comment 604 for storing a comment designated at the time of commit application, a file name 605 indicating the name of an update file, a 606 indicating a revision to be updated, and an update It consists of update contents 607 indicating the location and contents.
The hold ID 601 is assigned a unique ID in the development project when the commit permission determination unit 115 determines that voting is necessary.
The update date and time 602 stores the date and time when the client application of the development PC 109 applied for commit.
A file name 605 is a list of files that have been applied for commit, and a plurality of source codes are specified by the client application in one commit application.
The target revision 606 indicates a revision to be corrected and is designated by the client application. Here, the revision is an identifier of an editing history assigned to each file by the repository server, and the developer specifies the revision for each source code and acquires the contents at the target time.
The update content 607 is a line-by-line difference between the content of the target revision 605 and the content requested for commit, and this content is calculated and transmitted by the client application.
The contents from 602 to 607 are the same as the contents transmitted by the client application to the repository server 111 in the development using the general repository server 111. If the vote result is approved, the contents are reflected in the repository server 111 as they are. Is done.

FIG. 7 shows the data structure of the voting database 117, and the voting database 117 is composed of a hold ID 701, a standard voting time 702, and a voting result 703.
The hold ID 701 is defined in 601 of FIG. 6 and indicates a commit application to be voted.
The standard voting time 702 is a time serving as a reference for the voting time given to each developer, and the voting time is obtained by adding the average of the voting delay times for each developer to this time. The standard voting time 702 changes according to the amount of update content defined in 607.
The voting result 703 is a result of each developer voting on the content for which the commit application has been applied, and a voter 704 indicating the developer who voted, a scheduled voting date 705 indicating the scheduled voting date and time, and an actual vote. A voting execution date and time 706 indicating the date and time, a determination result 707 indicating the voted result, and an indication item 708 indicating an indication item designated at the time of voting.
As the voter ID, the developer ID defined in 301 of FIG. 3 is stored, and a developer other than the developer who applied for the commit in the development project is stored. The list of voters can be acquired from the applicant described at 603 in FIG. 6, the developer 301 stored in the developer database 104, and the ID 303 of the ongoing project. An ongoing project can be determined by whether or not the scheduled end date 305 is stored.
The scheduled vote date and time 705 stores the result calculated by the schedule adjustment unit 118 based on the standard vote time 702.
The voting date and time 706 stores the date and time when the voting input unit 120 actually voted.
The permission / inhibition 703 is designated by the voter, and stores two types of approval and rejection.
The pointed item 708 is input by the voter when rejection is selected in the availability 703.

FIG. 8 is a diagram showing the data structure of the assignment database 122.
The assignment database 122 includes an assignment ID 801 that uniquely identifies an assignment within the development project, a content 802 that indicates the contents of the assignment, a type 803 that distinguishes whether the assignment is a defect or a request, and a status 804 that indicates the progress status of the assignment. , A scheduled completion date and time 805 indicating the scheduled completion date and time of the task, an importance level 806 indicating the importance level of the task, a generator 807 indicating the developer who has caused the problem, and a correspondence indicating the developer assigned to the resolution of the task And a completion date and time 809 indicating the date and time when the problem has been solved.
The assignment ID 801 is set by the assignment input unit 121 to be unique within the development project.
In the contents 802, a description of the problem is arbitrarily input.
The type 803 is used to select whether the input task is desired or defective, and is used for calculation of evaluation.
The status 804 has three types, and takes one of the following values: an investigation indicating the status immediately after the issue has occurred, an assigned status indicating that a responder has been assigned, and a closed status indicating that the issue has been resolved. .
Note that the state of all tasks transitions to closed after being assigned from the investigation.
The scheduled completion date and time 805 and the importance 806 are input according to the difficulty of the task and the ability of the responder, and are not input when the status 804 is under investigation. The occurrence person 807 is an item for inputting the occurrence person of the trouble found by the investigation, and is inputted when the state 804 is updated to assigned.
If the type 803 is desired, the generator 807 is not input.
The responder 808 inputs a developer corresponding to the task, and inputs when the status 804 is updated to assigned. Note that information on the generator 807 and the responder 808 is used in calculation of evaluation. As the completion date and time 809, the task input unit stores the date and time when the state is updated to closed. The difference between the scheduled completion date and time 805 and the completion date and time 809 is used to calculate the evaluation.

FIG. 9 is an example of a project management screen displayed by the project input unit 106. The project management screen includes a new project registration field 901 and a project entry field 902. The new project registration field 901 includes: A project name input field 903, an attribute input field 904, and a new creation button 905 are provided.
The project entry field 902 includes a project ID input field 906, a developer ID input field 907, a join button 908, and a leave button 909.
The developer inputs these pieces of information by accessing the Web server 108 with a browser. When a project name 903 and an attribute 904 are input and a new creation button is pressed, the contents of the project name input field 903 are stored in the project name 202, and the contents of the attribute input field 904 are stored in the attribute 203. A plurality of attributes can be specified.
When the participation button 908 is pressed after inputting the project ID 906 and the developer ID 907, the project ID 303 is stored in the project history 302 in which the designated content matches the developer ID 301. Further, the date when the participation button 908 is pressed is stored in the participation date 304.
When the release button 909 is pressed, the date when the release button 909 is pressed is stored in the end date 305 in the project history 302 in which the developer ID 301 and the project ID 303 match.

FIG. 10 shows an example of a schedule management screen displayed by the schedule input unit 107. The schedule management screen includes an input field 1001 for a target developer ID, a display button 1002, a schedule display field 1003, and a schedule registration field. 1004.
The schedule display field displays the contents of the designated developer's schedule, and is displayed by inputting the target developer ID input field 1001 and pressing the display button 1002, and displays the contents of the start date and time 403. A start date / time display field 1005, an end date / time display field 1006 for displaying the content of the end date / time 404, a content display field 1007 for displaying the content of the content 405, and a delete button 1008.
When a delete button 1008 is clicked, the corresponding schedule is deleted from the schedule database.
The schedule registration field 1004 includes a start date / time input field 1009, an end date / time input field 1010, a content input field 1011, and a reservation button 1012, and the reservation button 1012 after inputting the contents of each input field. Press to register the entered schedule.

FIG. 11 shows an example of a voting screen displayed by the voting input unit 120, which includes a voting target display field 1101, an application content display field 1102, and a voting input field 1103.
The voting target display column 1101 includes an applicant display column 1104 indicating the commit applicant, an application date / time display column 1105 indicating the date and time of application, and a comment display column 1106 input at the time of commit application. .
The update content display column 1102 includes a file name 1107, a pre-update column 1108 indicating the content before update, and a post-update 1109 indicating the content after update.
The voting input field 1103 includes an indication item input field 1110, an approval button 1111, and a rejection button 1112.
The contents of the display field 1101 to be voted are output based on the contents of the hold database 116, the contents of the applicant 603 are displayed in the display field 1104 of the applicant, the contents of the application date 602 are displayed in the display field 1105 of the application date, The contents of 604 are displayed in the comment display field 1106.
Note that this screen is displayed by the browser, and the target hold ID 601 is specified by the URL.

The application content display field 1102 includes a file name display field 1107, a display field 1108 before update, and a display field 1109 after update, and is displayed for each modified file 605.
The content of the pre-update 1108 is acquired from the repository server 111, and the content of the updated display column 1109 is constructed together with the content of the update content 607.
The updated line is highlighted by changing the color as in 1113.
The voter carefully reads the update contents, inputs the indication item input field 1110, and presses the approval button 1111 or the reject button 1112. The input content is reflected in the voting result 702. It is assumed that the voter ID 703 of the voter is specified by the URL as with the hold ID.

FIG. 12 is a diagram illustrating an example of an assignment management screen output by the assignment input unit 121. The assignment management screen includes a new registration field 1201 for newly registering an assignment and an update field 1202 for updating a registered assignment. Is done.
The new registration column 1201 includes a content input column 1203 for inputting content, a type selection column 1204 for specifying a type, and a registration button 1205.
The content specified in the content input column 1203 and the type selection column 1204 is reflected in the content 802 and the type 803 of the assignment database when a registration button 1205 is pressed. Immediately after registration by pressing the registration button 1205, “under investigation” is stored in the state 804.
The update column 1202 includes a task ID display column 1206 for displaying the content of the task ID 801, a content display column 1207 for displaying the content 802, a type display column 1208 for displaying the type 803 content, and the status 804 content. The selection field 1209 for displaying the state of the person, the input field 1210 for the person who inputs the contents of the person 807, the input field 1211 for the person who inputs the contents of the responder 808, and the contents of the importance 806 are selected. An importance selection field 1212, a scheduled completion date and time 1213 for inputting the content of the scheduled completion date and time 805, and an update button 1214 for reflecting the input content are configured.

The update column 1202 displays all issues whose status 804 is other than closed, and items that have not been entered can be input and reflected in the issue database by pressing the update button 1214. However, when the status selection field 1209 is changed from being surveyed to assigned, the occurrence entry field 1210, the responder entry field 1211, the importance level 1212, and the expected completion date 1213 need to be input. There is.
In addition, when the type 1208 is a demand, the generator input field 1210 is not displayed. The state selection field 1209 can be updated to closed only when it has been assigned. When the close button is selected and the update button 1214 is pressed, the date and time is stored in the completion date and time 809.

FIG. 13 is a diagram showing the contents of a vote request email that the schedule adjustment unit 118 sends to the voter using the mail server 119. The voter development ID 1301, the commit applicant developer ID 1302, the application date and time 1303, comment content 1304, voting schedule date and time 1305, and voting screen URL 1306.
The development ID of the voter is acquired from the voter 703 of the vote database 117.
The developer ID 1302 of the commit applicant, the application date / time 1303, and the comment 1304 are acquired from the applicant 603, the application date / time 602, and the comment 604 whose holding ID 701 matches.
The voting schedule date 1305 is acquired from the voting date determined by the schedule adjustment unit.
The voting URL 1306 includes a voter developer ID and a hold ID as parameters, and the vote input unit 120 determines a target hold ID and a voter based on this content.

FIG. 14 is a diagram showing the contents of a rejection notification email that is sent to the applicant when the result of voting is rejection. The rejection notification email includes a developer ID 1401 of the commit applicant, an application date 1402, and a comment. 1403 and indication items 1404.
The contents 1401 to 1403 are acquired from the contents of the hold database 116, and the contents of the applicant 603, the application date and time 602, and the comment 604 are reflected.
The content of the indication item 1404 reflects the content of the indication item 708.
Note that this system assumes that the developer's email address can be inferred from the developer ID, but if this is not possible, the developer database 104 must have an email address defined for each developer ID. Needless to say.

FIG. 15 is a flowchart showing the overall flow of application development using this system.
The developer specifies the project ID 906 and developer ID 907 on the project management screen output by the project input unit 106 and participates in the developer project (step 1501).
Next, the developer grasps the assignment assigned in the assignment database 122 and describes the source code on the development PC 109 in order to solve it (steps 1502 and 1503).
When the source code is completed, the client application of the repository server 111 is operated to apply for committing the source code to the voting system 110 (step 1504).

When the commit application is received, the commit possibility determination unit 115 acquires the developer's integrated evaluation from the developer database 104 and the project database 103 (step 1505).
Next, the commit possibility determination unit 115 compares the acquired integrated evaluation with the integrated evaluation threshold set in the system setting database 114 (step 1506).
If the integrated evaluation is less than or equal to the integrated evaluation threshold, the commit application content is saved in the holding database 116, an area for storing the voting results is created in the voting database 117, and the voting schedule is calculated by the schedule adjustment unit 118. (Step 1507).

The voter receives the voting request mail shown in FIG. 13 from the mail server 119, accesses the voting input unit 120 at the URL 1306 described therein, confirms the update contents, and inputs the voting result (step 1508).
When all the voters 703 have voted, the commit permission determination unit 115 calculates the approval ratio of the total number of votes from the permission 707 and compares it with the approval rate threshold stored in the system setting database 114 (step 1509).
If the approval rate exceeds the approval rate threshold, the contents of the commit application saved in the hold ID 116 are reflected in the repository server 111 (step 1510).
Next, the developer operates the assignment update screen output by the assignment input 121 to update the assignment state 1209 to closed (step 1511).

In step 1506, if the integrated evaluation exceeds the integrated evaluation threshold, steps 1510 and 1511 are executed without voting.
If the approval rate is equal to or lower than the set value in step 1509, the process returns to step 1503 and the correction is repeated until approval is obtained.
If a problem is found in the test or the like in response to the request solved as described above (step 1512), the problem is registered in the problem database 122 and the process returns to step 1503.
If there is no problem, the remaining requests are solved. If all the requests are solved, the release button 909 is pressed on the project management screen to leave the development project (steps 1502 and 1513).

FIG. 16 is a flowchart showing a procedure for acquiring the integrated evaluation described in step 1505.
In this system, the integrated evaluation is calculated taking into account the attributes of the development project and the number of days elapsed. First, the integrated evaluation R is initialized to 0 (step 1601).
Next, one project history 302 having the same applicant 603 and developer ID is acquired (step 1602).
Next, the evaluations stored in the project history are summed and stored in the temporary variable P (step 1603). Depending on the evaluation value, the value of P may be a negative number.
Next, with reference to the project history end date 305, it is determined whether or not the acquired project has ended (step 1604).
If it is a completed project, the attribute 203 is acquired (step 1605).

Next, the attribute 203 of the currently ongoing project in which the end date 305 is not stored is acquired, and it is determined whether there is an attribute that matches the attribute acquired in step 1605 (step 1606).
If there is a match, the matching ratio in the attributes of the currently ongoing project is stored in the variable α (step 1607).
Next, the elapsed days from the acquired project end date 305 to the present are acquired (step 1608), and the project progress correction value corresponding to the elapsed days is acquired from the system setting database 114 and stored in the temporary variable β ( Step 1609). Then, the result obtained by multiplying the overall evaluation R by P, which is the total value in one project, α, and β is added (step 1610).
In step 1604, if the acquired project is an ongoing project, 1 is substituted for α (step 1611), 1 is substituted for β (step 1612), and step 1610 is executed.
The above operation is performed on all project histories (step 1613).
As a result, even if the evaluation is constant, the comprehensive evaluation value varies according to the attributes of the ongoing project and the elapsed days.

FIG. 17 to FIG. 19 are flowcharts in which the evaluation storage unit 124 calculates the developer's evaluation, and the timing for determining the evaluation in this system is when voting, when determining the voting result, and when the task is updated There are three.
FIG. 17 is a flowchart showing the evaluation calculation procedure at the time of voting. First, the voter's estimated vote date and time is obtained from the estimated vote date and time 705 (step 1701).
Next, the actual voting date and time of voting is acquired from 706, and the delay time is acquired together with step 1701 (step 1702).
Next, the corresponding evaluation is acquired from the delay time and the delay evaluation value of the system setting database 114 (step 1703).
Finally, the evaluation value is stored in the evaluation 307 of the developer database in which the voter 704 and the developer ID 301 coincide with each other, the vote is stored in the attribute 306, and the process ends (step 1704).

FIG. 18 is a flowchart showing the procedure of evaluation calculation at the time of voting result determination. From approval / disapproval 707, the ratio of the number of approvals in all voting results in the pending data is acquired (step 1801).
Next, it is determined whether to approve by comparing with the approval rate threshold of the system setting database 114 (step 1802).
If approval is obtained, the result obtained by multiplying the approval number ratio by the approval evaluation value in the system setting database 114 is used as the evaluation value (step 1803).
When rejected, the result obtained by multiplying the rejection ratio by the rejection evaluation value of the system setting 114 is set as the evaluation value (step 1804).
Finally, the evaluation value is stored in the evaluation 307 of the developer database 104 in which the applicant 603 and the developer ID 301 match, and the application 306 or application rejection is stored in the attribute 306 according to the approval result, and the process ends. ).

FIG. 19 is a flowchart showing the procedure of evaluation calculation at the time of task update. When the task is updated, the evaluation storage unit 124 acquires the updated state 804 (step 1901).
When the status is updated to closed (step 1902), the responder 808 is designated as the evaluation subject (step 1903).
Next, a corresponding importance evaluation value is acquired from the system setting 114 based on the importance (step 1904).
Next, the number of days delayed from the difference between the scheduled completion date and time 805 and the completion date and time 809 is acquired, and the corresponding delay correction value is acquired from the system setting 114 (step 1905).
Next, the result obtained by multiplying the temporary variable α by the importance evaluation value acquired in step 1904 and the delay correction value acquired in step 1905 is stored (step 1906).
Next, the content of the type 803 is judged. If the problem is a defect, the result obtained by multiplying α calculated in step 1906 and the defect solution correction value defined in the system setting 114 is used as an evaluation value (steps 1907, 1908, Step 1909).

If the type 803 is a request, the result obtained by multiplying α calculated in step 1906 and the request solution correction value defined in the system setting 114 is used as an evaluation value (step 1907, step 1910, step 1911).
If the status 803 is updated to “allocated”, the generator 807 is designated as the evaluation subject (step 1912).
Next, as in step 1903, an importance evaluation value is acquired from the importance 806 (step 1914).
Next, a result obtained by multiplying the importance evaluation value acquired in step 1914 and the defect occurrence correction value acquired from the system setting 114 is set as an evaluation value (step 1913).
The evaluation value calculated as described above is stored in the evaluation target person's evaluation 307 and the process ends (step 1916).
If the updated state is under investigation, the process ends without doing anything (step 1917).

FIG. 20 is a flowchart illustrating a procedure in which the schedule adjustment unit 118 determines a voting time for each developer based on the applied update content.
First, the number of characters in the update content 607 is acquired (step 2001).
Next, the average browsing time defined in the system setting 114 is multiplied by the number of characters acquired in step 2101 and the result is stored in the standard voting time 702 (step 2002).
Next, one voter 703 is acquired (step 2003). The delay time is acquired from the difference between the scheduled vote date 705 and the vote execution date 706 recorded in the voter database 117 of the voter, and a project average delay time that is an average of the delay times during the development project is calculated (step 2004). Step 2005). Then, the average delay time is added to the standard voting time calculated in step 2002 to obtain the developer voting time (step 2006).
The above processing is performed for each developer (step 2007).
The scheduled voting date and time 705 is calculated based on the voting time optimum for the development project from the free time stored in the schedule database 105 for each developer and the voting time calculated in FIG. Since this optimization algorithm is publicly known, a description thereof will be omitted.

It is a system configuration figure showing an embodiment of the invention. It is a figure which shows the data structure of a project database. It is a figure which shows the data structure of a developer database. It is a figure which shows the data structure of a schedule database. It is a figure which shows the data structure of a system setting. It is a figure which shows the data structure of a pending | holding database. It is a figure which shows the data structure of a voting database. It is a figure which shows the data structure of a subject database. It is a figure which shows an example of a project management screen. It is a figure which shows an example of a schedule management screen. It is a figure which shows an example of a voting screen. It is an example of an assignment management screen. It is a figure which shows an example of a voting request mail. It is an example of a rejection notice mail. It is a flowchart which shows the process of the whole system. It is a flowchart which shows integrated evaluation acquisition processing. It is a flowchart which shows the evaluation calculation process at the time of voting. It is a flowchart which shows the evaluation calculation process at the time of voting result determination. It is a flowchart which shows the evaluation calculation process at the time of a task update. It is a flowchart which shows a voting time calculation process. It is a whole block diagram of a conventional system.

Explanation of symbols

101 common system 102 development system 103 project database 104 developer database 105 schedule database 109 developer PC
DESCRIPTION OF SYMBOLS 110 Voting system 111 Repository server 114 System setting database 115 Commitability determination part 116 Pending database 117 Voting database 118 Schedule adjustment part 120 Vote input part

Claims (1)

A system that manages the storage of programs developed by a plurality of developers belonging to a development project using their own developer computers in a repository server,
The evaluation value including the past performance is acquired from the first database for the developer who has received the program storage application from the developer computer and sent the program storage application, and the program that has received the storage application is stored in the repository server. It is determined whether or not to store based on the evaluation value. If the evaluation value does not satisfy a preset setting value, the storage application program is saved and stored in the second database. A first means for storing in the repository server if satisfied;
Obtain the schedule of each developer from the third database in order to determine whether to save the program stored in the second database in the repository server by an approval vote of another developer belonging to the same development project. A second means for determining a schedule for each developer to vote for approval and notifying each developer;
Accepts and approves approval approval notifications that describe whether or not to save the programs saved in the second database from the developer computer of each developer in the repository server, and sets a preset value for which the approval rate is preset. And a third means for storing the saved and stored program in the repository server when the condition is satisfied, and discarding the saved and stored program when the set value is not satisfied. Management system.

Images